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. Vladimir > Best Regards, > Taka > > > > On Tue, Jan 14, 2020 at 12:57 AM Vladimir Dzhuvinov > <vladi...@connect2id.com <mailto:vladi...@connect2id.com>> wrote: > > John, thanks, much appreciated! > > On 11/01/2020 21:36, John Bradley wrote: >> >> Yes JAR is not prohibiting paramater replication in the header. >> >> I will see if i can add something in final edits to call that out. >> >> John B. >> >> On 1/11/2020 6:16 AM, Vladimir Dzhuvinov wrote: >>> >>> Thanks Mike for the rfc7519 section-5.3 >>> <https://tools.ietf.org/html/rfc7519#section-5.3> pointer. Can >>> this parameter replication be used for client_id or the >>> client_id ass "iss" even though it isn't explicitly mentioned in >>> the JAR spec? >>> >>> On 11/01/2020 02:58, John Bradley wrote: >>>> Right we just don't say to put the iss there in OIDC if it's >>>> symetricly encrypted. >>> >>> OIDC doesn't have the symmetric key selection issue, I suppose >>> that why the possibility to replicate params to the JWE header >>> isn't mentioned at all. OIDC requires the top-level query params >>> to represent a valid OAuth 2.0 request, and there client_id is >>> required. If the client_id is present the client registration >>> together with any present client_secret can be retrieved. >>> >>> I reread the JAR spec, this is the only place that mentions >>> handling of symmetric JWE. >>> >>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.2 >>> >>>> (b) Verifying that the symmetric key for the JWE encryption is the >>>> correct one if the JWE is using symmetric encryption. >>> >>> >>> Vladimir >>> >>> >>>> >>>> On Fri, Jan 10, 2020, 9:41 PM Mike Jones >>>> <michael.jo...@microsoft.com >>>> <mailto:michael.jo...@microsoft.com>> wrote: >>>> >>>> The technique of replicating JWT claims that need to be >>>> publicly visible in an encrypted JWT in the header is >>>> defined at >>>> https://tools.ietf.org/html/rfc7519#section-5.3. (Thanks >>>> to Dick Hardt for bringing this need to my attention as we >>>> were finishing the JWT spec.) >>>> >>>> >>>> >>>> -- Mike >>>> >>>> >>>> >>>> *From:* OAuth <oauth-boun...@ietf.org >>>> <mailto:oauth-boun...@ietf.org>> *On Behalf Of * John Bradley >>>> *Sent:* Friday, January 10, 2020 2:15 PM >>>> *To:* Vladimir Dzhuvinov <vladi...@connect2id.com >>>> <mailto:vladi...@connect2id.com>> >>>> *Cc:* IETF oauth WG <oauth@ietf.org <mailto:oauth@ietf.org>> >>>> *Subject:* [EXTERNAL] Re: [OAUTH-WG] JWT Secured >>>> Authorization Request (JAR) vs OIDC request object >>>> >>>> >>>> >>>> The intent was to do that, but specs change once the OAuth >>>> WG and IESG get there hands on them. >>>> >>>> >>>> >>>> Being backwards compatible with OIDC is not a compelling >>>> argument to the IESG. >>>> >>>> >>>> >>>> We were mostly thinking of asymmetric encryption. >>>> >>>> >>>> >>>> Specifying puting the issuer and or the audience in the >>>> headder has come up in the past but probably is not >>>> documented. >>>> >>>> >>>> >>>> John B >>>> >>>> >>>> >>>> On Fri, Jan 10, 2020, 6:29 PM Vladimir Dzhuvinov >>>> <vladi...@connect2id.com <mailto:vladi...@connect2id.com>> >>>> wrote: >>>> >>>> Yes, putting the client_id into the JWE header is a way >>>> around the need >>>> to have the client_id outside the JWE as top-level >>>> authZ request parameter. >>>> >>>> Unfortunately this work around isn't mentioned >>>> anywhere, I just checked >>>> the most recent draft-ietf-oauth-jwsreq-20. >>>> >>>> Our DDoS attack mitigation (for OIDC request_uri) also >>>> relies on the >>>> presence of client_id as top-level parameter, together >>>> with requiring >>>> RPs to register their request_uri's (so that we don't >>>> need to build and >>>> store an index of all request_uri's). I just had a look >>>> at "DDoS Attack >>>> on the Authorization Server" and also realised the >>>> request_uri >>>> registration isn't explicitly mentioned as attack >>>> prevention ("the >>>> server should (a) check that the value of "request_uri" >>>> parameter does >>>> not point to an unexpected location"). >>>> >>>> >>>> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20#section-10.4.1 >>>> >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-jwsreq-20%23section-10.4.1&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=%2FvHVp68SN5CAHimqZ5jx93aOCIruxqLCRMUFCc5DSxc%3D&reserved=0> >>>> >>>> To be honest, I feel quite bad about the situation with >>>> JAR we are in >>>> now. For some reason I had the impression that OAuth >>>> JAR was going to be >>>> the OIDC request / request_uri for general OAuth 2.0 >>>> use, as with other >>>> OIDC bits that later became general purpose OAuth 2.0 >>>> specs. >>>> >>>> I find it unfortunate I didn't notice this when I was >>>> reviewing the spec >>>> in the past. >>>> >>>> Vladimir >>>> >>>> >>>> On 10/01/2020 22:39, Filip Skokan wrote: >>>> > Vladimir, >>>> > >>>> > For that very case the payload claims may be repeated >>>> in the JWE protected header. An implementation wanting >>>> to handle this may look for iss/client_id there. >>>> > >>>> > Odesláno z iPhonu >>>> > >>>> >> 10. 1. 2020 v 21:19, Vladimir Dzhuvinov >>>> <vladi...@connect2id.com <mailto:vladi...@connect2id.com>>: >>>> >> >>>> >> I just realised there is one class of JARs where >>>> it's practially >>>> >> impossible to process the request if merge isn't >>>> supported: >>>> >> >>>> >> The client submits a JAR encrypted (JWT) with a >>>> shared key. OIDC allows >>>> >> for that and specs a method for deriving the shared >>>> key from the >>>> >> client_secret: >>>> >> >>>> >> >>>> >>>> https://openid.net/specs/openid-connect-core-1_0.html#Encryption >>>> >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23Encryption&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068793193&sdata=soK9t7pzu504iILuDNFnG%2BMLxZPP2pN6ugEJ4ZOpqd4%3D&reserved=0> >>>> >> >>>> >> If the JAR is encrypted with the client_secret, and >>>> there is no >>>> >> top-level client_id parameter, there's no good way >>>> for the OP to find >>>> >> out which client_secret to get to try to decrypt the >>>> JWE. Unless the OP >>>> >> keeps an index of all issued client_secret's. >>>> >> >>>> >> >>>> >> OP servers which require request_uri registration >>>> >> (require_request_uri_registration=true) and don't >>>> want to index all >>>> >> registered request_uri's, also have no good way to >>>> process a request_uri >>>> >> if the client_id isn't present as top-level parameter. >>>> >> >>>> >> >>>> >> Vladimir >>>> >> >>>> >> >>>> >>> On 10/01/2020 20:13, Torsten Lodderstedt wrote: >>>> >>> >>>> >>>>> Am 10.01.2020 um 16:53 schrieb John Bradley >>>> <ve7...@ve7jtb.com <mailto:ve7...@ve7jtb.com>>: >>>> >>>> I think Torsten is speculating that is not a >>>> feature people use. >>>> >>> I’m still trying to understand the use case for >>>> merging signed and unsigned parameters. Nat once >>>> explained a use case, where a client uses parameters >>>> signed by a 3rd party (some „certification authority“) >>>> in combination with transaction-specific parameters. Is >>>> this being done in the wild? >>>> >>> >>>> >>> PS: PAR would work with both modes. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https:// >>>> >>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cc470d4ec4bd14d481c0f08d7961a8abb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142913068803145&sdata=kobH%2FsGT7ElSSUCJvu%2FbiAqnRCXx%2B4SZNJsrL%2FCuVyc%3D&reserved=0> >>>> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
