Defining SIOP and the scope of its specification

[Stephane Durand]

The question SIOP definition has recently surfaced through different issues (1399, 1397, 1400) 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 )

[David Waite]

Because a SIOP is an OP from a protocol flow, the difference is in the trust model and trust evaluation from the RP.

For an OP, you make a trust decision on whether the OP is making statements about particular end users which you can rely upon.

For a SIOP, you make a trust decision on whether an end-user is making trustworthy statements about themselves through a user agent they control.

This reversal in SIOP means that your statements often need additional proof of validity, hence OIDC4VP proceeding in parallel.

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

The personal/self-hosted aspects are not security or conformance properties of the system - there’s nothing preventing a large social network from providing SIOP-style authentication via individual end-user-representing, OP-held keys.

So far, there hasn’t been a big motivation for a potential OP to be a SIOP. Being an OP imparts additional capabilities, and having a relationship with an OP is a good basis for making trust decisions on claims.

[Kristina Yasuda]

summarizes and proposes concrete changes to Issue #1399.

[Kristina Yasuda]

How about the below definition?

This specification extends OpenID Connect with the concept of a Self-Issued OpenID Provider (Self-Issued OP), an OP that issue self-signed ID Tokens.

Per your comment on fixing the errata language, my understanding is we agreed that SIOP v2 may introduce breaking changes to SIOP v1 text in errata, so us changing definition in SIOPv2 should be enough, but need to confirm.

Per DW’s comment, we have not heard of concrete use-cases of using “not-self-hosted” OPs as SIOPs. Though I agree it should be possible.

[Kristina Yasuda]

2022-Feb-03 SIOP call, we agreed to come back to this issue after reaching consensus on other related issues. Mainly PR #116.

[Michael Jones]

Discussed during the 3-Feb-22 SIOP Special Topic call.

[Kristina Yasuda]

noting before I forget what was brought to my attention

“ability to self-signed ID Token = using the key used to self-sign as a user identifier.“

[Kristina Yasuda]

@Stephane Durand Would you consider this issue to be resolved with PR #144?

[Stephane Durand]

Sorry, I haven’t been able to follow the work for a while (not that I doesn’t interest me anymore, but agenda and priorities…)

• PR 144 address the main point of the issue (remove the ‘local’ restriction).

• Then, I was bringing forth two other points, but as I am not up-to-date with the recent version of the specification, I can’t tell where we stand there:

  • Recommendation for a clarification on the fact that SIOP may support other flows than implicit (a restriction that was in connect) has been addressed.
  • Suggestion to assist implementers by highlighting that there was two main flavors of SIOP (with hosted, resolvable, endpoints vs not) that may on some aspect follow different behaviors (and requirements?).

I am not confident to revert shortly on the two later, so feel free to decide whether they (still) need to be considered, or the issue can be closed.

[Kristina Yasuda]

• Recommendation for a clarification on the fact that SIOP may support other flows than implicit (a restriction that was in connect) has been addressed.
• Suggestion to assist implementers by highlighting that there was two main flavors of SIOP (with hosted, resolvable, endpoints vs not) that may on some aspect follow different behaviors (and requirements?).

Both of the points have been addressed. OpenID4VP is now based on OAuth instead of OIDC. and SIOPv2 explicitly says it "allows use of any OpenID Connect flow for Self-Issued OPs"