Digital Wallet Conformance Criteria

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 Digital Wallet providers.

Introduction

Intended Audience

The publication is intended for DIgital Wallet implementers or service providers who wish to be recognized by the Open Credentialing Initiative (OCI) as Digital Wallet Providers 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). This document specifies the Conformance Criteria for a Digital Wallet Provider. It includes definitions of key terms and concepts, W3C standards requirements, technical wallet implementation requirements, and requirements for integration with VRS providers. For a general introduction to OCI, please refer to the Open Credentialing Initiative website.

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:

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.

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. Looking to the future, Digital Wallet Providers are encouraged to ensure flexibility and customizability to support additional use cases for authorized trading partner verification, including the exchange of additional enterprise compliance credentials.

For additional information, please see the Open Credentialing Initiative website.

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 manufacturing, repackaging, distribution, and dispensing of prescription drugs. In addition to verification, product tracing, and serialization requirements, each supply chain actor must ensure that their Trading Partners are authorized (including indirect Trading Partners). DSCSA requires that Trading Partners of manufacturers, wholesale distributors, dispensers, repackagers, and third-party logistics providers (3PLs) 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); briefly, “authorized” means registration in accordance with section 510 (manufacturers and repackagers), or having a valid license under State law (wholesalers, 3PLs, and dispensers).

Digital Ecosystem

Identity of Transacting Entities

Verifying that a company 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 company. 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 Product Identifier (PI) Verification and Transaction Information (TI) Tracing move through any number of intermediaries (solution providers, routing systems, etc.), all of whom fall under the statute. In a digital ecosystem, good design is to limit the opportunity for information leaks, transaction replays, and tampering with the transaction or Credential content throughout the ecosystem.

OCI Credentialing Roles

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, to others who hold a Credential on behalf of the subject, or to third parties authorized to cache or hold a Credential that has been provided to them.

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 their 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 connected services to create enterprise identities via decentralized identifiers (DID) for Trading Partners (e.g. Manufacturer, Wholesaler, Dispenser, Repackager, 3PL) and Verifiable Credential Issuers.

A Verification Router Service (VRS) provides PI verification routing and PI verification request and response 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 (VC); also known as a Credential Service Provider (CSP). The Credential Issuer is responsible for checking the status of entity registrations and licenses prior to issuing VCs to ATPs.

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

The following stakeholder roles shall be established in the OCI:

