v2.0.0

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede 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.

The purpose of this document is to clearly outline the conformance criteria for service providers who wish to be recognized by the Open Credentialing Initiative (OCI) as Credential Issuers.

Introduction

Intended Audience

The publication is intended for service providers who wish to be recognized by the Open Credentialing Initiative (OCI) as a Credential Issuer in the OCI interoperable environment, or for anyone associated with the pharmaceutical drug distribution industry who is interested in understanding the statutory definitions, regulatory guidances, and best practices for establishing Authorized Trading Partner ( ATP ) status under the US Drug Supply Chain Security Act (DSCSA).

History and Purpose of the Open Credentialing Initiative

The OCI was formed by a group of industry service providers, manufacturers, and wholesalers, and dispensers working together to design and deliver an electronic solution for the pharmaceutical industry to achieve compliance with FDA mandates for supply chain security. Upon successful demonstration of the technical solution, and acceptance by the participating manufacturers and wholesalers, the participants formed the OCI to further develop the solution into a set of tools that could be adopted and implemented across the industry.

The name OCI was chosen for the following reasons:

  • Open – Non-proprietary and interoperable. OCI is open to all providers, users, and standards organizations that support adoption of the integrated W3C standards and applicable NIST identity proofing standards. The interoperable tooling among service providers is open source.
  • Credentialing – A means of providing a credential (similar to a license or identity card that you carry in your digital wallet) that attests to the identity and status of its owner / holder.
  • Initiative – Indicates that the work is ongoing.
  • OCI supports pharmaceutical industry compliance with DSCSA requirements for ATP. Beyond supporting the adoption and standardization of the ATP architecture, OCI establishes a structure for running further credential-based pilots and incubation projects. For additional information, please see the Open Credentialing Initiative website.

    Roles in the OCI Ecosystem

    A credential is a digital assertion containing a set of claims (e.g., about a state license or FDA Establishment Identifier) made by an entity about itself or another entity. A subset of identity data, credentials are cryptographically signed and can be verified. Credentials can be used to create selective disclosures of information (known as “verifiable presentations”) to limit personal data exposure. The entity described by the claims is called the subject of the credential.

    A holder can refer to the subject, or to others who hold a credential on behalf of its subject, or to third parties authorized to cache or hold a credential that has been presented to them. The holder may or may not be the subject of the credential. Each supply chain actor has proven to be an Authorized Trading Partner. A Credential Issuer is an entity that creates a credential for use by its intended holder. 

    A relying party or verifier is generally the entity to whom a verifiable credential is presented (i.e., the party making decisions based on the claims and its degree of trust in the credential). A verifier requests a credential or proof from a holder and verifies it to make a trust decision about the subject entity.

    A Digital Wallet Provider provides Digital Wallets and services to create enterprise identities (DIDs) for Trading Partners (e.g. Manufacturer, Wholesaler, Dispenser) and Verifiable Credential Issuers. 

    A VRS service provider provides PI verify routing and saleable return verification requests and responses services. The VRS can act on behalf of the holder (when generating a verifiable presentation) or the verifier (when verifying a verifiable presentation).

    A Credential Issuer is an entity that issues Verifiable Credentials (VCs). Also known as a Credential Service Provider (CSP). The Credential Issuer is responsible for checking the status of such registrations and licenses prior to issuing VCs to wholesaler  and manufacturer entities.

    A regulatory body is an entity that establishes a legal requirement for the subject to be registered or licensed in a particular field (i.e., the FDA and States Board of Pharmacy for DSCSA ATP status, and other enforcement agencies as may be applicable).

    Regulatory Compliance – Federal Mandates

    The US Drug Supply Chain Security Act (DSCSA) has the objective of securing pharmaceutical drug distribution, from manufacturers all the way to pharmacies. For patient safety, it is essential to know that only trusted and authorized entities are involved in the manufacture, distribution, and dispensing of prescription drugs. In addition to verification, product tracing, and serialization requirements, each supply chain actor must ensure that its Trading Partners are authorized (including, in some cases, indirect Trading Partners).

    DSCSA requires that Trading Partners of manufacturers, wholesale distributors, dispensers, and repackagers meet the applicable requirements for being “authorized trading partners” (see sections 582(b)(3), (c)(3), (d)(3), and (e)(3) of the FD&C Act (21 U.S.C. 360eee-1); where “authorized” means registration in accordance with section 510 (manufacturers and repackagers), or having a valid license under State law (wholesalers and dispensers).

    Digital Ecosystems - Identity of Transacting Entities

    Verifying that an organization is “authorized” is enough to meet the letter of the law; however, in digital ecosystems it is also necessary to establish the identity of the organization. Thus, it becomes a two part process – is the counterparty who they say they are, and if so, are they “authorized”? To add to this challenge, DSCSA transactions for PI Verification and TI Tracing move through any number of intermediaries (solution providers, routing systems, etc.) all of whom fall under the Statute. In a digital ecosystem it is a matter of good design to limit the opportunity for information leaks, transaction replays, and tampering with the transaction or credential content throughout the ecosystem.

    Role of Credential Issuer

    While gathering information about an organization ATP status is relatively simple, ensuring that an ATP credential is being granted to the right entity, and not to an imposter, is more difficult. ATPs are subject to licensing at either the state or federal level, and the statuses of those licenses are a key gating feature of gaining ATP status. These licenses or registrations have a public component, which is both a benefit and a curse. While establishing that a given ATP exists is a requirement of credential issuance, the greater challenge is to validate an individual's claim to be that ATP's representative. By performing thorough and auditable due diligence, a Credential Issuer promotes confidence in a Trading Partner’s digital identity prior to the issuance of an ATP Credential. The Identity Credential becomes the Root of Trust upon which an ATP Credential can be issued.

    In the future, the Root of Trust could be instantiated on a higher level by establishing a body that certifies the Credential Issuers, and then issues verifiable credentials to them. As there are very few Credential Issuers in the initial phase of OCI, such a process is not necessary. OCI uses the DID:web method for the Credential Issuers as this is a method built upon proven, well-known instruments. The initial OCI implementation includes a registry with the names and DIDs of vetted Credential Issuers that have demonstrated and proven adherence with the OCI Credential Issuer Conformance Criteria.

    Purpose of Conformance Criteria

    The primary purpose of this publication is to communicate Conformance Criteria. Conformance Criteria establish the trusted processes that are to be followed for an organization to be recognized and accepted by OCI as a Credential Issuer. This ensures interoperability among all OCI-compliant service providers.

    Keywords

    The following keywords indicate the precedence and general rigidity of a given conformance criterion, and are to be interpreted as:

  • SHALL and SHALL NOT indicate strict requirements from which no deviation is permitted.
  • SHOULD and SHOULD NOT indicate preferred approaches; among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, but is not necessarily required, or that (in the negative form) a certain course of action is discouraged but not prohibited.
  • MAY and NEED NOT indicate possible and permissible approaches that are not necessarily preferred.
  • CAN and CANNOT indicate a capability, whether material, physical or causal or, in the negative, the absence of that capability.
  • Keywords appear in bold and ALL CAPS in the Conformance Criteria.

    Terms and Abbreviations

    The following terms and abbreviations appear throughout this publication:

    Conformance through recognized standards (W3C, NIST )

    Credential Issuers desiring to participate in DSCSA initiatives that were designed, tested, and proven by OCI can begin by understanding and embracing the underlying open standards for credential formatting (W3C) and identity proofing ( NIST ). While neither is specified by statute or FDA guidance, NIST is a division of the US Department of Commerce and a trusted FDA partner, and W3C is an internationally recognized standards body. These standards serve as anchoring points for the OCI to establish an identity ecosystem that is fit for purpose.

    W3C Standards for Credential Formatting

    About (W3W)

    The World Wide Web Consortium (W3C) is an international community where member organizations, a full-time staff, and the public work together to develop Web standards. One of the many standards put forth by the consortium establishes generally accepted formats for verifiable credentials. The abstract from the W3C website Verifiable Credentials Data Model page states:

    “Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.”

    For more information, please visit the Verifiable Credentials page on the W3C website.

    Credential Structure

    Working groups at the W3C author, host, and maintain the W3C Verifiable Credential Data Model 1.0 specification. This W3C VC Standard is now a W3C recommendation (the most mature stage of the W3C standards process). Verifiable credentials (VCs) are issued against identifiers that may be associated with cryptographic operations, be they DIDs, self-certifying identifiers, or legacy identities backed with traditional PKI. The structure of a VC is an important component of interoperability.

    OCI relies on an implementation of a common standard for the credential structure. Credential Issuers SHALL implement Verifiable Credential Data Model 1.0.

    At time of writing, there are only early, non-standard and experimental implementations that combine traditional PKI with VCs and DIDs. Therefore Credential Issuers SHALL implement DIDs as cryptographic identifiers. It SHALL be understood that DIDs can be blended with X.509 within the Identity Verification Process in the form of wrapped or nested credentials.

    Credential Serialization & Schemas

    Credentials that are issued by the Credential Issuer are created in accordance with the W3C JSON-LD format for schema serialization. To ensure processing, validation, and interpretation of verifiable credentials by different implementers, JSON-LD schemas for Identity and ATP credentials are introduced. Credential Issuers SHALL support the JSON-LD format and JSON-LD schema validation.

    Credential Issuers SHALL have mechanisms in place to support multiple valid versions of credential schemas endorsed and published by OCI. Such a mechanism will allow handling transition periods when new credential schema versions are released and the industry has to adopt changes to schemas. It shall be understood that there can be multiple active schema versions; decommissioned and revised versions can have an expiration date. Decommissioned schema versions SHALL return an error by the ATP credential verification API.

    The OCI SHALL document and publish a list of approved (active), revised, and decommissioned versions of the Identity and ATP Credential schemas on https://github.com/Open-Credentialing-Initiative. Credential Issuers SHALL follow the schema requirements published by OCI for.

    Digital Wallet Providers SHALL support the OCI approved credential schema for processing, validation and interpretation that are published on the OCI Github for the Identity Credential and the DSCSA ATP Credential.

    Outlook

    GS1 maintains a web vocabulary which is designed to extend the work done by schema.org and make use of similar concepts (Product, Offer, Organization), extending them with many more details. As the definitions defined in the vocabulary are already used in attributes of GS1 B2B messages and EPCIS events, OCI is working with GS1 to normalize the definitions of the OCI credential schemas.

    In the future, OCI may decide to move the credential schemas to a GS1 schema repository (e.g. GS1 web vocabulary on Github). To be consistent with GS1 requirements, OCI might want to introduce further validation instruments such as SHACL. If and when these changes happen, Credential Issuers SHOULD support the GS1 schema repository and the SHACL instruments.

    NIST Standards for Identity Proofing

    The National Institute of Standards and Technology (NIST) was founded in 1901 and is now part of the U.S. Department of Commerce. One of the nation's oldest physical science laboratories, NIST was established by Congress to remove a major challenge to U.S. industrial competitiveness. One of the many standards put forth by NIST establishes generally accepted methods for a CSP to prove the identity of a subject. The full set of standards can be found in Section 2 of NIST Special Publication 800-63A. The core concepts are included in the three excerpts below:

    Expected Outcomes of Identity Proofing

    When a subject is identity proofed, the expected outcomes are:

    1. Resolve a claimed identity to a single, unique identity within the context of the population of users the CSP serves.
    2. Validate that all supplied evidence is correct and genuine (e.g., not counterfeit or misappropriated).
    3. Validate that the claimed identity exists in the real world.
    4. Verify that the claimed identity is associated with the real person supplying the identity evidence.

    Security, Privacy, and Fraud Detection Measures

    The Credential Issuer SHALL conform to section 4.2 General Requirements of NIST SP800-63A.

    Identity Assurance Levels

    NIST defines three different levels of assurance regarding identity. These standards can be found in Section 4 of NIST Special Publication 800-63A. The level chosen by a CSP is based on the requirements of the specific use case. The three levels are:

    • Identity Assurance Level 1 (IAL1) – There is no requirement to link the applicant to a specific real-life identity. Any attributes provided in conjunction with the subject’s activities are self-asserted or should be treated as self-asserted (including attributes a CSP asserts to an RP ). Self-asserted attributes are neither validated nor verified.
    • Identity Assurance Level 2 (IAL2) – Evidence supports the real-world existence of the claimed identity and verifies that the applicant is appropriately associated with this real-world identity. IAL2 introduces the need for either remote or physically-present identity proofing. Attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes.
    • Identity Assurance Level 3 (IAL3) – Physical presence is required for identity proofing. Identifying attributes must be verified by an authorized and trained CSP representative. As with IAL2, attributes could be asserted by CSPs to RPs in support of pseudonymous identity with verified attributes. A CSP that supports IAL3 can support IAL1 and IAL2 identity attributes if the user consents.

    Broadly speaking, under OCI all Credential Issuers are required to achieve both a minimum standard of due care as well as perform vigilant checks on revocable events. While technological progress and human ingenuity are difficult to predict, some approaches are clearly inadequate – a chain is only as strong as its weakest link. Self-reporting is clearly inadequate, and excessive gathering of weak evidence creates unnecessary risk for stakeholders.

    In principle, the evidence to support a credential should be strong (secret information that only a valid applicant would have), verifiable (difficult and risky to falsify), and minimal (the minimum number of secrets to transfer, hold, and verify).

    IAL1, the lowest level of identity proofing, is not appropriate for the DSCSA use case. DSCSA regulations specify that you must confirm that the trading partner is authorized. Failure could result in penalties including fines, imprisonment, and/or suspension or revocation of licenses. If the identity of the trading partner is self-asserted, then even if a CSP goes to an official source to check licenses or registrations for “authorized trading partner” status, that status would also be considered as self-asserted because it is based on a self-asserted identity. Therefore, one cannot confirm whether the party on the other end of a DSCSA transaction is an ATP .

    IAL2, the mid level of identity proofing, is suitable as an anchoring point for DSCSA requirements. Details are included in the next Section.

    IAL3, the highest level of identity proofing, is a higher degree of assurance that far exceeds DSCSA requirements. It would come at a substantially higher price, which is unnecessary for the DSCSA use case.

    Evidence for Identity proofing based on NIST IAL2

    Evidence Quality – Superior, Strong, and Fair

    In order to issue an Identity Credential to an Entity/Company, sufficient evidence is required to prove the:

    Section 4.4.1.2 (Evidence Collection Requirements) of NIST Special Publication 800-63A states:

    The above rules apply to both the Organization and its Representative.

    The NIST standards are written to a broad variety of use cases, and therefore do not specify particular evidence needed under the DSCSA use case. Section 5.2.1 of the NIST publication contains helpful information on how to assess the strength of identity evidence. For example, a strength of SUPERIOR requires, among other things, that:

    A strength of STRONG requires, among other things, that:

    The above bullet points are just a few excerpted examples to illustrate subtle differences between identity strengths. Please consult the NIST publication for a more complete set of guidelines. Because the NIST publication does not delineate particular evidence for the DSCSA use case, the writing of this conformance criteria publication required analyzing the NIST material against the DSCSA requirements, and researching due diligence processes of other identity proofing use cases. What follows is the result of this research and analysis process.

    Examples of the Use of One Piece of Strong Evidence

    DEA Signing Certificate

    Use of the DEA Signing Certificate alone meets the NIST standard of “One piece of SUPERIOR or STRONG evidence” for Identity Assurance Level 2 (IAL2). The Credential Issuer validates the evidence directly with the issuing source through the certificate itself, which is a set of encrypted codes generated by the issuing source (DEA), which cannot be modified or replicated by another party. In addition, misrepresentation of a DEA Signing Certificate is a prima facie offense where no further fraud, misrepresentation, or unauthorized access is needed for the authorities to pursue action against an offender. It's one thing to lie to a [=Credential=] Issuer, but it's an entirely different level of risk to steal a DEA number.

    The DEA Signing Certificate not only validates the existence and identity of the organization, but also validates the identity and authority of the representative. It is therefore the quickest and simplest method for complete identity proofing. Nothing from this point on in this Section 4 on Evidence for Identity Proofing is required if the DEA Signing Certificate is used.

    The DEA reassures registrants that the use of the DEA Signing Certificate is perfectly acceptable for this purpose; it was foreseen and specifically allowed for by the DEA in their policy manual CSOS Certificate Policy , Version 4.1, January 2015, section 1.4.1 Appropriate Certificate Uses:

    • CSOS Subscriber certificates shall only be issued to entities engaged in the transfer of controlled substances between manufacturers, distributors, retail pharmacies, authorizing institutions and other registrants and must be used for the signing of electronic transaction orders. However, the use of CSOS certificates is not restricted to this single application.
    • CSOS certificates are appropriate for use with other applications requiring a Medium level of assurance or below, as defined by the Federal Bridge Certification Authority (FBCA). This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.

    National Provider Identifier

    Use of the NPI registration alone meets the NIST standard of “One piece of SUPERIOR or STRONG evidence” for Identity Assurance Level 2 (IAL2). The Credential Issuer validates the evidence directly with the issuing source (National Council for Prescription Drug Programs (NCPDP)) by retrieving the registration information from the NCPDP database.

    The NPI registration not only validates the existence and identity of the organization, but also provides evidence toward validation of the identity and the authority of the representative. There is still a need to validate that the applicant representing the organization is the same person that is listed in the NPI registration. This step is covered in Section 4.5.

    Examples of the Use of Multiple Pieces of Strong or Fair Evidence

    If an organization does not have a singular qualifying superior or strong identify evidence, the alternative is for them to gather and submit offical documents to the CSP to prove the existence and identity of the organization. In addition, the applicant representing the organization must submit documentation to prove their individual identity, as well as their authority to act on behalf of the organization.

    IMPORTANT NOTE: Simply collecting documents or identification numbers does not constitute identity proofing. Due diligence is required to thoroughly validate the collected documents and identification numbers.

    Existence and Identity of the Organization

    Organization Name

    As a first step to analyzing the organization documents submitted by the applicant, the Credential Issuer SHOULD attempt to locate a government-issued license or registration (using the license/registration information given by the applicant) OR a listing for the organization (using the organization name given by the applicant) on the Better Business Bureau website ( www.bbb.org ), the chamberofcommerce.com website, or the local Chamber of Commerce website where the applicant organization resides (found by searching the Internet).

    Company Address of Record

    As specified in NIST SP800-63A section 4.4.1.6, the Credential Issuer SHALL validate the organization's address. The mailing address and phone number MAY be considered validated and confirmed (as address of record) by the processes in section 4.4.1 above if the address from one of those sources matches the address on the corporate document(s) submitted by the applicant. If they match, then the phone number (if available) from the above-mentioned sources(s) can be considered as reliable as the mailing address for communication purposes. The ability to communicate with the applicant via phone (as opposed to mailing address) can expedite the identity proofing process.

    If the company name and address of record cannot be verified through one of the sources listed in 3.4.1, then the Credential Issuer SHALL request from the applicant a copy of a recent (no more than 3 months old) bank statement, utility bill, industry trade publication / letter, or other official piece of business mail that displays the organization’s name and address. The mailing address from this document SHALL become the address of record. Note that this process does not allow a phone number to be verified as part of the address of record; thus, later steps of the due diligence process SHALL be transacted via mail, and SHALL NOT be transacted via phone.

    Another way to expedite the communication process is to use a verified email address. This can be accomplished if the applicant has an email address within the organization’s domain, and the Credential Issuer can reasonably ascertain that the domain belongs to the organizations through one of the following:

    • If the domain registration record is accessible and the owner information can be retrieved and confirmed;
    • If the Chamber of Commerce website includes the organization’s website address; or
    • If the applicant provides a link to a page on the organization’s website where the displayed organization name and address (and phone number if present) match the address of record (see above) established thus far.

    Articles of Incorporation

    A copy of the Articles of Incorporation can be viewed online and downloaded by anyone inside or outside the organization; therefore, a copy of the document that looks exactly like the one on the website is considered by NIST to be WEAK evidence for proving identity because it does not meet the following criteria: “The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the applicant.” However, a recent scan of the original document that looks slightly different (coloration, positioning of pages, and the like) from the one on the website would indicate that the original document is in the hands of the applicant, and it could qualify as STRONG depending on other factors, such as the name and address of the organization’s “Registered Agent” on the document.

    The [=Credential=] Issuer SHALL go to the Secretary of State’s (or other authority’s) website and retrieve the publicly available copy of the document to compare it with the one submitted by the applicant. If the applicant IS also the Registered Agent, then this document would qualify as one STRONG piece of evidence even if the document looks like it was simply downloaded from the website. If the applicant is someone other than the Registered Agent, then this would still qualify as one STRONG piece of evidence if it looks authentic (not just downloaded from the website) and the address matches the applicant’s address. Otherwise it would be considered a FAIR piece of evidence as long as the address matches. If the address doesn’t match, then it would be considered WEAK and unusable as evidence.

    IRS Employer ID Number (EIN) Letter

    The original EIN letter (form CP 575) was mailed by the IRS to the address specified on the application form SS-4, and is not downloadable from a website. Therefore, it would be quite difficult for someone not associated with the organization to get a copy of this document. An organization can get a replacement (147c letter) by knowing the EIN, name and address of business, and phone number of business; if the contact info has not changed since the original application for the EIN, the IRS will mail or fax it to the original contact. If the contact info has changed, you must file form 8822. Thus, it is reasonable to conclude that either the CP 575 copy or the 147c copy meets the following criteria: “The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the applicant.”.

    If the document is faxed to the [=Credential=] Issuer from a fax number that matches the fax number on the document, it would qualify as one STRONG piece of evidence. If the document is uploaded, it would qualify as one STRONG piece of evidence if the address matches the applicant’s address. If the address doesn’t match, then it would be considered WEAK and unusable as evidence.

    A business license or permit, a notice from the IRS, or some official paperwork from a bank where the organization opened an account might also have the organization’s EIN on it. Such documents could be evaluated for consideration as FAIR evidence for proof of identity if the EIN Letter itself cannot be provided.

    Data Universal Numbering System (DUNS) number

    The DUNS number can be easily retrieved online for any organization by anyone outside the organization; therefore, the number itself is considered by NIST to be WEAK evidence for proving identity because it does not meet the following criteria: “The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the applicant.”.

    However, this number can still be useful as evidence because the address and phone number of the organization are associated with the DUNS number. The [=Credential=] Issuer can look up the information on the:

    to ensure that the name and address match those on other proofing documents. This would qualify as one FAIR piece of evidence. Then, the [=Credential=] Issuer can consider the phone number listed on the D&B website to be valid for communicating with the applicant.

    Global Location Number (GLN)

    The GLN can be easily retrieved online for any organization by anyone outside the organization; therefore, the number itself is considered by NIST to be WEAK evidence for proving identity because it does not meet the following criteria: “The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the applicant.”.

    However, this number can still be useful as evidence because the address of the organization is associated with the GLN. The [=Credential=] Issuer can go to the GS1 website ( https://gepir.gs1.org/index.php/search-by-party-name ) and look up the organization name or GLN to ensure that the name and address match those on other proofing documents. This would qualify as one FAIR piece of evidence.

    Legal Entity Identifier (LEI)

    The LEI can be easily retrieved online for any organization by anyone outside the organization; therefore, the identifier itself is considered by NIST to be WEAK evidence for proving identity because it does not meet the following criteria: “The issuing process for the evidence means that it can reasonably be assumed to have been delivered into the possession of the applicant.”.

    However, this identifier can still be useful as evidence because the address of the organization is associated with the LEI. The [=Credential=] Issuer can go to the GLEIF website (search.gleif.org) and look up the organization name to ensure that the name and address match those on other proofing documents. This would qualify as one FAIR piece of evidence.

    [=Credentials=] from Another Issuer

    As the use of verifiable credentials grows across the industry, the possibility will arise for using other, as-of-yet-unidentified credentials as evidence and as a basis for issuing an Identity [=Credential=]. OCI will provide a list of other credentials that could be used for proving identity as they are discovered over time.

    Identity and Authority of the Representative

    Representative’s Identity – Photo ID, Notary, Live Video Appearance

    The applicant, as a Representative of the organization, SHALL provide his or her full name, mailing address at the organization, email address at the organization, phone number at the organization, a copy of a government-issued photo ID, and either:

    • a notarized copy of a [=Credential=] Request Letter (provided by the [=Credential=] Issuer) attesting that the documents being submitted for the identity proofing are true and accurate; or
    • a live appearance in front of a computer or phone with a camera that allows the [=Credential=] Issuer identity proofing application to capture a photo or video of the applicant.

    In the case of using a notarized document, the notary verifies that the Representative’s photo ID matches their face. Then the Issuer SHALL verify the notary through the Secretary of State’s website or by phoning the office for the state in which the notary operates. As an alternative, a copy of the notary’s certificate, showing their ID number, date of authorization, and date of expiration, can be accessed through the National Register of Notaries (a paid service.).

    In the case of the Representative appearing on a live camera, the [=Credential=] Issuer SHALL capture an image of the Representative, and match it against the Representative’s photo ID.

    Representative’s Authority – Enrollment Code via Validated Mail, Email, Phone

    As specified in NIST SP800-63A section 5, if the CSP ([=Credential=] Issuer) performs remote proofing (unsupervised):

    1. The CSP SHALL send an enrollment code to a confirmed address of record for the applicant.
    2. The applicant SHALL present a valid enrollment code to complete the identity proofing process.
    3. The CSP SHOULD send the enrollment code to the postal address that has been validated in records. The CSP MAY send the enrollment code to a mobile telephone (SMS or voice), landline telephone, or email if it has been validated in records.

    The Enrollment Code SHALL be, at minimum, a random 6-character alphanumeric code.

    Authorized Trading Partner (ATP) [=Credential=] Due Diligence

    In order to issue an ATP [=Credential=], sufficient evidence SHALL be gathered and documented regarding the identity of the Applicant and the status of the regulator-issued license (i.e. Board of Pharmacy, BOP) or registration record (FDA). The due diligence process SHALL include five checks:

    Check 1: Identity Credential Verification

    The [=Credential=] Issuer SHALL request a verifiable presentation of the Applicant’s Identity Credential. If a valid Identity Credential presentation cannot be verified, the [=Credential=] Issuer SHALL NOT proceed with ATP [=Credential=] issuance. A valid Identity Credential is one that is issued:

    Check 2: Organization Name Comparison

    The [=Credential=] Issuer SHALL employ logic to match the organization name on the Identity Credential against the organization name on the regulator-issued license or registration record (BOP or FDA) to ensure that the license or registration belongs to that organization. If the names do not match, the organization’s application for ATP credential SHALL be further scrutinized to determine if the ATP credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.

    Check 3: Address Comparison

    A [=Credential=] Issuer SHALL employ logic to match the organization address on the Identity Credential against the organization name on the regulator-issued license or registration record (BOP or FDA). If the addresses do not match, the organization’s application for ATP credential SHALL be further scrutinized to determine if the ATP credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.

    Check 4: Expiration Date Check

    The [=Credential=] Issuer SHALL check the expiration date on the regulator-issued license to ensure that the license is in good standing. If the date is in the past or is not found, the company’s application for ATP credential SHALL be further scrutinized to determine if the ATP credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.

    Check 5: License Status Check

    The [=Credential=] Issuer SHALL check (for wholesalers and dispensers) the BOP-issued license status. (Manufacturers are not subject to this check, as the FDA does not provide a “status” for FDA Establishment Identifier (FEI) Registrations.) This check SHALL include querying the most recent possible version of the regulatory board’s data source. Some boards refresh their data as frequently as daily, but none refreshes their data less frequently than monthly. Therefore, the License Status query SHALL be against BOP data that is no more than one month old.

    If the License Status is not interpreted to be “Active”, the organization’s application for ATP credential SHALL be further scrutinized to determine if the ATP credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.

    Note: With 150+ different assigned statuses across the state regulatory bodies (such as boards of pharmacy, etc.) the state regulatory bodies can communicate what is considered “Active” among the simple, straightforward statuses as well as more complex statuses that are subject to interpretation.

    Check Summary

    Once passing Check 1, every ATP request for:

    1. Wholesaler or Dispenser must pass checks 2, 3, 4, and 5.
    2. Manufacturer must pass checks 2, 3, and 4.

    In the future, exceptions might be added. For example, a well-known corporation with many license locations PASSES all of the below checks:

    but FAILS Check 3 - Address Comparison.

    Technology Conformance Criteria

    General Requirements

    A Credential Issuer SHALL:

    Credential Revocation

    In the future, OCI can potentially support multiple methods for communicating when a credential has been revoked. At the current stage, OCI supports a proven revocation management method based on LDAP CRLs. Credential Issuers SHALL implement the OCI Directory Service (LDAP) based mechanism for determining if a Verifiable Credential has been revoked (vc-status-2021-ldap). 

    Digital Wallet Providers are allowed to implement a caching mechanism for credential revocation data to cache LDAP data for up to 24 hours. Existing cached data can be used to speed up revocation list checking, and can also be used when the OCI Directory Service is not available due to technical / communication issues. Credential revocation data SHALL not be older than 24 hours during normal operations of the OCI Directory Service. 

    Identity Credential Monitoring and Expiration

    An Identity Credential SHALL expire one year from the date it is issued. The expiration date indicates when the credential is no longer monitored, after which it SHALL be considered invalid. During this one-year term, the [=Credential=] Issuer SHALL perform continuous monitoring (on at least a weekly basis) to identify possible triggers for revocation / recertification.

    Triggers for Identity Credential Revocation/Recertification

    The following triggers are given a 30 day grace period to be resolved. If the issue has not been resolved by the credential’s expiration date, the credential will remain valid for an additional 30 days before being revoked.

    Identity Credential Audit Trail

    The [=Credential=] Issuer SHALL keep detailed records of all Identity [=Credential=] issuance and monitoring activities for a period of not less than six (6) years. These detailed records are considered to be an audit trail that can be used in the event an investigation is conducted into credential-related activities of the credential owner.

    For Identity Credential issuance, the audit trail SHALL include copies of all original source data used by the [=Credential=] Issuer in conducting the due diligence to determine the existence and identity of the corporation, and the authority of the representative. In addition, all notes, decisions, and actions taken by the [=Credential=] Issuer as part of the approval process must be captured and stored as part of the audit trail. Finally, the digital signature of the individual who was responsible for conducting the due diligence must be applied to the issued credential to ensure that accountability can be tracked to an individual in the [=Credential=] Issuer’s organization.

    For Identity Credential monitoring, the audit trail SHALL include copies of any documents, or screenshots of any websites, that were reviewed to identify acquisitions, mergers, name changes, or address changes; all attributes associated with any other relevant revoked credentials; and all notes, decisions, and actions taken by the [=Credential=] Issuer as part of the monitoring process.

    ATP [=Credential=] Monitoring and Expiration

    An ATP [=Credential=] SHALL expire one year from the date it is issued. The expiration date indicates when the credential is no longer monitored, after which it SHALL be considered invalid. During this one-year term, the [=Credential=] Issuer SHALL perform continuous monitoring to identify possible triggers for revocation / recertification.

    Triggers for ATP [=Credential=] Revocation/Recertification

    ATP [=Credential=] Audit Trail

    The [=Credential=] Issuer SHALL keep detailed records of all ATP [=Credential=] issuance and monitoring activities for a period of not less than six (6) years. These detailed records are considered to be an audit trail that can be used in the event an investigation must be conducted into credential-related activities of the credential owner.

    For ATP [=Credential=] issuance, the audit trail SHALL include capturing all Identity Credential attributes, the original source License Data, and all notes, decisions, and actions taken by the [=Credential=] Issuer as part of the approval process.

    For ATP [=Credential=] monitoring, the audit trail SHALL include all attributes from the valid Identity Credential located in the credential owner’s digital wallet; copies or screenshots of the name and address from the license or registration, and copies or screenshots of the associated attributes on the ATP [=Credential=]; copies or screenshots of the License Expiration Date and License Status from the regulatory body’s source data (if applicable); and the current copies of any documents, or screenshots of any websites, that were reviewed to identify acquisitions, mergers, name changes, or address changes; all attributes associated with revoked credentials that are relevant; and all notes, decisions, and actions taken by the [=Credential=] Issuer as part of the monitoring process.

    Organization Controls

    Third Party Audit

    This section will contain detailed information about the third party audit requirements once it is decided who the audit company will be and what process will be followed.

    Documentation

    It is RECOMMENDED that the Credential Issuer offers the following documentation to support any audit/validation process: