Re: WebID equivalence

On 2 Jan 2012, at 20:16, Kingsley Idehen wrote:

> On 1/2/12 5:36 AM, Henry Story wrote:
>>> On 1/1/12 11:38 AM, Mo McRoberts wrote:
>>>> On 31 Dec 2011, at 17:52, Kingsley Idehen wrote:
>>>> 
>>>>>> Now, because URI-A's document can't be parsed, there's no way to verify that it does contain the triples which confirm the relationship between it as a WebID URI and the WebID certificate, *however* a consumer can look for triples describing URI-A in the document referring to it retrieved from URI-B: in this case, it finds some, and can process them as being equivalent to as if they were asserted about URI-B, but what it cannot do is state that URI-A is an identifier for the certificate-holder.
>>>>> Identifier equivalence has been asserted in a signed claim via the use of multiple URIs in a Certs. SAN. The effect here is that we have synonyms so the public key associated with URI-B is now also a relation with URI-A. The fact that we can't make a union of all the data the one could de-reference via URI-A and URI-B doesn't matter re. this kind of equivalence and the resulting assurance.
>>>> The problem here isn't the data. Getting the union set of triples is fine.
>>> You don't need to get a union of triples. You just need triples that describe any URI in the owl:sameAs relation.
>>> 
>>>>  The problem here is what you consider the URI to be for the certificate holder. As you can't retrieve and process the data for URI-A, you can't treat that URI as belonging to the holder.
>>> The Certificate Identifies a Subject. The SAN is a slot for alternative Names of said subject. A composite of alternative names is a signed equivalence claim that may or may not be mirrored in idp space.
>>>> It's a subtle point, but it's an important one when you're dealing with synonyms.
>>> <URIA>  owl:sameAs<URIB>  means that both URIs share a co-referent. Thus, what goes for one (e.g., public key association) goes for the other, if if the evidence emerges from triples that describe either<URIA>  or<URIB>.  This is all about equivalence by name. You can also have equivalence by values, and you require an IFP predicate in the relation for that. All of this is quite easy to demonstrate.
>> Yes, you are right a = b means that a refers to the same thing as b.
>> But that is not the problem that needs to be addressed. The problem is whether the claim is true, or likely to be true. Do you believe what URIA-Profile-Doc says about URIA? Well you can believe what it says about terms it defines in that document, since it is master of the terms it defines there. That is why WebID works.
>> 
>> But is the assertion of identity it makes in that document true, when those assertion cross namespaces? That is something that can be doubted and over which there can be disagreement, and so to the degree that it can be doubted so you have a problem of trust. It is the problem of trust that we are dealing with here, which is a layer above the linked data cake.
> 
> Of course I understand the layer above the hyperlink driven  linked data structure (aka Linked Data). I am referring to assurance that comes from the verification of the claim itself. What is WebID if it simply about the verification of a single claim?
> 
> Why do we have compound and composite keys in the DBMS realm?
> 
> Why do we forget that URIs are superclasses of URLs. Thus, you can really put compound and composite keys to use inside an X.509 cert. and up the ante re. assurances that can be derived from the WebID protocol?
> 
> 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 not necessarily pushing for this to increase complexity of the simple WebID spec. But in reality, esp. re., matters that are of interest to Peter (and many of similar profile across enterprises), this is where the action is going to be and its all doable via SPARQL and Linked Data oriented resources.
> 
> WebID is for all intents and purposes a simple exploitation of what's possible. That's all fine. But in reality (industry level) its quite a distance away for the nirvana.
> 
> The nirvana is about revisiting and understanding DBMS technology and what its always provided once you can front said technology with a declarative query language. Especially, one where data access protocol and data representation formats are distinct, as delivered by SPARQL.
> 
> We are basically exploiting deductive DBMS technology which failed last time around re. Datalog due to the non existence of today ubiquitous InterWeb and distributed data objects.
> 
> We just need to be able to sign claims and then combine that with the what's already delivered to use re. X.500 names re. the ability to exploit compound and composite keys.
> 
> URI abstraction plays extremely well here, but this will play out on the commercial product implementation front (e.g., via RWW apps) and less so re. the WebID spec goals etc..
> 
> 
> Kingsley
> 
>> 
>> Henry
>> 
>> 
>> 
>>>> M.
>>>> 
>>> 
>>> -- 
>>> 
>>> 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
>> 
> 
> 
> -- 
> 
> 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
http://bblfish.net/

Received on Tuesday, 3 January 2012 09:06:56 UTC