The first such grant was initiated by Microsoft, which has a long history of collaborations in DIF. Of the various modalities described by the grant program, The Claims and Credentials Working Group will be overseeing a new work item open to all DIF members that creates and harden a JWS test suite, with this grant funding a lead editor to drive the work and keep it to a pre-determined timeline, paid upon stable and complete release.

History

Pamela Dingle, co-chair of the Interoperability WG, identified a recurring theme in conversations about interoperability across the great “JSON”/”JSON-LD” divide: while considerable cross-vendor, cross-stack alignment had happened over the last years to address many other aspects of credential exchange and identifier resolution, “translation issues” and varying interpretations of the JSON sections of the VC data model specification lead to divergent ways of structuring, defining, signing, and parsing VCs in JWT form. The kinds of signature suite definitions that define Linked Data Proofs made strange bedfellows with the in-built mechanisms of JWT, which were hardened and commoditized earlier. This results in a slightly “balkanized” landscape of VC-JWTs that make different concessions to the expectations of JSON-LD-native parsers and systems.

Initially, the idea of iterating one or more foundational specifications seemed a natural solution: a few key sections of any specification could be made more explicit, more normative, or less ambiguous. But just as the plural of anecdote is not data, so too is the plural of specifications not disambiguation. Another tack was chosen: implementers of the existing specification would come together and compare their running code to identify every difference and incompatibility, defining a test suite that interpreted the current specification. They might still produce a list of changes they would like to see in a future specification, and that list might contain some contentious items that take a long time to align. But in the meantime, they would have a practical roadmap to alignment and a benchmark for conformance to drive interoperability amongst each other and clarity for external interoperability.

A signature suite that spans two worlds

The specification under test in this new work item is Json Web Signature 2020 (“JWS2020” for short), a CCG signature suite that defines how the signature mechanisms and data structures native to “detached signature” JWS tokens can be parsed as Linked Data Proofs. The signature mechanisms of the JWT world and the LDP world are quite different– bridging them requires a deep understanding of both: differing security models, canonization and serialization complexities, explicit reliance on IANA registries, URDNA dataset normalization, and the like. Advanced topics, even for this blog!

Understanding such a specification on a deep intellectual level and understanding its design decisions requires a firm grasp on all these complexities spanning two very different engineering traditions. Implementing the specification, however, should not; to be blunt, our community cannot afford such understanding gating off successful implementation, particularly if industrial adoption of decentralized identity is a shared goal. Before the specification gets iterated, it needs to be testable, and even more implementable than it already is.

This is where a test suite offers pedagogical tool for first-time implementers, as well as a negotiation tool for seasoned veterans and large corporations managing vast roadmaps and production development pipelines. While many DIF members do not encode VCs in JWT form, this grant is clearly in the common interest because mainstream adoption will indisputably benefit from a clearer, more explicitly-defined, and definitively-testable “normative VC-JWT”.

Selection Process

From 26 July 2021 to 9 August 2021, the chairs fielded applications through a google form, and submitted all valid application to github for posterity. The selection criteria for the work item lead is as follows:

1. familiarity with JWS mechanics and common JOSE libraries/best-practices
2. experience with automated testing, vector design, and test scripts/suites
3. familiarity with LD Proofs and signature suites generally
4. familiarity with JSON/JSON-LD interop problems, at the semantic, signature-verification, and representation/parsing levels

Grantee Announcement

On 12 August 2021, The Claims & Credential (C&C) Working Group at DIF gladly announced Transmute Industries as the recipient of the first DIF Grant to provide a JWS Test Suite for Verifiable Credentials. One of the chairs, Martin Riedel, summarized the chairs’ decision thusly:Transmute has been a thought leader in the SSI space for years and uniquely fits the requirement profile laid out in the Grant announcement.

