Digital self sovereign identity Image
06.11.2020

Highlights of #IIW31

Nader Helmy

Last month’s Internet Identity Workshop (IIW) was held entirely online for the second time in its history. This bi-annual unconference, typically hosted in Mountain View, CA at the Computer History Museum, connects a wide variety of people from across the globe focused on solving the hard problems around digital identity. As an unconference, the attendees set the agenda each day. The format is focused on open collaboration which creates a real and rare opportunity to organically discuss not only the latest technology developments, but also the surrounding social, political and legal implications.

This year, over 400 attendees from across the globe participated in IIW31. It was a great showcase of both the work and progress being achieved across a variety of open standards and open source communities.

Although there is too much to cover in one write up, we wanted to highlight MATTR’s pick of the three major themes:

  1. KERI comes into the spotlight
  2. Bridging Decentralized Identity with Federated Identity Systems
  3. Self-Sovereign Identity (SSI) maturing into multi-dimensional & relationship-oriented identity

KERI comes into the spotlight

One of the technologies that received a great deal of attention this year was Sam Smith’s Key Event Receipt Infrastructure (KERI). Sam first introduced this topic over a year ago, and it’s evident that a lot has happened since then to bring these ideas and concepts to life.

KERI attempts to address the self-certifying aspect of identifier-based systems such as DIDs. Central to this technology is the concept of Key Event Logs (KELs) which are maintained by each user in a distributed identity system. Key Event Logs contain digitally signed messages of all key management related transactions done by the user, and can be used not only to prove control over your identifier, but also shared with other external ‘witnesses’ who can independently validate and prove that you control your identifier. In practice, this means that KERI identifiers and keys are not “ledger-locked”—they are fully portable and can be validated using any ledger, distributed database, or other verifiable data registry.

In a session called “KERI for Muggles”, Drummond Reed and Sam Smith identified 7 main characteristics that make KERI useful for identity:

  1. Self-certifying identifiers
  2. Self-certifying Key Event Logs
  3. Witnesses for Key Event Logs
  4. Pre-rotation as simple, safe, scalable protection against key compromise
  5. System-independent validation
  6. Delegated self-certifying identifiers enable enterprise-class key management
  7. Compatibility with the GDPR “right to be forgotten”

There were a number of additional sessions that dived into advanced KERI topics, including how KERI can create interoperability between different DID methods and solving the operational concerns related to bringing these ideas to life. There are several ongoing open-source projects at the Decentralized Identity Foundation (DIF) which are driving this work forward. We look forward to the positive change this will bring to our ecosystem, particularly in reducing our technology’s strict dependence on specific infrastructure like distributed ledgers.

Bridging Decentralized Identity with Federated Identity Systems

Following on from IIW30, there was a continued theme around the bridging of W3C Verifiable Credentials (VCs) with existing identity protocols on the web today such as OpenID Connect (OIDC), which are mainly used in federated identity systems. 

Evolution of existing protocols such as OIDC allows existing infrastructure providers to make adjustments to their implementations in order to start using new technology, rather than having to tear it all down and rebuild. The goal here is to build as much as we can upon previous work while addressing a number of significant shortcomings around federated identity as it exists today. We’ve covered this topic before, so needless to say, we’re committed to solving this problem and we were extremely supportive of the continued discussion around these issues at this IIW.

A key component of this approach is the ability to  allow existing identity solutions to issue and verify Verifiable Credentials. One way to achieve this is to extend the OpenID Connect protocol to enable more portable digital identity. Instead of using OIDC as a bearer token between an Issuer and Relying party, we can create a client-bound assertion that’s held in a user’s digital wallet. To that end, we introduced an approach that we’re calling OpenID Connect Credential Provider, which turns traditional Identity Providers (IdPs) into credential providers. It modifies current authentication/issuance flows used by OpenID Connect to allow IdPs to issue assertions that are re-provable and reusable for authentication. This helps to decouple the issuance of identity-relation information and the presentation of that information by a user, introducing the “wallet” layer between issuers and relying parties. There was great participation in this discussion from some of today’s existing Identity Providers, and one of the outcomes from this IIW is that the specification will be contributed to the OpenID Foundation (OIDF) as a work item, where it will be further developed by the community there.

There was also a great deal of interest around the evolution of Self-Issued OpenID (SIOP). The SIOP chapter of the OpenID Connect specification was written in a way that clearly tried to leave room for some of the user-centric design concepts that are quite popular today, but given that it was first introduced in 2014, it lacked the context of today’s technologies such as DIDs and VCs. ُThere’s a laundry list of topics to cover here, so kick starting this effort has been a matter of breaking down each component and coming up with potential solutions. We identified 3 main problems that SIOP aims to address:

  1. Enabling portable identities between providers
  2. Solving the NASCAR problem
  3. Dealing with different deployment types of OpenID providers

