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

Re: Should WebIDs denote people or accounts?

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Sun, 18 May 2014 19:44:54 +1000
Message-Id: <E97DB734-496C-4531-892E-16E583EAB13B@gmail.com>
Cc: "public-webid@w3.org" <public-webid@w3.org>, Melvin Carvalho <melvincarvalho@gmail.com>
To: Sandro Hawke <sandro@w3.org>
Inline seems to be failing in my reader.

If people end-up with their own tld, then different subdomains can separate identities / persona / professional roles, projects etc.

However from experience, having multiple tls certs in the browser isn't a great user experience.

Then beyond the single user per workstation experience, situations with multiple users (either family set-ups or potentially also public internet cafe's and the like...).

Another factor is being able to have different certs in use in different tabs.


Sent from my iPad

> On 18 May 2014, at 2:16 pm, Sandro Hawke <sandro@w3.org> wrote:
> 
>> On May 17, 2014 11:25:15 PM EDT, Timothy Holborn <timothy.holborn@gmail.com> wrote:
>>> On 18/05/2014 10:05 AM, "Sandro Hawke" <sandro@w3.org> wrote:
>>> 
>>> On May 17, 2014 5:36:12 PM EDT, Timothy Holborn
>> <timothy.holborn@gmail.com>
>> wrote:
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>>>> On 18 May 2014, at 7:18 am, Melvin Carvalho
>>>>> <melvincarvalho@gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 17 May 2014 22:30, Timothy Holborn <timothy.holborn@gmail.com>
>>>> wrote:
>>>>>> Timbl has referred to persona in past.
>>>>> 
>>>>> Do you have a pointer to this?
>>>> http://lists.w3.org/Archives/Public/public-rww/2014May/0022.html
>>> 
>>> Oh, very interesting.   I haven't found an opportunity to talk to
>> TimBL
>> about this specifically, but it sounds like he's thinking in the same
>> direction.   In that email he's very clearly showing a WebID denoting a
>> persona, not a person.
>> 
>> I think multiple persona could be linked to the same WebID-TLS cert, as
>> the
>> cert clarifies a relationship between a person / agent, and a machine.
>> Use-case could be made to associate to a rww-storage location (for a
>> specified persona, linked to an approved person / agent) and perhaps
>> also
>> support oauth, or similar. (Password + webid/webid-tls enabling
>> different
>> persona / acls / rdf data structures)
> 
> I'm not really following that.   The use cases I'm hearing from friends and family members tend to involve privacy in ways that make them hard to share here, but they tend to involve people wanting very distinct modes of being, and they don't want to switch modes without a heavy ritual like entering a password.
> 
> As one person quipped, "doesn't everyone have a normal account and a porn account?"     Others have just said they like having a clear separation between work and non-work.    In some professions and with some employers, that separation is mandated by law, I believe.
> 
> So maybe there's a cert for a person and then a password prompt for particular roles/personas associated with it....
> 
> My instinct however is the simplest thing is to identify ones self using the URL of a public profile page of yours at a particular service.    And then leave authentication  open to that service.    
> 
> Maybe for high security, you could configure a service to say that to login to it I have to also already be logged into some other service.    That's a kind of natural two factor auth, and maybe the outer auth is about you as a person (maybe based on biometrics or physical tokens) and the second one is persona based.     But still, sometimes you need to get into the system when the outer check fails....
> 
>     - Sandro
> 
> 
>>> 
>>> So far this discussion has strengthened my sense that:
>>> 
>>> - WebIDs to date have been used to denote people and independent
>> software
>> agents
>>> 
>>> - Users need to authenticate and authorize a different kind of
>> entity,
>> such as an account or persona.
>>> 
>>> It seems possible to use a WebID to identify a persona/account by
>> saying
>> that persona/account is a software agent of mine.   But that certainly
>> conflicts with what Kinsley is saying and may be too confusing.
>>> 
>>>    - Sandro
>>> 
>>> 
>>>>>> 
>>>>>> The notion of multiple accounts is highly important, for security
>>>> reasons if nothing else.  webID has been interpreted as an identity
>>>> aggregation strategy IMHO by some.  The spec itself does not mandate
>>>> that use-case.
>>>>>> 
>>>>>> (Mind, I've debated the need for other ontological options
>> before)
>>>>>> 
>>>>>> Sent from my iPad
>>>>>> 
>>>>>>> On 18 May 2014, at 1:57 am, Sandro Hawke <sandro@w3.org> 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
> 
> 
Received on Sunday, 18 May 2014 09:45:35 UTC

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