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