There are a number of insights we can gain by addressing each of these issues separately, and bringing them together to form more robust solutions. It was exciting to see that there are many people interested in revisiting SIOP and trying to address the underlying issues with federated identity. The work will continue to develop at the OpenID Foundation AB working group, so the conversation doesn’t stop at IIW.

In related news, there was some collaborative dialogue with Google’s WebID technology, which aims to explore how browsers can help solve the user privacy problem of cross-site cookie tracking on the web. Given that the IIW community is deeply focused on issues of security and user privacy, it made a lot of sense for those working on WebID to connect with people working on OpenID Connect, as well as the W3C community working on the Credential Handler API (CHAPI). The team developing Chromium discussed the possibility of adding a minimal set of browser APIs to work with CHAPI. Having something like CHAPI supported directly by the browser would allow for a more friendly user experience, allowing a credential holder to choose the provider of their identity (instead of being dictated by the relying party) and enabling better credential storage synchronization. The discussion here is really just a starting point, and we’re looking forward to seeing how WebID incorporates this approach and continues to work with the IIW community as the work develops.

SSI maturing into multi-dimensional & relationship-oriented identity

It’s been nearly 15 years since Kim Cameron wrote the 7 Laws of Identity, and over 4 years since Christopher Allen first laid out the 10 Principles of SSI. In the time since then, thinking has evolved a great deal around how to bring the power of SSI to users. This work has not only included building out the foundational technologies, but also addressing the practical tradeoffs between convenience, usability, and privacy.

As these technologies get deployed in the real world, what’s emerging is the fact that what we call ‘SSI’ (Self-Sovereign Identity) is more a set of guiding principles in how we would like digital identity systems of the future to behave like or be based around, rather than a concrete checklist where you can say this technology is SSI. As it is, there are always new ideas about how to bring these principles to life in real world applications. This continued to be a hot topic at this IIW, including:

  • Scaling peer communications
  • Scaling blockchains 
  • Scaling privacy 

Scaling peer communications

Besides all of the ongoing work on KERI, there were a number of updates surrounding technology enabling peer-to-peer communication. There were a few sessions dedicated to giving the community an update on the DIDComm protocol, showing that the specification is maturing to a point where it will be stable enough to broadly implement. In addition, Daniel Hardman of Evernym presented a thought provoking session on the intersection of privacy and discoverability on the web, which he calls “The Kobayashi Maru Problem of SSI”.

Scaling blockchains

The team at Consensys presented an interesting proposal for a new DID method based on ZK Rollups. In recent years, there has been a big push in the community to reconsider the use of ledgers and minimize what information is made public, especially when it comes to identifying individual people. While there has been a lot of interest in DID methods that don’t use any blockchain or ledger infrastructure, Consensys and many others continue to explore the use of ledgers due to their unique properties, such as the ability to offer global resolvability. Although it’s early stages for this work and there is no codebase yet, there was a lot of interest from those in the community looking to use blockchain-based DID methods. Their approach would give DIDs global resolvability with the potential to keep the DID “off ledger” and privacy preserving, making it ideal for persons using DIDs. As mentioned earlier, the work on KERI is also helping to illustrate how we can continue using decentralized ledger technologies in a way that preserves user sovereignty and data portability.

Scaling privacy

As a followup to last IIW, we provided an introduction to multi-message signatures and an overview of recent developments made around using BBS+ Signatures for selective disclosure in JSON-LD Verifiable Credentials. We first introduced this technology at IIW30 in April of this year. Since then, steady progress on open-source implementations and technical specs have resulted in a number of additional enhancements to the privacy preserving characteristics of zero knowledge proof based credentials, including the ability to have blinded subject credentials and domain bound proofs. In addition to progress on the technical specification, there have been significant developments on open-source implementations from a number of independent organizations. This progress has made the case for privacy-preserving credentials and selective disclosure stronger than ever.

Recording of our IIW31 session on JSON-LD BBS+ Signatures

Summary

SSI and decentralized digital identity are maturing at a steady pace, but we still have a lot of work ahead to solve the difficult problems around trust, privacy, and scalability that come with deploying systems in the real world. We’re excited to see progress on the critical issues move forward as the work happens across so many different communities and areas of interest.

As always, we’re incredibly grateful for the work that Kaliya Young, Phil Windley, and the team at IIW are doing to bring together different perspectives and to host important discussions which are open, respectful, and always illuminating. As for MATTR, you can usually find us on GitHub and working within organizations like the W3C, DIF, OIDF, and Hyperledger to push forward the vision for a more open and accessible internet. We will see you all at IIW32!

You may also be interested in.