Wallets, Transactions and Decentralized Identity

Introduction

Decentralized applications (dApps) do not usually authenticate users through a central username-and-password database. Instead, users control cryptographic keys, authorize transactions, and present verifiable claims. Wallets provide the principal interface between users, blockchain networks, decentralized applications, and identity systems.

This chapter examines wallet architecture, key management, transaction construction and signing, account abstraction, decentralized identifiers (DIDs), verifiable credentials (VCs), and secure authentication flows. The emphasis is practical: a developer must understand not only how these mechanisms work, but also how to design systems that remain secure when keys are lost, devices are compromised, transactions are misrepresented, or users are exposed to malicious applications.

A wallet is not merely a digital container for coins. It is a key-management and authorization system. In many systems, the wallet does not store assets directly; assets remain recorded on a distributed ledger, while the wallet stores or accesses the cryptographic capability required to control them.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the relationship between private keys, public keys, addresses, accounts, and wallets.
2. Compare custodial, non-custodial, smart-contract, hardware, and multisignature wallets.
3. Describe transaction construction, fee calculation, signing, broadcasting, confirmation, and failure.
4. Apply sound key-management and wallet-connection practices.
5. Explain account abstraction and its effect on user experience and authorization.
6. Distinguish decentralized identifiers from verifiable credentials.
7. Design secure authentication flows using wallet signatures and challenge–response protocols.
8. Evaluate privacy, governance, regulatory, usability, and operational risks.

1. Cryptographic Foundations of Wallets

1.1 Keys and signatures

Most blockchain wallets rely on asymmetric cryptography. A key-pair consists of a private key and a corresponding public key. The private key is secret and is used to create digital signatures. The public key can be distributed and is used by others to verify those signatures.

A signature does not normally encrypt a transaction. It proves that the holder of a private key approved a specific message. A valid signature demonstrates integrity and authorization under the relevant cryptographic scheme, but it does not prove the legal identity of the signer.

A simplified signing relationship can be represented as:

Here, sk is the private key, m is the message, and σ is the signature. Verification is represented as:

where pk is the corresponding public key. The equations describe an interface rather than a particular algorithm. Actual security depends on the cryptographic scheme, implementation, random-number generation, message encoding, and protection of the private key.

A blockchain address is usually derived from a public key or, in smart-contract systems, from contract-account data. Address derivation is network-specific. An address should therefore be interpreted as an identifier for an account or destination, not as a universal identity.

1.2 Seed phrases and hierarchical deterministic wallets

A hierarchical deterministic (HD) wallet derives many keys from a single root secret. A recovery phrase, often called a mnemonic phrase, is an encoding of entropy from which a seed can be generated. From that seed, a wallet derives a tree of private keys and public keys according to a defined derivation procedure.

The convenience is substantial: one backup can recover many accounts. The risk is equally substantial: compromise of the recovery phrase may compromise every account derived from it. A recovery phrase should never be entered into an untrusted website, sent by email, stored in ordinary cloud notes, or photographed on a device connected to the internet.

Derivation paths create interoperability issues. Two wallets can possess the same recovery phrase yet display different accounts if they use different derivation paths, address formats, or network conventions. Professional recovery procedures must document the wallet type, network, derivation path, account index, and any passphrase.

1.3 Wallet categories

The terms “hot” and “cold” describe connectivity. A hot wallet is connected to an online environment and is convenient for frequent transactions. A cold wallet keeps signing capability offline or substantially isolated. Neither category is automatically safe: a cold wallet can be misused through social engineering, while a hot wallet can be appropriately protected for low-value activity.

2. Key Management as a Security Discipline

Key management is a lifecycle, not a single storage decision. It includes generation, backup, use, rotation or replacement where possible, recovery, revocation, and destruction.

2.1 Threat model

A wallet design should begin with explicit threats:

• phishing websites that request approval for a harmful transaction;
• malicious browser extensions or mobile applications;
• clipboard replacement and address poisoning;
• compromised signing devices;
• insider misuse in organizations;
• loss of a device or recovery material;
• smart-contract vulnerabilities;
• denial of service against RPC providers or wallet infrastructure;
• coercion, theft, or unauthorized physical access;
• fraudulent customer-support impersonation.

Risk is not determined only by cryptographic strength. A technically secure signature scheme cannot compensate for a recovery phrase copied into malware or a user signing an unintelligible message.