1. Orie Steele, the CTO of Transmute, is the initiating author of, lead editor of, and main contributor to the (LD-) JSON Web Signature 2020.
2. Transmute has a strong background in TDD and is a strong proponent of delivering test vectors with specifications in order to achieve greater implementation-level interoperability. Examples include Test Vectors in Sidetree.js and did-key.js.
3. The company already provides integrated libraries to support (LDS)-VC and JWT-VC side-by-side, demonstrating their familiarity with both representations. See vc.js.
4. Lastly, Transmute has a strong track record of making specifications and libraries accessible to the general public in a variety of deployed web-projects (https://did.key.transmute.industries/, https://wallet.interop.transmute.world/ and others…)

Therefore we regard Transmute Industries as the ideal candidate to provide a comprehensive JWS test suite for LDS-VC and JWT-VC and support the community interactions around this project within DIF’s C&C Group.

Next Steps

The new work item will be announced and regular meetings initiated at the 23 August meeting of C&C– if you are interested in participating, please attend and/or drop a note in the C&C slack channel.

DIF Grant #1: JWS Test Suite was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our last essay, we explored the means and ends of interoperability targets and roadmapping across stacks and markets. “Interoperability,” like “standardization,” can be a general-purpose tool or an umbrella of concepts, but rarely works from the top-down. Instead, specific use-cases, consortia, contexts, and industries have to take the lead and prototype something more humble and specific like an “interoperability profile” — over time, these propagate, get extended, get generalized, and congeal into a more universal and stable standard. Now, we’ll move on to some technical problem areas ripe for this kind of profile-first interoperability work across stacks.

> What makes sense to start aligning now? What are some sensible scopes for interoperating today, or yesterday, to get our fledgling market to maturity and stability as soon as safely possible?

From testable goals to discrete scopes

The last few months have seen a shift in terminology and approach, as many groups turn their attention from broad “interoperability testing” to more focused “profiles” that test one subset of the optionalities and capabilities in a larger test suite or protocol definition. This decoupling of test suites from multiple profiles each suite can test helps any one profile from ossifying into a “universal” definition of decentralized identity’s core featureset.

As with any other emerging software field, every use case and context has its own interoperability priorities and constraints that narrow down the technological solution space into a manageable set of tradeoffs and decisions. For instance, end-user identification at various levels of assurance is often the most important implementation detail for, say, a retail bank, and DID-interoperability (which is not always the same thing!) might be a hardware manufacturer’s primary concern in being able to secure hardware supply chains.

Every industry has its unique set of minimum security guarantees, and VC-interoperability is obviously front-of-mind for credentialing use-cases. For example, in the medical data space, “Semantics” (data interpretation and metadata) might be a harder problem (or a more political one) than the mechanics of identity assurance, since high standards of end-user privacy and identity assurance have already made for a relatively interoperable starting points. Which exact subset of the many possible interoperability roadmaps is safest or most mission-critical for a given organization depends on many factors: the regulatory context, the culture of the relevant sectors, its incentive-structures, and its business models.

Cross-cutting industry verticals, however, are structural issues with how decentralized identity stacks and architecture vary, which can already been seen today. By applying “first principles,” (or in our case, the “functions” of a decentralized identity system and its many moving parts) across use-cases and industrial contexts, certain shared problems arise. As is our default approach in DIF Interop WG, we applied DIF’s in-house mental model of the “5 layers” of decentralized identity systems, sometimes called “the 4+1 layers”. (See also the more detailed version).

We call these the “4+1” layers because our group agreed that a strict layering was not possible, and that all the architectures we compared for using verifiable credentials and decentralized identifiers had to make major architectural decisions with consequences across all four of the more properly “layered” categories. This fifth category we named “transversal considerations,” since they traverse the layers and often come from architectural constraints imposed by regulation, industrial context, etc. Foremost among these are storage and authorization, the two most vexing and cross-cutting problems in software generally; these would justify an entirely separate article.

In a sense, none of the topics from this transversal category are good candidates for specification in the medium-term across verticals and communities — they are simply too big as problems, rarely specific to identity issues, and being addressed elsewhere. These include “storage” (subject of our newest working group), “authorization” (debatably the core problem of all computer science!), “cryptographic primitives”, and “compliance.” (These last two are each the subject of a new working group, Applied Cryptography and Wallet Security!). These interoperability scopes are quite difficult to tackle quickly, or without a strong standards background. Indeed, these kinds of foundational changes require incremental advances and broad cooperation with large community organizations. This is slow, foundation work that needs to connect parallel work across data governance, authentication/authorization, and storage in software more generally.

Similarly, the fourth layer, where ecosystem-, platform-, and industry-specific considerations constrain application design and business models, is unlikely to crystallize into a problem space calling out for a single specification or prototype in the medium-term future. Here, markets are splintered and it is unclear what can be repurposed or recycled outside of its original context. Even if there were cases where specification at this later would be timely, DIF members might well choose to discuss those kinds of governance issues at our sister-organizations in the space that more centrally address data governance at industry-, ecosystem-, or national- scale: Trust over IP was chartered to design large-scale governance processes, and older organizations like MyData.org and the Kantara Initiative also have working groups and publications on vertical-specific and jurisdiction-specific best practices for picking interoperable protocols and data formats.

That still leaves three “layers”, each of which has its own interoperability challenges that seem most urgent. It is our contention that each of these could be worked on in parallel and independently of the other two to help arrive at a more interoperable community — and we will be trying to book presentation and discussion guests in the coming months to advance all three.

Scope #1: Verifiable Credential Exchange

The most clear and consensus-building, even urgent way forward is to bring clarity to Verifiable Credential exchange across stacks. This has been the primary focus of our WG for the last year. Given that most of the early ecosystem-scale interest in SSI revolves around credentialing (educational credentials, employment credentials, health records), it is highly strategic to get translation and unified protocols into place soon for the interoperable verification and cross-issuance of credentials.

In fact, there has actually been a lot of good progress made since Daniel Hardman wrote an essay on the Evernym blog making a pragmatic case for sidestepping differences in architecture and approach to exchange VCs sooner. This aligned with much of our group’s work in recent months, which has included a survey of VC formats among organizations producing “wallets” for verifiable credentials (be they “edge” wallets or otherwise). Our group has also sought to assist educational efforts at the CCG, in the Claims and Credentials working group, and elsewhere to make wallet-producing organizations aware of the relevant specifications and other references needed to make their wallets multi-format sooner and less painfully. Much of this work was crystalized into an article by co-chair Kaliya Young and crowd-edited by the whole group; this work was a major guiding structure for the Good Health Pass work that sought to make a common health record format (exported from FHIR systems) equally holdable and presentable across all of today’s VC systems.

One outgrowth of this effort and other alignments that have taken place since Hardman’s and Young’s article is the work of prototyping a multi-community exchange protocol that allow a subset of each stack’s capabilities and modes to interoperate. This tentative, “minimum viable profile” is called WACI-PEx and is currently a work item of the Claims and Credentials working group. Work is ongoing on v0.1, and an ambitious, more fully-featured v1 is planned for after that. This profile acts as an “extension” of the broader Presentation Exchange protocol, giving a handy “cheat sheet” for cross-stack wallet-to-issuer/verifier handshakes so that developers not familiar with all the stacks and protocols being spanned have a starting point for VC exchanges. Crucially, the results of this collaborative prototype will be taken as inputs to future versions of the DIDComm protocols and the WACI specification for Presentation Exchange.

Note: There has been some discussion of a OIDC-Presentation Exchange profile at some point in the future, but given that the alignment of DIDComm and Presentation Exchange started over a year ago, the most likely outcome is that work on this would not start until after v1 has been released of the “WACI-PEx” profile for DIDComm has been released.

Scope #2: Anchoring layer

Of course, other forms of alignment are possible as well in the “bottom 3” layers of the traditional stack, while we wait on the ambitious transversal alignment specifications and the ongoing work to align and simplify cross-format support for VCs (and perhaps even multi-format VCs, as Hardman points out in the essay above).

The Identifiers and Discovery WG at DIF has long housed many work items to align on the lowest level of stack, including general-purpose common libraries and recovery mechanisms. It has also received many donations that contribute to method-level alignment, including a recent DID-Key implementation and a linked-data document loader donated by Transmute. The group has also served as a friendly gathering point for discussing calls for input from the DID-core working group at W3C and for proposing W3C-CCG work items.

One particularly noteworthy initiative of the group has been the Universal Resolver project, which offers a kind of “trusted middleware” approach to DID resolution across methods. This prototype of a general-use server allows any SSI system (or non-SSI system) to submit a DID and get back a trustworthy DID Document, without needing any knowledge of or access to (much less current knowledge of or authenticated access to) the “black box” of the participating DID methods. While this project only extends “passive interoperability” to DIDs, i.e., only allowing DID document querying, a more ambitious sister project, the Universal Registrar, strives to bring a core set of CRUD capabilities to DID documents for DID methods willing to contribute drivers. Both projects have dedicated weekly calls on the DIF calendar, for people looking to submit drivers or get otherwise involved.

Scope #3: “Agent”/Infrastructure Layer

There is another layer, however, in between DIDs and VCs, about which we haven’t spoken yet: the crucial “agent layer” in the ToIP/Aries mental model, which encompasses trusted infrastructure whether in or outside of conventional clouds. The Aries Project has scaled up an impressively mature ecosystem of companies and experimenters, largely thanks to the robust infrastructure layer it built (and abstracting away from application-layer developers and experimenters).

Until now, differences of strategy with respect to conventional clouds and infrastructures have prevented large-scale cooperation and standardization at this layer outside of Aries and the DID-Comm project. Partly, this has been a natural outgrowth of the drastically different infrastructural needs and assumptions of non-human, enterprise, and consumer-facing/individual use cases, which differ more at this level than above or below. Partly, this is a function of the economics of our sector’s short history, largely influenced by the infrastructure strategies of cloud providers and telecommunication concerns.

This is starting to change, however, now that agent frameworks inspired by the precedent set by the Aries frameworks have come into maturity. Mattr’s VIII Platform, the Affinidi framework SDK (including open-source components by DIF members Bloom, Transmute, and Jolocom), ConsenSys’ own modular, highly extensible and interoperable Veramo platform, and most recently Spruce ID’s very DID-method-agnostic DIDKit/Credible SDK all offer open-source, extensible, and scalable infrastructure layers that are driving the space towards greater modularity and alignment at this layer.

As these platforms and “end-to-end stacks” evolve into frameworks extensible and capacious enough to house ecosystems, DIF expects alignment and harmonization to develop. This could mean standardization of specific components at this layer, for example:

• The DIDComm protocol could expand into new envelopes and transports
• Control recovery mechanisms could be specified across implementations or even standardized on a technical and/or UX level
• Auditing or historical-query requirements could be specified to form a cross-framework protocol or primitive
• Common usages of foreign function interfaces, remote procedure calls like gRPC and JSON-RPC, or other forms of “glue” allowing elements to be reused or mixed and matched across languages and architectures could be specified as a community

We are very much in early days, but some see on the horizon a day when frameworks that don’t cooperate with one another can’t compete with the ones that join forces. After all, adoption brings growing pains, particularly for the labor market — aligning on architectures and frameworks makes onboarding developers and transferring experience that much easier to do!

Next Steps

I would encourage anyone who has read this far to pick at least one of the three scopes mentioned above and ask themselves how they are helping along this alignment process in their day-to-day work, and if they truly understand what major players at that level are doing. Often large for-profit companies pay the most attention to what their competitors are doing, but here it is important to think outside of competition and look instead at non-profit organizations, regulators, and coalitions of various kinds to really see where the puck is heading. Sometimes consensus on one level is blocking compromise somewhere else. It can be pretty hard to follow!

In recent articles, DIF has encouraged its members to think about an open-source strategy as comparably important to a business plan, a living document and guiding philosophy. I would like to suggest that the subset of DIF companies working with VCs and DIDs should also think of interoperability strategy and conformance testing as the most crucial pillar of that strategy — if you cannot demonstrate interoperability, you might be asking people to take that strategy on faith!

Setting Interoperability Targets Part 2 of 2 was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

[Written in consultation with the Interoperability Working Group chairs]

A recurring topic in the Interoperability Working Group is that of defining short-, medium- and long-term goals or “targets” for interoperability. The topic comes up again every few months, and each time it does, the chairs try to tackle it head-on for a full meeting or two, some emails, and various off-line discussions, but doing so never seems to arrive at a satisfactory or definitive answer. Each time, what feels a Herculean outlay of effort only gets us a tentative resolution, as if we’d deflected a debt collector with a minimum payment. Dear reader, we would like to refinance, or at least restructure, this debt to our community!

In this two-part overview of our goals for 2021, we would like to survey the landscape of “provable,” testable interoperability targets and give some guidance on what we would like to see happen next in the testable interop world. Then, in a companion article, we will lay out clear proposal for parallel, distributed work on multiple fronts, such that progress can be distributed across various subcommunities and hubs of open cooperation, each reasonably confident that they are helping the big picture by “zooming in” on one set of problems.

A seemingly uncontroversial target state

Interoperation is a deceptively transparent etymology: any two things that perform a function are inter-operating if they can perform their operation together and mutually. Two fax machines interoperate if one sends a fax and the other receives it, which is a far more impressive feat if the two machines in question were designed and built by different companies on different continents, fifteen years apart. This is the kind of target state people usually have in mind when they imagine interoperability for an emerging technology.

This everyday example glosses over a lot of complexity and history, however. Standards bodies had already specified exact definitions of how the “handshake” is established between two unfamiliar fax machines before either model of fax machine was a twinkle in a design team’s eye. In addition to all the plodding, iterative standardization, there has also been a lot of economic trial and error and dead-ends we never heard about. Even acceptable margins of error and variance from the standards have been prototyped, refined, socialized, and normalized, such that generations of fax machines have taken them to heart, while entire factories have been set up to produce standard components like white-label fax chips and fax boards that can be used by many competing brands. On a software level, both design teams probably recycled some of the same libraries and low-level code, whether open-source or licensed.

Decomposing this example into its requirements at various levels shows how many interdependent and complex subsystems have to achieve internal maturity and sustainable relationships. A time-honored strategy is to treat each of these subsystems in a distinct, parallel maturation process and combine them gradually over time. The goal, after all, is not a working whole, but a working ecosystem. Architectural alternatives, for example, have to be debated carefully, particularly for disruptive and emerging technologies that redistribute power within business processes or ecosystems. Sharing (or better yet, responsibly open-sourcing and governing) common software libraries and low-level hardware specifications is often a “stitch in time” that saves nine later stitches, since it gives coordinators a stable baseline to work from, sooner.

Naturally, from even fifty or a hundred organizations committed to this target state, a thousand different (mostly sensible) strategies can arise. “How to proceed?” becomes a far-from-trivial question, even when all parties share many common goals and incentives. For instance, almost everyone:

• Wants to grow the pie of adoption and market interest
• Holds privacy and decentralization as paramount commitments
• Strives to avoid repeating the mistakes and assumptions of previous generations of internet technology

And yet, all the same… both strategic and tactical differences arise, threatening to entrench themselves into camps or even schools of thought. How to achieve the same functional consensus on strategy as we have on principles? Our thesis here is that our short-term roadmaps need testable, provable alignment goals that we can all agree on for our little communities and networks of technological thinking to converge gradually. Simply put, we need a few checkpoints and short-term goals, towards which we can all work together.

Today’s test suites and interoperability profiles

Perhaps the biggest differences turn out not to be about target state or principles, but about what exactly “conformance” means relative to what has already been specified and standardized. Namely, the core specifications for DIDs and VCs are both data models written in the Worldwide Web Consortium (W3C), which put protocols out of scope. This stems partly from the decisions of the groups convened in the W3C, and partly from a classic division of labor in the internet standards world between W3C, which traditionally governs the data models of web browser and servers, and a distinct group, the Internet Engineering Task Force (IETF).

VCs were specified first, with a preference (but not a requirement) for DIDs, with exact parameters for DIDs and DID systems deferred to a separate data model. Then, to accommodate entrenched and seemingly irreconcilable ideas about how DIDs could best be expressed, the DID data model was made less representationally-explicit and turned into an abstract data model. This shift to a representation-agnostic definition of DIDs, combined with the still-tentative and somewhat representation-specific communication and signing protocols defined to date, makes truly agnostic and cross-community data model conformance somewhat difficult to test. This holds back interoperability (and objective claims to conformance)!

W3C: Testing the core specifications

The only test suite associated with the core W3C specifications is the VC-HTTP-API test suite for VC data model conformance and the fledgling DID-core test suite, both worked on in the W3C-CCG. The former tests implementations of VC-handling systems against some pre-established sample data and test scripts through a deliberately generalized API interface that strives to be minimally opinionated with respect to context- and implementation-specific questions like API authentication. The latter is still taking shape, given that the DID spec has been very unstable in the home stretch of its editorial process arriving at CR this last week.

The VC-HTTP-API interface, specified collectively by the first SVIP funding cycle cohort for use in real-world VC systems, has been used in some contexts as a de facto general-purpose architecture profile, even if it is very open-ended on many architectural details traditionally specified in government or compliance profiles. Its authors and editors did not intend it to be the general-purpose profile for the VC data model generally, but in the absence of comparable alternatives, it is sometimes taken as one; it has perhaps taken on more of a definitive role than originally intended.

Following the second iteration of the SVIP program and the expansion of the cohort, the API and its test suite are poised to accrue features and coverage to make it more useful outside of its original context. Core participants have established a weekly public call at the CCG and a lively re-scoping/documentation process is currently underway to match the documentation and rationale documents to the diversity of contexts deploying the API.

Aries: End-to-end conformance testing

Other profiles, like the Aries interoperability profile, serve an important role, but it would be misleading to call it a VC data model test suite — it is more like an end-to-end test harness for showing successful implementation of the Aries protocols and architecture. Here “interoperability” means interoperability with other Aries systems, and conformance with the shared Aries interpretation of the standard VC data model and the protocols this community has defined on the basis of that interpretation.

Many matters specified by the W3C data model are abstracted out or addressed by shared libraries in Ursa, so its scope is not exactly coterminous with the W3C data model. Instead, the Aries interoperability profile has its own infrastructural focus, which focuses on scaling the privacy guarantees of blockchain-based ZKP systems. In many ways, this focus complements rather than supplants that of the W3C test suites.

Many of the trickiest questions on which SSI systems differ are rooted in what the Aries and Trust-over-IP communities conceptualize as “layer 2,” the connective infrastructural building-blocks connecting end-users to VCs and DIDs. As more and more features get added to be testable across language implementations, and as feature-parity is achieved with other systems (such as support for LD VCs), the case for productive complementarity and deep interoperability gets easier and easier to make.

The first wave of local profiles and guidelines

Other specifications for decentralized-identity APIs and wallets, modelled on that W3C CCG and/or extending the work of Aries-based infrastructures, are starting to crop up around the world. So far these have all arisen out of ambitious government-funded programs to build infrastructure, often with an eye to local governance or healthy competition. Canada and the European Commission are the most high-profile ones to date, building on earlier work in Spain, the UK, and elsewhere; Germany and other countries funding next-generation trust frameworks may soon follow suit.

It is important, however, to avoid framing these tentative, sometimes cautious attempts at bridging status quo and new models as universal standards. If anything, these frameworks tend to come with major caveats and maturity disclaimers, on top of having carefully narrowed scopes. After all, they are generally the work of experienced regulators, inheriting decades of work exploring identity and infrastructural technologies through a patchwork of requirements and local profiles that tend to align over time. If they are designed with enough circumspection and dialogue, conformance with one should never make conformance with another impossible. (The authors would here like to extend heartfelt sympathy to all DIF members currently trying to conform to multiple of these at once!)

These profiles test concrete and specific interpretations of a shared data model that provide a testing benchmark for regulatory “green lighting” of specific implementations and perhaps even whole frameworks. Particularly when they specify best practices or requirements for security and API design, they create testable standardization by making explicit their opinions and assumptions about:

• approved cryptography,
• auditing capabilities,
• privacy requirements, and
• API access/authentication

These will probably always differ and make a universal abstraction impossible; and that’s not a bad thing! These requirements are always going to be specific to each regulatory context, and without them, innovation (and large-scale investment) are endangered by regulatory uncertainty. Navigating these multiple profiles is going to be a challenge in the coming years, as more of them come online and their differences come into relief as a stumbling block for widely-interoperable protocols with potentially global reach.

The Interoperability working group will be tracking them and providing guidance and documentation where possible. Importantly, though, there is a new DIF Working Group coming soon, the Wallet Security WG, which will dive deeper into these profiles and requirements, benefiting from a narrow scope and IPR protection, allowing them to speak more bluntly about the above-mentioned details.

Setting Interoperability Targets Part 1 of 2 was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

WACI = Wallet And Credential Interactions

WACI was introduced at the annual IIW32 Workshop, where it was received quite warmly as a step forward for open specification. Its goal is simple: to specify interactions between a wallet and a Relying Party (RP) such as an issuer or a verifier, in an ergonomic and agnostic way.

At its core, WACI can be thought of as a handshake using classic, industry-standard JWTs: the “Relying Party” signs a token given to the end-user’s wallet, and the wallet signs over a “challenge” contained within it, proving ownership of a DID.

From there, credentials can be issued or exchanged on the basis of the resulting channel. This channel can also double as a secure authentication, an application “log in” (for DID-based accounts), and a WACI is to offer a way to log into an application without a password with Verified Credential (VC) based authentication that cannot be faked.

Here’s lead editor Jace Henley giving a demo of Bloom’s sample implementation, demostrating the flows being specified further at DIF:

WACI at DIF

Bloom has been a core member of DIF’s Claims and Credentials WG for years, and a core contributor to many of its work items, which focus on specifying and standardizing protocols and libraries that create, exchange, and verify what the SSI community calls “[verifiable] credentials,” and what other sectors of the software industry call “claims” [about a subject]. In fact, WACI evolved out of the earlier, more foundational Presentation Exchange specification, and like its sister specification, the Credential Manifest, its primarily function is to extend the functionality of PE and create an onramp to adoption and implementation of it as a protocol. In a nutshell, Presentation Exchange’s scope ends at how the data is sent between the holder and issuer/verifier, which is where WACI’s begins.

WACI isn’t being donated as a snapshot or as a reference implementation of a finished protocol, however; it’s being donated as a starting point for an ongoing work item in C&C WG that will round out the spec to be more robust and flexible. A first application of this set of interactions is a complex interoperability exercise, developing an interoperability profile for quickly achieving tentative wallet-credential interactions between systems that have implemented all of Presentation Exchange OR all of DIDComm– without having to implement all of both. On the basis of this prototyping experiment, the WACI group expects to fold some extensions and refinements back into the next generation of the WACI specification.

Next Steps for Bloom and C&C collaborators

1. Achieve v1 release of WACI-Presentation-Exchange specification.
2. Fold back in lessons and extensions from #1 and then flush out remaining sections to achieve v1 feature-completeness for v1 of the WACI specification and sample implementation
3. Potentially, work on a new profile (“WACI-OIDC”?) when the next-generation of specifications currently being incubated with DIF participation at the OIDF AB/Connect working group are published
4. Register a custom URI schema (waci://)

Bloom donates WACI was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scalable, Flexible Infrastructure for Decentralized Identity

This week, the DIF Steering Committee officially approved the first major release of the Sidetree Protocol specification, “v1” so to speak. This protocol has already been implemented, and four of its implementers have been collaborating intensively for over a year on expanding and extending this specification together.

What exactly is a “Sidetree”?

Sidetree is a protocol that extends “decentralized identifiers” (DIDs), one of the core building blocks of decentralized identity. Decentralized identifiers (DIDs) enable a person or entity to securely and directly “anchor” their data-sharing activities to a shared ledger, secured by cryptography. The first generation of DID systems accomplished this with a 1-to-1 relationship between “blockchain addresses” (cryptographic identities) and the more flexible, powerful addresses called DIDs. These latter functioned as privacy-preserving extensions of the blockchain addresses to which they were closely coupled. In this way, each DID effortlessly inherited the formidable security guarantees of those blockchains — but in many cases, they also inherited scalability problems and economic models that were a bad fit for many DID use-cases.

Sidetree is a systematic, carefully-engineered protocol that loosens that coupling between anchor-points on a distributed data system (usually a blockchain) and the DID networks anchored to them. Crucially, it replaces the 1-to-1 relationship with a 1-to-many relationship, pooling resources and security guarantees. Depending on the use-case and implementation strategies chosen, the protocol can optimize for scalable performance, for developer-friendly ergonomics and SDKs, for the portability of DIDs and networks of DIDs across multiple anchoring systems, and even for high-availability in low-connectivity contexts where a global blockchain cannot be relied upon directly.

The name “sidetree” combines two hints as to its early technical inspirations and superpowers. Each Sidetree network functions as a kind of identity-specific “Layer 2” overlay network where participating nodes root aggregated operational data into transactions of the underlying chain. This mechanism has many high-level conceptual similarities with the “sidechains” of other “Layer 2” systems, such as the Lightning network running atop Bitcoin or state channel implementations on Ethereum. It also shares with merkle “trees” (and DAGs like IPFS) the self-certifying property of content-addressability, a core building block of decentralized and distributed systems.

Leveraging concepts from sidechains and “Layer 2” network protocols, Sidetree was first proposed by Microsoft’s Daniel Buchner and has been incubated in the DIF community, evolving along the way with major contributions from a growing list of DIF members.

The team that delivered the specification

A global consumer and enterprise app, service, hardware, and cloud infrastructure provider whose mission is to empower every person to achieve more. Microsoft is proud to have worked on Sidetree and implemented the Sidetree protocol via its contributions to ION. As a key piece of infrastructure that is foundational to its Decentralized Identity work, Microsoft is committed to the continued development of Sidetree and ION in DIF.

SecureKey is a leading digital identity and authentication provider, and is a champion of the ecosystem approach to decentralized identity and verifiable credentials, revolutionizing the way consumers and organizations approach identity and attribute sharing in the digital age. This ecosystem-first philosophy informs our investment in Sidetree as a protocol for extensibility and scalability, which can evolve its featureset, and its network model over time. Of particular technological interest to us is how Sidetree can be overlaid on a wide variety of ledger and propagation systems. This will enable identity systems that span many use cases and work across public blockchains, federation and witness protocols, and permissioned blockchains without being locked to any particular ledger technology.

Transmute uses decentralized identifiers (DIDs) and verifiable credentials (VCs) to secure critical trade data by digitizing key trade documents so that they’re traceable and verifiable anywhere in the world, easily accessible and selectively shareable, searchable and auditable, and impossible to forge or alter. Transmute contributed to Sidetree’s development because it leverages batch processing capabilities to achieve enterprise scale and retains maximum optionality for our customers, allowing their business to span many blockchains and trust frameworks. Transmute sees Sidetree-based networks as necessary for scaling up decentralized identity capabilities to a global enterprise scale, where thousands of verifiable transactions per second can be processed at an unbeatable price.

Mattr works with communities and a growing network of companies to shift industries like digital identity towards a more equitable future, providing tools to support digital inclusion, privacy and end-user control. Sidetree represents a significant leap forward in thinking around how to create truly decentralized infrastructure for resilient identifiers. We welcome the agnostic and extensible approach not just to distributed ledgers but also to content addressable storage and other building-blocks of flexible infrastructure. We look forward to integrating many of the DID systems coming out of the Sidetree standardization effort.

The first generation of Sidetree Systems

Transmute maintains Sidetree ledger adapters for Ethereum, Amazon QLDB, Bitcoin and Hyperledger Fabric. We also support interoperability tests with DID Key, the Universal Wallet Interop Spec, the VC HTTP API, and Traceability Vocabulary. Transmute has built Sidetree.js, an implementation of the Sidetree protocol based on the DIF’s codebase that focuses on modularity: it is a Typescript monorepo where each component of a Sidetree node (Ledger, Content Addressable Storage, Cache database) can be substituted with different implementations that use a common interface.

SecureKey has created a ledger-agnostic Go implementation of Sidetree along with Orb and Hyperledger Fabric variations built on top. The did:orb method enables independent organizations to create decentralized identifiers that are propagated across a shared decentralized network without reliance on a common blockchain. By extending Sidetree into a Fediverse of interconnected registries, Orb provides the foundation for building digital ecosystems on top of decentralized identifiers using a federated, replicated and scalable approach.

Microsoft is a primary contributor to ION, an open source, public, permissionless implementation of Sidetree on the Bitcoin ledger. There are several repositories and public utilities that make working with ION easier, including:

• ION GitHub repo: the main repository for the code that powers ION nodes
• ION Tools: JavaScript libraries for Node.js and browser environments that makes using DIDs and interacting with the ION network easier for web developers
• ION Install Guide: A step-by-step guide for installing an ION node
• ION Explorer: A graphical interface for viewing DIDs and auditing other data transactions published to the public ION network.

What’s next for Sidetree

One significant feature on the horizon is to add support for pruning of verbose lineage data (which is no longer needed to maintain the secure backbone of DIDs in a Sidetree implementation) at Sidetree’s anchor points. This addition will allow Sidetree-based networks to purge upwards of 95% of legacy operation data in a decentralized way that maintains all of the security guarantees the protocol currently makes.

Another near-future feature is the so-called “DID Type Table.” DIDs in various DID Method implementations may be typed to provide an indication as to what they DID might represent. The Sidetree WG will publish a table of types (not including human-centric types) that stand for organizations, machines, code packages, etc., which DID creators can use if they want to tag a DID with a given type.

The medium-term roadmap is up for discussion, so if you have ideas get involved!

Sidetree Protocol reaches V1 was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Competitors working together in the open

Having gone over the subtleties and complexities of open-source software and open standards in general, we will now drill down into how exactly DIF advances both, in the form of a “Frequently Asked Questions” (FAQ) document. Topics covered include:

• What “standardization” means to DIF and what DIF means to standardization.
• A newbie-friendly survey of how DIF relates to nearby organizations with overlapping or related foci.
• What “co-development” and “coöpetition” really mean, concretely

The next installment in this series will offer some concrete steps that a DIF member organization (or even a non-member organization) can take to roll up their sleeves and get involved.

We can start with this 2020 diagram of how specific specifications fit in the landscape of open-source and open-standards organizations. Click on the image below to download a clickable PDF file.

What is DIF’s role in “standardizing” decentralized identity?

The governance of the decentralized identity standards space is, by design, decentralized: many different complementary organizations make steady, focused progress on specifications and codebases. In these coextensive communities, each garners consensus and buy-in for a focused set of data models and protocols with overlapping scopes and functions. Claiming the mantle of central authority for decentralization would be a pyrrhic victory for any Standards Development Organization (SDO).

Having been founded as a joint development project, DIF’s guiding mission is to effect harmonization, interoperability, and usability among early adopters, growing rather than controlling the development community. This nurtures healthy competition in the market growing around these technologies and provides a space for competitors to work together openly but safely, balancing “code-first” open source approaches and “standards-first” or protocol-driven ones. Allowing any single standards body (even DIF itself) to set the tone for all of decentralized identity or speak on its behalf would run counter to this mission.

Instead, the DIF exists to support, promote and facilitate two processes that seem to contradict each other at first blush. On the one hand, DIF accelerates the advance of standards and pre-standard specifications and libraries for emerging, decentralized identity systems. On the other hand, DIF strives to decentralize the landscape of identity technology and encourage new forms of data governance, new business models, and meaningful competition in our corner of the sector.

We unite these two processes with a pragmatic, considered, and adoption-ready strategy that is grounded in cooperation with external stakeholders and adjacent organizations. Most of these focus more squarely on technical standards or industry coordination and development, or some narrower set of technologies or protocols; decentralizing identity requires a both/and approach, which is deeply encoded in the DNA of DIF as an organization.

Who are the other major organizations in decentralized identity?

Of the various standards development organizations with which DIF cooperates closely, the World-Wide Web Consortium clearly has pride of place. The core specifications of decentralized identity were incubated there. The verifiable credential specification was ratified (or in W3C parlance, moved to “candidate recommendation” status) over a year ago, and the decentralized identifier specification joined it two weeks ago. As its name would imply, the WWW consortium is squarely focused on the standards structuring the WWW: browsers, cookies, web servers, and other “agents” in the topology of public web browsing.

Many important standards and specifications for data formats outside of the web problem space take place at the Internet Engineering Task Force (IETF), particularly around data representations, transports, and security engineering. This includes many primitives and building blocks of modern programming, like JSON representations, cryptographic primitives, and universal tokens and authentication standards, usage of which extends far beyond the public web. There is a traditional division of labor according to which the web’s data models are standardized at W3C and its protocols are standardized in the IETF, leading to a kind of odd-couple dynamic whereby two very different cultures have grown up around these specialties.

Another major site of coordination for primitives and building blocks is the more constitutively open-source-focused Organization for the Advancement of Structured Information Standards (OASIS). Originally a governance group for XML and the earliest forms of what we now call “Big Data”, OASIS saw its purview and power extended when various global trade and messaging standards were built extending XML. To this day, the Open Office document standards and much of the open-source tooling for PDF, DITA, and other non-proprietary document standards are still governed and advanced through OASIS.

DIF supports decentralized identity by incubating and co-developing prototypes and specifications, some of which are handed off to these more deliberative organizations for formal review and standardization where appropriate. Importantly, though, not all “pre-standards” work has as its goal a standardized or universalized version of that work. In many cases, a specification that was good enough to guide an experimental or contingent implementation making its way to market might serve its purpose well enough without further hardening.

These “DIF-terminal” specifications and sample implementations are apt contributions to the field and the market without going on to formal review. They serve to bootstrap and jumpstart other development by getting more credentials or identifiers into circulation, while growing the pool of developers experienced and excited about the technology and the community. This “build early” approach is crucial to refining and hardening other parts of the stack, as well as building up a market and its workforce.

How does DIF work together with these organizations?

DIF is not the only pre-standards organization in which specifications and implementations are co-developed by early adopters and explorers of this family of technologies and applications. Anywhere companies and individual experimenters collaborate on open-source projects, “co-development” is happening, but these too vary in the kinds of collaboration for which they have designed and optimized their processes.

The earliest work in this space, as well as much of the long-view-oriented work developing tooling for open-world data models and Linked Data tooling, takes place in the Credentials Community Group (CCG) of the W3C. The CCG is a community group operated through the W3C but open to participants that do not pay W3C dues. It promotes and hosts pre-standards work and maintains dialogue with various other W3C groups, not just those chartered to work on the VC and DID specifications. Since the CCG is hosted by the W3C, it inherits many of the procedures and specification publication processes from the members-only processes of the Consortium. The Secure Data Storage working group is cosponsored by the CCG and DIF to maximize the community-wide participation creating a pre-standards specification for Confidential Storage structures that can serve many different kinds of decentralized identity and data systems.

The Linux Foundation houses a complex family of Hyperledger projects, which coordinate global contributors to massive open-source codebases that power blockchains and other decentralized data and identity systems. Indy, the first major fit-for-purpose permissioned distributed ledger optimized for decentralized identity applications, is the oldest and most high-profile of the identity-focused projects in Hyperledger, designed to anchor decentralized identities and governed by the Sovrin Foundation.

Another major Hyperledger project is the modular and progressively more blockchain-agnostic Aries community, which evolved out of Indy-specific open-source systems. The Aries Project offers many common libraries, entire single-language frameworks, and cross-framework protocols so that small companies can quickly build into an ecosystem of interoperable service providers and business models. The DID-Communications working group is co-sponsored by Aries and DIF, allowing members of either group to participate directly in the specification of a DID-based communications protocol for the entire decentralized identity community, not just the ecosystem built around the Aries codebases.

Other groups also overlap and coordinate with DIF in their development of implementations and specifications in advance of formal standards. One of these is the OpenID Foundation (OIDF), which governs increasingly widespread standards for authentication that federate identity systems across most of the commercial consumer internet. As with Hyperledger Aries and CCG, this relationship is formalized as a “liaison agreement” between the two organizations, and also entails a Liaison Officer to coordinate the relationship; DIF’s DID Auth WG was put on pause in mid 2020 to focus on work happening in OIDF working groups, and hopes to re-open regular meetings to work on items on the DIF side again soon.

Another is the Linux Foundation’s first project devoted exclusively to data governance and related legal and ecosystem management issues, the Trust-over-IP Foundation (ToIP), where many DIF members work on task forces and working groups on compliance issues, consent tracking, data-capture best practices, and industry-specific governance issues. The decentralization-friendly but wider-scoped Kantara Initiative, which promotes user-centricity and data subject rights in legacy identity systems, is also an important touchstone for regulatory and legal issues. The Sovrin Foundation continues to maintain the active Indy production network and house many important collaborations and working groups, and are represented in many DIF working groups.

Coöpetition and DIF’s particular brand of co-development

The way DIF relates to other organizations working in the same space arose naturally from DIF optimizing its processes for neutrality and collaboration between companies of different sizes and market positions. DIF’s culture is one of business collaboration aligned with the increasingly buzzy term “co-opetition” (sometimes spelled “coöpetition” to emphasize the pronunciation). The term is a portmanteau combining cooperation and competition, but the clearest definition might be “coöperation between competitors, who remain competitors before and after coöperating”.

“Coöpeting” early in the design process makes for a unique pact between competitors, one that is crucial to the DNA of DIF: it is a forward commitment, before the design process, to cooperate through and after release of an open standard or codebase. This kind of pact makes the most sense in situations where network effects and portability of data and users matter more than platform control and vendor lock-in. Indeed, when your business plan is to maximize openness and interoperability, you end up cooperating earlier and more deeply than in more siloed forms of “open source” development. After all, much of what we consider open-source wasengineered for a single vendor’s business goals and opened up after release, once all the major design decisions had been made and tested. The difference of timeline and design process is hard to overstate!

Put bluntly, committing to coöpetitive development of common standards and protocols is committing in advance to a truly open standard, rather than one which advantages its designers on its path to general adoption. This kind of pact is particularly useful when forged between companies that are direct competitors or companies of vastly different sizes.

Cooperating in the patent-free zone

In large part, competitors and companies of different sizes find it far easier to work together substantively on new ideas once a safe space has been established for new ideas. Startups stay up at night worrying that their best ideas could be patented out from beneath them by collaborators with well-staffed legal departments, and large enterprises hesitate to do any work in the open that might endanger their R&D inventions. The solution for both is often coming together openly on a precisely-scoped working group or project with proper “IPR protections.”

Put in plain language, the IPR agreements protecting DIF’s work prevent all contributors from taking legal action against the results of the group, whether on the basis of previously-held patents, or the new ideas originating in the group.

The terms of these IPR agreements can seem cumbersome to people coming from non-profit or academic research, but in the private sector and particularly at industrial or global scale, the enforceability in global courts of ownership over ideas and patents is absolutely essential to software investments, infrastructural governance, and even geopolitics. The protocols, specifications, and libraries co-authored in an IPR-protected group can be thought of as safe dependencies, which cannot have their open-source status (i.e., their royalty-free status!) endangered by the current or pre-existing intellectual property of any of its contributors. The relative degree of this safety is of huge importance to infrastructural decision-making and long-term planning. These assurances can be an important insurance policy against one major risk in software development — patent action against code or its dependencies.

Another crucial way in which this kind of “co-development” protects participants from the risks inherent in cooperating with competitors is that DIF, not the contributing member organizations, “owns” the products of its members’ collective labors. In concrete terms, this means the ongoing governance, maintenance, and licensing of the products of working groups, often referred to as “technical control” of resulting code or specifications, stays with the Foundation rather than with any of the legal entities contributing. The risk that a trusted co-development partner will change its strategy, its culture, or its ownership and thus its governance structure is only one of the many unsavory surprises a product or a company can meet on the road to market.

This means that if the relationship sours between two parties collaborating on a standard or a reference implementation, the work might “fork” and take on two different future paths, but the version ratified by DIF stays open to the public under DIF’s management. In such a case, any DIF member can join the relevant group and maintain the project’s main branch, or influence future versions if the group continues the open work. In fact, DIF’s licensing even imposes some restrictions on contributing organizations forking a DIF collaboration to continue the work elsewhere, whether further development is carried out in the open or not.

It is important to note that DIF is not original here, but rather, standing on the shoulders of giants. We were founded within the Joint Development Foundation, now part of the Linux Foundation, and inherits not only their licenses and legal structures but also their culture of co-development and IPR protection. While the staff of DIF is happy to help socialize, navigate, and enforce these structures, none of us are lawyers and we defer to the professionals (including those available to DIF through the JDF) for all serious matters and conflict resolution on the subject of intellectual property.

Drilling further down

We’ve sketched out the different kinds of open source development and the many ways variously-open standards can structure markets, and positioned DIF among all these concepts and its neighbors in the community. There’s not much further down we can drill in general terms: it’s time to get particular and start positioning you and your organization in this landscape! In our next piece, we’ll sketch out how you can get strategic about open source, roll up your sleeves, and get your hands dirty at DIF.

Drilling Down: [Co-]Development in the Open was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

DIF held its semiannual “Face-to-Face” community’ event this week, and man what an event it was! For obvious reasons, it was virtual for the second time, and for the first time, it spanned both Zoom and the interactive social platform gather.town, giving a more intimate atmosphere and allowing for more organic networking than often happens at “tele-conferences.” If you missed it in part or in full, you’ll find below summaries and recordings of the main events.

1# Opening remarks, and an update on DIF-OIDF Collaboration

Executive Director Rouven Heck got us started on a warm and welcoming note, bringing the largely unfamiliar audience up to date on DIF’s member-driven nature and its goals for 2021. These include a more engaged membership, more co-development at various scales, and more work items reaching stable specifications and publicly going from community incubation to commercial production.

Then, presenting from Tokyo (actually a little before the opening remarks, as is our asynchronous way here at DIF) Kristina Yasuda (Microsoft, Mydata) gave an update on her new role as the liaison between DIF and the OpenID Foundation. Joined by DID Authentication WG chair Oliver Terbu (Consensys Mesh), Kristina gave an overview not only of the ongoing SIOP work in the AB/Connect WG at OIDF, but also other identity-related efforts that might be of interest to DIF members, including the MODRNA and KYC-IDA working groups.

2# Interoperability and DIDComm working group

The “main stage” working group presentations started with the Interoperability Working Group, which has taken a break from its test-harness/test-suite role under its new chairs to concentrate on educational materials that support broader interoperability among verifiable credential protocols… and a better understanding of those protocols among decision-makers on the business side of the decentralized-identity business.

The chairs (Pam, Kaliya, and Juan) gave an overview of the last 6 months of their group, its publications and maps, and other products, an overview of their invited guests (and handy recordings), as well as the “parking lot” for future discussion/research topics for Q1.

The DID Communications Working Group, energetically presented by Chair Sam Curren (Indicio, Mattr), got the ball rolling with a swift and accessible overview of the group’s rapid progress from ambitious roadmap to the sophisticated draft specification since the last conference. In addition to the specification reaching its final rounds of editorial clean-up, many “nice to have” protocols that were put out of scope while the group focused on the specification alignment process (specifically a Bluetooth implementation and an NFC implementation) have spun out into parallel work items, which are already underway. In other DIDComm news, DIF member Jolocom announced this week a DIDComm v2 sample implementation in Rust, built for the company’s [otherwise completely non-Aries!] wallet. It seems 2021 will be the year of DIDComm!

3# Claims and Credentials, Presentation Exchange, and Sidetree

The Claims and Credentials group’s co-chair Wayne Chang (Spruce Systems) took a quick stroll through the new work item initiation process (currently being extended to other WGs DIF-wide) and the other major work items: the paused Credential Taxonomy, the work item formerly known as Credential Manifest, the new VC Marketplace.

DIF’s first Executive Director, Daniel Bucher (Microsoft Research), gave a quick overview of the Presentation Exchange spec, an ambitious specification for scaffolding credential requests and presentations between unfamiliar systems. After months of collaboration with core architects of the Aries ecosystem from DIF member Evernym, the presentation and request mechanics have been aligned with the upcoming iteration of the relevant Aries “Present Proof” RFCs, making this a major interoperability win that bridges the largest production ecosystems the decentralized identity space has yet seen. The specification is in the very home stretch of reaching 1.0 status and in the last weeks of a period of public comment, so give it a read and leave some issues soon if you have any!

Daniel also presented the other specification he has been tirelessly driving for even longer than the Presentation Exchange work item at Claims and Credentials — the Sidetree specification, which reached v1.0 this week. In this quick, extemporaneous video, Daniel runs through some common misconceptions and relates the overarching Sidetree Layer-2 architecture to Microsoft’s specific Ion implementation, the work of DIF members SecureKey on a Hyperledger Fabric implementation, DIF members Transmute’s Ethereum implementation, and even the affinities with DIF’s next working group to spin out of I&D, KERI.

4# Secure Data Storage WG, Identifiers and Discovery WG, and KERI

From potentially universal specifications for presenting credentials, we jumped straight to potentially universal specifications for storing credentials and other confidential data. The Secure Data Storage working group co-chair Dmitry Zangadulin (Digital Bazaar) talked about the group’s first and flagship specification, Confidential Storage, which is designing a modular and DID-controlled storage protocol that would allow so-called “encrypted data vaults” (with or without a coupled authorization server called an “identity hub”) to create a portable, secure, redundant, and replicable storage layer for the decentralized identity world. In addition to bringing the audience up to speed on the current status of the specification work and prototyping, the group also gave a quick overview of the many guest presentations since the last F2F, spanning the cutting edge of decentralized storage and next-generation database projects.

Identifiers and Discovery WG, the oldest continuously-active group at DIF, gave a detailed overview of its impressive roster of donations, work items, and updates since the last F2F. Chair Markus Sabadello (DanubeTech) ran through this long list. These include research on WebID and key recovery/roll-over systems, the evolving WebID pre-standard being discussed in some browser groups of W3C, new common libraries in .NET and Rust. Markus also explained to those new to the space the group’s broader mission of supporting the DID ecosystem and DID methods in particular as they experiment with decentralized governance and infrastructure. (Of particular interest to close watchers of the space was his update about the Universal Resolver project offering up very high-level analytics (privacy-preserving, of course!) about resolution activity on the public “testnet” service.)

Markus’ co-chair, Sam Smith (ProSapien, Digital Trust Ventures) talked about his passion-project, soon to become its own DIF WG: Key Event Receipt Infrastructure, or “KERI.” KERI offers a new way of thinking of the “layers” of decentralized identity infrastructure, focusing doggedly on the “bottom half” of the concerns of a traditional DID method and separating itself entirely from the “top half,” including method-specific namespacing and all [clear-text] data. After months of honing the skill, Sam impressively conveys a considerable portion of the core concepts in this complex and nuanced system in a record-setting fifteen minutes!

5# Special Interest Groups: Product Managers, Banking and Finance, and Healthcare

Transmute’s Margo Johnson, co-chair of the Product Managers’ community of practice, gave a quick overview of their very generative and generous non-technical working group. In addition to producing a useful open-source corpus of discussion notes, presentations, and UX blotters, and the like, the group is also an important watering hole for product and user interface design thinking, covering such topics as accessibility, ethics, and adoption strategies, for products but also for new concepts of software (and better user interface patterns) more generally.

Co-chairs Paul Dunphy (OneSpan) and Isaac Patka (Bloom) gave a fascinating overview of the activity of their fast-moving and diligent Banking and Finance open group. Paul introduces the philosophy, focus, and working methods of the group, then Isaac overviews the invited guests to date. In addition to hearing reports from SSI researchers in the financial services space, the group is also building out a wiki of relevant regulatory events in the space, as well as opportunities in the space like the UK’s financial regulatory sandbox, the subject of their next meeting with Evernym’s Andy Tobin.

Interim Chair Juan Caballero (LearningProof) gave a brief overview of the discussion group’s intentions and format. These could respectively be summarized as exploring the opportunities and access points for innovations in the healthcare space, and a recorded invited-guest series where researchers from the space offer “reverse pitches” about pain points and problems that decentralized identity might be uniquely suited to solve. As with all of DIF’s special-interest groups, the group is open to DIF non-members and interested parties can reach the chairs through the group’s repository, where they can also find notes and recordings of all guests to date.

Stay Tuned and Get Involved

As you can see, the DIF community has grown considerably since the last F2F, and keeps expanding into new terrains and modalities. If you work in the decentralized identity space or are trying to move your work into it, please consider joining the foundation, joining one of these working groups and special-interest groups, or even bringing a future project into DIF as a work item.
Or subscribe to our monthly newsletter.

DIF Face to Face Jan 2021 Highlights was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the years, the Identifiers and Discovery WG at the DIF has received many donations that form a vital resource for developers of DID-based systems: recently, a flotilla of complementary secret recovery mechanisms, a command-line tool for handling Verifiable Credentials that was the foundation for years of JWT work in the Ethereum community, the .well-known specification, and the /did-common-{language}/ series of basic libraries and tooling in various popular languages, to say nothing of the donations of drivers for the open-ended Universal Resolver project.

The newest donation to the I&D WG archive is an implementation of did:key built in the Rust language by long-time active DIF members, Trinsic. In addition to being great news for the I&D WG itself, it is also great news for the “target audience” of the WG: developers trying to smoothly and efficiently extend the domain of DID-based systems to new programming languages, use cases, and contexts.

Don’t all DIDs contain keys?

DID:Key, originally specified in the W3C Credentials Community Group (CCG), is a DID “pseudo-method” that allows static, pre-existing, and/or pre-published public keys to function like traditional DIDs — they can be queried, stored, issued against, and resolved to return valid DID documents. These DID documents, or “pseudo-documents” if you prefer, are generated deterministically from their public keys, allowing the integration of complex key management systems involving cold storage, hardware security modules, etc.

This “masquerade” of wrapping external or pre-existing keypairs in the form of a valid DID is crucial to many kinds of interoperability, legacy integration, and testing. It can be a life-saver in both the early days and the home-stretch of moving to production in the messy real world of legacy systems and interoperability stress-testing.

Like the /did-common-{language}/ series, a plug-and-play library that handles all the transformations between different kinds of key and their “DID-ification” is a huge time-saver for people working in new contexts, or contexts where prior art has not yet been open-sourced. In addition to these advantages, the unique design of did:key has also been valuable in demonstrating the flexibility and universality of the DID concept itself — and that DIDs can seamlessly interoperate with systems that do require a blockchain or similar technologies.

Rust and DIF

Rust has earned a reputation among contemporary blockchain and web developer communities, in large part because it is so performant, controllable, and versatile across in-browser, server-side, and cloud environments. It plays nicely with widely different programming languages as well.

In particular, it has also been designed to be smoothly integrated into JavaScript systems, for decades the most common language in most kinds of web development. In fact, many of today’s JS developers consume Rust/WASM libraries without even knowing they’re doing so. The libraries from Hyperledger Aries, for instance, use Rust cryptographic libraries packaged and managed by the Hyperledger Ursa project.

One crucial distinction, however, between Rust and Javascript is that the former has a drastically different way of managing dependencies and packages. In addition to being very resource-conscious in their assembly, “crates” (as the packages are called in Rust’s native “cargo” package management system) can be imported and compiled selectively, using only what each project needs “at build”. For in-browser, edge-device, and other resource-constrained environments, this makes a world of difference compared to traditional JS frameworks like Node or Angular.

While the authoritative branch of the source code is being donated to DIF where it will stay open to new issues and pull requests from the DIF community, the “crate” is already available at crates.io, and can be used directly in your project’s Cargo.toml file:

did-key = “*”

Extending the library

Like all code donations to DIF, there are many ways in which this library can be extended. GitHub issues and pull requests are open! So far, the key formats currently supported are:

• BLS12381 (G1 & G2 derivations)
• Ed25519
• X25519
• NIST P256
• Secp256k1

If you find this project useful in your own development, whether for compliance-testing, for supporting new verifiable credential formats like BBS+, or for extending your interoperability and compatibility reach, please leave an issue describing future features you might find useful. Better still, if you have experience with Rust/WASM, please consider getting involved and contributing features, leaving constructive feedback, or extending the specification’s documentation and implementation guidance notes.

We also welcome you to join and participate in the I&D Working Group, regarding any questions or contributions to the Rust did:key implementation or one of the other work items!

Trinsic donates did-key.rs to I&D WG was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

DIF is proud to announce that it has entered into a liaison agreement with the OpenID Foundation (OIDF). This provides a mechanism for both parties to work together on areas of mutual interest, allowing working groups to align and coordinate through dual-members. The first major collaboration, which has already been underway for weeks, is a process for revising the Self-Issued OpenID Connect (SIOP) chapter of the OpenID Connect (OIDC) specification. This revision takes place in the AB/Connect working group of OIDC, which focuses at any given time on extending the core OIDC specification.

Given the foundational nature of this collaboration (and the potential for breaking changes or mental-model shifts in the next major version), the work on DIF’s Self-Issued OpenID Connect Provider DID Profile working draft, referred to colloquially as “did-siop,” has been paused. It is expected to resume, still housed as a work item in DIF’s DID Authentication Working Group, after the work on the new SIOP specification in AB/C is finalized. Other collaborations on OIDF work items are also expected.

DIF members from the group are actively contributing to the new version of SIOP specification through OIDF’s structure and channels. If you are interested in advancing or contributing to this work substantially, you are very welcome to join the calls, details of which you can find here. If you are not a member of OIDF, you may contact the chairs of the DID Auth working group, or the DIF’s Liaison Officer to OIDF, which are listed at the bottom of the working group’s webpage.

NOTE: The latest version of the “did-siop” specification has not been approved by the DIF steering committee; it is currently paused at v0.1 and remains an unofficial Working Group Draft at time of press.

DIF & OIDF was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.

Adoption by markets, standards bodies and regulators is largely contingent upon provable security and provable interoperability, so these promising developments cannot come soon enough.

The Digital Identity Foundation (DIF) is very proud to be hosting one particular research and development project that could prove pivotal in this process. It is currently a work item of DIF’s Identifiers and Discovery Working Group. However, a charter for an autonomous working group will be available for review at #IIW31 this week (20–22 October 2020) to facilitate broader participation. The project is called KERI and it is a project that could only be developed in the open, for the public good and for the widest, quickest adoption.

But first, what is KERI?

KERI stands for Key Event Receipt Infrastructure. A “key event” is a discrete event in time that involves public/private keypairs, often called blockchain identities or cryptographic identities. These events can be generalized as inceptions (creations), rotations, and signing events: the three kinds of events for which KERI generates and handles receipts. In other words, key events are cryptographic events in the history of an identifier.

Importantly, everything else a decentralized identifier says, does, or refers to is not a key event. As KERI is deliberately laser-focused on key events only, we can call these other events non-KERI events. The real world consequences of a signature or rotation are out of scope and method-specific to boot. KERI is only interested in the most universal aspect of interactions between keys and cryptographic systems, i.e. the cryptography that allows drastically different DID systems to trust each other’s security guarantees.

“DID Methods exist to solve a trust issue. This does it in a different way.”

Charles Cunningham (Jolocom GmbH, Rust development lead for KERI)

Each key event produces a receipt containing only checkable signatures of key event information. Nothing more. Receipts are threaded into logs tracking the history of each identifier, which is similar to a traceable audit trail of hashes — useful for confirming but not for deducing the underlying key material. These threads are compiled into logs that are shared and replicated according to a consensus algorithm and a logic of trust thresholds that creates a fabric of shared history between nodes.

Is KERI a blockchain or a DLT? No. Does it replace blockchains? Also no.

The trust fabric created when KERI nodes share and propagate key material records might

sound redundant to the blockchains where all of today’s DID methods store their key material chronologically. To a degree, this is true: each log containing the history of one key is a “microledger,” like a blockchain with only one participant. Inception and rotation events in all of today’s DID methods are stored in a chronological distributed ledger which can be crawled to create a log of these key events by DID. So, why the redundancy? Why replicate a subset of the blockchain’s capabilities and features in a distinct blockchain-like infrastructure just for key material?

The answer is simple and manifold: blockchains enable many features outside the scope of KERI. These features bring with them complexity, diversity, scale costs, and trust issues. Within KERI’s scope, however, only some of a blockchain or distributed ledger technology’s (DLT’s) features are necessary. Total ordering and double-spend protection, for instance, are hallmarks of distributed ledgers, but hardly justify the added complexity here.

Working backwards from a short list of security features, KERI infrastructure can be a much more performant, minimalist distributed ledger system. It is still in the family tree of blockchain, DLTs and directed acyclic graphs (DAGs), but it is closer to a sidechain or a trans-blockchain interoperability mechanism. In use cases where all that is needed is a self-certifying, widely-portable identifier, KERI can stand alone as a lightweight DID method. In combination with a traditional DID Method, KERI can increase key management options and strengthen security guarantees by raising a red flag at the first discrepancy between the two parallel and redundant systems.

As a scaling mechanism, KERI can also take away some of the traffic and complexity from the underlying blockchain. In implementations where key management and state maintenance (record keeping about keys that rotate over time) are entrusted directly to the KERI mechanism, these functions can be operated much closer to the edge and replicate after a slight delay. This might be a totally acceptable trade-off of efficiency for latency in many use cases. For example, a roundtrip write-and-wait-for-finality transaction on a global blockchain makes no sense in a low-connectivity Internet of things (IoT) use case, where double-spend is a non-issue.

KERI is both an interoperability mechanism and a standardization incentive

More importantly for the DIF, however, is another major feature of KERI: it could become the foundation of massive interoperability and portability at the infrastructure layer. What’s more, if adopted by enough major players, it could even speed up the standardization process of DIDs themselves. By offering a minimum level of security guarantees shared across all participating methods, it would simplify the security review process for both individual DID methods and for interoperable DIDs as a whole.

By abstracting out the universal, minimal set of key functions, a KERI log that spans multiple ledgers or methods is just as verifiable as one that does not. This means that anywhere

self-certifying KERI identifiers are accepted, an identifier’s history can stretch back further than the existence of KERI. Plus, that history can include so-called “portability events”, where an identifier is deactivated on one ledger and re-activated on another. Method-specific features or records might still need to be exported and imported. The core proof of control function of a DID, however, would be universalized in a way that enabled massive portability.

This same universalizing effect of sharing a security vocabulary across all participating DID methods has the added benefit of being able to guarantee certain security features in any KERI-compliant system. Since KERI also lends itself to simple compliance tests, and since KERI logs give a benchmark against which to test method-specific and blockchain-specific security, this is a small leap for each DID method and a giant leap for standardization and security engineering.

KERI’s history: from whitepaper to community incubation

So far we have been highly technical in our explanation of the project. A careful reader, however, may already have caught the community commitment implicit in phrases such as “KERI-compliant” and “participating DID methods.” KERI is only useful if the major DID methods incorporate it, or if the set of participating DID methods becomes congruous over time with the set of major DID methods.

It is, in a nutshell, a community project of alignment as much as a technological innovation: an agreement on the security model for the common core functionality shared across all DID methods, allowing much variety and extensibility to be preserved by the participating DID methods. Decentralized identifiers have been very decentralized in their design and governance from the beginning, with a high degree of extensibility and flexibility within the fiefdom of each DID method and its governance. KERI has been gathering steam for over a year as a countervailing force, potentially making all DIDs function in an end-verifiable and thus universal way.

“Investing in KERI is investing in interoperability, standardization, and cross-community security guarantees.”

Dr Sam Smith, author of the KERI whitepaper and project lead

In large part, the roots of KERI lie in debates within the World Wide Web Consortium’s (W3C’s) Decentralized Identifier Working Group. For years it has been discussing the “shalls” and “mays” that define a W3C-compliant DID method (and thus a DID system). In practical terms, this process specifies what each DID method can and must assume about other DID methods for such a decentralized and open system to make appropriate security guarantees.

KERI’s creator and the author of its whitepaper is Samuel M Smith PhD., a pioneering technologist in multiple fields, including automated reasoning, distributed systems, autonomous vehicles and blockchain protocol design. Dr. Smith has been refining and experimenting with such a cross-method mechanism since 2019, presenting at every meeting of the biannual Internet Identity Workshop. First came some core principles and requirements of a key infrastructure at IIW28, then at IIW29 a series of sessions about different aspects of a hypothetical system of witnesses that could replicate logs. For IIW30, Dr Smith brought more concrete sessions on finer points and even the roadmapping session that became the DIF working group. Along the way, he has iterated an ever-growing whitepaper describing and explaining all of this.

Now, however, Dr Smith has moved the project into the DIF under the auspices of its Identifiers and Discovery Working Group where he sits as co-chair. Asked about the decision, Dr Smith said, “DIF was a natural choice because I wanted the work to happen quickly but in the open, with participation from the greatest number of companies and innovators across various communities.”

KERI’s contributors: join us!

Foremost among DIF contributors is, of course, Dr Smith, who brings to his KERI design work more than a decade of engineering experience with scale and high-performance systems. Much of this work, focusing largely on AI and streaming/scaling projects, was done through his Python-centric consulting company Prosapien.com. He has also worked with Consensys, contributing to the Seed Quest project among others, soon to be donated to DIF.

Berlin-based Jolocom GmbH has been a major interlocutor in the early development of KERI, since before the creation of the working group at DIF. Jolocom’s Charles Cunningham is the working group’s lead Rust developer, who has written a highly interesting post about mental models of How KERI tackles the problem of trust from a developer’s point of view for the Jolocom logbook.

Representing Spherity GmbH are the working group’s lead JavaScript developer and note-taker. Spherity’s founder, Carsten Stöcker, has written a detailed piece for his company’s blog which called KERI “a more performant ledger for trusted identities.”

The Human Colossus Foundation, a Swiss-based non-profit, has been co-developing on the Rust side as well, working in parallel and providing input on the design considerations. The Human Colossus Foundation has also put substantial energy into promoting and socializing KERI in the Trust-over-IP Foundation, the MyData community and in the Sovrin community, including featuring an hour-long KERI session prominently in a half-day mini-conference it organized.

At IIW31, the KERI developers will be demonstrating their initial work to date while there is still the opportunity to get involved and determine the course of KERI as the project moves from direct mode (two-party) to witness mode (multi-party, distributed consensus). Many sessions are planned for IIW, ranging from introductions to technical discussions to use-case and requirements gathering for KERI-based ideas. Additionally there will be a live demo of the working direct-mode prototype.

Introductory reading and video materials are collected at the main DIF repository, but even if you don’t watch them in advance (or fully understand them if you do), there are many ways to get involved and make this community project stronger and more diverse.

KERI: For every DID, a microledger was originally published in Decentralized Identity Foundation on Medium, where people are continuing the conversation by highlighting and responding to this story.