Re: Should WebIDs denote people or accounts?

On 5/19/14 9:23 AM, Sandro Hawke wrote:
> Long message, to which I don't have time to write a full reply right 
> now.   So I'll just respond to a few key points for now.
>
> On 05/19/2014 08:04 AM, Kingsley Idehen wrote:
>> On 5/18/14 8:31 PM, Sandro Hawke wrote:
>>>> How do you know that two IRIs denote the same thing without an 
>>>> owl:sameAs relation? Or without participation in an IFP based 
>>>> relation? How do you arrive a such conclusions?
>>>>
>>>> If a WebID doesn't resolve to an Identity Card (or Profile 
>>>> Document) comprised of owl:sameAs or IFP based relations, how can 
>>>> you claim coreference? You only know that two or more IRIs denote 
>>>> the same thing by way of discernible and comprehensible relations.
>>>
>>> You're putting the burden of proof in the wrong place.
>>
>> An Identity Card holds Identity claims.
>>
>> Verifying the claims in an Identity Card is handled by an ACL or 
>> Policy system. One that's capable of making sense of the claims and 
>> then applying them to ACL and Policy tests en route to determining 
>> Trust.
>>
>> A WebID is like your Passport Number.
>>
>> A WebID-Profile is like you Passport.
>>
>> The WebID-TLS protocol is a protocol used by the Passport Issuer 
>> (this entity has a Trust relationship with Immigration Services).
>>
>>>
>>> You (and the rest of of the WebID community, including me until 
>>> about 5 days ago) model the world in such a way that if your 
>>> access-control reasoner ever got hold of some forbidden knowledge 
>>> (the perfectly correct fact that two my WebIDs co-refer) it would do 
>>> the wrong thing.
>>
>> Please don't speak for us (OpenLink Software) as I know that simply 
>> isn't the case with our ACL engine. You see, you are making the same 
>> old mistakes that tend permeate these efforts. As I told you, we 
>> actually start our implementations from the point of vulnerability. 
>> You get to understand the point of vulnerability when you understand 
>> the concepts behind a specification.
>>
>> I spent a lot of time drumming home the fact that we needed a 
>> conceptual guide for WebID so that we simply wouldn't end up here 
>> i.e., you come along and assume everyone has implemented exactly the 
>> same thing.
>>
>> If we spent more time performing interoperability tests of 
>> implementations, others would have also come to realize these issues 
>> too, and factor that into their work.
>>
>> As far as I know, we are the only one's performing serious WebID-TLS 
>> based ACLs testing against ourselves. Thus, you really need to factor 
>> that into your implementation assumptions re. ACLs, which for all 
>> intents an purposes isn't as far as I know generally standardized etc..
>>
>
> I'm sorry for suggesting that OpenLink's software was in any way 
> insecure or poorly designed.    Knowing you and your company I'm 
> confident that's not the case.   I was being careless in my argument, 
> conflating two different system designs (as explained below).   I'll 
> try to be much more careful in the future.

Sandro,

No apologies required, we are just debating. We aren't strangers to one 
another, so I don't draw such inferences in debates likes these. Even 
when my tone is strong, its just me debating (passionately, my default 
mode).

[SNIP]

>> See my earlier comments about reasoning which has always been 
>> controlled in our products. An ACL engine can't just infer 
>> coreference without any kind of configurable inference modality. 
>> That's an exploit that compromises the system, period.
>>
>
> This is the core of the issue, and it may just be a point on which we 
> have to agree to disagree.
>
> I think systems should be designed so that giving them more correct 
> information will do no harm other than possibly cause performance 
> problems.

Okay, so your concern is a default implementation by the book, so to 
speak, right? Thus, if the ACL system is following RDF semantics, an IFP 
or owl:sameAs inference has to be processed according of their 
respective relation semantics etc..

Sticking with the scenario above, a system can protect a resource purely 
on the basis that an :Account is associated with a WebID as the basis 
for granting Read or Read-Write access. Basically, the WebID 
(unilaterally) isn't the basis of the privilege grant, its the existence 
of a relation that associates a WebID and with a specific :Account that 
achieves this goal.
>
> I might be able to make a principled argument for this preference of 
> mine, but it's kind of a separate issue.

But its a good point for shedding light on the nature of ACLs.

