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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
