- From: Henry Story <henry.story@bblfish.net>
- Date: Sat, 6 Oct 2012 11:05:25 +0200
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: "public-webid@w3.org" <public-webid@w3.org>, Ben Laurie <benl@google.com>
- Message-Id: <28A6942E-1AC2-44A9-977A-FFF37CCBE500@bblfish.net>
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 https://github.com/bblfish/scalaz-playground/blob/master/src/main/scala/play/DynamicServer.scala > 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 http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Saturday, 6 October 2012 09:05:57 UTC