<div dir="ltr"><div dir="ltr"><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">(The most recent version of the following article is available at <a href="https://nat.sakimura.org/2018/12/11/todo-list-for-self-issued-op/">https://nat.sakimura.org/2018/12/11/todo-list-for-self-issued-op/</a>) </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">Enjoy, </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">Nat Sakimura</p><h1 class="gmail-title gmail-single-title" style="box-sizing:inherit;font-size:32px;margin:0px;color:rgb(42,42,42);text-transform:uppercase;line-height:1.1;clear:both;padding:0px;font-family:"Droid Sans",sans-serif">TODO LIST FOR SELF-ISSUED OP</h1><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">Self-issued OP (SIOP) is defined in Chapter 7 of OpenID Connect (2014). If we take </p><ol style="box-sizing:inherit;margin:1.5em 0px 1.571em 1.9em;list-style-position:initial;padding:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif;font-size:14px"><li style="box-sizing:inherit">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;</li><li style="box-sizing:inherit">to identify himself that he is the PII principal that the identity relates to;</li></ol><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">as the requirements for Self Sovereign identity, SIOP can be used to implement SSID. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">In this model, there are four basic actors: </p><ol style="box-sizing:inherit;margin:1.5em 0px 1.571em 1.9em;list-style-position:initial;padding:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif;font-size:14px"><li style="box-sizing:inherit">Data S<span class="gmail-gr_ gmail-gr_13 gmail-gr-alert gmail-gr_spell gmail-gr_inline_cards gmail-gr_run_anim gmail-ContextualSpelling gmail-ins-del gmail-multiReplace" id="gmail-13" style="box-sizing:inherit">ubject</span>: that is “me”; </li><li style="box-sizing:inherit">Claims Providers (CPs) that provides attested claims; </li><li style="box-sizing:inherit">Relying Parties (RPs) that consumes the attested claims in order to provide services to the data subject; </li><li style="box-sizing:inherit">Self-issued OPs (SIOPs) that provide the authenticated identity to the </li></ol><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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 </p><ol style="box-sizing:inherit;margin:1.5em 0px 1.571em 1.9em;list-style-position:initial;padding:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif;font-size:14px"><li style="box-sizing:inherit">Registering the SIOP to the claims provider so that the SIOP can request signed claims to the claims provider; </li><li style="box-sizing:inherit">Binding the Self-issued identifier (a hash of the public key) and the attested claims; </li><li style="box-sizing:inherit">Attesting the signing key from the past;  </li><li style="box-sizing:inherit">Providing the claims to the RP when the SIOP is offline; and </li><li style="box-sizing:inherit">Enabling key recovery. </li></ol><h3 style="box-sizing:inherit;margin:0px 0px 12px;color:rgb(42,42,42);text-transform:uppercase;font-size:22px;line-height:1.4;font-family:"Droid Sans",sans-serif">1. REGISTERING THE SIOP TO THE CLAIMS PROVIDER</h3><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><h3 style="box-sizing:inherit;margin:0px 0px 12px;color:rgb(42,42,42);text-transform:uppercase;font-size:22px;line-height:1.4;font-family:"Droid Sans",sans-serif">2. BINDING THE SELF-ISSUED IDENTIFIER TO THE ATTESTED CLAIMS</h3><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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 <span class="gmail-gr_ gmail-gr_7 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_run_anim gmail-Grammar gmail-only-ins gmail-replaceWithoutSep" id="gmail-7" style="box-sizing:inherit">one-to-many</span> 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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">To achieve the goal,</p><ol style="box-sizing:inherit;margin:1.5em 0px 1.571em 1.9em;list-style-position:initial;padding:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif;font-size:14px"><li style="box-sizing:inherit"> the SIOP as a client MUST send the SIID to be used against the RP in the claims request; </li><li style="box-sizing:inherit">the CP MUST include the SIID as the value of the <code style="box-sizing:inherit;font-family:monospace,monospace;font-size:1em;padding:0px 8px;line-height:1.5">siid</code> claim; </li></ol><h3 style="box-sizing:inherit;margin:0px 0px 12px;color:rgb(42,42,42);text-transform:uppercase;font-size:22px;line-height:1.4;font-family:"Droid Sans",sans-serif">3. ATTESTING THE SIGNING KEY FROM THE PAST</h3><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><h3 style="box-sizing:inherit;margin:0px 0px 12px;color:rgb(42,42,42);text-transform:uppercase;font-size:22px;line-height:1.4;font-family:"Droid Sans",sans-serif">4. PROVIDING THE CLAIMS TO THE RP WHEN THE DATA SUBJECT IS OFFLINE</h3><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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 <code style="box-sizing:inherit;font-family:monospace,monospace;font-size:1em;padding:0px 8px;line-height:1.5">client_id</code> and send it in the request. then, the CP creates an access token and binds it to the <code style="box-sizing:inherit;font-family:monospace,monospace;font-size:1em;padding:0px 8px;line-height:1.5">client_id</code> provided.  The RP then uses it against the URL of the CP that was provided in the ID Token to obtain the desired claims. </p><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">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 <code style="box-sizing:inherit;font-family:monospace,monospace;font-size:1em;padding:0px 8px;line-height:1.5">client_id</code> is handy here as well. </p><h2 style="box-sizing:inherit;margin:0px 0px 12px;color:rgb(42,42,42);text-transform:uppercase;font-size:24px;line-height:1.4;font-family:"Droid Sans",sans-serif">5. ENABLING KEY RECOVERY</h2><p style="box-sizing:inherit;margin-bottom:12px;font-size:14px;margin-top:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif">Individuals are notorious in managing his keys. There has to be layers of protection against it. Some of them are: </p><ol style="box-sizing:inherit;margin:1.5em 0px 1.571em 1.9em;list-style-position:initial;padding:0px;color:rgb(85,85,85);font-family:"Droid Sans",sans-serif;font-size:14px"><li style="box-sizing:inherit">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. </li><li style="box-sizing:inherit">Instead of storing the QR code off-line at his home, he can send it to the safe-keeping service. </li><li style="box-sizing:inherit">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. </li></ol><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div></div></div></div>