($and/ <== DO NOT REMOVE - switch for preventing MathML interpretation of dollar signs on this page)


This is the text of the Design Goals section of the XDI Core 1.0 spec.


When describing XDI at a very high level, members of the XDI TC have used the analogy that “XDI is to RDF what JSON is to XML”. The essence of this analogy is that JSON as a data interchange format does not have all the power of XML, but because it is so simple, lightweight, and versatile, it has been widely adopted for many problem domains. XDI seeks to provide the same type of solution for semantic data interchange. XDI does not have all the power of RDF or other semantic description logics, but by being comparatively simple, lightweight, and versatile, its goal is to provide maximum utility in a wide variety of semantic problem domains.

In this section we summarize the ten design goals of the XDI Technical Committee in developing the XDI graph model and semantic data interchange protocol.

Design Goals

100% Addressability of All Graph Nodes

To perform semantic data interchange with precise control over every data element, the first requirement of the XDI TC was that every node of every XDI graph be uniquely addressable. This architecture essentially mirrors that of the W3C in the Architecture of the World Wide Web, where it states:

Ehis requirement is one reason that the XDI TC does not use the term “XDI document” or compare XDI graphs to documents. A document metaphor suggests a natural division between addressing of the document and addressing of nodes inside the document. In Web URI architecture, this is reflected by the # fragment, which represents an address local to the current resource, vs. an address outside this resource.

The XDI graph model does not have this distinction because every node of every XDI graph is equally addressable. Or, as members of the XDI TC have put it, “It’s turtles all the way down.”

Note that XDI addressing stops once you reach an XDI literal node—the ultimate leaf nodes of an XDI graph which contain the literal data values. If a client needs to address within a literal data value, it must switch from an XDI address to an address in the native addressing syntax of the literal data (e.g., a JSON path for a JSON document, an XML path for an XML document, a fragment for an HTML document, etc.) Such addresses are out of scope for XDI.

This requirement is perhaps the most significant difference between XDI and RDF, because unique addressability of RDF graph nodes was not part of the RDF problem domain. Appendix A contains a short analysis of how the RDF and XDI graph models treat addressability differently.

Heterarchical — No Central Authority

A second major design goal of XDI architecture is to support heterarchy, i.e., to not assume or rely on a central authority. This meant designing a fundamentally peer-to-peer model in which any group of peers may cooperate to create an addressing and interchange space for its community. This addressing space may make use of existing resolvable identifiers for those peers, or it may extend those existing addresses, or it may be an entirely new addressing space. In all cases XDI can standardize discovery of peers and peer addresses, including both public and private discovery. This “radically P2P” architecture supports any deployment topology, from highly centralized to highly decentralized, and imposes the fewest pre-existing policy assumptions or restrictions on communities of XDI users.

Note: for more about this aspect of XDI, see the XDI Discovery specification.

Contextual Identification

It is a mantra in digital identity that “identity is contextual”, i.e., that both the requirements for identification and the uniqueness of identifiers is relative to the context in which identification is required. Even “global” or “absolute” identifiers like telephone numbers, email addresses, or URIs are still relative to a particular addressing context.

It is also a maxim in the privacy community that “privacy is contextual”, and thus a data authority must be able to control the data being shared and permissions being granted in any identification context.

This primacy of context means that a third core XDI design goal is that it support the ability to model context at any degree of granularity and enable XDI authorities to control the sharing of identity and data by context.

Again, we note that modeling of context was not a requirement of the RDF problem domain, so this is not an aspect of digital identity or data sharing addressed by the RDF graph model.

Persistent Identification

A second core quality of identification is whether it is persistent (immutable) or reassignable (mutable). In the former case, an identifier (or other means of identification) is bound to the resource being identified in such a way that this association will not change over time—ideally forever. In the latter case, an identifier bound to one resource at one point in time (such as an IP address assigned to one computer, or a domain name registered to one owner) may subsequently be bound to a different resource at another point in time (such as when an IP address is reassigned to a new computer, or when the domain name is transferred to a new owner).

