Re: WEbID Todos

On 6 October 2012 11:05, Henry Story <henry.story@bblfish.net> wrote:

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

I agree 'search' is not the same as a lookup.  Although a lookup over a
network is not guaranteed to return.  What I was trying to illustrate is
the generalization of the problem we are trying to solve.  And that is,
given an IFP can we verify the URI.  There are a number of ways to do this,
of which the spec gives a great example.


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

Yes agree.  This is one of the reasons I was starting work on the service
at http://publickey.info/ which will store a historical record of your
key(s) over time.  So much to work on tho, it's hard to find time to build
up this kind of infrastructure.


>
> (1) I think solves the unlinkability problem
>
>
> Can you explain what the unlinkeability problem is? Or for who it is a
> problem?
>

4.  Unlinkability

   Definition:  Unlinkability of two or more Items Of Interest (e.g.,
      subjects, messages, actions, ...) from an attacker's perspective
      means that within a particular set of information, the attacker
      cannot distinguish whether these IOIs are related or not (with a
      high enough degree of probability to be useful).

This is something Harry brought up.


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