[Openid-specs-ab] Issue #1240: OpenID Provider as Collective (openid/connect)

david_waite issues-reply at bitbucket.org
Thu May 27 07:26:44 UTC 2021


New issue 1240: OpenID Provider as Collective
https://bitbucket.org/openid/connect/issues/1240/openid-provider-as-collective

David Waite:

It is desirable to have SIOP-style behavior outside of the hard-coded [https://self-issued.me](https://self-issued.me) behavior:

1. to allow for newer integration and discovery options, e.g. universal links over custom URI schemes
2. to define a larger set of minimal capabilities and behavior
3. 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.

1. an issuer identifier which represents or is resolvable to metadata, which

    1. indicates that it is a collective
    2. indicates common methods of invocation \(most likely - a common authorization endpoint\)
    3. indicates a base set of features
    4. 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.



More information about the Openid-specs-ab mailing list