In the context of digital identity and secure data sharing, persistent identification is a requirement for one core reason: if an XDI authority with a particular identifier has been granted a particular set of permissions, and the XDI authority identified by that identifier changes, then the permissions now belong to (and can be exercised by) a different authority.

Persistent identification is also important for portability (see below), because if an identifier (or other means of identification) needs to change when the location of an XDI graph changes, the XDI relations described in that XDI graph will break. For these reasons, it is critical that XDI support a class of identifiers that are assigned once to a resource and never be reassigned to another resource.

At the same time, it is widely acknowledged that persistent identification is a nightmare from a usability standpoint. The human brain is wired to use simple, memorable natural language identifiers for our cognition and communication, and to subconsciously adjust the mappings of those identifiers over time as we learn, grow, and evolve. For example, the person you first think of by the name “Tom” today may be different from the person you first thought of by that name when you were a child.

So a key design goal of XDI is to support the requirements of both persistent and reassignable forms of identification; to provide precise means to map between them; and to make it syntactically unambiguous which form is being used in which context.

Serialization Independence

Another goal is for the XDI graph model to be a precise logical abstract model that is independent of any specified serialization format. For example, in the XDI 1.0 specifications, several JSON serialization forms are specified. In addition the XDI TC plans to specify at least one XML serialization format. All these formats transmit 100% of the information in an XDI graph, and all are losslessly convertible into the others.

Portability and Location Independence

Since XDI graphs may be used to describe the data associated with any entity, including people and businesses that are constantly changing contexts, attributes, service providers, and endpoints on the network, another design goal is for the semantics expressed in an XDI graph to be portable, i.e., location-independent. This means an XDI graph can be moved to any location (endpoint) on a network without breaking any of the descriptions or relations described in the graph.

This design goal is particularly important for XDI graphs representing individuals, as it supports the ability for an individual to maintain ongoing, sustainable control of his/her personal data and relationships independent of any particular service provider or network location.

Note: the specialized use of the XDI protocol provide wide-area location independence is defined in the XDI Discovery specification.

Protocol Expression and Transport Independence

To make semantic data interchange as simple and extensible as possible, another XDI design goal is to define the XDI semantic data interchange protocol in XDI itself. This means all XDI messages must be valid XDI graphs, and all XDI data sharing operations are XDI graph merge operations.

This design goal also achieves transport independence, i.e., as a logical protocol for the exchange of data between any two systems, the XDI protocol can be independent of any specific transport protocol (e.g., TCP/IP, HTTP(S), XMPP, SMTP, etc.), with bindings defined to such transport protocols as needed.

Note: The logical XDI protocol and its binding to HTTP(S) is defined in the XDI Messaging specification.

Authorization and Policy Expression

To meet the security and privacy requirements of XDI authorities, the XDI protocol must enable them to precisely describe the rights pertaining to any shared data. And in order for these rights to be enforced uniformly by the all XDI authorities to which they are granted, XDI authorization must be able to be fully described in XDI itself. This includes the ability to express any policy governing authorization and the ability for such policies to reference data, variables, relations, and other statements in the relevant XDI graphs.

Note: the primary XDI data structure that fulfills this design goal is called a link contract and is defined in the XDI Policy specification.

Schema and Ontology Expression

The core difference between markup languages and semantic data interchange is that an express goal of the latter is to solve the problem of interoperable data semantics, i.e., to provide the infrastructure necessary to map semantics between widely disparate systems with the precision necessary for digital data to automatically flow between them. To do that, it is a design goal of XDI to enable definition of schemas and ontologies for XDI data in XDI.

Note: XDI schema and ontology definition is defined in the XDI Dictionary specification.


A final design goal (and the reason for the “X” in “XDI”) is for any XDI authority to be able to extend XDI semantics without permission from any other XDI authority. This includes the ability to establish new XDI addressing spaces, to define new XDI dictionary vocabulary, and to create specializations of the XDI protocol for specific types of semantic data interchange.


XdiDesignGoals (last edited 2013-11-27 02:49:07 by drummond-xns)