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: Added XDI Connections spec to the wiki list of XDI specs - and question about Bindings

Per the discussion on yesterday's TC call, I added a new spec called XDI Connections to the list of the XDI 1.0 specs on the wiki.

In doing so I noticed that the Bindings spec is currently called XDI HTTP(S) Binding V1.0.

I recall some discussion that the Bindings spec would actually cover all the bindings we publish. Is that the case—in which case we should change the name to XDI Bindings V1.0—or are we going to do modular specs for each binding?


---------- Forwarded message ----------
From: Markus Sabadello <markus.sabadello@xdi.org>
Date: Fri, Sep 12, 2014 at 12:23 PM
Subject: [xdi] Minutes: XDI TC Telecon Friday 2014-09-12
To: OASIS - XDI TC <xdi@lists.oasis-open.org>

Note: These minutes contain text from both Dan and myself. So there may be some redundancy. It probably can't hurt to have two different perspectives on this.

XDI TC Minutes

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

Date:  Friday, 12 September 2014 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


Peter Davis

Drummond Reed
Dan Blum
Markus Sabadello
Hubert Le Van Gong
Ning Zhang
Phil Windley
Joseph Boyle


André Martins



XDI IRC channel


Markus will add a note to the OASIS XDI TC homepage.


Report from XDI editors subcommittee



Link contract instantiation

Let’s continue to discuss link contracts, templates, instantiation, community contracts, requester contracts, etc.

Dan’s latest version of the XDI Policy draft spec:


Notes from a call about link contract instantiation on Aug 19 2014 can be found here:


Notes from a 3 day face-to-face “deep dive” on Aug 27 2014 can be found here:



We discussed the following topics:

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?

[Notes by Markus]

Drummond argued that a user makes an authorization decision based on what they see in their authorization manager,  which displays the link contract template at that specific point in time. Therefore, a copy of a link contract template, rather than just a reference to it, should be stored. This can be important e.g. for audit purposes that a future point in time may have to reconstruct what a user agreed to when establishing the connection.

The link contract template in TA’s graph would optionally be signed by the TA. The link contract instance plus the link contract template in RA’s graph would optionally be signed by the RA.

We discussed the case where a copy of a new link contract instance is stored in the graphs of both the RA and AA. In those cases, would the RA also store a copy of the link contract template like the AA does? We concluded that the RA has three options: 1. Store a copy of the link contract template, 2. Store a reference to the link contract template, 3. Not store the link contract template.

[Notes by Dan]

XDI should support many use cases, from light weight bare-bones functionality to heavyweight audit and compliance-proof functionality. At this point in the spec we should define the policy and link contract patterns with a lot of flexibility. We may want to develop conformance profiles later to streamline common characteristics of typical solution requirements.

The only thing that’s always required to be stored, for portability, is the AA’s link contract link instance with the address of the instantiating template.

For audit purposes, the following features should be optionally available:

  • TA signs template instance

  • AA includes signed template instance in the LC instances

  • AA signs LC instance

  • RA stores a copy of the LC instance

In a compliance-heavy profile, all those things might on the other hand be mandatory. Also, AAs and RAs could enforce policies requiring that what they receive from the other party contain any and all optional information, and valid signatures.

Template versioning - what if the Template Authority changes a template? How does this affect existing link contract instances?

We did not discuss this question.

Are community and requester link contracts required for link contract instantiation to work, or are they “good to have” extras?

[Notes by Dan]

All filtering of incoming LC requests can be done via the community LC.

AA’s can request Community LC instances from Community Authorities using Community LC template. AA’s can use the community LC instances to filter incoming LC requests from RAs.

A community template can specify that the community LC instance created contain mandatory and optional policies. The mandatory policies ($required) must be accepted by the AA, cannot be changed, and should be signed. Any other policies are “suggestions” or “recommendations” and they can be changed by the AA. The AA could also use authorization manager software to add additional policy expressions to any community LC.

Policies in community LCs are used to filter LC requests. The community LC could, for example, express a policy such as “approve all requests from certified Kaiser providers immediately” or “reject all requests with member aggregate reputation store < 100” or “defer all requests from authenticated community members for interactive user approval.”

Peer nodes can optionally publish which communities they belong to in the public part of their graph. They may to belong to “unlisted communities” as well.

Requestors can refer to the community LC instance for any peer node by generating the instance’s address algorithmically under the inner root: (=AA/=CA)=CA#template-id

If an AA doesn’t belong to any communities, it can still define LC request filtering policies against a “public community LC.” This $public LC would probably contain no required policies and should be published in the XDI specs once we decide exactly what it looks like.

General consensus on this approach was given on the call and the next step is to write up some patterns and examples of community link contracts.

[Notes by Markus]

Dan initially explained his understanding of the community link contract. It contains rules for membership in a community and for processing incoming connect requests. These rules can control filtering and automatic acceptance of the connect request. Dan’s original understanding was that users can choose a community, which would add the community contract to their graph. The user can not change the community contract, but may add their own rules “on top of it”, which may create a “chain” of link contracts.

Drummond replied that the community contract is just a suggestion that everyone can arbitrarily modify. If you join a community, you voluntarily use its community link contract. We then entered into a discussion about use cases where this may or may not be appropriate. Drummond emphasized that a fundamental design goal of XDI is that every authority in a network has full control over the link contracts it enters into, i.e. can always edit them. Every node in the network enforces its own (and only its own) link contracts.

We then had the idea that even though every node enforces only its own link contracts, a community may require that a node’s community link contract must enforce certain rules. We noticed that for what we had been calling the “community link contract”, there would really be a “community link contract template” in the CA’s graph, which gets instantiated in the graph of all community members. Drummond added that usually a “community link contract template” would be designed with customization in mind to give community members some guidance and options when setting their rules for incoming connect requests.

The instantiated community link contracts may have to be signed (approved) by the CA to ensure it meets the community’s requirements. Dan added that some of these community requirements may be required, and some may be optional.

Dan asked about the use case where a user may not want to be part of a community, but still have a way to filter incoming connect requests. Drummond felt that then the public link contract template would be used.

We also asked how it would be possible for an RA to know which communities an AA is a member of? We agreed this information could be publicly available using the XDI discovery process.

Finally, we liked the idea of using the term “connect” instead of “link contract instantiation”, including for the name of the spec that covers this part of XDI.

How do “deferred” link contract instantiation requests look like?

[Notes by Markus]

We did not discuss this question during the call. Dan however reported that he and Markus have recently spent a lot of time discussing link contract instantiation requests, including “deferred” ones. Drummond requested that a summary of these discussions be sent to the TC.

Variables and variable collections

We have been using variables such as {$from} or {$msg} or {$do}.

It seems we have consensus on variable syntax, but we may need to discuss in more detail how variables are processed.

Transactional integrity

We have discussed the topic of transaction 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:



The next call is next week at the regular time.

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