v1.2.0

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.)

Status of this 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.

Introduction

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.

OCI Verifiable Credential Design Principles

The OCI defines these design principles to narrow down the attributes included in the credential schema to OCI supported use cases.

Include credential attributes that do not relate to internal tracking or due diligence activities

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 included

Include attributes enabling credential consuming applications to perform logic and/or operational validation checks.

An 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 structure

Enable credential integrity checks

The 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.

Terminology

Vocabulary

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

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

Identity Credential Metadata

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

Claim: Subject Name

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

Claim: Issuer Name

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

Claim: Subject Parent Organization

Legal entity of the Credential subjects parent organization.

Term parentOrganization
Full IRI https://schema.org/parentOrganization

Claim: Street Address

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

Claim: Address Locality

Text specifying the name of the locality; for example, a city.

Term addressLocality
Full IRI https://schema.org/addressLocality

Claim: Address Region

Text specifying a province or state in abbreviated format; for example, NJ.

Term addressRegion
Full IRI https://schema.org/addressRegion

Claim: Postal Code

Text specifying the postal code for an address.

Term postalCode
Full IRI https://schema.org/postalCode

Claim: Country

Text specifying the country for an address.

Term addressCountry
Full IRI https://schema.org/addressCountry

Example Identity Credential

DSCSA Stakeholder Credential Schemas

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.

DSCSA Stakeholder Credential Metadata

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

Claim: Organization Type

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

Claim: Subject Name

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

Claim: Issuer Name

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

Claim: Street Address

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

Claim: Address Locality

Text specifying the name of the locality; for example, a city.

Term addressLocality
Full IRI https://schema.org/addressLocality

Claim: Address Region

Text specifying a province or state in abbreviated format; for example, NJ.

Term addressRegion
Full IRI https://schema.org/addressRegion

Claim: Postal Code

Text specifying the postal code for an address.

Term postalCode
Full IRI https://schema.org/postalCode

Claim: Country

Text specifying the country for an address.

Term addressCountry
Full IRI https://schema.org/addressCountry

Claim: Subject Associated Identifier

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

Example DSCSA-ATP-Credential

Verifiable Presentation of DSCSA Stakeholder Credentials

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.

Verifiable Presentation Metadata

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

Example Verifiable Presenations