Re: The Payment Identity Problem

On 20 Jul 2014, at 12:50 am, Kingsley Idehen <kidehen@openlinksw.com> wrote:

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

JSON-LD Should be included.  Interoperability is perhaps a different part to defining standards, where MUST is a technical pre-requisite (i.e. Linked-Data / RDF)?
> 
>> 
>> * 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.
> 
FOAF Specifically notates the use of FOAF.  Most community Members use FOAF in their “WebID’s”, and a variety of tools / apps are seemingly created in such a way as to seek-out FOAF.  Where the WebID notates a ‘person’ or ‘persona’ (agent of person) FOAF seems to provide an excellent method to provide pseudo-anonminity / a ‘loosely coupled’ identifier - which is an extremely important piece of the identity eco-system as to provide a ’safe’ internet (noting the words used by Vint Cerf, re: Safe vs. Secure…)
http://www.verisigninc.com/en_US/innovation/verisign-labs/speakers-series/evolution-of-internet/index.xhtml

WebPayments has a different requirement.  The Identity Eco-System requires more functionality than is currently in-scope for the existing, very well defined specifications, of WebID.  Perhaps we have a product vs. initiative problem.   
> 
>> 
>> * 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.
> 
+1  

I believe the notions around (decentralised) identity services should ideally be governed, from a W3 CG point of view - through a lead-group.  a multitude of requirements exist; from ‘high-stakes through to pseudo-anonminity requirements.  A lay-Web User, should be empowered with the opportunity to use both, either or neither - on a session basis - should we successfully do our part well.

we may have a multitude of persona - yet only one identity, as recognised before the law. 

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