[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-10-10
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 10 October 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Les Chasen
Peter Davis
Joseph Boyle
Dan Blum
Amanda Navarro
Hubert Le Van Gong
William Dyson
Markus Sabadello
André Martins
Gurusham Sudhir
Drummond Reed
Andy Dale
Dan has uploaded version 8 of XDI Policy, and version 1 of XDI Connections. Dan has also uploaded a working document about community link contracts.
Markus reported he had been working on XDI Messaging a bit, but not uploaded anything.
We discussed once again how to correctly reference XSL stylesheets from the Docbook files to display them properly. Markus mentioned he had successfully followed Peter’s advice to use relative paths. Right now, different Docbook files in our repository do it in different ways, at some point we have to harmonize these.
Dan+André+Markus have been meeting in Vienna this week to discuss current issues around the XDI Policy and XDI Connection specs, as well as preparations for the upcoming IIW conference, e.g. the XDI Hackathon.
Markus reported that the discussions during the meeting were basically on the same topics that had also been the focus of recent TC calls, i.e. everything related to link contracts, connections, policies, etc. The new documents uploaded by Dan (XDI Policy v8, XDI Connections v1, Community Link Contracts) reflect many new insights and proposals that were developed during the Vienna meeting. Markus said he feels comfortable about the relationships between the XDI Policy, XDI Connections, and XDI Bindings specs, which depend on each other in various ways.
Peter said he noticed that the XDI Connections spec does not reference XDI Bindings. Markus replied he was not sure whether it should or not, considering that connection requests/invitations are just XDI messages, which could be delivered over any binding. Some combinations of connection requests/invitations and bindings may in practice make more sense than others.
While talking about XDI Connections and XDI Bindings, we discovered an issue that has simultaneously also come up during the Vienna Deep Dive: The need to clearly correlate messages and their results. Do results need IDs that match the message IDs? This topic seems to be generic for all XDI messages, but may have special relevance for connection requests/invitations. Peter said this may be a bigger issue in some bindings than in others. Dan commented he felt that the inability to correlate messages and message results will cause problems in some way. Hubert and Peter both proposed that there should be a generic (binding-independent) mechanism to correlate messages and their results. Hubert added that although this mechanism should be defined in a generic way, it may only be “triggered” by certain bindings that don’t have implicit correlation. We had consensus on this.
# ACTION ITEM: Markus suggested that any of the editors or other contributors to the XDI Messaging spec should propose a mechanism that can achieve binding-independent correlation.
Example 1: Very simple $get using XDI Direct Binding:
=alice[$msg]!:uuid:1234/$is()/(=bob)
=alice[$msg]!:uuid:1234$do/$get/=bob<#email>
=bob<#email>&/&/”bob@email.com”
… nothing else needed here, correlation is implicit by the binding ...
Example 2: Connection request using XDI Browser Binding:
=alice[$msg]!:uuid:1234/$is()/(=bob)
=alice[$msg]!:uuid:1234$do/{$do}/+ta#hello{$do}
... link contract successfully instantiated …
…correlation may be implicit by the binding ...
…or maybe explicit correlation is needed to =alice[$msg]!:uuid:1234 ...
In the first example, no explicit correlation is needed, since it is implicit in the XDI Direct Binding (same HTTP TCP/IP connection). In the second example, correlation may also be implicit (same HTTP browser session), or explicit correlation may be needed, if there are many steps between the message and its result.
We then focused on the topic that sometimes message results can be “deferred” (not immediately available), e.g. in the case of a connection request that requires user interaction. Peter explained that in User-Managed Access (UMA), there are many cases where success or failure decisions are deferred until user interaction can occur, and that similar problems exist in SAML.
We also seem to have some uncertainty about terminology in XDI messaging, e.g. “message”, “request”, “response”, “result”. Markus explained he had been thinking in terms of “messages” and “message results”.
Finally, we recalled that we are planning an XDI Asynchronous Messaging spec, but did not come to understanding how exactly this spec relates to the above issues.
Joseph asked a few questions about XDI Messaging: How are message IDs generated and handled? Markus responded that he thinks we haven’t discussed this sufficiently yet. The purpose of message IDs is to be able to uniquely identify messages, which is meant to be the basis for signatures, protection against replay attacks, and other security features. Joseph was worried message IDs could potentially be exhausted. Peter replied that the scope of message IDs is constrained by the sender and recipients, and that exhaustion of UUIDs is unlikely. Joseph then asked if a server’s address was constant. Peter said a server’s endpoint IP / URI may change constantly, e.g. in the case of a mobile device. On the XDI level, persistent addresses (cloud numbers) are used that do not change. Joseph was also interested in additional bindings that use persistent connections. Markus said many additional bindings would be possible.
XDI Policy and Connections
Let’s continue to discuss XDI connection requests, connection invitations, link contracts, templates, community contracts, requester contracts, etc.
We talked about several issues/proposal Dan, André and Markus have discussed during the Vienna Deep Dive.
Dan reported on new thoughts about the requestor link contract. We discussed several ways how a Requesting Authority (RA) can obtain a copy of a newly instantiated link contract. Should the use of a requestor link contract be mandatory, which would allow an Authorizing Authority (AA) to write the copy to the RA’s graph? And/or should a new link contract be directly returned in the message result of the connection request? There seem to be three options for such results:
Option 1: $true or (empty) ## only “success” or “failure”
Option 2: (=bob/=alice)+ta#hello$do ## the link contract address
Option 3: (=bob/=alice)+ta#hello$do/..../… ## a copy of the entire link contract
We recalled that previously we had already recognized the importance of having a copy of a link contract in both graphs, e.g. for audit purposes.
Markus then explained another challenge which has come up during the Vienna Deep Dive. We had said that given an RA, AA, and link contract template address, it must be possible to algorithmically determine a link contract address (so that an RA does not have to remember/store it). This does not seem to be possible however if the same AA has multiple link contracts for the same RA based on the same link contract template. Markus gave the example of a pizza delivery service asking customers to share their address. If Markus desired pizza delivery to both his home and work address, he would have to instantiate the same link contract template twice. We did not come to a conclusion on this topic, but it may not actually represent a problem.
We did not have time to cover the following 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.
Template versioning - what if the Template Authority changes a template? How does this affect existing LC instances? Should versioning for LC templates be mandatory?
What do “deferred” connection requests look like, and how are they processed?
Markus encouraged all participants of the call to review Dan’s XDI Policy and XDI Connections draft specs, or to provide any other input related to the above topics.
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
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.
The following document has a section titled “XDI Message Transactional Integrity Notes”, let’s review and discuss:
https://www.oasis-open.org/committees/download.php/53921/LinkContractInstantiation17Aug2014.pdf
We did not discuss this topic.
Let’s discuss what demos or other sessions we are planning for the upcoming Internet Identity Workshop.
We did not discuss this topic.
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]