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

Re: Credentials Community Group

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 03 Aug 2014 11:43:18 -0400
Message-ID: <53DE5896.6010800@openlinksw.com>
To: Web Payments CG <public-webpayments@w3.org>
CC: public-webid <public-webid@w3.org>
On 8/1/14 2:17 PM, Tim Holborn wrote:
> If your saying the Credentials initiative has no merit - I have to 
> disagree.
>

I don't believe I was making any kind of judgement about a credentials 
oriented initiative.

> the demo that was created - i thought was good.  I was annoyed i 
> couldnít generate a WebID / WebID-TLS Cert in the demo - but itís just 
> one of the many bridges that could be built along the way.
>
> The question remains - Have we considered the identity lifecycle 
> sufficiently, and what could be done to improve the overall solutions 
> - including, ensuring cooperative predicates that acknowledge the 
> existence of other formats, for different purpose, providing 
> interoperability between the various initiatives and/or fields.
>
> A possible answer is no.  (Iím not sure that would be the most 
> constructive one.)

My concern is more to do with not overlooking what exists, in regards to 
core infrastructure for building open solutions that don't look anyone 
into a silo.

>
> Love your work - with very high esteem overall - yet sometimes your 
> twitter posts have more code than content, doesnít mean i donít spend 
> (sometimes lots of) time figuring out what itís all about, etc.
>

Turtle statements are one way of *encoding* and *decoding* information 
(data in some context). Just like English, which really isn't optimal 
for a global Web in which every information recipient isn't an English 
speaker or reader. I don't believe in imposition of a single notation 
that serves as nothing more than a tax for access to information.

Thus, when you see me tweet with nanotations, I am actually 
demonstrating how you can make digital renditions of natural language 
sentences using an RDF notation that fits into the 147 character 
limitations of a Tweet [1][2].

I prefer to show, and then tell. Alternative approaches are antithetical 
to my nature.

> seperately; as part of my dev. cycle, I worked with people in their 
> 70ís, 80ís and older - teaching them how to digitise heritage content, 
> within a (group of) country historical societies, seeking to look at 
> an array of problems around the digital divide, civic content, RDF 
> based licensing for Civic / commercial use, production lifecycles, 
> identity systems with history related stakeholder groups, etc.  Within 
> that area, it would be good to have WebIDís associated to contributors 
> - so when they post additional data about an image, such as ďa 
> personsĒ, or the manufacturer of an object depicted - We can figure 
> out whether or not itís real - and in-turn, send help verify 
> interactions, etc.
>
> Other aspects include that it is my belief, that seniors - given their 
> various disabilities - can benefit enormously from tablet computing, 
> and if their is troubled, isolated kids - well, theyíve got alot of 
> time and it takes ages to scan archives of historical content ++ they 
> generally know something about computers (perhaps not so much about 
> community).

Seniors are typically literate. The are have highly honed natural 
language skills. Thus, you only need to show them how they can make 
sentences in digital form rather than forcing them to keep up with the 
next tweet, sms, vernacular etc., which simply reflect the opportunity 
cost of RDF's poor narratives of yore.

RDF is a powerful language that enables any one literate in a natural 
language (not just English) to encode and decode information via the Web 
medium, effectively.

>
> But tell me.  When these seniors need one sort of ID for shopping, but 
> do not wish to be harassed due to info theyíve been made to share to 
> do that transaction (not very tech. savvy at allÖ).  So many already, 
> have some inbound call by someone who then asks for their banking 
> details because theirs a problem - which they hand-over, over the 
> phone - because thatís the way organisations do business nowadays, 
> itís cheaper.
>
> So - whilst itís high-up on my agenda to get stuck into that 
> data-rights issue - in relation to the broader issues i perceive may 
> be worth considering - iím thinking, at least iíve blown the trumpet 
> and said something along the lines of - hey all - why donít we have a 
> good think about how weíre going about this whole identity area. 
>  Perhaps we can define something that fits the needs of various 
> industries, whilst still, as technologists - putting the peopleís 
> interests first, as part of the design criteria.
>
> Even with anders stuff.  I see no reason why, although being very 
> different to other solutions, some sort of design requirement cannot 
> be made so that his specific field of interest may be incorporated in 
> some way thatís rational.
>
> Yet - itís so not that easy.  I know that.  Else iíd simply DIY.
>
> ATM - identity is institutionally fragmented - in a manner, where 
> user-data is stored with the identity provider, or in relation to a 
> commercial identity provider.  I envisage this will change, and that 
> the best approach will likely be to have a market-based solution.  To 
> do that, i envisage a full set of standards will be required and i see 
> no reason why the HTTP aspects of it, shouldnít be done via the W3C.
> </rant>

