Minutes: XDI TC Telecon Friday 2014-11-07

XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 7 November 2014 USATime:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
William DysonLes ChasenPeter DavisDrummond ReedMarkus SabadelloHubert Le Van GongDan BlumJoseph BoyleAmanda NavarroBrian Wu
GUESTSREGRETS
Phil Windley
PRESENTATIONS/DISCUSSIONSReport from XDI editors subcommitteehttps://wiki.oasis-open.org/xdi/XdiOneSpecshttps://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

No Editor’s Committee call today.

ABNF and removal of value context nodes

Drummond and Joseph reported that work is ongoing on the ABNF. Joseph has not updated the ABNF on the wiki page yet, but should make progress on it this week.

Drummond is working through text edits on the next draft of XDI Core.

Markus is working on implementing the removal of value context noes:

http://xdi2.projectdanube.org/no-value-node

https://github.com/projectdanube/xdi2/tree/no-value-node

Markus thinks the change works well. Markus would like to try using an automatic parser generator (e.g. APG) for XDI2 as soon as there is a complete ABNF.

Glossary

Continue work on this: https://wiki.oasis-open.org/xdi/Glossary. Markus suggests that we use this as we are harmonizing definitions, then move it into DocBook.

XDI Policy and Connections

Let’s continue to discuss XDI connection requests, connection invitations, link contracts, templates, community contracts, requester contracts, etc.

Open topics:

Insight: A link contract instance may be used by many authorities that can satisfy a policy _expression_ (e.g. groups, roles, organization membership)

Insight: Just like there can be a connection invitation, there can also be invitations for any other operation, e.g. $get

Review what happens when a connection invitation is processed.

What do “deferred” connection requests look like, and how are they processed? How do we handle cases where user interaction is required?

Template versioning - what if the Template Authority changes a template? How does this affect existing LC instances? Should versioning for LC templates be mandatory?

Topics discussed previously:

Discuss different ways for an RA to receive a copy of a new link contract instance

Challenge of correlating message requests and responses (see below)

Issue related to having multiple link contract instances based on one link contract template (how to algorithmically determine the address?)

Collection of Documents:

XDI Policy draft spec:

https://www.oasis-open.org/committees/download.php/54276/XDIPolicyDraft%20v8.docx

XDI Connections draft spec:

https://www.oasis-open.org/committees/download.php/54279/XDI%20Connections%20V1.docx

Link Contract Instantiation:

https://www.oasis-open.org/committees/download.php/54205/LinkContractInstantiation25Sep2014.pdf

Community Link Contracts:

https://www.oasis-open.org/committees/download.php/54287/Community%20link%20contracts%20-%20Google%20Docs.pdf

Berkeley Deep Dive notes:

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

We began the discussion talking about Jira issue 38, which describes the types of policy _expression_ statements. We agreed there are 3 branches:

$do branch—operational permissions

$if branch—conditional policies.

$for branch—usage policies (what XACML calls obligations)

Hubert suggested that we adopt the terminology of XACML for describing policies.

ACTION ITEMS:

ALL: Review XACML 3.0 terminology.

DRUMMOND: Review this section of policy spec with Dan and make recommendations.

We next discussed this insight from Dan’s and Markus’ sessions in Vienna:

Insight: A link contract instance may be used by many authorities that can satisfy a policy _expression_ (e.g. groups, roles, organization membership)

There was a consensus that this was a powerful feature of XDI link contracts.

ACTION ITEM TO POLICY SPEC EDITORS:

Add text to the spec explaining this feature and giving several examples.

We next discussed the idea of inverse operations, i.e, this insight from Dan’s and Markus’ list:

Insight: Just like there can be a connection invitation, there can also be invitations for any other operation, e.g. $get

Markus explained the use case for inverse operational statements

Connection Request:  =ra[$msg]!:uuid:1234$do/{$do}/+ta#newsletter{$do}

Connection Invitation:  =aa[$msg]!:uuid:1234$do/$is{$do}/+ta#newsletter{$do}

$get Invitation:  =aa[$msg]!:uuid:1234$do/$is$get/=aa<#email>

Dan suggested that we should have a section in XDI Core that explains inversion (already captured in Jira issues 22 and 23) and how it works generically in all XDI statements. Drummond agreed.

ACTION ITEM TO POLICY AND/OR CONNECTION SPEC EDITORS:

Add an example of how to use inverse operations in XDI operational policies.

ACTION ITEM FOR MESSAGE SPEC EDITORS:

Add discussion of inverse operations in message policies.

We next discussed community link contracts and the bootstrap issue, i.e., how does an XDI authority join a new community before the authority has any community contract (or a new community that is not related to any existing community contract). 

ACTION ITEM FOR XDI POLICY SPEC:

Review the link contract patterns, including the community link contract patterns

Add/enhance the text on how to bootstrap link contracts using the root link contract

We still have the open issue of how to handle when user intervention is required to approve a connection request. We need to define this vocabulary.
Transactional integrity
We did not have time to discuss this topic.
NEXT CALL
The next call is next week at the regular time.