Re: [Auth]Re: What I percieve is wrong with IDsec (was IDsec specification draft)

[Hans Zandbelt]

David,

At 16:23 1/5/2002 -0500, David Sugar wrote:
>What Hans said was what my comment was going to be, which, essentially, in the 
>IDsec model, you can always be your own profile provider, and one hopes one 
>can trust oneself :).  In that respect, it is not a fundimental weekness, nor 
>is it at all bad that one can establish organizations or commercial entities 
>that also act as profile providers; you can use them if you want or use 
>yourself.  There is also choice, since anyone is free to be or act as a 
>profile provider for others, rather than an exclusive club or only one such 
>entity.
>
>That being said, there are issues worth looking at in IDsec, and it, among 
>other potential solutions, are of course still evolving.  We should look at 
>the strengths and weekenesses of each.  One question to consider in IDsec is 
>knowledge leaking, or what information is leaked or reveled even if one does 
>run one's own profile provider.  If I learn that person "X" from IP "Y" is 
>always person "X", is that nessisary bad? Is this something that can 

This is indeed a matter that needs to be investigated. It should be an option to
for a user to allow a Content Provider to "recognize" his identity (although
this does not imply that his name is known) to correlate him to Content Provider
specific data that is stored at the Content Provider site. But ofcourse there
must also be an option for a user to specify that a Content Provider does *not* 
have access to any profile attribute that uniquely identifies the user.

I guess  it is impossible to prevent any Content Provider from using an
IP adress as an identifier and correlate it to earlier retrieved profile
attribute sets. (user "country: Holland, hobbies: soccer, favorite color: blue"
surfing from IP address x.x.x.x is visiting again).

>be learned thru other means anyway?  The question I wish to consider in more 
>detail is not so much what a given session reveals but what correlative data 
>might be revealed that would allow content provider site "A" to learn that 
>person "X" is the same as a given person identified thru IDsec at  content 
>provider "B", and if IDsec enables this to happen even if no correlative data 
>is enabled to be shared in the profile.  Certainly if you share 
>credit cards, for example, with both providers, this correlation can be done, 
>but what if I use IDsec only for the purpose of signon with both?  Does IDsec 
>as a session protocol reveal something that allows such correlations to occur?

I agree that this is what we need to prevent at all times. I think this is also 
partly
a job that a user has to do himself: if someone uses the same accountname and 
password on
site A and site B, a correlation can always be made by two malicious providers, 
regardless
of the IDsec protocols.

Hans.


------------------------------------------------------------
Hans Zandbelt                         address@hidden 
Telematica Instituut                     http://www.telin.nl 
P.O.Box 589, 7500 AN                   Phone: +31 53 4850445 
Enschede, Netherlands                    Fax: +31 53 4850400