Re: WebID equivalence

On 1/3/12 7:22 AM, Henry Story wrote:
>> 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.

So you are claiming this is wrong then?

  Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
                  OU=FreeSoft,CN=www.freesoft.org/emailAddress=baccala@freesoft.org


>
>> >  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?

The very same thing that the Hammer Stack brings to URIs. The ability to 
lax the de-reference expectations. Basically, to understand that 
de-referencable Names are a nuance laced luxury in the grand scheme of 
things. Thus, why not take a more relaxed approach that gets you the 
same results plus added intuition.

Use Addresses as pointers to descriptor resources.
Use Names as the description subjects.

An X.509 Cert. caters for this looser coupling of a subject and its 
descriptor resource. You would be quite amazed how much simpler matters 
will become should this be considered, post full understanding.

>
>> >  
>> >  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.

I know what Peter wants. He wants to do what is known as Data 
Programmability. Basically, he wants to make everything happen 
dynamically via REST, to the degree possible. In doing so, he is never 
encumbered by points of control on the InterWeb.

It boils down to:

1. a URL to a descriptor resource -- he can make that with a SPARQL 
CONSTRUCT URL (an shorten it for aesthetic purposes using a URL shortener)
2. Names in SAN that are subjects of the description
3. Verifiers that de-reference Addresses, then lookup relations based on 
the Names in SAN.

>
> 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.

You can publish one graph with many owl:sameAs claims.

> 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.

The very first test of WebID for us was ACLs. When I loose control over 
a URI I don't need all the ACLs to be redone. I should be able to fix 
that in my personal idp space and make a new Cert. that points to the 
same space leaving the reasoning capability of a verifier to do the rest.

I have a boat load of certificates (with or without entries in SAN) that 
will pass verification with our verifier courtesy of reasoning. That's 
been so since we first implemented WebID. I am not mandating this of all 
verifiers, but as I've stated repeatedly, these issues matter.
>
> Henry
>
>
>


-- 

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

Received on Tuesday, 3 January 2012 14:06:49 UTC