Revolutionary Identity Tech, Evolved

Reflections on recent trends in modern identity technologies: drivers, direction, and why you should be excited.

Decentralized Identifiers

DIDs introduced a new paradigm, combining URIs and PPK principles in a decoupled manner (the DID Document). This has unlocked a whole new class of applications and a scalable architecture not dependent on a mono(po)lithic hub linking the spokes or IDPs with interests different from our own.

The idea of carrying your own private keys and the wallet concept was born out of the bitcoin era, and it was naturally assumed that identity-related public keys should also be rooted among the DLTs and blockchains which were happily proliferating in those days. Thus, the flexibility of supporting whatever blockchain is a fundamental requirement (/constraint) solved for by the DID design. This has several suboptimal consequences:

• (Too) many DID Methods, and we are all just waiting for most of them to go away (more on that in a moment)
• The did: prefix depends on a new component, the DID Resolver which knows how to resolve some set of DIDs.

Meanwhile, one particular DID Method is looking to gain momentum: did:web. Interestingly, one of the few DID Methods that isn’t blockchain-based. So, why is did:web winning? In short: the web is a well-understood, mature infrastructure. Comparatively, blockchains are expensive, and their benefits fall short of the requirements of enterprises.

So, the main challenges of DIDs result from unnecessary requirements — that’s a great opportunity to improve and simplify! If we only need to access public keys on the web, then let’s just access the DID Document with a good’ol URL!

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v2"
  ]
  "id": "did:example:123456789abcdefghi",
  ...
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": ...,
    "controller": ...,
    "publicKeyJwk": ...
  }...],
  "authentication": [
    "did:example:123456789abcdefghi#keys-1"
  ],
  "assertionMethod": [
    "did:example:123456789abcdefghi#keys-2"
  ] 
}

Above is an example of one of these Controller Documents. Those who know DIDs will find this very familiar and comforting! What has gone from the draft spec includes Method Operations, DID-to-DID Document relationships and other such abstractions.

Verifiable Credentials

VCs — the other side of SSI revolution — bind the above mentioned public key to a chunk of data at the application layer. This means you can trust the data on its own, no matter where it is kept or how it was acquired. Game changing stuff!

The spec allows for two flavors of VCs: Data Integrity Proofs (DIP) and JWTs. Admittedly, I used to have reservations about this part of the spec. I lumped JWTs together with access tokens in the domain of security folks, and I consider myself more functional, business-oriented. But, not unlike the DID situation, it turns out there are good arguments for not re-inventing a solution to a solved issue:

• First, JWTs are prevalent, there are orders of magnitude more JWT libraries than DIP libraries out there.
• Second, signing DIP requires expanding the entire data graph; this is a non-trivial (probably why so few have done it) and expensive operation. Especially as you move into larger credentials (such as trade documents), signing and verifying takes noticeably long. JWTs sign the “raw” JSON and therefore perform much better. In the future I am working towards, those clock cycles saved makes a real difference, energy consumption-wise.
• Third, they are more secure: signing the encoding is an encouragement to dismiss the whole VC if it doesn’t verify — which is the intention of VCs (you never know which elements are bad, so you must dismiss the whole thing). JWT’s encoding protects non-security experts from bad data.
• Fourth, when the proof relies on an external LD context (which it doesn’t have to, but in practice always does), your VC’s proof can suddenly break if the someone fiddled with the context. This literally happened to me in a customer meeting yesterday!

So, there are good reasons why the community seems to be heading in this direction.

As a sort of fifth argument, there is (finally!) a standard for Selective Disclosure, SD-JWT, which seems to be settling. SD is a potential silver bullet in many supply chain use cases, establishing traceability across credentials which cannot be shared in full. Unfortunately, SD has remained “potential” for as long as I remember, so rooting on SD-JWT to gain gravity and adoption — which would be another argument for JWT VCs.

These examples and our open source SD-JWT implementation are great sources to demystify the seemingly magical powers of selective disclosure.

Linked Data

Movement away from Linked Data Proofs does not mean movement away from Linked Data in general. Linked Data is awesome — particularly in the global supply chain environment. But it’s awesome for business semantics reasons, not for the sake of digital signatures.

“If you want to sign VCs, then you MUST use Linked Data” is not the right incentive model.

These are distinct benefits at separate layers: “you should sign your data so others can trust it” and “you should use Linked Data so others can understand it”. You should absolutely put LD inside of your business JWT VCs!

Look — it’s all familiar JSON-LD inside that SD-JWT!

Evolution of the Revolution

It is fascinating to watch how these tech trends unfold, and exciting which iteration ends up gaining gravity. Remember that this is all in flux (and that I am observing from the sideline). The only thing I can say with a bit of certainty is that this won’t be the end of it: technologies will forever evolve.

None of this changes the ongoing movement towards trusted data, a scalable architecture, commodity pricing, and identifier control — these are exciting times we live in. It’s just getting easier and better, as we learn and iterate along the way. So keep calm and fight the good fight!

Nis Jespersen, Transmute’s Solutions Architect, is editor of the United Nations CEFACT JSON-LD Web Vocabulary project and author of the W3C Traceability Vocabulary specification.

Connect with Nis on LinkedIn, Twitter, & GitHub

Sign up for free on Transmute’s Verifiable Data Platform on https://platform.transmute.industries.