Consolidated Delegate Proposal

Drummond Reed drummond.reed at cordance.net
Tue Oct 10 21:08:56 UTC 2006


>>> On 10/10/06, Dick Hardt wrote:
>>> [openid.rpuserid is the identifier] that the user gave the RP?
>>
>> Josh Hoyt wrote:
>> For URL identifiers, it is the supplied identifer, normalized, after
>> following redirects. In essence, it's the user's chosen identifier.
>>
>> For XRI identifers, it's the canonical ID (i-number).
>
>Dick Hardt wrote:
>
>This comment led me to want to make sure I understand the  
>requirements of XRI.
>
>Q: why would the RP not want the i-name to come back rather then the  
>i-number?
>
>The i-number can be derived from the i-name. The i-name is what is  
>user visible. The IdP will make sure the i-name the user is  
>presenting resolves to the i-number the user has presented in the past.
>
>Am I missing something?

Since the RP has to do discovery on the i-name, the RP already has the
i-number (CanonicalID). Further, as explained in previous threads, the
CanonicalID is the primary key the RP wants to store for the user, not the
i-name, because the i-number is forever while the i-name could change.

The RP is also motivated to send the i-number to the IdP for the same reason
that the RP is motivated to send the delegate URL (if available): to
increase performance by saving the IdP from having to re-resolve the i-name
(in the XRI case) or original URL (in the URL case).

Lastly, in the case where the identifier-the-RP-stores and the
identifier-the-IdP-stores are different, if the RP has already discovered
the latter, then the RP can be stateless by sending both to the IdP, knowing
it will receive both back in the response. If the RP can only send one
identifier to the IdP, it's stuck with a dilemma:

* If the RP sends the identifier-the-RP-stores, then it forces the IdP to
redo discovery, slowing performance.
* If the RP sends the identifier-the-IdP-stores, then the RP cannot be
stateless because it has to maintain a mapping between the
identifier-the-RP-stores and the identifier-the-IdP-stores.

In summary it boils down to this:

* If the identifier-the-RP-stores and the identifier-the-IdP-stores are both
the same, everything works fine with one identifier parameter,
openid.identity.

* However if the identifier-the-RP-stores and the identifier-the-IdP-stores
are different, several efficiencies and optimizations are possible by
enabling protocol messages to send and receive both the
identifier-the-RP-stores (openid.rpuserid) and the identifier-the-IdP-stores
(openid.identity) That's the proposal currently summarized at
http://www.lifewiki.net/openid/ConsolidatedDelegationProposal. 

=Drummond 





More information about the specs mailing list