Summary: Passwordless patient identity is now practical in healthcare by combining decentralized identifiers (DIDs), W3C Verifiable Credentials (VCs), OpenID for VC protocols, and passkeys. This guide shows decision‑makers how to design a compliant, production‑grade architecture that integrates FHIR, TEFCA, mDLs, and SMART Health Cards to eliminate passwords while improving security, privacy, and UX.

Blockchain healthcare app development with DID/VC: Secure Patient Identity Without Passwords

Healthcare finally has the standards, regulations, and vendor tooling to go passwordless. W3C’s Verifiable Credentials 2.0 became a Recommendation in May 2025; OpenID for Verifiable Presentations (OID4VP) 1.0 and OpenID for Verifiable Credential Issuance (OID4VCI) 1.0 are final; and NIST’s SP 800‑63‑4 recognizes subscriber‑controlled wallets and clarifies phishing‑resistant authentication with passkeys. TEFCA Common Agreement v2.0 adds FHIR API exchange, while ONC’s HTI‑1 sets SMART App Launch and USCDI v3 timelines. Together, these enable a DID/VC stack that removes passwords and meets U.S. healthcare compliance expectations. (w3.org)

What “production‑ready” means in late 2025

• W3C VC Data Model v2.0, Data Integrity 1.0, VC‑JOSE‑COSE, and Bitstring Status List v1.0 are Recommendations, providing stable data, proof, and revocation primitives. (w3.org)
• DID Core is a W3C Recommendation; did:web remains the pragmatic choice for enterprise issuer/verifier identities anchored in DNS. (w3.org)
• OpenID for Verifiable Presentations 1.0 is final for request/presentation flows; OpenID for Verifiable Credential Issuance 1.0 is final for issuance APIs. (openid.net)
• NIST SP 800‑63‑4 updates digital identity assurance, explicitly acknowledging wallets and adding phishing‑resistant options; the 2024 supplement clarifies that synced passkeys can meet AAL2 and device‑bound passkeys can meet AAL3. (pages.nist.gov)
• TEFCA CA v2.0 went live with FHIR API requirements; large networks (e.g., Epic footprint) are onboarding at scale. (techtarget.com)
• ONC HTI‑1 timelines: USCDI v3 baseline Jan 1, 2026; SMART App Launch v2 adoption; revised info blocking with a TEFCA‑friendly “manner” exception. (healthit.gov)

The core stack for passwordless patient identity

1. Identifiers and trust anchors

• Use DIDs for issuers/verifiers; start with did:web (backed by your domain & TLS) for operational simplicity and auditability; maintain a DID Document with verification methods (Ed25519/ECDSA) and service endpoints for OID4VCI/OID4VP. (w3c-ccg.github.io)

1. Credential formats and proofs

• Prefer W3C VC Data Model v2.0. For signatures, pick from:
  • VC Data Integrity with EdDSA/ECDSA cryptosuites (great for JSON‑LD ecosystems and ZK‑friendly evolution, e.g., BBS+).
  • VC‑JOSE‑COSE for JWT/COSE credentials and SD‑JWT selective disclosure when you want JOSE/COSE toolchains and compact tokens. (w3.org)

1. Protocols

• Issuance (wallet gets a credential): OID4VCI 1.0.
• Presentation (wallet proves to a relying party): OID4VP 1.0 with DIF Presentation Exchange v2 to express what you need, and only that. (openid.net)

1. Revocation/status

• Publish credential status with W3C Bitstring Status List v1.0 (space‑efficient, privacy‑preserving, high throughput). (w3.org)

1. Policy and trust lists

• Query authorized issuers/verifiers via Trust Over IP Trust Registry Query Protocol (TRQP) v2.0 to operationalize governance (e.g., “Is this NPI‑licensed facility authorized to issue a Prior‑Auth Approval VC?”). (trustoverip.org)

Architecture blueprint (reference for CTOs)

Below is a concrete end‑to‑end that we deploy at 7Block Labs for U.S. healthcare apps:

• Wallet and authenticator
  • Patient app uses a mobile wallet with platform key protection (Secure Enclave/Android Keystore) and passkeys for sign‑in, meeting NIST AAL2/AAL3 depending on configuration. Use hardware key attestation to verify keys are hardware‑backed. (nist.gov)
• Issuer(s)
  • Your EHR, payer, or telehealth system acts as a VC Issuer with OID4VCI endpoints:
    • .well‑known/openid‑credential‑issuer (metadata)
    • /oauth/token (OAuth 2.0)
    • /credential (VC issuance)
    • Supports pre‑authorized code flow where appropriate. (openid.net)
• Verifier(s)
  • Your app, portal, or API uses OID4VP to request minimal attributes via a Presentation Definition; receives vp_token + presentation_submission and verifies signature, holder binding, nonce, and status. (openid.net)
• FHIR integration
  • Map VCs to HL7 FHIR resources (R5 where available). For example, a “Patient Identity” VC references FHIR Patient; “Coverage” VC references FHIR Coverage; consent references FHIR Consent for policy rules. (hl7.org)
