Summary: So, guess what? We can totally make passwordless patient identity a reality in healthcare! By mixing together decentralized identifiers (DIDs), W3C Verifiable Credentials (VCs), OpenID for VC protocols, and passkeys, we’ve really got a game plan that works. How cool is that? This guide is designed to help decision-makers like you create a compliant and ready-to-go setup that integrates FHIR, TEFCA, mDLs, and SMART Health Cards seamlessly. What’s the aim here? Let’s say goodbye to those pesky passwords while also stepping up our game in security, privacy, and, of course, making the user experience a whole lot better.

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

Finally, healthcare is gearing up to say goodbye to passwords! This change is happening thanks to a great blend of standards, regulations, and some handy tools from vendors. So, back in May 2025, the W3C rolled out Verifiable Credentials 2. 0 became a Recommendation. Oh, and by the way, we’ve got the final versions of OpenID for Verifiable Presentations (OID4VP) wrapped up! You're all set with OpenID for Verifiable Credential Issuance (OID4VCI) as of version 1.0. 0. Plus, NIST’s SP 800-63-4 is now acknowledging subscriber-controlled wallets! It’s awesome because it also lays out some clear guidance on how to nail down phishing-resistant authentication with passkeys.

On top of that, we’ve got the TEFCA Common Agreement version 2. So, in a nutshell, the introduction of the FHIR API exchange is a big deal. At the same time, ONC's HTI-1 is rolling out some timelines for things like the SMART App Launch and the new USCDI v3. It’s all pretty exciting stuff happening in the health tech world! Basically, all of this is setting the stage for a DID/VC system that completely ditches passwords, and it’s doing so in a way that meets U.S. requirements. healthcare compliance requirements. If you're curious and want to dive deeper, feel free to check out more information over at w3.org. It's a great resource!

What “production‑ready” means in late 2025

• So, we're talking about the W3C VC Data Model v2. 0, **Data Integrity 1. Hey there! Just wanted to give you a heads-up about a few things: we’ve got 0, VC-JOSE-COSE, and the Bitstring Status List v1 on our radar. The 0 are now officially Recommendations! They've got some pretty solid data, reliable proof, and revocation parts all sorted out. Feel free to take a look at it here. It’s definitely worth your time!
• So, here’s some exciting news: the DID Core has officially been recognized as a W3C Recommendation! Pretty cool, right? And you know what? did:web continues to be the top pick for enterprise issuers and verifiers, mainly because it’s backed by DNS. If you're curious and want to dive deeper, check out the details here. There's a lot of interesting stuff to explore! So, when it comes to OpenID, let’s chat about OpenID for Verifiable Presentations 1.0. So, it looks like 0 is totally ready for both request and presentation flows. Meanwhile, OpenID for Verifiable Credential Issuance 1 is also in the works. The issuance APIs for version 0** have been finalized! For all the details, be sure to take a look here. You won't want to miss it! Hey there! So, the NIST SP 800-63-4 document just got some fresh updates on digital identity assurance. It’s pretty cool because it’s starting to recognize wallets and has added some solid options that are great at resisting phishing attempts. Oh, and just a heads-up--the 2024 supplement points out that synced passkeys are hitting AAL2, while device-bound passkeys can actually reach AAL3. Pretty interesting stuff! Get the details here.
• TEFCA CA v2. 0 is now officially up and running, and they've laid out the requirements for FHIR APIs. It’s exciting to see major players like Epic already getting onboard and ramping up their efforts! If you want to dive deeper into the details, check it out here. Happy reading! Alright, let’s wrap things up with a quick chat about the ONC HTI-1 timelines. So, the baseline for USCDI v3 is locked in for January 1, 2026. Plus, we’ve got the adoption of SMART App Launch v2 happening around the same time. Exciting stuff ahead! Oh, and they’ve made some updates to info blocking! They added a “manner” exception that aligns with TEFCA, which is pretty cool. If you want to dive deeper into this, you can find more info here. Check it out!

The core stack for passwordless patient identity

1. Identifiers and Trust Anchors.

So, let's talk about identifiers and trust anchors. These are pretty key concepts. Identifiers are basically the unique tags or labels we use to recognize different entities--like how we use usernames or email addresses online. Trust anchors, on the other hand, are the rock-solid references that help us verify who or what we can trust. Think of them as your go-to sources that give you confidence in the validity of information. They help keep everything secure and reliable in our digital world.

