Re: The Payment Identity Problem

On 7/19/14 9:46 PM, Tim Holborn wrote:
>
> On 20 Jul 2014, at 12:50 am, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto: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)?

Yes!

Basically, notations for content creation and serialization formats 
shouldn't really be part of these kinds of specs. The trouble is that 
they are, and the consequence is the never ending battles over which 
content creation notations and serialization formats MUST be supported.

In reality, RDF based specs should simply apply MUST to items like 
Linked Data (generically), RDF based Linked Data (specifically) etc..


>>
>>>
>>> * Reliance on FOAF. Let it die, use schema.org <http://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.

There needs to be a notion of Agent. As far as I know, FOAF comes into 
play because it describes an Agent class, a class (or category) of 
entity that can be associate with a public key using a
<http://www.w3.org/ns/auth/cert#key> relation (relationship type, 
association, connection etc.).

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

Payments simply need more relations constructed in line with its 
specific needs. Basically, you just need additional entity and 
relationship types described by a WebPayment specific vocabulary. That's 
all achievable without ignoring critical infrastructure provided by AWWW.


> The Identity Eco-System requires more functionality than is currently 
> in-scope for the existing, very well defined specifications, of WebID.

WebID-* is a building block. Add more domain (or problem space) specific 
relations for additional needs. This is about building blocks as opposed 
to "silver bullets".

> Perhaps we have a product vs. initiative problem.

I think we continue to have a problem understanding what AWWW provides 
and its underlying philosophy i.e., loosely couple everything, be 
tolerant, and accept you don't know everything since knowledge is 
eternally fluid.

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

There isn't a single identity recognized by the law. That's why you have 
a Passport, Driver's License, National Insurance Card, Credit Card, Club 
Card etc.. Each is a combination of Identifiers and Identity Claims 
(relations) associated with a specific Identity Provider. We should use 
computing to improve on what already exists. We should never opt to 
reinvent what exists, poorly.


Kingsley



>
>> 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 
>> <http://www.openlinksw.com/blog/%7Ekidehen>
>> 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
>>
>>
>


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