[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-09-05
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 05 September 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Peter Davis
Markus Sabadello
Andy Dale
Hubert Le Van Gong
Andre Martins
Drummond Reed
Dan Blum
Courtney Brown
Steve Greenberg
Gurusham Sudhir
Joseph Boyle
Les Chasen
Phil Windley
Dan published version 7 of the Policy spec.
We discussed the roles of the Policy spec and the Security Mechanisms and Privacy Mechanisms spec, and how they will guide conformance profiles.
Link Contract Instantiation
Let’s continue to discuss link contracts, templates, instantiation, community contracts, requester contracts, etc.
Let’s first figure out how this topic of link contract instantiation should be covered by the XDI specs, maybe a new separate spec called “XDI Authentication and Authorization”?
Peter pointed out that there needs to be a binding of the link contract instantiation flows to specific scenarios, e.g., brower-based vs. server-based.
Steve compared it to the SAML and OAuth protocol flow bindings, and in particular to the IdP or SP (service provider) initiated-request. In addition, there’s the case of a third-party requesting a connection between two other parties. With OAuth, there’s also the issue of how the tokens are passed—front channel or back channel. Steve believes that link contract instantiation is parallel to these use cases and can borrow from them.
Peter pointed out that UMA also has similar patterns and lexicon. Neither Peter or Steve was not sure whether UMA named the different bindings and flows. Dan said that UMA’s approach was richer than the other two. UMA is based around an authorization service.
Drummond suggested that we just start out putting all of the requirements about link contract instantiation into a spec tentatively titled Link Contract Instantiation. Then as we finish that and other
Markus said that this browser-based flow that has been developed could be considered an additional binding of the messaging spec. Drummond agreed that if the browser-based flows for XDI Messaging can be covered in a binding defined in XDI Bindings, that would make the Link Contract Instantiation spec smaller and keep it focused on that topic.
We briefly discussed that XDI Bindings may have a few bindings in it, but that there would be a small number of them, and they would share some common processing rules.
Drummond asked who is interested enough to volunteer to be an editor for the Link Contract Instantiation spec. Dan, Andy, Gurusham, and Markus volunteered.
Dan has uploaded a new version of the XDI Policy draft spec:
https://www.oasis-open.org/committees/document.php?document_id=54016&wg_abbrev=xdi
Dan said that the new draft represented the new thinking on the patterns for link contract instantiation that have come out of the past two weeks.
He also:
Added the $for word for the usage permissions.
Added the terminology for the different authorities involved.
Added the pattern for community contract.
Renamed the “governor” to the “requestor” link contract.
Replaced the previous Alice-Acme example with a new one.
Notes from a related call on Aug 19 2014 can be found here:
https://www.oasis-open.org/committees/download.php/53921/LinkContractInstantiation17Aug2014.pdf
Notes from a 3 day face-to-face “deep dive” on Aug 27 2014 can be found here:
https://www.oasis-open.org/committees/download.php/53986/xdi%20deep%20dive%202014-8-27.pdf
https://www.oasis-open.org/committees/download.php/53985/linkcontractExamples.pdf
Markus has also been implementing link contract instantiation in order to test out some of our previous patterns. It essentially combined elements of the XDI Bindings, XDI Link Contract Instantiation, and XDI Policy specs. It is only a first step and needs to be harmonized with the most recent work.
Some topics related to this:
Should the standard practice be to save a copy of the link contract template along with the link contract instance, and send a signed copy of both to the RA, so they are always paired, and an audit trail can see the link contract template display info that was shown to the user?
Template versioning - what if the Template Authority changes a template? How does this affect existing link contract instances?
Are community and requester link contracts required for link contract instantiation to work, or are they “good to have” extras?
We have been using variables such as {$from} or {$msg} or {$do}.
Let’s review the topic of variables in general—which spec should this be covered in?
Drummond noted that we did not have time to cover today the question of what spec they should be covered in, but we need to figure this out, given the critical role variables will play in XDI processing and XDI queries (and the role they already play in link contracts).
We discussed to options for variable collections and their syntax.
collection typed, members not typed
[#address]!:uuid:1234
[<#email>]!:uuid:1234
[{$do}]!:uuid:1234
[{<#foo>}]!:uuid:1234
collection typed, members typed
[#address]!:uuid:1234
[<#email>]<!:uuid:1234>
[{<#foo>}]{<!:uuid:1234>}
[{$do}]{!:uuid:1234}
[{$do}]{!:uuid:3456}
Markus explained the basic issue above. Andy then raised the issue of whether we are talking about typing of the members of a collection or just indexing the collection.
Markus mentioned a few uses of variables:
1. link contract templates {$do}
2. policy variables, e.g. {$from}, {$msg}, ...
(=markus/=markus)($do$if/$true){$from}/$is/[=]!:uuid:1111
Andy pointed out that in Java, the members of a collection are not strongly typed. However we agreed that in the XDI graph model we don’t want to support mixed collections—the members of a collection MUST all be of the same type.
We noted that when a link contract template gets instantiated (and the template is a member of a collection), then the member UUID of the link contract instance must match the UUID of the link contract template.
[{$do}]{!:uuid:1234} -> (=drummond/+acme)[$do]!:uuid:1234
Andy felt that this behavior might not be consistent with the UUID concept. But then Drummond explained that this use of UUIDs enabled algorithmic identification of the link contract template that was the source of any link contract instance. That is a valuable property.
Gurusham asked for clarification about the role of the collection and the role of the member: are they type statements or addresses? Drummond said that they are both: the identifier of the node (whether collection node or member node) both identifies the semantics of that node AND serves as the unique address of that node. This is true for all nodes in the graph.
Drummond explained the original reason for typing members of a collection (specifically, using angle brackets around members of an attribute collection) was consistency of the syntax. Markus explained that it has the advantage that you can look at any one arc in the graph and know the type of node (entity, attribute, variable, definition) from the arc alone, without having to backtrack one arc.
CONSENSUS: We concluded that, among the TC members on the call, we have a consensus to go with the typed member pattern. Drummond and Markus have the action item to review this with Joseph. We will only bring this issue back before the TC if Joseph is not in agreement (or if another TC member objects to this conclusion on the list).
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]