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://www.ietf.org/mailman/listinfo/oauth >> >> <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> >> > -- > Vladimir Dzhuvinov
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
