EBSI DID v2: A test to SSI usability and its use of blockchain technology

July 20th, 2022

What’s all the recent activity with DIDs?

In the past months, there have been numerous debates and decisions being made regarding Decentralized Identifier (DID) specifications worldwide:

While the first decision means great news for the SSI community given that DIDs are its core concept to enable true decentralization, the second has generated controversy. In this blog, we’ll dive into the EBSI DID versions 1 and 2, its potential implications including advantages and disadvantages.

EBSI DID version 1 vs version 2

So far, SSI technology has been widely tied to the use of blockchain technology, but in reality, blockchain is replaceable in the SSI sector.

In SSI, DLTs are -in the vast majority of frameworks- only used for the storage and localization of trusted registries – never, ever for the storage of sensitive personal information (e.g. Verifiable Credentials) or transaction processes.

Regarding natural persons, the only blockchain registry linked to them is the DID registry; that is, a database of all existing DIDs and their associated DID documents (which include public keys associated to such DID).

This connection between DIDs, DID documents, and DLTs has been standard in the SSI industry globally -including in EBSI DID v1- as it kept decentralized values at its core.

However, European regulators deemed DIDs personal information and the storage of DID documents in the blockchain non GDPR-friendly for natural persons. In response, the EBSI group has proposed EBSI DID v2 (see below), which eliminates the use of blockchain to register DID documents of natural persons, and therefore removes the link between a natural persons' DID and DLTs. In this new DID method, the public key can be derived from the DID itself, so that no registry of public keys is necessary.

ebsi did v2 blog

Original DID methods include a scheme, a DID method, and a DID method-specific identifier. In v1, the Identifier section is comprised of a random set of numbers (think of it as a holder’s URL). In v2, the identifier now includes a JWK thumbprint with the holder’s Public Key.

This change has an impact on how verification flows should be implemented. The flow of information in standard SSI frameworks - and hence in EBSI DID v1- are as follows:

Scenario DID v1

  1. Issuer records its DID document in EBSI Ledger & issues VC to Holder
  2. Holder shares VC + proof (containing DID and signature to prove ownership) with Verifier
  3. Verifier verifies Holder identity by taking DID and retrieving DID document from the DID registry in the EBSI Ledger, which contains the public keys used to verify the signature.

What does the flow look like now? Since the DID Document cannot be retrieved from EBSI, the Holder needs to send it along with shared VCs, as follows:

Scenario DID v2

  1. Issuer still records its DID Document in EBSI Ledger & issues VC to Holder
  2. Holder shares VC + DID + DID document with Verifier, with no ties to the EBSI Ledger
  3. Verifier verifies Holder identity by verifying DID, which now is linked to the Holder’s public key, without referring to the EBSI Ledger

ebsididv2 flow

Please note that there are no changes or impact on legal entities' DID process, only natural persons. DID documents for legal entities are still recorded in the EBSI ledger, and follow the DID method v1.

The EBSI DID v2 debate

Now that we’re all caught up with EBSI DID versions 1 & 2, let’s dive into the arguments and criticism for/against EBSI’s V2 approach and its impact on current and future SSI mechanisms:

Arguments in favor of v2 by their proponents

DIDs are considered personal information, and thus registering them on blockchain is against GDPR (among other reasons, because “the right to be forgotten” cannot be implemented). V2 offers a GDPR-compliant SSI solution.

Given that the majority of DLTs are public, storing anything tied to a Holder’s identity risks security and privacy
European authorities consider DIDs to be personal information as it is a holder’s representation in the digital world. Thus, they argue storing it in a public blockchain, accessible by any entity, violates holders' right to privacy.

Blockchain lasts forever, a person does not
At the end of the day, a blockchain network is supposed to be inmutable and indestructible, and naturally a person’s identity (or itself) is not. In V1, a holders' public keys, would remain forever in the blockchain regardless if the holder loses access to their key pairs, wants to abandon the service, or passes away. V2 argues that there always exists the chance that a malicious hacker can obtain access to these forget/lost/inaccessible keys and commit identity fraud. While current computing powers make this almost impossible, one never knows what computing will be like in a few years.
V2 was proposed with this in mind: holders should be able to delete their key pairs and DID from the world if they wish to.

Criticism against v2 by other parties

DIDs cannot be considered personal information
While DIDs are associated to a person, those against V2 argue DIDs themselves do not contain the actual personal information, Verifiable Credentials do, and VCs are never stored in the blockchain but in the holder’s device. A holder’s digital identity is created from a DID + VCs, but the DID acts as the glue that links the VCs issued by multiple issuers, but the DID itself truly only serves for the integrity and non-repudiation of validations.

Losing access to your cryptographic keys has major implications on user-experience.
Providers like GATACA have implemented Key Rotation mechanisms, similar to “change password” mechanisms, a functionality that is required by many industries. In this process, a new set of keys associated to a specific DID is generated, the old set revoked, and the update is registered on the blockchain DID registry, keeping a history of revoked keys. This key rotation mechanisms, only possible in v1:

  • implies little to no effort from the holders, as it can be automatically performed or executed on demand
  • provides extra security, since a set of keys can be renewed if the old ones are compromised or lost, without the need to revoke the entire DID and throw away all credentials issued to that DID.

With v2, Key Rotation is impossible given DID’s are tied to public keys, and the rotation of a key pair would imply the alteration of a DID. As V2 stands, if a holder lose access to their private key, they would have to request the re-issuance of all VCs as the DID tied to these would no longer be valid. This can be especially cumbersome as certain issuance process might involve physical presence.

V2 is a breaking change that makes interoperability with other frameworks much more difficult, potentially leading to vendor-lock in situations.

Natural persons will no longer be able configure specific use cases for public keys
DID Documents allow a DID to have multiple set of keys associated to it. This feature is useful if we want to associate different keys for different purposes or to provide compatibility with different cryptographic protocols. (E.g. to use different keys for authentication processes with Level of Assurance High or Low). With V2, only one key can be associated to the DID, thus limiting current functionality.

The future of self-sovereign identity technology

The EBSI DID method v1 & v2 represents the eternal debate of usability vs. privacy/security. While V1 ensured higher security & user experience via key revocation and other mechanisms, V2 guarantees a lifetime of privacy. How far away from usability are we willing to go to ensure privacy? Could V2 threaten mass adoption?

Furthermore, these slight changes are questioning the role blockchain has played in decentralized digital identity technology up until now, as well as the self-sovereignty of the technology itself.

Where will DID registries be stored now? The move to remove DIDs from blockchain generates some skepticism - is this the rise of semi-centralized databases? So far, v2 has not proposed another DID database or registry for verifiers to be able to consult whether a DID is active or not. Some SSI experts hypothesize that this first registry removal from blockchain can give way to the rise of centralized DID databases by certain groups such as EBSI, member states, local authorities, etc., allowing the filtering of centralized thinking into a decentralized world. While DID databases being semi-centralized by certain groups is better than federated identities (big tech owning those databases), it still tarnishes the advantages of decentralized identity technology.

Ongoing tech specification changes such as this one show how decentralized technologies have yet to find compromises with real world regulations, such as GDPR.

How important do you think blockchain is for SSI? Are there other mechanisms that preserve self-sovereignty just as well?

Let us know your thoughts on the matter - We’d love to chat with you. Let us know your perspective and comments on this topic or anything Digital Identity-related. Join our Telegram group.

Stay in the loop - Keep yourself updated on GATACA developments and how digital identities will transform our digital lives here.

Have a specific topic you’d like us to cover? Email us at hello@gataca.io - we’ll break it down for you in our upcoming blog articles.