Re: [OAUTH-WG] [EXTERNAL] Re: JWT Secured Authorization Request (JAR) vs OIDC request object

[John Bradley <[e-mail]>]

Right we just don't say to put the iss there in OIDC if it's symetricly
encrypted.

On Fri, Jan 10, 2020, 9:41 PM Mike Jones <[e-mail]>
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 <[e-mail]> *On Behalf Of * John Bradley
> *Sent:* Friday, January 10, 2020 2:15 PM
> *To:* Vladimir Dzhuvinov <[e-mail]>
> *Cc:* IETF oauth WG <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>:
> >>
> >> 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 <[e-mail]>:
> >>>> 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
> [e-mail]
> 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>
>
>