[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-10-17
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 17 October 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Dan Blum
Drummond Reed
Markus Sabadello
Hubert Le Van Gong
Patrick Reilly
William Dyson
Peter Davis
Les Chasen
Joseph Boyle
Courtney Brown
Phil Windley
Peter reported that the editors discussed what documentation would be available prior to the XDI hackathon at Internet Identity Workshop.
In terms of spec process:
Peter is going to be getting a new version of the Cryptographic Profiles spec checked in next week.
Drummond said he is planning to work with Joseph on the weekend of the 25-26 on an update to Core.
XDI Policy and Connections
We continued 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:
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
Dan began with a review of the issues discussed last week. The first issue we discussed was portability of XDI policies across different XDI servers. Dan was concerned that policy expressions may not be portable. Drummond said he believed that we needed 100% portability of XDI policy expressions just like with XACML or other policy _expression_ languages. Dan believes that the policy _expression_ sections of the spec need closer review by TC members (and others). We agreed to schedule specific spec review sessions at Internet Identity Workshop Oct 28-30 in Mountain View, CA.
We continued to discuss this topic. We had previously agreed that we need a binding-independent mechanism for correlating messages and message results.
We discussed the following different approaches to messaging:
A pattern where a message is sent, and a message result is returned immediately, e.g.:
MESSAGE
=alice[$msg]!:uuid:1234/$is()/(=bob)
=alice[$msg]!:uuid:1234/$do/(=bob/=alice)....$do
=alice[$msg]!:uuid:1234$do/$get/=bob<#email>
=alice[$msg]!:uuid:1234<$t>/&/"2014..."
=alice[$msg]!:uuid:1234<$sig>/&/"..."
SYNC MESSAGE RESULT
=bob<#email>/&/"bob@gmail.com"
A pattern where a “request message” is followed by a “response message”, e.g.:
REQUEST MESSAGE
=alice[$msg]!:uuid:1234/$is()/(=bob)
=alice[$msg]!:uuid:1234/$do/(=bob/=alice)....$do
=alice[$msg]!:uuid:1234$do/$get/=bob<#email>
(=alice[$msg]!:uuid:1234$do/$set)=bob../../..
=alice[$msg]!:uuid:1234<$async>/&/true
=alice[$msg]!:uuid:1234<$t>/&/"2014..."
=alice[$msg]!:uuid:1234<$sig>/&/"..."
ASYNC RESPONSE MESSAGE
=bob[$msg]!:uuid:5678/$is$msg/=alice[$msg]!:uuid:1234
=bob[$msg]!:uuid:5678/$is()/(=alice)
=bob[$msg]!:uuid:5678<$t>/&/"2014..."
=bob[$msg]!:uuid:5678<$sig>/&/"..."
(=bob[$msg]!:uuid:5678/$get)=bob<#email>/&/"bob@gmail.com"
A pattern where a “request message” is followed by a reference to a response message, if it is not immediately available (“deferred”).
MESSAGE
=alice[$msg]!:uuid:1234/$is()/(=bob)
=alice[$msg]!:uuid:1234/$do/(=bob/=alice)....$do
=alice[$msg]!:uuid:1234$do/$get/=bob<#email>
=alice[$msg]!:uuid:1234<$t>/&/"2014..."
=alice[$msg]!:uuid:1234<$sig>/&/"..."
REFERENCE TO ASYNC RESPONSE MESSAGE
=bob[$msg]!:uuid:5678/$is$msg/=alice[$msg]!:uuid:1234
The advantage of the simple “message result” is that it contains only the result(s) of the original operation. The advantage of the “response message” is that it has a clear correlation to the “request message”, and that it can have all other features of XDI messaging, such as a message ID, timestamp, signature.
If a “response message” is deferred, it can be sent to the sender’s XDI endpoint when it becomes available. This does not require a link contract.
We have discussed the topic of transactional integrity a number of times in the past without reaching a conclusion. This seems to now have new relevance in conjunction with link contract instantiation.
We did not discuss this topic.
Let’s discuss what demos or other sessions we are planning for the upcoming Internet Identity Workshop.
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]