W3C home > Mailing lists > Public > public-webid@w3.org > May 2014

Re: YouID for Android Released

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 22 May 2014 10:49:53 -0400
Message-ID: <537E0E91.6070400@openlinksw.com>
To: public-webid@w3.org
On 5/22/14 9:45 AM, Anders Rundgren wrote:
> On 2014-05-22 15:16, Andrei Sambra wrote:
>>     You have full control of your (Web and Internet) Identity when 
>> the following hold true:
>>     1. You control the Identifiers that denote You
>>     2. You control the Identity Cards that Describe You
>>     3. You control the location of Identity Cards that Describe You
>>     4. You control the Signature used to verify You
>>     5. You control the control how Data is encoded for You
>>     6. You control the ACL and Access policies for accessing stuff 
>> created by You
>>     6. You can achieve all of the above from any platform You choose.
>> +1
>> Well put, Kingsley.
> If we take a typical bank who identify their customers like 0563434:
> - How are their customers supposed to change this?

The customer will never change that. Here's what can happen, as a result 
of AWWW being put to use, in this problem scenario:

1. You have an Identifier that denotes You e.g., <#anders> .
2. They have an Identifier that denotes You e.g., "0563434" or '0563434' .

You can assert the following in your own data space (e.g., anders.ttl 
stored on a storage device in your network):

<#anders> :id "0563434" .
:id a owl:InverseFunctionalProperty.

Your bank can assert the following in their data space (e.g., 
customers.ttl stored on a storage device or DBMS system in their network):

<#anders> :id "0563434" .
:id a owl:InverseFunctionalProperty.

> - What is the message you intend to bring bank-IT?

They by making deeper use of AWWW they can actually express entity 
relations endowed with both human and machine comprehensible semantics. 
Basically, that logic becomes part of the data definition, and as a 
consequence, these kinds of data integration headaches becomes declarative.

Basically, that they can issue identifiers to customers grounded in 
their namspace while also allowing customers to provide then with 
identifier grounded in the customers own namespace.

A business is never seeking to annoy its customers, intentionally. It 
just happens inadvertently as a result of the company struggling with 
inflexible IT infrastructure or the lack of knowledgeable resources in 
regards to contemporary solutions to age-old problems e.g., data access, 
integration, and management.

> IMO, your best (and currently only) option is trusting the bank for 
> using the
> information they have about you in a good way.  There's no crypto or 
> linked data
> solution that can solve that problem AFAICT.

Of course there is, if you digest my example you realize that the "Magic 
of Being You!" lies in the fact that you know yourself better than 
anyone else, and that the Bank (and others that provide you with 
services) desperately want to know you better without:

1. being a nuisance
2. overtly or covertly compromising your privacy.

Thus, by you having your own identifier (e.g., a WebID) you ultimately 
are the master of all the fragmented puzzle pieces that described you. 
That piece of Magic is something you control access to via WebID-* stack 
since they leverage RDF which is the key to N-factor authentication and 
resource access authorization.

> The social web is another thing than banking.

Of course it isn't. Banks (run by human) provide services to humans. The 
moment a human being is in the mix, we have sociality in play.

The Web and its architecture isn't an accident. TimBL knew what he was 
doing when he designed it !
> Anders

[1] http://www.w3.org/DesignIssues/HTTP-URI.html -- understanding HTTP 
URIs (puts the effect of an HTTP URI in the SAN of an X.509 cert. into 
deeper context)

[2] http://bit.ly/WAJGCp -- Linked Data in a single slide .



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: 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

Received on Thursday, 22 May 2014 14:50:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:55 UTC