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

Nat Sakimura sakimura at gmail.com
Mon Dec 10 19:41:12 UTC 2018

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


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

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

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

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

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
   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20181211/b5064b24/attachment.html>

More information about the Openid-specs-ab mailing list