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


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


** On Nov 19, 2012, at 12:00 PM, Andrei SAMBRA wrote:
>> 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).

That's not an accurate description of the last telecon.

There was no such consensus.

There was a majority opinion, but there was some waffling in
that majority, and even TimBL conceded (or so I heard, quietly 
spoken, and sadly not captured in the minutes which tend to be 
cursory at best when discussions get particularly involved) that 
the hash need not be *required* in the *conceptual* spec -- even 
if it were to be required in (one of) the (1.0) *protocol(s)*.

The WebID *definition* in the *conceptual* spec, need not 
specify, need not require, the hash.  

The WebID *definition* should simply specify a HTTP URI.  

(We've conceded that because of the unfortunate specificity of 
"Web" in "WebID", that it may specify an "HTTP URI", even though
we strongly believe that this is a needless limitation, and will
force development of another standard because the requirement of
backward compatibility will force all future iterations of WebID
to have this same limitation.)



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

Please note that those hash URIs are not WebIDs.


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

* On Nov 19, 2012, at 12:01 PM, Henry Story wrote:
> 
> 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.

ISSUE-69 exists for this purpose.

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

The name/description was short-handed to get it into place before
being forgotten.  To my eyes, your (Henry's) "additional notes" in
that issue reflect less of what actually happened in the telecon, 
and more of what your interpretation of the conversation was.

There are strong arguments for both hashed and hashless URIs.
I see this these arguments as reason to permit both, and to 
include some discussion of the strengths and weaknesses of each
in the documents we produce -- including both the costs of lookup 
on 3xx redirection (both client- and server-side) and the increased 
flexibility that may be provided by such explicit indirection, vs
the lower cost of lookup without 3xx redirection and the limited
flexibility mandated by this implicit indirection.


Be seeing you,

Ted


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers