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-11


XDI TC Agenda


Following is the agenda for the unofficial telecon of the XDI TC at:


Date:  Friday, 11 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

XDI.org News

Drummond and Les will report on recent progress.


PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Report on progress on XDI Core and XDI Messaging.


JSON Canonicalization

Joseph will report on the status of this issue at IETF, because it is critical to XDI Signatures.


XDI Message Signing and Validation Demo

If Markus has time, he can show an XDI2 demo of how he is implementing XDI message signing and validation.


XDI Message Typing

In discussion about XDI messaging signing and specific XDI protocol flows (“subprotocols”) such as the Connect flow, the question came up this week about include a protocol version statement in the message. We will discuss whether this should be added to the XDI Message pattern template.


  https://wiki.oasis-open.org/xdi/XdiMessagePatterns


The “Unauthorized $ref Problem”

If there is time, we will return to this issue.

From 2 Weeks Ago

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”

If there is time, we will return to this issue.


From 2 Weeks Ago

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]