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: Agenda: XDI TC Telecon Friday 09:00 - 10:30AM PT 2013-10-04


XDI TC Agenda


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:

https://neustar.webex.com/neustar/j.php?ED=203186612&UID=1364257662&PW=NN2Y2NzAxZTVj&ORT=MiMxMQ%3D%3D


AGENDA

NEWS & UPDATES

Developer's Guide to XDI for Fall IIW 2013

Drummond will give an update on his discussion with Steve Greenberg.


PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Report on progress on XDI Core and XDI Messaging.


XDI Message Signing and Key Pairs

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 Top-Level Pattern Question

The examples above illustrate two questions about best practices:

  1. Should collections of uniquely identified attributes at the top level of the graph vs. under a specific authority node?

  2. If so, should this apply only to collections containing UUIDs or other globally unique collection member identifiers, or can it appy more broadly?


The “Unauthorized $ref Problem”

From Last Week

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?

Additional Comments Coming Out of Last Week’s Discussion

Drummond had the following thoughts:

  1. All forms of equivalence relations have this potential problem. In other words, $is, $ref, and $rep all share this issue.

  2. Equivalence relations within an authority’s own graph are not a problem. The issue only arises when equivalence relations need to cross authorities.

  3. 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.

  4. 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.



The “Unbounded $set Problem”

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.



DECISION POINTS FOR THIS CALL

Dictionary Syntax

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



DECISION POINT QUEUE REVIEW

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


NEXT CALL

The next call is next week at the regular time.




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