2.2 Controls and operational practice

For individual users, appropriate controls include separating high-value and daily-use accounts, verifying transaction details on a trusted display, using hardware wallets for significant holdings, and maintaining geographically separated backups. Backups should be protected against fire, water, unauthorized access, and accidental disclosure.

For organizations, key control should include role separation, transaction policies, approval thresholds, multisignature authorization, audit logs, incident procedures, and carefully tested recovery drills. A policy might require two of three authorized signers for treasury transfers above a defined threshold. The exact policy depends on the organization’s legal duties, risk tolerance, and transaction volume.

A recovery plan must answer five questions: who can recover, what evidence is required, where backup material is located, how compromise is detected, and how the organization continues operating if one custodian becomes unavailable.

2.3 Permissions and approvals

Users often confuse signing a message with approving an asset transfer. Modern dApps may request token allowances, permit signatures, session keys, delegated permissions, or smart-contract operations. A signature can authorize future activity rather than an immediate transfer.

Wallet interfaces should therefore display:

• the target address or contract;
• the network;
• the asset and amount;
• the effective fee or spending limit;
• whether an approval is temporary or persistent;
• the requested message or typed data;
• the consequences of granting the permission.

Developers should avoid opaque “sign this” prompts. Human-readable typed data is preferable to arbitrary hexadecimal data where the protocol supports it.

3. Wallet Connectivity and dApp Interaction

A dApp generally consists of a user interface, application logic, smart contracts, and a connection to a blockchain node or RPC provider. The wallet acts as a security boundary. The dApp may request the user’s public address, ask the wallet to sign a message, or request a transaction that the wallet displays and signs.

A robust connection flow is:

1. The user selects a wallet explicitly.
2. The dApp requests connection through the wallet’s standard interface.
3. The wallet displays the origin requesting access.
4. The user approves selected accounts rather than granting unnecessary access.
5. The dApp checks the network and account state.
6. The dApp requests signatures or transactions only when needed.
7. The wallet presents meaningful details for user confirmation.
8. The dApp treats the wallet response as untrusted input until validated.

A dApp should not assume that a connected address proves ownership of a person, organization, or legal identity. It proves only that the wallet exposed that address and, after a valid signature, that the signer controlled the associated key at that time.

Applications should also handle account changes, network changes, wallet disconnection, rejected requests, insufficient funds, nonce conflicts, chain reorganizations, and provider outages. Front-end state must not be treated as final blockchain state.

4. Transactions: Construction, Signing and Settlement

4.1 Transaction lifecycle

A transaction commonly passes through these stages:

1. Intent: the user or application specifies an action.
2. Construction: destination, data, value, nonce or sequence, fee parameters, and network identifier are assembled.
3. Simulation: the transaction is evaluated where simulation is available.
4. User review: the wallet presents the operation.
5. Signing: the private key signs a protocol-defined representation.
6. Broadcast: a node receives the signed transaction.
7. Inclusion: a block producer includes it in a block.
8. Confirmation or finality: the network provides increasing or explicit confidence that the result will persist.
9. Application reconciliation: the dApp updates its state based on verified chain data.

A signed transaction is usually immutable. If a user notices an incorrect destination after broadcasting, the transaction cannot generally be edited; a compensating transaction may be the only remedy.

4.2 Fees

Fee models differ by blockchain. In a simple variable-price model, the transaction fee can be expressed as:

GasUsed is the computational resource consumed, measured in gas units; GasPrice is the price per unit of gas; and the fee is denominated in the network’s native asset. The formula applies only to fee systems using this structure. Some networks use separate execution and data fees, fixed fees, priority fees, or resource leasing.

For a transaction with 80,000 gas units and a gas price of 25 gwei:

Because 1 ether equals 1,000,000,000 gwei, the fee is 0.002 ether. This calculation assumes that 80,000 is the actual gas consumed and that the quoted gas price remains applicable. A gas limit is not necessarily the same as gas used; unused gas may be refunded or treated according to network rules.

In an EIP-1559-style model, a simplified effective price is commonly represented as:

The base fee is protocol-determined, while the priority fee is an incentive to the block producer. Implementations may impose a maximum fee, and the amount actually paid depends on the protocol’s refund and inclusion rules. Developers must use the target network’s current specification rather than assuming one universal formula.

4.3 Nonces, replay protection and chain identifiers

