Re: New WebID spec on identity.

On 19 November 2012 21:36, Ted Thibodeau Jr <tthibodeau@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
>
>
> *** 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.
>

I've been wondering for some time now what you gain from the 303 dance.

Sorry if I've missed something, but could you go over the benefits of
having, say

http://graph.facebook.com/dave

over

http://graph.facebook.com/dave#



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