- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sat, 17 May 2014 14:17:30 -0400
- To: public-webid@w3.org
- Message-ID: <5377A7BA.4090707@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Saturday, 17 May 2014 18:17:56 UTC