[foaf-protocols] WebID spec: Subject Alternative Name extension

Bruno Harbulot Bruno.Harbulot at manchester.ac.uk
Sat Jul 17 00:25:12 CEST 2010

On 16/07/2010 22:46, Seth Russell wrote:

>     Again, the whole point of the WebID is to enable linked data and
>     what it entails. In particular, a simple example is, as you suggest,
>     getting the user's e-mail address. foaf:mbox does just that from the
>     WebID profile document.
>     Putting information in the certificate is rather limited (and
>     anyway, no one asserts that data, since we're not using a PKI).
>     Instead, getting the information from the WebID profile document
>     (aka the FOAF file), you'll be able to populate more things
>     automatically in the merchant sites, not only the e-mail address but
>     perhaps the full name, possibly address, etc.
> Thing is, if the whole wrap is going to be it's there in the X.509
> specification, so use it if you want, but what you should do is get the
> email from a FOAF file, (which err, you probably won't find it there),
> then, no, we don't get the benefit of instant motivation to
> implement.

That is an interesting question indeed.
We haven't talked about FOAF in the specification, but a lot of the 
interesting data will be using the FOAF vocabulary.

There are two options:
  (1) We stick to the authentication part in this spec (so we only talk 
about the cert ontology).
  (2) In addition to 1, we build in the dependence on FOAF.

I'm more in favour of (1).
However, mentioning FOAF is indeed important. FOAF helps you say things 
about that WebID, it's not really about verifying the WebID... unless we 
do 3rd party assertions (but again, they need not be made by a 
foaf:Agent, although that's likely).

Again, FOAF already exists, without WebID, so people who will want to 
support a WebID are de-facto likely to know how to get what they want 
using the FOAF vocabulary.

Perhaps a non-normative note to say that people should say interesting 
stuff about their WebID using widespread vocabularies and that services 
will do better if they can understand those widespread vocabularies. I 
think re-using established vocabularies is one of the key principles to 
make the semantic web work anyway.
Anyone willing to describe information about people (I mean what's in 
FOAF: a bit of personal data and links to other people/organisations) 
using semantic web technology, will have come across FOAF I think.
Mentioning it in the spec is fine, but if they don't use FOAF for that 
sort of things, they'll probably have missed the point of the semantic 
web altogether, I think.
Talking about FOAF would fit really well in the background and example 
sections, but that's not really the normative part of the authentication 
protocol, I think (unless we also want to consider getting key info from 
friends to see if we know one).

> So then it becomes important what we say about
> subjectAltName (rfc822Name).   What if we provide an informative section
> which reinforces that certificates can be issued with an email address
> in the subjectAltName (rfc822Name)  field, and that the client should be
> informed that choosing to transmit the certificate to a server provides
> their email address to that server.

On 16/07/2010 23:01, Jiří Procházka wrote:
> I think putting any extra stuff in the cert than FOAF Agent URI(s) would
> make WebID unnecessarily complex (please KISS), also maybe even
> competing with the linked data aspect - any extra info should be in the
> RDF fetched from the URI.
> TLS is just convenient technology which fits the purpose coincidentally,
> not core part.

+1: the X.509 certificate just happens to be a convenient container.

Best wishes,


More information about the foaf-protocols mailing list