Re: Should WebIDs denote people or accounts?

What (if any) are the barriers to updating the spec? Creating a version 2, perhaps starting with use-case scenarios (again?) 

Timh.

Sent from my iPad

> On 19 May 2014, at 10:22 pm, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> 
>> On 5/18/14 9:21 PM, Andrei Sambra wrote:
>> Hi,
>> 
>>> On Sun, May 18, 2014 at 8:40 PM, Sandro Hawke <sandro@w3.org> wrote:
>>>> On 05/18/2014 08:17 PM, Kingsley Idehen wrote:
>>>>> On 5/18/14 4:31 PM, Sandro Hawke wrote:
>>>>>> On 05/18/2014 01:59 PM, Nathan Rixham wrote:
>>>>>> I'd suggest that this is not a technical problem and cannot be addressed this way.
>>>>>> 
>>>>>> When you add reasoners in to the mix they can quickly determine that typographically different (personas/agents/uris) refer to the same thing, whatever approach is used.
>>>>> 
>>>>> Not true.   They might quickly determine that two personas are managed by the same person, but that is not the same as determining that the two personas are the same thing.
>>>> Only if you provide the information that makes that feasible.
>>>> 
>>>>> 
>>>>> Computers are perfectly capable of keeping track of my having multiple distinct mailing addresses, multiple distinct phone computers, multiple distinct phone numbers, etc.   They know they belong to the same person, without getting confused and thinking actually each of my mailing addresses is the same or each of my android devices is the same.   If they did, I couldn't exactly label one as being home and one as being office, or install some apps on one android device and not on another.
>>>>> 
>>>>> This is not hard to solve - we just have to be clear that what's being authenticated and authorized is a persona/account, not a human.
>>>> 
>>>> And why do you believe that:
>>>> 
>>>> 1. WebID isn't clear about being an Identifier that denotes an Agent?
>>>> 
>>>> 2. That WebID-Profile Documents aren't RDF documents that describe the referents of WebIDs (i.e, they are Identity Cards) ?
>>>> 
>>>> 3. That WebID-TLS isn't about authenticating the claims in the WebID-Profile document ?
>>>> 
>>>>> 
>>>>> Unfortunately, this doesn't match WebID's self-conception, so far.
>>>> Only if you are conflating WebID [1], WebID-Profile [2], and WebID-TLS [3], which is still a general problem we have with the term: WebID.
>>> 
>>> I'm fairly confident I know what those terms mean.  I talked to folks coming out of the meeting where WebID-TLS was split from WebID, in Lyon, and got the story at the time.
>>> 
>>> 
>>>> WebID is simply an identifier that denotes an Agent. WebID-Profile is a profile document that describes what a WebID denotes.
>>>> WebID-TLS is an authentication protocol that verifies the claims made in a WebID-Profile document or Identity Card.
>>>> 
>>>> Could it be that you are indicating to the spec editors that some organizational issues exists re., layout and overall presentation? if that's your concern, then I can certainly see where you might be coming from etc..
>>> 
>>> That was my hope when I started this threat, but that hope has died.
>>> 
>>>> Links:
>>>> 
>>>> [1] http://www.w3.org/2005/Incubator/webid/spec/identity/#the-webid-http-uri
>>> 
>>> The diagram is very clear that the WebID denotes the person.
>>> 
>>> You have also been very clear about that in your emails.
>>> 
>>> Since the WebID is also what the user authenticates as, and what authorization is granted to, in the systems I've seen, that means the unit of authentication and authorization is the person.
>>> 
>>> That's not acceptable to me as a user, and I think many other users will also find it unacceptable.
>>> 
>>> I don't see how we can expect to build mass-market systems using WebID until this is changed.
>> 
>> I've been thinking about the examples you and Kingsley gave and I'm not really seeing a problem anymore. Here are my thoughts:
>> 
>> 1. Current situation: we have WebID, WebID-Profiles and WebID-TLS. WebACLs uses WebIDs as identifiers for people (personae), not for accounts.
>> 
>> 2. Sandro fears that if a user has two or more WebIDs and if he/she adds an owl:sameAs or reuse the same email address, then an authentication service may consider those identities to belong to the same person, leading to unpredictable results. The issue started from the fact that FOAF defines "mbox" as Inverse Functional Property (Sandro, please correct me if I was wrong). The definition given by W3C is: "If the predicate has the "InverseFunctionalProperty", than that means that wherever you see the (subject) linked to an (object) by this particular (predicate), then the (subject) is the one and only (subject) with that (object) connected by the (predicate.) If you ever saw some other subject linked to the object by the predicate, you'd know that the "other" subject was actually the same subject."
>> 
>> In other words, if a system will follow OWL logic, then it may infer that WebID #1 is the same as WebID #2. If you want to separate two identities, you don't link them in the first place, but then you can't really stop people from reusing email addresses in different WebID-Profile documents. 
>> 
>> I have two suggestions at this point: 
>> 
>> 1. The first is to specify that WebID-* authentication services should not conflate identities unless profiles are linked through owl:sameAs, which is a clear indication that identities should be linked.
> 
> Yes, but owl:sameAs itself doesn't have to be gospel either. An ACL system could decide that such claims must be signed. Today, my assumption is that most WebACL systems actually ignore owl:sameAs on a precautionary basis. 
>> 
>> 2. I personally don't think that using inverse functional properties in FOAF was a good idea, so maybe we can also consider defining our own WebID-profile vocabulary, though it will limit current interop. On the other hand, it would help us clearly define what entities the WebID refers to.
> 
> It's a good idea in relevant circumstances e.g., data integration aided by identity reconciliation. As is always the case, we have to apply the "horses for courses" rule i.e., "one size doesn't fit all". 
> 
> In agreement with your statements above, I do believe that we did agree to caution implementers about owl:sameAs and IFPs i.e., disable or don't honor at first blush. Of course, if your implementation can reason conditionally, then by all means proceed.
> 
> In our systems, reasoning is an option. You have to enable it at the general level (e.g. Virtuoso system) and then at the ACL layer (which is where you can use signed claims as the proviso for     reasoning ditto factoring in the cert. issuer which brings the Cert. Issuers SAN into play too). 
> 
> 
>> 
>> -- Andrei
> 
> 
> -- 
> 
> 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
> 
> 
> 
>