[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Agenda: XDI TC Telecon Friday 09:00 - 10:30AM PT 2013-09-27
Following is the agenda for the unofficial telecon of the XDI TC at:
Date: Friday, 27 September 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
THE LINK TO THIS AGENDA AND LIVE MEETING MINUTES IS:
https://docs.google.com/document/d/1t5Mx0ITqJdLwo8wM5GD9lcqehgbgnrhk-k2sERwc7J0/edit
THE WEBEX INSTRUCTIONS FOR THIS MEETING ARE:
1. Go to https://neustar.webex.com/neustar/j.php?ED=203186612&UID=1364257662&PW=NN2Y2NzAxZTVj&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 5474
4. Click "Join".
5. Follow the instructions that appear on your screen.
To view in other time zones or languages, please click the link:
Discuss our goals for this conference.
Confirm our decision on the spec change commit progress.
Report on progress on XDI Core and XDI Messaging.
We will continue our discussion of link contract initiation and the three related versions of a link contract:
Link contract template.
Link contract instance.
Meta link contract.
See https://wiki.oasis-open.org/xdi/LinkContractPattern
Work on link contract implementation has surfaced the following problem: If a link contract gives you access to a certain part of a graph, and that part of the graph contains a $ref or $rep equivalence relation, and the target of that relation is not covered by the link contract, what should happen?
For example:
Graph:
([=]!:uuid:1111)/$ref/()
()/$is$ref/([=]!:uuid:1111)
(=demo2)/$ref/([=]!:uuid:1111)
[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend
[=]!:uuid:1111+friend$do/$get/[=]!:uuid:1111+profiles[<+work>]
[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})
[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)
[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>
[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>
[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"
[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"
[=]!:uuid:1111/+friend/[=]!:uuid:2222
=demo2/$ref/[=]!:uuid:1111
$do/$all/()
$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)
$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)
Message:
[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)
[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do
[=]!:uuid:2222[$msg]!:uuid:3333$do/$get/[=]!:uuid:1111+profiles[<+work>]
Message Result:
[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>
[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>
[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"
[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"
Problem Description:
The first name and last name are returned, even though they are not covered by the +friend$do link contract that is being used. The threat here is that if one has access only to a very limited part of a graph, they might just add a $ref equivalence relation to another part of the graph that they should not be authorized to access.
Is this problem similar to symbolic links in UNIX filesystems?
Proposed Approaches:
#1: Do not process $ref and $rep equivalence relations if their target is not covered by the current link contract.
#1A: Ignore them.
#1B: Or raise a link contract error.
#2: Somehow add semantics to the link contract to specify if and how $ref and $rep equivalence relations should be processed.
#3: Somehow limit the ability to create $ref and $rep equivalence relations in the first place
#3A: Allow their creation only if the creator has access to the target. (Animesh’ idea)
#3B: Only allow the owner of the graph to create them.
#3C: Define a new type of permission, e.g. $set.ref (Andy’s idea)
#4: Others?
A second link contract issue: if a link contract gives you $set access to a very limited part of a graph, you may add an arbitrary link contract to that part of the graph, and in a subsequent message refer to it in order to obtain any desired access to the graph.
For example:
Graph:
([=]!:uuid:1111)/$ref/()
()/$is$ref/([=]!:uuid:1111)
(=demo2)/$ref/([=]!:uuid:1111)
[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend
[=]!:uuid:1111+friend$do/$set/[=]!:uuid:1111+profiles
[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})
[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)
[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>
[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>
[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"
[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"
[=]!:uuid:1111/+friend/[=]!:uuid:2222
=demo2/$ref/[=]!:uuid:1111
$do/$all/()
$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)
$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)
Message:
[=]!:uuid:2222[$msg]!:uuid:3333/$is()/([=]!:uuid:1111)
[=]!:uuid:2222[$msg]!:uuid:3333/$do/[=]!:uuid:1111+friend$do
[=]!:uuid:2222[$msg]!:uuid:3333$do/$set/([=]!:uuid:1111+profiles$do/$all/())
Graph after Message:
([=]!:uuid:1111)/$ref/()
()/$is$ref/([=]!:uuid:1111)
(=demo2)/$ref/([=]!:uuid:1111)
[=]!:uuid:1111+friend$do/$all/[=]!:uuid:1111+friend
[=]!:uuid:1111+friend$do/$set/[=]!:uuid:1111+profiles
[=]!:uuid:1111+friend$do$if$or/$true/([=]!:uuid:1111/+friend/{$from})
[=]!:uuid:1111+friend$do$if$or/$true/({$from}/$is/[=]!:uuid:1111)
[=]!:uuid:1111+profiles[<+work>]<!:uuid:4444>/$ref/[=]!:uuid:1111+last<+name>
[=]!:uuid:1111+profiles[<+work>]<!:uuid:5555>/$ref/[=]!:uuid:1111+first<+name>
[=]!:uuid:1111+profiles$do/$all/()
[=]!:uuid:1111+first<+name>&/&/"Demo2FirstName"
[=]!:uuid:1111+last<+name>&/&/"Demo2LastName"
[=]!:uuid:1111/+friend/[=]!:uuid:2222
=demo2/$ref/[=]!:uuid:1111
$do/$all/()
$do$if$and/$true/({$from}/$is/[=]!:uuid:1111)
$do$if$and/$true/({$msg}$secret<$token><$valid>&/&/true)
Problem Description:
Using the new link contract [=]!:uuid:1111+profiles$do, full access to the entire graph is possible for everyone. The location of the link contract in the graph does not affect the permissions granted by the link contract.
Possible Approaches:
#1: Somehow specify that the location of the link contract in the graph affects the permissions granted by the link contract.
#2: Somehow limit the ability to create link contracts in the first place
#2A: Allow their creation only if the creator has access to the target.
#2B: Only allow the owner of the graph to create them.
#2C: Define a new type of permission, e.g. $set.do
#3: Other ideas?
#4: Drummond’s idea specific to the meta link contract pattern:
What if, instead of the meta link contract pattern looking like this...
<--from-->{$to}$do/<--operation-->/<--to--><--from-->$do
...it looked like this:
<--from-->{$to}$do/<--operation-->/<--to--><--from-->{$do}
In short, we would specify that if a meta link contract target graph ends with the typed variable {$do}, the permitted operation only applies to an instance of the link contract template. So the authorizer can $set an instance of the link contract template, $get an instance (even though they already have a copy), and $del an instance of the link contract template—but that's it.
As Drummond works on the XDI Core spec, one inconsistency that has been bothering him is that, after our syntax simplication last spring, all XDI context functions used exclusively bracket syntax EXCEPT dictionary definitions.
(=markus) <== root
[+passport] <== collection
<+tel> <== attribute
{foo} <== variable
$(+passport) <== definition
It would be cleaner and easier if there was also a uniform bracket syntax for definitions. One option would be to use double brackets:
[[+passport]] <== definition
Markus suggested another option of using pipes:
|+passport| <== definition
And one more thought is not to use brackets at all but define the a dictionary context by using a single instance of a class context symbol. This could be either + or $, i.e.:
++passport <== definition
$+passport <== definition
The decision queue stack is shown on the following three auto-generated Category pages:
https://wiki.oasis-open.org/xdi/CategoryLastCall
https://wiki.oasis-open.org/xdi/CategoryCurrent
https://wiki.oasis-open.org/xdi/CategoryHighPriority
See also this list of proposals that need to be developed:
https://wiki.oasis-open.org/xdi/XdiPendingIssues
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]