<div dir="ltr">I have built an self-issued plan for health care. I decided it did not have sense to have a sub that was essentially a key-id and went another route which i plan to continue.<div>It uses an ID that supports key roll-over.<br><div>I would like to see a group address self-issued, but if there is a precondition to use the sub as defined in opic, I would not bother.</div><div>I have been a member of FAPI and HEART.</div><div>I have not joined AB/C as it never seemed in my interest. If self-issued was started without preconditions i would join.</div><div>I would be happy to demonstrate the UX demo i have, or show how it fits into health care if that would be helpful.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Peace ..tom</div></div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 22, 2020 at 12:25 PM Mike Jones via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_4928781561654999418WordSection1">
<p class="MsoNormal"><span style="color:rgb(0,32,96)">FYI, those using the Self-Issued OpenID Provider for DID Auth are using it a conforming way. The “sub” value is the JWK Thumbprint of the public key and they add a “did” claim to the ID Token. No breaking changes
are needed.<br>
<br>
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"> -- Mike<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(0,32,96)"><u></u> <u></u></span></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><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>Pamela Dingle via Openid-specs-ab<br>
<b>Sent:</b> Friday, May 22, 2020 11:46 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> Pamela Dingle <<a href="mailto:Pamela.Dingle@microsoft.com" target="_blank">Pamela.Dingle@microsoft.com</a>><br>
<b>Subject:</b> Re: [Openid-specs-ab] Starting SIOP draft discussion<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Hey all, <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">DIF has written a decentralized identity draft profile for OpenID Connect self-issued provider. The draft link is below, it needs review by this community and I hope we can find a converged path
where we either move that profile to OIDF for ratification or have some kind of formal liaison so that both communities can easily work together. Please note, this draft was not developed in the blockchain vacuum, I believe various of you have been consulted
over time so hopefully when you read this you will see this as a reasonable initial attempt.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">The draft is here: <a href="https://identity.foundation/did-siop/" target="_blank">https://identity.foundation/did-siop/</a><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">I think both Nat and Mike have the cross-foundational experience to make a recommendation on a good path forward - perhaps a joint meeting to review?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Thanks,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Pam <u></u><u></u></span></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="gmail-m_4928781561654999418divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net" target="_blank">openid-specs-ab-bounces@lists.openid.net</a>> on behalf of George Fletcher via Openid-specs-ab
<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Sent:</b> Friday, May 22, 2020 11:26 AM<br>
<b>To:</b> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.net</a>><br>
<b>Cc:</b> George Fletcher <<a href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>><br>
<b>Subject:</b> [EXTERNAL] Re: [Openid-specs-ab] Starting SIOP draft discussion</span>
<u></u><u></u></p>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-family:Helvetica,sans-serif">I don't have any direct comments to these points other than to say that the topic of spinning out the SIOP work into a new document and revising it came up in
the OpenID Connect working group meeting this past Thursday.<br>
<br>
Topics discussed included making the 'sub' claim not tied to the public key and possibly using a DID-like identifier. Or at least allowing a DID as the 'sub' claim for those wanting to use SIOP with self-sovereign identity use cases.<br>
<br>
Personally, I'm in favor of making SIOP real for today's use cases :)<br>
<br>
Thanks,<br>
George</span><u></u><u></u></p>
<div>
<p class="MsoNormal">On 5/21/20 4:25 AM, Nat Sakimura via Openid-specs-ab wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<pre>Hi<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>I and Edmund have been discussing the additional SIOP requirements that<u></u><u></u></pre>
<pre>were agreed to made into an independent document a while ago.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>Here is what I am thinking right now. Edmund has a draft for new<u></u><u></u></pre>
<pre>"Aggregation Endpoint" of the Claims Providers (CP) that I am hoping that<u></u><u></u></pre>
<pre>he can follow up with.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre><u></u> <u></u></pre>
<pre><u></u> <u></u></pre>
<pre>General Flow happens like this.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>1. On-Boarding of SIOP to CP<u></u><u></u></pre>
<pre>1.1. Dynamic Client Registration of SIOP to CP<u></u><u></u></pre>
<pre>1.2. User Authorizes general data access to SIOP.<u></u><u></u></pre>
<pre>1.3. SIOP obtains the AT/RT.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>2. RP asking for a set of claims<u></u><u></u></pre>
<pre>2.1. RP requests the SIOP for a set of claims<u></u><u></u></pre>
<pre>2.2. SIOP creates the constrained claims request using AT and uid whose<u></u><u></u></pre>
<pre>value<u></u><u></u></pre>
<pre> is the `sub` value that the SIOP uses against the RP and should be set<u></u><u></u></pre>
<pre>as<u></u><u></u></pre>
<pre>the `sub` value of the aggregation endpoint response (NEW)<u></u><u></u></pre>
<pre>2.3. CP returns a JWS signed JWT that contains sub=value(uid) and other<u></u><u></u></pre>
<pre>requested claims in the payload.<u></u><u></u></pre>
<pre>2.4. SIOP puts the JWT in the ID Token and responds to the RP.<u></u><u></u></pre>
<pre>2.5. RP verifies that the `sub` value of the ID Token is equal to the `sub`<u></u><u></u></pre>
<pre>value in the CP minted JWT, besides all the verification that is required<u></u><u></u></pre>
<pre>for ID Token.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>Here are some of the Requirements that follows the above.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>1. CP MUST support OAuth Dynamic Client Registration.<u></u><u></u></pre>
<pre>2. CP MUST support "aggregation endpoint" that is capable of returning<u></u><u></u></pre>
<pre>constrained JWT with sub=uid.<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>Discussion<u></u><u></u></pre>
<pre>1. What should be the aud of the CP returned JWT?<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<pre>Please chime into this thread.<u></u><u></u></pre>
<pre>Perhaps I should create an issue in the tracker...<u></u><u></u></pre>
<pre><u></u> <u></u></pre>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Openid-specs-ab mailing list<u></u><u></u></pre>
<pre><a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><u></u><u></u></pre>
<pre><a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.openid.net%2Fmailman%2Flistinfo%2Fopenid-specs-ab&data=02%7C01%7CPamela.Dingle%40microsoft.com%7Cf39bbc422b754749a3b808d7fe7db2d9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637257688151453303&sdata=r%2BV7vX58WmLUWqOAyvaLuMEnVVuj4B1OhRPIUFrPRrU%3D&reserved=0" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><u></u><u></u></pre>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>