Copyright © 2023 Named editors. Contributors to the Open Credentialing Initiative.
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, Authorities, 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.
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.
This document specifies the Conformance Criteria for a Credential Issuer.
For a general introduction to OCI, please refer to our Getting Started guide or the Open Credentialing Initiative website.
While gathering information about an organization's DSCSA status (e.g. ATP, ATP Equivalent, or Authority) is relatively simple, ensuring that a Stakeholder 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 Stakeholder exists is a requirement of credential issuance, the greater challenge is to validate an individual's claim to be that Stakeholder's representative. By performing thorough and auditable due diligence, a Credential Issuer promotes confidence in a Stakeholder’s digital identity prior to the issuance of a Stakeholder Credential. The Identity Credential becomes the Root of Trust upon which a Stakeholder 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.
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.
The following keywords indicate the precedence and general rigidity of a given conformance criterion, and are to be interpreted as:
Keywords appear in bold and ALL CAPS in the Conformance Criteria.
The following terms and abbreviations appear throughout this publication:
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.
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.
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.
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 Stakeholder 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 Stakeholder credential verification API.
The OCI SHALL document and publish a list of approved (active), revised, and decommissioned versions of the Identity and Stakeholder Credential schemas on https://github.com/Open-Credentialing-Initiative. Credential Issuers SHALL follow the schema requirements published by OCI.
Credential Issuers SHALL be capable of issuing at least one of the types of credentials indicated below:
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.
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:
When a subject is identity proofed, the expected outcomes are:
The Credential Issuer SHALL conform to section 4.2 General Requirements of NIST SP800-63A.
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:
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 DSCSA 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.
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 issuing source of the evidence confirmed the claimed identity through written procedures designed to enable it to form a reasonable belief that it knows the real-life identity of the person. Such procedures are subject to recurring oversight by regulatory or publicly-accountable institutions.
The issued evidence contains a photograph or biometric template (of any modality) of the person to whom it relates OR the applicant proves possession of an AAL2 authenticator, or equivalent, bound to an IAL2 identity, at a minimum.
Where the issued evidence includes digital information, that information is protected using approved cryptographic or proprietary methods, or both, and those methods ensure the integrity of the information and enable the authenticity of the claimed issuing source to be confirmed.
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 pertaining to non-governmental entities.(As such, the examples below do not include examples of evidence that might be provided to demonstrate Authority or ATP-equivalent status, as this may vary widely depending on a number of factors). What follows is the result of this research and analysis process.
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:
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.
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.
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).
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/organization 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:
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.
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.
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.
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.
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.
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.
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:
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.
As specified in NIST SP800-63A section 5, if the CSP ([=Credential=] Issuer) performs remote proofing (unsupervised):
The Enrollment Code SHALL be, at minimum, a random 6-character alphanumeric code.
Note that in this section "DSCSA Authority" refers to governmental organizations (e.g. FDA), while "authority" refers to a representative's entitlement to represent a given organization.
In the case of an application for a DSCSA Authority or ATP Equivalent credential, the CSP SHALL ascertain the applying Representative’s authority to represent the organization in question. How this requirement is to be fulfilled depends on whether the DSCSA Authority List or DSCSA ATP Equivalent List (as applicable; see Section 5.7) enumerates designated Representative(s) (e.g. a person, group of persons, department, minimum seniority level, etc.) for the organization as a whole:
If either of the two above conditions is met, the applying Representative has passed the authority check. Note that these requirements only apply to CSPs issuing credentials; access to the Digital Wallet is defined by the Stakeholder organization (i.e. an Authority may wish to allow employees of a department to access wallet functionality).
In order to issue a Stakeholder [=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), registration record (FDA), DSCSA Authority List entry, or DSCSA ATP Equivalent List entry. The due diligence process SHALL include the checks outlined below.
It should be noted that different Stakeholder types are exempt from some checks; see section 5.7.
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 Stakeholder [=Credential=] issuance. A valid Identity Credential is one that is issued:
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 (e.g. BOP, FDA) to ensure that the license or registration belongs to that organization. If the names do not match, the organization’s application for Stakeholder credential SHALL be further scrutinized to determine if the Stakeholder credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.
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 (e.g. BOP, FDA). If the addresses do not match, the organization’s application for Stakeholder credential SHALL be further scrutinized to determine if the Stakeholder credential can be issued. Subsequent scrutiny and the basis of any decision SHALL be documented as part of the audit trail.
For ATPs, the [=Credential=] Issuer SHALL check the expiration date on the State BOP-issued license (for wholesalers, [=3PL=]s, and dispensers) and expiration on the FDA registration (for manufacturers & repackagers) to ensure that the license/registration 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.
For ATPs, the [=Credential=] Issuer SHALL check the State BOP-issued license status (for wholesalers, 3PLs, and dispensers) and the FDA registrations status (for manufacturers, repackagers, wholesalers, and 3PLs). 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 and FDA 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.
For ATPs, the [=Credential=] Issuer SHALL check (for wholesalers and 3PLs) the reporting year. Manufacturers, repackagers, and dispensers are not subject to this check, as the State-BOPs do not provide a “Reporting Year” for state-issued licenses.) This check SHALL include querying the most recent possible version of the FDA's Wholesale Distributor and Third-Party Logistics Providers Reporting data.
If the Reporting Year is not interpreted to be “Current” according to the FDA's Annual Reporting Requirements, 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.
For [=ATP Equivalents=], the Credential Issuer SHALL check the latest ATP-Equivalent Entities list. At time of writing, this list is contained within the PDG Foundational Blueprint for 2023 Interoperability Chapter 6: DSCSA Credentialing and User Authentication Functional Design (page 35), and as excerpted below comprises:
Note that as ATP Equivalents are by definition not subject to standard DSCSA licensure requirements, the Organization Type in the ATP Equivalent credential is specified by the ATP Equivalent applicant based on the applicant's attestation to the Credential Issuer.
For Authorities, the Credential Issuer SHALL check the latest DSCSA Authorities list. At time of writing, this list is contained within the PDG Foundational Blueprint for 2023 Interoperability Chapter 6: DSCSA Credentialing and User Authentication Functional Design (page 35), and as excerpted below comprises:
In the future, it is anticipated that these lists will be managed in a separate format.
Once passing Check 1, a Stakeholder must pass the following checks as applicable:
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.
A Credential Issuer SHALL:
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.
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.
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.
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.
A Stakeholder [=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.
The [=Credential=] Issuer SHALL keep detailed records of all Stakeholder [=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 Stakeholder [=Credential=] issuance, the audit trail SHALL include capturing all Identity Credential attributes, the original source License Data (if applicable), and all notes, decisions, and actions taken by the [=Credential=] Issuer as part of the approval process.
For Stakeholder [=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 (if applicable), and copies or screenshots of the associated attributes on the Stakeholder [=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.
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.
It is RECOMMENDED that the Credential Issuer offers the following documentation to support any audit/validation process: