[Openid-specs-ab] Issue #1239: We should stop using "SIOP" as an umbrella term and instead talk about individual features. (openid/connect)

david_waite issues-reply at bitbucket.org
Thu May 27 07:03:48 UTC 2021

New issue 1239: We should stop using "SIOP" as an umbrella term and instead talk about individual features.

David Waite:

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 a first attempt to document all the 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](https://self-issued.me) issuer.


**Provider as Collective**  
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 OPs. Such a collective is distinguished by the issuer URI, e.g. [https://self-issued.me](https://self-issued.me)

**Hard-coded policy switch**  
In the absense of the ability to declare these properties for arbitrary collectives, the [self-issued.me](http://self-issued.me) issuer is expected by any existing supporting relying parties to be used as a hard-coded behavioral switch

**Common Capabilities**  
While limited, it is expected that different SIOP instances would attempt to operate under the same rules and would thus be interchangeable - even when the implementation of an OP was by a different vendor

**Non-authoritatively-stated Subject Identifiers**  
A normal OP has subject identifiers which can be considered scoped underneath a single administrative domain. SIOP needed a different model where it provided cryptographic evidence of the subject identifier

**Non-authoritatively-stated Subject Userinfo**  
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 holder/SIOP instance.

**Subject-signed tokens**  
Given that the subject identity and not the issuer instance identity is important and cryptographically verifiable, 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.  
_NOTE: the_ `sub` _field is a computed thumprint of the JWK, based on a purposefully limited JWK canonicalization algorithm specific to SIOP._  
_Although not spelled out in text, the subject cryptographic identity is expected to be pairwise and thus distinct across individual relying parties._

**Non-identified SIOP instance**  
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, dynamic protocol elements typically are sent via a redirect-based channel for the holder, who has accessibility to all other parties involved. Information such as metadata can be resolvable via the collective's identifier, which is expected to also be the issuer identifier within the protocol.

**Implicit-only interactions**  
As a result of there being no back-channel and no authoritative source, 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.

More information about the Openid-specs-ab mailing list