[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-10-18
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
Drummond said that sessions on XDI planned for next week at Internet Identity Workshop in Mountain View.
XDI 101 - The Alice and Bob Tutorial (Drummond)
XDI Deep Dive - Understanding the Personal Cloud Stack
Personal Clouds: Risks, Threats, and Countermeasures
Drummond and Joseph said that XDI Core WD01 will be pushed on Monday if they can make enough progress this weekend, but that depends on other deadlines for IIW deliverables.
Drummond reported that added the Message Type statement to the XDI message pattern block on:
https://wiki.oasis-open.org/xdi/XdiMessagePatterns
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.
Drummond, Markus, and Animesh reported on a proposal revision to the standard link contract pattern that arose from of their implementation work:
https://wiki.oasis-open.org/xdi/LinkContractPattern
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”:
Authorizing party
Requesting party
Template ID
Each specializes the $word entity that follows it:
<<authorizing party>>$to<<requesting party>>$from<<template id>>$do
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:
A link contract with $all permission includes all equivalence relation permissions.
Otherwise, the following permissions must be explicitly declared:
$set{$is}
$set{$ref}
$set{$rep}
$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:
=alice/$ref/[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001
He also gave an example of equivalence relations that do NOT cross authority subgraphs:
[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001[<+tel>]<#0>&/&/”+1…”
[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001[<+tel>]<#1>&/&/”+2…”
[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001[<+tel>]<#2>&/&/”+3…”
[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001+home<+tel>/$ref/
[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001[<+tel>]<#0>
He gave an example of how a $set{$ref} permission would be granted:
…$do/$set[$ref}/[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001[<+tel>]
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.
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:
Dictionary definitions (+words or $words).
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:
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
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]