Openid2 to openidconnect

Migration Guide from OpenID AuthN 2.0 to OpenID Connect

(I intend to send this suggestion to OpenID Connect Spec WG.)

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 stop OpenID 2.0 support sometime. Though it may be several years later.
• OP may return different User Identifier for each protocols.

Through the following procedures, RP can provide OpenID Connect without re-registering existing users.

• Both RP and OP do not change any existing OpenID 2.0 code.
• OP returns an ID Token including the existing OpenID 2.0 identifier in OpenID Connect flow.
• RP will NOT make users confused as much as possible.

OpenID 2.0

RP uses Claimed Identifier included in Positive Assertions for the user identification. The format of this is URL or CanonicalID of XRI.

OpenID Authentication 2.0 - Final

11.5. Identifying the end user

The Claimed Identifier in a successful authentication response SHOULD be used by the Relying Party as a key for local storage of information about the user. The Claimed Identifier MAY be used as a user-visible Identifier. When displaying URL Identifiers, the fragment MAY be omitted.

RP stores the combination of Claimed Identifier and user identifier of own site.

Some OP supports realm-based PPID.
By the document of the ICAM, RP can require PPID for own policy.

ICAM OpenID 2.0 Profile

3.4.2 Private Personal Identifiers

1. The IdP MUST establish a unique and persistent pseudonymous end user identifier for each userRP pair. This Private Personal Identifier (PPID) SHALL be expressed in both the openid.identity and openid.claimed_identity fields within positive assertions about the end user. a. The pseudonym is used to identify the end user to the RP in a way that protects the end user's privacy by preventing propagation of the end user's common identifier throughout the Federal Government.
   b. All pseudonyms MUST be globally unique.
   i) The IdP MUST NOT use the same pseudonym for an end user at multiple RP realms.
   ii) To ensure global uniqueness the IdP SHOULD include an IdP specific base within the PPID.
2. The IdP MUST protect pseudonyms from disclosure outside of the user-RP pair.
3. The IdP MUST construct a pseudonym in a way that ensures that it cannot be reverse engineered to help identify an end user across multiple realms.
4. For purposes of computing the PPID, the IdP MAY normalize the realm by using the fully qualified domain name excluding the pre-pended www domain segment, if included.

However, most OP returns PPID forcibly.

OP

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.

TBD :

• How to verify openid2_realm parameter?

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

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",  
 ...  
}  

RP

User Interface

RP supports an identifier of OpenID Connect Discovery with an existing OpenID form.

The user may not notice that they can put Email into this form.
RP may have to give a user some kind messages.

Discovery

RP has to do discovery of OpenID Connect first. When the identifier that a user input is not Connect's format, RP skip it. If it failed, RP do discovery of OpenID 2.0.

• Email : Only Connect Discovery
• URL : Both Connect and 2.0 Discovery
• Domain : Both Connect and 2.0 Discovery
• XRI : Only OpenID 2.0

Request

If it works in OpenID Connect flow, RP requests "openid2_claimed_id" claim.

Response Handling

RP checks whether "openid2_claimed_id" claim is included in ID Token. If it is found, RP searches an existing user matching it.