W3C home > Mailing lists > Public > public-webid@w3.org > October 2012

Re: WEbID Todos

From: Henry Story <henry.story@bblfish.net>
Date: Sat, 6 Oct 2012 11:05:25 +0200
Cc: "public-webid@w3.org" <public-webid@w3.org>, Ben Laurie <benl@google.com>
Message-Id: <28A6942E-1AC2-44A9-977A-FFF37CCBE500@bblfish.net>
To: Melvin Carvalho <melvincarvalho@gmail.com>

On 6 Oct 2012, at 09:48, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> [snip]
> WebID is actually 2 specs.
> 1. The first part is authentication via your public key which is a IFP of your identity.  In certain circumstances (ie caching, just like ~/.ssh/authorized_keys ) you can be done here and it operates like SSH.

yes, the public key can be one of your Principals (in java language). This is problematic if you have more than one browser, as that then  requires you to use the same key in your browsers if you want to be recognised as  the same person across your devices. That is tricky whatever you do, because you need to make sure the private key does not leak.

But of course you can always already use the public key as a Principal immediately, before even you continue with webid verification. I played with this here for example


> 2. The second part is discovery and verification of your URI of which your public key is the IFP.  I tend not to like the term discovery too much because actually it's search.  Search can be a forward search (eg follow your nose) or a reverse search (eg google search engine).  It's possible to imagine a reverse search service that allows you to verify a webid given the IFP of a key (e.g. PEM / DER / exponent--modulus / fingerprint) and will verify the URI.

Search is not at all the same thing. It is the difference between looking up the meaning of a term, in 
a well known location, and searching for something with vague criteria, that may or may not result in correct hits.
We don't say that we search for a memory space when we have a pointer. We just do a lookup.

In WebID we are doing something very similar to what IETF DANE is doing. You lookup the meaning 
of the Identity by  dereferencing it in the canonical manner for that identifier token. So a domain name 
is dereferenced  using DNS(sec), and URL is dereferenced canonically using HTTP for HTTP urls, ... 
This gives you  the meaning of the key. If you can get the same information elsewhere with the same 
reliability, then you can use other methods of course. But the reason this works is that you are looking
up the definition of the term, which you find by definition at the canonical location! This is why we were
talking about this on the philoweb group too.

You cannot just do a google search for a WebID and hope that whatever comes back
is good enough. Otherwise I could just put up a lot of information pretending to be you and
perhaps win in the Google search results.

> (1) I think solves the unlinkability problem

Can you explain what the unlinkeability problem is? Or for who it is a problem?

> (1+2) is a complete identity solution.
> Henry
> Social Web Architect
> http://bblfish.net/

Social Web Architect

Received on Saturday, 6 October 2012 09:05:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:37 UTC