Minutes: XDI TC Telecon Friday 2013-05-24

[Drummond Reed <drummond.reed@xdi.org>]

XDI TC Minutes

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

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

ATTENDING

Les Chasen

Joseph Boyle

Markus Sabadello

Animesh Chowdhury

Dan Blum

Drummond Reed

REGRETS

Phil Windley

NEWS & UPDATES

DEVELOPER’S GUIDE TO XDI

First, Dan explained that he’s working on a Glossary that will help people map terms they already know about related spaces (e.g., directories, LDAP, databases) into XDI. This is particularly important since it XDI is a bridge between the world of the Semantic Web and RDF and the world of databases, data modeling, and data interchange.

Drummond then explained that some of the Respect Network Founding Partner companies are willing to help produce a Developer’s Guide to XDI.

This led to a discussion of the need for higher-level APIs that help reduce the complexity of XDI for developers. PXL (Policy _expression_ Language) was one example shown by Phil Windley at the last Internet Identity Workshop.

Animesh talked about the paradigm shifts in databases and data sharing from relational databases to object-oriented, and from XML to JSON.

Joseph pointed out that XDI is a language for dealing with data akin to SQL and SPARQL. As a protocol, XDI also has analogies to LDAP and DNS (at the discovery level).

RE the analogy to SQL, Dan said that most integration between distributed databases happens at a higher layer above SQL. You can use drivers like ODBC and JDBC, but the semantics of queries are still database and application-specific.

PRESENTATIONS/DISCUSSIONS

NEW XDI2 PARSER FEATURE

Markus demonstrated the new feature he added to the XDI2 Parser utility to decompose an XDI subject into the XDI graph model type each node represents.

 http://xdi2.projectdanube.org/XDIParser

Drummond asked whether the XDI Graph Model spec should include a UML diagram of the XDI graph model. There was a consensus that it could be very useful and could communicate the graph model in a widely understood language.

In this discussion it came up that the term “context” is one of the most overloaded in XDI. It has a very precise meaning as one of the two fundamental node types in the XDI graph model, but there was agreement that we should use the term “context node” for that precise meaning. The broader term “context” maps to the entire subgraph rooted on a particular context node. For this reason:

# JOSEPH to update the ABNF to use the term “context-path” rather than just “context”.

VISUAL GRAPH MODEL

We had a short discussion about whether it was worth trying to come up with different symbols for different node types in the visual graph model. The consensus was that this would hurt more than it would help, i.e., add more complexity to the visual graph model than was justified.

Animesh suggested a digital version of the visual graph model could support mouseovers that could tell you the type of each context node.

Drummond said that root context nodes are still important enough to distinguish from other context nodes to justify using unfilled circles (vs. filled circles) in the visual graph model. However there is one exception: Drummond suggested that because literal nodes currently used unfilled squares, value nodes be represented by filled squares. This is appropriate because value nodes have special rules that apply to them just like root nodes do.

DECISION POINTS FOR THIS CALL

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

XDI MESSAGE AUTHENTICATION

We continued our discussion of best practices and $words for processing secret tokens in link contracts.

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

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

Markus explained the use case again, which is shared secret (e.g., password) storage and comparison. In the demos for Internet Identity Workshop, plain text passwords were used, but this now needs to change for operational XDI endpoints.

We discussed different options for how operational security policies should be handled in link contracts.

One key high level question is the relationship of authentication and authorization in link contracts. Dan said that the two topics are inherently related, as authorization almost always depends on authentication. Certain authorization policies may also be dependent on how the sender was authentication or to what level of assurance (LOA) to which they were authenticated. So authorization policies may need to specify authentication requirements. That’s why SAML, for example, has an authentication context spec that enables a machine-readable description of how the message sender was authenticated.

Dan gave an example of RSA using “adaptive authentication” based on policies expressed by an authentication server.

In terms of LOA, Dan pointed to the U.S. federal NIST standard for LOA. Drummond agreed that this is the kind of LOA standard that XDI could and should leverage.

Dan asked about when an XDI endpoint should be using OAuth. There is consensus that we want to develop a profile of how to use OAuth with an XDI endpoint.

Joseph mentioned his earlier suggestion that the XDI TC define an XDI session protocol, where you can refer to previous session state in subsequent interactions. As a concrete example, it would be useful to have an XDI interactive command-line interpreter, or REPL (read-evaluate-print loop)—similar to that in many other languages—to facilitate testing and development. If this exists, it would be easy to put XDI messages over SSH or any session-oriented transport.

Dan suggested two options RE our overall approach to XDI security architecture:

1. We can assume that authentication takes place at another layer of the stack, so it is out of scope.

2. We can define how an XDI endpoint passes on security statements or “claims” to an externalized authentication service.

Drummond observed that the problem with the first option is that it could be a major hindrance to interoperability. The second path can largely solve the interop problem by leveraging external authentication services and protocols but still standardizing the claims that must be sent in XDI.

Dan asked about whether the XDI protocol was bound to HTTP. Drummond explained that it is transport independent, but that the TC agreed to focus the 1.0 specs on a binding to HTTP/S as the transport protocol.

Dan pointed out that authentication protocols are bound to transport protocols. Joseph echoed this by asking, “How much does the XDI graph need to know about authentication tokens?” Drummond agreed and felt this was a another reason why XDI should be used as a logical protocol for the transport of authentication credentials that can use just-in-time bindings to transport protocols.

Animesh said that one way of thinking about it is that XDI graphs are held in a container, and that container is managed by an engine, such as a JBOSS container. The container in turn is running in a host. So communications with an XDI endpoint needs to go through the host, the container, and then the graph.

This means authentication can be applied at the host level, the container level, and the graph level. For example, HTTPS can be used for secure communications at the host-to-host level. But that same type of authentication cannot be achieved using a different host-to-host transport protocol like SMTP.

Drummond suggested that the ability to sign and encrypt XDI messages would provide a message authentication mechanism at the graph level that would be independent of any container, host, or transport protocol.

Drummond suggested that Animesh post a message to the list with his thoughts about how transport-independent authentication could/should work.

ABNF

We did not have time tol continue 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

We agreed that this should be the first topic on our next call, with the authentication topic to follow.

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.