yet-another-identifier-post

Dick Hardt dick at sxip.com
Sat Oct 14 21:01:28 PDT 2006


Here is another description of the protocol. As usual, it is terse  
and concise. Hopefully this provides some insight.

Goal: RP would like to know which identifier to bind to a given  
browser session, specifically, is this an identifier the RP already  
knows about.

Assumptions:
	The RP trusts the DNS infrastructure.
	The RP trusts the user to select a trustworthy IdP and to securely  
manage documents that may be resolved with the identifier.
	The RP does NOT need to trust the IdP.
	
1) The RP gets a discovery_identifier from the user. (an i-name,  
OpenID URL, Homesite URL)
2) The RP normalizes the discovery_identifier, and then does  
discovery on it to determine the IdP entry point.
3) The RP sends the discovery_identifier to the IdP entry point in a  
request.
4) The IdP uses the discovery_identifier as a hint as to which  
presented_identifier the user would like to present to the RP.
5) The IdP sends the presented_identifier in a response to the RP
6) The RP verifies the response came from the IdP
7) The RP verifies the IdP is authoritative for the presented_identifier

The discovery_identifier is only a hint to the IdP. The user could  
pick any identifier to be presented to the RP, so what the RP sends  
is only a suggestion. The user may have typed in the wrong  
discovery_identifier, and the IdP can assist the user in using the  
same presented_identifier they have used in the past at a given RP

In (2), the RP may have learned what it needs for (7). Since the RP  
needs to trust this binding of presented_identifier and IdP, the RP  
cannot trust the IdP in making that binding.

The IdP needs to know which i-name the user typed in so that it can  
present that to the user if appropriate, same for the RP. The i- 
name / i-number binding at the RP must be performed by the RP.  The  
IdP likewise needs to verify the binding so that it knows it is not  
making a statement that is not true.



More information about the specs mailing list