XDI TC Minutes

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

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

ATTENDING

Drummond Reed

Joseph Boyle

Animesh Chowdhury

Dan Blum

Markus Sabadello

Phil Windley

GUESTS

Andy Dale

NEWS & UPDATES

TC Membership

Phil is joining Planetwork so he will begin participating as a representation of Planetwork.

PRESENTATIONS/DISCUSSIONS

Progress on Working Drafts

Drummond and Joseph reported that they had prepared an early outline of the XDI Core 1.0 spec:

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

This coming week, Joseph is will begin work on the first Working Draft, concentrating on the ABNF section. The following week Drummond will add preliminary text for the other sections, so that Working Draft 01 is ready by our target of the end of the month.

Markus aims to do the same thing for the XDI Messaging spec.

Proposal for XDI Privacy Mechanisms 1.0

After more work on the privacy-related aspects of XDI, and greater interest in how Privacy by Design can be implemented with XDI, Drummond proposes that we add another spec to our 1.0 suite: XDI Privacy Mechanisms 1.0 (short name xdi-privmech). Although it could be combined with the XDI Security Mechanisms spec, he explained that it would provide greater emphasis to keep it as a separate spec.

This would be consistent with the newly release RFC 6973, Privacy Considerations for Internet Protocols. It would also be consistent with the power of the privacy mechanisms we have designed in XDI. An example that Dan raised was the ways in which the XDI protocol and XDI link contracts can be used for authentication without tracking by an IdP (identity provider).

#DECISION: There was a unanimous consensus that we should add this specification to our 1.0 suite.

#DRUMMOND will update the XDI One Specs page. (DONE)

Link Contract Initiation Patterns

On last week’s call we had an excellent discussion of the sequence diagrams for initiating XDI link contracts. Subsequent discussion has simplified the flows and helped us focus in on the specific security requirements.

Drummond sent updated Alice->Acme and Alice->Bob flows (attached). We reviewed these simplified flows and their implications for the XDI Security Mechanisms spec. The main takeaways were:

By having XDI servers at XDI endpoints respond directly to the messages (and produce the corresponding authorization dialogs to the users) simplifies the flows and the attack surface.
Having Alice only authenticate to her own XDI service makes it easier for strong authentication to be used.
The XDI messaging between Alice’s and Acme’s or Bob’s XDI services can be secured at the transport or message levels using existing server-to-server authentication protocols and patterns.

Our next step is to move down to the XDI message level to illustrate these messages and security patterns.

DECISION POINTS FOR THIS CALL

Proposal for Attributes to Always Use Chevrons

After discussion on last week’s call, Drummond sent a poll to the list about the proposal to improve understandability of XDI syntax by having attributes always use chevrons (as classes, instances, or singletons).

https://lists.oasis-open.org/archives/xdi/201308/msg00014.html

The results of the poll were 4 in favor, 1 against, and 2 no preference. Drummond proposed that we move forward with this change, and there was unanimous consensus to do so.

# DECISION: We will make this change.

# DRUMMOND ET AL: Make the update across all wiki pages.

Unassigned Values vs. Null Values

After the discussion on last week’s call, Joseph proposed that we formally distinguished between an unassigned value and a null value, as he believes these are treated as programmatically distinct in some languages, and thus we need both semantics. Joseph’s proposal is:

To indicate an unassigned value, an attribute MUST NOT have a value context node.
To indicate a null value, an attribute MUST have a value context node whose value is the JSON null value.

This led to a long discussion. Markus feels that because XDI is not a programming model, but a data model, our data model does not need to have this distinction.

Joseph looks at it a different way: XDI gives a data item an address, and it should be clear what is at that address, if anything.

Andy shared this view: if the address exists, it can have a value, which may be empty. The only other option is that it has no value.

Drummond agreed with Andy, but voiced his concern that it seems strange that we support all JSON data types but null.

Animesh asked if there is a direct XDI query to confirm that an attribute node exists but does not have a value. Drummond believed it was not currently possible with a single call, but would require multiple calls.

Animesh asked Joseph if he had a particular use case that required this distinction. Joseph explained that it was not a particular use case, but more the motivation that developers should be able to store and retrieve all the JSON value types and be able to “roundtrip” them, i.e., get back the same datatype that was stored.

Andy asked if the XDI model of not having a value node could correspond to storing a JSON null. Drummond felt this is the key question the TC has been debating.

Joseph spoke about the value of being able to round-trip all the different JSON data types, including null. He noted Java’s null is not equivalent to JSON null but to JSON undefined: http://json-lib.sourceforge.net/apidocs/jdk15/net/sf/json/JSONNull.html

We then discussed whether the JSON serialization of an attribute with no value should be a JSON null, and the result in the XDI graph model result is to for the attribute’s value context node to have no literal node. This would allow a valid roundtrip of a JSON null value.

Joseph listed 3 possible alternatives, with behavior of each for null and undefined:

Case 1: JSON null is storable as a distinct value similar to JSON true and false.

Set null - get back null.
Do not set anything at address - on attempting to get that address, receive empty result, not to be confused with “” which would represent empty JSON string. (Alternatively, receive some other specified non-value error code.)

Case 2: JSON null is storable and interpreted to mean unassigned address in XDI.

Set null - stored as no assignment at address - on get on that address, the lack of assignment is interpreted as and serialized back as null.
Do not set anything at address - stored as no assignment - get back null: round trip failure. (In other words we are creating a 2:1 mapping sending null and undefined to the same thing, which is not reversible, breaking round tripping.)

Case 3: JSON null not storable. Attempting to set an address to null gives error. This would be an exception to the policy of JSON value semantics, i.e. providing unambiguous storage and retrieval of JSON values.

We ran out of time to come to a conclusion.

Clarified Proposal: Support All Native JSON Value Types

For the ABNF, Joseph wants to clarify that our serialization formats support all native JSON value types. In addition to strings, numbers, true, false, and null, this includes JSON objects and JSON arrays. The specific clarified proposal is:

A JSON object value MUST be serialized as specified by section 2.2 of RFC 4627. This means it is a valid JSON text beginning with { and ending with }.
A JSON array value MUST be serialized as specified by section 2.3 of RFC 4627. This means it is a valid JSON text beginning with [ and ending with ].

Joseph believes that for our 1.0 spec, these values should be treated as opaque from an XDI standpoint, i.e., we would not specify any rules for parsing or addressing inside these values (even though they are fully structured JSON). However this still gives developers the ability to store and retrieve JSON objects or arrays as XDI values.

#DECISION: Yes, we confirmed that our serialization spec includes both JSON objects and arrays as data types.