[Federation] client_registration_types client metadata

[Takahiko Kawasaki]

OpenID Connect Federation 1.0 defines the client_registration_types client metadata. Its type is a JSON array which may contain automatic and/or explicit.

I’m afraid that the client metadata is useless. There is no need to reference the value of the client metadata after a client is registered. Even during the client registration process, there is no need for an authorization server to care about the client metadata.

Am I missing something? Otherwise, the client metadata should be removed from the specification.

[Giuseppe De Marco]

I agree that once a client has been registered the claim client_registration_types appears quite useless, and also that the registration method may be duck-driven, if automatic it behaves like automatic, if explicit like explicit.

However the prupose of this claim covers the requirements of human readability in interoperability, in the way to establish a readable schema to inform every participants about the client registration methods supported by this RP.

evenmore, in the future there will be the possibility to define a new client registration type, for this reason I believe that keeping this information as explicit is a general purpose of the metadata schema.

I believe that also the claims contacts or the tos_uri or the privacy_uri sounds as completely informatives, not involved in any of the OIDC endpoint operations

[Takahiko Kawasaki]

After consideration, I found a case where existence of the client_registration_types client metadata is worth it. It’s when the client metadata is used in metadata_policy / ( openid_relying_party | oauth_client ) in order to restrict the type of client registration in a federation to either automatic or explicit.

It makes little sense for an authorization server (a leaf entity in a federation) to keep the value of client_registration_types of registered clients in its “client” database.

However, on the other hand, it makes sense for intermediate entities and trust anchors (non-leaf entities in a federation) to manage the value of client_registration_types in their “metadata policy” databases.

In that sense, existence of the client_registration_types client metadata is worth it. This issue can be closed.

[Giuseppe De Marco]

Thank you Takahiko for the elements you’ve pointed out!

[Takahiko Kawasaki]

I now think I should change my previous conclusion. Authorization server implementations also should remember the value of the client_registration_types client metadata.

Suppose that a client was registered by the “explicit” registration and the client’s client_registration_types does not contain "automatic". In this case, the authorization server implementation should not automatically update the client when the client makes an authorization request after its trust chain has expired. At least for this purpose, the authorization server implementation needs to keep the value of the client_registration_types client metadata in its database even after the registration process of the client is done.