Re: [saag] Liking Linkability

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. 
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

Received on Tuesday, 23 October 2012 09:57:23 UTC