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

From: Dave Tonge <[email-masked]>
Date: Fri, 24 Mar 2017 16:15:05 +0000

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

-- 
Dave Tonge
CT
O, Momentum Financial Technology

---

From: Jim Manico <[email-masked]>
Date: Fri, 24 Mar 2017 10:14:19 -0700

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

> On Mar 24, 2017, at 9:15 AM, Dave Tonge <[email-masked]> wrote:
> 
> Hi Nat and John
> 
> 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
>    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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth