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

Re: WebID equivalence

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 3 Jan 2012 13:22:22 +0100
Cc: public-xg-webid@w3.org
Message-Id: <CA778345-76F2-4708-8C3E-C6F626E611BA@bblfish.net>
To: Kingsley Idehen <kidehen@openlinksw.com>

On 3 Jan 2012, at 12:52, Kingsley Idehen wrote:

> On 1/3/12 4:06 AM, Henry Story wrote:
>>> These matters (IMHO) have less to do with the WebID spec. They are field usage matters. You don't need to look far as they pop up in the Authorization realm.
>>> >  >  Look at this:
>>> >  Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>>> >                  OU=FreeSoft,CN=www.freesoft.org/emailAddress=baccala@freesoft.org
>>> >  >  Where's the rule that states: we couldn't have a resource URL where you have:www.freesoft.org  and a mailto: URI that resolves as per hammer stack. In both cases they resolve to description oriented directed graphs. BTW -- the DN is just a compound key.
>>> >  >  Where's the rule that states that in the SAN we can have a composite key comprised of multiple URIs. Where the URIs in question are the Subjects of the description graphs exposed by Addresses in the DN?
>> Not only is there no rule against it, but the spec says you can have multiple SANs.  So I must be misunderstanding what you are saying. Can you provide a simple example?
> I am saying, the Subject of the cert. as outlined above is basically represented by a compound key comprised of the elements above. The Use of URLs and Email Addresses are crystal clear re. meaning i.e., they are addresses. Thus, you have Address slots in place for accessing data.
> Then in the SAN you have Names (not Addresses) and via Linked Data you can make these de-referencable names.
> End product is you have two routes to the description graphs. You also have natural accommodation for asserting co-reference when a SAN has > 1 URI base Names serving as WebIDs.

I see that you are saying there can be multiple SAN's. That's in fact specified in the X509 spec, and our spec, so there is nothing new here.

> The ultimate example of this will come from what Peter is trying to do with SPARQL URLs once he discovers the power of CONSTRUCT queries. The SPARQL Construct URL can go in the CN. It will basically describe at least 1 URI in SAN with equivalence relations for the others.
> What is an important point to consider re. WebID is what should be done when the CN contains URLs?

A Common Name is not meant to be a URL so there is nothing to do there, unless you want to do screen scraping or detective work.

> What I describe above reduces some of the Linked Data nuance burden for verifiers since you could even have URNs in SAN and their description graph Addresses in the CN.  Thus, Names do not necessarily have to be de-referencable if the CN has an Address (pointer) to a description graph that describes at least one of the Names in SAN.

And what is that supposed to bring in addition to the URI being in the SAN?

> Note: Hammer Stack covers the issue re. Email Addresses.

Still no idea what the use case is. I suppose we'll find out when you have worked out what Peter Williams thinks he wants. 

Earlier you seemed to be suggesting - and that is what made me start this separate thread - something about publishing profile documents at multiple places and asserting owl:sameAs equivalence relations between them. Well one of your examples was that you had 2 SANs and this could be useful when loosing an account. Perhaps you can try to tie the points above to the use case with an example of what is published where, what happens and what you can prove by doing this.


> -- 
> Regards,
> 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

Social Web Architect
Received on Tuesday, 3 January 2012 12:23:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:29 UTC