#	Supply Chain Role	Description	OCI Role
1	Identity and ATP license verification provider	Performs identity and ATP due diligence in accordance with the OCI Credential Issuer Conformance Criteria Issues credentials	Credential Issuer
2	Authorized Trading Partner (ATP) e.g., manufacturer, wholesaler, dispenser, repackager, 3PL	Uses VRS systems to automate generation and routing of verification request and response messages Uses Digital Wallets to acquire and manage ATP credentials Requesting ATP sends PI Verification requests. A Requesting ATP may engage a VRS provider to verify a product identifier and, consequently, enable VRS provider to present their ATP VC in the verification request message. Responding ATP sends PI Verification responses. A Responding ATP may engage a VRS provider to automate its response to a verification request for a product identifier and, consequently, enable VRS provider to present their ATP VC in the verification response message.	Holder Verifier
3	Digital Wallet Provider	Provides Digital Wallets for ATPs and Credential Issuers Provides functionality to issue, revoke and verify credentials Provides functionality to present and verify verifiable presentations of credentials Maintains verifiable data registry that ensures auditability and compliance of Credential Issuer's due diligence (responsibility shared with Credential Issuer in implementation-specific fashion) General Digital Wallet maintenance	Digital Wallet Provider
4	VRS Provider	Provides Verification Routing Service following the GS1 Lightweight Messaging Standard (LWMS) for PI Verifications Implements or utilizes Digital Wallet to invoke OCI standard ATP credential Application Programming Interface (API) to generate and verify verifiable presentations of ATP credentials When representing the ATP credential holder, the VRS provider will add the ATP’s credential presentation to the PI request or response message. When representing the ATP credential verifier, the VRS provider will send a verifiable presentation to the verifier`s Digital Wallet and process the verification result of the ATP Credential	VRS
5	State Board of Pharmacy	Acts as a governance body to provide licenses to trading partners. It is neither expected that regulators have the tools for digital identity verification nor a wallet to issue ATP license status credentials in the initial phases of the OCI ecosystem development. Future direction: It is recommended to investigate the option to use wallets to establish authorized enforcement body credentials so that an enforcement body can prove they are indeed an authorized government body for regulator-initiated DSCSA verification and tracing requests: use Digital Wallets to acquire and manage regulator credentials present regulator VC when interacting with ATP application systems	Source of truth for ATP status information Holder of regulator credentials
6	Regulator	Acts as a regulatory body to conduct audits and investigations for monitoring and enforcing DSCSA compliance. It is neither expected that regulators have the tools for digital identity verification nor a wallet to issue ATP license status credentials in the initial phases of the OCI ecosystem development. Future direction: As above, it is recommended to investigate the option to use wallets to establish authorized government body credentials: use Digital Wallets to acquire and manage regulator credentials present regulator VC when interacting with ATP application systems verify VC of Trading Partners responding to regulator-initiated verification and tracing requests	Source of truth for ATP status information Holder of regulator credentials Verifier (requester) of regulator-initiated (DSCSA) verification and tracing requests

Purpose of Digital Wallet

The dark side of the digital world is professionalizing its malicious activities at an amazing speed, launching sophisticated cyberattacks to compromise endpoints and sell stolen access credentials through Initial Access Brokers to others who then launch ransomware attacks on (supply chain) systems or steal, sell and manipulate internal information. The biggest struggle for API security lies with the building blocks of authentication and authorization. This thread has grown in importance with APIs' increased access to critical data in the US Pharma supply chain.

OCI leverages decentralized public key infrastructure (PKI) and credentials to protect Product Identifier (PI) verification API calls by providing tools to sign PI verification request and response messages while blending these messages with ATP credentials. With these tools in place, a responder API can check the counterparty’s ATP license status prior to responding to a PI verification call. As a result, only authorized parties with valid ATP credentials will receive a response. OCI applies the same mechanism for the verification of the response origin.

Digital Wallet infrastructure is used to protect the private key, acquire, store and exchange credentials of a given supply chain actor. As these wallets are integrated with the GS1 Lightweight Messaging Standard for Verification of Product Identifiers and VRS infrastructure, they allow a US DSCSA-compliant implementation of the ATP regulatory requirements. Decentralized PKI mechanisms of the system are designed to mitigate reuse of API access credentials, which further contributes to improved security.

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 Digital Wallet provider. This ensures interoperability among all OCI-compliant service providers.

The objective of this publication is to document the conformance requirements that shall be adhered to by implementers of Digital Wallets. Adherence is important for:

interoperability and Credential portability,
ease of implementation by VRS providers,
system security, and
DSCSA compliance of the pharma supply chain system.

To ensure consistent implementation of Digital Wallet conformance criteria, their implementation shall be audited by a third party. Only vetted and audited Digital Wallet implementations shall be used by trading partners.

Conformance criteria endorsed by the OCI address the following dimensions:

Technology Conformance Criteria
- OCI Digital Wallet Standards
- OCI Wallet Interfaces
- OCI Functional Wallet Features
- OCI Non-functional Wallet Features
OCI Wallet Integration Organizational Controls
- Documentation
- Information technology controls and security

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. The key words MAY, RECOMMENDED, REQUIRED, OPTIONAL, SHALL, SHALL NOT, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [[RFC2119]] [[RFC8174]] when, and only when, they appear in all capitals.

Terms and Abbreviations

The following terms and abbreviations appear throughout this Digital Wallet Conformance Criteria:

3PL (Third-Party Logistics Provider): As defined in the statute, "an entity that provides or coordinates warehousing, or other logistics services of a product in interstate commerce on behalf of a manufacturer, wholesale distributor, or dispenser of a product, but does not take ownership of the product, nor have responsibility to direct the sale or disposition of the product."
ATP (Authorized Trading Partner): The Drug Supply Chain Security Act (DSCSA) restricts access to the distribution system for prescription drug products by requiring that trading partners of manufacturers, repackagers, wholesale distributors, 3PLs, and dispensers meet the applicable requirements for being Authorized Trading Partners. DSCSA includes definitions for authorized and trading partner with respect to these categories. For example: “To be considered an authorized trading partner, a wholesale distributor must have a valid license under State law or section 583 of the FD&C Act, in accordance with section 582(a)(6) of the FD&C Act, comply with the licensure reporting requirements in section 503(e) of the FD&C Act, as amended by DSCSA, and accept or transfer direct ownership of a product from or to a manufacturer, repackager, wholesale distributor, or dispenser.”
Cloud wallet: A digital cloud wallet which manages the lifecycle, creation and storage of cryptographic key material for a single or multiple users hosted on a secure cloud infrastructure environment.
Digital wallet: A digital wallet which manages the lifecycle, creation and storage of cryptographic key material for a single or multiple users hosted on a secure cloud infrastructure environment. Digital Wallets can be either hosted on a cloud environment or on an edge device.
Edge wallet: A Digital Wallet in which cryptographic key material and credentials are held on a local device (e.g. mobile device) rather than being controlled by a server. While public keys and other data may be stored on the cloud, the private key remains on the local device, so that new presentations of a Credential can only be initiated by the user via their local device.
Credential : 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. Credentials are a subset of identity data. The entity described by the claims is called the subject of the credential.
CSP (Credential Service Provider): An entity that issues verifiable credentials. Also known as a Credential Issuer.
DID (Decentralized Identifier) A type of identifier specified by the World Wide Web Consortium (W3C) that enables verifiable, decentralized digital identity. In contrast to typical, federated identifiers, DIDs can be decoupled from centralized registries, identity providers, and certificate authorities. This takes the form of a Uniform Resource Identifier (URI) that associates a DID subject with a DID document, allowing trustable interactions associated with that subject.
PI (Product Identifier) DSCSA defines the term “product identifier” as, “a standardized graphic that includes, in both human-readable form and on a machine-readable data carrier that conforms to the standards developed by a widely recognized international standards development organization, the standardized numerical identifier (SNI), lot number, and expiration date of the product.” Per this definition, a DSCSA product identifier comprises the following four data elements: National Drug Code (NDC), Serial Number, Batch or Lot Number, Expiration Date. Product Identifiers are affixed to, or printed on a package or homogeneous case corresponding to the SNI assigned to the product by the manufacturer or the repackager.
DSCSA (Drug Supply Chain Security Act): An act of the U.S. Congress that mandates an electronic, interoperable system to identify and trace certain prescription drugs as they are distributed in the United States. The DSCSA imposes a number of current and emerging requirements on pharmaceutical supply chain stakeholders as part of a mandate to protect consumers from exposure to drugs that may be counterfeit, stolen, contaminated, or otherwise harmful.
IAM (Identity and Access Management) Identity management, also known as identity and access management (IAM), is a framework of policies and technologies to ensure that the right human or system users in an enterprise have the appropriate access to technology resources.
Identity Proofing : The process by which a CSP collects, validates, and verifies information about an entity.
NIST (National Institute of Standards and Technology): An agency that is part of the U.S. Department of Commerce. Congress established the agency in 1901 to build a measurement infrastructure and establish standards for a wide range of products and services.
TI (Transaction Information) For each transaction, product tracing information should be exchanged. Product tracing information include Transaction Information including lot number of product, number of containers, date of transaction, date of the shipment, business name and address of the seller and the purchaser.
VDR (Verifiable data registry) In order to be resolvable to DID documents, DIDs are typically recorded on an underlying system or network of some kind. Regardless of the specific technology used, any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. Examples include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage. The system facilitates the creation, verification, updating, and/or deactivation of the DID documents for corresponding decentralized identifiers.

TECHNOLOGY CONFORMANCE CRITERIA

To establish trust, verifiability, and auditability among the trading partners involved in the OCI ecosystem, an open, interoperable, portable, standards-based, decentralized identity framework is essential.

OCI uses decentralized public key infrastructure (PKI) technology for Digital Wallets and for electronically signed verifiable credentials about the enterprises involved in the ATP verification process.

The OCI conformance criteria are based on a set of identity standards (W3C standards, IETF standards, Hyperledger Aries), open API standards, and existing industry standards for PI message exchange (GS1 Lightweight Messaging Standard for Verification of Product Identifiers ) described in this section.

It shall be noted that the OCI Digital Wallet Conformance Criteria distinguishes between Cloud- and Edge wallets as illustrated below.

This diagram shows the basic differences between edge and Cloud wallet implementations. While public keys and other data are stored on the cloud, the private keys of Trading Partners and Credential Issuers may be located either on a local edge device, or managed by a (Cloud wallet) provider. Interoperability occurs at the level of verifiable presentations created and exchanged between wallets. Where potential interoperability between multiple Wallet Providers and Credential Issuers is desired, the OCI Digital Wallet Conformance Criteria include specific DIDcomm requirements.

OCI Digital Wallet Standards

Digital Wallet Implementations SHALL adopt the following set of standards:

Component	Realization and References
Identifiers	W3C Decentralized Identifiers (DIDs) v1.0 (W3C DIDs)
Verifiable Data Registry & DID Methods	Use of a common set of DID Methods endorsed by OCI (e.g. ETHR DID Method Specification, did:web Method Specification)
DID Resolution	Decentralized Identifier Resolution (DID Resolution) using the DIF universal resolver, SpruceID, or another valid resolver.
Vetted Credential Issuer & Root of Trust	Registry for vetted, trusted Credential Issuer maintained by OCI
Credential Structure	W3C Verifiable Credentials Data Model 1.0 (W3C VCs)
Credential Serialization & Schemas	OCI Credential Schema Definition (OCI Credential Schemas)
Signatures & Verification	Cryptographic primitives used for VC creation/verification, JWT creation/verification and wallet-to-wallet communication.
Wallet to Wallet communication (for cloud wallets)	Hyperledger Aries RFCsIssue Credential Protocol v2. Credential ManifestCredential-Manifest Attachment format for requesting and presenting credentials Present Proof Protocol v2 Presentation-Exchange Attachment format for requesting and presenting proofs Presentation Exchange Decentralized Identity Foundation specs. DIDComm Messaging v2 Credential Manifest Presentation Exchange
Revocation	Directory Service (LDAP) based mechanism for revoking Verifiable Credentials (vc-status-2021-ldap)
Messaging Standard to exchange ATP Credentials	GS1 US Implementation Guideline for Applying the GS1 Lightweight Messaging Standard for DSCSA Verification of Returned Product Identifiers

Identifiers for Enterprise Identity

A DID is a globally unique identifier developed specifically for decentralized systems as defined by the W3C DID specification. DIDs enable interoperable decentralized self-sovereign identity management using standardized Digital Wallets.

Implementers of Digital Wallets for OCI credentialing SHALL follow the specification on how DID documents are created and used.

DID documents have the following characteristics:

DID documents contain information associated with a DID.
They express verification methods, such as cryptographic public keys, and services relevant to interactions with the DID subject (wallet-to-wallet communication).
The properties present in a DID document and applicable operations to update these properties are described in DID methods.

DID methods are the mechanism by which a particular type of DID and its associated DID document are created, resolved, updated, and deactivated. DID methods are defined using separate DID method specifications as described in the following chapter.

Verifiable Data Registry & Endorsed DID Methods

To be resolvable to DID documents, DIDs are typically recorded on an underlying system or network of some kind. Regardless of the specific technology used, any such system that facilitates the creation, verification, updating, and/or deactivation of decentralized identifiers and DID documents is called a verifiable data registry (VDR). A verifiable data registry might also be used for other cryptographically-verifiable data structures such as verifiable credentials. Examples for VDRs include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage.

There are multiple VDRs used in today’s DID implementations that support different security protocols, discoverability, and linkage to existing trust networks. To avoid complexity and enable interoperability, OCI supports selected DID methods and establishes a process for maintaining a DID method endorsement.

To ensure resolution of DID methods, Digital Wallet Providers SHALL implement and support all DID methods endorsed by OCI. OCI endorses the following DID methods:

#	DID Method	Reference	VDR	OCI Credentialing Actor
1	did:ethr	did:ethr Method Specification	Ethereum Mainnet	Trading Partner
2	did:web	did:web Method Specification	Secure data store maintained by the implementer	Credentialing Issuer

DID Resolution

Digital Wallet Providers SHALL integrate a DID resolver service for resolving DID documents. The DID resolver SHALL support all DID methods endorsed by the OCI as defined in Table 3 in section 3.1.2. It SHALL be a trusted open source DID resolver with broad community participation (e.g. DIF Universal Resolver or DIDKit) vetted against the non-functional conformance criteria outlined in this document. Wallet providers SHALL NOT use public instances of resolvers, instead using their own implementations.

Vetted Credential Issuer, Root of Trust & Securing DID:web

Credential Issuers verify trading partner identity and license status. They are proving verifiable credentials within their trust domain and are therefore root of trust in their respective trust domain.

To qualify for an OCI Credential Issuer, the Credential Issuer shall fulfill the conformance criteria for Credential Issuers defined by OCI.

To enable Digital Wallet Providers to accept credentials issued from a vetted Credential Issuer only, OCI SHALL implement and maintain a Trusted Credential Issuer registry (see next section). Digital Wallet Providers SHALL be able to process and verify credentials issued by any vetted Credential Issuer that is endorsed via the specified OCI registry.

Credential Issuers SHALL use a DID method implementation that supports a Well-Known Uniform Resource Identifier [[RFC8615]] to make the identifiers well-known among the OCI trading partner.

To provide the well-known mechanism, Digital Wallet Providers SHALL support the DID:web method for Credential Issuers.

Digital Wallet Providers SHALL put controls in place to ensure that ATP credentials are from vetted Credential Issuers only.

Securing DID:web

DNS presents many of the attack vectors that enable active security and privacy attacks on the did:web method and it's important that implementers address these concerns via proper configuration of DNS. For example, without proper security of the DNS resolution via DNS over HTTPS it's possible for active attackers to intercept the result of the DNS resolution via a Man in the Middle attack which would point at a malicious server with the incorrect DID Document.

Implementers should be aware of issues presented by Spoofed DNS records where the record returned by a malicious DNS Server is inauthentic and allows the record to be pointed at a malicious server which contains a different DID Document. To prevent this type of issue, wallet implementers and verifiable credential issuers SHALL use DNSSEC which is defined in [[RFC4033]], [[RFC4034]], and [[RFC4035]].

Trusted Credential Issuer Registry

As described above, the trust placed in Credential Issuers is a key aspect of the OCI ecosystem. In order to ensure that this key role is not exploited, the trust is anchored in a decentralized and cryptographically verifiable way. The crucial information of which issuers, who have satisfied OCI’s Credential Issuer Conformance Criteria, are to be trusted is stored in the Trusted Issuer Registry, which is managed through Ethereum Smart Contracts.

OCI maintains multiple versions of the Trusted Issuer Registry for production and demo/testing purposes. You can find the deployed contracts at these addresses:

The Goerli Sandbox Contract has been modified to not require any OCI mechanisms to add and remove trusted issuer DIDs. This may be used for testing by anyone who is interested.

In addition to readily deployed versions of the contracts, OCI has also published the source code as well as implementation guidelines on GitHub: Trusted Issuer Registry.

Digital Wallet Requirements

At each generation and verification of a Verifiable Presentation, a Digital Wallet SHALL check if the respective Verifiable Credential has indeed been issued by a Trusted Issuer. To accomplish this, a wallet SHALL call one of the following contract method signatures to verify the status of the Credential Issuer:

Retrieve the full list of all Trusted Issuer DIDs.
- Signature: function getTrustedIssuers() public view returns (string[] memory)
- Returns a string array: ["did:ethr:0xf3beac30c498d9e26865f34fcaa57dbb935b0d74", "did:web:example.com", "did:key:0c498d9e26865f34fcaa50c498d9e26865f34fcaa5"]
Retrieve the Trusted Issuer status of given a supplied DID.
- Signature: function isTrustedIssuer(string memory _DID) public view returns (bool)
- Returns a boolean: true/false

By deriving this information from the contract, the Digital Wallet SHALL check that the issuer stated within the claims of the respective ATP credential matches one of those trusted issuers recorded in the Trusted Issuer Registry.

The Digital Wallet SHALL have measures in place to request other Ethereum nodes in case the requested node is down or does not respond in a reasonable amount of time.

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). VCs are issued for 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.

CI relies on an implementation of a common standard for the credential structure. Digital Wallet Providers 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 Digital Wallet Providers SHALL implement DIDs as cryptographic identifiers. It shall be understood that DIDs can be blended with X.509 DEA signing certificates 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. Digital Wallet Providers SHALL support the JSON-LD format and SHALL support JSON-LD schema validation.

The Digital Wallet provider 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 schema versions active, 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://open-credentialing-initiative.github.io/schemas/. Implementers SHALL follow the schema requirements defined by OCI credential schema requirements.

Digital Wallet Providers SHALL support the OCI approved credential schema for processing, validation, and interpretation that are published on the OCI Github for:

Identity Credential
DSCSA ATP Credential

Outlook

GS1 maintains a web vocabulary that is designed to extend the work done by schema.org and makes 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 on normalizing the definitions of the OCI Credential schemas with GS1.

At a later process of the OCI ecosystem development, 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 tools such as SHACL. If and when these changes happen, Digital Wallet Providers SHOULD support the GS1 schema repository and the SHACL instruments.

Proofs & Verifications

Electronic signatures are captured in three places during a digital transaction to verify its authorization. The Digital Wallet Provider SHALL implement the following signature suites and algorithms for signing and verification:

#	Signing Entity	Use Cases	Proof and Verification
1	Credential Issuer: Credential Issuance	Issuance of a Verifiable Credential from Credential Issuer’s wallet to a Trading Partner’s wallet via DIDComm protocol i.e., “issue-credential” v2.0. Verifiable Credential of “Identity Credential” type Verifiable Credential of “DSCSA ATP Credential” type	Verifiable Credential’s proof SHALL be generated and verified in conformance with Ed25519 Signature 2018 Linked-Data Signature Suite.
2	Trading Partner: ATP PI Verify Workflow	Generation and Verification of a Verifiable Presentation that proves the possession of “DSCSA ATP Credential” in the context of the GS1 Lightweight Messaging Standard Protocol.	Verifiable Presentations SHALL be encoded as JSON Web Tokens [[RFC7519]] per vc-data-model and signed using JSON Web Algorithm ES256K and verified accordingly. See [[RFC7518]] Section 3 for more information on the ES256K Digital Signature.
3	Trading Partner: Direct Presentation Exchange	Presentation of a Verifiable Presentation between Trading Partner wallets or from Trading Partner’s wallet to Credential Issuer’s wallet via DIDComm protocol i.e., “present-proof” v2.0. Verifiable Presentation that holds “Identity Credential” Verifiable Presentation that holds “DSCSA ATP Credential”	Verifiable Presentation’s proof SHALL be generated and verified in conformance with JSON Web Signature 2020 Linked-Data Signature Suite.

Signing Entity

Use Cases

Proof and Verification

Credential Issuer: Credential Issuance

Issuance of a Verifiable Credential from Credential Issuer’s wallet to a Trading Partner’s wallet via DIDComm protocol i.e., “issue-credential” v2.0.

Verifiable Credential of “Identity Credential” type
Verifiable Credential of “DSCSA ATP Credential” type

Verifiable Credential’s proof SHALL be generated and verified in conformance with Ed25519 Signature 2018 Linked-Data Signature Suite.

Trading Partner: ATP PI Verify Workflow

Generation and Verification of a Verifiable Presentation that proves the possession of “DSCSA ATP Credential” in the context of the GS1 Lightweight Messaging Standard Protocol.

Verifiable Presentations SHALL be encoded as JSON Web Tokens [[RFC7519]] per vc-data-model and signed using JSON Web Algorithm ES256K and verified accordingly. See [[RFC7518]] Section 3 for more information on the ES256K Digital Signature.

Trading Partner: Direct Presentation Exchange

Presentation of a Verifiable Presentation between Trading Partner wallets or from Trading Partner’s wallet to Credential Issuer’s wallet via DIDComm protocol i.e., “present-proof” v2.0.

Verifiable Presentation that holds “Identity Credential”
Verifiable Presentation that holds “DSCSA ATP Credential”

Verifiable Presentation’s proof SHALL be generated and verified in conformance with JSON Web Signature 2020 Linked-Data Signature Suite.

Credential Issuance & Exchange

Communication between Credential Issuer’s Digital Wallet and Trading Partner’s Digital Wallet or between trading parties for the exchange of credentials may be required to issue and exchange credentials.

DIDComm

The DIDComm Messaging Specification is a secure method for credential issuance based on a set of interoperable and DID method-agnostic Aries RFCs are working items of the Hyperledger and Decentralized Identity Foundation (DIF) that define technical standards specifications. It may be used to support wallet-to-wallet communication between organizations (e.g. Credential Issuer and Digital Wallet Provider), or facilitate secure message exchange within an organization.

Digital Wallet Providers SHALL implement DIDComm capabilities to meet the functional requirements outlined in the OCI Digital Wallet Conformance Criteria.

This high-level chart may be used as guidance for the subject workflow for credential issuance and exchange.

Beyond this, Trading Partners SHOULD be able to exchange Verifiable Presentations of their Identity Credentials with other Trading Partners using DIDcomm. This is important when a trading partner receives an ATP Credential from a previously unknown trading partner and wishes to request the corresponding identity Credential. Having established a trusted communication channel between Trading Partner wallets, future use cases that require exchanging credentials can be facilitated more easily.

#	Specification Source	Specifications
1	Hyperledger Aries RFCs	Issue Credential Protocol v2 Credential-Manifest Attachment format for requesting and presenting credentials Present Proof Protocol v2 Presentation-Exchange Attachment format for requesting and presenting proofs
2	Decentralized Identity Foundation Specifications	Credential Manifest Presentation Exchange

Credential Revocation

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 Credential Revocation Lists (CRLs). Consequently, Digital Wallet Providers SHALL implement the OCI Directory Service (LDAP)-based mechanism for determining if a Verifiable Credential has been revoked (vc-status-2021-ldap).

A Digital Wallet Provider MAY implement a caching mechanism for Credential revocation data to cache LDAP data for 24 hours. Credential revocation data SHALL not be older than 24 hours during normal operations of the OCI Directory Service.

It shall be understood that existing cached data can be used when the OCI Directory Service is not available for an update of the local cache due to a technical downtime. A Digital Wallet Provider SHALL store communication request data when OCI Directory Service is not available to establish an audit trail and document why revocation data older than 24 hours were potentially used for checking the revocation status over the time period of the OCI Directory Service downtime.

To mitigate man-in-the-middle attack vectors, Credential Issuer and Digital Identity providers SHALL implement LDAPS, which is LDAP secured by communication over Transport Layer Security (TLS) protocol.

Cloud Wallet Interfaces and Open API Integration

OCI wallet providers that provide a cloud wallet SHALL implement the interfaces and Open API integration defined below.

ID	Specification Source	Bidirectional Communication
IF001	Interface for Human Users	Digital Wallet Solution ⬄ Wallet Administrator
IF002	API Integration with VRS Provider	Digital Wallet Solution ⬄ VRS Provider
IF003	API Integration with Revocation DB	Digital Wallet Solution ⬄ Revocation DB of Credential Issuer
IF004	API Integration with VDR	Digital Wallet Solution ⬄ Verifiable Data Registry (VDR)
IF005	API Integration with Credential Issuer	Digital Wallet Solution ⬄ Credential Issuer


ID	IF001
Description	Interface for Human Users
Type	Manual interface, authentication via Two-Factor Authentication (2FA), Connection: HTTPS
Information flow Direction	Bidirectional: Human User ⬄ Enterprise Digital Wallet
Input Data	Enterprise Digital Wallet Administration Data, User and Role Management Data, Onboarding Data for Credential acquisition
Output Data	ATP Monitoring Data (list of connections with ATP counterparties, identity credentials of ATP counterparties, status of VPs, ATP validation of individual PI verify requests), Wallet Administration Data (users and roles, my company identity and ATP credentials).


ID	IF002
Description	API Integration with VRS Provider, API Interface for creating and verifying ATP Credential Presentations (See Section 5.1.7 Proof & Verifications )
OpenAPI Specification	https://open-credentialing-initiative.github.io/api-specifications/v2.0.0/#/VerifiablePresentation/postVerfiablePresentationVerification>
Type	REST API, authentication via OAuth2.0 bearer token, Encryption: SSL TLS v1.2+, Connection: REST on HTTPS
Information flow Direction	Bidirectional, VRS ⬄ Enterprise Digital Wallet
Input Data	Request creation of ATP Credential Presentation, Verify ATP Credential Presentation
Output Data	ATP Credential Presentation (JWT), ATP credential presentation verification response.


ID	IF003
Description	API Integration with Credential Issuer Revocation Database
Specification	https://spherity.github.io/vc-status-2021-ldap/>
Type	REST API, public API with no authentication, Encryption: SSL TLS v1.2+, Connection: REST on HTTPS
Information flow Direction	Bidirectional, Credential Issuer Revocation DB ⬄ Enterprise Digital Wallet
Input Data	Request VC revocation status
Output Data	Response VC revocation status


ID	IF004
Description	DID Transactions with DID Registry on Public Ledger, DID document read transactions via a universal resolver
Type	DLT RPC calls, VDR , no authentication required
Information flow Direction	Bidirectional, VDR ⬄ Enterprise Digital Wallet
Input Data	DID transactions: creation, revocation, update
Output Data	DID transaction (creation, revocation, update) confirmations or DID documents


ID	IF005
Description	Requesting verifiable credential issuance from Credential Issuer
Type	REST API, wallet-to-wallet communication
Information flow Direction	Bidirectional, Credential Issuer Wallet ⬄ Enterprise Digital Wallet, Encryption: SSL TLS v1.2+, Connection: Issuance of Credentials via DIDcomm V2 with Encrypted Messaging Envelope as specified in the DIDComm Messaging Specification based on Aries Protocols
Input Data	Request identity or ATP credential issuance
Output Data	Identity or ATP Credential

APIs implemented for the specifications above (IF002 - IF005) SHALL follow the OCI OpenAPI specification for Digital Wallet Providers. See OpenAPI Spec for further details.

The Digital Wallet Provider SHALL provide API concepts for:

Authentication: Endpoints of the Digital Wallets require authentication that is secured via a JWT. To obtain a token and start making requests, the implementer SHALL provide an authentication provider that can process requests to obtain authentication token.
Status Codes: Digital Wallets SHALL use HTTP status codes to indicate the success or failure of API requests. If a request fails, it returns an error using the appropriate status code.

Implementers MUST conform to [[RFC7231]] and [[RFC2616]] when processing and returning HTTP Status Codes to a requesting client. From RFC7231 Section 6 - Response Status Codes:

1xx (Informational): The request was received, continuing process

2xx (Successful): The request was successfully received, understood, and accepted

3xx (Redirection): Further action needs to be taken in order to complete the request

4xx (Client Error): The request contains bad syntax or cannot be fulfilled

5xx (Server Error): The server failed to fulfill an apparently valid request

OCI Functional Wallet Features

The following functional requirements (FRs) SHALL be respected by all Digital Wallet Providers.

Wallet User Management

A solution SHALL integrate an Identity and Access Management (IAM) solution for User and Role Management into the Digital Wallet infrastructure. A solution SHALL support user on-boarding, off-boarding and user Credential management features and workflows.

On-boarding includes a secure process to assign a role to a verified user of the trading partner. This process includes secure provisioning of 2FA or MFA access credentials to a given user.
Off-boarding includes an authorized process where an existing user's access to the Digital Wallet is removed.
User Credential management includes a secure process to reset and/or rescind access credentials and change user roles (where multiple user roles exist).

The wallet MAY be integrated with existing trading partner identity and access management (IAM) solutions. Implementers of solutions for smaller trading partners MAY simplify the user management solution by merging administrator and user roles, as users and administrators can be the same person.

Identity & ATP Credential Management

A solution SHALL provide a process workflow for acquiring identity and ATP credentials from a vetted Credential Issuer.

A solution SHOULD provide a feature for users of the trading partner to request and log identity credentials from another counterparty.

A solution SHALL provide a data store for storing identity and ATP credentials and transaction log data to support analysis, archive and auditing requirements for DSCSA.

OCI Non-functional Wallet Features

The following non-functional requirements (NFRs) SHALL be respected by Digital Wallet Providers:


ID	NFR001
NFR Type	Authentication & Authorization
Description	Only the authorized user of trading partner or credential issuer can manually access the Digital Wallet application.
Rationale	Authentication should be configurable in accordance with enterprise ISRM (Information Security and Risk management) requirements as well as policy rules Authorization: Access to the system features must be based on privileges and roles of the user
Conformance Criteria	Two-Factor Authentication (2FA) SHOULD be implemented. For operational systems, single sign-on with enterprise IAMs or identity providers MAY be integrated. Role-based access control MAY be configured for user role-based access.
Measurement	2FA authentication when users are accessing the application (single sign-on as optional solution).


ID	NFR002
NFR Type	Security - Data Authorization & Encryption
Description	Data at rest and in transit shall be protected
Rationale	Any sensitive data must be encrypted and protected
Conformance Criteria	Data at rest SHALL be secured using multiple methods as applicable to use cases such as encryption, authorization, and Role Based Access Control (RBAC). All customer data and metadata at rest SHALL be encrypted using the industry standard AES-256 encryption algorithm (256 bits key length) Connection to the solution for data in transit SHALL be encrypted using TLS 1.2+
Measurement	Functional testing


ID	NFR003
NFR Type	Security - Non-repudiation
Description	The system must prevent the initiator of a transaction from later disputing the creation of a given transaction.
Rationale	Standard pharma compliance requirement
Conformance Criteria	Solution SHOULD implement an audit trail including non-repudiable digital signatures for all ATP Credential transactions realized on the system. User authentication and activities SHALL be logged. Audit trail SHALL be available for user inspection.
Measurement	Application security testing against these features documented in User Acceptance Testing (UAT). Review of operational audit logs created by the solution and compared with user activity in a test scenario.


ID	NFR004
NFR Type	Security - Key Management & Rotation
Description	Key rotation best practices applied to regularly change signing and encryption keys.
Rationale	Protect application against theft of signing keys
Conformance Criteria	Solution SHALL provide secure key management for encryption and signing keys Solution SHALL provide features to update DID documents and to rotate keys in accordance with the W3C DID standards and best practices/implementation guidelines on a regular basis, keys SHALL be rotated no less often than once every 12 months. Solution SHALL provide rotation features for encryption keys (e.g. database encryption, certificate renewal)
Measurement	Application security testing against these features


ID	NFR005
NFR Type	Security – Platform & Network Security
Description	The system must adhere to platform security requirements.
Rationale	Cloud architecture should ensure VRS and trading partner systems are secured from attack. Since the system handles business critical data, the measures taken to protect data need to be defined. Privileged access to system components is minimized and strictly controlled.
Conformance Criteria	Security is critical to a solution deployed as Cloud Service. Implementers SHALL focus on security features: Platform Security: Relevant security procedures provided by the cloud platform shall be enabled PAM: Privileged Accounts must be managed securely. Logging & Monitoring: Logs should be maintained and reviewed Network Security: Infrastructure components must be protected by implementing relevant network security features including Web Application Firewall Secure DNS DDOS Protection VPC infrastructure
Measurement	Application security testing against these features


ID	NFR006
NFR Type	High Availability
Description	Digital Wallet and credentialing solution systems must be resilient to single points of failure or outages
Rationale	When integrated into operations, ATP credentialing is a critical business system
Conformance Criteria	DevOps infrastructure and cloud services SHALL be designed in a redundant manner so that the system will continue to work in production mode (i.e., no degraded performance) if one component fails. Digital Wallet Providers SHOULD aim for 99.5% availability
Measurement	Infrastructure designed for high availability, resilience and failover with ability to monitor and report on availability


ID	NFR007
NFR Type	Maximum system response time
Description	The maximum time taken by the system as a whole to send any information back to the end user who triggered a query (and out of the transit/transmission overhead). Average time for performing the two API calls to generate and verify ATP VPs SHALL be in total less than 1500 ms. Maximum time for both calls SHALL be in total less than 3000 ms.
Rationale	Solution SHOULD be easily scalable to handle high volumes of Product Identity Verification Requests and Responses as well as a high number of trading partners without making changes to the overall architecture.
Conformance Criteria	Solution SHALL provide low-latency APIs. Solution MAY apply caching methods (e.g., revocation lists, DID documents, credential verification events) where technically and legally possible to reduce throughput times of processing the APIs. Cached data SHALL be valid no longer than 48 hours.
Measurement	API performance designed for low-latency with built-in ability to measure performance, throughput and latency.


ID	NFR008
NFR Type	Disaster recovery
Description	The solution must survive a critical data center incident and large scale outage events.
Rationale	ISMS Standards dictate disaster recovery solution
Conformance Criteria	The solution SHOULD be replicated in an alternative datacenter. It SHOULD provide back-up and restore mechanisms.
Measurement	Recurring disaster recovery tests


ID	NFR009
NFR Type	Audit Requirements
Description	The solution must be able to support audit log requirements.
Rationale	Data and industry regulations require support for investigations and compliance
Conformance Criteria	Solution SHALL provide audit logs of interface access as well as of generation and verification of verifiable presentations. Solution SHALL log corrUUID so that transactions are correlatable across systems and wallets of the trading partners.
Measurement	Testing of audit logs. Checking that audit logs can be retrieved, are accessible and can be processed.


ID	NFR010
NFR Type	Archiving
Description	The solution can support audit archiving requirements.
Rationale	Data and industry regulations require support for investigations and compliance with data archiving regulations.
Conformance Criteria	The Wallet Provider SHALL keep detailed records of all VP generation and verification events as well as monitoring activities for a period of not less than six (6) years. These detailed records constitute an audit trail to be used in the event of an investigation into credential-related activities of the credential holder
Measurement	Testing of archiving features. Checking that archived data can be retrieved, are accessible and can be processed.

INTEGRATION WITH VRS PROVIDERS

API to generate a Verifiable Presentation of ATP Credential


API Name	Generate ATP Verifiable Presentation of ATP Credential
Description	The HTTP endpoint used to generate a Verifiable Presentation of a DSCSA ATP Credential.
OpenAPI Specification	https://open-credentialing-initiative.github.io/api-specifications/v2.0.0/#/VerifiablePresentation/postVerfiablePresentationGeneration
Request Body	The Digital Wallet SHALL provide an API consuming a JSON request body with the following values: corrUUID \| string \| required Correlation UUID which is obtained from the PI Message holderDID \| string \| required The DID that holds the requested Credential credentialType \| string (enum) \| required IdentityCredential or DSCSA-ATP-Credential The type of Credential that should be requested Note: It shall be understood that a counterparty VRS can be unavailable at any given time. If this is the case, the first VRS provider needs to regenerate a JWT token for resending the PI verify request to the counterparty VRS at a later time to retry the PI verification request.
Request Parameters	The Digital Wallet SHALL provide the following OPTIONAL query request parameters. During the generation of a VP these checks MAY be omitted and only be used for other use cases. In standard mode of operations verifiable presentations can be generated without any additional checks. Checks will always be done on the receiving side. Therefore and to reuse overall latency checks can be neglected on the sender side. The following optional checks can be done by the sender to check that the presentation generation is working properly and the underlying credentials are valid (e.g. for Periodical checking the validity of a Credential): vc-expirationDate \| boolean \| optional \| default 'false' The Digital Wallet SHALL provide this optional parameter to check the expiration date of the ATP Credential vc-proof \| boolean \| optional \| default 'false' The Digital Wallet SHALL provide this parameter to check the cryptographic proof of the ATP Credential vc-issuanceDate \| boolean \| optional \| default 'false' The Digital Wallet SHALL provide this optional parameter to check the issuance date of the ATP Credential vc-credentialStatus \| boolean \| optional \| default 'false' The Digital Wallet SHALL provide this optional parameter to check the revocation status (incl. expiration) of the ATP Credential
Response Body	Depending on whether the VP generation is successful or not, The Digital Wallet SHALL either return a response body representing positive or negative generation. For Positive Generation Response, the response body SHALL contain the following fields: success \| boolean \| required with value true Indicating wheter or not the request has been successfull or not. verifiablePresentation \| string \| format base64 \| required The JWT formatted and base64 encoded Verifiable Presentation. holderDID \| string \| optional The holderDID that was used to generate the verifiable presentation. corrUUID \| string \| optional The corrUUID that was used to generate the verifiable presentation. credentialType \| string \| enum \| optional The credentialType that was used to generate the verifiable presentation. Either of type IdentityCredential OR DSCSAATPCredential. message \| string \| optional Additional message to be included For Negative Generation Response, the response body SHALL contain the following fields: success \| boolean \| required with value false Indicating wheter or not the request has been successfull or not. errors \| array \| required a list of error messages describing the error code(s) as specified in section 4.2.1 encountered while attempting to generate VP errorCodes \| array \| required a list of error code(s) as specified in section 5.3 encountered while attempting to generate VP
HTTP Status Codes	The Digital Wallet SHALL return the following HTTP status codes and descriptions in accordance to section 4.2 Cloud Wallet Interfaces and Open API Integration: 1xx (Informational): The request was received, continuing process 2xx (Successful): The request was successfully received, understood, and accepted 3xx (Redirection): Further action needs to be taken in order to complete the request 4xx (Client Error): The request contains bad syntax or cannot be fulfilled 5xx (Server Error): The server failed to fulfill an apparently valid request

API to Verify Verifiable Presentation of ATP Credential


API Name	Verify ATP Verifiable Presentation of ATP Credential
Description	To check the authenticity, integrity, revocation & expiration status of a Verifiable Presentation of an ATP Credential.
OpenAPI Specification	https://open-credentialing-initiative.github.io/api-specifications/v2.0.0/#/VerifiablePresentation/postVerfiablePresentationVerification
Request Body	The Digital Wallet SHALL provide an API accepting a request body with the following values: Verifiable Presentation \| string \| format base64 \| required The verifiable presentation to verify in JWT base64 encoded format. verifierDID \| string \| required The DID that requests a verification of the provided Verifiable Presentation.
Request Parameters	None.
Response Body	Depending on whether the verification is successful or not, the Digital Wallet SHALL either return a response body representing positive verification or negative verification. For Positive Verification Response, the response body SHALL contain the following fields: success \| boolean \| required with value true Indicating wheter or not the request has been successfull or not. verifiablePresentation \| string \| format base64 \| optional The JWT formatted and base64 encoded Verifiable Presentation which has been verified verifierDID \| string \| optional The DID that requested a verification of the provided Verifiable Presentation. message \| string \| optional Additional message to be included For Negative Verification Response, the response body SHALL contain the following fields: success \| boolean \| required with value false Indicating wheter or not the request has been successfull or not. errors \| array \| required a list of error messages describing the error code(s) as specified in section 4.2.1 encountered while attempting to generate VP errorCodes \| array \| required a list of error code(s) as specified in section 5.3 encountered while attempting to generate VP
HTTP Status Codes	The Digital Wallet SHALL return the following HTTP status codes and descriptions in accordance to 4.2 Cloud Wallet Interfaces and Open API Integration: 1xx (Informational): The request was received, continuing process 2xx (Successful): The request was successfully received, understood, and accepted 3xx (Redirection): Further action needs to be taken in order to complete the request 4xx (Client Error): The request contains bad syntax or cannot be fulfilled 5xx (Server Error): The server failed to fulfill an apparently valid request

API specific Error Codes

Digital Wallet Providers SHALL return the following error codes if a verification (or if applicable in the generation) fails due to certain scenarios. The above defined response data structure SHALL be used to transport the code to a requesting client. An implementer SHALL use the field ‘errorCodes’ for transporting one (1) or multiple codes. It is RECOMMENDED to use the field ‘errors’ for transporting human readable error messages further explaining the reason why a verification has failed.

Given these scenarios, the following error codes MUST be included in the ‘errorCodes’ field in the verification (or if applicable in the generation) response. It is RECOMMENDED to include multiple errors in the response as applicable.

Determine if the decodation of the provided JWT-formatted Verifiable Presentation fails, and it is not possible to derive meaningful data from the input. This includes, but is not limited to, not readable JWT headers or signatures. This error SHALL also be returned if it is concluded that the decoded structure of the JWT is missing required fields.
- jwt_invalid
The field exp (VC expiration date) of the decoded JWT is either concluded to be in the past -
- vc_exp_expired | or the field is concluded to be unreadable/unprocessable in which case vc_exp_invalid needs to be returned
The field nbf (VC issuance date) of the decoded JWT is either concluded to be in the future -
- vc_nbf_expired | or the field is concluded to be unreadable/unprocessable in which case vc_nbf_invalid needs to be returned
The field iat (VP generation date) of the decoded JWT, factoring in the current approved VP lifetime, is concluded to be in the past -
- vp_iat_expired | or the field is concluded to be unreadable/unprocessable in which case vp_iat_invalid needs to be returned
The field iss (holder DID generating the VP) of the decoded JWT is concluded to not be a DID-compliant formatted identifier. See https://www.w3.org/TR/did-core/#did-syntax for ABNF syntax rules for forming and parsing a correct DID.
- vp_iss_invalid
The field nonce of the decoded JWT is concluded to not contain a valid UUID Version 4 Format as specified in [[RFC4122]].
- vp_nonce_invalid
The field vp.verifiableCredential (The Verifiable Credential in json-ld format) is evaluated and either concluded to be incomplete, non-parsable or fails sanity checks for expiration- and or issuanceDate.
- vc_invalid
The field vp.verifiableCredential.issuer (Issuer of the Verifiable Credential) is concluded to not be part of the OCI Trusted Issuer list state at the time of verification.
- vc_non_trusted_issuer
The field vp.verifiableCredential.credentialStatus (Revocation of the Verifiable Credential) is evaluated, the revocation checked and concluded to be revoked.
- vc_revoked
The field vp.verifiableCredential.proof (Proof of the Verifiable Credential) is concluded to be invalid given the signed body or does not yield a valid or resolvable result.
- vc_proof_invalid
The Digital Wallet Solution is not able to find a valid Verifiable Credential to be used for generating a Verifiable Presentation given the specified DID.
- vc_not_found

Protection against Credential Replay Attacks and VP Lifetime

It was decided by OCI members not to use the verifiable presentation approach employing a nonce created by the verifier as developed in the pilot phase, but instead to use a JWT with a given lifetime that then defines the expiration date/time of the JWT. The verifiable presentation approach of the ATP pilot is documented in the pilot documentation. This approach was designed to fulfill low-latency requirements. The rationale behind this decision is based on confidentiality considerations on an overall PI verification system level.

The JWT VP SHALL have a lifetime (or time to live) attribute. The lifetime for JWT VPs used in PI verifications SHALL not be longer than 5 minutes or 300,000 ms. The JWT VP verification API will use this VP lifetime threshold to check if a VP is expired. This VP lifetime threshold will be added to the issuance date of the VP, iat attribute of VP, to determine whether the VP verification time is within the acceptable time window for using the generated VP.

v3.2.0

Status of this Document