Delegation discussion summary

[Drummond Reed]

>>> Marius wrote:
>>>
>>> I was suggesting that portability can be resolved between the user  
>>> and
>>> the IdP. I cannot see how the protocol can help this by passing two
>>> identifiers. And if only the portable identifier is passed then  
>>> there is
>>> no need to mention the IdP-specific identifier.
>>
>> Marius, see the analysis at
>> http://www.lifewiki.net/openid/ConsolidatedDelegationProposal, now  
>> updated
>> to include Josh's lastest thinking from
>> http://openid.net/pipermail/specs/2006-October/000357.html.
>>
>> In sum, not being able to send the IdP-specific identifier: a)  
>> forces the
>> IdP to redo resolution, which is unnecessary and slows performance,  
>> and
>
>Not necessarily. When you register with the IdP most likely you will  
>claim all your portable identifiers with this IdP, so the IdP knows  
>about them.

With XRI i-name/i-number infrastructure that's neither practical nor
desirable. With XRIs, users control their own synonyms, i.e., I can register
a delegated i-name within a specific community (for example, at
@example.community I could register @example.community*drummond) and then
point that at my personal i-name (=drummond.reed) and the IdP for
=drummond.reed will never know -- and doesn't need to know. I could go to
any RP and login in as @example.community*drummond, the RP will resolve this
to =drummond.reed (through the way XRI resolution automatically handles
reference processing -- let me know if you want more info about this), and
end out storing the CanonicalID i-number for =drummond.reed (which is
=!F83.62B1.44F.2813).

>> b) prevents the protocol from being stateless.
>
>How? The RP deals only with the portable identifier and this is the  
>only thing the IdP sends back. Why do you need state?

It follows from the above. But this is so important that I'm going to send a
separate message about it.

=Drummond