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

Re: Credentials Community Group

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 06 Aug 2014 10:18:48 +0100
Message-ID: <53E1F2F8.4050304@openlinksw.com>
To: public-webpayments@w3.org
On 8/3/14 5:00 PM, Timothy Holborn wrote:
> Sent from my iPad
> On 4 Aug 2014, at 1:43 am, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>> 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).
> Cheers...
> I think the concept of data-rights is bigger than simply privacy, as 
> noted in-previous posts...

Data rights are a consequence of you controlling your data. Privacy is 
about self-calibration of vulnerability, in both cases, its all about 
the data. If you control your data, you control the levers of 
> Credentials are important.  Existing work, is also important. 
>  Life-cycles use various parts (not just on the http layer) and pseudo 
> anonymity is important for the user experience (inclusive of the 
> entire lifecycle).

I am not disputing that. My point is that all of that boils down to data 
and data access control.

> In my experience - the most unsettling experiences show I do not 
> control the levers.

See my comment above.

> Part of that problem includes not being furnished with a copy of the 
> "data".

See my comment above.

> The web currently monitises mostly data.

I assume you mean most Web Services (e.g., social media/network service 
providers)? If so, then yes they do. They are basically DBMS owners 
while their members are data entry clerks, so to speak.

> People mostly do stuff with "knowledge capital", paying a data tariff, 
> whilst their 'knowledge capital' is valued at the same amount only, as 
> the cost of providing a publishing / UI service.
> A complicated issue identity.  Happy to see the w3 webizen activities 
> moving forward.

Identity is complicated, sorta. I say that because the issues of open 
data connectivity and access controls always attract large degrees of 
cognitive dissonance. The Web itself works because it is built on 
infrastructure that isn't cognitively dissonant about open data 
connectivity and access controls. Our biggest challenge is actually the 
protection of this fundamental aspect of the Web's architecture.

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


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 Wednesday, 6 August 2014 09:19:12 UTC

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