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


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]