Move client registration to a separate document

[Razumain]

This issue has been discussed in different contexts and it was also discussed in Stockholm.

My position on this is that the OpenID federation sections on client registration is very valuable, but it is problematic for several reasons that this is placed in the core document. Main reasons are:

1. The federation document should focus on distribution of authentic data about services and should not impose any requirements on the underlying service protocol where that federated data is used (E.g. OpenID Connect, OAuth, OpenID4VCI, OpenID4VP, etc).
2. When moving existing infrastructure into using OpenID federation, it creates a very high bar for entry if the federation core document place requirements on the service protocol that use the federation.
3. When external bodies points to a standard, they often just include the name of the standard. This makes it very hard to require support for the core OpenID federation implementation but not a particular way to implement the service protocol.
4. Even if client registration is listed as not being mandatory, we can expect to see unintentional requirements to implement it as it is part of the core document.

We have already seen examples of 3 and 4 in the creation of OpenID4VP that bound its opened-federation prefix also to a requirement to support its specification of client registration. I fear this will happen over and over again as people will assume that you have to support all parts of the document.

I think it would be totally worth the effort, and make OpenID federation more future proof if the core document stayed free of requirements on specific service protocols. Each such protocol should writhe their own profile, offering a separate document that could be referred to in other places when relevant. This also makes it easier to let the separate documents to evolve independently from the core specification as well as allowing profiling for different environments.

[selfissued]

As discussed during the interop in Stockholm, this could be done as a non-breaking change after 1.0 is final. The result would be a 1.1 spec that is compatible with 1.0, but with a companion spec saying how Federation can be used with OpenID Connect, which again, would be compatible with 1.0 by design.

This may seem simple on the surface, but every definition and sentence in the spec has to be evaluated as to which spec it goes into in a careful and thoughtful way. We will be under less time pressure and more likely to get it right if we do this after 1.0 is final.

One point that already comes to mind that muddies the waters as to which spec(s) content would go into, if divided, is the content about the OAuth entity types. That's not OpenID Connect, but it's not core Federation functionality either. Should it go into the Connect profile or a third spec? That's one example of how dividing the current spec into two is not as straightforward as might be assumed.