What we learned at the Internet Identity Workshop

This post was authored by Alexis Falquier, who helps lead the self-sovereign identity (SSI) initiative at GlobaliD.

Back in October, team GlobaliD attended the 31st biannual Internet Identity Workshop (IIW), the premier conference dedicated to building collaborative environments that foster the development of open standards around all things digital identity. According to legend, it’s the birthplace of SSI

On top of leading two sessions, we also unveiled our Dynamic Governance API. And as part of GlobaliD’s ongoing commitment toward open SSI standards, we open sourced our iOS and Android native Hyperledger Aries frameworks.

With the year coming to a close, we wanted to look back at the conference and highlight some of the fascinating topics we came across and what we learned.

Disclaimer: This piece is a bit jargon heavy given the nature of the space. I’ve made my best attempt at making it as approachable as possible, but if you’re looking for a crash course on the basics of SSI, distributed identifiers (DID’s) and Verifiable Credentials, here’s some recommended reading:

• What is self-sovereign identity?
• Multi-Source and Self-Sovereign Identity
• The Architecture of Identity Systems

OK, without further adieu, here are some highlights from IIW:

Now KERI is my best friend

One of the hottest topics at IIW 31 — in part because of how much it offers — was our new friend KERI, which stands for Key Event Receipt Infrastructure. It’s no trivial subject, to the point that Drummond Reed and Sam Smith (the creator of KERI) held three separate sessions dedicated to describing it at different levels — KERI for Muggles, KERI for mudbloods, and KERI for Wizards. I can tell you that even KERI for Muggles very much felt like a “Wizards” session but I will do my best to share what KERI is all about.

In its most fundamental sense, KERI is a Public Key Infrastructure or PKI. One of the foundational pieces of SSI is public/private key cryptography and its relationship with a decentralized identifier or DID. In other words, public key encryption makes SSI go round. KERI, then, is a new and fully decentralized PKI. You can see why all of this might be such a big deal.

Some of real-world benefits of KERI — and why it was incidentally the belle of the ball — as explained by Timothy Ruff, Sam Smith, and Drummond Reed during their muggle-friendly and all around more approachable KERI session at IIW:

Independent and Portable

Distributed ledgers underpin many SSI solutions, but KERI is a highly portable public key infrastructure that does not necessitate their use. It is self sustained, and therefore every organization/individual is its own root of trust. It is not locked into one governance framework, network or ledger. It is truly decentralized.

Secure

KERI relies solely on cryptography as the means to prove the root of trust. What this means is that you can rotate the key without changing the identifier. You can pre-rotate future keys, safely store these, and — in the case that your current private key is compromised — you can use the pre-rotated keys to restore your identifier. To throw some more jargon at you, this pre rotation turns out is actually a post-quantum proof (secure against attacks with quantum computers) method of key security. In other words, it is future proof.

Delegatable

You can easily create keys and delegate them as needed. This creates the potential for any number of hierarchical architectures.

Scalable

Since KERI is self reliant it is extremely scalable, only limited by its hardware. Given its cryptographic nature, existing key management solutions can be used.

Private

The key logs are controlled by the organization/individual themselves. In some SSI solutions that rely on immutable ledgers privacy can become problematic in terms of GDPR, and the right to be forgotten. Since KERI is not reliant on ledgers this can be avoided all together.

Standard Adherent

Like many SSI solutions, KERI uses existing cryptography in new ways including W3C standards, DID’s and SSI Wallets. KERI follows open source standards and is fully auditable.

Sound good so far? If you’ve made it this far, here’s how KERI actually works at a very high level:

• KERI uses self certifying identifiers (SCID’s), which means that a specific identifier can prove to be the one and only identifier using cryptography alone. This is the pivotal piece of KERI.
• KERI uses key event logs (also self certifying) which carry the history of the keys, such that if you ever need to rotate your key you can do so, sign it, log it, and prove that you control this new key via the event logs.
• KERI uses “witnesses” that keep and sign a copy of your logs for added ‘evidence’ of your key ownership.
• You can pre-rotate future keys, safely store the keys, log the pre-rotation, and when this key is needed you will be able to prove the key is yours and keep your identifier safe.
• KERI is not attached to any one system, any system that can process data will be able to validate your identifier.
• KERI allows for the creation of multiple identifiers that can be delegated, allowing for any complex hierarchy of identifiers and keys.

If you feel like you still do not really get it, don’t worry, most of us didn’t either. One thing that isn’t hard to get is why KERI made such a big splash at the conference. These are still early days but the possibilities for KERI are vast and disruptive — it’s certainly one to keep an eye on.

If you’re feeling brave and are interested in learning more about the nitty gritty of KERI, here’s the 140-page white paper.

Chained Credentials

Another compelling topic at IIW was chained credentials — the concept of linking two or more verifiable credentials with one another. The discussion focused less on the how but rather on the why.

