Re: WebID-ISSUE-24: Privacy issues from WebID URI dereferencing [WebID Spec]

On 1 Feb 2011, at 11:27, WebID Incubator Group Issue Tracker wrote:

> 
> WebID-ISSUE-24: Privacy issues from WebID URI dereferencing [WebID Spec]
> 
> http://www.w3.org/2005/Incubator/webid/track/issues/24
> 
> Raised by: Nathan Rixham
> On product: WebID Spec
> 
> Part of the WebID protocol includes dereferencing a "WebID URI" specified by the identifying agent.
> 
> Whilst a measure of privacy and anonymity is provided by one half of the protocol (the TLS side), the act of dereferencing a "WebID URI" currently has authority/provenance issues (as outlined in ISSUE-23) and privacy issues.
> 
> Namely, privacy is not guaranteed, an intermediary (or a "webid/profile host") can detect a request from a server (say a bank, a private site, an adult site, a gambling site) to a users WebID URI and thus know the user has attempted to identify on said site.
> 
> This may be something which the protocol needs to address (for instance, force TLS for dereferencing), or may be something that is best noted and addressed by specification text (note as a security consideration and give advice).

I would argue that the possibility to identify the host who is requesting access to a WebID might be a requirement. 
This is e.g. the access for all (?) authentication schemes building on top of WebID. 

In use cases where WebIDs are seen as a key to access a users profile, the content returned by accessing the WebID URI might 
be determined by any kind of server side mechanism. E.g. an ACL / trust level / access policy set on the server side, or the result of some sort of distributed trust inference process. So depending on who is accessing the WebID, the returned data might be different ("dont include my telefon number").

Content negotiation might also be an issue to consider, not sure about that. 

However it might be possible to split the issue of masking access to the WebID on the server hosting the WebID, 
from the content and access negotiation, by defining how a "pure WebID" can point to another resource (or resources), 
which then holds actual user profile data. 
Then access to the pure WebID will not perform any content & access negotiation, but access to the further information will. 
This also means that access to the further information will always reveal the requesting host. 


To summarise: 
Entirely removing the possibility to identify the host requesting a WebID will basically cut of any resource *authorisation* schemes 
which might be built on top of pure WebID *authentication* (as far as I can see that). 

However it might be possible to make this optional somehow.

Received on Tuesday, 1 February 2011 13:26:01 UTC