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