dotgnu-auth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]Freport Update


From: David Sugar
Subject: Re: [Auth]Freport Update
Date: Fri, 15 Mar 2002 07:22:06 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914

In this Hans is completely correct. The underlying goal is to not design the framework to deliberately rat out users data so that profiles can be created. The content provider in IDsec does not know that you, as "user x" is the same at content provider "a" as you, as "user y" at content provider "b". However, if you permit content provider "a" and "b" to have correlative information (say the same cc number) then certainly they can draw a correlative conclusion whether this happened thru idsec, or by you visiting the site and giving each company your credit card directly :). If used for purely anonymous authentication, IDsec works fine, and it does not architecturally go out of it's way to rat out the user, assuming you can trust your profile provider, or yourself if you are your own.

While it's understood what a content provider can potentially learn depending on what is shared, the other question is what can a profile provider learn about you? This is an interesting question, because the profile provider would obviously know what content providers you are visiting based on their requests for your profile. If you are your own profile provider, this again eliminates that risk.

I do not say IDsec is perfect, but it is a reasonable effort and what flaws exist can be understood and mitigated, especially by locally hosting profiles. The primary question is can profile providers be trusted? But since anyone can become one, it is quite possible for trustworthy (and untrustworthy) ones to exist.

Hans Zandbelt wrote:

At 02:54 3/15/2002 -0600, John wrote:

That's it. Although ID-Sec has been much better supported, I still see
it's failure to protect the "sites-visited meta-data"  as a major
departure from DotGNU's original edict of fully protecting customer


This is *not* an IDsec problem!
IDsec in itself *does* guarantee that Profile Requesters cannot relate
eachothers data by using "meaningless" session identifiers!

However it depends on the nature and the amount of the
data itself that you give to Profile Requesters wether this will actually
work out: if you pass your private address to Profile Requester A and to Profile
Requester B, it's quite logical that they will be able to associate
these visits with the same person ... This is not an IDsec problem:
it's a problem that you would have with these Profile Requesters.
You shouldn't give this kind of profile data to malicious Profile Requesters;
The only thing IDsec can do is that it won't give this kind of data to Profile Requesters that you don't trust.

As a matter of fact, Service Providers today can easily assemble user
profiles bases on client IP addresses. This is also an issue that will
not be solved and that is out of scope here.

I have explained this before and you can read it in the draft
specification. Please do so before making this kind of statements!

Regards,

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
_______________________________________________
Auth mailing list
address@hidden
http://subscribe.dotgnu.org/mailman/listinfo/auth





reply via email to

[Prev in Thread] Current Thread [Next in Thread]