What is CARO?
About this document
Here we explain some basic concepts about our CARO app, Spherity's Credentialing Service for Authorized Trading Partners(ATP), to help you understand its purpose and main functionalities.
If you are looking for a high-level overview of CARO, download our info brochure or visit the website.
What are identifiers & credentials in CARO?
Identifiers & credentials are stored in your CARO digital wallet. They provide the basis for all of CARO's services to you.
You may have one or more Enterprise Identifiers. These are, in fact, so-called decentralized identifiers (DID). Each is unique and assigned to a specific enterprise of yours that has registered with CARO. Each identifier holds its own set of credentials, more specifically, these are so-called verifiable credentials that enable automated information exchange between you and your counterparty, i.e. the trading partner with whom you are in business.
To satisfy DSCSA ATP requirements, you require two credentials:
- The Identity Credential identifies your enterprise (not you as a person!).
- The DSCSA ATP Credential represents your enterprise's ATP status as defined by DSCSA.
Both of these credentials are assigned to the same Enterprise Identifier because the ATP Credential depends on the presence of a valid Identity Credential. Underlying this is basically a 2-step due diligence process per Enterprise Identifier.
Download a brief overview of the information needed to obtain these credentials.
So, what does my CARO Enterprise Account do for me?
Your CARO Enterprise Account is your gateway to pass credential details to your VRS provider. Your VRS will then present these details to your counterparty for verification. Even though only ATP credential information is exchanged in VRS interactions, both credentials (Identity and ATP) must be valid for a VRS transaction to be successful. All this happens behind the scenes without any need for you to intervene. CARO's system is based on the concept of the trust triangle.
For example, imagine you want to find out whether you can sell a returned box of drugs. This means you will need to enquire with the manufacturer whether the box has really been produced by them. To do so, you must prove to the manufacturer that you are allowed to trade pharmaceuticals, that is, you must demonstrate your valid ATP status as defined by DSCSA. CARO, in collaboration with your VRS, allows you to do this in a fully automated manner once registered with us. The manufacturer, in turn, will need to prove to you that they are indeed a legitimate manufacturer. They use the same mechanism as you to do so by sending their valid ATP status through their VRS to you.
What are VRS Events in CARO?
A full successful VRS messaging roundtrip for a product enquiry, i.e. Product Identifier (PI) verification, involves:
- you transmitting PI information to your VRS (for example through a product scanning app);
- your VRS sending this PI information in combination with your ATP status (as recorded in CARO) to the manufacturer's VRS;
- the manufacturer transmitting the response to their VRS essentially confirming or denying that the product stems from them;
- the manufacturer's VRS sending this response in combination with their ATP status (as recorded in CARO or another compatible service) to your VRS
- you receiving the PI verification response
The illustration above roughly depicts this flow.
It is important to understand that in this information exchange CARO is solely involved in providing the ATP status. Thus, what we call VRS Events in CARO refers only to the success or failure of the credential processing between CARO and your VRS, not the entire VRS messaging roundtrip.
What do the VRS Event statuses mean?
VRS Event Type | Your Status | Meaning |
---|---|---|
Outgoing | ✅ success | Your VRS has successfully retrieved your ATP credential from your CARO Enterprise Account. |
Outgoing | 🔴 fail | There was an issue with the ATP credential in your Enterprise Account. |
Incoming | ✅ success | CARO has verified your counterparty's ATP credential and found it to be valid. |
Incoming | 🔴 fail | CARO has deemed your counterparty's ATP credential invalid. |
Note that this overview focuses on the status of the VRS Events in your own CARO Enterprise Account. See below for explanations of the counterparty status.
VRS Event Type | Counterparty Status | Meaning |
---|---|---|
Outgoing | ✅ success | The other trading partner has received your ATP credential and found it to be valid. |
Outgoing | 🔴 fail | The other trading partner has received your ATP credential and deemed it invalid. |
Outgoing | ⚫ unavailable | If your own outgoing event status is a fail, the other party may not have received your ATP credential. It may also be that the counterparty is not a CARO user. Thus, CARO cannot access the status information. |
What are VRS Reports in CARO?
We bundle CARO's VRS Events to VRS Reports. This is possible because VRS Events that belong to the same messaging roundtrip are assigned the same unique identifier, a so-called correlation UUID. Thus, CARO VRS Reports make it easier for you to trace all interactions of your CARO Enterprise Account with your VRS that belong to a specific product enquiry.
What do the VRS Report statuses mean?
VRS Report Status | Meaning |
---|---|
✅ success | The full VRS roundtrip has taken place and passed all checks. Your VRS has successfully retrieved your ATP credential from your Enterprise Account and CARO has verified your counterparty's ATP credential as valid. |
🔶 incomplete | Only half of a VRS roundtrip has taken place due to some issues along the way. If you are the sender of a product enquiry, for example, your VRS may have successfully retrieved your ATP credential from your Enterprise Account, but your counterparty has deemed your ATP credential invalid. This prevented any further interaction with your Enterprise Account. |
🔴 fail | The full VRS roundtrip has taken place and failed critical checks. Most likely, your VRS has successfully retrieved your valid ATP credential from your Enterprise Account but CARO deemed your counterparty's ATP credential invalid. |
Glossary
A
Term | What is it? |
---|---|
Authorized Trading Partner (ATP) | DSCSA defines trading partners in the pharmaceutical supply chain as entities that accept or transfer direct product ownership. A trading partner is authorized when they hold either a valid license or FDA registration. There are five types of trading partners: manufacturers, wholesale distributors, dispensers, repackagers, and third-party logistics providers (3PLs). Dive Deeper - FDA Guidance |
Application Programming Interface (API) | An API basically works as a relay between one entity's app data and functionality and a third party. This allows developers to build new programmatic interactions on top of the original app. In the case of CARO, other service providers, such as VRS, can connect their existing tech stack via our APIs to our digital wallet. |
B
Term | What is it? |
---|---|
Blockchain | A decentralized ledger that stores data permanently in a secure, sequential, and immutable manner. |
C
Term | What is it? |
---|---|
CARO | CARO is the acronym for Credentialing of ATP for Regulatory Observance. It is Spherity's web-based app solution to authenticate direct and indirect trading partners in real-time. Dive deeper - Website |
Client ID & Client Secret | Essentially, these are access details. The Client ID is a public identifier for apps that, for security reasons, should not be guessable by third parties. The Client Secret is effectively a confidential password that is only known to the application and authorization server. In CARO, these details allow Service Providers to access and communicate with the CARO app. Dive deeper - oauth intro |
Correlation Universally Unique Identifier (corrUUID) | This is a unique ID for a set of transactions. In CARO, it allows us to group all transactions that pertain to the same VRS roundtrip, e.g. a Product Identifier verification request, to understand the complete history of the VRS-facilitated interactions. |
Counterparty | In CARO this is the trading partner with whom the CARO Enterprise Account holder has interacted in a VRS-facilitated credential exchange. It is basically the other side in a product enquiry process. |
Credential | Credentials exist in the physical and digital world. They are essentially certificates that attest to a certain status or achievement. This means an electronic credential is a digital assertion containing a set of claims made by an entity about itself or another entity. The entity described by the claims is called the subject of the credential. See - Verifiable Credential |
Credentialing | Credentialing in the context of DSCSA is the process of verifying documentation that proves a certain legal or regulatory status, e.g. the formal review of a pharmacy’s State license and proof of the company’s existence. Within the digital world, electronic credentials can be issued once electronic and/or physical documentation has been approved. See - Verifiable Credential |
Credential Issuer | This is an entity that is authorized to issue a credential and transmit the credential to a holder who stores Verifiable Credentials in a digital wallet. Issuers are, for example, government organizations, healthcare centers, financial organizations, universities, and regulatory compliance providers. Dive Deeper - OCI Credential Issuer Conformance Criteria |
D
Term | What is it? |
---|---|
Decentralized Identifier (DID) | A DID is a type of identifier that enables verifiable, decentralized digital identity. A DID is unique and may refer to any subject (e.g. a person, organization, thing, data model, abstract entity). It is a simple text string consisting of three parts: 1) the did URI scheme identifier, 2) the identifier for the DID method, and 3) the DID method-specific identifier. An example of a DID is did:ethr:123454123412341236abcdef. DIDs and DID documents are managed via verifiable data registries. Dive Deeper - W3C DID |
DID Document | This is the cryptographic metadata associated with a specific DID, such as the public key information or service endpoints. This record is accessible using a DID resolver. Dive Deeper - W3C DID Resolution |
DID Method | This is a mechanism by which a particular type of DID and its associated DID document are created, resolved, updated, and deactivated. DID methods are defined using DID method specifications. Dive Deeper - W3C DID Method Specifications |
DID Resolver | This software derives the DID document for a given DID by applying the respective DID method. |
Digital Wallet | A physical wallet stores your IDs like drivers' licenses, credit cards, and other credentials. In a similar sense, a digital wallet is a piece of software that allows you to securely acquire, store, manage and check Verifiable Credentials (VCs) as well as Decentralized Identifiers (DIDs). The wallet is not just a storage facility but also permits the use of VCs. This means that the wallet enables you to access certain services or exchange information. In the OCI ecosystem, integrators like VRS providers are able to connect themselves to your digital wallet to facilitate your drug information enquiries. This enables your compliance with DSCSA. Dive Deeper - OCI Digital Wallet Conformance Criteria |
Drug Supply Chain Security Act (DSCSA) | The DSCSA was enacted by US Congress on November 27, 2013. It demands several improvements to the US drug supply chain, for example, through an electronic, interoperable system to identify and trace prescription drugs. The goal is to prevent harmful drugs from entering or spreading across the US supply chain. Dive Deeper - DSCSA |
E
Term | What is it? |
---|---|
Enterprise Identifier | This is a unique ID for an enterprise. In CARO, this is the DID of an organization. See - DID |
J
Term | What is it? |
---|---|
JSON Web Token (JWT) | JWT is an open standard for secure data transmission. The transmitted information is digitally signed and can be verified. JWT is often used for authorization management, as the token can be used to manage access permissions. Dive Deeper - JWT intro |
O
Term | What is it? |
---|---|
Open Credentialing Initiative (OCI) | OCI is a collaborative non-profit industry collaboration formed in April 2021 by a group of trading partners, solution providers, and standards organizations to support the US pharmaceutical industry in adopting credentialing and digital wallet technologies to enhance supply chain security, and thus the protection of consumers. The ecosystem is open to trading partners, solution providers, associations, standards bodies, and others interested in contributing to future enhancements of the architecture and use cases. Dive Deeper - OCI Website |
P
Term | What is it? |
---|---|
Product Identifier (PI) | This is an ID fixed to each package and homogenous case of a marketed product. Dive Deeper - FDA Guidance - PI |
Proxy Server | This is an intermediary system that acts as a gateway between internet users and the web pages they visit online. A proxy aims to increase cybersecurity for your computer by protecting you from internet threats like malware. |
T
Term | What is it? |
---|---|
Trust Triangle | There are three entities in a Verifiable Credential (VC) ecosystem: Issuer, Holder, and Verifier. The issuer generates and bestows the credential; the holder is the entity about and/or for whom the credential is issued; and the verifier checks claims within a credential. The latter trusts the legitimacy of the issuer but does not need to trust the holder thanks to the verifiability of the holder's VC. Dive Deeper - W3C Ecosystem |
U
Term | What is it? |
---|---|
URL (Uniform Resource Locator) | This is a unique identifier used for locating files on the internet. It is basically the full web address of any website resource, e.g. https://www.spherity.com/caro. A domain name, e.g. 'spherity.com', forms part of a URL. Hence, you often see these terms used interchangeably. |
V
Term | What is it? |
---|---|
Verifiable Credential (VC) | Credentials are sets of claims that identify a particular entity or verify a specific attribute or qualifications such as driver's license, enterprise ID, and university degrees. W3C Verifiable Credentials provide a mechanism to express these sorts of credentials on the web in a cryptographically secure, privacy-respecting, and machine-verifiable way. Dive Deeper - W3C VC Use Cases |
Verifiable Data Registry (VDR) | A system or network that facilitates the creation, verification, updating, and/or deactivation of DIDs and DID documents, and even 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. |
Verifiable Presentation (VP) | A digital presentation is created from VC data in order to be shared with a verifier. A VP is a tamper-evident digital presentation that can be cryptographically verified to ascertain the trustworthiness of the presented data. Certain VP types might contain data that is synthesized from, but does not contain, the original verifiable credentials (for example zero-knowledge proofs). Dive Deeper - W3C VC Data Model - VP |
Verification Router Service (VRS) | VRS refers to a third-party routing system to send product information back and forth between pharmaceutical supply chain actors. Generally, the manufacturer holds all the required product identifier information. Upon information requests from downstream supply chain partners, e.g. dispensers or wholesalers, the manufacturer releases the requested information. This exchange is facilitated by VRS. Hence, within CARO a VRS can act on behalf of the VC holder (when generating a verifiable presentation) or the verifier (when verifying a verifiable presentation). Dive Deeper - HDA Saleable Returns Pilot |
W
Term | What is it? |
---|---|
Wallet | See digital wallet |