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)


ATTENDING

Animesh Chowdhury
Drummond Reed
Joseph Boyle


REGRETS

Phil Windley
Dan Blum
Markus Sabadello


NEWS & UPDATES

DEVELOPER’S GUIDE TO XDI

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


DISCUSSIONS

JSON-LD

Joseph pointed out this article.


  http://blog.ldodds.com/2010/12/02/rdf-and-json-a-clash-of-model-and-syntax/


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


  http://www.w3.org/TR/json-ld/


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.



DECISION POINTS FOR THIS CALL


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


XDI MESSAGE AUTHENTICATION

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


  https://wiki.oasis-open.org/xdi/XdiMessagePatterns

  https://lists.oasis-open.org/archives/xdi/201305/msg00048.html


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.


ABNF


We continued our review of the revised ABNF:


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

 https://lists.oasis-open.org/archives/xdi/201305/msg00055.html


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


  https://wiki.oasis-open.org/xdi/XdiAbnf


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:


=drummond+birth<+date>&/<+us><+formatted><+date>&/"1957-12-25"


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


=drummond+birth<+date>&/&/"1957-12-25"

=drummond+birth<+date>/$is+/+us+formatted+date


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.



DECISION POINT QUEUE REVIEW

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


  https://wiki.oasis-open.org/xdi/CategoryLastCall

  https://wiki.oasis-open.org/xdi/CategoryCurrent

  https://wiki.oasis-open.org/xdi/CategoryHighPriority


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


  https://wiki.oasis-open.org/xdi/XdiPendingIssues


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]