Remove client_id restrictions and registration request parameters from SIOPv2

Issue #1290 open
David Waite created an issue

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.

Comments (12)

  1. 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?

  2. David Waite reporter

    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 “”. 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.

  3. David Waite reporter

    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.

  4. David Waite reporter

    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.

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

  6. David Waite reporter

    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.

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

  8. Log in to comment