An account-based network may use a nonce or sequence number to order transactions and prevent unintended replay. If a transaction is submitted with an incorrect nonce, it may remain pending, replace another transaction, or be rejected. A chain identifier helps prevent a signature intended for one network from being accepted on another network.

Replay protection is a protocol property, not merely a wallet feature. Cross-chain applications require special care because a message valid on one domain may be dangerous if interpreted on another. Signed messages should include domain, chain, contract, purpose, expiration, and audience where appropriate.

4.4 Transaction failure

A transaction can fail before inclusion, during execution, or after inclusion from the perspective of the application. For example, a user may reject a wallet prompt; a node may reject an invalid nonce; a contract may revert because a balance or condition is insufficient; or a transaction may be included but later become non-final under a probabilistic consensus model.

A dApp should distinguish at least:

• user rejection;
• transport or RPC failure;
• validation failure;
• execution revert;
• pending status;
• successful inclusion;
• finality or confirmation status.

5. Account Abstraction

Traditional externally controlled accounts typically require the user to sign a transaction directly with a private key. Account abstraction allows account behavior to be defined by programmable logic. A smart-contract account can specify signature schemes, recovery mechanisms, spending limits, session keys, batching, sponsored fees, and alternative authentication methods.

A useful conceptual model separates three functions:

1. Authorization: deciding whether an operation is permitted.
2. Validation: checking signatures, policies, nonce rules, and replay protection.
3. Execution: carrying out the requested operation.

This separation enables features such as social recovery, where trusted guardians help replace a lost key, and gas sponsorship, where a relayer pays transaction fees on behalf of a user. It can also enable batched operations—for example, approving and depositing an asset in one user action.

Account abstraction does not eliminate security risk. It transfers some risk from a single private key to wallet code, validators, relayers, paymasters, upgrade mechanisms, and recovery governance. A poorly designed smart-contract account may contain vulnerabilities more serious than those of a simple key-based account.

Developers should evaluate:

• validation logic and signature malleability;
• nonce and replay handling;
• upgrade authority;
• recovery and guardian collusion;
• relayer censorship or fee manipulation;
• denial-of-service through deliberately expensive operations;
• compatibility with wallets, explorers, and protocols;
• emergency pause and recovery procedures.

6. Decentralized Identity

6.1 Identity models

Traditional identity systems commonly use centralized registries and identity providers. Decentralized identity aims to allow subjects to use identifiers and credentials without requiring every interaction to be mediated by one central provider.

A decentralized identity architecture normally separates:

• the subject, such as a person, organization, or device;
• the issuer, which makes a claim;
• the holder, which stores and presents a credential;
• the verifier, which checks the claim;
• the registry or network, which may support identifier resolution or key-status information.

These roles can be played by different parties, although one entity may occupy more than one role.

6.2 Decentralized identifiers

A decentralized identifier is an identifier designed to be controlled or updated through cryptographic mechanisms rather than issued solely by a centralized registration authority. A DID commonly resolves to a DID document or equivalent representation containing verification methods, service endpoints, and update or deactivation information.

A DID does not automatically reveal a person’s real-world identity. It may be pseudonymous, and a subject can use separate DIDs for separate contexts. Reusing one DID everywhere can create correlation and weaken privacy.

DID methods differ in their trust, cost, performance, persistence, governance, and dependence on a particular ledger or registry. Some use public blockchains; others use distributed databases, peer-to-peer exchange, or web-based mechanisms. The method specification determines how keys are added, rotated, recovered, and revoked.

6.3 Verifiable credentials

A verifiable credential is a digitally structured claim made by an issuer about a subject. Examples include professional qualifications, age eligibility, organization membership, or proof that a device passed a compliance assessment.

A credential normally contains an issuer, subject, claims, issuance information, and cryptographic proof. Verification may establish that:

• the credential was issued by the stated issuer;
• the credential has not been altered;
• the presentation was authorized by the holder;
• the credential is not expired or revoked, where status information is available;
• the claims satisfy the verifier’s policy.

A credential is not necessarily true merely because its signature is valid. Cryptography proves integrity and attribution to an issuer; it does not guarantee that the issuer’s original claim was accurate or that the issuer remains trustworthy.

A holder can create a verifiable presentation, sometimes disclosing only selected claims. Selective disclosure and zero-knowledge techniques can reduce unnecessary exposure. For example, a verifier may need proof that a user is above a required age without learning the user’s exact birth date. Such systems require careful implementation, compatible schemas, and sound revocation or status mechanisms.

