Re: Extending the WebID protocol with Access Delegation

On 8/17/12 4:35 AM, Olivier Berger wrote:
> Hi.
>
>
> Henry Story <henry.story@bblfish.net> writes:
>
>> Of interest to both RWW and WebID group:
>>
>> Sebastian Tramp, Andrei Sambra, Philip Frischmuth, Michael Martin, Sören Auer and I have submitted a paper entitled "Extending the WebID protocol with Access Delegation"  for the ISCW 2012, 3rd International Workshop on Consuming Linked Data
>>   
>>     http://bblfish.net/tmp/2012/08/05/WebID_Delegation.pdf
>>
>> The paper has not been accepted yet, and the review process will very likely allow us to revise parts of it. But the review process can start here already. Feedback, ideas and implementations are welcome :-)
>>
>> More pointers on the wiki
>>     
>>     http://www.w3.org/wiki/WebID/Authorization_Delegation#External_pointers
>>
> Thanks for sharing this preprint.
>
> I have a concern I'd like to share with you about the security of the
> protocol. I'm not a security expert, so I hope you can correct me ;-)
>
>
> In the basic WebID auth protocol, the "physical presence" of the agent
> connecting is the validation of the TLS negociation when the client cert
> is submitted, which relies on the user "owning" the private key of the
> credential passed to the server (which relies on the security of the
> browser key cert and likes).
>
> So everytime an agent uses her WebID, you can "trust" that she's really
> acting in person more or less.
>
> Now, let's suppose that that agent delegated her auth to a secretary
> hosted on another server than her's which gets eventually cracked.
>
> So let's say we have :
> <http://freedombox.alice.com/alice#me>
>    :secretary <http://freedombox.p0wned.com/secretary#me>.
>
> the freedombox.p0wned.com system is in control of anyone but Alice, now,
> and any WebID cert can replace that of the original secretary's.
>
> There's no need for the servers to detect that a spammer pretending acting
> On-Behaf-Of http://freedombox.alice.com/alice#me is no longer in control
> of Alice.
>
> I think there may be a possibility harden this a bit if we add an
> additional requirement that the secretary's WebID is "signed" by her
> owner's cert, or that the owner declares the secretary's cert's public
> key in addition to her own's.
>
> Now we would have :
> <http://freedombox.alice.com/alice#me>
>    cert:key [...];
>    :secretary <http://freedombox.p0wned.com/secretary#me>;
>    :secretary_key [...]
>
> Anyone getting control of the freedombox.p0wned.com could still make use
> of the delegated WebID at will, of course, but it would be harder to
> trick the DNS system to just act as a man in the middle.
>
> What's your opinion ?
>
Nice point!

In my eyes, that's another SPARQL ASK ACL that will function once 
there's a triple in the secrataries profile that enables the ACL engine 
get to the graph to describe above.

My fundamental point is that we have to separate protocols from ACL 
based rules. Taking the rules approach via SPARQL ASK (for instance) is 
the key to "deceptively simple" dexterity when building a security 
matrix, especially in today's world where social relationship semantics 
are a critical factor, ditto nyms (different types of denotations for 
entities i.e., psuedonyms, mononyms, aptonymns etc..).

To conclude, we want to use structured data (as delivered by linked data 
resources) to drive ACL based rules. We can use pingback notifications 
to move triples around social, professional, personal networks etc..


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen