Use OpenID Federations for RP metadata/auto-registration

Issue #1241 resolved
David Waite created an issue

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:

  1. The client identifier MUST be the redirect URI
  2. 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)

  1. Giuseppe De Marco

    I agree completely, OIDC Federation is the right way to prevent phishing attacks, it definitively build a solid way to establish trust between parties, dinamically.

    I won’t believe that a smartphone could load the metadatas of an entire (even multiple) federation

  2. Kristina Yasuda

    Suggest we close this issue as using OpenID Federation has been introduced in a merged PR #53.

    Note that options other than OpenID Federation also remain open

    • when request is not sighed, redirect_uri=client_id
    • when request is signed,

      • client_id can be a DID and DID resolution is used and
      • client_id can be an HTTP URL and OpenID Federation Entity Statements in Automatic Registration is used

  3. Log in to comment