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-09-27


XDI TC Agenda


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:

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


AGENDA

NEWS & UPDATES

Preparations for Fall IIW 2013

Discuss our goals for this conference.


PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Confirm our decision on the spec change commit progress.


Report on progress on XDI Core and XDI Messaging.


Link Contract Initiation

We will continue our discussion of link contract initiation and the three related versions of a link contract:

  1. Link contract template.

  2. Link contract instance.

  3. Meta link contract.


See https://wiki.oasis-open.org/xdi/LinkContractPattern


The “Unauthorized $ref Problem”

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?



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]