Note: Currently work is occurring at https://hackmd.io/@dwaite/Hyg0vTZFd
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 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 . See
Hard-coded policy switch
In the absense of the ability to declare these properties for arbitrary collectives, the self-issued.me issuer is expected by any existing supporting relying parties to be used as a hard-coded behavioral switch
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.
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.
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.
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. See: