Re: New WebID spec on identity.

On 19 Nov 2012, at 17:49, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 11/19/12 10:23 AM, Henry Story wrote:
>> 
>> I have updated the picture and put Tim Berners Lee as the example.
>> I think it is really important to have a real person be the reference of the WebID for explanatory reasons. People need to be able to do an http GET on a real URI and see that it actually does work. They must also know that the person in the real world exists, because otherwise we have to create a fictional character, and there will be a tendency for that fictional character to be thought of as just a diagrammatic person - making it difficult to help people distinguish between symbolic elements and real elements.
>> 
>> Henry
> 
> Now that we have the depiction in place, it's really important to use this context to explain *indirection*.
> 
> Note: the URIs in this document should be user agent accessible. Right now, I can't access TimBL's WebID: <http://www.w3.org/People/Berners-Lee/card#i> as shown via: http://linkeddata.uriburner.com/about/html/https/dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html . If done right, his URI/WebID would be exposed a value of sioc:links_to property.
> 
> Back to indirection.
> When used in the Linked Data context, a hash URI uses *implicit* indirection to enable critical look-up association between a URI that denotes an entity and the URL used to locate said entity's description document. The same thing happens re. DBpedia's hashless URIs, but the indirection is *explicit* and requires the user agent to handle 303 redirection to the URL of the entity description document. This is all about abstraction and data access by reference. While the aforementioned pattern is old, HTTP really brings it to the masses in manner that's a lot easier to appreciate.
> 
> An Identity Provider (the issuer of X.509 certificates) SHOULD be able to mint hash or hashless HTTP URIs re. WebIDs placed in the SAN slot of an X.509 certificate. That's the pattern in broad use today re. Linked Data, as exemplified by most of the LOD cloud.
> 
> An Identity Verifier (what performs WebID authentication e.g., over TLS) needs to be able to simply de-reference an HTTP URI (as other user agents do e.g., browsers, curl etc.) . Having them only look for hash based HTTP URIs is an unnecessary limitation.
> 
> A profile document publisher (who doesn't have to be an IDP per se.) SHOULD be encouraged to use hash based HTTP URIs to denote entities described by its profile documents since this style of URI inherits the deployment cost effectiveness associated with *implicit* indirection re., Linked Data deployed using hash HTTP URIs.
> 
> All:
> 
> These nuances are important. The thing to be prevented, above all else, is having WebID over TLS based verifiers coded to parse for hash based HTTP URIs instead of HTTP URIs. This also means not treating 303 as a fault since that's all about *explicit* redirection which can be used for the very indirection required by the Linked Data concept.
> 
> The performance headache (real or perceived) shouldn't be the basis for making this kind of decision.
> 
> Examples of the importance of these issues re. interoperability:
> 
> 1. hashless URIs enable simply integration of Facebook, Twitter, LinkedIn, and many other Web 2.0 data spaces into Linked Data -- today, any Facebook, LinkedIn, Twitter etc. user can acquire a fully functional WebID that verifies with the WebID authentication protocol via the click of a button
> 
> 2. there are already numerous WebIDs out in the field that are hashless .
> 
> The cost of hash specificity is too high and the reward too low. There is a middle line that will work fine for everyone.

For this you need to put up an issue in the issue tracker

  http://www.w3.org/2005/Incubator/webid/track/

in the product WebID-definition. Point to this e-mail for details.


> 
> -- 
> 
> 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 Monday, 19 November 2012 17:02:26 UTC