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

Re: what are claims mirrors?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 16 Jan 2012 09:20:38 -0500
Message-ID: <4F143236.4060206@openlinksw.com>
To: Henry Story <henry.story@bblfish.net>
CC: public-xg-webid@w3.org
On 1/16/12 8:47 AM, Henry Story wrote:
> On 16 Jan 2012, at 13:11, Kingsley Idehen wrote:
>
>> On 1/16/12 6:20 AM, Henry Story wrote:
>>> Kingsley keeps speaking of "Claims mirrors" in support of his arguments. What are they? How do they work?
>>>
>>> Henry
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>>
>> I mean the graph that is created in the IdP space.
> So you mean the WebID Profile, as specified in
> http://www.w3.org/2005/Incubator/webid/spec/#publishing-the-webid-profile-document
> ?
>
> In that illustration it would be<https://bob.example/profile>  ?

Yes.

It holds a mirror of a claims that exists elsewhere. Said place gets you 
to the profile. In the case of WebID by de-referencing SAN.

The relations in the profile mirror relations in an x.509 certificate, 
semantically.

>
> What is the IDP in this scenario? IDP is a word that comes from OpenId. In OpenID the IDP is the service one links to from one's profile page. But in WebID we don't have an IDP in that sense.

The place where the Profile graph resides or is accessible from.


>
>
>> It holds a mirror of claims in the x.509 certificate in a local key store.
> You mean the WebID Profile is mirroring the claims in the X509 certificate?
>
>> We make certificates and persist them to a local keystore. We then make a set of claims via triples in Idp oriented data space that mirrors whats in the local key store.
> So given that WebID does not require an IdP, it is even more mysterious what an "IDP oriented dataspace" is.

So we fix the mystery. The profile document that's accessed by URI 
de-reference (which ultimately boils down to a resource at a location 
somewhere on a network e.g. WWW).

btw - you seem to forget that "profile document" is sometimes 
misunderstood by certain user, developer, plumber (people to connect 
protocols together with zero or minimal coding) profiles. Remember how 
the BrowserID folks so the profile document requirement of WebID as a 
privacy issue?

>
>> If you have a relation associating a subject with a public key in a certificate that resides in your local store, having the same relation in your idp oriented data space via triples implies a mirror.
> In that case can we just use the word from the spec namely the WebID Profile?

Depends on your audience. My audience is a little more varied than 
yours, so please bear this in mind when I am communicating. We have 
quite different world views and target audiences.

My audience profiles:

1. people who could use WebID having worked on solutions in the past 
e.g. OpenID, OAuth (users, developers, and plumbers)
2. people who understand graphs and don't see RDF as the sole option for 
working with directed graphs e.g., Microformats and Microdata users, 
developers, and plumbers (who IMHO will help WebID adoption).


>
>> I hope that clears up the matter of "mirrored claims" re. WebID.
>>
>> btw -- some Idp spaces will mirror other claims too e.g. fingerprints, some can even hold a complete carbon copy of the x.509 certificate.
>>
>>
>> -- 
>>
>> 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/
>
>


-- 

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 Monday, 16 January 2012 14:21:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 January 2012 14:21:07 GMT