It is desirable to have SIOP-style behavior outside of the hard-coded https://self-issued.me behavior:
- to allow for newer integration and discovery options, e.g. universal links over custom URI schemes
- to define a larger set of minimal capabilities and behavior
- to potentially operate underneath a trust framework which does auditing and certification of the various roles
To that end, I propose a new concept of an Issuer or OpenID Provider collective (bikeshedding to be done later)
A collective is an OpenID provider made of several independent software instances, possibly by different vendors.
an issuer identifier which represents or is resolvable to metadata, which
- indicates that it is a collective
- indicates common methods of invocation (most likely - a common authorization endpoint)
- indicates a base set of features
- indicates requirements to participate.
There would be an expected set of required features and limitations - due to a different model of authority over the subject, limitations on information sharing, and limitations on reachability of a particular software instance.
Expressing this under the model of trust frameworks, it is expected that there would be ‘open’ collectives where you self-certify to join and there is no authoritative list of participants, and ‘closed’ collectives where there is a governance process and a limited list. The expectation would be that both of these are supported, analogous to the options we have for configuring Dynamic Client Registration or OP discovery today.