<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Forwarding Ryo Ito's response to list, don't think it went through.<br>
<div class="moz-forward-container"><br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Subject:
</th>
<td>Re: [Openid-specs-ab] Migration from OpenID 2.0 to
OpenID Connect</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">Date: </th>
<td>Thu, 13 Dec 2012 02:27:44 +0900</td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">From: </th>
<td>Ryo Ito <a class="moz-txt-link-rfc2396E" href="mailto:ritou.06@gmail.com"><ritou.06@gmail.com></a></td>
</tr>
<tr>
<th valign="BASELINE" align="RIGHT" nowrap="nowrap">To: </th>
<td>Justin Richer <a class="moz-txt-link-rfc2396E" href="mailto:jricher@mitre.org"><jricher@mitre.org></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>> but should it really be in the id token?
I think that the handling of RP becomes simple by putting this Claim
in ID Token.
For example, I image the following flow.
1. RP receives ID Token and Access Token in any Grant Type.
2. RP uses "user_id" included in ID Token for database lookup.
3. If the "user_id" is not registered, RP fetches an attribute from
UserInfo EP and display sign-up page.
In this case, RP only uses the Claimed ID of OpenID 2.0 instead of "user_id".
> I don't think it makes much sense to preregister this piece of information
This is a discussion points.
For OP which does not support PPID, it is not so sensitive to hand Claimed ID.
However, for OP supporting PPID, realm verification may be important.
I want to hear the thought of service supporting PPID like Google.
Ryo
2012/12/13 Justin Richer <a class="moz-txt-link-rfc2396E" href="mailto:jricher@mitre.org"><jricher@mitre.org></a>:
> I definitely like the idea of bridging the two -- we've got a similar
> situation here where our OIDC and OID2 servers will continue to run side by
> side. Some of our RPs are switching, some aren't, but the ones that are will
> need to have a way to transition. We can internally rely on stable usernames
> in the short term, so we've been doing that, but it would certainly be
> helpful to be explicit about it.
>
> I like the claim name, but should it really be in the id token? It seems
> like it's more a userinfo endpoint type of datum, to me. Stable, attached to
> the user, not changing with the session. Of course, like any claim, you
> could ask for it as part of a fat ID token, if that's your thing.
>
> I don't think it makes much sense to preregister this piece of information
> -- I'd rather see it just be included as part of the "profile" claim set or
> requested explicitly in the request object, like you have below.
>
> -- Justin
>
>
> On 12/12/2012 09:00 AM, Ryo Ito wrote:
>>
>> Hi,
>>
>> I talked with some Identity Geeks about migration from OpenID 2.0 to
>> OpenID Connect.
>>
>> This is a draft of Migration Guide.
>> <a class="moz-txt-link-freetext" href="https://github.com/ritou/r-weblife/wiki/Openid2-to-openidconnect">https://github.com/ritou/r-weblife/wiki/Openid2-to-openidconnect</a>
>>
>> This document assumes the situation in which OP is an existing site
>> which supports OpenID 2.0, and now is supporting the OpenID Connect.
>> OpenID 2.0 will be provided for the time being side by side.
>>
>> OP may not return a common identifier for each protocols.
>> We suggest that OP returns an ID Token including the existing OpenID
>> 2.0 identifier in OpenID Connect flow.
>>
>> ===
>> Dynamic Client Registration
>>
>> OP receives following parameters.
>>
>> require_openid2_claimed_id
>> OPTIONAL. (require openid2_claimed_id claim): Type: Logical - If the
>> value is true, then the openid2_claimed_id claim in the id_token is
>> REQUIRED. The returned Claim Value is the Claimed Identifier of OpenID
>> 2.0. The openid2_claimed_id claim request in the request object
>> overrides this setting.
>> openid2_realm
>> OPTIONAL. This is "openid.realm" parameter which used at OpenID 2.0
>> Request for realm-based PPID generation.
>> ===
>>
>> ===
>> OpenID Request Object
>>
>> If OP support the request with OpenID Request Object, RP is able to
>> set claims to "id_token" member.
>>
>> "id_token":
>> {
>> "claims":
>> {
>> "auth_time": {"essential": true},
>> ...
>> "openid2_claimed_id": {"essential": true},
>> "openid2_realm": <a class="moz-txt-link-rfc2396E" href="http://oid2rp.example.com/">"http://oid2rp.example.com/"</a>,
>> "acr": { "values":["2"] }
>> },
>> "max_age": 86400
>> }
>> ===
>>
>> ===
>> ID Token Payload
>>
>> OP includes "openid2_claimed_id" to Payload.
>> {
>> "iss": <a class="moz-txt-link-rfc2396E" href="https://op.example.com">"https://op.example.com"</a>,
>> "user_id": "24400320",
>> "aud": "s6BhdRkqt3",
>> "nonce": "n-0S6_WzA2Mj",
>> "exp": 1311281970,
>> "iat": 1311280970,
>> "openid2_claimed_id": <a class="moz-txt-link-rfc2396E" href="https://op.example.com/u/24400320">"https://op.example.com/u/24400320"</a>,
>> ...
>> }
>> ===
>>
>> Should these be included in specifications?
>>
>> regards,
>> Ryo.
>>
>
--
====================
Ryo Ito
Email : <a class="moz-txt-link-abbreviated" href="mailto:ritou.06@gmail.com">ritou.06@gmail.com</a>
====================
</pre>
<br>
</div>
<br>
</body>
</html>