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

Thanks for the feedback, response in line, which are my own personal
views.  I feel some issues are bigger than others, let me elaborate.


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

Great!


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

Legitimate concern.  Perhaps we need to get to the bottom of this technical
issue on another thread.


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

+1

The identity was decoupled from the WebID+TLS part last year, as TLS was
perceived to be a barrier for many.  I agree there has been a lack of
leadership, e.g. it took 6 months to get the spec published.  We do lack
resources also, so working together I would see as advantageous.


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

There's no dependence on RDFa, just an example.

Turtle is the only mandated serialization, but others are acceptable.
There is an open discussion going on about turtle vs json ld -- you're very
welcome to join the conversation here.


>
> * Reliance on FOAF. Let it die, use schema.org.
>

FOAF is not mandated, just used in the examples.

The examples could be changed.  I dont see any technical reasons this needs
to be a show stopper.


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

What you call HTTP range stuff, others might call awww or 5 star linked
data.  The idea here is that the content is separable from the medium.  I
know it's complicated, but the web is predicated on global variables and
pointers.  Working with global variables and pointers effectively is
difficult.

There is no dependence of hash URIs.  Timbl was in favour of using hash
URIs only, his comment, "because redirects are a pain".  I have to agree.
But we voted to allow any type of 5 star linked data in the end.

How are you going to be compliant with awww and have 5 star linked data
without using hash URIs or using 303s?

When you say that applications can reason on whether something is a
document or a concept, what does this mean.  You can get away with this on
the social web.  But this becomes important is when sending money.  Because
if one application thinks your sending money to a person, and one thinks
your sending to a document it's going to get lost.

>
>
> * TimBL fandom. Please take all references to Tim Berners-Lee out of
>   the specification, they're distracting. Use a generic example.
>

Do you realize that timbl is an author of this spec?  By all means it's
possible to change the examples.  They are just examples.  I dont see that
should be a show stopper.


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

Out of scope, can be layered on top.  Again this is just an example.


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

Out of scope, can be layered on top.  I think the LDP working group will
move onto this after LDP is complete.


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

This spec was always intended to be 1-2 pages, according to timbl.  Henry
Story pushed back on this because he, like you, didnt see the point of a 2
page spec.

However, identity is such a difficult topic, not because it's technical,
but rather, because everyone (understandably) has their own opinion, based
on experience.

In "weaving the web" Tim writes that "the web is more a social invention
than a technical one".  He's laid the ground work of how this could be
achieved in this spec.  That it's only 1-2 pages imho is a selling point.
We already have quite a few specs in this effort, modularization need not
be viewed as evil.

To summarize:

1. There are some issues with the examples.  Personally I dont care about
the examples, I dont see this should be a show stopper.

2. There are some issues with brevity, I dont see this should be a show
stopper.

3. The default serialization turtle vs json ld seems to be a show stopper.
Let's have a conversation about why, and see if we can reach a compromise.
The WebID group so far have been supportive of the case for JSON LD.

4. There is an issue with hash URIs.  Need to get to the bottom of this.
In particular,
- Will hash URIs be accepted in web payments?
- Will web payments profile documents be 5 star linked data?

I agree that leadership could be better here, but let's try and work
together.  A spec with both Manu and Timbl behind it has that much more
chance of success.


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