Decentralized Identity and Verifiable Credentials: The Enterprise Playbook 2026
A patient walks into a new hospital. At the front desk, they are asked to fill in their insurance details, their medication list, their allergies, their emergency contacts, and their primary care physician.
Decentralized Identity and Verifiable Credentials: The Enterprise Playbook 2026
A patient walks into a new hospital. At the front desk, they are asked to fill in their insurance details, their medication list, their allergies, their emergency contacts, and their primary care physician. They have filled in exactly the same form at six different providers in the last three years. Every provider stores a copy. Every provider’s database is a breach target. None of the copies are guaranteed to be current.
With verifiable credentials, the patient’s digital wallet contains a cryptographically signed insurance credential issued by their insurer, a medication summary signed by their primary physician, and an allergy record issued by their previous hospital. The new provider scans a QR code. In four seconds, they have instant, mathematically verified access to accurate, current information. No forms. No faxes. No manual re-entry. No duplicate databases. No breach risk from data that was never stored.
This is not a 2030 roadmap item. The European Union’s eIDAS 2.0 regulation requires every EU member state to provide at least one European Digital Identity Wallet to citizens and businesses by the end of 2026. Public and private services in the EU are legally required to accept the EUDI Wallet for authentication from 2027. The decentralized identity market was valued between $2.56 billion and $4.89 billion in 2025 and is projected to reach $7.4 billion in 2026 at a CAGR that exceeds 50% through the decade.
Organizations serving EU markets that have not started their eIDAS 2.0 assessment are already late. Organizations everywhere that are still running centralized identity databases should understand what they are migrating toward.
This guide covers the architecture of decentralized identity, how verifiable credentials actually work, what eIDAS 2.0 requires and when, which enterprise use cases are live today with proven ROI, and how to build a practical adoption roadmap without treating it as an overnight replacement of existing infrastructure.
The Problem with Centralized Identity: Three Structural Failures
Before explaining how decentralized identity solves the problem, it is worth being precise about the problem itself. Centralized identity has three structural failure modes that decentralized identity is specifically designed to address.
Failure Mode 1: The Honeypot Database Problem
Every organization that collects and stores identity data becomes a breach target. The value to attackers is proportional to the volume and sensitivity of the data. Large centralized identity databases represent decades of accumulated personal data, breach credentials, and relationship metadata that criminals and nation-state actors find valuable. There are currently over 24 billion compromised credential pairs circulating on dark web markets, representing years of database breaches from centralized identity systems.
The centralized model asks: “How do we secure the database?” Decentralized identity eliminates the question by eliminating the database. If each individual holds their own credentials in a personal wallet and organizations store only mathematical proof that a credential was valid at a particular moment, there is no central database to breach.
Failure Mode 2: The Repeated Verification Problem
The average person completes the same Know Your Customer (KYC) verification process at multiple financial institutions, healthcare providers, government agencies, and employers over their lifetime. Each verification is redundant – the same documents, the same identity questions, the same biometric capture – and each creates another stored copy of sensitive data.
The World Bank estimates that organizations adopting reusable verifiable credentials for KYC see onboarding cost reductions of 30-50% compared to document-scan-based verification. Mordor Intelligence research puts the repeat verification cost reduction at up to 60%. The operational efficiency argument alone – before considering security improvements – justifies investment in verifiable credential infrastructure.
Failure Mode 3: The User Control Problem
In the current model, individuals have virtually no visibility into where their identity data is stored, how it is used, or when it is shared. A user who registered with a platform in 2019 has no practical way to know whether that platform still holds their data, has sold it to data brokers, or has had it breached without disclosure. The Right to Erasure under GDPR exists in theory; enforcement and effective implementation are inconsistent.
Decentralized identity inverts this: the user holds their credentials. They decide what to share, with whom, for what purpose, and for how long. The verifier receives only the minimum data necessary – often a mathematical proof of a fact without the underlying data at all. This is not just a privacy philosophy; it is a compliance architecture that substantially simplifies GDPR and CCPA compliance for organizations that no longer need to store personal data they once did.
How Decentralized Identity Actually Works
Definition: Decentralized identity is a model where individuals control their own identity credentials in a personal digital wallet, rather than having identity data stored and managed by third-party institutions. Credentials are cryptographically signed by issuing authorities, held by the credential subject, and verified by relying parties through mathematical proof – without requiring contact with the original issuer or storing the data centrally.
The Three-Party Trust Model
Decentralized identity operates through a triangle of relationships between three parties. Understanding these roles is essential before any technical or architectural discussion.
The Issuer is an entity that verifies information and issues a credential certifying that verification. Government agencies issue identity credentials (driver’s licenses, passports, national ID). Employers issue employment credentials certifying role, tenure, and status. Banks issue KYC verification credentials certifying that a customer passed identity verification. Universities issue degree credentials certifying academic achievement. Professional bodies issue certification credentials. Hospitals issue vaccination and medical record credentials.
The issuer is the trust anchor. Their cryptographic signature on a credential is the basis for any verifier’s trust. This means issuers must be known, have published public keys, and operate within recognized trust frameworks.
The Holder is the individual (or organization) that receives credentials from issuers and stores them in a digital wallet. The holder decides when, with whom, and in what form to share their credentials. Selective disclosure means the holder can share only the specific attributes needed for a particular verification – proving age eligibility without revealing the exact birthdate, or proving employment without revealing salary.
The Verifier is a party that needs to confirm a claim. When a user presents a credential, the verifier checks the cryptographic signature against the issuer’s public key (published to a trust registry), confirms the credential has not been revoked, and confirms the credential meets the requirements for the specific interaction. Verification is mathematical – it does not require calling the issuer, does not require accessing a central database, and does not require the holder to transmit any data beyond what is being actively presented.
This three-party model replaces the current model where the verifier calls the issuer directly (the user fills out a form, the bank calls the employer to verify employment). The new model: the issuer signs once, the holder stores and presents as needed, the verifier checks the signature. One issuance event supports unlimited verification events.
The Core Technologies
Verifiable Credentials (W3C VC): The W3C Verifiable Credentials Data Model defines the standard structure for digital credentials. A Verifiable Credential is a tamper-proof digital document containing: the issuer’s identity (as a DID), the credential subject (the holder), the specific claims being made (attributes or facts), validity dates, and the issuer’s cryptographic signature. The signature makes the credential tamper-evident: any change to the credential after issuance produces a signature mismatch that any verifier can detect.
Decentralized Identifiers (DIDs): A DID is a globally unique identifier controlled by the holder rather than any central authority. DIDs are typically stored on a distributed ledger (blockchain) to ensure they cannot be deleted or modified by any single party. Critically, a DID contains no personal data – it is a pointer to a DID document that describes the DID subject’s public keys and authentication methods. The separation of identity (the DID) from personal data (the credentials) is architecturally important: the DID itself, even if discovered, reveals nothing about the person.
Digital Identity Wallets: A wallet is the holder’s software interface for managing credentials and DIDs. Wallets can be mobile-app-based (the EU’s EUDI Wallet model, Apple Wallet evolving to support verifiable credentials) or cloud-based for enterprise use cases. A modern digital identity wallet stores multiple credential types, handles cryptographic operations for credential presentation, supports selective disclosure, and manages the private keys associated with the holder’s DIDs.
Zero-Knowledge Proofs (ZKPs): Perhaps the most powerful privacy-preserving technology in the decentralized identity stack. A zero-knowledge proof allows the holder to prove a specific fact without revealing the data underlying that fact. Classic example: prove that you are over 18 without revealing your date of birth. The verifier receives a cryptographic proof that the claim is true without receiving the actual attribute value. For regulated industries where data minimization is both a privacy preference and a compliance requirement, ZKPs enable identity verification that collects genuinely the minimum necessary data.
The ZKP sector reached $28 billion in total value locked in 2025, with the ZKP market projected at $7.59 billion by 2033 growing at 22.1% CAGR. This reflects both the blockchain-native ZKP ecosystem and the growing enterprise adoption of ZKP-based identity verification.
eIDAS 2.0 and the EUDI Wallet: The Regulatory Deadline Organizations Cannot Ignore
eIDAS 2.0 is the most consequential regulatory development in digital identity in a decade. It is not a proposed framework or a voluntary standard – it is binding EU law that entered into force in May 2024 and carries mandatory deadlines.
Key eIDAS 2.0 requirement: By the end of 2026, every EU member state must provide at least one European Digital Identity Wallet (EUDI Wallet) to its citizens and businesses. From 2027, regulated private sectors including banking, telecommunications, healthcare, education, and very large online platforms must accept the EUDI Wallet for authentication alongside existing methods.
What the EUDI Wallet Enables
The European Digital Identity Wallet is a state-issued mobile application that allows EU citizens and residents to:
Store and present government-recognized identity documents (national ID, driver’s license, passport)
Present educational credentials, professional certifications, and other verifiable credentials
Authenticate to online services (private and public) using their wallet-based identity
Sign documents electronically with legally recognized qualified electronic signatures
Exercise selective disclosure: share only the specific attributes required for each interaction
The wallet is built on W3C Verifiable Credentials, Decentralized Identifiers, and OpenID for Verifiable Credentials (OpenID4VC). This standards alignment means that organizations building EUDI Wallet integration are building on the same technical stack that governs the global decentralized identity ecosystem – not a proprietary EU-only standard.
Who Must Act and When
For organizations already operating in the EU: Banks, insurance companies, telecom operators, healthcare providers, and very large online platforms (those with over 45 million monthly active users in the EU) must accept EUDI Wallet-based authentication from 2027. The infrastructure and integration work needed to accept wallet presentations takes 12-18 months for organizations starting from scratch. Organizations that have not started technical assessment should start immediately.
For public authorities: National governments and public services must issue attributes from authentic public sources (civil registries, tax IDs, social security numbers, professional licenses) in wallet-verifiable form. Public services must accept wallet-based identity as soon as national wallets are deployed.
For organizations outside the EU serving EU users: Any online service with significant EU user bases that is subject to eIDAS 2.0 “very large online platform” thresholds (45 million+ monthly active EU users) must accept EUDI Wallet authentication. Multinational organizations should assess their EU traffic against these thresholds now.
The eIDAS 2.0 Compliance Technical Checklist
For organizations building eIDAS 2.0 compliance:
W3C VC Data Model 2.0 compliance for credential issuance and verification
OpenID for Verifiable Credentials (OpenID4VC) support for wallet interoperability within existing OAuth/OIDC authentication flows
Integration with the EUDI Trust Framework (published by the European Commission) for issuer and verifier registration
ISO/IEC 18013-5 support for mobile driver’s license (mDL) verification where applicable
Privacy-preserving disclosure capabilities to avoid collecting data beyond what is required
Entrust CIAM, referenced in the top 5 enterprise CIAM platforms 2026 comparison, already supports W3C Verifiable Credentials, OID4VC for decentralized identities, and multiple trust frameworks including EBSI, Sovrin, Hyperledger Indy/Aries, and BC VON.
Enterprise Use Cases with Proven ROI Today
The most common misconception about decentralized identity is that it is a future-state architecture with no current practical applications. Several use cases are generating measurable returns today.
Reusable KYC: Issue Once, Verify Many Times
The financial services use case is the clearest illustration of compounding value. A bank completes KYC verification on a customer: verifies their government ID, confirms their address, assesses their risk profile. In the traditional model, this verification is locked in the bank’s system. When the customer opens a brokerage account with the same bank’s subsidiary, they go through KYC again. When they apply for a mortgage elsewhere, they go through KYC again.
With verifiable credentials: the bank issues a KYC verification credential to the customer’s wallet. The credential certifies that KYC was completed, at what assurance level, and with what result (without revealing the underlying personal data). When the customer needs to verify their identity elsewhere, they present the credential. The new institution verifies the bank’s signature and accepts the credential in lieu of a fresh KYC process.
The 60% reduction in repeat verification costs (Mordor Intelligence) reflects both the direct cost of the verification process and the operational overhead of managing duplicate identity records across the organization’s systems.
Revocation is supported: if a bank’s KYC credential is invalidated (the customer’s identity was later found to be fraudulent), the bank can revoke the credential and any verifier that checks revocation status will know the credential is no longer valid.
Employment and Credential Verification
This use case is gaining significant traction in regulated industries where verifying credentials is both critical and operationally burdensome.
Right-to-work verification: An employer issues an employment credential to an employee’s wallet certifying their employment status, right-to-work status, and any required certifications. When the employee changes jobs, the new employer can verify the credential instantly without reference calls, without contacting HR departments, and without manual document review.
Professional certification: A regulatory body issues a medical license credential, a legal bar admission credential, or an engineering certification to the professional’s wallet. Any organization that needs to verify the credential checks the regulatory body’s signature – instantaneous, authoritative, and current (revocation is propagated automatically when a license lapses or is suspended).
Academic credentials: Universities issuing degree credentials as verifiable credentials eliminate credential fraud (fake degree certificates cannot be created without the university’s cryptographic signature) and dramatically reduce the time required for academic background verification in hiring.
Trinsic predicts that mobile driver’s licenses (mDL, standardized under ISO/IEC 18013-5) will gain widespread adoption in 2026, particularly in the US and Australia. The US states that have already issued digital IDs in Apple Wallet are operating on the mDL framework, providing the practical infrastructure for expanding use.
Marketplace and Platform Trust
For two-sided marketplaces – platforms that need to verify both sides of a transaction – verifiable credentials provide a scalable verification architecture.
A gig economy platform needs to verify driver’s licenses, vehicle registrations, background check results, and insurance coverage for drivers. Each verification has traditionally required direct API calls to government databases, background check services, and insurance carriers, with the platform storing copies of all results.
With verifiable credentials: the driver assembles their credentials (license issued by DMV, vehicle registration issued by motor authority, background check issued by screening service, insurance certificate issued by insurer) in their wallet. The platform verifies the complete credential stack in a single presentation. Verification is instantaneous. No copies are stored by the platform.
Revocation handles the dynamic aspects: when a driver’s license is suspended, the DMV revokes the credential and the platform’s next verification check reflects the suspension. This is more current and reliable than the platform re-checking periodically against its stored copy.
AI Agent Identity: The Emerging Frontier
This use case is not yet in production at scale but warrants attention given the direction the AI industry is moving. As AI agents take on autonomous roles in business workflows – booking meetings, executing transactions, accessing data systems on behalf of principals – the question of agent identity becomes urgent.
How does a system know that an AI agent has authorization to perform a specific action on behalf of a specific human? How is that authorization scoped and bounded? How is it revoked when the agent’s task is complete or the authorization expires?
Decentralized identity and zero-knowledge proofs are being explored as the technical foundation for AI agent credential delegation: a human issues a scoped authorization credential to an AI agent’s DID, specifying exactly what the agent is authorized to do, for how long, and within what constraints. The agent presents this credential when requesting access to systems. Verifiers can confirm the authorization is valid and current without contacting the human principal for every action.
This use case will become critical as AI agent deployment in enterprise workflows accelerates. Organizations building AI agent infrastructure now should design for credential-based authorization rather than API key or OAuth token-based authorization, which lacks the revocation granularity that agent supervision requires.
Self-Sovereign Identity vs. Federated Identity vs. Centralized Identity
Understanding where decentralized identity fits relative to existing identity models helps enterprise architects understand what they are actually changing in their infrastructure.
Dimension
Centralized Identity
Federated Identity (OAuth/OIDC/SAML)
Self-Sovereign / Decentralized Identity
Who controls the data
The platform or institution
The Identity Provider (Google, Microsoft, Okta)
The credential holder
Breach risk
High – central database
Concentrated at IdP
Distributed – no central store
User portability
Locked to platform
Portable within federation
Fully portable, user-controlled
Privacy
Minimal user control
Better, but IdP sees everything
Maximum – selective disclosure possible
Implementation maturity
Fully mature
Fully mature
Maturing – standards stable, tooling growing
Cross-organization trust
Manual or custom integration
Within established federation
Standards-based, trustless verification
Revocation
Platform-controlled
IdP-controlled
Issuer-controlled, instant propagation
The key insight for enterprise architects: decentralized identity does not require replacing federated identity (OAuth/OIDC) for internal applications. The most pragmatic deployment model overlays a verifiable credential rail alongside existing OAuth/SAML flows for specific use cases (external KYC, partner access, regulated credential verification) rather than attempting a wholesale replacement.
Large enterprises captured 67% of the decentralized identity market revenue in 2025, and the dominant pattern is exactly this: weaving DIDs into existing IAM stacks, adding verifiable credential capabilities to specific workflows while maintaining OAuth/SAML for internal access management.
Enterprise Implementation Roadmap
Why Starting with Full Replacement is Wrong
The most common enterprise mistake with decentralized identity is scoping the initial deployment as a complete identity system replacement. This creates a project that is too complex to deliver, takes too long to show value, and generates organizational resistance from teams with existing IAM investments.
The right approach: start with one high-value use case where verifiable credentials provide clear, measurable value that existing infrastructure cannot easily replicate. Deliver that use case, demonstrate ROI, and expand from there.
Choosing Your First Use Case
The selection criteria for a good first use case:
High current cost or friction from repeated verification or manual credential checking
Clear, measurable metric that improves (onboarding time, KYC cost, credential fraud rate)
A willing issuer partner whose credentials you can accept (government agencies, established professional bodies, your own organization as issuer)
A bounded scope that does not require replacing existing authentication infrastructure
High-ROI first use cases by vertical:
Financial services: Reusable KYC for customer onboarding from affiliated institutions or third-party KYC providers. Measure: time-to-onboard, KYC operational cost per customer.
Healthcare: Patient insurance credential verification at point of care. Measure: intake form completion time, duplicate data entry error rate, administrative processing time.
Technology companies: Employee credential verification for partner and contractor access. Measure: onboarding time for new contractors, access provisioning error rate.
Marketplaces: Driver/seller credential verification (license, certifications, background checks). Measure: verification completion time, manual review escalation rate.
Regulated industries: Right-to-work and professional certification verification in hiring. Measure: background check completion time, credential fraud detection rate.
Phase 1: Standards Assessment and Architecture (Months 1-3)
Before writing any code: assess which decentralized identity standards your use case requires and confirm that your technology choices are compatible.
Key standards to assess: W3C VC Data Model (credential structure), DID Core Specification (identifier format), OpenID4VC (wallet interoperability), ISO/IEC 18013-5 (if mDL is in scope), EUDI Trust Framework (if EU compliance is required).
Identify your trust anchor: for your first use case, which issuer’s credentials are you accepting? Confirm they have or are building a credential issuance capability and that their DID is published to a recognizable trust registry.
Phase 2: Technology Selection (Months 2-4)
Options for building your verifiable credential infrastructure:
Enterprise CIAM platforms with VC support: Entrust CIAM supports W3C VC and OID4VC with no-code/low-code integration into existing authentication flows. This is the lowest-friction path for organizations with an existing enterprise CIAM deployment.
Specialized decentralized identity platforms: Indicio Proven supports multiple credential types and protocols (mDL, Digital Travel Credentials, EU credential standards) with standards-based interoperability. Dock.io provides verifiable credential issuance and verification with blockchain anchoring.
Build with open-source libraries: Hyperledger AnonCreds, Spruce DIDKit, Microsoft’s Entra Verified ID – open-source and Microsoft-native options for organizations with development capacity to build custom integrations.
For most enterprises, the path of least resistance is extending an existing CIAM platform rather than building a standalone decentralized identity stack. Evaluate your current CIAM platform’s VC roadmap before committing to a greenfield decentralized identity implementation.
Phase 3: Pilot Deployment (Months 4-9)
Run a bounded pilot with your first use case:
Deploy credential issuance for your selected credential type (either accepting third-party credentials or issuing your own)
Integrate credential verification into the specific workflow you selected
Measure the metrics you defined at the start
Test revocation flows: revoke a test credential and verify that the revocation propagates correctly within your SLA requirements
Critical: test the user experience. Credential presentation using a digital wallet must be as frictionless as the processes it replaces, or adoption will fail regardless of the security and efficiency benefits. User experience testing with actual users in your target segment is non-negotiable.
Phase 4: Production and Expansion (Months 9+)
After pilot validation, production deployment and monitoring. Expansion decisions:
Which additional credential types can be accepted (extending the trust ecosystem)
Which additional workflows benefit from credential-based verification
Whether the organization should issue its own verifiable credentials for attributes it currently verifies and certifies (professional certifications, KYC results, employment credentials)
The expansion dynamic is powerful: as the organization both issues and accepts verifiable credentials, it becomes a node in the trust network with compounding value on both sides.
Privacy-Preserving Verification with Zero-Knowledge Proofs
ZKPs deserve a section of their own because they represent the most significant privacy advance in verifiable credential architecture – and the one most commonly omitted in enterprise implementations that do not have dedicated cryptography expertise.
The core capability: prove a statement is true without revealing the data underlying the statement. The verifier learns that the claim is valid; they learn nothing about the actual attribute value.
Age verification without birthdate: A liquor retailer needs to confirm a customer is over 21. With a ZKP-based credential: the user’s wallet generates a proof that their credential contains a birthdate that satisfies the age requirement. The retailer’s verifier receives: a proof that the user is over 21, and nothing else. No birthdate. No name. No other credential contents.
Income above a threshold without revealing income: A lender needs to confirm an applicant’s income exceeds a minimum for loan eligibility. ZKP: the applicant proves their income credential satisfies the threshold without revealing the actual income figure.
Employment status without revealing employer: A background check service needs to confirm current employment. ZKP: the applicant proves they have a current employment credential without revealing the employer’s name. Depending on the specific verification requirement, this may be sufficient for the verifier’s compliance need.
Credential validity without revealing credential contents: In some verification scenarios, the verifier only needs to know that the holder has a valid credential from a recognized issuer in a certain category. ZKP: prove you have a valid professional certification from an approved certification body without revealing which certification or from which body.
For GDPR compliance, ZKP-based verification is extremely powerful. Organizations can confirm eligibility, verify attributes, and meet Know Your Customer requirements while collecting genuinely the minimum data possible – in some cases, zero personal data beyond the mathematical proof.
Frequently Asked Questions
Does decentralized identity require blockchain?
Not necessarily. Some decentralized identity systems use distributed ledgers to publish and manage DID documents and revocation registries – the public key infrastructure that enables trustless verification. Others use traditional web servers with signed files, or enterprise registries. The critical requirement is that the issuer’s public key is publicly verifiable and the revocation status is queryable. Blockchain is one mechanism for achieving this; it is not mandatory.
What is the difference between a DID and a username?
A username is an identifier assigned and controlled by a specific platform. Your Gmail address is only meaningful as an identifier on Google’s platform. A DID is a globally unique identifier that you control, independent of any single platform. You create it, you hold the corresponding private key, and no platform can revoke or modify it. The DID points to a DID Document containing your public keys, which issuers and verifiers use to cryptographically interact with your wallet.
How does credential revocation work?
Issuers maintain a revocation registry – a publicly readable list of revoked credential identifiers. When an issuer revokes a credential (because the underlying fact changed, the credential was fraudulently obtained, or the credential expired), they update the revocation registry. When a verifier checks a presented credential, they query the revocation registry for the credential’s identifier. If it appears as revoked, the credential is rejected. This process happens in milliseconds and requires no contact between the verifier and the issuer beyond the registry query.
Is eIDAS 2.0 compliance required for non-EU organizations?
eIDAS 2.0 mandates apply to organizations providing services to EU citizens. The “very large online platform” threshold (45 million+ monthly active EU users) applies to global platforms. Beyond the threshold requirement, eIDAS 2.0 creates market pressure: EU users will increasingly expect services to accept EUDI Wallet credentials, and organizations that cannot accept them lose a segment of the EU market. Non-EU organizations serving significant EU user bases should assess compliance requirements with legal counsel.
How do verifiable credentials protect against deepfakes?
Verifiable credentials are protected by cryptographic signature, not by the biometric representation of the credential holder. A deepfake video can fool a facial recognition system, but it cannot forge the cryptographic signature of a government-issued credential. The combination of a verifiable credential (cryptographically proven authenticity) plus a liveness-detection biometric match (proving the presenter is physically present and alive) provides stronger combined assurance than either factor alone. This is why the convergence of decentralized credentials with AI-powered liveness detection represents the most robust identity verification architecture for high-stakes use cases.
What to Read Next
The decentralized identity space intersects with every other major identity and authentication trend. These resources from this series cover the adjacent technologies:
Deepak Gupta is the Co-founder and CEO of GrackerAI and an AI and Cybersecurity expert with 15+ years in digital identity and enterprise security. He scaled a CIAM platform to serve over one billion users globally. He writes about cybersecurity, AI, and B2B SaaS at guptadeepak.com.
*** This is a Security Bloggers Network syndicated blog from Deepak Gupta | AI & Cybersecurity Innovation Leader | Founder's Journey from Code to Scale authored by Deepak Gupta – Tech Entrepreneur, Cybersecurity Author. Read the original post at: https://guptadeepak.com/decentralized-identity-and-verifiable-credentials-the-enterprise-playbook-2026/
About Author
