Re: what are claims mirrors?

There is evidence that the emails will now stop within 24h. So let me try for a good close, again.

I see folks attempting to put semantics on multiple San entries. This differs from having a collection of independent entries, addressing multiple browsers and limits on key/cert store sharing.

The only rationale I've seen for having any semantic beyond collection is captured in the thread that wanted the different values referencing the same entity, but using different descriptors.

In my case, kingsleys crawling of my blogspot website cum rss feed does more than cache my profile - the lead blog post bearing my webid profile. It makes a descriptor (in fact several). It describes more than I state in my profile graph, augmenting the description with relations drawn from relations in the profile documents header (links and metas). This is a consequence of my using rdfa (embedded in XHTML) that enables such to happen.

Thus the graph in linked data land says more than the graph one might reference on my blog post. It's a superset. It's a very useful superset, moreover.

In much the same way that the Openid.delegation relation "linked up" the profile hosted on the page hosting the delegation to the profile maintained by the Idp, I'm wanting webid to have similar semantic when linking up my rdfa blog post (and it's 5line graph) with my graph in a particular "data space" that I have nominated as authoritative - particularly as such concerns the profiles' now driving a security protocol exploiting such semantics: Openid (v2) in its delegation flow (specifically)

I explored claim mirroring. Assuming that multiple San Uris means owl:sameas between each element and also the certificate document that holds these equivalency statements berween entities, I expect to see such mirrored - in the profile documents. I expect to see the owl:sameAs bidirectional relations in the profiles' graphs (and a sameAs statement to the cert uri too, using the data uri scheme). This is the "mirroring".

Finally in the openid trial I mounted, only 1 claim was further mirrored to my relying party site (upon Completion of the openid protocol run). This was the webid uri actually used by the webid validator from those available in the cert I presented. This claim became the basis of a web session. It functioned as the nameidentifier claim functioned from 3 other classes of Idp (Facebook w/connect, live w/oauth2, google w/Openid). Essentially it added openlinksw w/webid to my site (and was almost production ready).

As no one agreed it had any value I eliminated it all, since it appeared to be going nowhere. I never showed it (publicly) landing on a production realty site (rather than a model site).

I found the linked data story aligned with the core webid validation agent story quite compelling. It made the horrendous complexity of the semantic web approach to validating a client cert seem almost worth it. There was real value being identified (beyond a sophistic dialog for post grads).

Now help me close out of this thread (and working group) on a nice even tone. These topics will go forward into the community group, and hopefully flower. The semantic web looks like it has something unique to offer in the world of trust management because it's so hard to pin down precisely what is meant. This seems to be exactly what is required since codification seems to be the root problem when scaling trust. It needs to be semantically amorphous yet formalish, and this project seems to have great potential there - and can thus make a breakthrough denied other attempts that relied on rigor - the very thing that really appears to precludes a breakthru on the specific topic of trust.

Sent from my iPhone

On Jan 16, 2012, at 4:06 PM, "Henry Story" <henry.story@bblfish.net> wrote:

> 
> On 17 Jan 2012, at 00:27, Kingsley Idehen wrote:
> 
>> On 1/16/12 4:48 PM, Henry Story wrote:
>>> On 16 Jan 2012, at 21:46, Kingsley Idehen wrote:
>>> 
>>>> On 1/16/12 2:45 PM, Henry Story wrote:
>>> [snip]
>>>> We are all endowed with the ability to describe the same concepts slightly differently based, on our backgrounds and target audiences. This capability ultimately makes the end product richer, especially when it brings others to the fold that would erstwhile not make obvious connections.
>>> Yes, but if people keep defining new words every few minutes, then we end up just confusing each other.
>> 
>> But that really isn't the case. Terminology is how one communicates to a given audience. Terminology and audiences go hand in hand. Semantic Web and Linked Data parlance is quite esoteric when you factor in the broader broader user and developer profiles. Sticking to esoteric terminology under all circumstances leads to the "too provincial" stigma that already undermines most things associated with "The Semantic Web".
>> 
>> BTW - Why did you build a Babel Fish as opposed to asking the world to coalesce around specific English words and phrases?
> 
> I don't think you have any idea how much time and work it took to put the tools for BabelFish together. The company called Systran who wrote the software started in the 60ies writing translation machines. The translation produced by the BabelFish was not that good either, which is why I called in BabelFish, so that people would not take it too seriously. Anyway the AltaVista babel fish appeared 30 years after the company had started.
> 
>> [snip]
>>> Here we are trying to work out how to integrate new ideas and make sure that things can work together, to write a good document so that other communities can join easily.
>>> 
>>> And it helps me to understand what a claim mirror may be when I am following a conversation here.
>>> 
>>> As far as I see you have the following triples
>>> 
>>> <http://joe.example/#joe>  cert:key key ;
>>>           owl:sameAs<http://other.place/som/doc#123>  .
>>> 
>>> and exactly the same triples are published:
>>> 
>>> 1. in the corresponding certificate - but with ASN.1 format
>>> 2. at<http://joe.example/>
>>>   or whatever is the :sense of<http://joe.example/#joe>
>>> 3. at<http://other.place/som/doc>
>>>   or whatever is the :sense of<http://other.place/som/doc#123>
>>> 
>>> Is that correct?
>> 
>> 
>> There are a set of claims in an x.509 certificate (expressed in ASN.1). There are set of claims in a Profile Document (expressed in RDF). Semantically, they are mirrors i.e., they hold equivalent claims discernible to humans and machines.
> 
> Ok, so I take you to be agreeing with me that the above example is the prototype  example of the mirrored claims that interest us. Your prototype would be with only one SAN in the certificate, Peter Williams would be with 2 SANs in the certificate. But we get the gist right? If we start off with the X509 certificate with n Subject Alternative NAmes, then the mirrored claims idea is that each SAN's :sense documents, i.e.. the WebID profile for that WebID, publish the relation to the public key and the owl:sameAs relations to the other SANs. IT is not really a full mirror, as there are a lot of things in the X509 certificate that are not published in the other formats. 
> 
> We should add this to the Wiki then
>  http://www.w3.org/2005/Incubator/webid/wiki/Terminology
> 
> Perhaps this would then be the minimum procedure we need. When people come up with new terminology, or when it is not clear, we should add the word to the wiki with some definitions and examples.
> 
> Also it would be good to learn to get to these definitions quickly.
> 
> Henry
> 
>

Received on Tuesday, 17 January 2012 00:58:39 UTC