[Openid-specs-ab] Issue #1417: Defining SIOP and the scope of its specification (openid/connect)

[Stephane Durand]

New issue 1417: Defining SIOP and the scope of its specification
https://bitbucket.org/openid/connect/issues/1417/defining-siop-and-the-scope-of-its

Stephane Durand:

The question SIOP definition has recently surfaced through different issues \([1399](https://bitbucket.org/openid/connect/issues/1399/siop-with-any-oidc-flow), [1397](https://bitbucket.org/openid/connect/issues/1397/please-describe-the-relationship-with-ciba), [1400](https://bitbucket.org/openid/connect/issues/1400/issuer-handling-in-siop)\) and seem important to agree on what the specification is supposed to address and how.

In the course of the work on SIOP, various topics have been tackled:

1. Integration with VC/VP \(and PE\)... this has since been spun off to OIDC4VP \(as a recognition that this is not a SIOP specific\)
2. The holder being the sovereign authority over their identity: how we build ID Token \(already in v1, extended to support DID\).
3. The inability for a SIOP to host an endpoint: restriction to implicit flow \(already in v1\), registration and discovery \(already in v1, extended\).

Core already proposes a definition for Self-Issued OpenID Providers, as

> personal, self-hosted OPs that issue self-signed ID Tokens

It is actually quite a good base and reflects the two of the topics that have been covered and that remained till last draft.

I didn't see that the part of about "issu\(ing\) self-signed ID Token" has been put to question.  
"Self-hosted" on the other hand has been widely interpreted as a limitation on the ability to host endpoints \(an implicit mapping to a mobile application\) and this interpretation is being challenged. Indeed, it should probably be merely read as "hosted under the control of the holder", which rather points at the nature of the signing materials available to the SIOP. \(For fairness, I think the interpretation was already around since v1, seeing that the flow was fixed to implicit\).

That being said, I still think that while SIOP specification should not restrict itself to cases where no endpoint can be hosted, it should definitely cover this case. Otherwise, I don't see any place else where it would be covered.

In the introduction of SIOP, I suggest we remove 'local' from "Self-Issued OpenID Provider \(Self-Issued OP\), an OpenID Provider \(OP\) which is within the End-User's local control" because it insists on the narrowed interpretation.

Then, should we:

* clarify in Connect the definition of a SIOP \(moving it from SIOP section introduction to the terminology section for better visibility, propose a wording with less room for interpretation or a clarification on how it should be read\) and refer is from SIOP, or
* Bring the clarification in SIOP, around the statement on scope?

In particular, we should explicitly amend the fact that v1 only considered the implicit flow.  
In term of document structure, it might be interesting to segregate SIOPs with endpoint hosting capabilities and without \(probably quite impactful :sweat:  \)