openid.identity and openid.identifier

[Dick Hardt]

Hello List

I have written up what I think are the requirements for identifiers  
so that we can see if we agree to those. If so, then the proposal  
revision I have below may be an acceptable solution that keeps things  
simple and provides backwards compatibility.

Sorry that we are still having this discussion, but it is important  
if we are going to make a change, that we get it right.

-- Dick

Basic Protocol:
---------------------
A) User provides the RP with an identifier of some kind
B) The RP uses that identifier to find the user's IdP (the RP may  
discover other  useful information in the process
C) the RP sends a request to the IdP. This request is not signed and  
could be modified between the RP and the IdP
D) The IdP decodes the request and interacts with the user
E) The IdP sends a response to the RP that includes an the identifier  
the user would like to be known as
F) The RP verifies the response is valid and from the IdP
G) The RP verifies the IdP is authoritative for the identifier  
provided (there is some funkiness with delegation)


Requirements:
---------------------
1) 1.x compatability
We want existing 1.x OpenID IdPs and RPs to work unmodified

2) portable identifiers
This is a separation of the identifier from the identity provider.  
The document returned by resolving the identifier is under the  
control of the user and contains the IdP(s) authoritative for the  
identifier. This was a feature in OpenID 1.x that was accomplished  
with a delegation statement. The IdP was not aware of the portable  
identifier which may have some privacy advantages. In current  
implementations the delegate tag is publicly visible, so the IdP can  
easily search to find the delegates. An existing privacy advantage is  
that if a user has multiple delegates pointing to the same delegate,  
the IdP does not know which one a given RP is using. Not sure how  
valuable that is. Current thinking is that it is useful for the IdP  
to be aware of the delegate and to manage the portable identifiers.  
See Delegate Identifier Binding below for the implications of this  
change.

3) XRI support
This is a new feature in 2.0 that allows the user to provide an i- 
name rather then a URL to the RP.

4) directed identity
By allowing the user to provide the IdP URL to the RP rather then  
their OpenID, the IdP can manage a unique URL for each RP, or even  
generate a new one each time the user visits the RP. RPs cannot use  
the URL to collude about the user.

5) IdP identifier management
By providing the RP the IdP URL, the IdP can now help the user decide  
which identifier to present to the RP. The IdP could even assist the  
user if the user provided an OpenID URL or i-name. For example, the  
IdP can remember what identifier(s) the user presented in the past so  
that the user does not have to remember which identifier/persona they  
used at which site and can quickly correct mistakes.

6) Simplicity
It is desirable to keep things simple and easy to understand and  
implement.

7) Secure
It is desirable that OpenID 2.0 does not introduce new security  
concerns. We accept DNS spoofing as being an acceptable risk.


Delegate Identifier Binding:
--------------------------------------
For consistency with previous discussions, let's call the identifier  
contained in the delegate the IdP-specific identifier. In OpenID 1.x  
the RP bound the IdP-specific identifier to the public identifier.  
The IdP was not explicitly aware of the public identifier. It is  
desirable in OpenID 2.0 to allow the IdP to have explicit knowledge  
of the public identifier. This allows the IdP to allow the user  
select the public identifier if the IdP URL was given to the RP.
There also now are three choices on what the response to the RP can  
contain:

1) the IdP-specific identifier as was done in OpenID 1.x which leaves  
binding of the IdP-specific identifier and public identifier to the RP

2) the public identifier which implies the binding of the IdP- 
specific identifier and the public identifier is done by the IdP. In  
this case, the RP does not need to understand how the IdP is binding  
the public identifier and the IdP-specific identifier, and the IdP- 
specific identifier does not need to be resolvable

3) both the IdP-specific identifier and the public identifier. In  
this case the RP is binding the public identifier to both the IdP- 
specific identifier and the IdP

Current Proposal:
------------------------
The current proposal:
	http://www.lifewiki.net/openid/ConsolidatedDelegationProposal
	http://openid.net/pipermail/specs/2006-October/000650.html

proposes binding using option (3). Issues with this are:

a) The IdP is able to do the binding, and the binding mechanism can  
be independent of the RP.
b) Both IdP and RP are doing the same work. Inefficient, and more  
points of security failure.
c) the message and flow is different from when non-portable  
identifiers are returned


Revised Proposal:
-------------------------

* preserve openid.identity to have the same functionality as it does  
in OpenID 1.x
* Add a new parameter, openid.identifier  to reflect the new  
functionality in OpenID 2.0 (perhaps not the best name, suggestions?)
* use LocalID element for the IdP specific identifier, the delegate  
statement would only be for OpenID 1.x
* only one of openid.identity OR openid.identifier are in a message

A) If the RP or IdP are OpenID 1.x, then openid.identity is used and  
things work how they did in OpenID 1.x

the value of openid.identity in the request MUST match the  
openid.identity in the response. (this was previously not specified,  
and likely is how existing code expects things to work)

This meets requirement (1)

B) If the RP and the IdP are both OpenID 2.0, then openid.identifier   
SHOULD be used.

if the identifier is an XRI or IdP URL, then openid.identifier MUST  
be used.

if the user provided an OpenID URL, openid.identifier is the URL
if the user provided an IdP URL, openid.identifier is http:// 
openid.net/identifier_select/2.0
If the user provided an i-name, openid.identifier is the i-number

In the response, openid.identifier may be an i-number or an OpenID  
URL. The response identifier does not need to match the request  
identifier.

This meets requirement (5)

If we can get consensus on this, I will get a patch to the latest  
spec to reflect.

-- Dick