>
>> BTW -- This issue has been raised and discussed over the years re. 
>> WebID and WebID-TLS (from the days of FOAF+SSL).
>>
>>>
>>>>> and what happens when machines figure out all my WebIDs denote me? 
>>>> Now, we have a WebID-Profile document which describes what a WebID 
>>>> denotes. That document is comprised of claims which may or may no 
>>>> indicate co-reference via owl:sameAs and/or IFP based relations 
>>>> (e.g., foaf:mbox). None of this means a WebID denotes an Account.
>>>
>>> I'm not saying it DOES denote an account, just that it SHOULD, in 
>>> order to get the persona-separation that people demand.
>>
>> The Persona separation is already in place. You don't seem to want to 
>> accept that fact. I say that because your claim is only true if we 
>> now conflate a WebID (Identifier) and the WebID-Profile (document) 
>> combined with all RDF claims as being processed as gospel. An 
>> "Account" is another type of thing. A "Persona" is what's discerned 
>> from the claims in an Identity Card or Profile Document.
>>
>> I can make an ACL rule in our system that decides you are only 
>> trusted if your homepage is referenced in a least one blog post or a 
>> blog post that is associated with the tag "#WebID" or whatever. The 
>> ACL system processes relations expressed using RDF. It doesn't have 
>> any hard-coded behavior and it has the option to override certain 
>> relation semantics.
>>
>> All things being equal, you will see a live online shopping system 
>> based on WebID, WebID-Profile, WebID-TLS, and our ACL system. I would 
>> be happy to see you break it.
>>
>>>
>>> It seems clear to me that using WebIDs to denote people is an 
>>> actively dangerous and harmful design.
>>
>> Using an HTTP URI to denote an Agent is an actively dangerous and 
>> harmful design?
>>
>>> Either it should be fixed or WebIDs should be scrapped.    Or, of 
>>> course, you can show how I'm wrong.
>>
>> How can I show you that you are wrong when you don't seem to be 
>> willing to make an actual example i.e.., negate an existing WebID-TLS 
>> based system by getting access to a protected resource. Would you be 
>> ready to try something as practical as that, bearing in mind current 
>> ACL systems aren't even supposed to support owl:sameAs and IFP 
>> relations based reasoning, by default.
>>
>>
>>>
>>>>
>>>> The fact that tools can figure out that an IFP based relation with 
>>>> a mailto: scheme URI as it object is a way to triangulate 
>>>> coreference still has no bearing on the case for a WebID denoting 
>>>> an Account.
>>>>
>>>>> Are you really being careful with every triple you write using 
>>>>> WebIDs to make sure it will still be exactly what you want to say 
>>>>> when a reasoner adds more triples just like it using my other WebIDs?
>>>>
>>>> Absolutely!!
>>>>
>>>> Even when dealing with owl:sameAs, we implement a verifier that 
>>>> won't even invoke an reasoning and inference if those statements 
>>>> are signed by the WebID-Profile document author. Or if those claims 
>>>> aren't part of the certificate (e.g., multiple WebIDs in SAN or 
>>>> using the Data extension to embed Turtle Notation based RDF claims 
>>>> in the certificate).
>>>>
>>>>>
>>>>> It sounds to me like you are not.   It sounds to me like you're 
>>>>> just assuming that certain valid inferences will never be made.
>>>>
>>>> Of course not, as per comment above.
>>>>
>>>
>>> You're saying the inferences will never be made because the 
>>> reasoners will never get hold of the data that would support the 
>>> conclusion that both my WebIDs denote the same person?
>>
>> I am saying even if it did, subject to modality, it wouldn't 
>> necessary perform the inference and reasoning in question (i.e., the 
>> claims expressed in the RDF statements it receives). To us good 
>> design includes understanding that more often than not, stuff 
>> actually goes wrong. I am enthusiastic about open standards but very 
>> pessimistic in regards to  actual design and code implementation.
>>
>>>   I don't think system should ever be built on assumptions like 
>>> that.  It's not just insecure, but it forces us to carefully limit 
>>> the flow of information between systems which trust each other and 
>>> operate on behalf of the same persona.
>>
>> Again, that isn't what I am saying. I am saying: claims that are 
>> *logically truthful* aren't *necessarily factual* in the context of 
>> an ACL system. 
>
> To my understanding, "logically truthful" and "necessarily factual" 
> are synonyms.

Can't be synonyms in a social system. Here's why: you have statements 
inscribed in a digital document that have social consequences. In a 
sense, that's like insinuating that "humor" doesn't exist. Good 
comedians are good basically "context flippers" i.e., the juxtapose 
their "context lenses" with generally conventional "context lenses" en 
route to making you laugh. They are making you imagine all the things 
you presuppose in a different context. The same applies to slang, "the 
new Black" isn't the same as "the new Black" in every human context, 
right? Ditto "He's bad" and "He's bad"  etc..

>
> What I think you're saying is: some claims that are logically truthful 
> will never be present in the ACL system's knowledge base.
>
>> An ACL system operator should be the final arbiter as to what's 
>> factual. Thus, owl:sameAs and IFP relations aren't gospel, they too 
>> are claims which may or may not have sway in regards to actual Trust 
>> determination.
>>
>
> In my view, a system should always "trust" information that it knows 
> to be "true".
>

Subject to processing context.

> I'm uncomfortable with a design where a system has to consider some 
> triples to be untrusted, even though they are true.

A good system has to cater to context fluidity. In my eyes, this is the 
underlying power baked into AWWW.

> I think that's what you're proposing.

I am proposing context fluidity. The ability to be able to apply 
reasoning contextually.

>
> I know systems do have to sometimes disregard triples they know to be 
> true for performance reasons, but I'd rather keep that to being just 
> about performance, not about security.

Ultimately, it has to always factor in security and insecurity. These 
issues even trump performance.
>
>
>> I believe in "context fluidity" and "context lenses" above all else. 
>> As far as I know, that's how the real-world tends to work too.
>>
>
> Combining information from different contexts is very hard, and one of 
> the great things about RDF is you don't have to do it nearly as much.
>
> So, to summarize where I think we are:
>
> * We agree it's important to have the functionality where a person can 
> login different ways and get access to different things

Yes!

> * You say those are different WebIDs and different Personas; I say 
> those are different Accounts

I say, you can have ACLs scoped to accounts without changing anything 
that's already in the WebID, WebID-Profile, WebID-TLS, and WebACLs specs.

That's why one of our basic ACL demos used to be:

Allow access to this protected resource if you (identity denoted by a 
WebID)  are known to TimBL and TimBL is known to you. Basically, stating 
that a reciprocal foaf:knows relation was the basis for protected 
resource access. Of course, that's just an extreme ACL to demonstrate 
(in exaggerated form) what's possible.

> * You keep them distinct by limiting inference

Apply context (subjective) to inference as part of the ACL 
implementation. Ultimately, a resource owner MUST never loose this 
privilege.

> * I think it's better to keep them distinct by having them be distinct 
> resources in the RDF modelling

I think we can triangulate this effectively via RDF statements, as is :-)


Kingsley
>
>        -- Sandro
>
>>>
>>>>>
>
>
>


-- 

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