OpenID Provider as Collective

[David Waite]

It is desirable to have SIOP-style behavior outside of the hard-coded 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.

[Kristina Yasuda]

related to #1207.

[Michael Jones]

It confuses me why it matters, on a protocol basis, whether there might be multiple instances of SIOP OPs, given that the RP is only interacting with the one chosen by the end-user. Put another way, it’s irrelevant to RPs and the end-user’s SIOP that SIOPs can be philosophically be considered to be part of a collective. I don’t think that focusing on that will help us develop a useful and usable SIOP V2 protocol.

Also, I believe that it’s irrelevant what software is behind the SIOP and whether it’s from one vendor or multiple vendors, just like it’s irrelevant to the RP what software is being run at login.google.com, and whether it’s written in Java and/or C++.

Of course, I may be missing something, but I’d like to focus on concepts and distinctions and that will be actionable during our specification and implementation work.

[David Waite]

Put another way, it’s irrelevant to RPs and the end-user’s SIOP that SIOPs can be philosophically be considered to be part of a collective.

I agree, Mike!

The goal of defining a collective is to have a new term separate from self-issued.me and SIOP which have fixed criteria and a fixed baseline featureset, and to start actually defining the features (and requirements) necessary to act as a collective.

If hypothetically there was a metadata entry “collective”: true that relying parties switched on to change behavior, that means we have some behavioral facet that we could (and probably should) have defined more explicitly.

It is closer to a named pattern. As we decide required features and constraints, it might even have enough consistency to become an OP certification profile.

Or to put it another way, you could say SIOP today is a set of policy defining the behavior for self-issued.me to act as a collective, with a lot of it hard-coded (e.g. only accept registration request parameters if the issuer is self-issued.me). If I want to have a similar collective for a more specific use case (say mobile drivers licenses) then I have to also set policy to control that behavior. Any document describing a collective describes how to properly set up a new issuer to have that sort of behavior securely.

[Oliver Terbu]

@David: This seems to be related to the SIOP Discovery discussion. Since this issue is inactive for a while and I have the feeling we have already addressed that in the specification, are you fine with closing this issue?

[Kristina Yasuda]

Agreed to close on Sept-16-2021