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: Minutes: XDI TC Telecon Friday 2013-06-21

XDI TC Minutes

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

Date:  Friday, 21 June 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


Markus Sabadello
Dan Blum
Peter Davis
Joseph Boyle
Animesh Chowdhury
Phil Windley
Les Chasen



Based on the input from Chet Ensign and Paul Knight last week, we now need to decide the names and contents of the specifications for which we want to request templates. See:


Drummond began by posting several example questions for this discussion:

  1. Should XDI Graph Model and XDI Serialization be combined since they are so hard to separate?

  2. Should XDI API be called XDI Messaging?

  3. What should be the scope of XDI DIscovery?

  4. Should XDI Link Contracts also include XDI Policy _expression_?

On the first question, we first discussed if serialization should be part of the graph model. There was consensus that since the two are so closely tied, especially in Joseph’s ABNF, that we should cover both in the same spec.

We then discussed three options for the name of the spec:

The consensus was to use XDI Core both because it covers all the topics that need to be in the spec (graph model, addressing, serialization), but because it also communicates that it is the core spec.

# DECISION: Our core spec will be called XDI Core V1.0.

Joseph explained that the template request form also requires that we specify the editor’s names. The following volunteered to be editors of XDI Core:

Drummond suggested and it was agreed we also should request the template for XDI Discovery. The volunteers for editor for XDI Discovery:

Since XDI Discovery has a dependency on messaging, we need to request that spec template as well. We had a short discussion about whether it should be called XDI API or XDI Messaging. The consensus was the latter. Volunteers for editor for XDI Messaging:

Peter suggested that we also needed to start a Security Mechanisms spec much like was done for SAML. He explained the different topics that he would propose to cover in a XDI Security Mechanisms spec.

There was a consensus that we would need this initially, plus an XDI Security Conformance Profile spec at a later date.

Volunteers for editor for XDI Security Mechanisms:

Finally, since Security Mechanisms will have a dependency on link contracts, we agreed that we need to request a template for XDI Link Contracts. Volunteers for editor for XDI Link Contracts:

Peter said he would also help with security-related aspects.

We discussed that conformance clauses would either need to be added to each spec, or included in a separate conformance spec. If the latter case, we could call it XDI Conformance Profiles. The TC members are leaning towards the latter, but we will revisit as we make progress on the Working Drafts.

# DRUMMOND to update https://wiki.oasis-open.org/xdi/XdiOneSpecs with these decisions. (DONE)

# JOSEPH request the Docbook template for XDI Core, XDI Messaging, XDI Discovery, XDI Link Contracts, and XDI Security Mechanisms.

Joseph also asked about the Github account that Bill Barnhill created.

# JOSEPH to check with Bill about this account.

RE XML editors, Peter said that Oxygen can convert from Docbook to some presentation formats, and it works well on the Mac platform.


This week's decision queue is the following set of proposals:


Based on our revised syntax, Drummond has been working out some common usage patterns illustrated here:


Drummond explained what these examples meant for usage of the =, @, and * context symbols.

  1. = as an entity singleton identifier is reserved for personal names. [=] is the class of all natural persons.

  2. @ as an entity singleton identifier is reserved for trademarks and tradenames: strings in which the registering authority claims legal rights. [@] is the class of all legal authorities and legally registered identities (including trademarked product and services).

  3. * as an entity singleton identifier is for strings in which legal rights are not claimed. [*] is the class of all “things” -- inanimate objects or any actor that cannot serve as an authority.


We briefly discussed the different contexts in which XDI security operates. Peter made the point that there are at least four contexts affecting XDI security considerations:

  1. Interacting with another XDI graph within a trust framework

  2. Interacting with another XDI graph outside a trust framework

  3. Interacting with a non-XDI resource in a trust framework

  4. Interacting with a non-XDI resource outside a trust framework

These contexts will all need to be taken into account in the XDI Security Mechanisms spec.


The decision queue stack is shown on the following three auto-generated Category pages:




See also this list of proposals that need to be developed:



The next call is next week at the regular time..

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