• I'd recommend using DIDs for your issuers and verifiers. Start by checking out did:web--it's really simple to use because it connects directly to your domain and TLS. This setup really simplifies things and makes it easier to track everything. Don't forget to hang onto a DID Document that outlines your verification methods, like Ed25519 or ECDSA, along with the service endpoints for OID4VCI/OID4VP. It’s super important for keeping everything organized and secure! Hey, take a look at this: w3c-ccg.github.io. It's worth checking out!

2) Credential formats and proofs

• If you're choosing a format for credentials, I’d recommend going with the W3C VC Data Model v2. It’s just a solid choice!

0. When it comes to signatures, you’ve got a few great choices to consider: If you're diving into JSON-LD ecosystems or want to keep things snazzy with zero-knowledge stuff like BBS+, aim for VC Data Integrity with EdDSA or ECDSA cryptosuites. They're the way to go! If you’re into JWT or COSE credentials and want to dive into SD-JWT selective disclosure, definitely take a look at VC-JOSE-COSE! It's a pretty cool resource that you won't want to miss. This option is a great fit for JOSE/COSE toolchains, and it gives you those neat, compact tokens too! For more info, just check out w3.org. They've got all the details you need!

3) Protocols

• Issuance (basically when a wallet receives a credential): OID4VCI 1.

• Presentation (how a wallet shows proof to someone who needs it): OID4VP 1. We're all set with DIF Presentation Exchange v2, which means you can pinpoint exactly what you want and nothing extra. Take a look at this: (openid.net). You might find it really interesting!

1. Revocation/Status

• You can share your credential status by using the W3C Bitstring Status List v1.

0. It's built to save space, respect your privacy, and handle a lot of data at once. Take a look at this: w3.org. You might find it interesting!

5) Policy and Trust Lists

• Go ahead and use the Trust Over IP Trust Registry Query Protocol (TRQP) version 2. You should definitely touch base with authorized issuers or verifiers to keep things running smoothly in terms of governance. So, let’s say you’re wondering, “Can this NPI-licensed facility actually give a Prior-Auth Approval VC?” If that's the case, you can dive deeper into the details by checking out trustoverip.org. There’s a lot of good info there!

Architecture blueprint (reference for CTOs)

Let me break down the simple process we’re following over at 7Block Labs for the U.S. healthcare apps:.

• Wallet and Authenticator
  The patient app comes with a handy mobile wallet that looks out for you, thanks to its solid platform key protection, like Secure Enclave for Apple users and Android Keystore for those on that side. Plus, it uses passkeys to make signing in super easy and secure! It really depends on how it's set up, but it can actually meet the NIST AAL2 and AAL3 standards. On top of that, it utilizes hardware key attestation to ensure that those keys are actually supported by the hardware. Take a look at this link: (nist.gov). It's got some really interesting info!
• Issuer(s)
  So, your EHR, payer, or telehealth system is stepping up as a VC Issuer, right? It’s got OID4VCI endpoints like:
  • .well-known/openid-credential-issuer (metadata)
  • /oauth/token (OAuth 2.0)
  • /credential (VC issuance)
• It's designed to back up pre-authorized code flow when it really makes sense to do so. Dive deeper here: (openid.net).
• Verifier(s)
  So, basically, your app, portal, or API is using OID4VP to pull in only the essential attributes through something called a Presentation Definition. Next, it grabs a vp_token along with the presentation_submission. This is used to check things like the signature, holder binding, nonce, and the status. Learn more at: (openid.net).
• FHIR Integration
  Hey, just a quick reminder--don't forget to link up those VCs with the HL7 FHIR resources, especially R5 when it comes out! So, for example, a “Patient Identity” verifiable credential connects to a FHIR Patient record. Then, the “Coverage” verifiable credential is linked to FHIR Coverage. And, of course, consent is tied back to FHIR Consent to follow those policy rules. It all fits together nicely! If you're curious about FHIR, feel free to check it out here: hl7.org. Happy exploring!
• Network and Compliance
• Connect with TEFCA by using your favorite QHIN or participant. If you want to get API access, just be sure you’re up to date with the timelines for SMART App Launch v2 and USCDI v3. If you’re looking for more details, check this out: (techtarget.com). It’s got all the info you need!
• Status & Trust
  Make sure to keep a Bitstring Status List close by for any suspensions or revocations that might come up. It’s a handy reference to have!
