[OAUTH-WG] JWT Secured Authorization Request: Inconsistencies with request_uri

[Dave Tonge]

Hi Nat and John

I have some questions re the JWT Secured Authorization Request spec
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12

*1. Does the request_uri always have to be an URL? *
If the request object is hosted by the client then it makes sense, but if
10.3.d is followed and the AS provides an endpoint where the client can
exchange a request object for a "Request Object URI" then it would seem
acceptable for that uri to be an urn. Only the AS would need to be able to
fetch the request object and therefore there would be no need for the
request object to be made available via https.

*2. Should the mechanism described in 10.3.d be explained in 5.2?*
I think that 10.3.d could be widely used as it solves a number of problems
- however it is currently not clearly defined in either OIDC Core
or jwsreq.

*3. The spec seems inconsistent on the use of HTTPS*
Subject to any discussion re request_uris always being urls, there seems to
be an inconsistency between 5.2 and 5.2.1

5.2:

The scheme used in the "request_uri" value *MUST be "https",
unless* the target Request Object is signed in a way that is
verifiable by the Authorization Server.


5.2.1

The Client stores the Request Object resource either locally or
remotely at a URL the Authorization Server can access. *The URL MUST
be HTTPS URL*. This URL is the Request Object URI, "request_uri".



Thanks

[Jim Manico]

From a security POV please force HTTPS as we see in 5.2.1. The only performance problem with HTTPS is that it's not used enough. There is no good reason for a security framework to support HTTP.

Aloha,
Jim

Post by Dave Tonge
Hi Nat and John
I have some questions re the JWT Secured Authorization Request spec
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12
1. Does the request_uri always have to be an URL?
If the request object is hosted by the client then it makes sense, but if 10.3.d is followed and the AS provides an endpoint where the client can exchange a request object for a "Request Object URI" then it would seem acceptable for that uri to be an urn. Only the AS would need to be able to fetch the request object and therefore there would be no need for the request object to be made available via https.
2. Should the mechanism described in 10.3.d be explained in 5.2?
I think that 10.3.d could be widely used as it solves a number of problems - however it is currently not clearly defined in either OIDC Core or jwsreq.
3. The spec seems inconsistent on the use of HTTPS
Subject to any discussion re request_uris always being urls, there seems to be an inconsistency between 5.2 and 5.2.1
The scheme used in the "request_uri" value MUST be "https",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.
5.2.1
The Client stores the Request Object resource either locally or
remotely at a URL the Authorization Server can access. The URL MUST
be HTTPS URL. This URL is the Request Object URI, "request_uri".
Thanks
--
Dave Tonge
CTO, Momentum Financial Technology
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth