Verification Method

A consensus model where a limited number of pre-approved, reputable nodes (validators) are granted the authority to validate transactions and create blocks. Identity and reputation are the staked assets.

• Key Feature: High throughput and efficiency, suitable for private or consortium blockchains.
• Use Case: Enterprise networks, testnets (like Goerli), and supply chain solutions.
• Trust Model: Relies on the legal identity and reputation of validators.

A consensus mechanism where miners allocate disk space to the network instead of computational power. The probability of mining a block is proportional to the amount of storage space committed.

• Key Feature: Utilizes hard drive space, which is more energy-efficient than PoW.
• Example: Chia Network is the most prominent implementation.
• Process: Involves "plotting" disks with cryptographic data and "farming" to find solutions.

A democratic variant of Proof of Stake where token holders vote to elect a small set of delegates (or witnesses) to validate transactions and produce blocks on their behalf.

• Key Feature: Aims for faster block times and higher scalability through representative validation.
• Governance: Voters can replace underperforming delegates.
• Examples: EOS, TRON, and Steem use variations of DPoS.

A Verification Method is a JSON object within a DID Document that specifies the mechanism for cryptographic verification. Its key properties are:

• id: A unique URI, often the DID plus a fragment (e.g., did:example:123#key-1).
• type: The cryptographic suite type (e.g., JsonWebKey2020, Ed25519VerificationKey2020).
• controller: The DID that controls this method.
• publicKeyJwk or publicKeyMultibase: The actual public key material in a specified format.

It is the foundational element for proving control of a DID.

A Verification Method is referenced by the authentication property of a DID Document. This creates a formal link between the DID subject and the proof mechanism.

• The authentication array contains IDs of Verification Methods (e.g., ["did:example:123#key-1"]).
• This separation allows a single key (Verification Method) to be used for multiple purposes (e.g., authentication and assertion).
• It enables key rotation: a new Verification Method can be added and referenced in authentication, deprecating the old one without changing the core DID.

The type field defines the cryptographic algorithm and key format. Common types include:

• JsonWebKey2020: A JWK (JSON Web Key) format, versatile for RSA, EC, or OKP key types.
• Ed25519VerificationKey2020: For Ed25519 signature schemes using multibase-encoded keys.
• EcdsaSecp256k1VerificationKey2019: For the secp256k1 curve common in blockchain contexts.
• X25519KeyAgreementKey2020: For key agreement (encryption) using X25519.

Each type dictates how the public key is encoded and which verification algorithms are valid.

Verification Methods are critical for Verifiable Credentials (VCs). When an issuer signs a VC, they use the private key corresponding to a Verification Method in their DID Document.

• A verifier fetches the issuer's DID Document.
• Locates the correct Verification Method via its id (found in the VC proof).
• Uses the public key and type from that method to cryptographically verify the signature on the credential.

This process establishes trust without centralized certificate authorities.

Verification Methods enable secure key management lifecycle events:

• Rotation: Add a new Verification Method to the DID Document and update the authentication or assertionMethod references. The old method remains in the document but is no longer referenced, providing an audit trail.
• Revocation: Remove the method's ID from the relevant purpose arrays (e.g., authentication). Some DID methods also support explicit revocation via a DID Document deactivation.

This mechanism is essential for long-lived identifiers, allowing recovery from key compromise.

Different DID Methods (e.g., did:ethr, did:key, did:web) handle Verification Method resolution differently:

• did:key: Embeds the public key directly in the DID itself; the DID Document is generated deterministically and contains a single Verification Method.
• did:ethr: Uses Ethereum addresses; Verification Methods are often EcdsaSecp256k1RecoveryMethod2020 types, allowing verification via standard Ethereum signed messages.
• did:web: Relies on fetching a JSON document from a web URL; the Verification Methods are as defined in that hosted document.

The method dictates how the Verification Method's data is anchored and discovered.

The security of a verification method depends entirely on the protection of its private key. Common vulnerabilities include:

• Hot Wallet Storage: Keys stored on internet-connected devices are susceptible to malware and phishing.
• Insecure Backups: Writing keys on paper or in plaintext files creates physical and digital exposure risks.
• Lack of Multi-Signature: Relying on a single key is a single point of failure. Best practices involve hardware wallets, multi-party computation (MPC), and secure, encrypted backups.

Attackers often bypass cryptography by targeting the user directly. Common threats include:

• Fake Websites: Mimicking legitimate dApp interfaces to steal seed phrases.
• Impersonation: Posing as support staff in forums or social media to request private keys.
• Transaction Manipulation: Tricking users into signing malicious transactions that drain assets. Defense requires user education, verifying URLs, and using wallet features that decode transaction intent before signing.

Bugs in the code that implements the verification logic can create critical vulnerabilities.

• Signature Malleability: Flaws where a valid signature can be altered without invalidating it, historically exploited in Bitcoin.
• Nonce Reuse: Reusing a nonce in ECDSA can lead to private key leakage.
• Improper Curve Parameters: Using non-standard or weak elliptic curves compromises cryptographic strength. Mitigation involves rigorous audits, formal verification, and using well-vetted, standard libraries.

For DIDs, a compromised verification method must be revoked and replaced. Security considerations include:

• Revocation Registry: The mechanism (e.g., a smart contract, ledger entry) that publicly records revoked keys must be tamper-proof.
• Recovery Methods: Secure processes for regaining control of a DID after key loss, avoiding central points of control.
• Key Rotation: The ability to proactively update to new cryptographic keys without losing the persistent identifier.

Most current verification methods (ECDSA, EdDSA) are vulnerable to attacks from sufficiently powerful quantum computers. This future threat necessitates:

• Post-Quantum Cryptography (PQC): Algorithms like CRYSTALS-Dilithium that are believed to be secure against quantum attacks.
• Agility: Designing systems where verification methods can be upgraded to PQC standards without breaking the underlying identifier.
• Hybrid Schemes: Using a combination of classical and post-quantum signatures during the transition period.

Verification methods rely on the security of the underlying blockchain or ledger.

• 51% Attacks: On proof-of-work chains, an attacker controlling majority hash power could censor or reorganize transactions, undermining verification.
• Finality & Reorgs: Methods assuming instant finality are risky on chains with long reorg depths.
• Smart Contract Vulnerabilities: If verification is delegated to a smart contract (e.g., a multisig), that contract's security becomes critical.

A JSON-LD document that contains the cryptographic material and service endpoints necessary to interact with a DID. It is the primary location where verification methods are defined and published.

• Contents: Lists public keys, verification methods, and service endpoints.
• Resolution: Retrieved by resolving the DID URI.
• Key Section: The verificationMethod array is where specific verification keys and their types (e.g., EcdsaSecp256k1VerificationKey2019) are declared.

A data format used by a holder to present one or more Verifiable Credentials to a verifier. It often requires the holder to prove control of their DID using a verification method, typically through a proof of possession.

• Purpose: Bundles and presents credentials for a specific interaction.
• Authentication: Contains a proof signed by the holder's private key, linked to a verificationMethod in their DID Document.
• Selective Disclosure: Can be used to reveal only specific claims from credentials.

A required property in a verification method or a linked data proof that declares the intent for which the cryptographic key is used. It restricts the usage of a verification method to prevent misuse.

• Common Purposes: authentication, assertionMethod, keyAgreement, capabilityInvocation, capabilityDelegation.
• Example: A key with proofPurpose: "authentication" can only be used to prove control of the DID during a login, not to sign a Verifiable Credential.

A standardized format for representing cryptographic keys as JSON objects. It is a common encoding used within verification methods in DID Documents to specify public key material.

• Standardization: Defined in RFC 7517.
• Usage: The publicKeyJwk property in a verification method contains the key in JWK format.
• Interoperability: Enables different systems to parse and use the same key material for verification.