• Check out TRQP to confirm whether the issuer is authorized and to see what ecosystem connections they have. For instance, you might want to look into whether a specific pharmacy chain is approved to issue a Dispense VC. If you're curious to dive deeper, check this out: w3.org. Happy reading!

Minimal data flows (protocol‑level specifics)

• OID4VCI issuance (pre-authorized)
  So, first up, the wallet takes a look at the credential_offer. After that, it makes a call to /oauth/token to trade the pre-authorized_code for an access token. Simple as that! Next up, it fires off a POST request to /credential and includes proof of possession--this could be something like DPoP or a holder binding key. In return, it receives a Verifiable Credential (VC), which can come in either JWT/COSE or Data Integrity format. Pretty neat, right? (openid.net).
• OID4VP presentation
  So, the verifier starts things off by putting together an authorization request. This request has a few important elements in it, like the presentation_definition, a nonce, and a state. After that, the wallet sends back a vp_token along with a presentation_submission that includes just the essential fields required by the PD. Once that's done, the verifier goes ahead and runs a few checks on the signature. They’ll confirm that the PD is all good, double-check the nonce, and then take a look at the status (you know, that Bitstring thing). (openid.net).

Practical healthcare examples you can launch in 90-180 days

1. Easy Patient Sign-Up for Telehealth Without Passwords.

• Step 1: The patient logs in using a passkey (WebAuthn) instead of typing in a password. Based on what you need for security, they might go for AAL2 (which is synced) or AAL3 (which ties to a specific device). If you want to dive deeper into this topic, hop over to nist.gov for more info!
• Step 2: The payer portal, also known as the Issuer, goes ahead and issues a “Coverage VC” using OID4VCI. So, with the telehealth app called Verifier, the first thing it does is ask for proof that you have active coverage. It also checks if you're 18 or older by using OID4VP along with Presentation Exchange predicates. And just a heads up, it’ll only show your date of birth if it really needs to. If you’re looking for more information, check out openid.net. There’s a lot of great stuff there!
• Step 3: We get consent by using a FHIR Consent resource linked to a "Consent VC." This setup allows us to share information with the telehealth provider, but only for specific purposes related to your treatment over the next 24 hours. If you want to explore this topic further, check out hl7.org. It's got a ton of great information!

2) EPCS Identity Compliance for Prescribers (DEA 21 CFR Part 1311)

So, to meet the DEA's two-factor authentication (2FA) requirement when signing, prescribers have to confirm their identity in two different ways. This could mean using something like a passkey along with a biometric scan, like a fingerprint or facial recognition, on their device. The app handles all the important logical access controls and audit trails mentioned in Part 1311, so you don’t have to worry about that. 120/. 140. When it comes to managing identity claims, we're going with DID/VC. For signing, we have this cool signature ceremony that incorporates platform authenticators and follows some pretty thorough audited workflows. It’s all about keeping things secure and smooth! If you want to dive deeper into this topic, feel free to check it out here. It's got all the details you might need!

1. Checking Prior Authorization in TEFCA. Alright, so here’s the deal: a plan will send out something called a “Prior Authorization Approval VC,” and it’s got this entry called a Bitstring Status List included in it. Next, the provider’s EHR sends that information over to a downstream facility using OID4VP. After that, the facility will take a moment to confirm the status and see if the issuer is recognized in a trust registry. Basically, they’re gonna ask, “Is this plan legit when it comes to handing out PA approvals in this network?” (w3.org).

4) Specialty pharmacy age and identity with mDL + VCs

Hey, if you need to confirm someone's identity and age, go with the ISO/IEC 18013‑5/‑7 mobile driver's licenses (mDLs). They do a great job! And to make sure you're checking for eligibility, you can mix that with a Coverage Verifiable Credential (VC). It’s a solid combo! The TSA's recent approval for state mobile driver's licenses at airports really shines a light on how verifiers operate in the real world. It also gives us a better idea of the reader setup we've got going on here in the U.S. Hey, just a quick reminder to check against the TSA's accepted list, okay? And once you’ve confirmed everything, make sure to delete any mDL data you have. Better safe than sorry! (tsa.gov).

5) Vaccination Records with SMART Health Cards (SHC)

So, a whole bunch of issuers are sharing their keys in the VCI Directory. This lets verifiers easily check the signatures without having to hang on to a ton of data. It's a pretty neat way to keep things efficient while still making sure everything checks out! Plus, SHCs can easily chill alongside W3C VCs in your wallets. They can also link up through OID4VP request objects, making it super convenient! (spec.smarthealth.cards).

