[Openid-specs-ab] Migration from OpenID 2.0 to OpenID Connect

[Justin Richer]

OK, the more I think about it, I'm starting to think that we might need 
a universal mechanism to register "default value for X request claim" as 
opposed to separate things for default_max_age, default_acr, etc. What 
does that look like, exactly? I'm not sure, but it could be as simple as 
namespacing the parameter name:

"Any registration parameter that starts with default_* indicates a 
client's desired default value for a request claim."

Or maybe use dot-notation instead of underbars, which is how I've 
suggested to use structure in the OAuth2 Form Encoding responses.

Thoughts? I can file an issue.

  -- Justin

On 12/12/2012 10:09 AM, Justin Richer wrote:
> 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.
>> https://github.com/ritou/r-weblife/wiki/Openid2-to-openidconnect
>>
>> 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": "http://oid2rp.example.com/",
>>        "acr": { "values":["2"] }
>>       },
>>     "max_age": 86400
>>   }
>> ===
>>
>> ===
>> ID Token Payload
>>
>> OP includes "openid2_claimed_id" to Payload.
>> {
>>   "iss": "https://op.example.com",
>>   "user_id": "24400320",
>>   "aud": "s6BhdRkqt3",
>>   "nonce": "n-0S6_WzA2Mj",
>>   "exp": 1311281970,
>>   "iat": 1311280970,
>>   "openid2_claimed_id": "https://op.example.com/u/24400320",
>>   ...
>> }
>> ===
>>
>> Should these be included in specifications?
>>
>> regards,
>> Ryo.
>>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>