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

XDI TC Minutes

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

Date:  Friday, 18 October 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


Dan Blum

Drummond Reed

Markus Sabadello

Joseph Boyle

Animesh Chowdhury

Phil Windley


XDI at IIW #17

Drummond said that sessions on XDI planned for next week at Internet Identity Workshop in Mountain View.

  1. XDI 101 - The Alice and Bob Tutorial (Drummond)

  2. XDI Deep Dive - Understanding the Personal Cloud Stack

  3. Personal Clouds: Risks, Threats, and Countermeasures


Progress on Working Drafts

XDI Message Typing

Drummond reported that added the Message Type statement to the XDI message pattern block on:


Animesh asked: is the message type statement required? His feeling was that it should be, because this is what will make servers interoperable.

Markus pointed out that it does make the message more complex to require a message type statement.

Drummond suggested that the XDI Messaging spec editors propose a table of which message statements are required and optional. There was a consensus to take this approach.

Link Contract Pattern Revision Proposal

Drummond, Markus, and Animesh reported on a proposal revision to the standard link contract pattern that arose from of their implementation work:


This revision involves adding one more layer of context to link contract instances. Instead of just requesting party and template, the authorizing party must also be included in order for each link contract instance to be fully qualified not just in the authorizing party’s graph, but in the requesting party’s graph.

Drummond suggested an easy way to remember the order of this pattern is “ART”:

  1. Authorizing party

  2. Requesting party

  3. Template ID

Each specializes the $word entity that follows it:

<<authorizing party>>$to<<requesting party>>$from<<template id>>$do

The “Unauthorized $ref Problem”

Last week we concluded with this proposed solution to the “unauthorized $ref problem”:

If a message requests a $set operation on an equivalence relation ($is, $ref, or $rep) that crosses XDI authority subgraphs, the requesting party MUST be authorized by a link contract permitting this operation on the target graph just like any other authorized XDI operation.

We took the general action item to consider precisely how this rule will be implemented and discuss it on this week’s call.

Drummond makes the following proposal:

  1. A link contract with $all permission includes all equivalence relation permissions.

  2. Otherwise, the following permissions must be explicitly declared:

    1. $set{$is}

    2. $set{$ref}

    3. $set{$rep}

    4. $set($do}

Markus asked, “What does it mean to cross XDI authority graphs?” Drummond said that XDI authority graphs are defined three context: = (for people), @ (for legal entities), and * (for everything else). So a precise definition is that the subgraphs being traversed belong to different XDI authorities. However, Drummond pointed out that if an authority has no subgraph, that might be an exception.

Drummond gave a simple example of an equivalence relation that crosses authority subgraphs:


He also gave an example of equivalence relations that do NOT cross authority subgraphs:






He gave an example of how a $set{$ref} permission would be granted:


This is how Alice would give permission in a link contract for a requesting party to set a $ref into her phone collection.

Dan asked about the real world use cases that originated this issue. Markus explained that it came out of implementing link contract enforcement in XDI2, specifically that a business card in the $public subgraph section of the graph might reference data in other private parts of the graph.

We returned to discussing the original proposal. Markus said he would word the rule this way:

If a message requests a $set operation on an equivalence relation ($is, $ref, or $rep) whose target context node is not covered by the requesting party’s current link contract, then it must be denied. To grant that permission, the link contract MUST provide either: $all, $set, $set{$is}, $set{$ref}. $set{$rep} permission on the target graph.

Drummond noted that if this same approach was extended to the $set{$do} permission for link contracts, this would also solve the “unbounded $set problem”. He also said that if a $set{$do} permission was inherently restricted by a meta link contract, then this approach may work because, even if the requesting party has $set permission, it can only write link contracts which will be allowed under the requesting party’s meta link contract.

We ran out of time for further discussion but will continue it on the list and/or the next call.


Dictionary Syntax

Drummond explained that we have had this on the decision list for a month now but have not prioritized it. However since it is the last remaining syntax issue that he and Joseph need to commit to the XDI Core spec, the two of them worked on it this week. Drummond explained that the problem is that since our syntax simplication last spring, all XDI context functions used exclusively bracket syntax EXCEPT dictionary definitions. For example:

(=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 had suggested another option of using pipes:

|+passport| <== definition

However after considerable reflection about these different options, Drummond proposes a different solution which takes a different architectural approach. Rather than syntax that applies to one node, this approach is to solve the problem by defining a single standard dictionary context node, identified by the + context symbol used by itself, under which all subcontexts are by definition either:

  1. Dictionary definitions (+words or $words).

  2. Dictionary namespaces (the = or @ or * spaces).

++passport <== generic entity definition

+<+tel> <== generic attribute definition

+=personal <== definition namespace for a person (mutable)

+[=]!1234 <== definition namespace for a person (immutable)

+@legal <== definition namespace for a legal entity (mutable)

+[@]!1234 <== definition namespace for a legal entity (immutable)

+*general <== definition namespace for a general entity (mutable)

+[*]!1234 <== definition namespace for a general entity (immutable)

There were no objections to taking this approach, so this will be the operational proposal that Drummond and Joseph will write up in XDI Core.


The decision queue stack is shown on the following three auto-generated Category pages:




See also this list of proposals that need to be developed:



There will no telecon next week due to travel after IIW. The next call will be Friday Nov 1.

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