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

[John Bradley <[e-mail]>]

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