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