<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
h1
        {mso-style-priority:9;
        mso-style-link:"Heading 1 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:24.0pt;
        font-family:"Calibri",sans-serif;
        font-weight:bold;}
h2
        {mso-style-priority:9;
        mso-style-link:"Heading 2 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:18.0pt;
        font-family:"Calibri",sans-serif;
        font-weight:bold;}
h3
        {mso-style-priority:9;
        mso-style-link:"Heading 3 Char";
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:13.5pt;
        font-family:"Calibri",sans-serif;
        font-weight:bold;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
code
        {mso-style-priority:99;
        font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.Heading1Char
        {mso-style-name:"Heading 1 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 1";
        font-family:"Calibri Light",sans-serif;
        color:#2F5496;}
span.gmail-m-8384283795225213265gmail-gr
        {mso-style-name:gmail-m_-8384283795225213265gmail-gr;}
span.Heading3Char
        {mso-style-name:"Heading 3 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 3";
        font-family:"Calibri Light",sans-serif;
        color:#1F3763;}
span.Heading2Char
        {mso-style-name:"Heading 2 Char";
        mso-style-priority:9;
        mso-style-link:"Heading 2";
        font-family:"Calibri Light",sans-serif;
        color:#2F5496;}
span.EmailStyle24
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">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
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Nat Sakimura <sakimura@gmail.com> <br>
<b>Sent:</b> Wednesday, December 12, 2018 5:05 PM<br>
<b>To:</b> Anthony Nadalin <tonynad@microsoft.com><br>
<b>Cc:</b> openid-specs-ab@lists.openid.net Ab <openid-specs-ab@lists.openid.net><br>
<b>Subject:</b> Re: [Openid-specs-ab] TODO list for Self-Issued OP<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hi Tony, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Actually, SIOP's identifier is not URL but the hash of the public key. That's one of the most common misconceptions about SIOP. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Having said that, what you have pointed out is true and I am aware of it. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Nat<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Dec 13, 2018 at 4:14 AM Anthony Nadalin <<a href="mailto:tonynad@microsoft.com">tonynad@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">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<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>>
<b>On Behalf Of </b>Nat Sakimura via Openid-specs-ab<br>
<b>Sent:</b> Monday, December 10, 2018 11:41 AM<br>
<b>To:</b> <a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a> Ab <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Nat Sakimura <<a href="mailto:sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>><br>
<b>Subject:</b> [Openid-specs-ab] TODO list for Self-Issued OP<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p style="margin-bottom:9.0pt"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">(The most recent version of the following article is available at <a href="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" target="_blank">https://nat.sakimura.org/2018/12/11/todo-list-for-self-issued-op/</a>) </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Enjoy, </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Nat Sakimura</span><o:p></o:p></p>
<h1 style="margin:0in;margin-bottom:.0001pt;box-sizing:inherit"><span style="font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">TODO LIST FOR SELF-ISSUED OP</span><o:p></o:p></h1>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Self-issued OP (SIOP) is defined in Chapter 7 of OpenID Connect (2014). If we take </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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;</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">to identify himself that he is the PII principal that the identity relates to;</span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">as the requirements for Self Sovereign identity, SIOP can be used to implement SSID. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">In this model, there are four basic actors: </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Data S<span class="gmail-m-8384283795225213265gmail-gr">ubject</span>: that is “me”; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Claims Providers (CPs) that provides attested claims; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Relying Parties (RPs) that consumes the attested claims in order to provide services to the data subject; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">4.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Self-issued OPs (SIOPs) that provide the authenticated identity to the </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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 </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Registering the SIOP to the claims provider so that the SIOP can request signed claims to the claims provider; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Binding the Self-issued identifier (a hash of the public key) and the attested claims; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Attesting the signing key from the past;  </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">4.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Providing the claims to the RP when the SIOP is offline; and </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">5.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Enabling key recovery. </span><o:p></o:p></p>
<h3 style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:16.5pt;font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">1. REGISTERING THE SIOP TO THE CLAIMS PROVIDER</span><o:p></o:p></h3>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<h3 style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:16.5pt;font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">2. BINDING THE SELF-ISSUED IDENTIFIER TO THE ATTESTED CLAIMS</span><o:p></o:p></h3>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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-m-8384283795225213265gmail-gr">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">To achieve the goal,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555"> the SIOP as a client MUST send the SIID to be used against the RP in the claims request; </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">the CP MUST include the SIID as the value of the </span><code><span style="font-size:10.5pt;color:#555555">siid</span></code><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555"> claim; </span><o:p></o:p></p>
<h3 style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:16.5pt;font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">3. ATTESTING THE SIGNING KEY FROM THE PAST</span><o:p></o:p></h3>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<h3 style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:16.5pt;font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">4. PROVIDING THE CLAIMS TO THE RP WHEN THE DATA SUBJECT IS OFFLINE</span><o:p></o:p></h3>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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 </span><code><span style="font-size:10.5pt;color:#555555">client_id</span></code><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555"> and send it in the request. then, the CP creates an access token and binds it to the </span><code><span style="font-size:10.5pt;color:#555555">client_id</span></code><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555"> provided. 
 The RP then uses it against the URL of the CP that was provided in the ID Token to obtain the desired claims. </span><o:p></o:p></p>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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 </span><code><span style="font-size:10.5pt;color:#555555">client_id</span></code><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555"> is
 handy here as well. </span><o:p></o:p></p>
<h2 style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-family:"Arial",sans-serif;color:#2A2A2A;text-transform:uppercase">5. ENABLING KEY RECOVERY</span><o:p></o:p></h2>
<p style="margin-bottom:9.0pt;box-sizing:inherit"><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Individuals are notorious in managing his keys. There has to be layers of protection against it. Some of them are: </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">1.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">2.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">Instead of storing the QR code off-line at his home, he can send it to the safe-keeping service. </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:22.8pt">
<span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">3.</span><span style="font-size:7.0pt;font-family:"Times New Roman",serif;color:#555555">   
</span><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:#555555">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. </span><o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--
<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Chairman, OpenID Foundation<br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C7c3686d30b254f6e369808d66097107b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636802599274659036&sdata=aLAQHGn7qtMRTr9aghMAbVYkGpqk2xf5CWcW2KV%2BHPg%3D&reserved=0" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<p class="MsoNormal">Nat Sakimura (=nat)<o:p></o:p></p>
<div>
<p class="MsoNormal">Chairman, OpenID Foundation<br>
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnat.sakimura.org%2F&data=02%7C01%7Ctonynad%40microsoft.com%7C7c3686d30b254f6e369808d66097107b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636802599274669045&sdata=ZsSilJ%2FgBE%2FDQO1U0YzagpdvOUWZmq9SanIs6FD%2F8S4%3D&reserved=0" target="_blank">http://nat.sakimura.org/</a><br>
@_nat_en<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>