Re: The Payment Identity Problem

On 7/16/14 11:48 PM, Manu Sporny wrote:
> 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/
>
>
> * 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.

Why? Even the tales of king Solomon teach us that approaches such as 
what you are suggesting above on serve to kill the baby.

Neither TURTLE nor JSON-LD should be mandated in any RDF based spec. RDF 
is a Language associated with many notations.

During implementation and open standards interoperabilty testing, 
various profiles will veer towards relevant notations.

We continue to stall all RDF endeavors by reducing RDF to a specific 
notation via the use of MUST in RDF related specs.

Just make examples aimed at specific audiences, and qualify them as 
such. For example, JSON-LD notation based examples target Javascript 
developers. Likewise, TURTLE notation based examples target Linked Open 
Data developers and end-users etc..

Those that feel strongly about a given notation should contribute the 
examples rather than making that the burden of someone else, which is 
often the case.

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

Yes! WebID doesn't require any FOAF specificity, by that I mean: a WebID 
doesn't need to resolve to a FOAF based WebID-Profile document.


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

HttpRange-14 is a distraction.

The issue at hand is simple:

We use words to denote i.e., we use identifiers to denote or "refer to" 
entities

We use sentences or statement to connote i.e., we encode and decode 
information sentences, as is the case with natural language e.g., 
representing how two entities are related/associated/connected .

HTTP URIs can be used to denote entities, unambiguously.

RDF sentences or statements can be used to construct sentences that 
bring connotation (sense manifestation) to entities denoted by identifiers.

Web Accessible Documents provide a surface for inscribing RDF statements 
or sentences.

Web Documents (like you piece of paper) share identity distinct from:

1. sentences inscribed in/on them
2. identifiers denoting the subject, predicate, and object parts of the 
sentence .

As I said, HttpRange-14 permathread is much to do about nothing, bar 
perpetual demonstration of the prevalence of AWWW incomprehension.

>
> * There is no mechanism described that provides a way to express
>    information that has been digitally signed by 3rd parties.

That's for specs addressing a different need e.g., Web Payments. Nothing 
to do with the fundamentals of Web-like or Webby Identity (aka WebID).

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

Yes, that's what should happen.

>
> * re: Privacy. The only privacy that the mechanism provides via
>    WebACL is protection from who can read/write the information.

Again, WebACLs are distinct from WebID.

You solve this problem, and all other problems via the creation of a 
vocabulary aimed at the creation of statements or sentences that entity 
relationship meaning in the relevant problem space.


> There is
>    no pervasive monitoring protection against identity providers.

Nothing to do with WebID.

>    Identity providers can track your every move. To provide real
>    privacy and tracking protection, you need more than just WebACL.

Of course you do, and developers can encrypt content. They can share 
keys using a variety of protocols.

This has nothing to do with WebID, solely.

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

Yes.

WebID should be a one page document.
WebID-Profile a one page document.
WebID-ACLs a one page document.
etc..

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

You could take the simple foundation blocks and build something for a 
specific problem space, keeping the open underpinning intact.

We can all do better. Let's veer towards collaboration rather that 
distracting squabbles that ultimately bring inertia to all of these 
useful initiatives.

Links:

[1] http://slidesha.re/QEqLZN -- RDF and Natural Language
[2] http://bit.ly/1fdTTPE -- Revisiting Linked Data principles using 
Natural Language examples
[3] http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word -- 
Words (are IRIs that denote entities) and Terms (are HTTP URIs that 
denote entities while also resolving to Entity Descriptions).


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this