W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2014

Re: [foaf-dev] Credentials Community Group

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 01 Aug 2014 10:21:14 -0400
Message-ID: <53DBA25A.6080401@openlinksw.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>, Tim Holborn <timothy.holborn@gmail.com>
CC: "public-webid@w3.org" <public-webid@w3.org>, Web Payments CG <public-webpayments@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
On 8/1/14 3:57 AM, Anders Rundgren wrote:
> Tim,
>
> I believe that some of these issues will be simplified once the idea 
> of a universal identity concept is finally put to rest.

+1

>
> Banks (to take an example I know of) have their own identity silos and 
> IMO they have no compelling reason changing that.
> In fact, even nations have identity silos which is one reason why all 
> EU cross-border identity schemes have failed miserably.
> OTOH, the EU doesn't even have a common language and therefore all 
> efforts automating cross-border operations are by definition futile 
> anyway.

+1

>
> The challenge for *this* particular community is creating 
> decentralized schemes that offer strong authentication, convenience 
> and user-control of identity information.

+1

> Since Google can put *hundreds of people* on developing various 
> browser/platform goodies while we appear not having a *single* 
> browser-developer at our disposal (although our task is *much more 
> difficult* than supporting "super-provider" schemes like Apple, Google 
> or PayPal), I think we are currently pretty much stuck.
>

-1000

Of course not!

> Although it is interesting discussing the high-level aspects of the 
> "identity enigma", this discussion must eventually be converted into a 
> *platform requirements*.

We have the Architecture of the World Wide Web (AWWW) at our disposal. 
It is a little more capable that most assume. As I've stated in the 
past, it gives us:

1. URIs -- Identifiers that function like words or terms in natural language
2. URLs -- Identifiers that denote locations i.e., Addresses.

Building on the above you have open standards from the W3C that cover:

1. RDF -- Sentence or Statement construction
2. LDP -- for Reading and Writing Sentences about things (entities) in 
the world to Documents (denoted by their Addresses/Locations).

Exploiting the above we have some "best practices" and usage patterns 
that include:

1. WebID -- Agent denotation via HTTP URIs
2. Linked Open Data -- Use of HTTP URIs to denote the subject, 
predicate, and object (optionally) of sentences (e.g. those constructed 
using RDF).

With all of the above in place, you can build declarative as opposed to 
imperative solutions that simply leverage the logic processing 
capability of RDF processors.

> I see very little of that.  Not even the list of features "required" 
> (?) to make WebID-TLS more usable have reached specification-status.

You are conflating issues here. The pursuit of a divine spec is 
dead-on-arrival. Building *useful* solutions that work and impart 
*"opportunity costs"* on the doubters is how you make a difference with 
technology. There has never been a time where change happened due to 
mass adoption of a divine-specification.

If we build useful solutions, we make justifiable cases for adoption 
that ultimately pull in the doubters and laggards.
>
> That LinkedData solves all problems is great but rather useless unless 
> you describe each problem separately including how it works and why 
> existing or other solutions do not really cut it.

Linked Data solves many problems, only because (as per my comments 
above) it enables the development of loosely-coupled applications that 
leverage untethered data flows (subject to protected resource access 
acls and policies)  across data silos.

> How (for example), Identity Credentials address the NASCAR issue is 
> beyond my understanding at least, do you know?

What makes you think NASCAR is a problem for end-users?
What makes you think TLS CCA is a problem for end-users?

Most of the time, the items above originate from the questionable views 
of programmers that assess problems from the bottom up, instead of from 
the top down.

Rather than the usual Links section, I am embedding some digital 
statements about things mentioned in my response, for context.

## Turtle Start ##

@prefix kidehen: 
<http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/GlossaryOfTerms.ttl#> 
.
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix schema: <http://schema.org/> .
<>
a sioc:Post ;
rdfs:label "Re: [foaf-dev] Credentials Community Group" ;
rdfs:comment """Another discussion about Identity, Authentication, and 
Distributed Solutions""" ;
foaf:topic kidehen:LinkedData,
                 kidehen:LinkedOpenData,
                 kidehen:Identifier,
                 kidehen:URI,
                 kidehen:HTTPURL,
                 kidehen:HTTPURI ;
dcterms:references 
<http://www.wikihow.com/Differentiate-Between-a-Term-and-a-Word>,
<http://latentflip.com/imperative-vs-declarative/> ;
rdfs:seeAlso <http://www.jfsowa.com/pubs/fflogic.htm> .

<http://www.jfsowa.com/pubs/fflogic.htm>
a schema:WebPage;
rdfs:label "Fads and Fallacies about Logic" .

<http://latentflip.com/imperative-vs-declarative/>
a schema:WebPage;
rdfs:label "Imperative vs Declarative Programming".


## Turtle End ##
>
> Anders 


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


Received on Friday, 1 August 2014 14:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:33 UTC