OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] Minutes: XDI TC Telecon Friday 2014-10-17


Markus, great notes. Everyone: this was another very productive call. Having a clear and "as simple as possible but no simpler" answer for how the XDI protocol handles both sync and async messaging would be a real win.

=Drummond 

On Fri, Oct 17, 2014 at 2:36 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

XDI TC Minutes


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)

ATTENDING

Dan Blum
Drummond Reed
Markus Sabadello
Hubert Le Van Gong
Patrick Reilly
William Dyson
Peter Davis
Les Chasen
Joseph Boyle
Courtney Brown

GUESTS

REGRETS

Phil Windley

NEWS & UPDATES

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

https://wiki.oasis-open.org/xdi/XdiOneSpecs
https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook


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:

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


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.

Correlating message requests and responses

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:


  1. 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"


  1. 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"


  1. 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.

Transactional integrity

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.

IIW Preparations

Let’s discuss what demos or other sessions we are planning for the upcoming Internet Identity Workshop.

NEXT CALL

The next call is next week at the regular time.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]