Best emerging practices (what we recommend now)

• Pick either VC-JOSE-COSE or EdDSA for ensuring data integrity, depending on what meshes well with your tech setup. Both of these options come highly recommended by W3C, and they play really well with OID4VCI/OID4VP. Take a look at this link: (w3.org). You’ll find some really interesting info there!

Hey there! Just a quick tip: when you're working with Presentation Exchange v2, don’t forget to set those “statuses” constraints clearly. It's super important! This means that verifiers will only go for active credentials and will automatically shut out any that have been suspended or revoked. For more info, check this out: identity.foundation.

To keep things secure, it’s smart to make sure that holder binding is enforced with key-bound credentials. Also, don’t forget to add some replay protection using nonces or state in OID4VP. When it comes to handling clinical risk flows, it's a good idea to avoid using self-attested identifiers. If you want to check out the specs, just hop over to this link: (openid.net).

To handle revocations smoothly, make sure to get your hands on the Bitstring Status List v1. It's a handy resource! 0. Don’t forget to publish those lists using HTTPS! It’s super important for security. Also, make sure you add caching and ETags to keep things running smoothly. That way, everything loads faster and works like a charm! If you’re looking for more details, you can check it out here: w3.org.

Hey there! If you're diving into the world of wallets, one thing you definitely want to keep in mind is the importance of using hardware-backed keys and attestation. Trust me, it makes a big difference! Make sure you check the Android Key Attestation chains and take advantage of the iOS Secure Enclave. It's a smart move to keep your app secure! When dealing with high-risk situations, it’s usually a good idea to play it safe and fail closed, especially if you don’t have hardware attestation in place. For more info, check this out: (developer.android.com).

Trust registries are super helpful when it comes to managing ecosystems. Make sure to use TRQP to check out the issuer and verifier authorizations in a programmatic way. And hey, don’t overlook adding the registry provenance to your audit logs! It's super important for keeping everything transparent and traceable. If you want to dive deeper, check it out at: trustoverip.org. There’s some really interesting stuff there!

• So, here's the final thought: when it comes to data, remember that sometimes less is actually more. If you're thinking about using selective disclosure, like the SD-JWT VC, for handling demographics, go for it! Just make sure your verifier libraries are fully on board with the latest drafts before you dive in. Happy coding! If you want to dive deeper into the details, just head over to this link: (ietf.org). It’s packed with more info for you to explore!

Compliance map for U.S. healthcare

• HIPAA Security Rule and some potential updates: There are some really intriguing proposals being discussed right now about MFA (multi-factor authentication) requirements. If you’re looking to up your security game, you might want to think about using phishing-resistant passkeys, just like NIST suggests. They can really help keep your accounts safe! So, basically, you wanna shoot for an AAL2+ when it comes to authentication assurance levels. Also, don’t forget to keep everything audit-friendly! Take a look at this: (nist.gov). It's worth your time!
• 42 CFR Part 2 (finalized on February 8, 2024): This update really complements HIPAA by refreshing the ways consent and redisclosures are handled. It’s a great step forward, making it easier to navigate these important regulations! Hey there! It's a good idea to get to know the latest rules about disclosing substance use disorders (SUD). They’ve been revamped to work with the FHIR Consent framework, along with some new policy enforcement stuff. Just a heads-up! Hey there! Just a quick reminder to make sure you log any redisclosures and breaches as needed. If you want more info, check out this link: (hhs.gov). It’s all laid out there!
• TEFCA CA v2. 0: Just a heads up - make sure that your Verifiable Credentials (VC) flow plays nice with the TEFCA API exchange. It's super important for everything to run smoothly! For example, if you use VCs to manage identity and consent gating combined with FHIR APIs for data exchange, you can definitely make your entire process a lot smoother. If you want to dive deeper into it, check it out here: techtarget.com. It's got all the details you need!
• HTI-1: It's definitely smart to start prepping for USCDI v3 and the SMART App Launch v2. Make sure you're on board with sharing information that aligns with TEFCA, particularly when it comes to the new “manner” exception. For the latest scoop on this, take a look right here: (healthit.gov).

Data model patterns that actually work

