Re: New WebID spec on identity.

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.

-- 

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