7. Secure Authentication Flows

7.1 Why signing an address is insufficient

A login system must prevent replay and cross-site misuse. Asking a user to sign only their address is inadequate because the same signature may be reused by an attacker. A secure challenge–response flow gives the user a fresh, unpredictable challenge bound to the intended application.

A recommended sequence is:

1. The client requests a nonce from the server.
2. The server generates a cryptographically random, single-use nonce and stores it with an expiration time.
3. The server constructs a domain-bound message containing the domain, address, nonce, issued-at time, and intended action.
4. The wallet signs the message.
5. The client sends the signature and message to the server.
6. The server verifies the message format, domain, nonce, time window, address, and signature.
7. The server marks the nonce as used and creates a session.
8. The session uses secure cookies or another protected mechanism, with expiration and revocation controls.

The message should not contain misleading instructions or request an unrelated transaction. Human-readable signing standards can improve user comprehension, but developers must still validate every field server-side.

7.2 Authentication versus authorization

Authentication asks, “Which key or credential is controlling this session?” Authorization asks, “What is this actor allowed to do?” A valid wallet signature may authenticate control of an address, but authorization should be governed by application roles, credential attributes, transaction policies, and risk controls.

High-risk actions should use step-up authentication, fresh signatures, transaction-specific intent, and possibly multiple approvers. A long-lived session should not automatically authorize an irreversible treasury transfer.

7.3 Privacy-preserving identity

Identity systems should collect the minimum information required for the purpose. Design principles include pairwise identifiers, selective disclosure, short-lived presentations, encrypted storage, explicit consent, and separation of authentication records from business data.

Public ledgers are generally poor locations for personal data. Even encrypted data can create legal and operational problems because deletion, key loss, metadata analysis, and future cryptanalytic advances may affect privacy. Store proofs, hashes, or status references on-chain only when the purpose and governance model justify doing so.

8. Applied Case: Illustrative Credential-Based Learning Platform

Background

Consider an illustrative decentralized learning platform called OpenCert. Universities issue digitally signed course credentials. Students store them in a wallet and present them to employers or partner institutions.

Problem

The platform must allow students to authenticate without passwords, prove completion of a required course, protect personal information, and support credential revocation when an administrative error is discovered.

Analysis

A wallet address alone cannot prove that the holder completed a course. The university must act as issuer, and the student must control the holder wallet. The employer acts as verifier. The system must also distinguish authentication from qualification: controlling a wallet proves control of a key, whereas the credential provides the qualification claim.

Approach and solution

The platform uses a challenge–response login. The server creates a short-lived nonce and a domain-bound message. The student signs it with the wallet, and the server verifies the signature before establishing a session.

The university issues a verifiable credential containing the student’s pairwise identifier, course identifier, completion date, issuer identifier, and credential status reference. The student presents only the required course claim to the employer. The employer verifies the issuer signature, schema, expiration, subject binding, and status. The system avoids placing the student’s name or course results directly on a public blockchain.

Administrative staff use multisignature authorization for issuer-key changes. Issuer keys are held in hardware-backed custody, and a documented incident process supports rotation. The credential status mechanism is designed to reveal as little information as possible about the student’s activity.

Outcome

The resulting architecture reduces password dependence, supports portable qualifications, and allows selective disclosure. It does not remove trust: employers must still decide whether the university is an appropriate issuer, and the university must protect its signing keys and maintain accurate records.

Learning points

1. Authentication, authorization, and qualification are distinct.
2. A credential’s cryptographic validity does not guarantee the truth of its claim.
3. Privacy requires deliberate identifier and data-storage choices.
4. Issuer-key governance is as important as the credential format.
5. Revocation, recovery, and incident response must be designed before deployment.

9. Governance, Regulation and Ethical Considerations

Wallet and identity systems can create legal obligations involving consumer protection, financial crime controls, data protection, accessibility, electronic signatures, and regulated custody. Requirements vary by jurisdiction and by the function performed. A system that merely verifies a credential may have different obligations from one that safeguards assets or facilitates financial transfers.

Decentralization does not automatically distribute responsibility fairly. Users may bear irreversible losses caused by confusing interfaces, while service providers may retain substantial control through upgrade keys, relayers, or infrastructure. Ethical design requires transparent risk communication, accessible recovery options, protection against coercion, and support for users with disabilities or limited technical literacy.

