Todo list for Self-Issued OP to achieve #self-sovereign-identity

Self-issued OP (SIOP) is defined in Chapter 7 of OpenID Connect (2014). If we take 

1. that the Identity (set of data related to the entity) needs to be provable as attested at the time of attestation and cannot be taken away;
2. to identify himself that he is the PII principal that the identity relates to;

as the requirements for Self Sovereign identity, SIOP can be used to implement SSID. 

In this model, there are four basic actors: 

1. Data Subject: that is “me”; 
2. Claims Providers (CPs) that provides attested claims; 
3. Relying Parties (RPs) that consumes the attested claims in order to provide services to the data subject; 
4. Self-issued OPs (SIOPs) that provide the authenticated identity to the 

Then, the Data subject can ask the CP to provide the attested claims in the form of signed JWT that resembles ID Token and includes it in the ID Token that he provides through the SIOP to the RP. 

Having said that, a bunch of things are going to be implementation specific and need standardization. The list of such features includes a standardized method for 

1. Registering the SIOP to the claims provider so that the SIOP can request signed claims to the claims provider; 
2. Binding the Self-issued identifier (a hash of the public key) and the attested claims; 
3. Attesting the signing key from the past;  
4. Providing the claims to the RP when the SIOP is offline; and 
5. Enabling key recovery. 
6. Finding the SIOP address.

1. Registering the SIOP to the claims provider

From the point of view of the claims provider, the SIOP will be an OAuth client. Assuming that the claims provider has an existing relationship with the data subject and has established a credential for the PII principal to authenticate against the Claims Provider, the SIOP has to start the regular OAuth dance to get authorization to obtain the claims at the Claims Provider. 

It is a regular OAuth Dance. The SIOP initially has to register itself to the Claims Provider using the dynamic client registration, then does the OAuth Dance with Code grant type and PKCE. When successful, it will obtain the access token and refresh token. The SIOP, acting as the client, can now obtain the attested claims from the Claims Provider, in the form of a signed JWT. 

Note that such attested claims MUST include the subject identifier of the data subject that was authenticated at the dance. Thus, the access token and the refresh token MUST be bound to the data subject and unique to the data subject. 

2. Binding the self-issued identifier to the attested claims

The data subject can establish any number of key-pairs at the SIOP to manage his identities. He picks one of them to communicate to the RP. Thus, there will be one-to-many relationship between the subject identifier at the Claims Provider and the Self-issued identifiers(SIID). Noting that the key-pairs can be created on the fly and even be ephemeral to achieve the anonymous attribute-based authentication, this binding has to be done dynamically. 

To achieve the goal,

1.  the SIOP as a client MUST send the SIID to be used against the RP in the claims request; 
2. the CP MUST include the SIID as the value of the siid claim; 

3. Attesting the signing key from the past

A claims provider may go out-of-business. However, that does not mean that the attestation made in the past is invalid. For example, I may have obtained a qualification from a training course that the institution provides, but the institution may disappear years later but I may still want to prove that I was provided with the qualification. 

To achieve this, the public-key corresponding to the private-key MUST be timestamped and made available publicly. One way to do this is to write to a publicly maintained registry, such as a blockchain. Whenever the key is rotated, the CP MUST write it to the registry. 

SIOP may also want to rotate the key for various reasons. If the data subject is interested in providing the attested claims that it obtained in the past, then he has to write the old and new SIIDs as the pair to the registry, signed by the key corresponding to the old SIID. This exact format also needs to be standardized. 

There is yet another potential reason for writing one’s identifier into a shared timestamped registry service such as a blockchain. This is when one wants to establish a so-called “longitudinal trust”. You often see claims by merchants such as “Established 1837”. This is trying to garner the customer trust by claiming that the business has been in business for a long time. This tells us that “length of time as the market participant” is an important input to the trust formation. The same applies to the Self-issued identities. If the SIID has been in use for a long time, it may earn some credit on it. Needless to say, however, it needs to be verifiable. One way to do so is to write the SIID into such a registry so that everyone can verify that it existed at least from that time. 

4. Providing the claims to the RP when the data subject is offline

It is often the case that the data subject does not want to reveal where the claims are going to be presented. Thus, making it not possible for the CP to reasonably link the transaction to the RP where RP and CP are not colluding is desirable. 

When providing access to the fresh claims while the SIOP is offline, this property is not fulfilled any more. Thus, this feature should be evaluated carefully before providing, but it can be done using the distributed claims model. 

In this case, the SIOP MUST provide the link to the endpoint that the CP provides together with the token that encodes the fact that the data subject has authorized the access. 

It is a more complicated flow. The RP now acts as a client to the CP but at the time of the attribute request, it cannot know which CP it will be getting the data from. It will find it only when it receives the ID Token from the SIOP, in which the pair of the URL of the CP and the token that encodes the fact that the user has authorized the access is provided. 

A Globally unique client identifier, such as URL, is useful here. If it is adopted in the ecosystem, then the SIOP can specify it as the RP’s client_id and send it in the request. then, the CP creates an access token and binds it to the client_id provided.  The RP then uses it against the URL of the CP that was provided in the ID Token to obtain the desired claims. 

If the access token is a bearer token, this means that the SIOP (i.e., the data subject) can also obtain the same claims and it is good from the transparency purposes. However, there are times where the access of the data subject is undesirable. In this case, the access token needs to be sender constrained to the RP by such mechanism like MTLS. Using a URL as the client_id is handy here as well. 

5. Enabling key recovery

Individuals are notorious in managing his keys. There has to be layers of protection against it. Some of them are: 

1. Transform the JWKS of the SIOP by All-or-nothing-transform and split it into two, where one part is printed out as a QR code and the rest is stored in the cloud. The data subject can safely store the QR code off-line. 
2. Instead of storing the QR code off-line at his home, he can send it to the safe-keeping service. 
3. Identity proofing service: It is not a key-recovery service, but to assist the data subject to re-establish himself after having lost the keys, there can be a third party service that binds the data subject to the list of identifiers. When the user has lost all the keys that were bound together, then the service can declare that the newly generated keys are the successor of the previous identifiers after going through the identity re-proofing process, such as examining the identity documents, etc. 

6. Finding the SIOP address

Self-issued OP is called from the RP by OpenID:// scheme. That works but any app can claim that it owns the scheme. Sometimes, it may be desirable to be able to signal the RP that which “claimed uri” the SIOP uses. This is akin to DID discovery.