Last week I attended my first TPAC ever – in Lyon, France.
Coming from the open-source world and such events like Fosdem or the ever brilliant Akademy I was not sure what to
expect. Should I pack a suite? On arrival all my fears were blown
away by an incredibly well organized event with a lot of nice
people. I felt very welcome as a newbie, there was even a breakfast
for the first-timers with some short presentations to get an
overview of the W3C‘s work in
general and the existing working groups. So before getting into any
details: I would love this to become a regular thing (not sure it
will though, seeing that next year the TPAC will be in China).
My main reason for going to the TPAC was identity on the Web, or
short WebID. OpenLink Software is a strong
supporter of the WebID identification and authentication system.
Thus, it was important to be present for the meeting of the WebID
community group.
The meeting with roughly 15 people spawned some interesting
discussions. The most heatedly debated topic was that of splitting
the WebID protocol into two parts: 1. identification and 2.
authentication. The reason for this is not at all technical but
more political. The WebID protocol which uses public keys embedded
in RDF profiles and X.509 certificates which contain a personal
profile URL has always had trouble being accepted by several
working groups and people. So in order to lower the barrier for
acceptance and to level the playing field the idea was to split the
part which is indisputable (at least in the semantic web world)
from the part that people really have a problem with (TLS).
This lead to a very simple definition of a WebID which I will
repeat in my own words since it is not written in stone yet (or
rather “written in spec”):
A WebID is a dereferencable URI which denotes an agent (person,
organization, or software). It resolves to an RDF profile document
uniquely identifying the agent.
Here “uniquely identify” simply means that the profile contains
some relation of the WebID to another identifier. This identifier
can be an email address (foaf:mbox), it can be a Twitter account,
an OpenID, or, to restore the connection to the WebID protocol, a
public key.
The nice thing about this separation of identity and
authentication is that the WebID is now compatible with any of the
authentication systems out there. It can be used with WebID-Auth
(this is how I call the X.509 certificate + public key in agent
profile system formally known as WebID), but also with OpenID or
even with OAuth. Imagine a service provider like Google returning a
WebID as part of the OAuth authentication result. In case of an
OpenID the OpenID itself could be the WebID or another WebID would
be returned after successful authentication. Then the client could
dereference it to get additional information.
This is especially interesting when it comes to WebACLs. Now we
could imagine defining WebACLs on WebIDs from any source. Using
mutual owl:sameAs relations these WebIDs could be made to denote
the same person which the authorizing service could then use to
build a list of identifiers that map the one used in the ACL
rule.
In any case this is a definition that should pose no problems to
such working groups as the Linked Data Protocol. Even the OpenID or
OAuth community should wee the benefits of identifying people via
URIs. In the end the Web is a Web of URIs…