Identity systems can also enable surveillance. Permanent identifiers, public transaction histories, and credential-presentation metadata may permit profiling. Designers should conduct data-protection assessments, minimize collection, and provide meaningful alternatives where feasible.

10. Contemporary Developments and Best Practices

Current development trends include passkey and secure-enclave integration, smart-contract wallets, social recovery, session keys for games and applications, account abstraction, privacy-preserving credentials, and interoperability across credential ecosystems. Artificial intelligence may assist with transaction explanation and anomaly detection, but an AI-generated explanation must not replace authoritative wallet data or user confirmation. AI systems can misclassify malicious transactions and should be treated as advisory.

Best practices include:

• use audited, maintained cryptographic libraries;
• never implement cryptographic primitives independently unless qualified to do so;
• bind signatures to domain, chain, contract, purpose, nonce, and expiration;
• provide clear transaction and permission displays;
• separate low-value operational wallets from treasury wallets;
• test recovery, key rotation, revocation, and incident response;
• simulate transactions and monitor for unexpected state changes;
• use multisignature or policy controls for organizational assets;
• minimize personal data and avoid unnecessary on-chain publication;
• document dependencies, trust assumptions, and administrator powers;
• conduct independent security audits and adversarial testing;
• communicate that blockchain finality and reversibility vary by network.

Challenges and Limitations

Wallet systems remain difficult for ordinary users because cryptographic responsibility is unfamiliar and errors may be irreversible. Recovery mechanisms introduce trusted parties or code complexity. Smart-contract wallets can improve usability but increase the attack surface. Cross-chain identity is hindered by inconsistent standards, differing finality models, and uncertain governance.

DIDs and credentials face interoperability challenges. A credential may be technically verifiable but socially or legally unacceptable to a verifier. Revocation can leak information or depend on an issuer remaining available. Privacy techniques may require advanced cryptography and careful performance engineering.

Finally, decentralization is a spectrum. Wallet providers, RPC endpoints, credential issuers, relayers, software maintainers, and governance bodies may exercise significant practical control. A credible architecture states these dependencies explicitly rather than presenting decentralization as an absolute property.

Chapter Summary

Wallets are interfaces for cryptographic control, authorization, and interaction with decentralized networks. Private keys produce signatures; public keys support verification; addresses identify accounts or destinations; and recovery phrases can derive entire hierarchies of keys. Security depends on lifecycle management, threat modeling, clear permission displays, and operational governance.

Transactions move through construction, simulation, user review, signing, broadcasting, inclusion, and confirmation. Fees, nonces, chain identifiers, replay protection, and failure states must be handled according to the target network’s specification. Account abstraction makes authorization programmable and can support recovery, sponsored fees, batching, and alternative authentication, but it introduces additional code and governance risks.

DIDs provide decentralized or distributed identifiers, while verifiable credentials carry issuer-signed claims. Secure authentication requires a fresh, single-use, domain-bound challenge and server-side verification. Authentication must be separated from authorization and qualification. Privacy, regulation, accessibility, revocation, recovery, and issuer governance are essential parts of professional dApp design.

Key Terms

Private key: Secret cryptographic value used to authorize operations and create signatures.

Public key: Cryptographic value corresponding to a private key and used for verification.

Digital signature: Cryptographic proof that a key holder approved a message.

Wallet: Software or hardware that manages keys and facilitates blockchain interaction.

Recovery phrase: Human-readable representation of wallet recovery entropy or seed material.

Hierarchical deterministic wallet: Wallet that derives many keys from one root seed.

Custodial wallet: Wallet in which another organization controls the signing keys.

Non-custodial wallet: Wallet in which the user or organization controls the signing keys.

Hardware wallet: Dedicated device that isolates or protects key operations.

Multisignature wallet: Wallet requiring authorization from multiple keys.

Nonce: Sequence value used to order operations and reduce replay or duplication.

Gas: Protocol-defined unit representing computational or resource consumption.

Account abstraction: Programmable account model separating authorization from transaction execution.

Decentralized identifier (DID): Identifier designed for cryptographic control and decentralized resolution or management.

DID document: Representation containing verification methods, services, and management information for a DID.

Verifiable credential: Digitally structured, issuer-signed claim about a subject.

Verifiable presentation: Holder-created presentation of one or more credentials to a verifier.

