SIOP Properties

A.K.A. We should stop using "SIOP" as an umbrella term

Note: This is meant to be for collaboration on the list of properties referenced in this OpenID issue. If you do not think there is concensus around a change, feel free to use the comment feature in HackMD (by selecting text in the rendered view) to start discussing the topic. Also, please describe changes made to this document while it is being collaborated on to the bulleted list at the bottom.
Revisions to this document are tracked and are visible by going to the ellipsis menu (…) on the top right and selecting "Versions and Github Sync"

There have been repeated misunderstandings when “SIOP” is used to describe an umbrella feature-set, especially when we are discussing creating subsets and extensions of these features to solve specific problems.

This is an attempt to document all the existing properties that people may associate with SIOP today, for the purpose of identifying desirable properties and attempting to break them out as first-class behavioral concepts.

The goal would be to eventually have specific feature names in discussions, and that “SIOP” is used exclusively as the name of the existing https://self-issued.me issuer.

Provider as Collective Set/Group/Sytem -> implementation guide

SIOP was originally designed as a way to represent that the OP was not in the traditional model where it is operated under a single administrative control, and instead was a more distributed network of individual, self-owned OpenID Providers which might be considered instances or members. Such a collective is distinguished by the issuer URI, e.g. https://self-issued.me

Today, the use of the self-issued.me issuer is expected to operate as a policy switch for RPs. The expectation is that "collectives" would not operate as a technical distinction for relying parties in the future, but rather would request various features from relying parties which would be interpreted for appropriate policy. In that sense, collectives may become a template or set of practices/recommendations around concrete features. Those concrete features would be what would be represented in a collective's metadata, and would be acted upon by relying parties.

• OIX guide to trust frameworks

Common Collective Capabilities -> implementation guide

While limited, it is expected that different members of a collective (including SIOP redefined as a collective) would operate under the same rules and would thus be interchangeable - even when the implementation of member OP instances is a different deployment or even by a different vendor.

Hard-coded policy switch -> non-normative reference in the spec text

In the absense of the ability to declare these properties for arbitrary collectives, the self-issued.me issuer acts as a signal to relying parties as a hard-coded behavioral switch. If other collectives can exist, it is expected that relying parties need other ways to understand appropriate behavior.

Examples of this include:

• Discovery is discouraged, metadata should be hard-coded
• Implicitly understood client registration[link]
• Registration request parameter[link]
• Custom encrypted request/id_token_hint rules[link]
• sub_jwk claim as id_token signing key[link]
• sub claim must be sub_jwk thumbprint

Cryptographically-proven Subject Authority -> non-normative reference in the spec text

A traditional OP can assert authentication for any subject identifier underneath its administrative domain (e.g., scoped to its issuer or entity id). Collectives need to operate under a different model where there is additional cryptographic evidence of the subject identifier.

No Authoritatively-stated Subject Userinfo -> non-normative guidance for OIDC4VP/Claims aggregation/ekyc-ida

An OP operating within a contractual relationship or trust framework may imply a level of trust in asserted user claims (e.g. acceptance of the email_verified claim value of true). The existing self-issued.me collective members do not have either of these frameworks to rely upon, making claims self-asserted.

A mechanism such as distributed/aggregated claims or verifiable presentations would be needed to retrieve and present authoritative statements about the subject. These also would need to have an appropriate confirmation system to know that they were issued to the SIOP instance.

Just as there are motivations today to share credentials with others to give them access in traditional environments, the availability of claims/credentials that may be used to make authorization/access decisions could be abused. There may be a need in the security model of such mechanisms to retrieve and present such information to distinguish between the subject of the claims and the holder who is able to prove possession of those claims.
-> difference in confirmation model - does not have to be bound to OP, but cryptographic material that proves user possession or nonce.
-> Authority to make a statement about a subject -> signature on the claims

Subject-signed tokens

Given that the subject identity and not the issuer instance identity is important and cryptographically verifiable, id_tokens are signed using the subject identity. The additional property sub_jwk is used to convey the full key in a structured manner, so that sub can remain StringOrURI as required by JWT.

The sub field in this case is required to be the computed thumbprint of the JWK.

Although not spelled out in text, the subject cryptographic identity is expected to be pairwise and thus distinct across individual relying parties.

There have been discussions on using other forms of cryptographic subject confirmations (such as DID-backed proofs). It is expected such proposals will define how they affect the signature on the id_token

No SIOP instance identity

As a fall-out of the previous point, the SIOP instance only has an identity indirectly by way of representing a particular subject identifier. There is no way to distinguish that two different subject identifiers came from the same native application instance (nor is there particular value for doing so).

Reduced back-channel accessibility

As software instances within the collective are not necessarily distinguished individually and may not be network-resolvable, hosted resources are meant to represent the entire collective.

For instance, self-issued.me has experimental support for:

• OpenId Connect Metadata
• Basic Dynamic Client Registration

However, individual instances do not have their own hosted endpoints, such as the token endpoint to exchange a code for an id_token. Protocol exchanges between a relying party and an instance are typically only possible and are thus defined by a user agent which can address both the relying party and the OP instance.

Limited OpenID Connect capabilities –> Limited to Implicit grant

As a result of there being no direct communication with an instance and a different model of authority within the collective, SIOP is limited to providing an id_token via the implicit protocol. Code grants and negotiation of access/refresh tokens are prohibited.

Just-in-time Client Registration

The expectation is that the information necessary for interaction with a relying party is included on the request.

Dynamic endpoints which codify behavior of the collective are possible as well, such as a registration endpoint for relying parties which encodes relevant information into the client identifier, secret, and/or assertion.

To support negotiation of additional features by the relying party in the absense of DCR, SIOP allows for a 'registration' request property. As this could conflict with any authoritative relying party metadata (via relationship or DCR), this property is exclusive to SIOP.

See also: working document for Proposed Adaptations

Alternative JWE rules

The self-issued providers, due to a combination of use of subject-signed tokens and lack of per-member hosted metadata, can leverage the JWK of the subject in order to encrypt entire requests or just the id_token_hints.

Changes

• Adopted document to format of issue
• Added note to set groundrules for editing and inform people unfamiliar to HackMD where to find features
• Reorder "Common Capabilities" and change text to make it clearer that it is capabilities common to the collective.
• Enumerate some of the existing policy switches on self-issued.me issuers. Hyperlink to relevant points in this document
• Create "Alternative JWE rules" topic
• Add DID callout to "Subject-signed tokens"
• From issue: add clarification that a "collective" is a conceptual concept without direct relying party policy impact - e.g. more of a pattern on how to achieve a certain setup using concrete features.
• Clarified "Reduced back-channel interactions" to basically say - a collective would typically be network accessible, but individual instances are not. Gave examples of network accessible SIOP features.
• Change "Non-authoritative subject identifier" to "Cryptographically-proven Subject Authority" - not great, but perhaps less misleading?

---

I tried sorting the properties (Kristina)