When we get this stuff delivered and described the right way, everyone 
(including seniors) will end up being in full control of their privacy. 
Remember, privacy is about self-calibration of one's vulnerability i.e., 
you control the levers of vulnerability, not some "big brother or 
sister" third party (increasingly a broken robot).

Links:

[1] http://bit.ly/blog-post-about-nanotation --- Nanotation (beaming 
memes over the Web using digital rendition of natural language 
sentences, from wherever).
[2] http://slidesha.re/QEqLZN -- RDF and Natural Language .


Kingsley
>
> timh.
>
> On 2 Aug 2014, at 2:46 am, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> On 7/31/14 3:43 AM, Anders Rundgren wrote:
>>> I don't feel too optimistic about this effort.
>>>
>>> This seems like a repetition of WebID-TLS, zero buy-in from the 
>>> browser-vendors.
>>>
>>> Without new stuff added to browsers I don't see how you can move the 
>>> market.
>>>
>>> Years ago I suggested creating a "Cloud Token":
>>> https://groups.google.com/forum/#!topic/icf-members/Csyd1NWcmog
>>>
>>> Unfortunately nobody liked the idea. When FIDO/Google did the same 
>>> thing
>>> with U2F, *the entire industry* from Microsoft to ARM flocked around 
>>> it.
>>> This is why browser-vendor buy-in remains the #1 problem.
>>>
>>> BTW, the fixation with Linked Data is contra-productive, there are a 
>>> lot
>>> of use-cases that do not need or want to put credential data on the 
>>> web.
>>> I.e. credential data should always be possible to supply "in-line" 
>>
>> Linked Data == Web-like (or Webby) Structured Data Representation. It 
>> enables data to flow across data silos, via HTTP URIs. It is based on:
>>
>> 1. HTTP URIs
>> 2. RDF language statements (which can be crafted using a variety of 
>> notations re., document content).
>>
>> What does RDF uniquely add to structured data representation?
>>
>> 1. Use of IRIs
>> 2. Semantics for Relationship Properties (Predicates, Relations 
>> etc..) that are both human and machine readable.
>>
>> #1 means identifiers functioning like words, they do not implicitly 
>> resolve to what they denote.
>> #2 means you can just make up a relation on-the-fly that's 
>> comprehensible to both humans and machines, if you simply describe 
>> the relation semantics [1].
>>
>> What do HTTP URIs add to RDF?
>>
>> 1. Use of HTTP URIs for denotation that resolves to connotation
>> 2. RDF document become vehicles of connotation (sense) based on the 
>> Name/Address indirection that HTTP URIs enable .
>>
>> #2 means Identifiers functioning like natural language terms i.e., 
>> they implicitly resolve to what they denote.
>>
>> Linked Data isn't the issue here. The issue is understanding how to 
>> use AWWW to build solutions that work within the existing 
>> infrastructure provided by the Web. Just as the Web was constructed 
>> to leverage the infrastructure provided by the Internet.
>>
>> You don't need Browser buy-in for anything since Web Browsers are 
>> simply client applications that leverage AWWW infrastructure.
>>
>> The notion of applications and services change, due to the dexterous 
>> nature of AWWW, therein lies the real problem. We have infrastructure 
>> that's much smarter (by way of core design) than most presume, 
>> initially !!
>>
>> To conclude, you can't build an W3C endorsed spec that turns AWWW on 
>> its head. That will fail during the review process, and if my some 
>> bizarre miracle it doesn't, it will implode, predictably, due to all 
>> of its points of data-silo-fication.
>>
>> [1] http://linkeddata.uriburner.com/c/9DA62JIF -- about "H/T" a human 
>> and machine comprehensible relation I made on-the-fly, using RDF in 
>> Twitter, Facebook posts etc..
>> -- 
>> 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
>


-- 
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 Sunday, 3 August 2014 15:43:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:38 UTC