A digital identity wallet is a secure, encrypted database that collects and holds keys, identifiers, and verifiable credentials (VCs). The wallet is also a digital address book, collecting and maintaining its controller’s many relationships. The wallet is coupled with a software agent that speaks the protocols necessary to engage with others. Sometimes, we’ve used wallet as a shorthand for both wallet and agent, not distinguishing carefully between them. But here, we’ll be more specific about which tool performs which actions. Alice’s digital wallet might contain many things that she, in her capacity as controller, needs to store securely, including:

  • Decentralized identifiers she has created or received, including public DIDs, peer DIDs, and KERI identifiers
  • The backing store (or key event log) she uses to manage peer relationships
  • Keys related to DIDs but perhaps others as well; SSH keys, for example, could be securely managed in a digital wallet
  • PKI digital certificates and the private keys associated with them
  • Keys and addresses for cryptocurrency
  • VCs that Alice holds
  • Receipts, warranties, and titles (some as VCs)
  • PDFs or other digital representations of physical credentials for which Alice doesn’t have proper VCs
  • Usernames and passwords
  • Personal data of all kinds that Alice uses to create self-issued VCs, fill out web forms, or simply store securely

Many people store these kinds of data in password managers or operating-system-specific tools like Apple’s Keychain. People who hold cryptocurrencies also have one or more cryptowallets to store keys and addresses. These various protowallets suffer from several problems:

  • They are often proprietary systems. As such, they suffer from many of the problems that I’ve delineated for administrative identity systems. The most limiting is that they can be used for only the purposes their owners allow.
  • While they might be open, allowing other parties to store things in them, the types of use cases are tightly controlled.
  • They use inflexible data schemas that limit the kinds of data they can store.
  • They aren’t built on open standards and thus lock people into a specific platform. I’d hate to reenter all the login data I have stored in my password manager, for example.
  • They lack consistent user experiences. My password manager, keychains, smartphone wallet, and cryptowallets all behave differently. Sometimes even the same tool, like a keychain, differs from platform to platform despite being created by one organization.

An identity wallet overcomes these problems and has the added advantage of putting all of your important documents and relationships in one consistent place. Thus, many people will opt to move sensitive data from protowallets into identity wallets. Other terms you might hear in the context of identity wallets are personal data store and vault. The variety of information that might be stored in an identity wallet may feel like a loose grab bag of digital stuff. The line between an identity wallet, a personal data store, and a vault is blurry, but they are distinguished by both their sizes and the types of data they contain. A vault might be a secure place to store all my digital stuff, while a personal data store holds all the information I have about me and an identity wallet is just the information I use to recognize, remember, and interact with others. Another key distinction between these three stores is the level of protection they must offer. Figure 1 illustrates the levels of protection we might require for various kinds of personal information.4 Information like my cryptocurrency keys needs much stronger and more robust security protection than the messages I’ve exchanged with Amazon or my friends. Personal data stores and vaults may get by with weaker protections for the data they hold than an identity wallet would. These distinctions provide guidance on the design and implementation of an identity wallet. [1]

Figure 1. Relative protection requirements for personal data



