Tumbled Logic

What is WebID?

WebID is a W3C Incubator Group (soon to be, and possibly by the time you read this already, a W3C Community Group) specifying a mechanism for using X.509 End Entity (or “client”) certificates to identify yourself to online services, and for performing attribute exchange through Linked Data.

WebID works like this:

• You generate, or obtain, an X.509 certificate for yourself. It doesn’t really matter to WebID-consuming services whether this is self-signed, self-issued, or issued to you by a third party.

• Your certificate includes a subjectAltName extension containing a URI which can be dereferenced (i.e., you plug it into some software and get some data back) in order to obtain some machine-readable data about you — that is, a profile document.

• That structured data includes a copy of the public key from your certificate.

Assuming the data could be retrieved and the keys match, this tells the consuming service three things:

• You have access to the corresponding private key (the TLS protocol exchange would have failed if not).

• Because the public keys in the certificate and profile document matched, any assertions made within the profile can be treated as being equivalent to if you made them as part of the certificate itself (and nobody else can make those assertions to you, because their public key wouldn’t appear in the profile).

• Because the keys match, you have confirmed that you are able to publish information at the URI in your subjectAltName (you can’t pick somebody else’s URI, because you don’t have the private key corresponding to the public key in their profile).

Almost all identity systems designed to operate across multiple sites involve some kind of attribute exchange — that is, passing information between the identity provider and consumer. In WebID, the part of the “provider” is played by the profile document that you publish yourself. If you want to add new “attributes” for exchange (i.e., publish additional information about yourself), you just make sure that it appears in the profile.

The profile itself can take any of a number of forms. At the time of writing, you can publish it as RDF/XML or XHTML+RDFa, but there are moves to expand this list to include Turtle and HTML5 Microdata.

You might wonder, reading this, how you can trust the information in the profile if the individual has published it themselves — but in actual fact this isn’t really any different to what happens elsewhere: you don’t trust that a person’s date of birth really is their date of birth because it says as much in their Facebook profile; the only thing which Facebook Connect can definitively tell you is data exclusively managed by the service itself: principally, that the person is logged in with a particular Facebook account, but also their “friendships” with other people (and the same applies to OAuth with Twitter, and other services similarly).

WebID doesn’t solve the world’s identity problems (there remains unspecified plenty of stuff around long-term key management, selective access-control to the profile, and trusted attribute exchange — that is, relaying claims made by other people about you), but nonetheless I think WebID is going to form an important piece in the puzzle.

Now, for some Q&A:

Do I need to use a “hash URI” or 303 for WebID subjects?

If you’re using http: or https: URIs, then in principle, yes (but see the next question, too). The URI carried by the subjectAltName extension is meant to be the URI for you, not the profile document. The theoretical constraint is therefore that the URI you pick for yourself and the URL for your profile document should be different, but by dereferencing the former you end up with the profile document (i.e., the latter) but that it describes you using the URI you started with. Using fragment identifiers is a way to do this which requires the least moving parts, because it means using something which is automatically stripped out (according to HTTP) when you dereference a URI — but it is by no means the only way.

However, it should be noted that a WebID verifier can be completely conforming and not care, and nor should it: as a piece of software which simply needs to deference a URI and check that in the document it gets back there is the public key correctly associated with URI it started with.

However, in the world of RDF, a given URI isn’t supposed to refer to two different kinds of resource (i.e., an information resource — or document — and non-information resource — something which isn’t the document) simultaneously, and so although it’s a valid as far as WebID is concerned to use the same URI to refer to both you and your profile document at once, you may find that the applications which employ WebID aren’t so forgiving, depending upon what it is that you’re doing.

In any case, what’s to say that you haven’t devised a (semi-)autonomous kind of document which can both present its own public key in a certificate and describe itself?

Can I use an acct: URI as my WebID URI, for example?

It’s not yet been specified, but there’s no reason why you couldn’t in principle: an acct: URI which can be resolved to the URL of a profile document containing a description of the acct: URI that you started with certainly satisfies the constraint of “the URI you pick for yourself and the URL for your profile document should be different, but by dereferencing the former you end up with the profile document but that it describes you using the URI you started with”. At the moment nobody has written the specification detailing how WebID consumers should process acct: URIs in order to obtain a profile document.

Why is the public key material copied into the profile document? Why not anything else?

Copying the public key material into the profile is a close parallel to the “verify your e-mail address” e-mail messages which services send you when you sign up to them: it confirms that you really do have the ability to publish information at the WebID URI.

The public key is used for this because of the nature of asymmetric cryptography: if only you have the corresponding private key, then there’s no benefit or incentive for anybody else to publish your public key in their profile, and similarly because you don’t have the private key belonging to anybody else, there’s no benefit or incentive for you to put their WebID URI in your certificate.

In fact, the public key is the only piece of information which needs to match: WebID doesn’t really care about all of the other stuff in your certificate: consumers know that if there’s any information that you really want to publish, you’ll put it in your profile.

Why use subjectAltName and not the Subject Distinguished Name?

The subject DN is intended to be a composite key allowing location of information in the X.500 DIT, and designed to be plugged straight into DAP queries. Even the emailAddress attribute is a bit of an aberration in this respect.

More importantly, a subjectAltName extension is (on balance), more likely to be user-specifiable than the content of the subject DN, and the retrieval semantics of URI alternative names are relatively well-defined (although WebID does extend them by adding processing rules). Finally, it’s not at all uncommon for certificate issuers to put all manner of cruft in the subject DN.