Yet Another Delegation Thread

Pete Rowley prowley at redhat.com
Wed Oct 25 18:50:41 UTC 2006


Drummond Reed wrote:
>>> Drummond Reed wrote:
>>> 3) Allowing the user to control Claimed
>>> Identifier-to-IdP-Specific-Identifier mapping gives the user the ability
>>>       
> to
>   
>>> establish any number of OpenID "synonyms" that do not require any
>>> involvement on the part of the IdP. In many ways this is the user-facing
>>> compliment of the directed identity value proposition: in directed
>>>       
> identity,
>   
>>> the user can have the IdP create any number of pseudonyms for different
>>>       
> RPs.
>   
>>> But the user is dependent on the IdP for this functionality. With Claimed
>>> Identifier-to-IdP-Specific-Identifier mapping, the user controls which
>>> Claimed Identifier maps to which IdP-Specific-Identifier, and is NOT
>>> dependent on the IdP for this mapping (which means it is entirely
>>>       
> portable).
>   
>>>   
>>>       
>> Pete Rowley wrote:
>>
>> Is it a goal to not allow correlation of identifiers? If so, I do not 
>> think this meets that goal.
>>
>> Looking at the parties involved here, I necessarily have to trust my 
>> IdP, but I certainly don't want to trust RPs. So if there is to be 
>> leakage of information, it should go to the IdP, who is charged with the 
>> protection of my data. This appears to construct what amounts to a map 
>> of all my online identifiers nicely formatted so that a bot can harvest 
>> it easily. Perhaps non-correlation is a non-goal for this particular 
>> feature - but I would hope that it would be a high priority.
>>     
>
> You're absolutely right, Pete -- since all of these identifiers would be
> public identifiers, a bot could harvest them. So non-correlation is not a
> goal of this feature -- the goal is IdP-independent public synonym
> management.
>   
It seems to me - especially given directed identity is another feature - 
that the two could be merged such that non-correlation could be achieved 
for portable identifiers. It might be hard to do that without _any_ help 
from the IdP - but it seems like a worthwhile thing to think about.


-- 
Pete

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20061025/00ed3447/attachment-0002.bin>


More information about the specs mailing list