W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: WebID equivalence

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 04 Jan 2012 09:03:57 -0500
Message-ID: <4F045C4D.2000209@openlinksw.com>
To: Mo McRoberts <mo.mcroberts@bbc.co.uk>
CC: Henry Story <henry.story@bblfish.net>, public-xg-webid@w3.org
On 1/4/12 6:39 AM, Mo McRoberts wrote:
> Some specific notes:
>>> 1. Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
> A server certificate, where the FQDN carried in the CN is used as part of a *matching* process.
>>> 2. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>>                OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
> (For the avoidance of doubt, note that CN and emailAddress are two separate attributes, it's just that the syntax for printing them is sometimes a little confusing).

Yes, I am very aware of that.
> emailAddress is an e-mail address, that’s a given. *Typically* it’s there in client certs because the issuer only has the fact that the certificate requestor was able to click a 'verify e-mail address' link as the sole piece of verified (and so differentiating) information.

Yes, I am very aware of that too.

> Putting a domain name in the CN in a client certificate serves no practical purpose beyond advertising to people and making certificate-selection dialogs even more confusing than they are anyway.

But I am not advocating a domain name. I am suggesting the use of an 
http: scheme URL. Or at least inferring that the entry is an http: 
scheme URL just as the Email Address can be inferred to be a mailto: 
scheme URL.

>   It’s still just an arbitrary label which happens to contain a domain name. More often than not where domain names DO appear in client cert CNs, they're not a domain name belonging to the subject.

They are implicitly associated with the subject.

>>> 3. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>>                OU=FreeSoft, CN=MyOrganization Literal Label/emailAddress=baccala@freesoft.org .
> Same as above.
> And yes, you can quite cheerfully attempt to do WebFinger lookups on an emailAddress attribute in a DN, or do them on an acct: URI in a subjectAlternativeName, or do them on an rfc822Address in a subjectAlternativeName.

Yes, but my point remains this:

de-referencable HTTP based Names are a luxury. This is a fact that 
manifests ultimately once you engage Linked Data exploitation at 
industry levels. This luxury aspect of Linked Data is what could be 
potentially addressed by making explicit use of URLs (Addresses) and 
URNs (Names).

The Subject Alternative Name slot is for URI based Names. Linked Data 
mandates that said names are de-referencable, a powerful feature that's 
also a pragmatic luxury. In addition, you ultimately hit the 
httpRange-14 issue with implementors of verifiers and publishers of 
profiles or identity declarations.

>   There's no question about that; it doesn't appear in the spec, and unless some WebFinger-providing service starts offering the ability to link through to some FOAF which can contain a cert:RSAPublicKey, I can't see that there's a hugely compelling case for it to, either.

My point is that you can make mailto: scheme URI resolve via Webfinger 
(we've achieved that since inception of WebFinger and Fingerpoint). The 
act of resolution is also consistent with the role of Address. It's 

> What's (still) not clear is why you'd bother exposing your e-mail address to the world in your certificate when you can have a URI to your WebID profile anyway.

Because, and I've said this to you before in a prior post, there are 
times when you need to remember Names. There are times when lookups will 
fail or be unavailable to you. Typical example: when constructing WebID 
ACLs for a resource (e.g. a photo you want to share with members of a 
group/circle). Everyone has been taught to remember and use Email 
Addresses as Identifiers of the Name variety.

>   It’s definitely not clear why you’d want to bother exposing implementation details (i.e., your WebID profile can be dereferenced using a URI of some sort carried within the cert) to selection UIs and the like by putting them in the CN.

What I am suggesting, and this really is this:

Have an intuitive Address as the pointer to the mirrored claim graph in 
the idp space.
Have Names (which do not have to be de-referencable) in the Subject 
Alternative Name slot.

This allows people much more flexibility when it comes to publishing 
claims since the *luxury* burden of Linked Data de-referencable URIs is 
reduced. You don't have the intuition cost. You don't have the actual 
deployment costs. The coupling of the mirrored claims graph (or profile 
document) becomes very loose and friendly to Web Developers and Users 
that aren't of the profiles: Semantic Web or Linked Data developer.

> Kingsley, you’ve said that you perceive a “bias towards HTTP”, and that’s probably *implicitly* true to an extent: while you could do a lookup against a public LDAP server instead (it's what PGP does, after all), do you not think that most people will end up publishing their profile document via HTTP?

They more than likely would, but we don't have to force them to do that 
per se. The bigger problem, as outlined above, is that Linked Data 
deployment is nuance laced and basically a luxury item for the majority. 
This matter re. Linked Data isn't new, what's interesting right now is 
that in this particular use-case there is an opportunity to alleviate 
this cost.
> And thus, any additional indirection — which isn’t by any means prohibited by the spec — amounts additional complication which really just has novelty value right now… or is there some really compelling justification?

I hope I've explained the justification above. Ultimately, there is a 
Linked Data challenge for publishers re. de-referencable HTTP URI based 
Names. It's this very problem that Hammer Stack folks have addressed via 
Webfinger as a vehicle for de-referencable mailto: and acct: scheme 
URIs. Even in the Linked Data realm, you have the emergence of the 
.well-known/host-meta resource as mechanism alleviating costs associated 
with Linked Data deployment.

If for whatever reasons you still don't accept or may understand what I 
am trying to articulate re. Linked Data deployment costs and challenges. 
I strongly encourage Dan Brickley to step in and explain in his own 
words. He has experienced these challenges first hand during the course 
of his FOAF endeavors, over the years.
> M.



Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Wednesday, 4 January 2012 14:05:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC