[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xdi] Link Contracts revised
I agree with Giovanni. I think the adoption success of XDI is tied to our ability to successfully and convincingly answer the question 'Why use this in addition to or in place of RDF?'. If we do not get our operators right I don't see us being able to answer that question well enough.
Another point on link contracts I'd like to toss out is that as they are they really seem tied to an access-control based authorization model rather than a capability based authorization model like RBAC (role based access control) or ABAC (attribute based access control), or even what I've been calling KBAC (knowledge based access control) - which XDI is well suited for. To that end I wonder if $has is not the right operator to use. Instead maybe something more explicitly related to matching a pattern, such as $matches or $applies.to, might be appropriate. The object of $matches could then be an XDI context template (a concept where the statements in the context represent a filter on subjects, accepting only subjects connected to a sub-graph equivalent to the sub-graph represented by the context statements.
As a use case, lets say you have a link contract representing access to a whiteboard during an XDI TC meeting by Drummond. In other words the links contract participants matches Drummond in his identity as XDI chair and is restricted to a time period with the same start and end times as the XDI TC conference. How would you express this with $has? You couldn't use a template graph because AFAIK $has can't point to a context and intuitively represents something concrete rather than a query/template IMHO.
Using $match an initial cut and would need tweaking would be
@freewebconf+whiteboard$contract!23 (The contract between @freewebconf and =Drummond acting as @OASIS*TC*XDI+chair)
$matches
/
$is
@OASIS*TC*XDI+chair
$currentTime
/
$lowerBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+start
$upperBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+end
Thinking about it I have an even better set of operators: $allow, $deny, so the above becomes (with deny then allow):
@freewebconf+whiteboard$contract!23 (The contract between @freewebconf and =Drummond acting as @OASIS*TC*XDI+chair)
$allow
/
$is
@OASIS*TC*XDI+chair
$currentTime
/
$lowerBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+start
$upperBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+end
$deny
/
FYI, following is my current though on an deny all sub-graph
$deny
/
i.e. All graphs have a set of sub-graphs that includes the null sub-graph.
Hmm, final thought is that the above does not capture who the contractually obligated parties are, just who's authorized (i.e. -Drummond should be there somewhere), but that's for later. Or not, just thought of it...
@freewebconf+whiteboard$contract!23 (The contract between @freewebconf and =Drummond acting as @OASIS*TC*XDI+chair)
$party
=Drummond$contract!45
$allow
/
$is
@OASIS*TC*XDI+chair
$currentTime
/
$lowerBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+start
$upperBound
$sameAs (??)
@OASIS*TC*XDI+cal+meeting($date*2009*Nov*11)+end
$deny
/
For simple ACL based approach...
@freewebconf+whiteboard$contract!23 (The contract between @freewebconf and =Drummond acting as @OASIS*TC*XDI+chair)
$party
=Drummond$contract!45
$allow
/
$is
@freewebconf+whiteboard$contract!23 /$party
$deny
/
-Bill
___________________________________
From: Giovanni Bartolomeo [giovanni.bartolomeo@uniroma2.it]
Sent: Wednesday, November 11, 2009 10:41 AM
To: Markus Sabadello
Cc: xdi@lists.oasis-open.org
Subject: Re: [xdi] Link Contracts revised
Hello Markus,
I understand your concerns! but, I fear that if we do not assign the
correct semantics to operators we risk to have an inconsistent model
(and vanish the advantages of RDF syntax).
The problem highlighted in issue #1 is related to the associativity
(see for example http://en.wikipedia.org/wiki/Operator_associativity)
of the $has operator; as we used right now, this is a left associative
operator.
Therefore
+a+b+c reads as ((+a/+b)/+c)), i.e. (+a+b/+c)
but if we want to compose +a with +b+c the ONLY way I see is to refer
to +b+c is using an xref: (+b/+c)
+a(+b+c) reads as (+a/(+b/+c)), i.e. (+a/+b+c)
therefore, +a+b+c and +a(+b+c) are NOT synonyms.
When +b+c appears as an object in the RDF triple, we probably do not
need to xref it, as there is no ambiguity.
What do you think?
Btw, for the sake of clearness, issue #2 is something different (in my
original mail there are two different issues with two proposed
solutions, not one single issue with two different solutions ;-)
ciao!
Giovanni
Def. Quota "Markus Sabadello" <markus.sabadello@xdi.org>:
> Hey Giovanni,
>
> I think the challenge we have here is to try and align the theoretical /
> scientific background (the XDI metagraph model) with practical, intuitive
> patterns that are easy to use. I don't know if that can always be done. I
> assume when Drummond wrote those link contract examples, he probably tried
> to make it as simple as possible :)
>
> From a practical perspective, I want to be able to easily write and evaluate
> link contracts, e.g. I want a list of all subjects to which a link contract
> grants permissions.
>
> First of all, I don't think $has should sometimes produce subjects with ( ),
> and sometimes not. It seems in your examples the parentheses get added
> "automatically".
>
> For your solution #1, I think to produce subject
> =drummond+friend$contract$sig(=web*markus) I would have to construct my link
> contracts like this:
>
> =drummond+friend$contract$sig
> $has
> (=web*markus)
>
> And for your solution #2, to produce subject
> =drummond+friend$contract(=web*markus$sig), I think I would have to do this:
>
> =drummond+friend$contract
> $has
> (=web*markus$sig)
>
> Both patterns look a bit more complicated than the original, but I guess
> they would work too.. Not sure what makes most sense from a theoretical
> perspective.. I'm basically happy with anything that can be parsed and
> understood by an XDI endpoint that has to evaluate the link contracts.
>
> Markus
>
> On Mon, Nov 9, 2009 at 3:46 AM, Giovanni Bartolomeo <
> giovanni.bartolomeo@uniroma2.it> wrote:
>
>> Hello,
>>
>> I was revising link contracts and I've noted the following two issues:
>>
>> We have this example:
>>
>> =drummond+friend$contract$sig
>> $has
>> =web*markus <-- Drummond adds Markus to this contract
>> -->
>>
>> Thus a new subject is created:
>>
>> =drummond+friend$contract$sig=web*markus
>>
>> ISSUE#1: since $has is left associative (+a+b+c <==> ((+a/+b)/+c)), see
>> mail "Key implications of new metagraph $has definition" (May 4, 2009) this
>> statement is parsed as =web was part of the composite subject
>> =drummond+friend$contract$sig=web, and not part of =web*markus.
>> To solve this, my proposal is to use xref, as follow:
>>
>> =drummond+friend$contract$sig(=web*markus)
>>
>> ISSUE#2: we have now the following entailment (+x+y==>+x+y/$is$a/+y):
>>
>> =drummond+friend$contract$sig(=web*markus)
>> $is$a
>> =web*markus
>>
>> this sounds a bit odd. My proposal is to change the original statement as
>> follow
>>
>> =drummond+friend$contract
>> $has
>> =web*markus$sig <-- Drummond adds Markus to this contract
>> -->
>>
>> This way we have the new composite subject
>> =drummond+friend$contract(=web*markus$sig) which correctly entails
>>
>> =drummond+friend$contract(=web*markus$sig)
>> $is$a
>> =web*markus$sig
>>
>> There would be more to say about the relationship btw $contract$sig and
>> =drummond+friend$contract(=web*markus$sig), OO people (like myself) could
>> see inheritance and polimorphism applied here, but for the moment just stop
>> here, waiting for your comments.
>>
>> Kind Regards,
>> Giovanni
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]