Re: Should WebIDs denote people or accounts?

On 17 May 2014 19:36, Sandro Hawke <sandro@w3.org> wrote:

>  On 05/17/2014 12:28 PM, Melvin Carvalho wrote:
>
>
>
>
> On 17 May 2014 17:57, 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.
>>
>
>  Neither, it denotes an Agent (being a person or machine)
>
>
> I was glossing over the distinction between foaf:Person and foaf:Agent for
> simplicity.   I don't think it changes my argument.
>

Sure!


>
>
>
>  I think what you are referring to is AWW Indirect Identifiers?
>
> http://www.w3.org/TR/webarch/#indirect-identification
>
> [[
> To say that the URI "mailto:nadia@example.com" identifies both an
> Internet mailbox and Nadia, the person, introduces a URI collision.
> However, we can use the URI to indirectly identify Nadia. Identifiers are
> commonly used in this way.
>
> Listening to a news broadcast, one might hear a report on Britain that
> begins, "Today, 10 Downing Street announced a series of new economic
> measures." Generally, "10 Downing Street" identifies the official residence
> of Britain's Prime Minister. In this context, the news reporter is using it
> (as English rhetoric allows) to indirectly identify the British government.
> Similarly, URIs identify resources, but they can also be used in many
> constructs to indirectly identify other resources. Globally adopted
> assignment policies make some URIs appealing as general-purpose
> identifiers. Local policy establishes what they indirectly identify.
>
> Suppose that nadia@example.com is Nadia's email address. The organizers
> of a conference Nadia attends might use "mailto:nadia@example.com" to
> refer indirectly to her (e.g., by using the URI as a database key in their
> database of conference participants). This does not introduce a URI
> collision.
> ]]
>
>
> Sure, that's another way to frame the question: is the WebID a direct
> identifier for a human or an indirect identifier for a human?   Clearly
> WebIDs were originally intended as direct identifiers for humans, but the
> issue I'm raising is that such usage doesn't fit how people seem to want to
> interact with computers.   I'm suggesting we may need to change them to
> being indirect identifiers.
>

When I mentioned indirect identifiers to timbl at TPAC he seemed to suggest
they were a bad idea.

Maybe slightly relevant is also his post, "Working without being ambushed
by Ambiguity"

http://lists.w3.org/Archives/Public/www-tag/2012Oct/0086.html


>
>
>
>   Why not just link an agent to an account, perhaps as an IFP?
>
>
> Certainly agents and accounts can be linked, eg using foaf:account or
> sioc:account_of, but that doesn't answer my question - which end of that
> arc is the WebID?   Which end is the one that is authenticated?   Which end
> is used in stating authorization?   Which end is used when stating a name?
> When stating a short biography?   When stating a "knows" relationship?
> When stating a subscription/follows relationship?
>

I would personally consider the Person the "primary key" in the sense that
I would add this as a "knows" relation.

However, you're not required to do the same, tho you may end up in wilful
violation of any spec / doc that is published, with the issue of interop
breaking.

We debated this for a while, and it went to a vote, with the current
definition.  Namely an HTTP URI that denotes an agent and MUST provide
turtle.

Timbl commented that this was essentially a branding decision.  Therefore,
you could use account as the same thing, but call it something else.

But what does this give you?  A bridge to web 2.0 social nets?  Cant we do
this already, e.g. by adding #this to the given URI ... I think Kingsley
uses this pattern extensively in YouID.  Note: YouID is a super set of
WebID.


>
> Also, foaf:account is neither FP nor IFP, which I think is correct.   One
> could make an IFP variation, something like "individualsAccount" which
> would make it work more nicely for identifying humans.     Or
> "singleAgentAccount" if its for foaf:Agents.
>
>
>
>  Timbl in his WebID has also a very interesting predicate, preferredURI
> ...
>
> http://www.w3.org/2000/10/swap/pim/contact#preferredURI → "
> http://www.w3.org/People/Berners-Lee/card#i"
>
>  Does this solve the mulitple identity issue?
>
>
> Not at all.     That's for selecting among re-referring IRIs, for
> situations where you want a "best" one.   But they all have the same
> semantics.   In the problem I'm pointing out, it's the semantics that are
> wrong.
>

Got it.


>
>
>
>   It strikes me that an Agent and an Account are very different things,
> but
>
>
> Oh, absolutely.   That's half my point -- that the are different.
>
> The problem is that a significant fraction of the user base (including me,
> my kids, and the friends I talked to) strongly prefer logging in to an
> account rather than identifying themselves as being a particular agent.
>

Could we go through an example?

So facebook *dont* have this problem, you would be

https:/graph.facebook.com/sandro#

And I could link to it.

Which are the nets causing an issue?  Twitter (let's not talk about the
hash bang debacle!), google ... what relation would you like to see?


>
>
>    I'm open to persuasion.
>
> Note: also that webfinger tried to open this can of works and ended up
> minting a acct: URI scheme ... seems like fragmentation is undesirable ...
>
>
>
> Can you summarize the story there, or point to a summary?   I missed that.
>

The idea of webfinger was to get an HTTP URL from an email address that
gave machine readable information, such as, name, avatar, blog etc.

So it originally looked something like this

/.well-known/webfinger?subject=user@host

But then there was confusion ... was user@host the subject or the object.
It was decided that user@host (ie mailto:) was the object.  Which left the
awkward question, what's the subject?  To tackle this the idea was that
users have "accounts" at websites.  So a new URI scheme was minted
acct:user@host, which would be the subject of the query.

So now you go to

/.well-known/webfinger?subject=acct:user@host

But now we have fragmentation of the the common user@host pattern.  Is it
mailto: ? is it acct: ? is it xmpp: is it sip: ? etc.  When do I use it as
a primary key or foreign key at web scale?

Of course here you could have just used mailto: as an indirect identifier
or as a reverse lookup on the object.  But that's not how the spec went, so
things got complicated.

A clean architecture is helpful in building things that scale.  Do you have
a specific pain point that we could think about addressing?


>
>        -- Sandro
>
>
>
>>        -- Sandro
>>
>> [1] http://en.wikipedia.org/wiki/Role-based_access_control
>>
>>
>
>