[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-02-14
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 14 February 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Drummond Reed
Dan Blum
Peter Davis
Phil Windley
Joseph Boyle
Markus Sabadello
Les Chasen
Animesh Chowdhury
Markus has completed Part 4 of the XDI Tutorial (about XDI Messaging):
Animesh and Drummond gave Markus high kudos for such a clear explanation of how XDI messaging works.
We reviewed the Link Contract patterns at:
https://wiki.oasis-open.org/xdi/LinkContractPattern
Dan mentioned that he had been working on a “Technical and Operational Specification” for Respect Network, which contains a section on using link contracts for controlling access to Personal Clouds. Dan explained that there are different purposes for link contracts, e.g. between individuals, or between an individual and groups, or link contracts based on external authorization services.
This resulted in a discussion around link contracts and policy _expression_ statements and the potential issues around portability. One question here is whether or not all the information needed to evaluate a link contract is part of the XDI graph. Peter commented that link contracts may become very complex, considering that they may contain a lot of personal preferences.
Drummond clarified that the policy _expression_ associated with a link contract is itself expressed as XDI and should therefore be portable. Peter warned that most likely there will be cases of non-portable (parts of) policy expressions. For example, a CSP in the healthcare space may have an internal policy which may require that only the last 4 digits of a SSN would ever be returned to an XDI client, even if the full SSN is stored in the XDI graph.
Dan mentioned that he and Andy Dale were also concerned with cases like this. It may make sense to distinguish between personal policies that are part of the XDI graph, and CSP-internal policies, which would not be portable. Dan called this an “extensibility point” for CSPs for policy processing. Peter saw a need to view policies as a “framework” within the XDI specs, which RN and others could then profile.
One conclusion was that the XDI Policy Spec should specify very precisely how code should process a link contract and all the policy expressions it contains. Then implementations should try to faithfully conform to that spec so that there is 100% interop to the extent those implementations are conformant.
We next discussed the link contract patterns. Markus explained the “old” approach to link contract paterns (which basically allowed storing link contracts at any arbitrary address in the graph), and the “new” approach which is currently documented on the LinkContractPattern page. This page describes very concrete patterns based on an authorizing party, requesting party, and other components, e.g.:
<--authorizing-authority-->$to<--requesting-authority-->$from<--template-authority--><--template-id-->$do
We agreed that this pattern is very useful for many common link contracts, including the root link contract and public link contract.
Markus asked whether this pattern is a loose recommendation, or whether it is strictly enforced. He also asked if the pattern influences any policy decisions when a link contract is evaluated. Animesh explained that in his opinion, the link contract patterns do not actually affect how a link contract is processed. Drummond agreed, and added that the purpose of these patterns is scoping and uniqueness, not policy evaluation.
Markus next asked whether the above link contract pattern would work for more complex link contracts, e.g. when there are multiple requesting parties. We came up with different options to address this:
- Markus suggested that the “requesting authority” of the pattern could be optional, if it is not obvious who the “requesting authority” is.
- Animesh proposed that in such a case, one would invent an identifier for the abstract/unspecified “requesting authority”.
- Drummond said that scoping is important. If there is no clear “requesting authority”, then unique scope of the link contract has to be achieved in some other way.
Finally, Markus raised two more questions which we did not have time for:
1. The LinkContractPattern page also specifies a pattern for a Meta Link Contract. This pattern is however incompatible with the above mentioned pattern. Markus asked if these two patterns could somehow be more closely aligned.
2. The LinkContractPattern page also specifies a pattern for Link Contract Templates, which just like Link Contracts uses the $do identifier. Markus felt that this was not correct, since Link Contract Templates are not actually themselves Link Contracts. Maybe a different identifier such as {$do} could be used.
Within the XDI2 project, the potential use of I-JSON and JSON Schema for the XDI/JSON serialization format has come up.
We did not have time to discuss this topic.
We will discuss the additions/corrections we want to make to produce XDI Core 1.0 Working Draft 02, including:
MIME types for serialization formats.
Formatting improvements.
Adding missing sections.
Improved Github merging process.
We did not have time to discuss this topic.
None scheduled.
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
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]