OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] A quick link contract riddle


Agreed that it's not about implicit or explicit. 

But I think we have to be very precise about "falls within the target graph". A proposed definition would be: "the entire set of statements being requested fall within the target graph". So if the target graph is =a*b, then a request for the statement (=a/()/*b) will succeed because the entire statement falls within the target graph, but ()/()/=a and =a/+friend/=x don't.

The one place where I see a problem is $ref statements. Let's say we have the graph:

=a/$ref/[=]!:uuid:1 
=b/$ref/[=]!:uuid:1 
=c/$ref/[=]!:uuid:1 
[=]!:uuid:1/()/*b

So we have 3 XDI singleton "names" that reference one XDI instance "number" that has one subcontext.

Now, let's say the link contract is:

$do/$get/[=]!:uuid:1*b

What happens to a $get request for ="" now?

My first answer is: it should succeed, because =a/$ref/[=]!:uuid:1 

However, if that is true, then $get requests for ="" and =c*b should both succeed too. But what if the authority for this graph didn't want to reveal that =b and =c were references to [=]!:uuid:1 ? In other words, does that introduce a privacy problem?

I think the answer is that a $ref should be treated as a discoverable reference whereas a $rep should be treated as a non-discoverable reference. This means if we had the graph:

=a/$ref/[=]!:uuid:1 
=b/$ref/[=]!:uuid:1 
=c/$ref/[=]!:uuid:1 
=d/$rep/[=]!:uuid:1
[=]!:uuid:1/()/*b
$do/$get/[=]!:uuid:1*b

Then a $get on =a*b, =b*b, =c*b, or [=]!:uuid:1*b would all succeed, but a $get on =d*b would fail, because a $rep cannot be traversed without explicit authorization.

Agree?


On Tue, Jul 16, 2013 at 2:17 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I agree. Not sure about the wording though. I don't think this has anything to do with implicit or explicit.

I'd just say the link contract applies to all statements that fall within the "target context" of the link contract.

So if the "target context" of the link contract is =a*b, then =a/()/*b still falls into it, but ()/()/=a and =a/+friend/=x don't.

Markus


On Tue, Jul 16, 2013 at 6:59 PM, Drummond Reed <drummond.reed@xdi.org> wrote:
On Tue, Jul 16, 2013 at 1:43 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Yes this makes sense, and with my current implementation the message would indeed succeed.

I was just asking because it feels a bit inconsistent that the link contract would allow a $get on (=a/()/*b), but not on (=a/+friend/=x).
Both statement have the same subject, i.e. they are arcs on the same context node, but still the link contract applies to one but not the other.

The bright line rule I would suggest is that a link contract allows a $get on EITHER an explicit or implicit XDI statement that falls within the object graph of the link contract.

A $get on (=a/()/*b) is an implicit statement that falls within the object graph of the link contract.
 

A similar question applies to XDI2 connectors, e.g. if I "install" a connector to handle the subgraph at =a*b, would the connector also be "in charge" of the statement (=a/()/*b) or not.

Not sure about the idea of "in charge", but can we just use the bright line rule above?
 

BTW I think you would agree that the link contract in the same example would NOT allow the following Message 3:

 =sender[$msg]!1$do/$get/(()/()/=a)
 =sender[$msg]!1/$do/$do


Agreed because under the bright line rule above, (()/()/=a) does NOT fall within the object graph of the link contract. So it would fail.
 



On Tue, Jul 16, 2013 at 9:58 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
On Mon, Jul 15, 2013 at 11:36 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I thought I'd share this with the list:

Let's say we have this graph:

 =a*b<+c>&/&/"hello"
 =a/+friend/=x

And this link contract in the same graph:

 $do/$get/=a*b

Now let's look at the following two messages:

Message 1:

 =sender[$msg]!1$do/$get/(=a/+friend/=x)
 =sender[$msg]!1/$do/$do

Message 2:

 =sender[$msg]!1$do/$get/(=a/()/*b)
 =sender[$msg]!1/$do/$do

Message 1 will obviously fail, because the link contract doesn't cover the requested statement.

Now my question is, will Message 2 fail or succeed? Anyone?

It should succeed. Reason: If the link contract authorizes the sender (which you didn't show any policy for) to get =a*b, then I believe it should authorize the sender to discover that =a has a subcontext *b. In otherwise, implicit context statements should be included in the authorization policy.

If it ends out being a security issue, I could see us adding a policy statement covering whether discovery of implicit statements is allowed under the link contract or not.

Is that what you are asking?

=Drummond 






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]