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.
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.
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
Markus
On Tue, Jul 16, 2013 at 9:58 AM, Drummond Reed <> wrote:
On Mon, Jul 15, 2013 at 11:36 AM, Markus Sabadello <> 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
