Worldwide Web Consortium’s (W3C) DID Working Group meeting
The firsthand account a first-time observer
Last week, Carsten Stöcker, CEO of Spherity (pictured below) and I were in Amsterdam as observers at the specification-planning face-to-face meeting of the Worldwide Web Consortium’s Decentralized Identifier Working Group (W3C DID-WG). Microsoft generously hosted the meeting in the Spaces coworking facility adjoined to their Amsterdam offices. There, core stakeholders and designers from the W3C community hammered out a re-scoping and process change for the editorship of the specifications underlying interoperable “DIDs”. We were among a handful of invited experts and non-editing observers contributing to the supplemental materials, such as the use-cases document. What follows is an overview of our observations and notes, with links to the relevant sections of the public slides documentation.
DID Documents: What exactly are they, really?
The main event at this meeting was the renegotiation of the specified limits and interoperability assumptions of DID Documents, the sometimes stable and sometimes ephemeral sets of data and/or metadata that DID methods return when given a DID in their purview. To translate this admittedly very abstract and conceptual issue into interpersonal or political terms, one founding member of the working group reminded the group that they have been conceiving of this issue as the fundamental “contract” implicit in interoperability. Namely, if one software agent presents a DID, what exactly do they have to include in the request, and what exactly are the set of responses which they can be expected to be able to process in good faith, as the lawyers say? In various open-discussion sessions throughout the conference, it became clear that there are a wide range of interpretations about what exactly a DID Document should contain or how it can be interpreted to represent/reflect on the subject and/or controller of that DID.
The set of cross-platform assumptions that can safely be made when resolving a DID from another has become a sticking point in recent months due to the complexity of ongoing development based on how this resolution process is affected by different encodings (traditional JSON, JSON-LinkedData, CBOR, and even ASN.1 and PDF). Some of this work had previously been “outsourced” to a parallel working group defining and specifying the resolution process in the abstract, but there too incompatible assumptions and interpretations have been undermining the necessary clarity to make progress. One procedural side-discussion revolved around how the resolution group and the core specification group could be in closer dialogue on these mutual stumbling blocks.
To make the security and the translation of DID-Documents more manageable across these divergent encodings, the working group decided to define a finite list of valid DID Document properties and contents, establishing a threshold for method interoperability and a standard registry for maintenance of the standard. (Here are a graphical and a textual representation of that momentous agreement). While this might strike some open-web hardliners as a centralization of the specification process itself, it was coupled with a corollary process change: the contents of this core properties list would be defined according to an encoding-agnostic abstract data model (except choice TBD), with all code samples to be written for the specification document provided in at least 3 encodings throughout (traditional JSON, linked-data JSON, and CBOR). Implicit in this agreement is the potentially substantial and laborious commitment (the extent of which was made clear by Manu Sporny’s presentation) to design and type these properties in a maximally encoding-agnostic way.
Non-registry extension points
An interesting aspect of this agreement to specify via an abstract data model and update via registry was that open-web and greater-extensibility proponents still got to eat their cake and have it too — as long as those DID Document contents could be clearly and securely marked as safe to ignore by the leaner, core-only DID:Methods. More complex extensibility mechanisms, which might be difficult or less necessary for all other standards-compliant methods to support fully, were essentially relegated to a separate layer linked via the @Context field (native to JSON-LD but still parseable in other encodings) to allow simpler systems to remain fully-compliant while ignoring additional contexts, and thus, the extensions arrived at by them.
The group also received an update on another open design discussion, which has iterated over the last year and is now referred to by the technical name “matrix parameters” (which work like the query strings or URIs after the “?” in a web URL). These were discussed by Markus Sabadello of DanubeTech (Austria), who has been central to both this discussion and the related resolution topic. These could be seen as a way to specify or bring additional information to an interoperable resolution process, but they could also be seen as a form of extensibility of the core DID/DID-Document data model.
Use Cases & Rubrics
Two important supplemental documents, that will be included along with the specification although far less normative or technical in nature, were also discussed at length. Joe Andreiu brought his requirements-gathering experience to bear on both of these important informational contexts for designing systems around the specifications.
The use-cases document (which have not historically received as much thought or effort as the specifications themselves) describe in minimal detail the user stories or real-world uses DID systems could enable. Each of these can be seen as crystalizing the real-world utility and requirements for any given set of properties or features of a given DID design. Conversely, any proposed feature, no matter how useful or convenient to a specific industry, architecture, or system, could be dismissed as inessential if it does not answer to a need documented in the use cases.
For this reason, Andreiu lobbied for more active and thoughtful contributions to the use-cases document, particularly as relates to the more contentious debate around inclusion or exclusion of properties from the finite list of core properties might be diffused and made easier to referee if properties were grounded in use cases. Spherity is committed to contributing further to these use-cases, particularly as pertains to the IoT-specific networking requirements and standards overviewed earlier in the meeting by Sam Smith. It remains to be seen if these use-cases might also be useful to think through decentralised extensibility as well.
The rubrics document, which grew out of an interoperability meeting last year lead largely by DACH-based SSI thinkers, fulfills a similar role at the other end of the design process. It provides conceptual guidance for assessing how decentralized (according to different subrubrics and focused heuristics) a given DID method or SSI platform can be judged to be. This might sound esoteric, but as the number of DID methods grows, subsets of the interoperable space might be useful to define according to a set of criteria and methods, which might also be useful to certification or self-assessment processes for a kind of “Third Party Risk Management” when federating decentralized identity platforms. As not all SSI systems are created equal, the rubrics serve to help “matchmake” between interoperable systems and a multi-system or open use case. A substantial discussion ensued about how long it takes to fill out such an assessment or self-assessment, and one helpful suggestion from the crowd was to offer a “lightweight” or reduced version that overviewed the core considerations to allow for faster assessments.
Looking forward
In summary, one recurring theme came up in every discussion: people are picking up this technology, forking everything open source and experimenting right now, all around the world. For the safety of the ecosystem, they need to be as concrete, finite, and very clearly documented as possible, particularly so that developers and designers with less relevant technical and standards experience than the ideal implementer or familiar interlocutor can interpret them safely. As one standards veteran said in a side-conversation (on background, of course): “most developers don’t read the security considerations appendix or the design guidance — they just cut and paste the examples and start adding and subtracting. For that reason, we need to pick and edit our examples very carefully and be 100% certain that the examples given in all three encodings are perfect translations of one another, fully compliant, and maximally safe.”
As the W3C-imposed “feature freeze” approaches in May, the next few months will see substantial dialogue within and between the various SSI developer communities working on extending and evolving the DID systems already in production. The IIW conference in April will be a major one for the insiders and meta-architects, as the final details get hammered out — the decentralized identity foundation, the W3C community, and the Aries/Sovrin communities will no doubt have consequential face-to-face meetings in the few days before and after IIW.
Stay sphered by joining Spherity’s Newsletter list and following us on Linkedin and Twitter.
