By Alex Colgan

A pharmacy technician in Ohio scans a bottle of oncology product that lacks proper documentation. The label says it was made by a manufacturer the pharmacy has never bought from directly, two intermediaries back. Under DSCSA, the technician has to find out whether that product identifier is real, and the only party who can answer is the manufacturer that printed it.

Looking under the hood, one system in Ohio is about to send a question to a system somewhere else, on behalf of a company with no contract with the company receiving it, no shared account, no onboarding history, and no prior public key exchange. The manufacturer has to decide, in a few dozen milliseconds, whether to answer at all.

DSCSA, the Drug Supply Chain Security Act, restricts the US pharmaceutical supply chain to authorized trading partners. That’s easy to satisfy when two companies have an established connection… most of the time. (More on that in the next section.) In those cases the work is part of the onboarding process: someone signed a contract, someone checked the license, someone provisioned the connection and logged a certificate.

Product identifier verification breaks that assumption on purpose. The law requires that a dispenser investigating a suspect package reach out to the manufacturer that made it, and often those two parties have never met. To achieve this in the “interoperable, electronic” manner envisioned by the law, the industry developed a network called the Verification Router Service (VRS), which automates requests and responses between wholesalers, dispensers, and regulators on the on hand, and manufacturers and repackagers on the other. The network has to deliver four things at once, and they pull against each other:

• Authorization. Only parties with current authorized status get an answer. The problem is that this status can lapse anytime.
• Authentication. The party on the other end really is the company it claims to be, and a thief holding its access can’t pass for it.
• Confidentiality. Nobody outside the two parties learns the exchange happened. DSCSA data traffic is a map of who a company buys from, how much, and what products give them pause.
• Choice. The two parties will be running different vendors, and neither can be forced to adopt the other’s.

Any one of these is easy on its own. The trouble starts when you notice that the obvious fixes for the first two undermine the third and fourth.

The false dilemma of shared secrets: manual labor vs. single point of failure

Our first natural instinct is to hand each party something to present. An API key, a client certificate with a static secret, a bearer token. That works fine between two systems, but at the scale of a national network it fails. How it fails depends on how the secrets are shared and distributed.

If the secret is point-to-point per relationship, the count grows with the square of the participants, and every single one has to be created, delivered, rotated, and destroyed, often by hand. If the secret is centralized per service, so one key gets you into a verification endpoint no matter who you’re acting for, a single theft hands out a skeleton key. Drag the sliders in the diagram below and watch both problems get worse.

Point-to-point failures

The point-to-point option looks survivable on a diagram, because the cost is invisible on a diagram. It shows up as labor. For example, take a network with 12 participants, involving mutual exchanges of x509 certificates. This means 66 pairwise relationships where 12 companies each maintain 11 of them. Every one of those 66 started as an email thread. Certificates have to be regularly rotated, on both sides, on a variable schedule. The human hours (and the costs) start to add up.

Thanks to Murphy’s Law, failures tend to crop up at the worst possible time. A certificate expires on a Saturday and verification stops for a partner nobody has spoken to in 11 months. Somebody leaves and their replacement inherits a list with no provenance. Certificate keys get emailed in plaintext because the deadline is today.

Centralized failures

While point-to-point failures are a constant headache, centralized failures are more like heart attacks. The Change Healthcare breach involved exploiting a remote access application that lacked basic multi-factor authentication. The attackers moved laterally for nine days, exfiltrating data, and deployed ransomware in February 2024.

One set of working credentials was ultimately worth 192.7 million people’s health data. Pharmacies across the country could not fill prescriptions because a company serving more than 30,000 of them had become unreachable.

In this case, the credential authenticated a piece of software. Any company acting through that software inherited its access, so possession was the whole of authorization, and nothing downstream could tell a thief from the tenant. As a direct result, a system everyone had to route through turned one compromise into a national outage.

Moreover, authorized status isn’t a property you check once. A state license can lapse on a Tuesday. If authorization rides on a long-lived secret, the network has no way to notice, and the shady actor keeps getting access to until someone somewhere checks something.

So what’s the solution? Most of the time it’s tackled by putting the answers in one place. Build a service that knows everyone’s current status, and call it before you respond to anything: is this company authorized right now? The data is always fresh, revocation is instant, and there’s exactly one integration to build.

This is a frequent and useful pattern for certain types of interactions, including license checks on established trading partners on established channels. However, consolidating too much data and too many workflows into a single centralized system – especially if it combibes authorization and authentication – introduces several systemic vulnerabilities.

Count the verifications against each manufacturer? You have a live market share estimate. Watch a health system’s traffic to one manufacturer dry up while traffic to a competitor climbs? You’ve seen a contract change hands. Watch a buyer who has never touched a manufacturer’s products start verifying its full line? This is the pattern of due diligence, and it might suggest an acquisition.

