Blockchain for Decentralized Identity — Layer 2 — Digital Wallets
Layer 2 is built on cryptographic trust and enables secured connections between digital wallets and their respective agents. The digital wallet allows for privacy and security with the entity’s consent usage of verifiable credentials and their claims. It is portable with standards still in development by the W3C. The holder’s identity is stored encrypted in the wallet app that an agent accesses.
The capabilities of the wallet include:
1. Creation and management of DIDs (decentralized identifiers)
2. Management of authentications
3. Management of keys and permissions
4. Communication with the DID resolver to lookup DIDs on blockchains
5. Approval of offer for verifiable credentials from an issuer
6. Receipt of issuer documents
7. Acceptance of attestation proof requests from verifiers
8. Creation and delivery of Zero-Knowledge Proofs
9. The entity’s use cases to close a transaction — could be that of the issuer, holder, or verifier
10. Revocation of credentials
11. Encrypted identity storage of the entity
12. Back and recovery of identity data associated with a wallet
The digital wallet communicates with other wallets using an agent. The agent has a framework and controller.
1. Sends and receives messages for the entity (person, organization, or thing)
2. Encrypts and decrypts data
3. Signs digital information
4. Handles verifiable credentials for the entity, including backups, and retrievals
5. Manages wallet information
Agents enable the entity to assume the role of an issuer, holder, or verifier within the Decentralized Identity ecosystem. The agent communicates with the blockchain using a DID resolver that reads the DID and returns the DID document. An entity can create any number of DIDs, one for each digital relationship and context managed by the agent. The DIDs are permanent and cannot be re-assigned. They have specific procedures for key registration, recovery, and expiration. The messages flow logically to complete a transaction defined by the business logic that the controller handles. The wallet is portable and interoperable; the holder can transfer their agent and wallet data to a provider of their choice. Agents from two parties can create unique, private, pairwise DIDs to communicate and transfer data that is secured cryptographically. It is akin to a messaging service without an intermediary provider of a messaging app.
Implementation of the Agent includes:
1. A Key Management Service that aids the storage of DIDs, Keys, and credentials. Its implementation includes processes that require the creation, storage, access, deletion, signature, and verification of data.
2. A Messaging interface to send messages to agents of other entities manage relationships and conversations with the other agents.
3. A Ledger interface to write to the blockchain includes the DID resolver to return the DID’s Doc. It consists of the verifiable credential handler for issuing and verifying credentials.
4. The agent has a controller that defines the business rules regarding its actions and the sequence for their execution. It sends instructions on activities to the agent’s framework.
A web interface lets the holders install a digital wallet, sign up and deploy an agent. When an agent requests another agent to connect, the framework sends the information to the controller that sends back the message to accept or deny the request. The entity using its agent with the wallet makes a cryptographically secure connection with another agent from another entity to communicate using an agent-to-agent protocol (also called DID Comm protocol). These secured connections assist the exchange of verifiable credential data. The communications are secured using cryptography, public and private keys that are encrypted and decrypted by the entities. Every connection has a unique pairwise DID and purpose. Once its purpose is no longer relevant, the entities may choose not to use the connection anymore. If an entity is compromised and the pairwise DID is made available to a malicious party, the entity cancels the DID and issues a new one. A compromised DID is useless for anyone.
Within the business process to issue a credential, the issuer’s controller tells the framework, the ledger to use, the name of the schema, and the claims within the verifiable credential while issuing one for a holder. The framework then uses its capabilities to create the schema, credential definition, and revocation registry object. Once the credential is issued, the issuer’s controller receives an identifier stored by the holder.
To revoke a credential, the issuer’s controller retrieves the identifier for the credential and sends it to the framework. The framework then posts this on the revocation registry and sends the information back to the controller.
The entity signs a transaction written to the ledger by the agent and is verified cryptographically by the ledger. The agent controls the private key involved in the transaction. The private key is essential for the holder to decrypt messages. Hence, it is necessary to remember their private key. Once lost or forgotten, all the decentralized identity data may be inaccessible. The holder’s private key can be secured online or offline, only accessible to the holder. Wallets can be client-side or server-side. Client-side or non-custodial wallets can be an app on a mobile phone, while server-side or custodial wallets can be on a cloud. The agent provides hot or cold storage backup of the wallet.
The W3C is working on a standard for Digital Wallets. In addition, the eIDAS 2.0 (electronic Identification, Authentic and trust Services) wallet functionality working group is working on a “reference wallet architecture”. (More of this in upcoming blogs).
In the next blog, I will cover Layer 3 of the stack; the Trust Triangle.
To reference previous posts refer to this link. Again, I would suggest reading the posts in succession.
A service provider could host cloud agents or provision edge agents for entities. Essentially “Agent as a Service.”
Piece of code associated with a wallet that makes secure connections with other agents and wallets to share and communicate identity information to complete a transaction. It enables an entity to take on one or more roles in an SSI model –an issuer, holder, or verifier. There are two types: edge agents that run on a mobile device or cloud agents that run on a server in the cloud.
A blockchain is a decentralized ledger, which can be public, private, or hybrid. In the context of decentralized identity, it can store a public DID, DID Document, schemas, and formal descriptions of a verifiable credential, revocation registries, and proof of data sharing — however, the blockchain stores no PII (Personal Identifiable Information).
Associated with an agent, the controller defines the business rules and sequence for execution to complete a transaction for the entity.
Software installed on a mobile device enables the storage of verifiable credentials, private keys, link secrets, and other cryptographically sensitive data. It also stores financial instruments that an entity can use to make payments. The wallet also holds payment balances in either tokens or fiat currencies.
An entity can be a person, organization, or thing.
Key Management System
Key Management Service aids the storage of DIDs, Keys, credentials in a database. Its implementation includes processes that require the creation, storage, access, deletion, signing, and verification of data.
A zero-knowledge proof is a method of authentication using cryptography that allows an entity to prove to another that specific requirements for a transaction are met instead of disclosing all the data.
1. SSIMeetup.org: O’Donnell, Darrell — The State of the Digital Wallet
#SSI; #decentralizedidentity; #blockchain; #digitalidentity; #selfsovereignidentity; #identity; #dlt; #web3; #web3.0; #dApps; #digitalwallets; #distributedledger