Remove client_id restrictions and registration request parameters from SIOPv2

[David Waite]

Assuming SIOP v1 and v2 are distinct protocols, we should consider removing the adhoc registration scheme rather than inheriting to SIOP v2.

1. The reason to allow for non-authoritative registration metadata was due to there not being a scheme to resolve client metadata in OpenID originally. With OpenID Connect Federation, we now have a defined system of automatic registration via client metadata resolution
2. Having a single format for registration (via automatic client registration as defined in OpenID Connect Federation) will simplify SIOP implementations.
3. There are distinct issues with the registration query parameter, such as the ability to maliciously capture id_tokens if the registration metadata is trusted to provide certain values, such as alternative redirect_uri.

This proposal would be to:

1. Remove registration and registration_uri as acceptable parameters for SIOP v2, making them exclusive to SIOP v1.
2. client_id should be used to resolve OpenID Federation entity metadata, rather than being required to be a redirect_uri. Discussion on how this might be done for non-HTTPS scheme URI (such as DIDs) at Issue #1289.

‌

[Stephane Durand]

As it stands, I am not sure automatic client registration is compatible with SIOP: the required aud claim of the request object must be set to “the URL of the Authorization Server's Authorization Endpoint”. How is it handled for a SIOP in a wallet app?

What is the rational with this requirement on aud and can it be lifted in the case of SIOP?

[David Waite]

With SIOP, the communication pattern is via the implicit flow - so it would be a custom URI scheme like “openid://” or a HTTPS URI like “https://vertical-federation.example.com/siop/authz”. In the first case, the scheme would be registered by The app with the platform, in the second case there may also be a platform-specific hosted file on the origin whitelisting SIOP apps by team, app bundle or certificate thumbprint.

Grant types which do not use authorization endpoint would need a different audience, but we don’t have those defined in OpenID Connect. They would need to be defined for OpenID Connect Federation to say become generalized to OAuth, if that becomes a future goal.

Possibly the larger issue is that JWTs are multi-purpose (id_tokens, access tokens, logout messages, security events, protocol requests, entity statements, origin session cookies, DPoP proofs, etc) but unfortunately neither the typ or cty protected header values are defined by JWT as appropriate for distinguishing usage, and we never got a JWT claim for doing such.

The aud being the authorization endpoint rather than the issuer may be a case where the messages are specifically being defined to conflict with other known usage.

[David Waite]

See also: #1289, #1263, #1267, #1259, #1198, #1241, #1217

[Torsten Lodderstedt]

I think using the redirect_uri as client_id and passing registration data by value is a pragmatic and simple solution that should be kept.

Adding support for resolvable identifiers is fine, it makes the protocol more powerful but I would not assume it makes implementations easier.

re redirect_uri: this metadata parameter shall just be prohibited in SIOP context (see https://bitbucket.org/openid/connect/issues/1259/redirect_uri-claims_supported)

[David Waite]

My concern about passing a registration parameter by value is that it is entirely non-authoritative. OpenID Connect and OAuth both assume authoritative metadata exchange for registration.

Likewise, we cannot assume origins are an appropriate security boundary without taking into account that the redirect_uri may be an endpoint suffering from script injection or other compromise. This makes informing the user for consent much harder, and makes migrating to different infrastructure more complex (as you may need to preserve the existing redirect_uri to prevent user warnings or new consent prompts/differing pseudonyms)

Finally, the registration and request together (with PEX) may push up against platform URI length limits - in which case they may need to host metadata for space-savings anyway.

Brainstorming - if the registration parameter was signed by say a TLS certificate root we might be able to consider a registration parameter as a JWT, even without client_id = redirect_uri.

I’d recommend against a registration_uri parameter (e.g. hosted non-authoritative metadata) in either case.

[Kristina Yasuda]

Registration metadata included in the signed request would be authoritative. Could mandating signing of the request be a simple solution?

For example, when DIDs are used, client_id=<RP DID>, domain controlling DID verified using .well-known file (https://identity.foundation/.well-known/resources/did-configuration/), and keys to verify the signed request are obtained from a DID Document.

‌

[David Waite]

Registration metadata included in the signed request would be authoritative

We would need some external mechanism other than registration to define authoritative signing keys for the client.

For instance, the client id could be embedded as subject in the signing certificate chained up to a mutually trusted root CA, with the certificate/chain included within the header of the signed request object.

[Torsten Lodderstedt]

I agree that registration_uri in an unsigned request is not a good idea.

re signed requests: I can envision SIOP deployments where the SIOP relies on central registries for RP entitlement and metadata/key sharing. That would give the signed request some authority.

I don’t see an issue with passing format related metadata in unsigned requests.

[David Waite]

Just a note that the client_id == redirect_uri restriction needs to be rethought both in the wake of resolvable client_id and in the wake of potentially multiple redirect_uris.

[Kristina Yasuda]

I think there is a demand to keep client_id == redirect_uri when request is not signed for the most simple deployments of SIOP.

as of PR #53, usage of redirect_uris is the registration parameters is banned entirely in SIOP.

[Kristina Yasuda]

resolving since we have reached agreement on both 1. to keep registration parameters and 2. using client_id to obtain entity statement.