Hi Nat,
On 04/08/16 14:00, Nat Sakimura wrote: > >> 1. alg:none request JWTs being no longer permitted > > I think it is a bug of the OpenID Connect Core 1.0. > > > > Request Object itself can be alg=none in OAuth JAR draft 08 as well. > > > > If alg=none, it MUST NOT be passed by value using `request` parameter. > > It is fine to be that way as long as you pass it by reference. > > > > Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated to > "Request Object" if I remember correctly. However, during the re-factoring, > it was subsumed in "5.5. Requesting Claims using the "claims" Request > Parameter" and the statement about allowing alg=none in Request Object that > are passed by value sneaked in there. > > > > I am going to file a bug report for OpenID Connect on this. > > > > Or, do you have any specific use case for keeping "alg=none" for the > "passing by value" case? An "alg:none" request object has no value if it's passed by value, so yes, in that sense we can call it a bug. The only potential use case I see for "alg:none" is clients that can't handle crypto but may be able to pass the JWT via a HTTPS URL (perhaps preregistered). BTW, I don't see request URI registration mentioned, and this is quite a significant feature, especially in dynamic scenarios. > >> 2. HTTPS request_uri's becoming always required, though there is confusion > about that (see below). > > > > I should remove the statement in 5.2.1., as it just meant to have repeated > what it was said in 5.2. > > I see. > I should also add further condition in 5.2. so that it becomes: > > > > ``` > > unless the target Request Object is signed in a way that is > > verifiable by the Authorization Server and the channel is > > protected so that network attacker cannot observe. > > ``` > > > > What do you think? On the 1st condition - HMAC - protected or signed request object to ensure authenticity - ok, this is a must if the JWT is fed via plain HTTP, to ensure the parameters cannot be tampered with. On the 2nd condition - do you mean encrypting the JWT, or something else? > > > Nat > > > > -- > > PLEASE READ :This e-mail is confidential and intended for the > > named recipient only. If you are not an intended recipient, > > please notify the sender and delete this e-mail. > > > > From: OAuth [mailto:[email protected]] On Behalf Of Vladimir Dzhuvinov > Sent: Thursday, August 4, 2016 6:59 PM > To: [email protected] > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt > > > > Thanks Nat. > > It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect > in regard to > > 1. alg:none request JWTs being no longer permitted > > 2. HTTPS request_uri's becoming always required, though there is confusion > about that (see below). > > > > I don't know if this is intentional. > > > > Quoting the original Connect spec on alg:none: > > http://openid.net/specs/openid-connect-core-1_0.html#RequestObject > > ``` > The Request Object MAY be signed or unsigned (plaintext). When it is > plaintext, this is indicated by use of the none algorithm > <http://openid.net/specs/openid-connect-core-1_0.html#JWA> [JWA] in the JOSE > Header. > ``` > > > There is also confusion about the requirement to have HTTPS, which in 5.2 is > conditionally required, and in 5.2.1 always required (the 5.2.1 edit > appeared in -08). > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2 > > ``` > > The contents of the resource referenced by the URL MUST be a Request > Object. 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. > ``` > > > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1 > > ``` > > The URL MUST be HTTPS URL. > > ``` > > > Cheers, > > Vladimir > > -- Vladimir Dzhuvinov :: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
