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. In this FAQ, we'll cover what co-development means in general, at DIF, beyond DIF, and in legal terms. 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.
Let's 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.