What is a "Dynamic OpenID Provider," and can we avoid being one?

[callahad]

A bunch of things in the OpenID Connect Discovery have stricter requirements for "Dynamic OpenID Providers."

Like having to support the code and token id_token response types in addition to just id_token, or supporting both authorization_code and implicit flows, when we really just want to support the implicit flow.

We could intentionally break from the spec, but I'd like to see how far we can get while being compliant, first.

[callahad]

Here are all the relevant quotes from the OpenID Connect Core spec, all emphasis mine:

• "this specification assumes that the Relying Party has already obtained sufficient credentials and provided information needed to use the OpenID Provider. This is normally done via Dynamic Registration, as described in OpenID Connect Dynamic Client Registration 1.0, or may be obtained via other mechanisms."

• It is expected that some OpenID Providers will require static, out-of-band configuration of RPs using them, whereas others will support dynamic usage by RPs without a pre-established relationship between them. For that reason, the mandatory-to-implement features for OPs are listed below in two groups: the first for all OPs and the second for "Dynamic" OpenID Providers.

• OpenID Providers supporting dynamic establishment of relationships with RPs that they do not have a pre-configured relationship with MUST also implement the following features defined in this and related specifications.

• Some OpenID Connect installations can use a pre-configured set of OpenID Providers and/or Relying Parties. In those cases, it might not be necessary to support dynamic discovery of information about identities or services or dynamic registration of Clients.

  However, if installations choose to support unanticipated interactions between Relying Parties and OpenID Providers that do not have pre-configured relationships, they SHOULD accomplish this by implementing the facilities defined in the OpenID Connect Discovery 1.0 and OpenID Connect Dynamic Client Registration 1.0 specifications.

• when interacting with OpenID Providers that support Discovery, the OP's Discovery document can be used to dynamically determine which OP features are available for use by the RP.

[callahad]

My interpretation is that a "Dynamic OpenID Provider" is specifically one implements the Dynamic Client Registration spec.

Similarly, providers that interact with unknown third parties are encouraged but not required to do so via the Discovery and Registration specs.

Does that make sense? Can anyone find an explicit definition of "Dynamic OpenID Provider" in any of the Core, Discovery, or Dynamic Client Registration specs?

[callahad]

If we do have to go down this path, the Dynamic Client Registration spec mentions a way to do so without needing a stateful OpenID Provider:

One means of doing this is to encode necessary registration information about the Client into the client_id value returned by the initial registration of the Client. This has the effect of having the Client store this information, rather than the Authorization Server. The particular encodings used by different Authorization Servers will differ.

When stateless dynamic client registration is used by the Authorization Server, read operations are likely to not be possible, because issuing a Registration Access Token might require per-Client state at the Authorization Server. In that case, no Client Configuration Endpoint or Registration Access Token will be returned by the initial registration of the Client.

[callahad]

Ooh! I found a definition in the OpenID Connect Conformance Profiles document:

Dynamic OpenID Providers implement the Mandatory to Implement Features for Dynamic OpenID Providers described in Section 15.2 of OpenID Connect Core 1.0. Note that conforming to the Dynamic OpenID Provider profile also means that the implementation will conform to the Basic OpenID Provider, Implicit OpenID Provider, and OpenID Provider Publishing Configuration Information profiles and implement the OP features of the OpenID Connect Discovery 1.0 and OpenID Connect Dynamic Client Registration 1.0 specifications.

[callahad]

I think we want to start by aiming for compliance with two of the above profiles:

1. Implicit OpenID Provider

   Which just means supporting the id_token and id_token token response types.

2. OpenID Provider Publishing Configuration Information

   Which just means key rotation (punt for the prototype) and publishing provider metadata at /.well-known/openid-configuration. This is a subset of the full "Dynamic OpenID Provider" level.