Re: New WebID spec on identity.

On Mon, Nov 19, 2012 at 11:49 AM, 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 <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<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.
>

You're going back on what we've agreed on in the last teleconf. The
consensus was that all NEW WebIDs MUST contain the hash, but verifiers
should not fault on hashless ones. It's been marked in red as an issue, but
it's difficult to spot at this point (no HTML markup when looking at the hg
raw file).


> 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.
>

Maybe this is something we should discuss further. How do we process
WebIDs? We could open an issue for it.


> 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


Facebook has hash URIs. A _billion_ hash URIs.


>
>
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<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>