[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-10-04
Following is the agenda for the unofficial telecon of the XDI TC at:
Date: Friday, 04 October 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:
Drummond will give an update on his discussion with Steve Greenberg.
Report on progress on XDI Core and XDI Messaging.
Drummond, Markus, and Dan did work this week on how key pairs for message signing and encryption should be represented in the graph. Following is an example of the singleton pattern for discussion:
$msg$sig$keypair$public<$key>&/&/”...”
$msg$sig$keypair$private<$key>&/&/”...”
$msg$sig$keypair$not$valid$before<$t>&/&/”...”
$msg$sig$keypair$not$valid$after<$t>&/&/”...”
$msg$sig$keypair/$is+/$rsa$2048
The collection version of this pattern would be:
$msg$sig[$keypair]!:uuid:1$public<$key>&/&/”...”
$msg$sig[$keypair]!:uuid:1$private<$key>&/&/”...”
$msg$sig[$keypair]!:uuid:1$not$valid$before<$t>&/&/”...”
$msg$sig[$keypair]!:uuid:1$not$valid$after<$t>&/&/”...”
$msg$sig[$keypair]!:uuid:1/$is+/$rsa$2048
The examples above illustrate two questions about best practices:
Should collections of uniquely identified attributes at the top level of the graph vs. under a specific authority node?
If so, should this apply only to collections containing UUIDs or other globally unique collection member identifiers, or can it appy more broadly?
This was the description of the problem we discussed last week.
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?
Drummond had the following thoughts:
All forms of equivalence relations have this potential problem. In other words, $is, $ref, and $rep all share this issue.
Equivalence relations within an authority’s own graph are not a problem. The issue only arises when equivalence relations need to cross authorities.
Equivalence relations across graphs controlled by the same authority are not a problem. In fact this functionality is in critical to how pseudonyms work in XDI.
Thus the key issue is equivalence relations that cross graphs controlled by different authorities. In this case, a solution is to specify that such equivalence relations must be authorized by the target authority just like any other operation on the target graph.
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]