Hi Vladimir, See inline:
> -----Original Message----- > From: Vladimir Dzhuvinov [mailto:[email protected]] > Sent: Friday, August 5, 2016 5:15 AM > To: Nat Sakimura <[email protected]>; [email protected] > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt > > 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. > It is obscure, I agree. The scenario was there from the beginning, and I made sure that it is permissible from the very beginning. The following sentences in 5.2.1 is talking about this. ``` The Client stores the Request Object resource either locally or remotely at a URL the Authorization Server can access. ``` Then, in Section 10.3, it goes: ``` (c) Authorization Server is providing an endpoint that provides a Request Object URI in exchange for a Request Object. [...snip...] (d) A third party, such as a Trust Framework Provider, provides an endpoint that provides a Request Object URI in exchange for a Request Object. ``` BTW, I found a bug in 10.3. (d). The reference (b) in the paragraph 1 should be (c) instead. Perhaps I should mention these possibilities in the Intro and 5.2. More significant change would be to define an API to do it, e.g., swagger: '2.0' info: version: "1.0.0" title: Request Registration Endpoint Example description: | An example for how to use Request Registration Endpoint. host: as.example.com schemes: - https securityDefinitions: basicAuth: type: basic description: HTTP Basic Authentication. Works over `HTTPS` paths: /v1/requestObjects/: post: security: - basicAuth: [] responses: 200: description: Request Uri schema: $ref: #/definitions/RequestURIResponse examples: application/json: |- { "request_uri": "file://mc.example.com/aFwfo9w", } default: description: Unexpected Error schema: $ref: "#/definitions/Error" Though it is possible to define something like this in this spec., I would rather do it as a separate spec. > > > > >> 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? For example, the Authorization Server (AS) may provide a Request Object registration service which returns a HTTP `request_uri` which is only accessible by the AS. > > > > > > 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] > -- 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. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
