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-05-31

XDI TC Minutes

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

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


Animesh Chowdhury
Drummond Reed
Joseph Boyle


Phil Windley
Dan Blum
Markus Sabadello



Drummond reported that there continued to be interest in this project, and he would report as further progress was made.



Joseph pointed out this article.


We had a short discussion of the JSON-LD spec:


We agreed that it is very well written and includes numerous good examples that help make the spec very clear. We would do well to emulate its approach.


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


We continued our discussion of the relationship of XDI messages and authentication.



Today we began by discussing how XDI could implement a distributed PKI infrastructure. The basic approach, which has been discussed several times by the TC since its inception, can be summarized as:

  1. Each XDI authority could publish its own self-signed certificate. Alternately, an XDI host provider could issue certificates for the XDI endpoints that it hosts, or other XDI peers could sign the certificates of peers that it trusts.

  2. The certificate could be sent with an XDI message, or available via trusted discovery from a known XDI address at the source XDI authority.

  3. The current certificate could be used by the recipient of an XDI message to verify its authenticity and integrity.

Animesh explained the advantages of having XDI host providers provide certs for their customers—this provides a higher level of trust that a particular XDI endpoint at a particular CSP is authentic.

However this approach is still not a silver bullet for the root-of-trust problem. The recipient of an XDI message still has to find a chain of certificates it trusts, i.e., how does it know it can trust the XDI host provider?

Drummond also pointed out the need for strong auth between a user and his/her XDI endpoint. The stronger that authentication is, the more it can be leveraged everywhere it is needed.

We referenced a suggestion from Markus about the three XDI security options he believes will cover the use cases we have been discussing:

  1. Shared secret token authentication in simple cases when you want to talk to your own XDI endpoint.

  2. OAuth when you want to give apps access to your XDI endpoint.

  3. PKI for talking to other authority’s XDI endpoints, i.e., inter-cloud communication.


We continued our review of the revised ABNF:

 https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion (see the 2013-05-05 comment)


Joseph reported that he the discussion ABNF was now mature enough that he moved it to the main ABNF page:


He gave us a high-level walk through of how it is now broken into several abstract grammar modules that then lead to the concrete ABNF needed for each serialization format. Drummond said that it looked very elegant and very easy to parse by module.

The only specific rule we discussed was the literal-statement rule that currently has the option of including a type-singleton:

literal-statement    = literal-context "&" SPSEP *type-singleton "&" POSEP json-value

Drummond explained that the option to include a type-singleton in the XDI predicate was a vestige of when we were proposing to include a datatype identifier for what is now the value node. We subsequently decided that was not necessary since all the serialization formats now include the native JSON data types. So we discussed whether it was helpful to optionally include it in the predicate representing the XDI literal arc. Example:


The other option is NOT to allow it in the XDI predicate and instead make it a separate $is+ statement. Example:



Both Animesh and Joseph preferred the second option. They felt the rules are simpler. Drummond also pointed out that the first option only permits one literal datatype assertion, whereas the second option permits multiple literal datatype assertions when needed.

# DECISION: We will remove the type singleton option for the predicate of XDI literal statements.

# DRUMMOND: Edit ABNF page to conform. (DONE)

We then discussed Joseph’s goals for the ABNF for this coming week:

  1. Finish the Graph Tree grammer.

  2. Create a list of any open issues for discussion with the TC.

  3. Recommends solutions for identifying the serialization type.

# DRUMMOND to put ABNF review first on the agenda for next week’s call.


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]