Re: [saag] Liking Linkability

On 23 Oct 2012, at 11:56, Nathan <nathan@webr3.org> wrote:

> Ben Laurie wrote:
>> b) Linkability it not, as you say, inherently bad. The problem occurs
>> when you have (effectively) no choice about linkability.
> 
> .. and when people convey or infer that there is no choice about linkability, when there really is scope to be as unlinkable as one likes within WebID.
> 
> Quite convinced now that the confusion is just differing objectives and opinions, and nothing technical.
> 
> You can have one or more WebIDs to cover any combination of one or more requests to one or more resources. Be as linkable or unlinkable as you like.
> 
> On the other hand, WebID the idea (rather than the technical protocol) has been created within a context where linkability is desired, indeed it's creation was to enable and promote increased linkability - so applying it to situations where unlinkability is desired goes against the grain, or clashes with individual's general mental model of it.
> 
> In it's simplest form, WebID is just a way to establish an identifier for an agent layered on to the usual client cert auth. This allows:
> - WebID to be used anywhere HTTP+TLS can be used
> - Crucially, identifiers to be used that refer to resources anywhere on the web which can be interacted with in order to find out more about the agent identified. Without relying on fixed API features, multiple protocols and layers, out of band knowledge, or limited functionality by using non dereferencable identifiers.
> 
> So if wikileaks want to generate a cert with an identifier only they can view and which is completely unlinkable, for a one time use, they can.

yes, but they had better use some other technology such as TLS-Origin-Bound Certificates
then. http://tools.ietf.org/agenda/81/slides/tls-1.pdf
I am not even sure that is a good idea. Strong username passwords may still be a lot better there, and suggesting strongly the user remember it by heart.

> If a bank wants to issue a series of certs to a client which has some stable identifier in them for the client, they can. If facebook want to issue certs which have identifiers which deref to a machine/human readable version of the users profile, and allow people to use their facebook id on any site, they can. If a single person wants to handle their own identity and profile, they can. If services like AWS want to issue keys to machine agents, they can. And critically, they'd all be interoperable from a technical view, with limits to which identifiers and keys and as to which information is visible and what can be used where added on by ACL and usage restrictions.
> 
> It's quite simple really, client cert auth over TLS is well established, and HTTP(s) URIs allow dereferencing to anything on the web, with the possibility of any features you find anywhere on the web.
> 
> Seems far more logical and simpler than creating a plethora of custom protocols which rely on layer upon layer of techs and protocols in order to try and make non dereferencable identifiers dereferencable, or to try and provide more information about an identified agent via a suite of API extensions that need implemented by all adopters, or to come up with something new which has most of the same negative sides, and requires web scale adoption in order to work everywhere WebID already can.
> 
> Best,
> 
> Nathan

+1 :-)

Social Web Architect
http://bblfish.net/

Received on Tuesday, 23 October 2012 10:15:53 UTC