[Openid-specs-ab] TODO list for Self-Issued OP

Anthony Nadalin tonynad at microsoft.com
Thu Dec 13 17:24:57 UTC 2018

Sorry I was not clear, what I was actually talking about was the issuer, as today it’s a URL and uses Web Finger, we need to look at expanding this to allow for other types of discovery

From: Nat Sakimura <sakimura at gmail.com>
Sent: Wednesday, December 12, 2018 5:05 PM
To: Anthony Nadalin <tonynad at microsoft.com>
Cc: openid-specs-ab at lists.openid.net Ab <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] TODO list for Self-Issued OP

Hi Tony,

Actually, SIOP's identifier is not URL but the hash of the public key. That's one of the most common misconceptions about SIOP.

Having said that, what you have pointed out is true and I am aware of it.
In the list, it corresponds to  2 as an identifier is a claim, and 3 to some extent as you may want to establish the binding between that identifier and the time.


On Thu, Dec 13, 2018 at 4:14 AM Anthony Nadalin <tonynad at microsoft.com<mailto:tonynad at microsoft.com>> wrote:
So, there may be some ubiquity in the “identifier”, as the current SIOP is a URL, but there are many cases where there are actually other identifiers that need to be attested to, and the public-key that the identifier may have, I don’t expect that the SIOP identifier would be used much other than to find the SIOP and related meta-data. I do believe that we should be looking at how we do binding to all the other identifiers

From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net<mailto:openid-specs-ab-bounces at lists.openid.net>> On Behalf Of Nat Sakimura via Openid-specs-ab
Sent: Monday, December 10, 2018 11:41 AM
To: openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net> Ab <openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net>>
Cc: Nat Sakimura <sakimura at gmail.com<mailto:sakimura at gmail.com>>
Subject: [Openid-specs-ab] TODO list for Self-Issued OP

So, there is a renewed interest to Self-issued OP (SIOP) due to the Self-sovereign movement. I believe SIOP can be used to achieve Self-sovereign identity, but there are loose ends. Here is the list of TODOs that I came up with.

(The most recent version of the following article is available at https://nat.sakimura.org/2018/12/11/todo-list-for-self-issued-op/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnat.sakimura.org%2F2018%2F12%2F11%2Ftodo-list-for-self-issued-op%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C7c3686d30b254f6e369808d66097107b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636802599274649026&sdata=iOXeiJFgOQIOuRxpXSnK84VmntjaeRWegGCYVIPS%2FYE%3D&reserved=0>)


Nat Sakimura


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.

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.


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;

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.


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.


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.

Nat Sakimura (=nat)
Chairman, OpenID Foundation

Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181213/ee9d27a8/attachment-0001.html>

More information about the Openid-specs-ab mailing list