Challenge–response authentication: Authentication method using a fresh challenge signed by the claimant.

Selective disclosure: Presentation of only the credential attributes necessary for a purpose.

Replay attack: Reuse of a previously valid message or signature in an unauthorized context.

Review Questions

Short Answer Questions

1. What is the relationship between a private key, public key, and digital signature?
2. Why is a recovery phrase more sensitive than an ordinary wallet address?
3. Distinguish gas used from a transaction gas limit.
4. What is the purpose of a nonce in an authentication challenge?
5. How does a verifiable credential differ from a decentralized identifier?

Long Answer Questions

1. Compare custodial, software, hardware, smart-contract, and multisignature wallets, including their principal security trade-offs.
2. Explain the complete lifecycle of a blockchain transaction from user intent to finality.
3. Describe how account abstraction can improve usability and identify the new risks it introduces.
4. Explain the roles of issuer, holder, subject, and verifier in a verifiable credential ecosystem.
5. Design a secure wallet-based login protocol and justify each security control.

Analytical / Application Questions

1. An organization stores treasury keys in one browser wallet used by several employees. Analyze the risks and propose a revised governance and key-management architecture.
2. A dApp asks users to sign an opaque hexadecimal message and later reports unauthorized token transfers. Identify the likely design failures and recommend corrective measures.
3. Design a privacy-preserving credential flow for proving eligibility for a service without publishing the user’s name or exact date of birth. Discuss issuer trust, revocation, holder binding, and verifier obligations.

Multiple Choice Questions with Answers

Question 1

Which capability does a private key primarily provide in a blockchain wallet?

A. Creating digital signatures that authorize operations

B. Encrypting every block on the network

C. Determining the market price of an asset

D. Guaranteeing the legal identity of its holder

Correct Answer: A. Creating digital signatures that authorize operations

Question 2

Using the simplified fee formula Fee = GasUsed × GasPrice, what is the fee for 50,000 gas units at 20 gwei per unit?

A. 0.0001 ether

B. 0.001 ether

C. 0.01 ether

D. 1 ether

Correct Answer: B. 0.001 ether

Question 3

What is the main security purpose of a fresh, single-use nonce in wallet authentication?

A. Reducing blockchain storage costs

B. Preventing replay of an old authentication message

C. Increasing the user’s token balance

D. Replacing the need for signature verification

Correct Answer: B. Preventing replay of an old authentication message

Question 4

Which statement best describes a verifiable credential?

A. A private key stored in a hardware device

B. A digitally structured claim issued about a subject

C. A blockchain block containing all user identity data

D. A network fee paid to a relayer

Correct Answer: B. A digitally structured claim issued about a subject

Question 5

What is a major advantage of account abstraction?

A. It makes all smart contracts bug-free

B. It allows programmable authorization and features such as recovery or sponsored fees

C. It eliminates the need for any cryptographic keys

D. It guarantees that transactions cannot be censored

Correct Answer: B. It allows programmable authorization and features such as recovery or sponsored fees

Question 6

Which party normally makes a claim in a verifiable credential system?

A. Issuer

B. Relayer

C. Block producer only

D. RPC cache

Correct Answer: A. Issuer

Question 7

Why should a dApp bind a signed login message to its domain?

A. To increase gas consumption

B. To prevent the message from being misused by another application

C. To convert a public key into a private key

D. To make the signature anonymous in every context

Correct Answer: B. To prevent the message from being misused by another application

Question 8

Which practice best protects a high-value organizational wallet?

A. Sharing one recovery phrase among all employees

B. Using multisignature authorization and documented recovery procedures

C. Publishing the private key for transparency

D. Disabling transaction review to improve speed

Correct Answer: B. Using multisignature authorization and documented recovery procedures

Question 9

What does selective disclosure seek to achieve?

A. Reveal every credential attribute to every verifier

B. Present only the information necessary for the verification purpose

C. Remove the issuer’s signature from a credential

D. Make a credential permanently non-revocable

Correct Answer: B. Present only the information necessary for the verification purpose

Question 10

Which statement about a valid credential signature is correct?

A. It proves that every claim is factually true in all circumstances

B. It proves integrity and attribution to the issuer, subject to trust in that issuer

C. It proves that the holder is a government employee

D. It removes the need to check expiration or status

Correct Answer: B. It proves integrity and attribution to the issuer, subject to trust in that issuer