Use OpenID Federations for RP metadata/auto-registration

As the SIOP system today does not have a way for a client to do advance registration with an individual software instance, it provides two custom rules which are not usable by any other type of OpenID Provider:

The client identifier MUST be the redirect URI
A registration JSON object MAY be sent with the request giving a loosely defined set of acceptable values

This creates challenges in reuse if we start to define generalized OpenID Provider Collectives, rather than having the SIOP behavior be triggered by a hard-coded issuer URI.

This also creates a new category of security risk which has to be evaluated, as there is also no way defined to verify the registration object is authoritative. An OP may evaluate a request based on forged client configuration, so the allowed set of registration parameters would need to be evaluated to understand if there is an impact on the legitimate relying party.

OpenID Federation has been defining a way to have entities acting as relying parties publish metadata, which was previously not defined. They have also defined a way to resolve this metadata based on client identifier (using .well-known.) Finally, they defined an auto-registration system where clients may specify sufficient resolvable metadata for an interaction to occur without any prior direct relationship or dynamic client registration endpoint usage.

We should evaluate this as a potential recommended alternative over DCR or the redirect_uri-based client identifiers used today by SIOP.

Comments (5)