Decentralized Identity Architecture
W3C standards, DIDs, and verifiable credentials explained
Learning Objectives
Explain the W3C DID architecture and its core components including DID documents, controllers, and resolvers
Differentiate between DIDs, DID documents, verifiable credentials, and verifiable presentations in the identity stack
Design a basic credential issuance and verification flow using W3C standards
Evaluate different DID methods and their trade-offs for security, scalability, and governance
Compare identity wallet architectures and their security models for key management and credential storage
This lesson builds the technical vocabulary and architectural understanding necessary for implementing decentralized identity systems. Unlike traditional identity approaches that rely on centralized authorities, the W3C standards create a framework where identity can be both self-sovereign and universally verifiable.
Your Learning Approach
Focus on Relationships
Understand the relationships between different components rather than memorizing specifications
Consider Security
Think through the security implications of each architectural choice
Evaluate Implementation
Consider how these standards translate to real-world implementation challenges
Assess Trade-offs
Evaluate the trade-offs between decentralization, usability, and regulatory compliance
By the end of this lesson, you will understand not just what these standards define, but why they are structured the way they are and how they enable the identity solutions we will build in later lessons.
Core Identity Architecture Concepts
| Concept | Definition | Why It Matters | Related Concepts |
|---|---|---|---|
| Decentralized Identifier (DID) | A globally unique identifier that enables verifiable, decentralized digital identity without requiring a centralized registry | Eliminates single points of failure and control in identity systems while maintaining global uniqueness | DID Document, DID Controller, DID Subject, DID Method |
| DID Document | A JSON-LD document containing cryptographic material and service endpoints associated with a DID | Provides the technical mechanism for proving control of an identity and enabling secure communication | Public Keys, Service Endpoints, Authentication Methods, Verification Methods |
| Verifiable Credential (VC) | A tamper-evident credential with authorship that can be cryptographically verified | Enables trusted information exchange without requiring direct relationships between all parties | Issuer, Holder, Verifier, Claims, Proof |
| Verifiable Presentation (VP) | A tamper-evident presentation of one or more verifiable credentials | Allows selective disclosure of credential information while maintaining cryptographic integrity | Zero-Knowledge Proofs, Selective Disclosure, Presentation Definition |
| DID Method | A specification that defines how a particular DID scheme is implemented on a specific ledger or network | Different methods offer different trade-offs for cost, performance, governance, and decentralization | did:web, did:key, did:xrpl, Resolution, CRUD Operations |
| Identity Wallet | Software that manages DIDs, keys, and credentials on behalf of a user or organization | The user-facing component that makes decentralized identity practical and secure for everyday use | Key Management, Credential Storage, Agent, Backup and Recovery |
| Trust Framework | Governance rules and technical standards that define how credentials are issued, verified, and trusted within an ecosystem | Bridges the gap between technical standards and real-world legal and business requirements | Governance Framework, Accreditation, Liability, Interoperability |
The World Wide Web Consortium (W3C) DID specification, published as a recommendation in July 2022, establishes the foundational layer for decentralized identity systems. Unlike traditional identifiers that depend on centralized authorities -- domain names require ICANN, email addresses require domain owners, phone numbers require telecom authorities -- DIDs create globally unique identifiers that can be resolved and verified without any centralized infrastructure.
DID Architecture Components
A DID consists of three parts: the scheme (`did`), the method identifier (such as `xrpl` or `web`), and the method-specific identifier. For example, `did:xrpl:rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH` represents an XRPL-based DID where the method-specific identifier corresponds to an XRPL account address.
The power of this architecture lies in its method agnostic design. Each DID method defines how DIDs are created, resolved, updated, and deactivated on a specific system, but all methods must conform to the same abstract data model. This creates interoperability -- a verifier can work with DIDs from any method without understanding the underlying implementation details.
DID Resolution is the process of obtaining the DID document associated with a DID. The resolution process is method-specific but returns a standardized DID document format. For XRPL-based DIDs, resolution involves querying the ledger for the account's current state and constructing the DID document from the account's cryptographic keys and metadata. For web-based DIDs (did:web), resolution involves fetching a JSON document from a well-known URL path.
The resolution process must be deterministic and verifiable. Given a DID, any resolver should return the same DID document (assuming the underlying state hasn't changed). This property is critical for security -- if different resolvers returned different documents for the same DID, the entire system would be vulnerable to manipulation.
DID Document Structure and Security Model
A DID document contains the cryptographic material and metadata necessary to interact with the DID subject. The core components include verification methods (public keys), authentication methods (keys that can prove control of the DID), key agreement methods (keys for encrypted communication), and service endpoints (network addresses for interaction protocols).
{
"@context": ["https://www.w3.org/ns/did/v1"],
"id": "did:xrpl:rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
"verificationMethod": [{
"id": "did:xrpl:rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH#keys-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:xrpl:rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
"publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
}],
"authentication": ["#keys-1"],
"service": [{
"id": "#messaging",
"type": "MessagingService",
"serviceEndpoint": "https://example.com/messaging"
}]
}The security model relies on cryptographic proof of control rather than institutional verification. When a DID controller wants to prove their identity, they create a digital signature using their private key. Verifiers can check this signature against the public key listed in the DID document, confirming that the signer controls the DID without requiring any trusted third party.
This creates a fundamental shift in trust architecture. Traditional PKI systems require certificate authorities to vouch for the binding between identities and public keys. DID systems eliminate this dependency by making the identifier itself cryptographically derivable from or bound to the key material.
The Key Rotation Problem One of the most sophisticated aspects of DID design is handling key rotation -- the ability to change cryptographic keys without changing the identifier. This is crucial for long-term security, as keys may be compromised or need updating due to algorithmic advances. The DID document structure supports multiple verification methods and allows for atomic updates that add new keys before removing old ones. On XRPL, this is implemented through the account's master key and regular key mechanisms, allowing secure key transitions while maintaining identifier continuity.
Method Diversity and Trade-offs
Ledger-based methods (did:xrpl)
- Strong decentralization and censorship resistance
- 3-5 second finality on XRPL
- Minimal fees (~$0.00002 per transaction)
- Permanent availability as long as network operates
Web-based methods (did:web)
- Familiar hosting models and no blockchain costs
- Reintroduces centralized dependencies
- Domain expiration risks
- Hosting failure vulnerabilities
Peer-to-peer methods (did:peer)
- No external infrastructure required
- Ideal for private communications
- Cannot be publicly resolved or verified by third parties
The choice of DID method has profound implications for system architecture. A credential issued to a did:web identifier depends on the continued availability of the web infrastructure, while a credential issued to a did:xrpl identifier remains verifiable as long as the XRPL network operates.
Method Selection Strategy
Organizations implementing decentralized identity must evaluate DID methods as infrastructure investments. Ledger-based methods require ongoing transaction costs but provide stronger guarantees about long-term availability and decentralization. Web-based methods have lower immediate costs but create operational dependencies. The total cost of ownership includes not just technical costs but also the business risk of method unavailability or governance changes.
The W3C Verifiable Credentials Data Model, also published as a recommendation in 2022, defines how claims about subjects can be expressed in a cryptographically verifiable format. This standard transforms credentials from documents that must be trusted based on their source to mathematical proofs that can be independently verified.
Credential Structure and Components
A verifiable credential contains four essential components: the credential metadata (issuer, issuance date, expiration), the credential subject (the entity the credential is about), the claims (the actual information being attested), and the proof (cryptographic evidence of the issuer's authorship).
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"id": "http://university.example/credentials/3732",
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"issuer": "did:xrpl:rUocf1ixKzTuEe34kmVhRvGqNCofY1NJzV",
"issuanceDate": "2024-01-15T14:30:00Z",
"expirationDate": "2029-01-15T14:30:00Z",
"credentialSubject": {
"id": "did:xrpl:rN7n7otQDd6FczFgLdSqtcsAUxDkw6fzRH",
"degree": {
"type": "BachelorDegree",
"name": "Bachelor of Science in Computer Science",
"degreeSchool": "University of Technology"
}
},
"proof": {
"type": "Ed25519Signature2020",
"created": "2024-01-15T14:30:00Z",
"verificationMethod": "did:xrpl:rUocf1ixKzTuEe34kmVhRvGqNCofY1NJzV#keys-1",
"proofPurpose": "assertionMethod",
"proofValue": "zH4s8D9jKqF2M8gP7vR3nL6wX9cE2aB5..."
}
}The power of this structure lies in its mathematical verifiability. The proof section contains a digital signature created by the issuer's private key over the credential content. Any verifier can check this signature against the issuer's public key (obtained from their DID document) to confirm that: (1) the credential was indeed issued by the claimed issuer, (2) the credential content has not been tampered with since issuance, and (3) the issuer had control of their DID at the time of issuance.
Credential Lifecycle and State Management
Issuance
Issuer creates credential content, signs it with private key, and delivers to holder
Storage
Credential becomes holder-controlled asset stored independently of issuer
Presentation
Holder presents credential to verifiers with cryptographic proof of authenticity
Revocation
Issuer can revoke credentials through various mechanisms including on-ledger registries
Revocation presents unique challenges in decentralized systems. Traditional credentials can be revoked by simply removing them from a central database, but verifiable credentials exist independently of their issuers. The W3C specification defines several revocation mechanisms, including revocation lists (centralized lists of revoked credentials) and status list credentials (decentralized approaches using cryptographic accumulators).
For XRPL-based implementations, revocation can leverage the ledger's native capabilities. Issuers can maintain revocation registries on-ledger, providing a decentralized and tamper-evident record of credential status. This approach offers stronger guarantees than web-based revocation lists, which can be manipulated or become unavailable.
Credential updates require careful consideration of the relationship between credentials and their subjects. Unlike mutable database records, credentials are immutable cryptographic artifacts. Updates typically require issuing new credentials and revoking old ones, though some advanced cryptographic techniques allow for updatable credentials with zero-knowledge proofs.
Selective Disclosure and Privacy
One of the most significant advantages of verifiable credentials over traditional credentials is support for selective disclosure -- the ability to reveal only specific claims from a credential without revealing the entire credential content. This capability is essential for privacy-preserving identity systems.
Selective Disclosure Approaches
Basic selective disclosure
- Separate, independently signed claims
- Example: separate signatures for name, age, address
- Allows proving age without revealing name or address
Advanced selective disclosure
- Uses BBS+ signatures or zero-knowledge proofs
- Fine-grained control over information revelation
- Can prove predicates ("I am over 21") without revealing data
The privacy implications are profound. Traditional identity systems require holders to reveal more information than necessary -- showing a driver's license to prove age reveals name, address, and license number. Selective disclosure enables minimal disclosure, revealing only the information required for the specific interaction.
The Correlation Problem
While selective disclosure solves the over-disclosure problem, it introduces a new challenge: correlation. If the same credential is used across multiple contexts, verifiers can potentially link these interactions to build profiles of holder behavior. Advanced privacy-preserving techniques like unlinkable presentations and credential splitting address this challenge, but they require careful implementation and user education to be effective.
Identity wallets serve as the user-facing component of decentralized identity systems, managing DIDs, private keys, and credentials on behalf of users. The architecture and security model of these wallets fundamentally determines the usability and security of the entire identity system.
Wallet Architecture Patterns
Custodial wallets
- Manage private keys on behalf of users
- Familiar user experiences like password managers
- Reintroduces centralized control and single points of failure
Non-custodial wallets
- Users have direct control over private keys and credentials
- Maximizes self-sovereignty
- Places full burden of key management on users
Hybrid approaches
- Multi-party computation (MPC) or threshold signatures
- Keys split between user and service provider
- Neither party has unilateral control
The wallet architecture choice has implications beyond just key management. Custodial wallets can implement sophisticated privacy features like credential mixing and unlinkable presentations more easily, while non-custodial wallets provide stronger guarantees against surveillance and censorship.
Key Management and Recovery
Key management represents the most critical security challenge in decentralized identity systems. Unlike traditional systems where forgotten passwords can be reset by administrators, lost private keys in decentralized systems typically mean permanent loss of access to the associated identity and credentials.
- **Deterministic key generation** using standards like BIP-32 allows wallets to generate multiple keys from a single seed phrase
- **Social recovery** mechanisms allow users to designate trusted contacts who can help recover access through threshold schemes
- **Hardware security modules (HSMs)** provide stronger protection by ensuring keys never exist in plaintext outside secure hardware
For XRPL-based identity wallets, the ledger's native multi-signing capabilities can be leveraged to create sophisticated key management schemes. A DID can be controlled by multiple keys with different weights, allowing for scenarios like daily operations keys (low weight) and recovery keys (high weight) that must be combined for sensitive operations.
Credential Storage and Management
Local storage
- Maximum privacy and availability
- Challenges for backup and device synchronization
- Recovery difficulties if devices are lost
Encrypted cloud storage
- Synchronization across devices with client-side encryption
- Key management challenges for encryption keys
- Additional backup and recovery complexity
Distributed storage
- Censorship-resistant using IPFS or decentralized networks
- Higher latency and complexity
- May not provide required availability guarantees
The storage architecture also affects credential presentation capabilities. Wallets with server-side components can implement sophisticated presentation policies and automated compliance checking, while purely client-side wallets must implement these features locally or rely on external services.
The Backup Paradox
Identity wallets face a fundamental paradox: the more secure the backup mechanism, the more complex it becomes for users. Simple backup approaches like cloud storage of encrypted credential files are vulnerable to password attacks. Complex approaches like social recovery or hardware-based backup are difficult for ordinary users to understand and execute correctly. This paradox is one of the primary barriers to widespread adoption of decentralized identity systems.
While the W3C standards provide technical interoperability, they do not address the governance and legal frameworks necessary for real-world deployment. Trust frameworks bridge this gap by defining the business, legal, and operational rules that govern how credentials are issued, verified, and trusted within specific ecosystems.
Governance Models and Structures
Centralized governance
- Single authority defines standards and policies
- Clear accountability and consistent standards
- Reintroduces centralization that decentralized identity aims to eliminate
Federated governance
- Multiple authorities cooperate on common standards
- Balances decentralization with coordination
- Requires ongoing cooperation between competing entities
Decentralized governance
- Blockchain-based voting or consensus mechanisms
- Maximizes decentralization
- Can be slow to adapt and difficult to coordinate
The governance model choice affects every aspect of the identity ecosystem, from technical standards to legal liability. Centralized models can move quickly and provide clear accountability, but they may not be acceptable to participants who prioritize decentralization. Decentralized models provide stronger censorship resistance and participant autonomy, but they may struggle to establish the consistent standards necessary for widespread interoperability.
Accreditation and Quality Assurance
Technical accreditation
Evaluates correct implementation of standards and security practices including key management and credential issuance processes
Operational accreditation
Evaluates business processes, staff qualifications, and operational controls including identity verification and incident response
Legal accreditation
Evaluates legal standing, liability coverage, and compliance programs including corporate structure and regulatory compliance
The accreditation framework must balance rigor with accessibility. Overly strict accreditation requirements may exclude legitimate issuers and limit ecosystem growth, while overly lax requirements may undermine trust and enable fraud.
Liability and Risk Management
Decentralized identity systems create new liability and risk management challenges that traditional identity systems handle through centralized authorities and insurance mechanisms. Trust frameworks must address these challenges to enable real-world deployment.
- **Issuer liability** covers risks from incorrect or fraudulent credential issuance and may require insurance or bonding
- **Verifier liability** covers risks from accepting invalid credentials and requires clear verification procedures
- **Holder liability** covers risks from credential misuse while balancing holder rights with accountability
The liability framework must also address the technical risks inherent in decentralized systems, including key compromise, system failures, and protocol vulnerabilities. This may require new forms of insurance and risk management that are specifically designed for decentralized identity systems.
Governance as Competitive Advantage Organizations that successfully establish trust frameworks and governance models for decentralized identity will have significant competitive advantages. These frameworks create network effects -- the more participants that adopt a particular governance model, the more valuable it becomes. Early movers that establish credible, balanced governance frameworks may be able to capture significant value as ecosystem coordinators, even in decentralized systems.
What's Proven
Technical Foundation
- W3C standards provide technical interoperability across multiple implementations
- Cryptographic verification eliminates trust dependencies through mathematical proof
- Method diversity enables ecosystem adaptation for different use cases
- Selective disclosure provides meaningful privacy benefits with BBS+ signatures and zero-knowledge proofs
What's Uncertain
**User adoption and usability at scale** -- While technical demonstrations are successful, large-scale user adoption remains uncertain. Key management complexity may limit adoption to technical users (60% probability that mainstream adoption requires significant simplification). **Regulatory acceptance** -- Many jurisdictions lack clear legal frameworks (40% probability of regulatory clarity within 2 years). **Governance sustainability** -- Long-term viability of decentralized governance models remains unproven (50% probability of hybrid models emerging as dominant). **Trust framework interoperability** -- Business and legal interoperability across frameworks is uncertain (70% probability of persistent fragmentation).
What's Risky
**Key management complexity** creates security vulnerabilities through poor user practices. **Privacy vs. compliance conflicts** may arise between advanced privacy features and regulatory requirements. **Governance capture** by powerful actors could undermine decentralization benefits. **Implementation complexity** may lead to security vulnerabilities in production systems due to sophisticated cryptography requirements.
The Honest Bottom Line
The W3C standards provide a solid technical foundation for decentralized identity, but significant challenges remain in usability, governance, and real-world deployment. Success will require not just technical excellence but also careful attention to user experience, regulatory compliance, and ecosystem coordination. The technology is ready for specialized applications and pilot programs, but mainstream adoption will require additional innovation in key management, governance models, and integration with existing systems.
Assignment: Design a comprehensive technical specification for a decentralized identity-based authentication system for a specific use case of your choosing (e.g., university credentials, professional certifications, supply chain verification, or healthcare records).
Requirements
System Architecture (40%)
Define overall architecture including DID method selection, wallet architecture, credential schemas, and trust framework. Justify choices based on trade-offs. Include diagrams showing relationships between issuers, holders, verifiers, and governance entities.
Technical Implementation Details (35%)
Specify technical details including DID document structure, verifiable credential schemas, presentation protocols, and revocation mechanisms. Include example JSON-LD documents and cryptographic specifications. Address key management, backup, and recovery procedures.
Governance and Risk Analysis (25%)
Define governance model, accreditation requirements, liability framework, and risk mitigation strategies. Address regulatory compliance and privacy considerations. Include analysis of potential failure modes and mitigation strategies.
Value: This specification will serve as a foundation for understanding how W3C standards translate into real-world systems and will be referenced in later lessons on XRPL-specific implementations.
Question 1: DID Architecture
A university wants to issue verifiable credentials for degrees using a DID-based system. They are considering between did:web and did:xrpl methods for their issuer DID. Which factor most strongly favors the did:xrpl method?
A) Lower implementation complexity and familiar web infrastructure
B) No transaction costs for DID operations and credential issuance
C) Stronger decentralization and censorship resistance for long-term credential validity
D) Better integration with existing university IT systems and databases
Correct Answer: C
While did:web offers lower complexity and costs (A, B), and potentially better integration (D), did:xrpl provides stronger guarantees about long-term availability and decentralization. For university credentials that may need to be verified decades after issuance, the censorship resistance and decentralized nature of ledger-based DIDs is crucial. Web-based DIDs depend on continued domain ownership and hosting, which may not be sustainable over academic timescales.
Question 2: Verifiable Credentials
A verifiable credential contains a proof section with a digital signature. What does successful verification of this signature guarantee about the credential?
A) The credential subject's identity has been verified by a trusted authority
B) The credential content is accurate and reflects the true state of the world
C) The credential was issued by the entity identified in the issuer field and has not been tampered with
D) The credential is currently valid and has not been revoked by the issuer
Correct Answer: C
Digital signature verification only guarantees cryptographic integrity -- that the credential was signed by the holder of the private key corresponding to the issuer's public key and that the content hasn't been altered since signing. It does not guarantee the accuracy of the claims (B), the verification of the subject's identity (A), or the current revocation status (D). These require additional verification steps beyond cryptographic signature checking.
Question 3: Identity Wallets
An enterprise is evaluating identity wallet architectures for their employees. They need to balance security, usability, and compliance with corporate audit requirements. Which approach best meets these requirements?
A) Fully custodial wallets managed by the enterprise IT department
B) Fully non-custodial wallets with employee-controlled private keys
C) Hybrid wallets using multi-party computation with split key control
D) Hardware security modules with centralized key backup
Correct Answer: C
Hybrid wallets using MPC provide the best balance for enterprise requirements. Fully custodial (A) provides good audit trails but eliminates employee autonomy and creates single points of failure. Fully non-custodial (B) maximizes security and autonomy but creates compliance and audit challenges. HSMs with central backup (D) provide good security but don't address the autonomy vs. control balance. MPC allows shared control that meets audit requirements while preserving some degree of employee autonomy.
Question 4: Trust Frameworks
A trust framework is being designed for professional certification credentials. Which governance model would be most appropriate for ensuring both credibility and broad adoption?
A) Centralized governance by the largest professional association in the field
B) Decentralized governance using blockchain-based voting by all credential holders
C) Federated governance involving multiple professional associations and educational institutions
D) No formal governance, relying on market forces and reputation mechanisms
Correct Answer: C
Federated governance (C) balances credibility with inclusivity by involving multiple legitimate stakeholders. Centralized governance (A) might exclude competing organizations and limit adoption. Decentralized voting (B) may lack the expertise and accountability needed for professional standards. No governance (D) would undermine the credibility needed for professional certifications. Federated models allow for shared standards while respecting the autonomy of different professional bodies.
Question 5: System Integration
When integrating W3C DID and VC standards with existing enterprise systems, which technical consideration is most critical for long-term success?
A) Choosing the DID method with the lowest transaction costs
B) Implementing the most advanced privacy-preserving features available
C) Ensuring credential schemas align with existing data models and business processes
D) Selecting wallets with the most sophisticated user interface designs
Correct Answer: C
Schema alignment with existing systems (C) is most critical for long-term success because it determines how well the decentralized identity system integrates with existing business processes and data flows. While costs (A), privacy (B), and UX (D) are important, they can be optimized over time. Misaligned schemas create fundamental integration challenges that become more difficult to fix as the system scales and more stakeholders depend on it.
- **W3C Standards:**
- - [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/did-core/) - Core specification
- - [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/) - Credential specification
- - [DID Specification Registries](https://www.w3.org/TR/did-spec-registries/) - Method registry
- **Technical Implementation:**
- - [Universal DID Resolver](https://github.com/decentralized-identity/universal-resolver) - Multi-method resolver
- - [Verifiable Credentials API](https://www.w3.org/TR/vc-api/) - HTTP API specification
- - [Presentation Exchange](https://identity.foundation/presentation-exchange/) - Credential request protocol
- **Privacy and Security:**
- - [BBS+ Signature Scheme](https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html) - Selective disclosure
- - [Confidential Storage](https://identity.foundation/confidential-storage/) - Encrypted storage specification
- **Governance and Trust:**
- - [Sovrin Governance Framework](https://sovrin.org/library/sovrin-governance-framework/) - Example trust framework
- - [Trust over IP Foundation](https://trustoverip.org/) - Governance model research
Next Lesson Preview Lesson 3 will explore XRPL-specific implementations of these W3C standards, including the did:xrpl method specification, on-ledger credential registries, and integration with XRPL's native account and transaction systems. You will learn how XRPL's unique features like deterministic transaction ordering and low fees create advantages for decentralized identity applications.
Knowledge Check
Knowledge Check
Question 1 of 1A university wants to issue verifiable credentials for degrees using a DID-based system. They are considering between did:web and did:xrpl methods for their issuer DID. Which factor most strongly favors the did:xrpl method?
Key Takeaways
W3C DID architecture enables globally unique identifiers without centralized authorities through method-agnostic identifiers and method-specific resolution
Verifiable credentials transform trust from institutional to mathematical by using cryptographic proofs instead of institutional vouching
Identity wallet architecture determines the practical security and usability of the entire system through key management and credential storage decisions