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

Re: WEbID Todos

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sat, 6 Oct 2012 09:48:38 +0200
Message-ID: <CAKaEYh+ntf69Y7hfkbK-6uZSU+U6U0ZiqKS5T4tcv6MgPLOGGA@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Cc: "public-webid@w3.org" <public-webid@w3.org>, Ben Laurie <benl@google.com>
On 27 September 2012 13:11, Henry Story <henry.story@bblfish.net> wrote:

> While it is still fresh in my head let me write down a few things that
> came out of the conversation with Ben that we can improve in our spec:
> 1. Improve the spec to show how a WebID can be associated with a number of
> public keys.
> 2. Add a wiki page detailing the Making the public key:
>    - we should have a wiki page that goes into detail in the process of
> key creation as shown in the video shown on
>       http://webid.info/
>     so we can point people to it. This is not obvious
> 3. Having a password for your profile page is no sin.
>    We should perhaps emphasize that somewhere: the profile page you have
> may be the one place
>  you can still use a password. I know that foaf.me and my-profile had
> wanted to only use certificates, and that doing this though conceptually
> cool, makes starting things up more difficult. Other toosl can be used such
> as one time passwords, or OATH ( OATH not OAUTH! ), but the benefits of
> WebID comes from logging into OTHER sites that support it, removing the
> NASCAR problems.
> 4. Explain TLS renegotiation more: this is what allows one to create TLS
> sites that don't ask you for a certificate before you even reach the page.
> 5. Link clearly to the improvements in browsers that can be done.
> All of these should be easily available from the home page of the
> community group and from webid.info
> Those some points I can remember, that we could improve.


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.

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.

(1) I think solves the unlinkability problem

(1+2) is a complete identity solution.

> Henry
> Social Web Architect
> http://bblfish.net/
Received on Saturday, 6 October 2012 07:49:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:43 UTC