• Network and compliance
  • TEFCA connectivity via your chosen QHIN/participant; for API access, align with SMART App Launch v2 and USCDI v3 timelines. (techtarget.com)
• Status & trust
  • Maintain Bitstring Status List for suspension/revocation.
  • Use TRQP to check “authorized issuer” and ecosystem affiliations (e.g., pharmacy chain allowed to issue a Dispense VC). (w3.org)

Minimal data flows (protocol‑level specifics)

• OID4VCI issuance (pre‑authorized)

  • Wallet scans credential_offer; hits /oauth/token to exchange pre‑authorized_code for an access token; POSTs to /credential with a proof of possession (e.g., DPoP or holder binding key); receives VC (JWT/COSE or Data Integrity). (openid.net)

• OID4VP presentation

  • Verifier creates an authorization request including presentation_definition, nonce, and state; Wallet returns vp_token and presentation_submission with only fields required by the PD; Verifier checks signature, PD satisfaction, nonce, and status (Bitstring). (openid.net)

Practical healthcare examples you can launch in 90–180 days

1. Passwordless patient onboarding for telehealth

• Step 1: Patient signs in with a passkey (WebAuthn) instead of a password; AAL2 achieved (synced) or AAL3 (device‑bound). (nist.gov)
• Step 2: The payer portal (Issuer) issues a “Coverage VC” via OID4VCI; the telehealth app (Verifier) requests proof of active coverage + age ≥ 18 via OID4VP with Presentation Exchange predicates (disclose date‑of‑birth only if necessary). (openid.net)
• Step 3: Consent is asserted using a FHIR Consent resource bound to a “Consent VC,” allowing purpose‑limited sharing to the telehealth provider for treatment for 24 hours. (hl7.org)

1. EPCS identity compliance for prescribers (DEA 21 CFR Part 1311)

• Prescriber authenticates with two factors (e.g., passkey + biometric on device) to meet DEA’s 2FA requirement for signing; the app enforces logical access controls and audit trails required in Part 1311.120/.140. DID/VC handles identity claims; the signature ceremony uses platform authenticators and audited workflows. (law.cornell.edu)

1. Prior authorization proofing across TEFCA

• Plan issues a “Prior Authorization Approval VC” with a Bitstring Status List entry; provider EHR presents it to a downstream facility via OID4VP; the facility checks status and the issuer’s authorization in a trust registry (e.g., “Is this plan authorized to issue PA approvals in this network?”). (w3.org)

1. Specialty pharmacy age and identity with mDL + VCs

• Accept ISO/IEC 18013‑5/‑7 mDLs for identity/age; combine with Coverage VC for eligibility. TSA’s acceptance of state mDLs at airports illustrates real‑world verifier workflows and reader infrastructure in the U.S. (verify against TSA’s accepted list; do not store mDL data beyond verification). (tsa.gov)

1. Vaccination records with SMART Health Cards (SHC)

• Many issuers publish keys in the VCI Directory; verifiers validate signatures and minimize retention. SHCs can coexist with W3C VCs in wallets and be bridged via OID4VP request objects. (spec.smarthealth.cards)

Best emerging practices (what we recommend now)

• Prefer VC‑JOSE‑COSE or EdDSA Data Integrity depending on your stack; both are W3C‑recommended paths, and either integrates cleanly with OID4VCI/OID4VP. (w3.org)
• Use Presentation Exchange v2 with explicit “statuses” constraints so verifiers require the credential to be active and disallow suspended/revoked. (identity.foundation)
• Enforce holder binding (key‑bound credentials) and replay protection (nonce/state) in OID4VP; reject self‑attested identifiers for clinical risk flows. (openid.net)
• Adopt Bitstring Status List v1.0 for scalable revocation; publish lists over HTTPS with caching and ETags. (w3.org)
• Hardware‑backed keys and attestation in wallets: verify Android Key Attestation chains and use iOS Secure Enclave; fail closed for missing hardware attestation in high‑risk flows. (developer.android.com)
• Trust registries for ecosystem governance: integrate TRQP to check issuer/verifier authorizations programmatically; include registry provenance in your audit logs. (trustoverip.org)
• Minimize data: prefer selective disclosure (e.g., SD‑JWT VC) for demographics; only adopt once your verifier libraries support the latest drafts operationally. (ietf.org)

Compliance map for U.S. healthcare

• HIPAA Security Rule and proposed updates: while MFA mandates are proposed, you can exceed current expectations with phishing‑resistant passkeys per NIST guidance; design for AAL2+ and auditability. (nist.gov)
• 42 CFR Part 2 (finalized Feb 8, 2024): aligns with HIPAA, modernizes consent and redisclosure; encode SUD disclosure rules in FHIR Consent + policy enforcement; log redisclosures and breaches per rule. (hhs.gov)
• TEFCA CA v2.0: ensure your VC flows complement TEFCA API exchange (e.g., use VCs for identity/consent gating; use FHIR APIs for data exchange). (techtarget.com)
• HTI‑1: plan for USCDI v3 and SMART App Launch v2; support TEFCA‑aligned information sharing under the updated “manner” exception. (healthit.gov)

Data model patterns that actually work

