This section describes the status of this document at the
time of its publication. Other documents may supersede this
document.
This is a living OCI Document developed by OCI Members with input
from relevant interested parties. It is anticipated that the contents of this document will be reviewed and
updated to address any applicable feedback. A list of current public OCI Documents, including Conformance Criteria, can
be found in OCI's GitHub repositories.
This document lays out OCI’s expectations of ecosystem participants and conformance auditors with respect to OCI Conformance Criteria.
Purpose
OCI sets Conformance Criteria for participant groups within the OCI ecosystem. This Conformance Program lays out the framework for OCI’s monitoring of participants’ adherence to these criteria.
This Program sets OCI’s expectations of ecosystem participants and conformance auditors, the scope of OCI’s involvement in the conformance audit process as well as expectations about audit outcome and processes in reaction to possible audit results.
Operationally, OCI’s goal is to achieve service reliability and true interoperability among service providers. Overall, this Conformance Program is to provide assurance to industry users within the wider OCI ecosystem that they will be in compliance with the letter and intent of FDA and DSCSA if they participate in this ecosystem.
General Terms and Abbreviations
Good standing: An organization in good standing is regarded as having complied with all their explicit legal obligations, be financially sound, while not being subject to any form of sanction, suspension or disciplinary censure. A business entity that is in good standing has unabated powers to conduct its activities, which can include business endeavors.
The following OCI Service Providers SHALL undergo a formal third-party audit to assert their compliance with the respective published Conformance Criteria:
Credential Issuers
Digital Wallet Providers
Further, where Operational Attestation is deemed a more useful proof of compliance for certain individual conformance requirements of OCI Service Providers undergoing formal third-party audit, these service providers SHALL also provide self-attestations in the applicable format (refer to Test of Controls).
Once an OCI Service Provider is approved as a result of a successful audit and self-attestation (as applicable), they are considered a valid OCI Service Provider until one of the following events triggers another audit (re-audit) and/or self-attestation:
OCI Service Provider has changed their auditable or attestation-relevant processes and/or code associated to the prior audit or self-attestation if the OCI Steering Committee and Service Provider deem such change sufficiently significant;
OCI has changed the respective Conformance Criteria that affect the auditable or attestation-relevant processes;
OCI Service Provider has acquired a solution from another company (audit and/or self-attestation is only applicable to the company to which it was originally awarded).
Scheduling
The OCI Steering Committee SHALL agree on a suitable specification release process with the OCI Service Providers to allow for realistic deadlines to compliance (Figure 1). This process SHOULD include considerations regarding audit requirements, time to audit, and any other necessary arrangements. Where these considerations allow for a grace period between the trigger of a re-audit or re-attestation and the execution of those, the affected OCI Service Providers SHALL continue to be considered as valid OCI Service Providers for that period.
Where Operational Attestation requires recurring reports, the start date for the reporting cadence is determined by the most recent audit affecting the respective conformance requirement. At a minimum, reports SHALL show monthly averages of the relevant operational data and cover no more than six (6) months in total. The first report begins in the month of successful (re-)audit completion. Subsequent reports SHALL cover the reporting period directly following the prior reported period. Reports MAY show more granular data than monthly averages and cover more frequent time periods. Reports MAY constitute manual submissions to OCI or automated publicly accessible displays. Each report SHALL be submitted no later than five (5) business days following the end of each reporting period.
Key steps in OCI compliance monitoring
Scope of formal audit
Credential Issuers
The formal audit SHALL address all compliance criteria in the OCI Credential Issuer Conformance Criteria as it relates to the specific Credential Type(s) the Credential Issuer offers.
The OCI Credential Issuer Conformance Criteria document can be found at the following public location: OCI GitHub - Credential Issuer Conformance Criteria.
Digital Wallet Providers
The formal audit of a Digital Wallet provider SHALL address all compliance criteria as set out in the published OCI Digital Wallet Conformance Criteria document found at the following public location: OCI GitHub - Digital Wallet Conformance Criteria.
Since the nature of the various conformance criteria differs, auditors SHOULD distinguish between Test of Details and Test of Controls as applicable to individual criteria or groups of criteria.
To the extent that OCI conformance criteria are covered by another audit, auditors MAY rely on audit work performed by other trustworthy entities to avoid duplication of work, for example in the context of a SOC 2 or ISO audit.
Temporary limitation of audit scope
OCI has not yet standardized the DIDComm-based wallet-to-wallet communication that is to be implemented by Digital Wallet Providers. Since the initial overview of technologies proposed in the Digital Wallet Conformance Criteria only permits the implementation of custom DIDComm flows that might be outside of OCI's future recommendations,
OCI does not require conformance with any DIDComm-specific elements of the Digital Wallet Conformance Criteria until the respective specifications have been updated. In this transition period, OCI permits other technological means for the issuance and exchange of Verifiable Credentials (VC), such as API-based approaches.
To support stakeholders through the DSCSA Stabilization Period, OCI is deferring the requirement in Section 4.1.4.1 Verifying the Credential Issuer for the Trusted Issuer check to take place at each generation. While checking Trusted Issuer status at each Verifiable Presentation (VP) generation benefits VC holders by preventing invalid VPs from being sent, this must be balanced against the potential performance impact to the overall system (i.e. VRS API response times). It must be noted that even if a VP is not “pre-checked” in this way prior to sending, credentials issued by a non-trusted Issuer will always fail a VP verification check, and therefore the overall security of the credentialing ecosystem is not affected.
Test of Details
OCI defines Test of Details as any audit method that assesses factual evidence of whether the required conformance criteria have been met as stated.
This is a direct testing approach and may involve methods such as sampling, reperformance, or analytical review.
Test of Controls
OCI defines Test of Controls as any audit method that assesses whether operational controls and practices put in place by the auditee are sufficiently documented, functional and adhered to as intended by systems and staff of the auditee.
This is an indirect testing approach based on the assumption that adequate controls lead to compliance with stated conformance criteria. Test of Controls may involve methods such as enquiry, inspection of documentation, or observation of the auditee’s staff. Test of Controls methods SHOULD be applied by the auditor in cases where Test of Details is deemed neither feasible nor informative.
Where the auditor applies solely a Test of Controls approach, Service Providers SHALL produce audit-independent Operational Attestation that is available via OCI's public repository. It is then the responsibility of OCI members and service users to assess whether such performance is acceptable for continued collaboration.
The auditor SHALL apply the Test of Controls approach to the following specific conformance criteria.
Digital Wallet Conformance Criteria:
NFR006 High Availability
NFR007 Maximum system response time
Data handling by auditor
Auditors SHALL inspect and the auditee SHALL make available as much sensitive or confidential data as needed for the auditor to come to a reliable conclusion. Such data or information about the data SHALL be shared securely only between auditor and auditee. Auditors SHALL store only as much sensitive or confidential data as needed for audit completion and potential re-use or reference in future audits.
Audit outcome
Auditor conclusion
The auditor SHALL express the overall audit conclusion in the form of a written and signed audit opinion or certificate issued to the auditee stating the auditee’s compliance or failure to comply with the applicable published OCI Conformance Criteria.
The auditor SHOULD highlight to the auditee any suggestions for improvement and other professional feedback in separate communication.
Process after successful audit result
Publication of audit outcome
As soon as the auditee has successfully passed the audit, they SHALL inform the OCI Steering Committee and make a copy of the auditor’s conclusion document publicly available either on their own website or other online repository or by submitting it to the OCI Steering Committee. Regardless of the means by which the auditee submits the information, OCI will publish all auditor’s conclusions in a single OCI-managed repository. Where a link to an external location is provided, the auditee agrees to allow OCI to hyperlink to that online location from the OCI repository. The auditee SHALL alert the OCI Steering Committee in a timely manner if the link needs to be changed.
The auditor SHOULD also publish limited audit results, such as the signed audit opinion or certificate, on their public website. It is assumed that the auditor agrees to allow OCI hyperlinks to their online location from the applicable OCI registry or repository.
OCI SHALL update the applicable public registry of trusted service providers to add or update the successful auditee’s details.
Validity period
The auditor’s conclusion SHALL be valid starting on the signing date of the conclusion until one of the triggering events stated earlier or the end of an agreed grace period following the triggering event (refer to Compliance Monitoring).
Process after audit failure following a re-audit
Notification of OCI
In the case of a re-audit, the auditee SHALL submit a copy of the auditor’s conclusion of failure to the OCI Steering Committee on the day of receiving the final audit report or the day after if the report is received outside the auditee’s business hours.
The OCI Steering Committee SHALL inform all other valid OCI Service Providers of the auditee’s negative audit conclusion.
OCI SHALL update the applicable public registry of trusted valid OCI Service Providers to remove the auditee’s details at the appropriate date if listed.
Notification of service users
The auditee SHOULD inform their customers of the negative re-audit outcome in a timely manner.
Trusted service provider registries
OCI SHALL maintain up-to-date registries listing valid OCI Service Providers that have passed the compliance audit, referred to as Trusted Service Providers.
Any listed valid OCI Service Provider who does not make a copy of the latest positive auditor’s conclusion available to OCI, will be removed from the registry. They will be added back to the registry upon submission of the positive audit conclusion.
Service Providers that have failed in the audit to prove their compliance with OCI Conformance Criteria will not be added or, if already listed, will be removed from the applicable registry.
OCI MAY take up to five (5) business days to add a new Trusted Service Provider to the respective registry and to update the status of an already listed Service Provider in the respective registry if required.
The registries can be found at the following public locations:
Service Providers, who require a third-party audit to assert OCI conformance, MAY choose an audit firm themselves as long as the firm meets the set of minimum acceptance criteria detailed below.
The Service Provider SHALL prove to OCI that they have performed the required due diligence for auditor selection by submitting evidence to the OCI Steering Committee using the respective signed form provided by OCI.
Auditor acceptance criteria
OCI defines the minimum acceptance criteria for audit firms as follows.
The audit firm SHALL:
demonstrate a track record of industry-relevant audit work (e.g. EPCIS; CSOS, SOC 2);
demonstrate their understanding of the relevant OCI conformance criteria through their audit strategy.
The audit firm SHOULD:
not be involved in any lawsuits with clients or regulators.
The audit firm MAY:
have performed prior OCI-related audits.
Auditor inspection
The OCI Steering Committee MAY inspect the auditor at any time, for example, by assessing audit practices or reputational standing. Since the Service Provider is the audit firm’s customer, the auditee SHALL make the auditor aware of OCI’s desire for an inspection, where direct contact with the auditor is required, and facilitate the contact.
Self-Attestation
Self-attestation, in general, refers to representations made by the Service Provider in reference to the relevant OCI Conformance Criteria as a whole or selected requirements therein. OCI distinguishes between Attestation of Conformance and Operational Attestation.
An Attestation of Conformance is an explicit statement by the Service Provider about their adherence to the applicable OCI Conformance Criteria. Such self-attestation SHALL be signed by the Service Provider’s senior management and provided to the OCI Steering Committee for publication, either as a stand-alone document or as a statement of permission for OCI to hyperlink to the Service Provider’s own public storage location. Where OCI prescribes a template for such representation, the latest published version at the time of signing SHALL be used by the Service Provider.
An Operational Attestation is a presentation of operational or system performance data by the Service Provider in relation to selected requirements within the applicable OCI Conformance Criteria. Such self-attestation NEED NOT be signed by the Service Provider’s senior management or other staff. The Service Provider NEED NOT make any claim beyond the presented data in the self-attestation.
At any time the OCI Steering Committee MAY challenge any Service Provider on any of the statements or claims made. The Service Provider SHALL then address the points of concern raised by the OCI Steering Committee in a form and timeframe appropriate to the situation and as agreed with the OCI Steering Committee.
Where Operational Attestation is permissible or required as additional evidence on top of a third-party audit (refer to Test of Controls), the Service Provider SHALL make the necessary documentation available to OCI.