At its most basic function, linking credentials makes sense in the same way that databases have relationships that link data from one table to another. You might have two credentials that work just fine on their own for a specific purpose, but attributing them together can provide broader significance.

A basic example of this would be having a credential of citizenship and a credential of residence — the link of which allows you to vote in local elections. Really, anytime you have a history of transactions such as supply chain, registries, etc., verifiable credentials add value. So rather than present use cases, I will focus on a few primary benefits.

Reputation

For Kiva’s Nathan George, their work with refugees led them toward the path of chained credentials. Since refugees often lack traditional forms of documentation and credentials, the concept of chained credentials opens up the possibility of building their reputation by allowing them to receive credentials that attest to their skills — whether by linking one with the next or by adding endorsements.

Proof of Linkage

Linked credentials would allow for proof of a larger scope of information without disclosure. If part of my verifiable credential is how it is linked to another, then I could disclose to a verifier the proof of linkage without disclosing the credential itself, thus demonstrating the reputability of my credential without actually disclosing it. If this proof of linkage also shows where the credential was linked from, I am able to show the provenance of truth. In other words, the source of the link can add to the validity of my credential.

Delegatable Credentials

Chained credentials are a core building block of delegatable credentials. In simple terms, a delegatable credential is one that proves the permission of an action by means of proving a link to the original credential that allows for that action. For example, if I lend my friend my car, I will delegate my car’s credential to them, in the case that they need to prove that they are allowed to drive it (or in the future, be able to start and drive it, period). For delegatable credentials to work, revocation is also needed — a topic for another day. The point being, linked credentials are a key part of the delegation process.

All in all, there are use cases abound — one reason why I’m so excited to see where people take the concept.

Guardianship (AKA Custodial Agents)

The topic of guardianship made an appearance in multiple sessions. For the purposes of this piece, I’ll focus on the one held by Ken Ebert and Sam Curren.

At first glance, you might think that this is about the legal role of guardianship when it comes to a person’s online identity, i.e. a parent being a guardian for a child’s digital presence until they turn 18. While that is an ever present topic at IIW and one that is always interesting to be part of, this discussion focused on guardianship in a technical sense.

This potential for confusion came up during the discussion and we ended up changing the phrase to custodial agents for semantic clarity.

A custodial agent is an agent that resides on a cloud infrastructure rather than on someone’s personal device. Therefore, their identity and wallet is being maintained by someone else. This is worth considering because in reality, there are people who cannot have an end agent, generally for the purposes of convenience and access. That might mean a web wallet interface for easy integration and adoption or simply because not everyone has a smartphone.

Since the agent is not on a personal device, this means that the keys are being managed by whoever manages the cloud infrastructure. Naturally, this adds a degree of centralization. (Someone on the discussion made the joke that here, SSI stands for Somewhat Sovereign Identity.) That’s true — to an extent. On the other hand, it’s important to solve for cases where the ideal scenario might not exist in the name of inclusivity.

The thing is, even though cloud hosted wallets inherently takes away some portability, we should focus on the potential benefits cloud-hosted wallets provide users over not having an SSI wallet at all. End users (for the most part) do not care what is happening in the background. They simply care how it affects their experience.

So while not not all the benefits of SSI come with cloud hosting, there’s enough upside that it would still make a significant impact.

This also puts the onus on cloud-hosted providers to maintain sovereignty of their users’ identity to the largest extent possible. Given that they inherently hold some fiduciary responsibility, we discussed ways in which cloud-hosted against could be architected that optimized for user sovereignty.

One of the first ideas brought up was the imposition of restrictions on what agents can do. Cloud-hosted providers should focus on and adhere to specific use cases. Furthermore — as to allow a user to move to a truly self-sovereign solution — the agent and the wallet should be de-coupled such that the user always has the option to retrieve their wallet and transfer it to an end agent. GlobaliD’s Dev Bharel also brought up the concept of “trusted execution environments” as a means to host an agent and wallet without requiring the ability to see any information transaction — including keys.

There’s still plenty of considerations to consider in the context of custodial agents, but many organizations along with GlobaliD are actively exploring options that promote inclusivity in the space.

Signing out

These are but a few of the notable highlights, but if you’re interested in reading more about any of these or any other session at this past IIW, the book of proceedings (which contains notes on each session) can be found here.

It’s truly difficult to put into words the level of knowledge and ideas shared at each and every IIW, a conference that breeds innovation every time you attend. For us it’s a privilege and an opportunity to see how the world of online identity is evolving. So here’s to the next IIW, where we will eagerly see what is discussed and find what’s already been implemented — while also sharing some of our own progress along the way.

Also, stay tuned for another follow up piece on the GlobaliD approach to Governance Frameworks.

The digital identity revolution is well underway, and here at GlobaliD, we’re proud to be apart of it.