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