Yes, that sounds good to me. Best, Filip
On Tue, 25 Feb 2020 at 03:18, Nat Sakimura <sakim...@gmail.com> wrote: > So, where should we take it to? > Just add back client_id as it used to be? > > On Fri, Jan 24, 2020 at 6:55 AM John Bradley <ve7...@ve7jtb.com> wrote: > >> >> ---------- Forwarded message --------- >> From: John Bradley <ve7...@ve7jtb.com> >> Date: Sat, Jan 18, 2020, 9:31 PM >> Subject: Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request >> (JAR) vs OIDC request object >> To: Benjamin Kaduk <ka...@mit.edu> >> >> >> If you put the iss in the JWE header it is integrity protected, as JWE >> only supports AAD encryption algs. >> >> It is more of a problem when the client is sending a requestURI in that >> case having the clientID in the GET to the Authorization endpoint is useful. >> >> I think there is a argument for explicitly allowing the clientID as long >> as it exactly matches the clientID in the JAR. >> >> John B. >> >> On Fri, Jan 17, 2020 at 11:53 PM Benjamin Kaduk <ka...@mit.edu> wrote: >> >>> On Fri, Jan 17, 2020 at 08:44:18AM -0500, Justin Richer wrote: >>> > I don’t agree with this stance from a security or implementation >>> perspective. >>> > >>> > If there’s a clear order of precedence for the information, it’s not >>> particularly problematic. Everything inside the request object is to be >>> taken over things outside the request object. We have the exact same >>> semantics and process with dynamic registration, where the software >>> statement is carried alongside plain JSON claims, and the two are mixed >>> with a very simple algorithm: >>> > >>> > - If a field is inside the signed payload, use that value and ignore >>> any copy of it on the outside >>> > - If a field is not inside the signed payload and is outside the >>> signed payload, use the outside value >>> > >>> > Can someone please point out a concrete security issue with this >>> algorithm? This is the extent of the “merge” semantics that we need here, >>> and it would solve not only the ability to use this for use cases that call >>> for a more static request object (perhaps signed by a third party and not >>> the client) along side the plain parameters that can vary, but also the >>> backwards compatibility issue that’s been discussed. With this algorithm in >>> place, you could have OIDC clients actually be compliant with the spec, >>> since OIDC requires replication of the values inside the request object on >>> the outside with exact matches. An OIDC server wouldn’t be fully compliant >>> with the new spec since it would reject some compliant JAR requests that >>> are missing the external parameters, but that’s fairly easy logic to add on >>> the OIDC side. And in that case you get a matrix of compatibility like: >>> >>> I agree that the merge algorithm is simple and fairly straightforward to >>> implement. But, as Joseph has been alluding, it's only simple if you've >>> already made the decision to use all the parameters, both from inside and >>> from outside the signed payload. The security risk lies about having to >>> make the trust decision twice, more than the mundane details of actually >>> doing the merge. (Though there is still some latent risk, given that >>> we've >>> seen some really crazy quality of implementation out there.) >>> >>> It's certainly *possible* that things end up fine in many well-deliniated >>> cases where merging can be used. But it's more complicated to reason >>> about, and I don't remmber seeing much previous discussion about the >>> specifics of the double trust decision. >>> >>> -Ben >>> >>> > >>> > JAR Server | OIDC Server | >>> > ------------+------------+--------------+ >>> > JAR Client | YES | NO | >>> > OIDC Client | YES | YES | >>> > >>> > Breaking one out of the four possible combinations in a very >>> predictable way is, I think, the best way to handle backwards compatibility >>> here. >>> > >>> > But between this issue and JAR’s problematic call for the value of a >>> request_uri to always be a JWT and be fetchable by the AS (neither of which >>> are true in the case of PAR) makes me think we need to pull this back and >>> rework those things, in a push back to the IESG’s comments. >>> > >>> > — Justin >>> > >>> > >>> > > On Jan 16, 2020, at 7:38 PM, Joseph Heenan <jos...@authlete.com> >>> wrote: >>> > > >>> > > I agree with this, particularly the security concerns of merging. If >>> we merge, we can much guarantee there will eventually be a security issue >>> where an attacker is able to gain an advantage by adding a parameter to the >>> url query (which the server would then happily process if that parameter >>> isn’t found inside the request object). Ruling out that case makes security >>> analysis (particularly when creating new OAuth2 parameters) significantly >>> simpler. >>> > > >>> > > Putting the iss in the JWE header and having the client_id >>> duplicated outside the request object seem to address all the concerns I’ve >>> seen raised. >>> > > >>> > > (It seems like it may be unnecessary to have the client_id >>> duplicated outside if the request_uri is a PAR one though.) >>> > > >>> > > Joseph >>> > > >>> > > >>> > > >>> > >> On 16 Jan 2020, at 22:40, John Bradley <ve7...@ve7jtb.com> wrote: >>> > >> >>> > >> I agree with the IESG reasoning that merging is problimatic. Once >>> we >>> > >> allow that given a unknown list of possible paramaters with diffrent >>> > >> security properties it would be quite difficult to specify safely. >>> > >> >>> > >> Query paramaters can still be sent outside the JAR, but if they are >>> in >>> > >> the OAuth registry the AS MUST ignore them. >>> > >> >>> > >> Puting the iss in the JWE headder addresses the encryption issue >>> without >>> > >> merging. >>> > >> >>> > >> I understand that some existing servers have dependencys on getting >>> the >>> > >> clientID as a query paramater. >>> > >> >>> > >> Is that the only paramater that people have a issue with as oposed >>> to a >>> > >> nice to have? >>> > >> >>> > >> Would allowing the AS to not ignore the clientID as a query >>> paramater as >>> > >> long as it matches the one inside the JAR, basicly the same as >>> Connect >>> > >> request object but for just the one paramater make life easier for >>> the >>> > >> servers? >>> > >> >>> > >> I am not promising a change but gathering info before proposing >>> something. >>> > >> >>> > >> John B. >>> > >> >>> > >> >>> > >> On 1/16/2020 1:53 AM, Benjamin Kaduk wrote: >>> > >>> On Wed, Jan 15, 2020 at 11:02:33PM +0200, Vladimir Dzhuvinov wrote: >>> > >>>> On 14/01/2020 19:20, Takahiko Kawasaki wrote: >>> > >>>>> Well, embedding a client_id claim in the JWE header in order to >>> > >>>>> achieve "request parameters outside the request object should >>> not be >>> > >>>>> referred to" is like "putting the cart before the horse". Why do >>> we >>> > >>>>> have to avoid using the traditional client_id request parameter >>> so >>> > >>>>> stubbornly? >>> > >>>>> >>> > >>>>> The last paragraph of Section 3.2.1 >>> > >>>>> <https://tools.ietf.org/html/rfc6749#section-3.2.1> of RFC 6749 >>> says >>> > >>>>> as follows. >>> > >>>>> >>> > >>>>> /A client MAY use the "client_id" request parameter to identify >>> > >>>>> itself when sending requests to the token endpoint. In the >>> > >>>>> "authorization_code" "grant_type" request to the token >>> endpoint, >>> > >>>>> *an unauthenticated client MUST send its "client_id" to prevent >>> > >>>>> itself from inadvertently accepting a code intended for a >>> client >>> > >>>>> with a different "client_id".* This protects the client from >>> > >>>>> substitution of the authentication code. (It provides no >>> > >>>>> additional security for the protected resource.)/ >>> > >>>>> >>> > >>>>> >>> > >>>>> If the same reasoning applies, a client_id must always be sent >>> with >>> > >>>>> request / request_uri because client authentication is not >>> performed >>> > >>>>> at the authorization endpoint. In other words, */an >>> unauthenticated >>> > >>>>> client (every client is unauthenticated at the authorization >>> endpoint) >>> > >>>>> MUST send its "client_id" to prevent itself from inadvertently >>> > >>>>> accepting a request object for a client with a different >>> "client_id"./* >>> > >>>>> >>> > >>>> Identifying the client in JAR request_uri requests can be really >>> useful >>> > >>>> so that an AS which requires request_uri registration to prevent >>> DDoS >>> > >>>> attacks and other checks can do those without having to index all >>> > >>>> request_uris individually. I mentioned this before. >>> > >>>> >>> > >>>> I really wonder what the reasoning of the IESG reviewers was to >>> insist >>> > >>>> on no params outside the JAR JWT / request_uri. >>> > >>>> >>> > >>>> I'm beginning to realise this step of the review process isn't >>> > >>>> particularly transparent to WG members. >>> > >>> Could you expand on that a bit more? My understanding is that the >>> IESG >>> > >>> ballot mail gets copied to the WG precisely so that there is >>> transparency, >>> > >>> e.g., the thread starting at >>> > >>> >>> https://mailarchive.ietf.org/arch/msg/oauth/lkOhwiDj_hCI55BQRdiR9R0JwgI >>> > >>> Which admittely is from almost three years ago, but that's the >>> earliest >>> > >>> that I found that could be seen as the source of this behavior. >>> > >>> >>> > >>> -Ben >>> > >>> >>> > >>> P.S. some other discussion at >>> > >>> >>> https://mailarchive.ietf.org/arch/msg/oauth/-tUrNY1X9eI_tQGI8T-IGx4xHy8 >>> and >>> > >>> >>> https://mailarchive.ietf.org/arch/msg/oauth/Uke1nxRlgx62EJLevZgpWCz_UwY >>> and >>> > >>> so on. >>> > >>> >>> > >>> _______________________________________________ >>> > >>> OAuth mailing list >>> > >>> OAuth@ietf.org >>> > >>> https://www.ietf.org/mailman/listinfo/oauth >>> > >> >>> > >> _______________________________________________ >>> > >> OAuth mailing list >>> > >> OAuth@ietf.org >>> > >> https://www.ietf.org/mailman/listinfo/oauth >>> > > >>> > > _______________________________________________ >>> > > OAuth mailing list >>> > > OAuth@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/oauth >>> > >>> >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
