Is there a comparison document available somewhere comparing Veridian to Identus?

[abailly]

Identus is an SSI solution, based on W3C DIDs and previously developed at IOG under the name Atala Prism, and currently hosted under the Hyperledger umbrella.

How does it compare with Veridian? How does KERI compares to DIDs? I would assume some analysis comparing various existing SSI solutions is available somewhere, could someone point me at it?

[iFergal]

There are various articles out there that compare KERI to DIDs, such as here and here. I don't believe there are any that specifically compare Identus and KERI, so I'll provide my thoughts here.

At Veridian, we use the KERI suite which is composed of the KERI, ACDC and CESR specs. Identus is based on did:prism.

Background context on Veridian

Before Prism was open sourced, we originally started out in the DID space by writing our own DID spec, but we quickly dropped this to avoid adding “one more DID method” to the growing list. Overall, it was more of a learning exercise during a time where Prism was closed source with little information available. Once Prism was open sourced, we joined the Pioneers program to evaluate it.

In parallel, we were particularly interested in KERI because of its powerful feature set. When we started the wallet, we supported both Hyperledger Aries (DID/VC framework) and KERI in our wallet but eventually realized that both didn't make sense (see interoperability below) and KERI was the best fitted option for building highly secure systems and supporting organizational identity.

Before I delve into the differences, I want to point out that many aspects of KERI come from lessons learned from the DID space. There are a number of key advantages to KERI which we advocate for, but there have been years of great work in the DID space to build on.

Some of my knowledge on Identus/Prism might also be dated, so happy to be corrected.

Interoperability - the larger issue with DIDs

The W3C DID method specification was created to provide a specified way for decentralized identifiers from one ecosystem to interact with another. For example, a wallet could support Cardano backed DIDs and Ethereum backed DIDs as tools could speak a common language to verify signatures related to DIDs.

One practical issue with this is an application would need to run a Cardano node and an Ethereum node in order to securely verify the signatures of each DID method. So for every (secure) DID method, you need to maintain more infrastructure and you need to understand that infrastructure. Crypto exchanges do this to an extent but for good (directly financial) reason, and single exchanges don’t support every chain.

There are something like 200 different DID methods out there, so it’s virtually impossible to build systems that can be interoperable with all DID methods while maintaining any security. In practice, many wallets only end up supporting the DID method of their ecosystem and did:peer; which is the opposite of interoperability. And there’s too much choice with little enforcement on decentralization and security - many, including Microsoft are reverting to the insecure did:web: “Register your decentralized ID for did:web”. Every time we attend the Internet Identity Workshop, another DID method is announced.

The DID space has a universal resolver, which is designed to be a service that you plug your nodes (or whatever) into to supply the key state and provide this abstraction, but now every other service external to the resolver must trust it to provide accurate data, which is entirely problematic. Even if you run one within your infrastructure, it goes back to traditional perimeter security and against zero trust networking, and in general is very costly. Keeping your infrastructure up to date with many on-going hard-forks isn’t easy - it’s already challenging enough to get traditional companies to support a single blockchain.

KERI intends to be one decentralized key management infrastructure that spans the internet, and can be used in any use case - a single backbone. You should be able to use your decentralized identity in any context, with the assurance that everything is secure. Just like the internet has adopted TCP or TLS across the board. It also has a property called ambient verifiability which means even edge devices can always securely verify the key state of an identifier at any time, rather than relying on a resolver - which is possible because of how lightweight it can be. In some way, KERI can be thought of as taking the web of trust from PGP and solving the key rotation problem so your identity can stay with you for life.

Specific differences between KERI and did:prism

Serialization

CESR is an encoding mechanism in the KERI suite that is very efficient and scalable for cryptographically intense protocols. It has a text domain for the developer friendliness of JSON and a binary domain for efficient over the wire transfers. Things like hashes and public keys are first class citizens with clear crypto agility.

It has a number of advantages (efficiency, security) over JSON/JSON-LD that is used in the DID space. For more info, I would suggest this video. It also touches on the chaining of ACDCs vs W3C VCs.

CESR adds to the up front development work needed, but increases long term adoptability.

Identifiers

KERI does everything possible to provide world-class security for identifiers that can last a lifetime. It takes the view that in certain scenarios, key compromise or key loss is inevitable, so there is a strong focus on detecting key compromise and providing recoverability. It also considers that scalability is necessary or no one will adopt decentralized identity into real world use cases.

