Re: Question/idea: Self-contained WebID

Hi Brian,

  welcome to the list. 

On 5/27/14 1:08 PM, Brian Allen Vanderburg II wrote:
> As a person using many different accounts to different sites, having a
> lot of usernames and passwords can be a real pain.  As a result, I like
> the ideas I've seen with concepts like OpenID and WebID.  I do have one
> question/idea that I would like to know about that could improve it.

You may want to check the specifications
we have published allready and which are published here:

   http://www.w3.org/2005/Incubator/webid/spec/

We are keen for any feedback you may have on the specs.

> 
> OpenID requires third party identity providers.  That means that I don't
> really "own" my identity, instead another group owns my identity.  If,
> for some reason, that server is unavailable, I can't use that identity.
> Or if that server gets compromised, then my identity, along with others,
> may also become compromised.

OpenID 1.0 at least requires you to have a web site, which is where the
relying party goes to fetch the information for the identity provider.

> 
> One idea I've had in the past would be a system similar to SSH private
> key logins.  With SSH, I own my identity by owning my private key file.
> I can put the same public key on multiple systems, and log in using that
> one private key file.  It doesn't depend on any external third party
> groups, only my client and the server I am connected to.

You can do this with TLS as is. In fact in part 4 of the authentication sequence
of WebID-TLS that is all the server knows about the client.

  http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence

The WebID protocol is all about how to tie a public key to a WebID. The reason
we are interested in the WebID is that we want to build a distributed social web.

There is no reason why this could not be enough to identify someone at that 
point. One could imagine an Web Access Control Rule that stated

@prefix acl: <http://www.w3.org/ns/auth/acl#> .
@prefix cert: <http://www.w3.org/ns/auth/cert#> .

[] acl:accessTo <protected>; 
   acl:mode acl:Read; 
   acl:agent [ a foaf:Agent;
               cert:key [ cert:modulus "cb24..."^^xsd:hexBinary;
                          cert:exponent 65537 ] ] .


cert:key is an inverse functional relation so a key helps identify an agent.

> 
> I'm only vaguely familiar with WebID.  

I hope our specs can help you there too. 

> It seems like it works by storing
> a client certificate on the user's computer.  But it still seems to
> require a public server for access to the WebID foaf.rdf file. Would it
> not be possible for a client/browser to implement it's own way of
> storing that file and sending it to a server when attempting to use
> WebID for authentication and login, so that it would remove the need of
> some hosting provider or server from storing it.  

You don't need WebID for that. Plain X509 Certificates allready do that.
True the X509 certificate syntax is really old and cranky, but one could imagine replacing 
that with a JSON-LD signed document in an improved TLS. 

The question is then how do people trust the X509 certificate when you log in somewhere?

Currently the solution people have is to get that X509 certificate signed by a "big corporate".
One could also work by signing the certificate by a number of friends, but then you have
the problem of how do you change your certificate when you need to. That is illustrated in this FAQ:

https://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_this_improve_over_X.509_or_GPG_Certificates.3F

So the advantage of an http:// url is that we can use links between agents to build an indirect
web of trust.


> The idea there would
> be to allow the user to own their identity entirely, without any need of
> an external provider or server to host the file, perhaps allowing for ID
> by the key fingerprint.

That you can do already: you could describe your friends by the keys they use as shown above,
and use that to give or deny access to people. 


> 
> Brian Vanderburg II


Social Web Architect
http://bblfish.net/

Received on Wednesday, 28 May 2014 19:44:24 UTC