XDI TC Notes

Following are the notes of the unofficial telecon of the XDI TC held on:

Date: Tuesday, 11 October 2016 USA
Time: 9:00AM - 10:00AM Pacific Time (17:00-18:30 UTC)

The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.

ATTENDING

Markus Sabadello
Les Chasen
Drummond Reed

REGRETS

Phil Windley

NOTES

The XDI TC congratulates Phil on a joyful family event!

DID Spec Working Draft 03

Markus asked about the current state of work on Decentralized IDentifiers (DIDs), which are not (yet) at OASIS but being developed under of a grant from the U.S. Department of Homeland Security. Les reported that work was just started on Working Draft D03. This working draft introduces a suggestion from Christopher Allen to add a “method” field to the identifier format.

did:method:identifier-part-1[:additional-identifier-parts]

The method would be defined by a separate specification and cover where and how to access an identifier (e.g. via Bitcoin, Ethereum, Sovrin, etc.) as well as how to cryptographically interact with a DID record (write it, update it, revoke it). As a consequence, however, the method component makes DIDs ledger-specific.

Drummond drew a comparison to URIs. All URIs follow the same format, but URI schemes can be defined and registered to “bind” classes of URIs to specific protocols.

We had a long discussion about whether or not this is a good thing, and if principles such as decentralization and data portability can still be maintained with such identifiers.

Markus was worried that ledger-specific identifiers would be “less” decentralized and portable than fully abstract identifiers. Markus also recalled that a key promise of XDI discovery is “peer discovery”, i.e. the ability to create a fully abstract identifier (i-number) that could be registered with any arbitrary other XDI peer(s).

Drummond said the advantage of including the “method” was that it solved the problem of interoperability between multiple ledgers because the “start of authority” would be clear whenever you are resolving/using DID identifiers. Equivalence and portability could still be established via appropriate elements of the DID records on each ledger.

We realized that a combination of both fully abstract identifiers and ledger-specific identifiers can make sense, i.e. 100% abstract identifiers like XDI i-numbers could be “bound” to ledger-specific identifiers using XDI equivalence statements.

Markus wondered if this approach could enable “linked local numbers”, a variant on Christopher Allen’s proposal for linked local names, where DIDs are just registered in one’s own “address book”, i.e. in a completely decentralized way without any single “start of authority”. Drummond loved this idea because it was a completely new way of thinking about a DID identifier method. Rather than methods being defined only for binding to distributed ledgers, this method could define a binding to a discovery protocol such as the XDI discovery protocol that did not require a ledger (or essentially treats any XDI endpoints as a ledger). Drummond felt this use case was another argument in favor of the “method” approach.

JXD

Markus presented new examples of JXD documents, including DID (Decentralized IDentifiers) records and Sovrin claims, invitations, etc. He first showed an example DID record in JXD format:

[
{
   "@xdi": {
     "is": {
       "@id": "$is",
       "@type": "@id"
     },
     "cid": {
       "@id": "#cid",
       "@type": "@id"
     },
     "control": {
       "@id": "#control",
       "@type": "@id"
     },
     "service": {
       "@id": "#service",
       "@type": "@id"
     },
     "xdi": {
       "@id": "<#(https://oasis-open.org/xdi/)><$uri>"
     },
     "openid": {
       "@id": "<#(https://openid.org/openid/)><$uri>"
     }
   },
   "@id": "=!:did:76d0cdb7-9c75-4be5-8e5a-e2d7a35ce907",
   "is": [
     "=!:did:33ad7beb-1abc-4a26-b892-466df4379a51",
     "=!:sha-256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
     "=!:sha-256:207952f2a7737fdd7b13f02141bc0d59f8c5c83d4e997ebc70d48e21bf605362"
   ],
   "cid": [
     "=!:cid-1:MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCABMC"
   ],
   "control": [
     "{$self}",
     "=!:cid-1:807542FB6685F9FD8F37D56FAF62F0BB4563684A5153",
     "=!:cid-1:D8F37D56FAF62F0BB4563684A51539E4B26F0840DB36"
   ],
   "service": {
     "xdi": "https://xdi.example.com/123",
     "openid": "https://openid.example.com/456"
   }
}
]

While the DID Spec Working Draft 02 defines a single specific JSON-based format, Markus recommended that it describe DID records in an abstract way, with several concrete supported formats (e.g. plain JSON, JSON-LD, JXD). Drummond agreed, explaining that separating the abstract definition from concrete formats is on the roadmap for one of the next drafts.

We discussed how applications of JSON-LD and JXD should handle the fact that both formats support many variations that represent the same underlying semantic graph (RDF or XDI, respectively). Is there a risk in building applications on top of these formats that may only support certain constrained variations and may therefore create interoperability problems? For example, Markus had at some point noticed constraints that existed in Blockstack (which uses JSON-LD in a certain variation for storing user profile data).

Markus also suggested that perhaps previous work such as JRD, Webfinger, OAuth/OIDC discovery could be at least partially re-used for DID records.

Markus also shared a few examples of using JXD in the Sovrin self-sovereign identity network. This is work-in-progress. Markus is working on mapping Sovrin concepts such as “issuer”, “relying party” and “link” to XDI concepts such as “peer roots”, “inner roots” and “link contracts”. Some concepts seem very relevant, such as connection requests, invitations, attributes, etc.

Lastly, on the topic of whether on whether JXD should be incorporated into XDI Core or a separate spec, we discussed which earlier serialization formats of XDI (before JXD) should be maintained going forward. Markus thought only JXD and the XDI Statement format (sometimes called the Display format) should be supported, and both should be included in the XDI Core spec. Drummond, who missed the previous call, was surprised that the current serialization format specified in XDI Core 1.0 Working Draft 01 (also called the quad format) would not be continued. However given the simplicity and developer friendliness of JXD, he was very open to making it the standard format for serialization of XDI just as JSON-LD has become (for some developers) the standard format for serialization of RDF.

NEXT REGULAR CALL

The next call will be the following week at the usual time (Tuesday 9AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing