Copyright © 2023 Named editors. Contributors to the Open Credentialing Initiative.
In November 2013, the U.S. Congress enacted the Drug Supply Chain
Security Act (DSCSA) in order to intercept drugs that may be
counterfeit, stolen, contaminated, or otherwise harmful and better
safeguard patient health. To ensure that only legitimate actors are part
of the supply chain, the regulation establishes a definition of
Authorized Trading Partners (ATPs) and associated licensing requirements
for different types of stakeholders. Not only must U.S. pharmaceutical
trading partners be authorized (as defined in the statute), but also to ensure that they only
interact with other trading partners that are also authorized.
In addition, the U.S. pharmaceutical supply chain includes two other major groups:
Authorities (e.g. federal and state regulators) and ATP Equivalents (i.e. trading partners that are not required to register with the FDA or obtain a State license, such as the Veterans Administration, Department of Defense, etc.). Together, these "DSCSA Stakeholders" (or "Stakeholders") represent the three key groups for DSCSA interoperability.
The Open Credentialing Initiative (OCI) has come together to support the
industry-wide implementation and adoption of the architecture
demonstrated in the ATP Proof of Concept and Pilot conducted in 2020.
This architecture supports the ATP requirements of the DSCSA and employs
the use of W3C-standard Decentralized Identifiers, Verifiable
Credentials, Verifiable Presentations, Credential Revocation Registries,
and the necessary processes and information exchanges between
DSCSA-defined Stakeholders to establish mutual verification of identity and licensure
status.
This specification describes a Linked Data vocabulary for
asserting organization-level identity verification and license status of
manufacturers, repackagers, wholesalers, third-party logistics providers (3PLs), dispensers, ATP equivalents, and authorities used to verify a counterparty
identity and to determine the ATP licenses of supply chain
actors (where applicable).
(Note that the JSON objects described later in this specification bear their own version numbers, as the changes in the 1.X.0 revision are limited to this specification document.)
This is a living document developed by OCl's Founding Members with input
from other OCI Charter Members, DSCSA Trading Partners, Solution
Providers, Associations, Standards Bodies and others interested in
implementing and contributing to the betterment of the W3C Verifiable
Credentials architecture piloted by the DSCSA ATP Pilot.
It is
anticipated that the contents of this document will be reviewed and
updated to address feedback related to compliance, business operations,
W3C and GS1 Standards, interoperability, changing legislation,
regulations, and policy.
Please open an issue, if you wish to collaborate on this OCI specification.
This specification describes a Linked Data vocabulary for asserting the
digital identity and DSCSA status (e.g. licensure) of entities acting as trading partners or authorities
in the U.S. pharmaceutical supply chain. Based on that vocabulary,
trading partners and authorities are able to first acquire an identity credential and
second a relevant Stakeholder credential as a verifiable representation of their
DSCSA status. Both credentials are issued by a Credential Issuer
following the OCI Conformance Criteria for Credential Issuers.
A primary
goal of this specification is to standardize the creation of Verifiable
Credentials from standardized JSON-LD [[json-ld]] which is itself created from JSON
Schema definitions as would normally be passed of REST and other APIs.
This promotes code re-usage and establishes a pattern for the creation
of JSON-LD and related Verifiable Credentials derived from those JSON-LD
objects in a manner that is friendly to code and API development as well
as to promote better interoperability between vendors who serve common
or related markets.
The Vocabulary section covers each vocabulary item,
its properties, other attributes, and provides an example of a
Verifiable Credential for each item.
The OCI defines these design principles to narrow down the attributes included in the credential schema to OCI supported use cases.
If an attribute is needed only by the Credential Issuer to document the internal process of tracking or due diligence activities, the attribute does not need to be included in the credential schema.
Example: Hash value signature from person signing of the Due Diligence is not includedAn attribute is included if the value supports the application consuming credentials to perform certain logic or operational checks.
Example: Parent organization of the trading partner to provide the verifier context of the organizational structureThe OCI determines that the:
only applies to the Stakeholder schemas (i.e. DSCSA ATP Credential, DSCSA ATP Equivalent, and DSCSA Authority) because there is a use case for consuming credential
applications to use these attributes to perform credential integrity checks.
However, these attributes do not apply to the Identity Credential schema, because while the usage of these associated
identifiers applies to the Issuer’s internal due diligence and tracking processes, there is no current apparent
use for consuming Identity Credential applications.
A thing with distinct and independent existence, such as a person, organization, or device that performs one or more roles in the ecosystem.
An identifier as defined by [[RFC3986]].
A decentralized identifier as defined by [[did-core]].
This vocabulary assumes all terms specified in the base Verifiable Credentials [[vc-data-model]] context.
You may find the latest json-ld vocabulary at:
https://open-credentialing-initiative.github.io/schemas/
Identity Credential assures that the Credential Issuer performs an identity verification process and that the subject DID is a trusted entity.
Term | IdentityCredential |
Full IRI | https://open-credentialing-initiative.github.io/schemas/credentials/IdentityCredential-v1.0.0.jsonld |
Term | Description | Full IRI |
---|---|---|
Credential Type | Declares what data to expect in the credential | https://www.w3.org/2018/credentials/v1 |
Credential ID | Identifier of the credential as a URN containing a unique UUID in version 4 UUID format such as the following example: urn:oci:uuid:6d7096c7-96ba-44e5-b448-ddd0364f6dc3 | https://www.w3.org/2018/credentials/v1 |
Issuer DID | Decentralized Identifier of the credential issuer | https://www.w3.org/2018/credentials/v1 |
Credential Issuance Date | Issuance date | https://www.w3.org/2018/credentials/v1 |
Credential Expiration Date | Expiration date | https://www.w3.org/2018/credentials/v1 |
Revocation | Details about mechanisms to check the credential status. | vc-status-2021-ldap:RevocationStatus2021LDAP |
Revocation ID | Location of revocation list | https://github.com/Spherity/vc-status-2021-ldap |
Revocation Type | Method for accessing revocation list | |
Credential Claim Type | Property describing the type of the subject | IdentityCredential |
Subject DID | Identifier of the subject holding the credential | https://www.w3.org/2018/credentials/v1 |
Issuer Signature | Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential | https://www.w3.org/2018/credentials/v1 |
Subject company/organization legal name. Entity that is able to send requests to other trading partners might not be a legal entity itself.
Term | legalName |
Full IRI | https://schema.org/legalName |
Credential Issuer company/organization legal name. Name of the legal Entity that issued the Credential to the subject.
Term | issuerName |
Full IRI | https://schema.org/legalName |
Legal entity of the Credential subjects parent organization.
Term | parentOrganization |
Full IRI | https://schema.org/parentOrganization |
The street address is expressed as free form text. The street address is printed on paper as the first lines below the name. For example, the name of the street and the number in the street or the name of a building.
Term | streetAddress |
Full IRI | https://schema.org/streetAddress |
Text specifying the name of the locality; for example, a city.
Term | addressLocality |
Full IRI | https://schema.org/addressLocality |
Text specifying a province or state in abbreviated format; for example, NJ.
Term | addressRegion |
Full IRI | https://schema.org/addressRegion |
Text specifying the postal code for an address.
Term | postalCode |
Full IRI | https://schema.org/postalCode |
Text specifying the country for an address.
Term | addressCountry |
Full IRI | https://schema.org/addressCountry |
As mentioned previously, there are three key groups for DSCSA interoperability: ATPs, ATP Equivalents, and Authorities. Each Stakeholder type has its own distinct schema: (1) the DSCSA ATP Credential, which represents and verifies a subject as an authorized trading partner; (2) the DSCSA ATP Equivalent Credential, which represents and verifies a subject as a trading partner that is not required to register with the FDA or obtain a State license; and (3) the DSCSA Authority Credential, which represents and verifies a subject as an authority as outlined under the statue or is generally recognized by industry (see OCI Conformance Criteria for Credential Issuers for more details).
Term | DSCSAATPCredential |
Full IRI | https://open-credentialing-initiative.github.io/schemas/credentials/DSCSAATPCredential-v1.0.0.jsonld |
Term | DSCSAATPEquivalentCredential |
Full IRI | https://open-credentialing-initiative.github.io/schemas/credentials/DSCSAATPEquivalentCredential-v1.0.0.jsonld |
Term | DSCSAAuthorityCredential |
Full IRI | https://open-credentialing-initiative.github.io/schemas/credentials/DSCSAAuthorityCredential-v1.0.0.jsonld |
While each credential type has its own schema, the same types of metadata and claims are shared across all three, unless otherwise noted below.
Term | Description | Full IRI |
---|---|---|
Credential Type | Declares what data to expect in the credential | https://www.w3.org/2018/credentials/v1 |
Credential ID | Identifier of the credential as a URN containing a unique UUID in version 4 UUID format such as the following example: urn:oci:uuid:6d7096c7-96ba-44e5-b448-ddd0364f6dc3 | https://www.w3.org/2018/credentials/v1 |
Issuer DID | Decentralized Identifier of the credential issuer | https://www.w3.org/2018/credentials/v1 |
Issuer | Name of the Credential Issuer | https://www.w3.org/2018/credentials/v1 |
Credential Issuance Date | Issuance date | https://www.w3.org/2018/credentials/v1 |
Credential Expiration Date | Expiration date | https://www.w3.org/2018/credentials/v1 |
Revocation | Details about mechanisms to check the credential status. | vc-status-2021-ldap:RevocationStatus2021LDAP |
Revocation ID | Location of revocation list | https://github.com/Spherity/vc-status-2021-ldap |
Revocation Type | Method for accessing revocation list | |
Credential Claim Type | Property describing the type of the subject | DSCSAATPCredential, DSCSAATPEquivalentCredential, or DSCSAAuthorityCredential |
Subject DID | Identifier of the subject holding the credential | https://www.w3.org/2018/credentials/v1 |
Issuer Signature | Digital proof mechanisms, a subset of which are digital signatures, are required to ensure the protection of a verifiable credential | https://www.w3.org/2018/credentials/v1 |
Type of credential subject: can be Manufacturer, Repackager, Wholesaler, 3PL, or Dispenser. Note that this claim is not present in the Authority credential. For more information about how Organization Type is ascribed to ATPs and ATP Equivalents, see section 5 of the Credential Issuer Conformance Criteria.
Under the DSCSA, a trading partner can fit into one or more categories, depending on their business practices. Only one Organization Type can be specified in a credential. In many cases, OCI expects that organizations will wish to have only a single Stakeholder credential with its single Organization Type. For example, a Wholesaler with 3PL and repackaging divisions may face up to the community as a Wholesaler, if that aligns with their business practices. This is because their primary business function is as a Wholesaler, and the sole use of a Wholesaler credential suits their needs (e.g. reduced complexity for IT and internal operations).
In other circumstances, a Stakeholder may select to have the option to present more than one role. If, for example, an entity is a Manufacturer and a Wholesaler, they may desire to have an ATP credential for each role (e.g. this may prevent the appearance that a manufacturer is seeking information on another manufacturer's products when it was their wholesale division seeking the information.) In this case, the Issuer would verify as part of their due diligence that the company is licensed for both roles, and issue two separate ATP credentials.
As this decision ultimately relies on Stakeholder business practices, OCI makes no recommendations with regard to multiple Stakeholder credentials.
Term | organizationType |
Full IRI | https://schema.org/additionalType |
Subject company/organization legal name. Entity that is able to send requests to other trading partners might not be a legal entity itself.
Term | legalName |
Full IRI | https://schema.org/legalName |
Credential Issuer company/organization legal name. Name of the legal Entity that issued the Credential to the subject.
Term | issuerName |
Full IRI | https://schema.org/legalName |
The street address is expressed as free form text. The street address is printed on paper as the first lines below the name. For example, the name of the street and the number in the street or the name of a building.
Term | streetAddress |
Full IRI | https://schema.org/streetAddress |
Text specifying the name of the locality; for example, a city.
Term | addressLocality |
Full IRI | https://schema.org/addressLocality |
Text specifying a province or state in abbreviated format; for example, NJ.
Term | addressRegion |
Full IRI | https://schema.org/addressRegion |
Text specifying the postal code for an address.
Term | postalCode |
Full IRI | https://schema.org/postalCode |
Text specifying the country for an address.
Term | addressCountry |
Full IRI | https://schema.org/addressCountry |
This attribute pair is OPTIONAL. it can be used to associate an identifier with the Subject DID of the credential. As an example, a company's GLN can be associated with their GLN which is used in TI/TS EPCIS events and PI Verification request and response messages. This can be used as an additional integrity check of the PI Verification request or response message as the Associated Identifier Value should match the Requester GLN or Responder GLN. It can also be used as an audit aid in collecting all communications about a product (connects EPCIS, PI Verifications, and future Trace messages).
Term | identifier |
Full IRI | https://schema.org/identifier |
Verifiable Presentations may be used to combine and present credentials. They can be packaged in such a way that the authorship of the data is verifiable. OCI generates a Verifiable Presentation after [[vc-data-model]] specification.
Term | Description | Full IRI |
---|---|---|
jti | This field represents the id property of the verifiable presentation being generated. | https://w3c.github.io/vc-data-model/#jwt-encoding |
iss | Represents the holder property of the verifiable presentation being generated. | https://w3c.github.io/vc-data-model/#jwt-encoding |
aud |
Verifiable Presentation Audience. We might include PI_Verification in this field to represent that this VP
is used in this context
We might include ATP_DSCSA in this field to represent that this VP is used in this context |
https://w3c.github.io/vc-data-model/#jwt-encoding |
iat | Issuance Date of the VP in EPOCH format | Used for determining whether or not the VP is valid by including the OCI validity time frame defined in Digital Wallet Conformance Criteria | https://w3c.github.io/vc-data-model/#jwt-encoding |
nbf | Issuance Date of the VC in EPOCH format | https://w3c.github.io/vc-data-model/#jwt-encoding |
exp | Expiration Date of the VC in EPOCH format | https://w3c.github.io/vc-data-model/#jwt-encoding |
vp | Contains the Verifiable Presentation | https://w3c.github.io/vc-data-model/#jwt-encoding |
vp.type | The type property is required and expresses the type of presentation, such as VerifiablePresentation. | https://w3c.github.io/vc-data-model/#presentations-0 |
vp.verifiableCredential | The VerifiableCredential (including all attributes) that are represented by this VP | https://w3c.github.io/vc-data-model/#presentations-0 |
nonce | Contains the corrUUID for which the VP has been generated for. | https://www.iana.org/assignments/jwt/jwt.xhtml |