Re: The Payment Identity Problem

On 17 July 2014 05:48, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 06/26/2014 11:55 PM, Melvin Carvalho wrote:
> > Regarding Identity (as opposed to authentication, and user
> > experience)
> >
> > Could you sum up your objections to the WebID spec (and I dont mean
> > WebID+TLS)
> >
> > As far as I can see there are 2 sticking points:
>
> My responses here are with my chair hat off. They're general
> observations over the past 7 years of Linked Data use and adoption
> failures.
>
> > 1. You object to the use of the Term Agent, which is the parent class
> > of Person
>
> The terminology, while important, is of little concern to me. I'm sure
> we can come up with the right terminology once we scope the problem
> correctly.
>
> > 2. You object to mandatory serialization of turtle
>
> Yes, I'd rather mandate a single serialization that has strong adoption
> and that supports graph names. JSON-LD is the only one that fits the
> bill, imho. Alternative serializations like NQuads, TURTLE, etc. are
> just fine. To be clear, my objection to TURTLE has to do with technical
> issues as well as adoption issues. It's not that I don't like TURTLE,
> it's that it isn't technically capable of doing certain things that
> we'll need to do (namely, cleanly signing provenance information).
>
> > Fragmentation will be an influence on whether both efforts succeed or
> > fail.
>
> I have the same concerns.
>
> > Is there anything else that you view as a show stopper.  Is there
> > any room for compromise?
>
> There is certainly always room for compromise. Here's a quick review of
> the spec and my concerns:
>
> http://www.w3.org/2005/Incubator/webid/spec/identity/
>
> * The WebID group's leadership and lack of progress over 7+ years. I
>   personally feel that the groups leadership is out of touch with
>   business requirements for this technology and is not capable of
>   bringing big players to the table. To provide a counter example,
>   we've only been at the Identity Credentials stuff for a little under
>   a year and we already have strong interest and deep contacts in the
>   US Federal Reserve, World Bank, large education companies, the
>   United Nations' Internet Governance area, and a number of other
>   large players in the identity and education ecosystem.
>
> * Dependence on TURTLE and RDFa. I suggest removal of both as
>   requirements, allowing developers to optionally encode information
>   using those technologies. The only MUST should be JSON-LD.
>
> * Reliance on FOAF. Let it die, use schema.org.
>
> * Dependence on hash URIs and 303 redirects. Most developers won't care
>   to understand why 303s exist. Hash URIs, while useful, shouldn't be
>   used in the spec because you have to then get into why you "should"
>   use them in the first place. Applications can reason on whether
>   something is a document or a referral to a concept via other means.
>   Stay away from the HTTP Range stuff, it complicates the solution.
>
> * TimBL fandom. Please take all references to Tim Berners-Lee out of
>   the specification, they're distracting. Use a generic example.
>

I did smile to myself when I went and checked the 'generic example' used in
JSON LD:

Example 1: Sample JSON document
{
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

:)


>
> * There is no mechanism described that provides a way to express
>   information that has been digitally signed by 3rd parties. This is
>   vital to the Web Payments and High-stakes Credentials use cases.
>   I'm fine if a spec, like Identity Credentials, is layered on top
>   to provide the functionality.
>
> * re: Privacy. The only privacy that the mechanism provides via
>   WebACL is protection from who can read/write the information. There is
>   no pervasive monitoring protection against identity providers.
>   Identity providers can track your every move. To provide real
>   privacy and tracking protection, you need more than just WebACL.
>
> If you strip/change much of the stuff above, you're left with a 1-2 page
> document that doesn't do much other than set the groundwork for the
> really important stuff (setting and getting high-stakes credentials in a
> privacy-protecting / anti-tracking manner). Personally, I'd rather fold
> those 1-2 pages into a more comprehensive specification than require the
> reader to bounce between a 1-2 page document and the spec (Identity
> Credentials) that actually does something useful.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Marathonic Dawn of Web Payments
> http://manu.sporny.org/2014/dawn-of-web-payments/
>
>