The wallets tasks can be summarised as below:

  • Secure Storage: Wallets act as secure enclaves for storing DID information, including private keys, credentials, and verifiable presentations. Cryptographic primitives like zero-knowledge proofs ensure secure access and control over data. Standards like W3C DID Document [https://www.w3.org/TR/did-core/] specify the data structure for DID information within wallets.
  • Credential Management: Wallets provide mechanisms for receiving, managing, and revoking credentials issued by various entities. This involves functionalities like parsing credential formats like Verifiable Credentials (VCs) based on JSON Web Signature (JWS) [https://datatracker.ietf.org/doc/html/rfc7515] or JSON Web Encryption (JWE) [https://datatracker.ietf.org/doc/html/rfc7516] for secure data representation and cryptographic signatures. Wallets should also support Selective Disclosure [https://www.w3.org/TR/vc-data-model/] to reveal only necessary information within credentials.
  • Interoperability: Wallets should support different DID methods and communication protocols to interact seamlessly with various issuers and verifiers. Standards like Decentralised Identifiers (DIDs) Document https://www.w3.org/TR/did-core/ and JSON Web Signatures (JWS) [https://datatracker.ietf.org/doc/html/rfc7515] facilitate interoperability.

The Roles of Agents

Identity agents are software services that manage all the stuff in the wallet. Agents store, update, retrieve, and delete all the artifacts that a wallet holds. Beyond managing the wallet, agents perform many other important tasks:7

  • Sending and receiving messages with other agents
  • Requesting that the wallet generate cryptographic key pairs
  • Managing encrypted data interactions with the wallet
  • Performing cryptographic functions like signing and verifying signatures
  • Backing up and retrieving data in the wallet
  • Maintaining relationships by communicating with other agents when DID documents are updated
  • Routing messages to other agents

Figure 2 shows the relationship between an agent, a wallet, and an underlying operating system. While most current implementations pair a single agent with a single wallet, the presence of an API means that it’s possible for one agent to use several wallets, or for multiple agents to access one wallet. Some specialized agents might not even need a wallet, such as those that just perform routing, although most will at least need to store their own keys.

The key-management function in the wallet includes events for cryptographic keys like generation, storage, rotation, and deletion. Key management is performed in cooperation with the operating system and underlying hardware. Ideally, the operating system and hardware provide a secure enclave for key storage and a trusted execution environment for performing key-management functions.

Figure 2. The relationship between identity wallets and agents


The basic functions shown in Figure 2 might not seem to have much to do with identity. Identity-related activities like authentication and credential exchange are built on top of these basic functions. The agent can issue, request, and accept VCs. The agent also presents and verifies credentials. Specialized messages perform these activities [2]

Properties of Wallets and Agents

The identity wallets and agents discussed above have several important properties that distinguish them from the protowallets that most people use now:

  • Open, substitutable, and portable

The discussion of the properties of email, showed the important features that result when a system is based on a standard set of protocols. Alice should see similar benefits from her identity wallet and agent that she enjoys in email: choice, consistent user experience, and flexibility—all design features of an identity metasystem.

  • Secure by design

Security is a nonnegotiable feature for identity wallets and agents. Some security features are the result of mutually authenticating DID exchange as the basis for relationships that natively support confidential messaging. Some security features depend on good engineering of things like the wallet’s encrypted storage or the wallet API. Still others result from governance of the overall ecosystem.

  • Private by design

As you know, privacy by design doesn’t layer privacy onto an already built system. Rather, it uses specific design principles to ensure privacy is the default. Identity wallets and agents provide privacy in their design by supporting minimal disclosure of personal data using zero-knowledge proofs (ZKPs) and other techniques, properly encrypting data so that it’s visible only to the intended party, and engineering anticorrelation into the system with techniques like blinded identifiers.

  • Autonomous

As key components in algorithmic and autonomic identity system architectures, agents and wallets give people tools for exercising control authority over identifiers and personal data. This control is the basis for autonomy in digital relationships.

  • Consistent and familiar in their user experience

There’s a saying in security: “Don’t roll your own crypto.” I think we need a corollary in identity: “Don’t roll your own interface.” By supporting the exchange of data based on VCs, identity wallets and agents provide a single means of accomplishing many tasks. One of the important UX features of identity wallets and agents is that people do not manipulate cryptographic keys and DIDs; rather, they manage relationships and credentials. These are familiar artifacts that people understand. [3]


Other roles in the wallet ecosystem:

Issuers

  • Credential Issuance: Issuers are entities authorised to issue verifiable credentials that attest to specific attributes or qualifications. They implement cryptographic signing algorithms like those specified in JSON Web Signature (JWS) [https://datatracker.ietf.org/doc/html/rfc7515] to bind issued credentials to the issuer's DID.
  • Credential Revocation: Issuers maintain the ability to revoke credentials in case of disputes or changes in the attested information. This often involves issuing revocation statements verifiable by holders and verifiers, following standards like W3C Verifiable Credential Revocation List (VCRL) [TODO].
  • Privacy-Preserving Issuance: Issuers can leverage techniques like Selective Disclosure https://www.w3.org/TR/vc-data-model/ and zero-knowledge proofs based on standards like Zero-Knowledge Succinct Non-interactive Argument of Knowledge (zk-SNARKs) to reveal only the necessary information within credentials while preserving user privacy.

Verifiers

  • Credential Verification: Verifiers are responsible for validating the authenticity and validity of presented credentials. This involves verifying cryptographic signatures using standards like JSON Web Signature (JWS) [https://datatracker.ietf.org/doc/html/rfc7515], checking revocation lists based on W3C Verifiable Credential Revocation List (VCRL) [TODO], and potentially contacting issuers for additional information using secure communication protocols.
  • Policy Enforcement: Verifiers can define access control policies based on specific credential attributes. This allows granular control over access based on user claims as specified in the W3C Verifiable Credential Data Model https://www.w3.org/TR/vc-data-model/.
  • Standardised Verification: Verifiers should adhere to established standards for DID communication protocols like DIDComm [https://identity.foundation/didcomm-messaging/spec/v2.1/] to ensure interoperability with various wallets and issuers.

considerable: (TODO)

SIOP2 interface for communication with relying party


References

[1] Windley, Phillip J.. Learning Digital Identity (pp. 511-514). O'Reilly Media. Kindle Edition.

[2] Windley, Phillip J.. Learning Digital Identity (pp. 516-518). O'Reilly Media. Kindle Edition.

[3] Windley, Phillip J.. Learning Digital Identity (pp. 519-520). O'Reilly Media. Kindle Edition.

  • No labels