Manual entity registration with OpenID Federation 1.0

The OpenID Connect profiles in the Federation spec are simply two methods to register relying parties (RP) with an OpenID provider, utilising the available trust infrastructure:

• A profile for automatic registration, which takes a request object (JAR) or an authenticated pushed authorisation request (PAR) to establish a trust chain to a federation trust anchor. This enables the RP to get registered on the spot, as part of the authorisation request.

• A profile for explicit registration, which is similar to dynamic client registration (DCR), but uses a trust chain to authorise the registration request.

These profiles don’t preclude the possibility of “manual” registration. In fact, this can be a part of a plan to gradually introduce OpenID Federation 1.0 in a ecosystem, with zero pressure and little initial change. The Swedish federation project for national trust infrastructure chose precisely this approach.

• It relies on the trust anchors to operate resolvers, to return resolved metadata for OpenID providers and OpenID RPs in the federation.

• The metadata can be downloaded, manually or by a script, and used to create or update the registration for an RP at an OpenID provider. Behind the scences the registration can be done by the operator or the script making a standard DCR request.

  The only caveat is that the client_id must be set to the federation entity ID of RP, e.g. to https://rp.example.com, rather than let the OpenID provider assign a random value. The Connect2id server allows this with the preferred_client_id parameter.

• From that point on the registered RP can authenticate users and obtain ID tokens, just like with any other OpenID provider.

Yes, this may be a crude way to use the capabilities of an OpenID federation, like using a coal-powered steam engine in the age of electricity. But nevertheless, it can be a good way to start and make gradual difference.