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. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
