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: Minutes: XDI TC Telecon Friday 2013-10-11


XDI TC Minutes


Following are the minutes of 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)


ATTENDING

Animesh Chowdhury

Drummond Reed

Markus Sabadello

Phil Windley

Joseph Boyle


GUESTS (for final portion)

Steve Greenberg

Andy Dale

NEWS & UPDATES

XDI.org News

Drummond and Les reported that a new set of contracts for XDI infrastructure services is just being concluded and will be announced at Internet Identity Workshop (Oct 22-24 in Mountain View).


PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Drummond reported that he is set up with Oxygen now and, thanks to Joseph, with Github coordination. He and Joseph also did some work on the ABNF for XDI Core, and both of them plan to make progress on preparing Working Draft 01 in time for IIW.


Markus will also try to do some work on XDI Messaging on his flight to IIW.


JSON Canonicalization

Joseph reported on the status of this issue at IETF, because it is critical to XDI Signatures. He said that there is much debate over the issue in the IETF on this subject, however it may only affect comparing JSON values.


We talked about how other JSON specs that deal with signatures, e.g., JWS, handle this issue. Markus said that JWS does not tackle the question.


Markus explained that what XDI2 does when saving XDI JSON documents is convert literals into Java values, which will not always work for a roundtrip match. An example is converting a JSON value of 5 to a Java number might result in 5.0. That would break an XDI signature if the signed XDI message was reconstituted after storage. Markus considers it an XDI2 bug; there is consensus that the exact JSON value should be roundtrippable.


# JOSEPH to continue to think about how best to specify this in XDI Core, particularly white space and number comparison.


XDI Message Signing and Validation Demo

Markus gave a demo using the XDI2 Discoverer and XDI2 Signer utilities of how he is implementing XDI message signing and validation.


$public

We clarified that the semantics of the $public dollar word is that no authorization is required to access a resource in this subgraph. We will need to specify a different $word, or a specialization of this $public, to impose other requirements, e.g., the resource is available just to an authenticated sender.

$anon

This led us to a short discussion of the $anon dollar word, which has been in the XDI $ Dictionary wiki page for the last few months. The original motivation for $anon was contractual anonymity, i.e., for link contracts that can share data explicitly referenced using $rep equivalence relations from a $anon subgraph so that the requesting party agrees that this data MUST be kept anonymous.

However Drummond agreed with Markus that $anon could also be used as an XDI subject for anonymous messaging when needed. He noted that the security implications of doing this require more research.

XDI Message Typing

Our next discussion grew out of work Animesh and Markus were doing this past week on XDI messaging signing and specialized XDI protocol flows such as the Connect flow. They raised the question of whether such a specialized protocol should include a protocol version statement in the message, and if so, should we add this to the XDI Message pattern template at:


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


There was agreement that this was generally a good idea for both forwards and backwards compatability. We then identified that there were two questions to answer:


  1. Is the appropriate context for this XDI statement the outer root node or the [$msg] entity node?

  2. How do we specialize this statement to describe specialized versions of the XDI protocol (“subprotocols”)?

Regarding the first question, Markus observed that it depends on whether we want to be able to send multiple messages of different version types in one envelope. He suggested there were three options:

  1. Describe the outer root of the message envelope only.

  2. Describe each message only.

  3. Describe the outer root and then allow individual messages to override.

Animesh said that this statement should convey these pieces of information:

  1. What version of XDI syntax overall is being used in the message?

  2. What type and version of specialized protocol is being used?

  3. What type of message within that specialized protocol is being used?

Drummond suggested the following pattern for a statement describing the type and version of XDI syntax used for an XDI graph (any graph, including an XDI message):

()/$is+/$xdi[$v]#0

He suggested this pattern for a statement describing the type and version of a specific XDI message contained within the XDI graph:

()/$is+/$xdi[$v]#0

To deliberately match OASIS naming conventions, we could go immediately to V1.

()/$is+/$xdi[$v]#1

Drummond explained that to express minor versions (“subversions”) would use this pattern:

()/$is+/$xdi[$v]#1[$v]#0

With regard to the second question of specializations of the XDI protocol, Drummond suggeseds following the standard specialization pattern, i.e., using supercontexts to specialize the described context. For example, if the context was a connect request, and the TC assigned that context the XDI address of $connect, then the specialization would be:

()/$is+/$connect$xdi[$v]#0

If a sender needed to identify a specific message within the Connect protocol, this context would be further specialized. For example:

()/$is+/$discovery$connect$xdi[$v]#0

This pattern can be adapted to other generic protocol definitions using +words. Example:

()/$is+/+health$connect$xdi[$v]#0

This pattern could also be adapted to highly specialized protocol definitions using other authority context symbols. For example:

()/$is+/=markus$connect$xdi[$v]#0

Markus asked if these should include the $msg entity. For example:

()/$is+/=markus$connect$xdi[$v]#0$msg

We agreed we need to think more about that.

In our discussion, there was a concensus that this XDI graph type and XDI message type statements could be used for:

  1. Message validation on an XDI server.

  2. Constraints on associated link contracts for authorization.

  3. Backwards compatibility.

We agreed on the following action items from this discussion:

  1. Think about the $msg question (should it be included).

  2. Add message type statement(s) to the XDI Messaging Pattern template.

  3. Add a section to that wiki page explaining usage.

# DRUMMOND OR MARKUS will follow through on these action items.


The “Unauthorized $ref Problem”

The following notes are from previous minutes to provide context. See the new discussion at the end.

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.

New Discussion

Animesh made the comparison of XDI equivalence relations to Unix symbolic links, and specifically that the creation of a symlink cannot change the permissions of the object it points to.

Steve said the comparison is apt, because in Unix, the current folder is always the current context, and you always have a current effective userID. Unix also has a setUI bit that you can use to run something with the userID assigned to it.

Steve suggested that XDI could apply the same model to XDI contexts.

Andy gave an example of having a bizcard in the $public subgraph, with $ref pointers to 3 email addresses that are not in the $public subgraph. It should not require a separate link contract to access these 3 email addresses if there are $ref equivalence relations pointing to them from within the $public subgraph.

We then discussed the policy model, and clarified the way it works:

  1. The requested operation on the target graph must be subject to one link contract singleton or collection.

  2. If the policies in that link contract singleton or collection evaluate to true, then the message sender is authorized.

Animesh summarized the problem as, “What permissions travelled with a $ref”?

Drummond questioned this framing of the “unauthorized $ref problem” because the permissions should not “travel” with the $ref. Rather the setting of a $ref (or $rep or $is) relation should be subject to the same constraints as other XDI operations.

Finally, Drummond summarized the proposed solution this way: to do a $set on an equivalence relation ($is, $ref, or $rep), a requesting party MUST be permissioned by a link contract similar to any other authorization within an XDI graph.

# ALL TC MEMBERS have the action item to consider precisely how this rule will be implemented.

# DRUMMOND to add this to the agenda for next week’s call.


DECISION POINTS FOR THIS CALL

Dictionary Syntax

Although we ran out of time to discuss this issue, Drummond noted that he was leaning towards the final proposal below, i.e., by defining the dictionary context to be a single + context symbol.


# DRUMMOND to further flesh out this proposal.


From Previous Calls

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]