It’s also a single point of failure for a key network. If the status service goes down, either everyone stops verifying or everyone starts skipping the check. A single bad actor could do a lot of damage with no indication that something has gone wrong.

Classic certificate hierarchies land in a similar place for a similar reason. A certificate authority can bind an identity to a key convincingly. What it handles badly is an attribute that changes on the state’s schedule rather than the certificate’s, and the standard freshness fix – an online status responder – reintroduces exactly the observer you were trying to avoid.

The third option: verifiable credentials

W3C verifiable credentials rescue us from this false dilemma with a clear separation of duties, keys, and data access. The OCI specification, which the PDG Blueprint folds in by reference, separates the party who vouches from the party who presents, and never lets the two of them into the same conversation.

For quick background, DSCSA and FDA guidances establish the legal requirements and how the Agency interprets the law. The Partnership for DSCSA Governance translates that into business requirements in its Blueprint, and Chapter 6 of that Blueprint hands conformance to the Open Credentialing Initiative in three flat requirements: credential issuers, digital wallets, and VRS solutions all have to conform to OCI’s criteria. OCI then writes criteria specific enough that an auditor can test a vendor against them, pulling in GS1’s message format and NIST’s identity proofing guidance along the way.

The practical effect is that the identity and status of an “authorized trading partner” becomes digitally verifiable,. A credential issuer does due diligence on a company, verifying the company is who it says it is, and it verifies and tracks the FDA registration or state license that makes it authorized. Those are two findings, so they become two credentials. The Identity Credential ties a decentralized identifier (DID) to a legal entity and acts as the root of trust. The ATP Credential sits on top of that and asserts current authorized status. When the license lapses, the issuer switches (or even revokes) the second and the first survives.

Both are signed by the issuer and handed to the company’s digital wallet, and that’s the end of the issuer’s involvement until a periodic recheck or a revocation.

When the company actually needs to prove something, the wallet wraps the credential in a verifiable presentation and signs the wrapper with the company’s own key. The whole design turns on this move. The issuer’s signature answers one question: is this claim about authorized status true and intact? The holder’s signature answers a different one: did the company holding this credential approve its use in this specific exchange, right now? Two keys, two jobs. Steal an issuer’s key and you can’t generate VPs to impersonate a trading partner. Steal a trading partner’s key and you can’t mint credentials, and the one credential you can us can be revoked by the issuer.

The presentation gets serialized as a JWT, a compact signed token, and rides in an ATP-Authorization header. Click any box in the map, or any row in the list.

The five-minute window

A signed object that lives forever is a signed object somebody will eventually capture and reuse. To prevent this, each VP carries an issuance timestamp, and OCI caps its usable lifetime at 300,000 milliseconds. A verifier adds that ceiling to iat and refuses anything past it.

The other hedge against replay attacks is the Universally Unique Identifier (UUID). Every GS1 verification exchange carries a UUID generated for that one request and echoed on its response. When the verification service asks the wallet for a presentation, it hands over that UUID, and the wallet signs it into the token as the nonce. So the value appears twice: once in the clear, as a query parameter on the request, and once inside the signed envelope in the header. Two truly random UUIDs should never collide; if you created UUIDs at a rate of a million a second, you have a 50% chance of a collision after 100,000 years.

Seven checks

When a presentation arrives, the receiving system doesn’t evaluate it. It hands the whole thing to its own digital wallet, along with its own DID, and asks. Credential authentication happens in a conformant wallet on the verifier’s side, never in the message and never in the router.

The wallet then runs the seven checks the PDG Blueprint and OCI criteria have established. Each one closes a specific attack, and they’re built so that the gaps between them close too. Try breaking them one at a time:

Who vets the vetters

As you might have noticed, while verifying that the issuer’s signature is genuine tells you the credential came from that issuer, it tells you nothing about whether the issuer is anyone you should believe. Nothing stops a bad actor from standing up their own issuer, assigning themselves an ATP credential, and presenting a cryptographically flawless proof of a claim nobody ever checked.

With that in mind, the list of issuers who have met OCI’s conformance criteria has to live somewhere verifiable, reachable by every wallet, and outside the control of anyone in the exchange. OCI publishes it as an Ethereum smart contract following ERC-7506, organized by credential type. A wallet calls isTrustedIssuer with the issuer’s DID before accepting anything, or subscribes to the contract’s change events and keeps a local copy current. The list can only be changed by a cryptographically signed voting process.

The same logic covers the rest of the supporting cast. Public keys live in DID documents that anyone can resolve, so a verifier fetches the key it needs without asking the counterparty for it and without a certificate authority in the middle. Revocation lives on a list the issuer publishes and the verifier polls, so a revoked credential stops working inside a bounded window and the issuer never learns who was about to accept it.

