Re: Should WebIDs denote people or accounts?

On 5/17/14 1:27 PM, Anders Rundgren wrote:
> Sandro,
> Well, your observations are correct, WebID doesn't make
> sense for logging in to a bank.

WebID is not supposed to log you into a Bank. There is no precedent in 
the history of mankind where such an Identifier has provided you with 
access to anything.

WebID is an Identifier that denotes an Agent.

## Turtle Start ##

<#WebID>
a <#Identifier>;
rdfs:label "WebID" ;
rdfs:comment """An HTTP URI that denotes an Agent (a Person, 
Organization, Software, or Machine)""".
<#denotes> [ a foaf:Agent ] .

## Turtle End ##

A Bank (and similar organizations) requires you to present an Identity 
Card (in some form) en route to Account (log/ledger holding your Credits 
and Debits transactions) access.

#Turtle Start ##

<IdentityCard.ttl>
a foaf:Document ;
rdfs:label "Identity Card" ;
rdfs:comment """Identity Card that holds Identity Claims 
(attribute=value pairs that coalesce around an Identifier e.g., a WebID) 
""";
foaf:primaryTopic <#YourWebID> .

<#YourWebID>
foaf:name "Moi"
foaf:onlineAccount <#YourAccountID> .

## Lots of other claims go into this document as a basis for 
Identification, the very purpose of this document ##

## Turtle End ##


>
> However, the reason for that is not because a bank login denotes an "account"
> (since you anyway MUST distinguish different users accessing a bank account),
> the actual reason why WebID is inappropriate is that there is no point adding
> a URI to web-base user data since it is anyway stored inside the bank-server.
> The URI would only add authorization hassles.

Sorry, this simply isn't true or accurate. Every bank already has a 
proprietary protocol in place for identity verification. WebID and 
WebID-TLS are simply options for them re., incorporation of a more webby 
(or web-like) solution into what exists, because its ultimately more 
flexible due to loose coupling and the logic that RDF unleashes.


>
> TLS may be used although banks usually bypass the standard solution for the
> fact that is is incomplete from their perspective including missing support
> for PIN-code protected keys for on-line provisioned certificates. Netscape's
> 1995 two-week student hack (HTML5's keygen) doesn't really cut it.

As I've told you repeatedly, this too is inaccurate. You are looking at 
things from a very specific perspective (programming of PKI applications 
pre Web) that you've rendered immutable. Until you loosen your 
worldview, we will continue to loop on this matter.

WebID and WebID-TLS protocol simply enable PKI to become webby or 
web-like combined with the power of RDF for expressing entity relations 
semantics.

>
> Anders
> Bank-PKI professional

Kingsley
>
> On 2014-05-17 17:57, Sandro Hawke wrote:
>> Summary: Most people will be unwilling to give up the idea of having
>> multiple separate accounts.  This calls into question the whole idea of
>> WebID.
>>
>> First off, as an aside, hello everyone.   I was in the CG for its first
>> few weeks to help get things started, but then left when it looked like
>> things were well in hand, and I had many other W3C duties.   Since then,
>> nearly all of my Working Groups (SPARQL, RDF, GLD, etc) have wrapped up,
>> and I'm mostly doing R&D, working with TimBL and Andrei Sambra.   The
>> work we're doing needs something like WebID.
>>
>> That said, I have to raise a difficult issue.   Maybe there's a simple
>> solution I'm just missing, but I fear there is not.
>>
>> The examples in the spec, and what I saw from Henry when he first
>> presented foaf+ssl, show the WebID denoting a person.   In the examples,
>> it's often an instance of foaf:Person, and occurs in triples as the
>> subject where the predicate is foaf:name, foaf:knows, etc.  Also in
>> triples as the object of foaf:knows.
>>
>> So that means that in RDF, my WebID denotes me.   And if I have three
>> different WebIDs, they all denote me.    Anything that's said in RDF
>> using one of my WebIDs is equally true to say using any of my other
>> WebIDs, and a reasoner might well infer it.   That's how it looks like
>> WebIDs are supposed to work.
>>
>> This is in stark contrast to how most online identity systems work. The
>> usually model is that a person has an account with a particular service
>> provider.   In the old days that might have been a bank, while these
>> days it might be some kind of "identity provider" like Google or
>> Facebook.   There is important flexibility in this model.    I have two
>> Google accounts, and my kids have many among themselves, so on the
>> computers around the house, there are many possible Google accounts
>> saved as possible logins.    Behind the scenes, Google may or may not be
>> correctly inferring which humans are attached to each of these accounts,
>> but as long it doesn't get wrong which accounts can see adult content,
>> or use my credit card, or see/edit particular documents, that's okay.
>> Those important features are attached to accounts, not people, in
>> systems today.
>>
>> FOAF makes this distinction quite clear, with classes foaf:Person and
>> foaf:OnlineAccount.   FOAF, quite reasonably, puts relationships like
>> foaf:name and foaf:knows on foaf:Person.   It's interesting to know my
>> name and who I know.   It might also be interesting to see which of my
>> accounts are linked with other accounts, I suppose, although that's more
>> complicated.
>>
>> I'm not sure exactly why people might have multiple accounts. Sometimes
>> an account is provided by an employer or school and goes along with lots
>> of resources, but also includes restrictions on use or limitations on
>> privacy.  Sometimes an account is obtained with a particular service
>> provider, and then one no longer wants to do business with them.
>> Sometimes security on an account is compromised and a backup is needed.
>>     Sometimes one just wants to separate parts of life, like
>> work-vs-nonwork.   I've asked a few friends if they'd be willing to have
>> exactly one computer account, and gotten an emphatic "No!".
>>
>> So the my question might be, can WebID allow that separation?   If
>> access control is granted by WebID (as I've always seen it done), and
>> WebID denotes a person (as I've always seen it), and the computer
>> figures out that multiple WebIDs denote the same person (as it's likely
>> to do eventually), then isn't it likely to grant the same access to me
>> no matter which of my WebIDs I'm using?   Wouldn't that be the
>> technically correct thing for it to do?
>>
>> In summary: WebID is doing something quite radical in the identity space
>> by identifying humans instead of accounts.   Are we sure that's a good
>> thing?    It seems like in practice, humans interacting with service
>> providers want to have multiple distinguishable identities with separate
>> authentication.  One might try to clean this up with some kind of
>> role-based access control [1], but that might not solve the issue that
>> by having WebIDs denote people, they prevent people from authenticating
>> differently to get different access/behavior.
>>
>> (It's true some identity providers, like Facebook, forbid a human from
>> having multiple accounts.  But I think in response we see humans get
>> their additional accounts by using other providers.)
>>
>> The conclusion I'm tentatively coming to is that WebIDs should be 1-1
>> associated with accounts, not people.  As such, they'll be associated
>> with authentication, authorization, and profiles, as they are now.   But
>> the RDF modelling will have to be different, with things like { <webid1>
>> foaf:knows <webid2> } being disallowed.
>>
>> If we're going to make a change like that, making the WebID one hop away
>> from Person, I'd suggest actually making it denote the account's profile
>> page, so that it can be a normal URL, denoting an Information Resource.
>>
>>          -- Sandro
>>
>> [1] http://en.wikipedia.org/wiki/Role-based_access_control
>>
>
>


-- 

Regards,

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 Saturday, 17 May 2014 18:17:56 UTC