ConsolidatedDelegationProposal
Contents
|
Consolidated OpenID "Delegation" Proposal
- Note: updated on 2006-10-12 to incorporate the key points from Josh's latest proposal including renaming the proposed new parameter from **openid.rpuserid** to **openid.portable** and updating the terminology around identifier portability.*
This is not a new proposal but a consolidation of previous proposals including:
* Josh's original * Martin's * Josh's amendment
Terminology
* **Portable Identifier**: the OpenID URL or XRI that will be stored by an RP (this may or may not be the same identifier entered by the user – for example, with XRIs the user enters an i-name, but the RP will store the CanonicalID i-number). * **IdP-Specific Identifier**: the URL or XRI stored by the IdP and present in the openid:delegate element (for backwards compatability) or LocalID element (forwards compatability) of the OpenID service endpoint of an XRD (Yadis document). * **CanonicalID**: the XRI i-number in the verified CanonicalID element from the XRD (applies only to XRIs).
Summary of Motivations
1. Enable End-Users to manage **Portable Identifiers** at their IdP if desired. 2. Cleanly support the identifiers that the RP and IdP need to exchange in the directed identity use case. 3. Enable the protocol to be stateless (i.e., in OpenID 1.x the RP must keep track of the mapping between a **Portable Identifier** and the **IdP-Specific Identifier** because if it has both, the protocol only enables it to send the latter). 4. Enable RPs to take advantage of XRI **CanonicalDs** to protect End-Users from ever having their **Portable Identifier** reassigned (and thus their identity taken over). 5. Clearly separate and standardize the roles of the **Portable Identifer**, **IdP-Specific Identifier**, and XRI **CanonicalID** in the protocol.
Current State (before any of these proposals)
* The protocol has one identifier parameter: **openid.identity** * If the OpenID Service element in an XRD includes an openid:delegate element with a IdP-Specific Identifier, the **openid.identity** parameter is set to the IdP-Specific Identifier, otherwise **openid.identity** is set to the Portable Identifier. * Discovery is always done by the RP, and only RPs handle substitution of a IdP-Specific Identifier for a Portable Identifier.
Consolidated New Proposal
OpenID Authentication 2.0 would have two identifier parameters:
* **openid.identity** (required) * **openid.portable** (optional for RP to send, required for IdP to return if RP sends)
RP Rules for Identifier Parameters
The RP MUST perform discovery on the Portable Identifier. Then the rules governing the two identifier parameters depend on three inputs:
1. Whether the OpenID service type is **http://openid.net/identifier_select/2.0** or **http://openid.net/signon/2.0**. 2. Whether the Portable Identifier a **URL** or an **XRI**. 3. Whether or not a **IdP-Specific Identifier** is present in the XRD.
The rules for each of the five cases follow below.
Case 1: Directed Identity (Anonymous Portable Identifier)
If Portable Identifier is EITHER a URL or XRI that maps to a directed identity server (<Type>http://openid.net/server/2.0</Type>), the values are:
openid.identity = "http://openid.net/identifier_select/2.0" openid.portable = [empty] (optional)
Case 2: URL WITHOUT IdP-Specific Identifier
If Portable Identifier is a URL that DOES NOT map to a IdP-Specific Identifier, the values are:
openid.identity = Portable Identifier openid.portable = Portable Identifier (optional)
Case 3: URL WITH IdP-Specific Identifier
If Portable Identifier is a URL that DOES map to a IdP-Specific Identifier, the values are:
openid.identity = IdP-Specific Identifier openid.portable = Portable Identifier
Case 4: XRI WITHOUT IdP-Specific Identifier
If Portable Identifier is an XRI i-name (which always maps to a CanonicalID i-number) but doe NOT map to a IdP-Specific Identifier, the values are:
openid.identity = CanonicalID openid.portable = CanonicalID (optional)
Case 5: XRI WITH IdP-Specific Identifier
If Portable Identifier is an XRI that maps to a CanonicalID AND also to a IdP-Specific Identifier, the values are:
openid.identity = IdP-Specific Identifier openid.portable = CanonicalID
IdP Rules for Identifier Parameters
1. IdP MUST ALWAYS return the value of **openid.identity** sent by RP.
2. IF RP sends a non-empty **openid.portable**, IdP MUST return it.
3. If **openid.identity** = Portable Identifier that IdP does not recognize, IdP MUST to discovery to obtain the IdP-Specific Identifier.
4. If **openid.identity** = "http://openid.net/identifier_select/2.0", then IdP MUST: a) obtain the user's local identifier (doing discovery if necessary) and b) allow the User to select (or IdP to generate) the Portable Identifier. IdP returns:
openid.identity = "http://openid.net/identifier_select/2.0"
openid.portable = Portable Identifier
Openid:Delegate and LocalID Elements in OpenID Service Elements
For backwards compatability, the openid:delegate element (in the openid.net namespace) would continue to be supported. However starting with Working Draft 11 of XRI Resolution 2.0, the XRI TC is adding the LocalID element (which already a valid child element of the XRD root element) namespace) as a valid child of the Service element. This element (inspired by this very use case) allows any SEP to have a programmatically-accessible local identifier for the identified resource in the context of the service.
RPs and IdPs SHOULD use the LocalID element if present. If it is not present, they MUST use the openid:delegate element if it is present. (Note that neither is required because **openid.identity** will default to the Portable Identifier or CanonicalID if there is no IdP-Specific Identifier).
Example of using a LocalID element:
<Service priority="50">
<Type>http://openid.net/signon/2.0</Type>
<URI>http://www.whatever.com/openid</URI>
<LocalID>http://mart.whatever.com/</LocalID>
</Service>
Example of using an openid:delegate element:
<Service priority="50">
<Type>http://openid.net/signon/2.0</Type>
<URI>http://www.whatever.com/openid</URI>
<openid:delegate>http://mart.whatever.com/</openid:delegate>
</Service>
