[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-09-20
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 20 September 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Joseph Boyle
Dan Blum
Drummond Reed
Animesh Chowdhury
Markus Sabadello
Les Chasen
Steve Greenberg
Drummond reported on some key trends and feedback coming out of the conference this week in Seattle.
Joseph has committed content to the Core spec, including the ABNF:
Markus has been busy with XDI2 implementation work but has begun drafting the Messaging spec.
Steve asked where he can upload the XDI Developer’s Guide he is working on. We agreed it should be added as a repository to the XDI TC’s Github account. Markus created this repository for Steve and added appropriate permissions:
https://github.com/OASIS-XDI-Technical-Committee/xdi-developers-guide
Drummond has written a proposal for cryptographically signing XDI graphs.
https://wiki.oasis-open.org/xdi/XdiSignature
Although there are many use cases for signed graphs, the initial use case this is needed for is validation of XDI messages.
Dan asked if there will be a separate XDI Signatures spec, or if this will be part of the XDI Security Mechanisms spec. According to the XdiOneSpecs wiki page, no separate spec for signatures is planned.
Markus gave a demo of a new XDI2 tool that illustrates how signing and validating XDI (sub-)graphs could work:
http://xdi2.projectdanube.org/XDISigner
This tool supports both signatures (using a public/private key pair) and HMACs (using a symmetric key). In order to generate and validate signatures, a “normalized unsigned graph” is created.
Dan suggested that instead of defining our own “pure XDI” way of signing (sub-)graphs, we might also consider using JWS (JSON web signatures) from the JOSE suite of specifications that are used in OpenID Connect. This should be relatively easy given the fact that XDI/JSON is our primary serialization format.
We agreed that the XDI TC should specify the basic signature mechanism, as well as certain other functionality related to signatures and keys, e.g. how a public key can be obtained using XDI Discovery. There are however also topics that are likely out of scope of the XDI TC, such as the question where and how private keys are generated and stored, and how exactly they are retrieved and used for generating signatures.
Dan added that instead of obtaining a public key using XDI Discovery, it could also be sent alongside the signed XDI message itself, as part of a trusted certificate.
Markus also did a quick demo of an XDI server that automatically encrypts literal data. This resulted in an interesting discussion about the possibility of encrypting entire XDI (sub-)graphs.
This topic was raised in last week’s telecon when we discussed nesting of collections. It is critical for defining interoperable, predictable behavior of XDI servers.
We created an example of an XDI message envelope containing two XDI messages, each one of which contained multiple message parts.
=markus[$msg]!5ab4/$is()/([=]!1111)
TRANSACTION BEGIN
=markus[$msg]!5ab4[$msg]#0$do/$set/(=markus<+name>&/&/"Markus Sabadello")
=markus[$msg]!5ab4[$msg]#0$do/$set/(=markus<+email>&/&/"markus.sabadello@gmail.com")
=markus[$msg]!5ab4[$msg]#1$do/$set/(=markus<+age>&/&/34)
=markus[$msg]!5ab4[$msg]#1$do/$set/(=markus<+smoker>&/&/false) <--- ERROR
=markus[$msg]!5ab4[$msg]#1$do/$set/(=markus/+friend/=drummond)
=markus[$msg]!78d1[$msg]#0$do/$set/(=markus<+name>&/&/"Markus Sabadello")
=markus[$msg]!78d1[$msg]#0$do/$set/(=markus<+email>&/&/"markus.sabadello@gmail.com")
=markus[$msg]!78d1[$msg]#1$do/$set/(=markus<+age>&/&/34)
=markus[$msg]!78d1[$msg]#1$do/$set/(=markus<+smoker>&/&/false)
=markus[$msg]!78d1[$msg]#1$do/$set/(=markus/+friend/=drummond)
TRANSACTION COMMIT OR ROLLBACK
The question is, how should an XDI server behave if an error occurs at the indicated operation.
Animesh explained classic transaction support, e.g. in relational database systems. We agreed that concepts such as transactions, commits and rollbacks could be directly applied to XDI messaging. Under this assumption, the individual operations in the above example would either all succeed or all fail.
Markus noted that there is some transactional support today in XDI2, which however depends on whether the underlying storage layer supports transactions.
Animesh brought up the idea that an XDI client could “request” transaction support by using a message parameter.
We did not reach a conclusion on whether support for transactions and support for such a message parameter should be required or optional in the XDI specs. Depending on the use case and desired paradigms such as ACID and BASE, transactions have both advantages and disadvantages.
We also talked about error reporting. Animesh suggested that in case of an error, the response graph should contain not only an error message, but also an indication of where the error occurred (i.e. which message and message part).
We did not have time to further discuss link contract initiation flows.
We however mentioned that there are several open issues about link contract functionality. In various e-mail threads, two of these issues have been called the “unauthorized $ref problem” and the “unbounded $set problem”.
We did not have time to discuss the proposed dictionary syntax.
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
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]