• Patient Identity VC
• So, check it out, we've got the patient's DID right here. So, it covers stuff like your legal name, your date of birth (which is handy for figuring out your age), and some identifiers, like your MRN or payer member ID. You can also choose to add a photo if you'd like! The holder links up to the wallet by using the public key.
• Coverage VC
  Alright, so here’s the deal: this one’s all about the patient’s DID. It has to include some key details like the claims for their plan, the member ID (which could either be the suffix or a hash), and we need to see that the coverage status is active--so it should show true. Plus, don’t forget to include the effective dates!
• Consent VC
• This is about a FHIR Consent (R5) that specifically relates to treatment. It goes into detail about the purpose of use codes along with the relevant time frames. Just so you know, your verifier will double-check the policy rules before any FHIR API calls go through. Take a look at it here: (hl7.org). You'll find some pretty interesting stuff!

Security hardening checklist

Make sure to keep your wallet keys secure with some solid hardware. It's important to double-check attestation--if you're on Android, definitely check out the Google root chain and follow their tips on rotating trust roots. (developer.android.com). When it comes to block correlation, just keep in mind to rotate those pairwise DIDs for each relying party. And a tip: steer clear of logging any stable wallet identifiers. Instead, just stick with the cryptographic proofs and the decision metadata you’ve got.

• Make sure to regularly check the status for each VC. It's a good idea to cache the Bitstring Status Lists, but remember to keep those time-to-live settings short. And if you run into a soft fail, be prepared to step up the authentication process. (w3.org). Hey there! Just a quick reminder: try to avoid keeping any claims that were submitted unless you've got a solid heads-up through Presentation Exchange's "intent_to_retain" feature. And don’t forget to mention that retention info in your privacy notices too! (identity.foundation). Make sure to secure those issuer keys with did:web and keep an eye on the trust registry assertions. Also, don’t forget to stay on the lookout for any key rotation events! (w3c-ccg.github.io).
• Let’s stay focused on making sure everything lines up perfectly! First up, we need to run the OIDF conformance tests for OID4VP and OID4VCI. Don’t forget to throw in some Inferno/SMART tests for the FHIR APIs, too. Oh, and it’s really important to include some negative tests for replay and nonce reuse to cover all bases. (openid.net).

How to integrate with existing healthcare rails

• FHIR and SMART
• You can stick with your current app launch processes (shoutout to SMART v2 for that!), but let’s swap out those passwords for a passkey gate and add a DID/VC proof step.
  Once you’ve nailed down authentication, just keep moving forward with the regular FHIR scopes. It’s pretty straightforward! If you want to dive deeper into the details, hop over to the HL7 website. You’ll find all the info you need there!
• TEFCA
  Using VCs can really help create a solid trust framework for users and apps. It's definitely something to consider! This means you can easily swap data around by following the TEFCA guidelines and using FHIR APIs. It's a pretty straightforward process! Hey! Just a quick reminder to make sure you log the VC status and trust registry lookups whenever you're handling those QHIN transaction records. You can check out more details over at TechTarget if you need a refresher. Happy recording!
• SHC
• Continue to welcome SMART Health Cards from issuers listed in the VCI Directory for immunizations and test results. It’s a good idea to link up with VC/PE request flows to streamline things and avoid those random “one-off QR” code paths. If you're interested, take a peek at the details on Smart Health Cards. You might find it pretty informative!

Implementation timeline (12 weeks to MVP)

Weeks 1-2: Getting a Grasp on Architecture and Governance. To get started, first, pick your DID method--let's go with did:web for this example. Next up, choose a VC proof suite. You have a couple of options here: VC‑JOSE‑COSE or Data Integrity EdDSA. After that, you'll want to set up your VC schemas for Patient Identity, Coverage, and Consent. It’s a bit of a process, but you’ll get the hang of it! Hey, just a quick reminder to make sure you register the issuer in your trust registry! You can find all the details over at w3.org. Don’t skip this step!