• Patient Identity VC
  • Subject: DID for patient; claims: legal name elements, DOB (enable age‑over predicate), one or more identifiers (MRN, payer member ID), optional photo. Holder binding with the wallet’s public key.
• Coverage VC
  • Subject: patient DID; claims: plan, member ID (suffix only or hash), coverage status active=true, effective dates.
• Consent VC
  • References a FHIR Consent (R5) with scope=treatment; includes purpose_of_use codes and temporal bounds; your verifier enforces the policy rules before issuing FHIR API calls. (hl7.org)

Security hardening checklist

• Wallet keys in secure hardware; verify attestation (Android: Google root chain; rotate trust roots per Google guidance). (developer.android.com)
• Block correlation: rotate pairwise DIDs per relying party; never log stable wallet identifiers; store only cryptographic proofs and decision metadata.
• Require status checks for every VC; cache Bitstring Status Lists with short TTLs; handle soft‑fail with step‑up auth. (w3.org)
• Don’t retain presented claims unless explicitly disclosed via Presentation Exchange “intent_to_retain”; reflect retention in your privacy notices. (identity.foundation)
• Pin issuer keys via did:web and trust registry assertions; alert on key rotation events. (w3c-ccg.github.io)
• Continuous conformance: run OIDF conformance tests for OID4VP/OID4VCI; run Inferno/SMART tests for FHIR APIs; add negative tests for replay and nonce reuse. (openid.net)

How to integrate with existing healthcare rails

• FHIR and SMART
  • Keep your app launch flows unchanged (SMART v2), but swap passwords for a passkey gate and DID/VC proof step; once authenticated, proceed with existing FHIR scopes. (hl7.org)
• TEFCA
  • Use VCs to bind the user/app to a trust framework; perform data exchange via TEFCA policies and FHIR APIs; record VC status and trust registry lookups alongside QHIN transaction logs. (techtarget.com)
• SHC
  • Continue accepting SMART Health Cards (VCI Directory issuers) for immunizations/test results; bridge to VC/PE request flows to reduce “one‑off QR” code paths. (spec.smarthealth.cards)

Implementation timeline (12 weeks to MVP)

• Weeks 1–2: Architecture and governance
  • Select DID method (did:web), choose VC proof suite (VC‑JOSE‑COSE or Data Integrity EdDSA), define VC schemas for Patient Identity, Coverage, Consent; register issuer in your trust registry. (w3.org)
• Weeks 3–5: Build issuance & wallet
  • Stand up OID4VCI; implement pre‑authorized flow; integrate Android/iOS key protection and passkeys; add hardware attestation verification on server. (openid.net)
• Weeks 6–8: Build verification
  • OID4VP request API with Presentation Exchange v2; configure nonce/state; implement Bitstring Status List checks and TRQP lookups. (openid.net)
• Weeks 9–10: FHIR & TEFCA integration
  • Map claims to FHIR R5; enforce FHIR Consent before data pulls; validate against SMART v2 tests. (hl7.org)
• Weeks 11–12: Security, scale, and audit
  • Load test status list retrievals; finalize audit/event model; run OIDF conformance; conduct tabletop for 42 CFR Part 2 redisclosure flows. (hhs.gov)

Common pitfalls (and how to avoid them)

• Treating wallets as identity providers: wallets hold proofs; your verifier still must validate issuer authority (trust registry) and status on every transaction. (trustoverip.org)
• Over‑collecting PII: use Presentation Exchange constraints and SD‑JWT (as supported) to only request what’s necessary; avoid retaining VP payloads. (identity.foundation)
• Ignoring passkey assurance: configure synced passkeys for AAL2 flows and device‑bound for AAL3; document your authenticator policies to auditors. (nist.gov)
• Skipping hardware attestation: require it for prescriber/EPCS and high‑risk flows; fail closed if attestation is missing or untrusted. (developer.android.com)

Where this is going (2026 outlook)

• TSA’s mDL acceptance lists are growing; ISO/IEC 18013‑7 adds remote presentation support—expect pharmacies and telehealth KYC to benefit. (tsa.gov)
• TEFCA’s FHIR API exchange will normalize standards‑based patient access; pairing TEFCA exchange with DID/VC proofing unlocks low‑friction, high‑assurance experiences. (healthit.gov)
• OpenID’s High Assurance Interoperability Profile (HAIP) is maturing to standardize high‑assurance wallets, issuers, and verifiers—plan for HAIP conformance language in your RFPs. (openid.net)

---

How 7Block Labs can help

• VC program design: credential schemas, trust registry governance, and issuer onboarding playbooks.
• Engineering: OID4VCI/OID4VP services, wallet SDK integration, Bitstring Status List infrastructure, and FHIR/SMART/TEFCA connectors.
• Security & compliance: NIST 800‑63‑4 alignment, DEA EPCS workflows, 42 CFR Part 2 consent enforcement, and conformance testing pipelines. (pages.nist.gov)

Passwordless identity isn’t a moonshot anymore. With DIDs, VCs, passkeys, and the latest healthcare interoperability rules, you can deliver safer, faster patient and clinician experiences—without the liability and friction of passwords.