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

[Filip Skokan <[e-mail]>]

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
> 
> 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