In other words, verifiable credentials allow you to take trust dependencies out of the transaction path and publish them in advance instead.

The whole dance

This brings us to the diagram everybody finds intimidating. Scanning a drug and getting an answer from the VRS takes about a second, but it involves 26 interactions. The wholesaler or health system proves it’s authorized before the manufacturer will answer. Then the manufacturer proves it’s authorized before the wholesaler will believe the answer, because a confirmation from an unauthorized party is unhelpful. Steps 1 through 12 and steps 13 through 25 are the same choreography with the colors swapped:

Enhanced capabilities

Everything you see above is today’s production verification ecosystem with a network of solution providers serving hundreds of manufacturers, tens of thousands of pharmacies, wholesalers, regulators, and everyone in between. Companies prove authorized status, in both directions, in a second. Credentialed traffic on the VRS is up roughly 35x compared to last year, and ATP credentials secure a growing family of data applications: verification, trace, exceptions management, master data exchange, and more. To support these more sensitive applications, verifiable credentials also enable self-signed data and encryption. One of the simplest methods is to simply hash the data that accompanies the VP. Hash the transaction data, bake the hash into the VP, and send the VP as part of the header to the (now signed) message. The hash commits to one exact record: change a lot number, a quantity, a date, and it no longer matches.

DIDComm is the other option. A messaging protocol addressed to DIDs rather than to endpoints, DIDComm enables protection to travel with the message instead of with the connection. Because the address is the DID itself, the message can travel any path that will carry it: an HTTPS post, a queue, a mediator that holds it until the other side comes online. Whoever relays it never has to be trusted with the contents. Resolve the DID, take the keys from the document, wrap the message for that recipient, and hand it to whatever will move it.

Back to Ohio

All of this has taken place in about a second. The technician gets her answer and the manufacturer knows exactly who asked and that they’re authorized today. Neither side had to adopt the other’s vendor, and nothing got left lying around to steal: no key in a spreadsheet, no certificate waiting to expire on a Saturday, no single operator holding the industry’s traffic one stolen password away from being the next Change Healthcare. The bottle in her hand is either real or it’s not, and that’s the only part any patient will ever care about.

Resources

1. OCI Digital Wallet Conformance Criteria, v3.4.1. The criteria a digital wallet is audited against. It defines the verification checks, the error codes a refusal returns, the five minute presentation lifetime, ES256K signing, the 24 hour ceiling on cached revocation data, and the twelve month key rotation requirement.
2. OCI Credential Issuer Conformance Criteria, v2.4.1. What an issuer has to do before it vouches for anyone: identity proofing anchored at NIST IAL2, evidence strength, and the periodic re-checks that keep authorized status honest.
3. OCI Conformance Program, v1.1.2. How conformance is actually established. Credential issuers and digital wallet providers undergo third-party audit; VRS providers attest. It also sets what a qualifying audit firm looks like and what triggers a re-audit.
4. OCI Credential Schema Specification, v1.2.1. The shape of the credentials themselves. This is where the ATP credential’s subject properties live, along with the LDAP revocation status object, and it is the reference for the JSON in What is actually on the wire.
5. OCI DSCSA Interoperability Profile, v3.4.2. The bundle that pins which version of each criteria document and schema goes together. Useful when you need to know what “conformant” meant on a particular date.
6. PDG Foundational Blueprint for 2023 Interoperability, Chapter 6: DSCSA Credentialing and User Authentication Functional Design. The industry’s own statement of what the law requires of a system, and the document that hands conformance to OCI. Source of the credential types and the seven checks in The verification pipeline.
7. GS1 US Lightweight Messaging Standard for DSCSA Verification of Product Identifiers, Release 1.3.1. The message the credential travels in. It defines the GET request, its path segments and query parameters, the ATP-Authorization header, and the corrUUID that correlates a request with its response.
8. DIDComm Messaging, Decentralized Identity Foundation (v2.1 editor’s draft, working group approved), plus Routing Protocol 2.0. DIDComm Messaging provides a secure, private communication methodology built atop the decentralized design of W3C-compliant DIDs. The spec includes the message formats and envelope types.
9. W3C Verifiable Credentials Data Model and Decentralized Identifiers v1.0. The two W3C recommendations everything above is built on: what a credential and a presentation are, and how an identifier resolves to the keys that verify them.
10. ERC-7506, Trusted Hint Registry. The Ethereum standard behind the trusted issuer list, which is how a wallet answers the recursive question in The verification pipeline: whether the party that vouched for a company is itself anyone to believe.
11. NIST SP 800-63A, Digital Identity Guidelines: Enrollment and Identity Proofing. Where the identity assurance levels come from. OCI treats IAL2 as the anchoring point for proving an organization is who it claims to be.