• Weeks 3-5: Getting the Issuance and Wallet Ready. Alright, let’s get OID4VCI up and running! First up, we need to dive into setting up that pre-authorized flow. And don’t forget; we’ve gotta make sure we’re integrating key protection for both Android and iOS using passkeys. Let’s make this happen! Don’t forget to set up hardware attestation verification on your server, too! It’s an important step you won’t want to skip. (openid.net).
• Weeks 6-8: Time to Check Things Out. Let’s jump right into setting up the OID4VP request API with Presentation Exchange v2! It’s a great way to get started, and I’m excited to help you through the process. Hey, just a quick reminder to make sure you set up the nonce and state properly. Oh, and don’t forget to include those Bitstring Status List checks and check in with the TRQP lookups too! (openid.net).
• Weeks 9-10: Getting the Hang of FHIR & TEFCA Integration. Alright, let’s get those claims lined up with FHIR R5! Just a quick reminder to check FHIR Consent before diving into any data retrieval. And don’t forget to validate everything with the SMART v2 tests. We want to make sure everything’s spot on! (hl7.org).
• Weeks 11-12: Diving into Security, Scaling Up, and Auditing. Alright, it's go time for some serious testing! Let’s really put those status list retrievals to the test, wrap up your audit/event model, and make sure to run those OIDF conformance checks. And don't forget to do a tabletop exercise for the 42 CFR Part 2 redisclosure flows. We've got this! (hhs.gov).

Common pitfalls (and how to avoid them)

• Viewing wallets as identity providers: Think of wallets as your personal vaults for proof. They hold important info, but here’s the thing--your verifier has to ensure that the issuer is trustworthy (kind of like a trust registry) and check the status before you make any transactions. Always good to double-check, right? If you’re curious and want to dive deeper, you can find more info about it here. Happy reading!
• Steering clear of PII overload: When you’re asking for info, just focus on what you really need. Keep it simple! Alright, so here’s the deal: try using Presentation Exchange constraints and, if it makes sense, throw in some SD-JWTs. This way, you can keep everything nice and tidy without dragging around those VP payloads. Let's keep it streamlined! If you want to dive deeper, you can check out more details here. Happy exploring!
• Don't forget about passkey assurance: It's super important to get those synced passkeys in place for AAL2 flows. And for AAL3, be sure to set up device-bound passkeys. Trust me, you don't want to skip this step! Hey, don’t forget to write down your authenticator policies! It'll help the auditors understand everything better. Hey, take a look at this for some extra insights: NIST. It’s got some great info!
• Always make sure to do hardware attestation: Seriously, it’s essential for prescribers and EPCS, especially when dealing with high-risk situations. Trust me, you don’t want to overlook this step! If you come across a situation where attestation is either missing or seems a bit sketchy, it's definitely a good idea to play it safe and fail securely. If you're looking for some guidelines, check this out here. It'll give you all the info you need!

Where this is going (2026 outlook)

Hey, have you heard? The TSA is seriously ramping up the number of places where you can use mobile driver's licenses (mDLs). Plus, with the new ISO/IEC 18013-7 standards coming out, they're introducing remote presentation support. This is pretty exciting news, especially for pharmacies and telehealth services that need to verify identities! If you want to dive deeper into it, just click here for more info! TEFCA's FHIR API exchange is all about making things easier for patients when it comes to accessing their health data. It aims to create a more consistent experience, so everyone can get their info without a ton of hassle. When you bring together the TEFCA exchange with DID/VC proofing, it really enhances the user experience. You end up with something that's not just smooth, but also super reliable. Curious about the specifics? Check it out here for all the details! OpenID's High Assurance Interoperability Profile, or HAIP for short, is getting a makeover. The goal? To make high-assurance wallets, issuers, and verifiers more standardized and easier to work with. It’s all about stepping up the game for security and consistency in the digital world! Hey there! If you're working on some RFPs, don't forget to toss in a mention of HAIP conformance. It’s a good idea to make sure it's covered! If you want to dive deeper into this, just click here for all the details!

---

How 7Block Labs can help

• VC Program Design: We're really getting into the nitty-gritty of credential schemas, exploring how trust registry governance works, and crafting some great onboarding playbooks for issuers.
• Engineering: We're diving into some exciting stuff, like OID4VCI/OID4VP services. We’re also working on integrating wallet SDKs, developing the Bitstring Status List infrastructure, and linking up with FHIR/SMART/TEFCA. It's a lot, but we’re all about making those connections!
• Security & Compliance: We’re really focused on making sure we align with NIST 800-63-4. We're working hard to simplify the DEA EPCS workflows, uphold consent requirements set by 42 CFR Part 2, and establish those conformance testing pipelines we need. (pages.nist.gov).

Passwordless identity is finally here, and it's not just something we used to fantasize about! Thanks to DIDs, VCs, passkeys, and the latest healthcare interoperability guidelines, you can now whip up faster and safer experiences for both patients and clinicians. Plus, you can say goodbye to the headaches and risks that come with traditional passwords!