# 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](https://bitbucket.org/openid/connect/issues/1239/we-should-stop-using-siop-as-an-umbrella). 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](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedDiscovery)
* [Implicitly understood client registration](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRegistration)[[link](#auto-client-reg)]
* [Registration request parameter](https://openid.net/specs/openid-connect-core-1_0.html#RegistrationParameter)[[link](#auto-client-reg)]
* [Custom encrypted request/id_token_hint rules](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRequest)[[link](#jwe)]
* [`sub_jwk` claim as id_token signing key](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse)[[link](#sub_jwk)]
* [`sub` claim must be sub_jwk thumbprint](https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse)

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

<a id='sub_jwk'>Subject-signed tokens</a>
: 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](https://self-issued.me/.well-known/openid-configuration)
* [Basic Dynamic Client Registration](https://self-issued.me)

: 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.

<a id='auto-client-reg'>Just-in-time Client Registration</a>
: 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](https://hackmd.io/@dwaite/HydZ7fMKd)

<a id='jwe'>Alternative JWE rules</a>
: 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)