Re: New WebID spec on identity.

On Mon, Nov 19, 2012 at 3:36 PM, 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.
>
>
Yes there was. If you go over the minutes again, you will see that we all
agreed that "WebID verifiers MUST not fail on hashless URIs, they MAY flag
"there may be a performance (or other) burden here". If you look at the
current proposed spec, you will see this has been added to "The HTTP URI"
section, albeit as an issue. (again, the issue markup is does now show up
yet, but you can look at the source code for the document).

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.
>
>
According to the new spec, they are. I'm not sure though how _valid_ they
are from a URI perspective, since there is nothing after the #.


>
> >>> 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.
>
>
There was also this proposal: "Proposal: put the 303 issue in red in the
spec" which I think most people agreed on. This has been included in the
new draft.

Andrei


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