Some high level features of KERI:

• Uses CESR everywhere.
• Identifiers can be a fractionally weighted threshold multi-sig. (enables groups/entities, social recovery, multi-device recovery etc)
• Has a "pre-rotation" mechanism. (separates signing keys from rotation keys for recoverability [or custodial recovery etc], and rotation keys are hashed for post-quantum resistance)
• Delegated identifiers (delegate to someone else) can enable top-down hierarchical recovery. (a key rotation from one identifier can be set up to require a signed approval from another identifier - this is used in the GLEIF ecosystem)
• Delegated identifiers (delegate to yourself) can be used for scalability - avoids Key Event Log bloat, allows you to horizontally scale signing infrastructure, and also allows you to have keys in different places linked to the same identifier.
• Signing activities can (and should) be “anchored” in your Key Event Log so that old signatures can remain valid after rotation.
  • There are also recovery mechanisms to attest that certain signatures were made by an attacker etc. (“Superseded recovery”)
• Because of KERI’s watcher network, you can become aware of a key compromise on your identifiers almost immediately, and recover. In most security systems, an attacker goes unnoticed for a very long time and can escalate their attack.

These features are important because we need to move towards a verifiable internet where everything is signed, which is really why scalability is a big concern.

I can’t comment on did:prism right now, but when we originally considered it there was:

• No multi-sig
• No recovery if your keys were compromised
• No detectability that your keys were compromised
• No delegation
• If you rotated keys, all old signatures were invalidated (e.g. all issued credentials)

I raised some of these issues at the time. Perhaps it’s evolved since then though.

Note: There are some “KERI Lite” DID methods out there which borrow elements of KERI but not everything. In general, they lack the watcher network so are subject to an attack called the malicious controller attack.

Credentials

KERI uses the ACDC standard for credentials. Some key advantages over W3C VCs:

• Schemas are securely referenced by their hash/digest. (W3C use URLs to web hosted schemas)
• It can be used for credentials (targeted), but also just to sign something that isn’t a credential (untargeted) - like a report or document - “to whom it may concern”.
• ACDCs can be chained together (based on sub-schemas) to form powerful relationships between data.
  • It can form a property graph.
  • You can have edges such as “the holder of this credential must be the issuer of this chained ACDC”
  • It supports things like boolean logic - AND, OR, NOR, etc.
  • Edges can have weights (which have semantic meaning within an ecosystem).
• Due to usage of CESR + hashes for everything, elements of the property graph can be cached.

In general, the chaining allows you to provide cryptographic provenance, chains-of-custody, delegated authority etc. Credentials can be linked to documents, etc etc. This doesn’t exist in W3C VCs.

This chaining is also what really enables organizational identity (more-so than multi-sig) - check out this article. The GLEIF verifiable LEI (legal entity identifier) is built on KERI/ACDC and is now an ISO standard - ISO 17442-3.

So what does this mean?

Overall, it means did:prism is suitable for basic issuer <-> holder <-> verifier (trust triangle) use cases, with simple credentials like a certification for completing an academic course, where a single key pair is sufficient for security. And unless things have changed, if the issuer needs to rotate keys, you would need to re-issue every credential, which might be acceptable in some cases and not in others.

It becomes more challenging when you consider that organizations (like universities) are made up of many representatives and departments; and when you consider that cybercrime is only on the rise and more advanced security features are necessary.

It also isn’t as well equipped for making environments with a large amount of data or IoT verifiable because it’s harder to provenance data, and sign at scale.

If we also want to break the trust domain silos across industries/companies/etc, having a single adoptable identifier system is necessary. So it’s less of a KERI vs DIDs and more of a KERI vs a specific DID method - unless we think every system will run and maintain nodes for an ever-growing list of different DID methods.

Challenges with KERI

KERI is low-level, and hard. There are certain security considerations which for Identus are solved by Cardano itself. There are also certain nuances that take time to get to grips with or become aware of, and we’re dealing with more advanced topics. (coordinating multi-sig + out of order messaging, chaining of ACDCs etc)

The implementations and state of documentation have certain maturity issues, which is something we’re trying to help with. Things may move slower implementation wise in KERI because everything is barebones, from the ground up, with a small community.

[abailly]

Thanks a lot for the detailed reply, @iFergal

[abailly]

I think this could be useful documentation to have in veridian.id