How the DID, VC and VP concepts can be used to achieve lightweight, scalable interoperability between different distributed ledger networks
Introduction
Given the growing number and adoption of distributed ledger solutions and the assumption that the future digital infrastructure will be based on a variety of networks rather than one single blockchain, the importance of interoperability between different distributed ledger networks becomes evident. However, inter-ledger interoperability is still in its infancy and focuses on the transfer of tokens or more generalized assets. It quickly hits limits when it gets to the exchange of identities and data related to individual business processes or logic. For example, using the account and identity of a consumer or a business verified in blockchain network A to interact and sign business transactions in blockchain network B, is not possible using today’s inter-ledger approaches.
In the following, a pragmatic approach how to handle interoperability of identities and claims based on W3C Decentralized Identifiers (DIDs) and the related Verifiable Credential concept is introduced. By adding a thin abstraction layer on the application level, business applications using distributed ledger networks that support DIDs can easily be enhanced for supporting multiple DID methods related to different networks.
Solution Description
Note: the following description requires basic knowledge of the concepts of Decentralized Identifiers (DID) and Verifiable Credentials (VC) / Verifiable Presentations (VP). For a brief introduction see the W3C Primer. In the context of the suggested approach, we only consider public DIDs, contrary to private (“pairwise”) DIDs which are only used and shared as part of direct communication between two parties.
DID Resolution
Public DIDs can be resolved to a DID document that gives information about the validity, public keys or other means of authentication, and additional attributes of the respective identity. Each DID method must specify how DIDs can be resolved in a deterministic, immutable manner. Usually, providing a reference implementation of a DID resolver and adding it to the universal resolver initiative for universal resolving is part of the DID method specification. The DID resolution step gives a standardized way to verify and authenticate an identity, and systems or applications that identify users based on DIDs can support any DID method by adding a respective resolver of this DID method into their code or dispatch to the universal resolver.
Verifiable Credentials and Presentations
For the exchange of more specific claims, proofs and signatures related to a DID, Verifiable Credentials are issued and signed by a trusted party (also identified by the issuer DID) to a particular subject DID. The subject DID can then present one or more VCs to a verifier using a Verifiable Presentation, which basically adds the subject’s signature to the presented claims as a means of authentication.
Although VCs and VPs are supposed to be a standard, there are different implementation options and technical representations, which causes some challenges to interoperability in real-world applications. The most commonly used representations are the JSON(-LD) format described and used in examples in the W3C documents, but in practice the JWT (JSON Web Token) mapping is also widely used. By supporting those two alternatives, most current DID and related VC/VP implementations can be handled.
Multi DID Method Handler Architecture
Based on the previously described elements, we can define an architecture pattern adding a thin layer for the orchestration of DID, VC and VP related operations supporting different DID methods and related configuration properties.
The following diagram shows the suggested architecture in more detail.
The business logic of an application interacts with the DID orchestration layer through an interface that is purely based on general DID and VC/VP elements. The interface is implemented by a single orchestrator that handles the orchestration and dispatching of operations based on the DID method of the involved DIDs. The operations related to a particular DID method are dispatched to a specific handler that is registered for this DID method. Handlers all implement the same operations and can be realized or looked up using a plugin mechanism to allow extensibility for new DID methods. Only the handler for a particular DID method connects to the underlying blockchain or DLT network of this DID method if necessary. The configuration of the component can contain the information about supported DID methods or handlers, the own DID and account information for write operations, as well as node endpoints or other blockchain related properties.
Operations provided by the interface could include:
- Resolve DID document for DID
- Validate signature for DID and message
- Validate VC issued by DID
- Validate VP signed by DID
- Update DID document for own DID
- Sign message with own DID
- Issue new VC with own DID as issuer
- Issue new VP for list of VCs with own DID as signer
The interface could be distinguished in a read-only part allowing resolution and validation only, and a write part requiring to have direct or indirect (via custodian mechanisms) access to an account private key in order to generate signatures or authenticate. Applications that only perform validation could be restricted to the read-only part with a simplified configuration.
The interface must be defined in a way to be able to treat VCs and VPs both as JSON or strings (JWT), which may cause some challenges for the implementation, but should be possible in most object oriented and type-safe programming languages.
Example
To make it more comprehensible how an implementation of this approach would look like in practice, let’s have a look at the typical VC and VP example scenario of a university degree credential issued by the university to a student and verified by an employer e.g. as part of a recruitment process.
It is assumed that the student uses application 1 (which could be a general self-sovereign identity app) and has registered DID a with DID method A, which is related to blockchain network A and uses JWT as the format for VCs and VPs. The university uses application 2 that implements the described DID, VC & VP abstraction component. The university has registered DID b with DID method B related to DLT network B using JSON as the format for VCs and VPs, which is configured as the own account. The employer uses application 3 also implementing the DID, VC & VP abstraction, however only in a read-only manner without the need for an own DID.
The flow could then look like the following:
- The student (application 1) requests a Verifiable Credential from the university (application 2) by providing a proof of the physical identity and a signature by DID a.
Note: for the sake of comprehensibility, in this example the university (application 2) checks the physical identity of the student itself. In more realistic scenarios, the student could have already run through an identification by a third party identity provider that mapped the student’s DID to relevant properties of the physical identity, and only present a reference to the id provider or respective Verifiable Credentials issued by the id provider. - Using the abstraction component, the business logic in application 2 can validate DID a and its signature, dispatching the validation to the handler for DID method A.
- The business logic of application 2 checks the physical identity of the student, see note in step 1.
- After successful verification, application 2 issues a Verifiable Credential using its own DID b as the issuer and DID a as the subject via the handler for DID method B.
- Application 2 returns the VC issued in step 4 to the student (application 1).
- The student (application 1) prepares a Verifiable Presentation containing the VC from the previous step, signed by DID a and using the JWT format according to DID method A. It sends the VP to the employer (application 3).
- Using the abstraction component, the business logic in application 3 can validate both DIDs and signatures of DID a (7a) and DID b (7b) with the respective handlers. If all is valid in terms of that the DIDs exist, the signatures are correct and there is no expiration or revocation of the credentials, the abstraction component returns the validated VC information.
- The business logic of application 3 can now further validate the VC content from a functional perspective. The validation should include a check whether the issuer DID of the VC is trusted.
Evaluation
With the suggested approach, an application can easily be extended to support multiple DID methods based on a common, reusable pattern. As an additional benefit, business logic is kept independent of particular DID methods or DID, VC and VP processing.
Assuming that the DID, VC and VP concept establishes as the standard for decentralized, self-sovereign identity, it is likely that DIDs from different systems or networks will interact. Since the main usage scenarios for DIDs and VCs are user authentication (“single sign-on”) and verification (KYC — Know Your Customer and digital signatures), providers implementing those kinds of authentication and verification methods will want to support consumers from as many ecosystems and related DID methods as possible. The suggested approach is a suitable, rather light-weight solution for achieving such an interoperability on a DID level which should be flexible enough to be integrated into any existing application or environment. This differs from other solution approaches to DID interoperability like DIDComm or Hyperledger Aries, which require to adjust the software architecture and workflows towards an agent-based model and may not be suited for every case or come with high costs.
A drawback of the approach is a certain initial effort for implementing handlers to support new DID methods. This could be eased by moving the abstraction to a reusable component like a library or SDK, or even a separate micro-service, that can be shared by many applications. The general complexity due to dependencies to multiple networks and related configuration effort cannot be avoided, but should be mitigated in the implementation by sound error and exception handling. Also, the approach suffers from the current gaps and room for interpretations in the DID, VC and VP specification. In practice, this leads to DID methods that do not fully comply to the specification or implement different, incompatible extensions or variants. It is expected, though, that with increasing adoption the specification will become more robust and implementations will align in the future.
Summary and Outlook
This article described an architectural approach to realize interoperability between DIDs of different networks that can be well integrated into most existing application architectures.
A similar approach has been successfully prototyped and shown as a demo in a mobility use case allowing interoperability between the Evan network (Ethereum based business blockchain network) and the Ontology blockchain as part of the 8th Startup Autobahn program. You can watch the recording of the breakout session during the virtual expo to get more details. Gratitude and acknowledgements go to the project partners that gave valuable input and made the solution possible, in particular Dr. Harry Behrens of the Daimler Mobility Blockchain Factory and the team of Ontology.
Future work on this topic may include the adaptation in real business applications to understand the needs and adjust the approach based on learnings from more usage scenarios, providing open source reference implementations or libraries in different programming languages, as well as the implementation and test of handlers for the most widely used DID methods.
51nodes GmbH based in Stuttgart is a provider of crypto economy solutions.
51nodes supports companies and other organizations in realizing their Blockchain projects. 51nodes offers technical consulting and implementation with a focus on smart contracts, decentralized apps (DApps), integration of blockchain with industry applications, and tokenization of assets.