<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Helvetica, Arial, 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<br>
</font><br>
<div class="moz-cite-prefix">On 5/21/20 4:25 AM, Nat Sakimura via
Openid-specs-ab wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJcjuELwUmRNXCYoYAKHwOKkzOPwU4aaemg7kmXDX9rGXsG0=Q@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Hi
I and Edmund have been discussing the additional SIOP requirements that
were agreed to made into an independent document a while ago.
Here is what I am thinking right now. Edmund has a draft for new
"Aggregation Endpoint" of the Claims Providers (CP) that I am hoping that
he can follow up with.
General Flow happens like this.
1. On-Boarding of SIOP to CP
1.1. Dynamic Client Registration of SIOP to CP
1.2. User Authorizes general data access to SIOP.
1.3. SIOP obtains the AT/RT.
2. RP asking for a set of claims
2.1. RP requests the SIOP for a set of claims
2.2. SIOP creates the constrained claims request using AT and uid whose
value
is the `sub` value that the SIOP uses against the RP and should be set
as
the `sub` value of the aggregation endpoint response (NEW)
2.3. CP returns a JWS signed JWT that contains sub=value(uid) and other
requested claims in the payload.
2.4. SIOP puts the JWT in the ID Token and responds to the RP.
2.5. RP verifies that the `sub` value of the ID Token is equal to the `sub`
value in the CP minted JWT, besides all the verification that is required
for ID Token.
Here are some of the Requirements that follows the above.
1. CP MUST support OAuth Dynamic Client Registration.
2. CP MUST support "aggregation endpoint" that is capable of returning
constrained JWT with sub=uid.
Discussion
1. What should be the aud of the CP returned JWT?
Please chime into this thread.
Perhaps I should create an issue in the tracker...
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br>
</body>
</html>