Basic WebID overview

Hi Cosimo / All,

Let's try and give a developer overview of things to hopefully clarify, 
and in some ways re-start and refocus discussion.

Cosimo Streppone wrote:
> I feel a bit overwhelmed too.
> 
> I'm trying to get a hold of WebID, and I'm still stuck at
> the basic concept of it unfortunately.

WebID:
"Web Identifier", a web name (URI) for a person. For example, my WebID 
is http://webr3.org/nathan#me

WebID Protocol:
A protocol to use in order to authenticate a WebID

The abstract protocol:
- server requests authentication details
- user presents webid along with a key which the server knows they hold
- server GETs the webid URL and checks if the result contains the key 
the user presented
- if all goes well, server knows the user had permission to write to the 
webid url, and thus can use the url as a webid.


Rough design goals:
- use public key cryptography for keys, and force TLS on the wire (security)
- provide a machine readable profile for the user at the webid url 
(decentralization, user controls their own data etc)
- provide a human readable profile for the user at the webid url (the 
web is a whole lot nicer when humans can browser it)


Current realization of the WebID Protocol
- embed the webid inside the subjectAltName of an x509 certificate
- place the public key from the certificate in RDF at the webid url
flow:
-- user visits https address on server
-- server asks user to present a client side certificate
-- user selects certificate in browser
-- certificate is sent
-- server gets the public key details (exponent/modulus) and the webid 
(subjectAltName) from the certificate
-- server GETs the webid url, parses it, checks if the exponent and 
modulus is contained
-- if all matches, user is authenticated.


I think that about covers the basic concept of WebIDs and WebID 
protocol, there are many design considerations which can be added in to 
the mix, many different tech choices we can mix together, but roughly 
the abstract protocol mentioned above coupled with the rough design 
goals is what we're gunning for, in the easiest most future and 
backwards compatible way, taking in to account as many use cases as 
general web requirements as possible.

Web security and identity is a huge space though, so all kinds of things 
get brought up on the list, some are just things we need to be aware of, 
others are things we might be able to use, but imho the most important 
things are to gauge the direction of the rest of the web (ietf security 
guys going for mutual auth, considerations of openid and oauth flows) 
and to cover the main potential implementers (browsers, web developers, 
app/service developers), and main potential uses (social auth/ident, app 
auth/ident etc).

Hope that helps a little,

Best,

Nathan

Received on Thursday, 24 February 2011 01:31:50 UTC