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. _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs