# Introduction

<div align="left"><figure><img src="/files/0rxUqG05cq3iEMjIWson" alt="" width="307"><figcaption></figcaption></figure></div>

Indicio Proven helps businesses easily implement reliable and scalable decentralized identity solutions. With a plug-and-play suite of tools and services, it streamlines operations, reduces manual processes, and accelerates deployment while ensuring modern, secure data verification. Indicio Proven provides everything needed to create, issue, verify, and manage verifiable credentials using W3C decentralized identifiers (DIDs).

It’s easy to scale from simple use cases to managing national and global identity verification. Indicio Proven allows you to build in a way that works best for you, with flexible deployment options, including on premises, in Amazon Web Services, Azure, Google Marketplace, Oracle, or a provider of your choice.

## About Us

Indicio is a global leader in digital identity, authenticated biometrics, and verifiable credential technology with scalable solutions that organizations can easily and rapidly deploy for increased efficiency, better user experience, and reduced cost. Our award-winning enterprise solution, Indicio Proven®, offers the widest range of interoperable decentralized identity options for global deployments, from single sign-on to seamless border crossing, as well as compatibility with the European Union’s digital identity and wallet standards and leading open-source specifications. Learn more about how Indicio is using this technology to successfully transform education, finance, government, health, travel and tourism, and supply chains at indicio.tech.

## Public Benefit Corporation&#x20;

Founded in 2020, on the belief in privacy and security by design, Indicio supports the open source and interoperability goals of the decentralized identity community. Indicio is committed to advancing decentralized identity as a public good that enables people to control their identities online and share their data by consent. Identity should be simple, inclusive, and work for everyone.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio Proven®

## A complete verifiable credential solution for identity and data

### Seamless, streamlined, and secure identity verification

Indicio Proven is the world’s most advanced platform for decentralized identity using verifiable credentials and Open Badges 3.0.

It is designed to provide the widest possible range of options to build, deploy, scale, and manage verifiable credential ecosystems.

It is built to be interoperable and compatible with current and emerging global protocols and standards for decentralized identity, including the European Union’s new standards for digital identity (eIDAS) and digital wallets (EUDI).

It’s easy to implement — a platform that can work with your existing systems, and it is configurable in days rather than months.

And it’s easy to scale from simple use cases to managing national and global identity verification.

Verifiable credentials are a powerful new way to authenticate identity and data. As **Gartner Research** notes in its **2024 Market Report for Decentralized Identity**, they represent “magnitudes of improvement in terms of efficiency, cost and assurance.”

Indicio Proven allows you to build in a way that works best for you, with flexible deployment options, including on premises, in **Amazon Web Services, Azure, Google Marketplace, Oracle, or a provider of your choice.**

## What's included

### Issuer & Verifier Agents

The software needed to create, issue, and verify credentials.

### Mobile App & Mediator

The software to download, store, and use credentials on mobile devices.

### Verifiable Credential Schema

Flexible template for creating credentials.

### Distributed Ledger Network

Make use of a robust and stable distributed ledger, professionally managed by Indicio, choose the provider that works best for you, or have us build your own distributed ledger network.

### Technical support & training

## Benefits

* Verifiable credentials can hold all kinds of valuable information in a way that any attempt to alter that information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* You are always able to verify who you share data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is secure — no need for third parties to store the data in centralized databases to manage authentication.
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Verifiable credentials can protect biometric data from AI deepfakes.

## Unlocking efficiency, savings across industries and sectors

Indicio has years of experience developing and implementing verifiable credential solutions for global enterprises and governments. Here are just a few examples.

### Travel, Hospitality, & Tourism

Indicio is the leading developer of award-winning decentralized identity solutions for the air transport sector, and Indicio Proven® provides multiple ways to deploy verifiable credentials for seamless, secure, identity authentication with privacy-preserving features.

For complex information flows where security is critical, Indicio developed and deployed the world’s first Digital Travel Credential based on the International Civil Aviation Organization (ICAO) standards.

This “government-grade” digital identity enables passengers to convert their passports into authenticated digital credentials that can be used for pre-authorization for travel and seamless border crossing. Our DTC technology is being implemented by airlines and governments around the world, and is being extended to include immigration visas, airport lounge access, hotel check-in, and customer loyalty programs.

### Banking & Finance

Indicio Proven provides comprehensive verifiable credential solutions for rapid, remote onboarding, seamless account access and reusable (with expiration) Know-Your-Customer (KYC) checks.

By issuing a biometric template as a verifiable credential, institutions have a powerful way to verify liveness without having to store biometric data — and they can implement simple, instant workflows to defeat AI-generated identity fraud.

## Customers

Our customers are using Indicio Proven to create simple solutions to complex information problems, replacing manual processes, reducing error and friction, and developing markets through portable trust. Here are a few examples.

### Agriculture

Digital agriculture leverages the ubiquity of mobile devices to share critical data. Indicio created an entire ecosystem for farmers in New Zealand to share emissions and compliance data tied to geospatial location with key stakeholders in the agricultural value chain. The project, run by Trust Alliance New Zealand, has won a 2024 SuperNova Award from Constellation Research for Digital Safety, Governance, Privacy, and Cybersecurity.

### Education

USA Kansas is using Indicio Proven’s Open Badges 3.0 option to manage training and certification for teachers across the state.

### AI & IoT

The combination of secure, verifiable digital identity, secure, bi-directional communication, and decentralized governance enable a host of critical features for managing AI agents, chatbots, digital twins, drones, and smart cities. Whether it’s decentralized command and control of drone flight paths, permissioning verifiable AI agents to access your data, or personalized, secure chatbot interaction, Indicio Proven provides powerful, elegant solutions to the emerging authentication and communication challenges around new technologies.

### Book a demo — and learn how easy it is to get started, use, and generate value using Indicio Proven!


# A Complete Ecosystem

Indicio Proven comes ready with everything you need to create, exchange, and verify digital credentials in a secure, privacy-preserving manner.

<figure><img src="/files/eES1ESkv70uKBcS6F2dn" alt=""><figcaption></figcaption></figure>

## 1. Issuer

The issuer is an entity that creates and provides verifiable credentials to holders.&#x20;

Responsibilities:

* **Credential Creation:** Issues credentials that are cryptographically signed to ensure authenticity.
* **Data Source:** Acts as the trusted source of information contained in the credentials.
* **Examples:** Government agencies issuing digital IDs, universities issuing diplomas, or banks issuing creditworthiness statements.

## 2. Holder

The holder is the individual or entity that owns and controls the verifiable credential.&#x20;

Responsibilities:

* **Credential Storage:** Stores credentials securely, often in a digital wallet.
* **Consent and Sharing:** Shares credentials selectively with verifiers when needed.
* **Examples:** A student holding a digital diploma or a traveler holding a digital passport.

## 3. Verifier

The verifier is an entity that validates the authenticity and integrity of a verifiable credential.&#x20;

Responsibilities:

* **Verification Requests:** Requests credentials from the holder for authentication or authorization.
* **Credential Validation:** Uses cryptographic proofs to ensure the credential is issued by a trusted issuer and has not been tampered with.
* **Examples:** Employers verifying a candidate’s diploma or an airport validating a digital passport.

## 4. Governance Rules

The governance rules define the rules and standards for how verifiable credentials are issued, held, and verified.&#x20;

Responsibilities:

* **Establishes trusted relationships** among issuers, holders, and verifiers.
* **Specifies technical and policy requirements** for interoperability and compliance.
* **Examples:** Emerging European identity regulations, eIDAS and EUDI for digital wallets.

## 5. Mediator

A mediator plays a crucial role in enabling seamless, secure communication and interaction between mobile digital wallets and other entities (issuers, verifiers, and other wallets) in decentralized identity ecosystems. A mediator does in relation to mobile digital wallets:&#x20;

Responsibilities:

* **Facilitates Secure Connections:** Mobile wallets often need to establish secure, private channels for exchanging verifiable credentials and other data. This is especially useful for wallets on devices that are not always online or directly addressable (e.g., behind a firewall or NAT).
* **Routes Message:**  Mobile wallets may not be constantly connected to the internet, making direct communication with other parties (issuers, verifiers, or holders) challenging. The mediator acts as an intermediary to store and forward messages. It ensures that messages sent to the wallet are reliably delivered when the wallet becomes available.
* **Supports Credential Exchange:** Mediators play a role in helping mobile wallets request and receive credentials from issuers and present credentials to verifiers, often through secure and automated communication channels.
  * **Example:** The Indicio provides a mediator service that supports mobile wallets by managing secure communication channels. It allows wallets to exchange verifiable credentials even when they are not always online or directly reachable.

## 6. Verifiable Data Registry or Network

A registry or ledger may be used to publish public information, such as issuer credentials or revocation lists.&#x20;

Responsibilities:

* **Stores metadata** (not user information or credentials) like public keys or credential schemas.
* Verifiers use it to **confirm the trustworthiness** of an issuer or the revocation status of a credential.
  * **Examples:** Blockchain networks like Hyperledger Indy or the [**Indicio Network**](https://indicio.tech/indicio-mainnet/)**.**

## Key Interactions

* Issuers provide credentials to holders.
* Holders share credentials with verifiers.
* Verifiers validate the credentials using public keys or registries.
* All interactions occur under a governance framework to ensure security and trust.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Use Cases

Indicio has years of experience developing and implementing Verifiable Credential solutions for global enterprises and governments.

Our customers are using Indicio Proven to create simple solutions to complex information problems, replacing manual processes, reducing error and friction, and developing markets through portable trust.&#x20;

<figure><img src="/files/hZOLoZ23tPxTcYkxGhqm" alt=""><figcaption></figcaption></figure>

### Here are a few examples:

* [AI](/product/introduction/use-cases/ai)
* [Travel and Tourism](/product/introduction/use-cases/travel-and-tourism)
* [Government Services](/product/introduction/use-cases/government-services)
* [Education](/product/introduction/use-cases/education)
* [Banking](/product/introduction/use-cases/banking)
* [Biometric Verification](/product/introduction/use-cases/biometric-verification)
* [Access Management](/product/introduction/use-cases/access-management)
* [Open Badges](/product/introduction/use-cases/open-badges)
* [Financial Services](/product/introduction/use-cases/financial-services)
* [Mobile Driver's Licenses](/product/introduction/use-cases/mobile-drivers-licenses)
* [Enterprise Solutions](/product/introduction/use-cases/enterprise-solutions)
* [Healthcare Credentials](/product/introduction/use-cases/healthcare-credentials)
* [Employee Credentials ](/product/introduction/use-cases/employee-credentials)
* [Digital Passports](/product/introduction/use-cases/digital-passports)
* [Citizen ID](/product/introduction/use-cases/citizen-id)
* [Decentralized Ecosystem Governance](/product/introduction/use-cases/decentralized-ecosystem-governance-degov)
* [Border Management](/product/introduction/use-cases/border-management)
* [Zero Trust Architecture](/product/introduction/use-cases/zero-trust-architecture)
* [Web3 Infrastructure](/product/introduction/use-cases/web3-infrastructure)
* [Government issued credentials](/product/introduction/use-cases/government-issued-credentials)


# AI

As AI agents begin to take on sensitive tasks—from travel planning to healthcare coordination—we need to verify who they are, confirm who they represent, and ensure they access our data and act only with our permission. ProvenAI brings a trusted identity layer to AI by using standards-based verifiable credentials and privacy-preserving protocols to establish cryptographic trust.

ProvenAI addresses a fast-emerging need across sectors like travel, finance, education, where AI is already being deployed. It is ideal for customer-facing AI systems, like chatbots that book travel, process loan applications, or assist with student services—where trust, authentication, and compliance are non-negotiable.

#### How ProvenAI Works

* Prove the AI agent is legitimate\
  AI agents hold and present verifiable credentials to prove their identity and permissions when interacting with services or users.
* Consent to share personal data\
  Users share identity information with the AI agent using verifiable credentials, seeding the agent with the information it needs to provide accurate and relevant information.
* Authenticate users without revealing data\
  ProvenAI supports biometric-linked credentials and zero-knowledge proofs to confirm identity without exposing sensitive data.

ProvenAI is built on Indicio Proven and aligned with EUDI, ISO, and W3C standards, delivering global interoperability with support for wide range of standardized credential formats—including SD-JWTs, mdoc/mDL, JSON-LD, and AnonCreds—and widely used communication protocols like DIDComm and OpenID4VC.

The combination of secure, verifiable digital identity, secure, bi-directional communication, and decentralized governance enable a host of critical features for managing AI agents, chatbots, digital twins, drones, and smart cities. Whether it’s decentralized command and control of drone flight paths, permissioning verifiable AI agents to access your data, or personalized, secure chatbot interaction, Indicio Proven provides powerful, elegant solutions to the emerging authentication and communication challenges around new technologies

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Travel and Tourism

Provide an entirely new, seamless, integrated, and luxurious traveler experience.

Indicio is the leading developer of award-winning decentralized identity solutions for the air transport sector.&#x20;

For complex information flows where security is critical, Indicio developed and deployed the world’s first Digital Passport Credential based on the International Civil Aviation Organization (ICAO) standards.&#x20;

Indicio Proven® provides multiple ways to deploy digital identity with biometric authentication for seamless travel and border crossing using verifiable credentials based on ICAO DPC Type 1 specifications.

This “government-grade” digital identity enables passengers to convert their passports into authenticated digital credentials that can be used for pre-authorization for travel and seamless border crossing. Our DPC technology is being implemented by airlines and governments around the world, and is being extended to include immigration visas, airport lounge access, hotel check-in, and customer loyalty programs.

### Indicio is the leading innovator in decentralized digital identity for travel.

* World’s first successful implementation of ICAO’s DPC Type 1 specifications in a verifiable credential.
* World’s first successful implementation of IATA’s One ID in a digital wallet for travel.
* World’s first successful combination of a DPC Type 1 and OneID for international travel.

### Benefits

Seamless authentication with government-grade digital identity including authenticated biometrics enables digital transformation across the travel ribbon to remove friction, error from manual data entry, and delay from manual security touchpoints — all without airlines and airports having to securely manage their passengers’ personal data.

With an Indicio Digital Passport, travelers can fully consent to share their biographic and biometric information in advance of arrival, enabling pre-authorized travel and seamless border crossing.

Airports can streamline check-in, baggage management, access to lounges, and boarding because passengers can hold and share authenticated biometric and biographic data from a verifiable digital passport. This means reduced congestion and anxiety for travelers, at the same time as Increase airport capacity without increasing resources.

Airlines can know that every traveler has been precleared to board international flights, reducing the risk of fines for inadmissible travelers. Airlines can always and instantly know their customers when they log in to airline websites and use loyalty programs — and customers can be sure they are logging into their airlines.

### With a verifiable Digital Passport and authenticated biometrics, border crossing takes seconds…

Often, less than 3 seconds, offering potential improvement of over 80% compared to agent-to-traveler experience, and up to 50% improvement  compared to many e-gates\*

\*Border admission times vary, therefore improvement metrics will vary accordingly.

**Easy to implement, can work with any system…**\
… takes just days to implement, a couple of weeks to trial, and when operational it can scale to handle all your needs — with minimal changes needed to your existing infrastructure. Indicio is the global expert in mediation, the key technical process of connecting credential issuance and verification to mobile devices.

**Solves the compliance challenges around biometrics and GDPR**\
With Indicio’s Digital Passport, the passenger holds their own biometric data, sharing it with explicit consent. Biometric presentations can be combined and compared with liveness checks to ensure the highest level of authentication, and can be deployed in multiple workflows to counter the risk of generative AI deepfakes.

**Comes with a Mobile SDK**\
So you can quickly and easily implement an Indicio Digital Passport and other verifiable credentials into your apps — we’ve compiled all the code you need for Android and IoS.

**Easy for travelers to use**\
Crucially, an Indicio Digital Passport is easy for a traveler to create and use as its based on familiar mobile technology.

\
**Use a Digital PassportCredential**\
Scan and transform your passport into a verifiable credential (with liveness and biometric assurance) for check in and border crossing.

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfT24WV4Ztpvkpi_BWkE4ZzcX3dU_U8lRezPMPjAmjNesDmw9h-uYy3IWDUy1vNgyMS94_3JKhuv0yYCFLHsRnoyZNpe2oJMNGNrMFYpz5EuRUJzbdGqQ9WKdPJODE21AbJjvi75A=s2048?key=Ut76evrs-v2zDL5BHP6KsFDZ" alt=""><figcaption></figcaption></figure>

* **Manage check-in**\
  Customers can pre fill out any information needed for their stay, recurring only a quick scan at the front desk to check in at a hotel or potentially just issuing digital room keys without a check in.
* **Digital room keys**\
  Securely issue and revoke room keys directly to customers, reducing time spent at the front desk.
* **Store tickets on a credential**\
  You can manage your airport experience through a credential, storing boarding pass info, passport info, and visa details in a way that is easily shareable.
* **Manage loyalty programs**\
  Verified loyalty program holders can be offered special deals, quick and easy lounge access and more.
* **Reduce fraud**\
  Credentials will immediately alert you if any information presented is fraudulent.
* **Reduce liability**\
  Remove the need to store any customer information locally, which also removes the need to delete it in a regulatory compliant way.
* **Reduce the stress of travel**\
  When traveling is easy and everything a traveler needs is accessible through one place on their phone they are more likely to do it more.
* **Reduce lines**\
  A quick scan keeps the line moving much faster than a person checking every ID and document.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Government Services

Digital identity for citizen services, reducing fraud.

* **Replace your passwords with credentials**\
  Unlike passwords, credentials cannot be lost, stolen, or copied, and don’t require your employees to remember them.
* **Access management**\
  Both physical and digital access management can be done through credentials for enhanced security — and unlike access cards, credentials cannot be lost, stolen, or copied.
* **Manage social and welfare programs**\
  By issuing each citizen a credential you can reduce fraud in aid / benefits applications.
* **Employment authorization**\
  Ensure that applicants are eligible to work.
* **Manage travel**\
  Verifiable credentials can replace passports and offer a faster, more secure way to cross borders.
* **Replace driver’s licenses**\
  These licenses would be impossible to fake and offer a fast way to provide only the identity information necessary when needed.
* **Replace important personal documents**\
  Marriage licenses, death certificates, social security information could all be digitized and more secure than a paper document that can be lost or damaged.
* **Proof of residency**\
  By using credentials you could automate parts of the residency process and quickly verify status.
* **First responder credentials**\
  Quickly ensure only authorized personnel are allowed access to emergency areas.
* **Replacement permits**\
  Digitizing permits would speed up the process for checking that they are up to date and could notify holders when they are about to expire and need to be renewed.
* **Professional licenses**\
  Know for certain that your doctor or lawyer is licensed, and allow the end customer to verify their credentials for themselves.
* **Certifications**\
  Keep your certifications up to date and easily share them, as opposed to keeping them safe in a box somewhere.
* **Manage age restricted substances**\
  By sharing identification through a credential you can be more confident that only people that are old enough are buying restricted products.

<figure><img src="/files/HnKFsTuDom5b4T4bq6Mx" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Education

[Verifiable credentials](https://indicio.tech/what-are-verifiable-credentials-with-pictures/) in education allow students to share their data with verifying parties — such as places of employment or universities — without the need to check in with the original source of that information, namely the school or college where they did their coursework or received their diploma.&#x20;

* **Immediate proof of degrees and accreditation**&#x20;
* **Prove specific skills with microcredentials**
* **Eliminate redundant paperwork and manual processes**

### Indicio adds functionality to your student ID

By using verifiable credentials and Open Badges 3.0, Indicio can issue credentials to students’ mobile devices that allow them to cryptographically prove identity for both physical and digital access management and store important data like transcripts and diplomas on their mobile devices. As a result, students no longer need to manually contact and verify information with their issuing universities. Most implementations are completed within 12 to 48 hours.

### For Educational Institutions

* Increase efficiency,  eliminate the need for password resets, and prevent students from being locked out due to user error.
* Reduce the need to manually look up student grades when other universities or businesses need to verify them.
* Increase security with phishing-proof verifiable credentials; unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Provide a more convenient and automated information sharing process for faculty and students.

### For Students

* Simplify sharing and authentication with locally stored student records and eliminate waiting time.
* Quickly access school resources and buildings with the tap of a QR code instead of requiring physical keys, passwords, or student ID cards.
* Easily store student information in one place, removing the need to track down physical documents and paperwork.
* Diplomas and student information remain verifiable even if the educational institution experiences technical outages or becomes unreachable.

<figure><img src="/files/S2leWxDKVLJYZQkHy9pd" alt=""><figcaption></figcaption></figure>

* **Student awards and certificates**\
  Quickly issue and securely store any awards a student receives from the school.
* **Student access management**\
  Easily issue or revoke access to buildings or digital assets.
* **Diplomas**\
  Issue verifiable certificates of completion that can be quickly shared with prospective employers, removing the need to contact the school.
* **School issued permits**\
  Quickly issue and check parking permits, bike permits, and residential permits etc.
* **Reduce liability**\
  Unlike passwords or keys these credentials can’t be misplaced, stolen, or copied, so you can be more confident that only students have access to school areas.
* **Reduce student stress**\
  You can store all the classes a student has completed on a credential, streamlining the process for knowing which classes they are eligible to take next.
* **Faster data sharing**\
  All the data a student accumulates through the education process can be stored on one credential, removing the need to look back through paper records.

### Customer Success

USA Kansas is using Indicio Proven’s Open Badges 3.0 option to manage training and certification for teachers across the state.\
\
*"After learning about the technology and learning about the complete suite of software and tools that Indicio offers, we’re excited to use Indicio Proven to make it easier for our members to transmit learning transcripts and reduce the complexities associated with verification of information and data related to their educational achievements.”*  **Jerry Henn, Assistant Executive Director, United School Administrators of Kansas**

<figure><img src="/files/MKcDSjqdXCmB6TM4bLgS" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Banking

Improving the customer experience without sacrificing security or privacy

## Transforming Account Recovery for Banks with Verifiable Credentials

Indicio Proven provides comprehensive verifiable credential solutions for rapid, remote onboarding, seamless account access and reusable (with expiration) Know-Your-Customer (KYC) checks.&#x20;

By issuing a biometric template as a verifiable credential, institutions have a powerful way to verify liveness without having to store biometric data — and they can implement simple, instant workflows to defeat AI-generated identity fraud

## Account recovery made easy

Indicio Proven offers an innovative, decentralized identity solution that transforms account recovery by leveraging verifiable credentials within a digital wallet. This solution enables secure, frictionless identity for quick account recovery while reducing operational costs and improving compliance readiness.

### How It Works

1. Issue a Recovery Credential:

Upon account creation, the bank issues a recovery verifiable credential (VC) to the customer. This credential is stored in the customer’s digital wallet within their banking app. The credential is cryptographically secure, private, and tamper-proof.

2. Self-Service Recovery Process:

If a customer needs to recover their account, they simply present their VC via their secure digital wallet. The bank verifies the credential providing instant and reliable credential validation, no knowledge-based authentication (KBA) or passwords required.

3. Enhanced Security Measures:&#x20;

Biometrics can be bound with the verifiable credential for added security, ensuring compliance with banking regulations.

<figure><img src="/files/XBgQEABufhVq7orcmOez" alt=""><figcaption></figcaption></figure>

## Why Indicio Proven?

* Interoperable: Compatible with major digital wallet providers and existing banking systems.
* Scalable: Handles large-scale deployments across multiple branches and regions.
* Customizable: Tailored technology selections to fit specific regulatory and operational needs.
* Proven Expertise: Trusted by industry leaders, including SITA, IATA, and governments, for its secure, scalable verifiable credential solutions.

### Challenge: Stress-free account recovery in banking

Account recovery is a critical process for financial institutions, yet it often causes frustration for customers and operational inefficiencies for banks. Traditional recovery methods rely heavily on outdated mechanisms such as knowledge-based authentication (KBA) and manual identity verification, which introduce challenges:

* Compliance Strain: Regulatory requirements around data privacy and security intensify the need for robust and auditable solutions.
* Customer Friction: Long wait times and multiple verification steps create frustration, reducing customer satisfaction and loyalty.
* Security Risks: KBA and other traditional methods are vulnerable to fraud, phishing, and social engineering attacks.
* Operational Costs: Manual verification processes demand significant resources and time, driving up costs for banks.

\
Benefits for Banks
------------------

**Streamlined Customer Experience:**

Eliminates lengthy manual verification steps, enabling near-instant account recovery. Reduces frustration and improves customer satisfaction.\
\
**Enhanced Security:**

Cryptographic verification significantly reduces the risk of fraud and phishing attacks. Decentralized identity ensures that sensitive customer data is not stored in a centralized database, minimizing the risk of breaches.\
\
**Cost Savings:**

Automating the recovery process reduces operational overhead, allowing staff to focus on higher-value tasks.\
\
**Regulatory Compliance:**

Indicio Proven’s decentralized identity framework aligns with privacy laws such as GDPR and CCPA, ensuring secure and auditable processes.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>

\ <br>


# Biometric Verification

## ‘Bring your own biometrics’ Secure biometric data against fraud and AI deepfakes with verifiable credentials

### &#x20;Biometric verification without the risk of having to store biometric data

Biometrics were supposed to solve the problem of passwords. But if a password is stolen, it can be reset. If biometrics are stolen or faked using generative AI, they become an existential threat: You can’t reset someone’s face.

With Indicio Proven, biometric data can be bound to a verifiable credential so that verifiers do not have to store the biometric data to authenticate it.&#x20;

<figure><img src="/files/ApuTz4W8Vuh5rj05L19L" alt=""><figcaption></figcaption></figure>

This also protects against generative AI deepfakes.

* Capture a person’s biometrics in a template during identity assurance and issue the template as a verifiable credential.
* The person presents the verifiable credential when they use biometric authentication and the verifier compares the two to make sure they match. The verifying party records validation and discards the template for simple data privacy compliance.
* No centralized biometrics database is required for authentication.
* Authenticity and integrity of biometric details are cryptographically provable.
* Provides a quick, simple, low-cost way to defend against generative AI deepfakes.
* No loss of biometric verification process benefits.
* Consent is architecturally required, making data protection compliance easy.

Bringing your own biometrics reassures public over biometric privacy and security.

<figure><img src="/files/g3etQJNhHr8uFs4Jpej2" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Access Management

## Easily control access to important information and areas with verifiable credentials

By using verifiable credentials, Indicio is able to issue credentials to user’s mobile devices that allow them to cryptographically prove their identity for access management to both physical buildings and the digital files and programs, such as those employees require to work.

## Indicio Proven Auth Overview

Proven Auth is an OpenID Connect identity provider, similar to Google, Azure Active Directory, Auth0, Keycloak, etc. What makes Proven Auth unique is that rather than relying on a centralized database of users, Proven Auth uses digital credentials to authenticate its users. These credentials are signed by any Issuer that Proven Auth has been configured to trust. In short, Proven Auth is a credential verifier that can speak OpenID Connect to act as an Identity Provider.

## What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. It enables authentication in a standardized way and facilitates secure interaction between different systems. OIDC is widely used for Single Sign-On (SSO) solutions, where users can authenticate once and access multiple systems seamlessly.

Chances are you’ve used OpenID Connect before, whether you realized it or not. When you see a button on the login form of a website that says “Login with XYZ,” there’s a good chance that login is accomplished using the OpenID Connect protocol.

## How does OIDC Work?

OpenID Connect works by letting one system – called the Identity Provider (IdP) – handle authentication for other systems that trust it. These other systems are referred to as the Relying Party (RP). Here’s what happens in practice: When you try to log into an application, instead of asking for your username and password directly, the app sends you to the Identity Provider. The IdP is responsible for verifying your identity, which might involve entering a password, using a security code, or confirming via an app.

Once the IdP confirms who you are, it sends a token back to the application. This token contains information about you, such as your name or email address, and proves to the application that you’ve been authenticated. The application checks the token, and if it’s valid, it lets you in.

The advantage is that the IdP can handle authentication for multiple applications. After logging in once, you won’t need to log in again as long as all the applications trust the same IdP. This is what makes Single Sign-On possible.

## How does Proven Auth Work?

Proven Auth acts as a bridge between “traditional” web services and Digital Credential enabled systems. To traditional web services, Proven Auth is just another OpenID Connect Identity Provider, making it trivial to integrate into an existing website through the plethora of OIDC plugins and libraries available for virtually every web framework.

When the RP asks Proven Auth to authenticate a user through standard OIDC requests, Proven Auth creates a Presentation Request and makes it available to the End-User, or in Digital Credential terminology, the Wallet or Credential Holder. The Holder then presents the requested credential to Proven Auth where the credential is verified and then transformed into an ID Token to be returned to the RP.

## Organization benefits

* Increase efficiency, eliminate the need for password resets, and prevent users from being locked out due to user error.
* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Easily revocable – No requirement to change  access rights, passwords, or collect keys when an employee leaves.
* Protect yourself from deepfakes and establish a more secure verification process online before sharing sensitive information.
* Integrate into existing systems easily and enable a robust identity layer for Zero Trust architecture.

## User benefits

* All access information is stored securely on the employee's mobile device, removing the need to carry keys, physical ID cards, or remember passwords.
* Know that your personal information is secure because there is no centralized database of logins and passwords.
* Simple, secure, and easy to use interface removes tedious multi-factor authentication.
* Fight impersonation attacks with credentials that can only be presented by the person they are issued to.

<figure><img src="/files/XhlO685LMXMDOx5vySie" alt=""><figcaption></figcaption></figure>

[Contact Us Today To Get Started](https://indicio.tech/contact/)

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Open Badges

## Indicio simplifies proving achievements and skills without relying on a third-party provider

By using verifiable credentials, Indicio is able to issue proof of achievements and new skills as Open Badges 3.0, allowing users to securely hold these badges on their mobile devices and share them at their discretion without relying on a third-party hosting platform or provider.

## For Educational Institutions

* Provide a more convenient and automated information sharing process for faculty and students.
* Remove the need to manually look up student grades when other universities or businesses need to verify them.
* Remove reliance on third-party providers to store and share student achievement data.
* Fight fraud and phishing attempts with tamper-proof and uncopiable badges.

## For Students

* Simplify sharing and authentication and eliminate waiting time with locally stored student records.
* Easily store all your achievement information in one place, removing the need to track down physical documents and paperwork.
* Diplomas and student information remain verifiable even if the educational institution experiences technical outages or becomes unreachable.

<figure><img src="/files/Q2fZkqa0ddzuSqopxe9U" alt=""><figcaption></figcaption></figure>

<br>

**Overview:** Open Badges were launched in 2011 by the Mozilla Foundation with support from the MacArthur Foundation as an open specification and infrastructure for creating and sharing digital records of skills and achievements.

* With this infrastructure, the badges could only be issued to a certified Open Badges platform and could not be sent directly to recipients. Badges hosted on a website could also be changed without showing any record of the change.
* [The Open Badges 3.0 specification](https://www.imsglobal.org/spec/ob/v3p0/#abstract-0), created by the global educational nonprofit, [1EdTech](https://www.1edtech.org/), solved these challenges by updating the specification to align with the [W3C Verifiable Credential Data Model](https://www.w3.org/TR/vc-data-model/).
* Now, a badge can be issued directly to a recipient’s digital wallet application on a mobile device. And, as a badge is digitally signed, it cannot be altered or tampered with once it has been created.
* As 1EdTech [says](https://www.imsglobal.org/spec/ob/v3p0/#what-is-the-problem-this-solves-for), with a verifiable credential format, badges can support “limitless claims,” and provide enhanced security and privacy through cryptographic verifiability.
* The updated specification meets “market needs for trustworthy machine-ready data to power connected ecosystems in education and the workforce.”

## Advantages of Implementing Open Badges 3.0 as Verifiable Credentials

* Portability: They are no longer tied to an Open Badge Platform. An Open Badge recipient holds their credentials in their digital wallet.
* Immutability: They are now digitally signed in a way that prevents alteration after issuance.
* Resilience:They are not tied to a platform or API that could fail or go out of business.

As 1EdTech notes: The verifiable credential format enables “limitless claims,” enhanced security and privacy through cryptographic verifiability, and meets “market needs for trustworthy machine-ready data to power connected ecosystems in education and \[the] workforce.”

## Why Verifiable Credentials and Open Badges 3.0?

* Verifiable credentials can hold all kinds of valuable information in a way that any attempt to alter that information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* You are always able to verify who you share data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is secure — no need for third parties to store the data in centralized databases to manage authentication.
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Verifiable credentials can protect biometric data from AI deepfakes.

## Indicio’s Implementation of OpenBadges 3.0

* Following 1EdTech’s 3.0 standard, Indicio Proven now enables Open Badges as verifiable credentials.
* This means that Open Badges can be directly issued to a digital wallet, overcoming a key limitation of previous Open Badge implementations.
* Open Badges are now immutable, portable, private, and secure.

## Additional features for Openbages in Indicio Proven

* The ability to issue micro credentials
* The ability to create profiles
* Bulk issuance and messaging
* DIDComm is available as an option, allowing personalized interaction
* LinkedIn posting

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Financial Services

## Indicio simplifies customer account access and allows you to reuse costly KYC information

Indicio uses verifiable credentials to issue decentralized digital identities directly to customers' mobile devices, enabling them to cryptographically prove their identity for account access with a simple tap. These credentials also allow for the secure storage of Know Your Customer (KYC) information in a tamper-proof and verifiable manner, making it trustworthy and reusable across your organization, and with partner organizations.

### For financial institutions

* Increase security with phishing-proof verifiable credentials; unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Protect yourself from deepfakes and stop fraud with mutual authentication that allows both parties to verify each other’s credentials before exchanging sensitive information.&#x20;
* Increase efficiency, eliminate the need for password resets, and prevent customers from being locked out due to user error.
* Keep all KYC information in one convenient, immutable place, allowing you to reuse information collected from customers easily across your organization.&#x20;
* Provide a better customer experience by removing passwords and tedious multi-factor authentication, allowing customers fast and secure access to accounts.

### For customers

* All account access information is stored securely on customers’ phones, removing the need to remember passwords or security questions.
* Store all your KYC documentation in one place and avoid needing to track down physical documents and paperwork.
* Simple, secure, and easy-to-use interface offers fast account setup, easy information retrieval, and reduces the chance of user error.
* Mutual authentication provides a more fool-proof way to ensure that it really is your bank reaching out about your account rather than a fraudster.<br>

<figure><img src="/files/yIh31orPwkzWq8yKzNLn" alt=""><figcaption></figcaption></figure>

## Reusable KYC processes for faster onboarding and compliance.

### Create once, use often

* Record all details needed for customer onboarding and risk assessment KYC credential schemas.
* Source of KYC and integrity of the data is verified through cryptography and digital signatures.&#x20;
* Credentials can be coded to expire.

<figure><img src="/files/4TpNxF550AZeZhW2vPwI" alt=""><figcaption></figcaption></figure>

* **Reduce fraud**\
  Use verifiable credentials for frictionless, mutual authentication before any data is shared. A bank is able to cryptographically authenticate that it is interacting with a real account holder, and the account holder is able to authenticate that he or she is interacting with their bank.
* **Reuse KYC information**\
  Credentials can be configured to store the information required for more complex financial transactions and a KYC credential is a way for a bank or its partners to reuse and share this information. If a third party trusts the original bank’s KYC process, they can trust the veracity of the KYC credential.
* **Provide more secure customer access**\
  The customer can securely access their account without a username or password.
* **Use as a credit card**\
  Credit card information can be put into a verifiable credential; virtual CC numbers can be used; temporary cards for one-time use can be issued as a credential.
* **Reduce the time necessary for larger transactions**\
  Credentials remove the need to contact third parties to verify funds.
* **Data sharing**\
  Know that any data shared with or between your team can be trusted.
* **Reduce liability**\
  The customer can choose to disclose only the information necessary for a transaction, removing the need to securely store or delete customer information.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Mobile Driver’s Licenses

What you need to know about Mobile Driver’s Licenses

*A Mobile Driver’s License (mDLs) is a digital specification for a physical driver’s license. Given that driver’s licenses are widely used for identification, it's likely that a digital version would enjoy similar ubiquity online. Here, we look at what exactly they are (are they verifiable credentials?) their benefits, and why they are not currently widely available.*

It all starts with the International Organization for Standardization (ISO) 18013 series. In a nutshell, this document creates a common standard for international recognition of a digital driver’s license.

**The standard lays out the scope as follows:**

* You must use a machine to obtain the mDL.
* The mDL must be tied to the mDL holder.
* You must be able to authenticate the origin of the mDL data.
* You must be able to verify the integrity of the mDL data.

**Critically, there are two things the standard does not cover:**

1. How the holder’s consent to share their data is obtained.
2. Any requirements on how the mDL data is stored.

So now we know what the mDL is: it is a driver’s license that can be stored on your mobile device and is tied to you. It can be proven to be as accurate as a physical card because we can prove that it was issued by a proper authority — such as the department of motor vehicles — and prove that the integrity of the data has not been compromised.

But an mDL is not the same as a verifiable credential because the mDL data can technically be stored in a siloed database. **However**, a verifiable credential, which allows a person to hold their data, could absolutely fit this standard and be used to easily issue mDLs, as they meet all the other requirements laid out above.

### The benefits

The benefit to using mDLs is similar to the benefits of using verifiable credentials. They are simple to verify and use, convenient, and often more secure than a physical document.

There are guides written on [how to spot a fake ID](https://www.webstaurantstore.com/blog/3402/how-to-spot-a-fake-id.html?srsltid=AfmBOop1f7y9DGx5ejqFKZGFKabvL_JdRGI5AyW3z1rb9eVgx_luzk4w). This is because each state has their own methods for trying to make their driver’s licenses difficult to counterfeit. An mDL offers a much simpler way to verify the identity of a person or their age for eligibility to purchase goods: all you need to do is scan the QR code and the software will tell you. You don’t need a flashlight, or to look for holograms.

Most people also now have a mobile device that is always with them. Carrying a digital version of your driver’s license allows you to not worry about accidentally leaving your ID somewhere or needing to fish through a bag to find it, it is always at your fingertips.

Lastly, the security features of these mDLs, especially if they are created through verifiable credentials, are hard to match. If the mDL is a verifiable credential, it is essentially immune to forgery because the software can cryptographically verify the origin of the data, and there is an additional layer of security from the data being stored on the holder’s mobile device instead of a centralized database, removing the risk from data breaches.

### Why are these mDLs not commonplace?

One of the reasons why these credentials have not yet been widely adopted is that regulations have not kept up with the technology.

In the US, the REAL ID act of 2005 wasn’t updated [until the end of 2020](https://www.congress.gov/bill/116th-congress/senate-bill/4133#:~:text=REAL%20ID%20Modernization%20Act%20This%20bill%20revises%20requirements,REAL%20ID%20Act%20of%202005.%20Specifically%2C%20the%20bill) to include permission for digital and mobile drivers licenses. But the federal government leaves the issuing of driver’s licenses to each state, meaning that the state governments also have to vote on implementation; as of August 2024, only [13 have passed](https://www.biometricupdate.com/202408/widespread-adoption-of-mdls-in-us-remains-a-slow-slog) legislation to start issuing mDLs.

If they are being issued by your state they are not currently a replacement for your license, but an additional way to represent it, meaning that you will likely still have a physical license somewhere. This could be another reason that many haven’t adopted them, they see it as an add-on that is unnecessary.

It's important to remember that this technology is still new. Many people might not understand or trust it yet, but as the world shifts to be more digital, it will be a big part of how we prove our identity moving forward.

If you are part of an organization looking into mDL technology, or a better way to prove your identity online, Indicio can help! [Get in touch with our team of experts today](https://indicio.tech/contact/).

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Access Management Credentials

## Easily control access to important information and areas with verifiable credentials

By using verifiable credentials, Indicio is able to issue credentials to user’s mobile devices that allow them to cryptographically prove their identity for access management to both physical buildings and the digital files and programs, such as those employees require to work.

## Organization benefits

* Increase efficiency, eliminate the need for password resets, and prevent users from being locked out due to user error.
* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Easily revocable – No requirement to change  access rights, passwords, or collect keys when an employee leaves.
* Protect yourself from deepfakes and establish a more secure verification process online before sharing sensitive information.
* Integrate into existing systems easily and enable a robust identity layer for Zero Trust architecture.

## User benefits

* All access information is stored securely on the employee's mobile device, removing the need to carry keys, physical ID cards, or remember passwords.
* Know that your personal information is secure because there is no centralized database of logins and passwords.
* Simple, secure, and easy to use interface removes tedious multi-factor authentication.
* Fight impersonation attacks with credentials that can only be presented by the person they are issued to.

<figure><img src="/files/vo5JISwiEuftwULVRzHN" alt=""><figcaption></figcaption></figure>


# Enterprise Solutions

Employee credentials and secure internal operations.


# Healthcare Credentials

## Secure sharing of health credentials and data privacy compliance.

By using verifiable credentials, Indicio is able to issue credentials to medical works and patient mobile devices that allow them to cryptographically prove their identity for access to healthcare systems, as well as securely store and share their medical history.

### Healthcare provider benefits

* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Fight fraud and reduce databreachs by removing reliance on centralized databases for sensitive information.
* Easily manage access, assign roles, and simplify data sharing across your organization.
* Provide a better experience for your patients with faster administrative tasks like document collection and their health records stored securely on their mobile device.
* Protect your systems and staff from deepfakes and fraud with mutual authentication, establishing two way verification process online before sharing sensitive information.

### Patient benefits

* Access healthcare benefits faster with less time spent on identity and document verification and more time spent addressing your needs.
* Easily share your medical records with new doctors, medical insurances, or new providers with one tap.
* Reduce identity theft and impersonation attempts with a secure digital identification that cannot be copied by bad actors.
* Store all of your healthcare records in one place, and eliminate the hassle of tracking down physical documents and paperwork or reaching out to your care provider.

<figure><img src="/files/azehZSCZoMETcCkKJEb6" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Digital Farming Solutions

## A powerful, portable, privacy-preserving data management solution that saves farmers time, money, and tedium

With Indicio Proven® Digital Farming, authenticated data can be shared instantly and reused endlessly

Farming is data-intensive work and each hour spent on data management is a measurable economic cost to farmers. Indicio Proven developed an award-winning solution to this problem using verifiable credentials and decentralized identity.

With a verifiable credential, a farmer can hold and manage authoritative farm data from their phone, share it seamlessly with other stakeholders in the agricultural value chain — suppliers, government agencies, financial services, and vendors — all while maintaining data privacy and protection.

With this easy-to-implement solution, data doesn’t need to be stored by third parties in order to be authenticated. Thanks to cryptography, the data shared from a credential cannot be tampered with — and the credential origin is always provable.&#x20;

This means that data can be reused over and over again with the absolute certainty that those who need to see it can verify it as authentic. It gives farmers the power to be their own data platforms, while radically simplifying their data management burden.<br>

* Connect authoritative data across different areas and systems.
* Capture data once in tamper-proof records that can be easily shared and reused.
* Fully own your farm data with permissioned, secure sharing to other parties.
* Farms and farmers hold their own data — not third parties.
* Simplifies access to global markets
* Proven success in New Zealand.

<figure><img src="/files/RZj2QqYGRrX0usd957Fi" alt=""><figcaption></figcaption></figure>

### A seamless way to control and share authenticated data&#x20;

Verifiable credentials can be configured to store all kinds of data for seamless, secure sharing:

* Biodiversity data
* Crop data
* Environmental data
* Farm management apps, sensors, drones
* Field boundaries
* Financial and compliance data
* Insurance
* Land data
* Livestock data
* Soil data

### Customer Success&#x20;

Indicio created an entire ecosystem for farmers in New Zealand to share emissions and compliance data tied to geospatial location with key stakeholders in the agricultural value chain. The project, run by Trust Alliance New Zealand, has won a 2024 SuperNova Award from Constellation Research for Digital Safety, Governance, Privacy, and Cybersecurity.&#x20;

*“Being able to quickly share data about their goods or emissions to these key relying parties provided a huge benefit to the farmers, saving them time, creating better connections between them and their customers, and reducing the amount of effort they have to spend filling out the same forms multiple times”* - **Sharon Lyon-Mabbet Project Manager at TANZ.**<br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Employee Credentials

## Indicio adds functionality to your employee ID

By using verifiable credentials, Indicio is able to issue credentials to employee mobile devices that allow them to cryptographically prove their identity for access management to both physical buildings and the digital files and programs employees need to work.

### For Employers

* Increase efficiency, eliminate the need for password resets, and prevent employees from being locked out due to user error.
* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Easily revocable – No requirement to change  access rights, passwords, or collect keys when an employee leaves.
* Keep all employee information in one convenient place, including documents created, contracts signed, and more.
* Protect yourself from deepfakes and establish a more secure verification process online before sharing sensitive information.

### For Employees

* All access information is stored securely on the employee's mobile device, removing the need to carry keys, physical ID cards, or remember passwords.
* Easily store all your employment information in one place, and eliminate the hassle of tracking down physical documents and paperwork.
* Simple, secure, and easy to use interface removes tedious multi-factor authentication
* Share proof of employment with partner organizations, such as insurance companies, with the tap of a button.

<figure><img src="/files/7D7rdNGumoQ6yo240g2E" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Digital Passports

## Seamless, government-grade digital identity with biometric authentication for travel and border crossing using Verifiable Credentials based on ICAO DPC Type 1 specifications

### Indicio is the leading innovator in decentralized digital identity for travel.

* World’s first successful implementation of ICAO’s DPC Type 1 specifications in a verifiable credential.
* World’s first successful implementation of IATA’s One ID in a digital wallet for travel.
* World’s first successful combination of a DPC Type 1 and OneID for international travel.

### Benefits

Seamless authentication with government-grade digital identity including authenticated biometrics enables digital transformation across the travel ribbon to remove friction, error from manual data entry, and delay from manual security touchpoints — all without airlines and airports having to securely manage their passengers’ personal data.

With an Indicio Digital Passport, travelers can fully consent to share their biographic and biometric information in advance of arrival, enabling pre-authorized travel and seamless border crossing.

Airports can streamline check-in, baggage management, access to lounges, and boarding because passengers can hold and share authenticated biometric and biographic data from a verifiable digital passport. This means reduced congestion and anxiety for travelers, at the same time as Increase airport capacity without increasing resources.

Airlines can know that every traveler has been precleared to board international flights, reducing the risk of fines for inadmissible travelers. Airlines can always and instantly know their customers when they log in to airline websites and use loyalty programs — and customers can be sure they are logging into their airlines.

#### With a verifiable Digital Passport and authenticated biometrics, border crossing takes seconds…

Often, less than 3 seconds, offering potential improvement of over 80% compared to agent-to-traveler experience, and up to 50% improvement  compared to many e-gates\*

\*Border admission times vary, therefore improvement metrics will vary accordingly.

**Easy to implement, can work with any system…**\
… takes just days to implement, a couple of weeks to trial, and when operational it can scale to handle all your needs — with minimal changes needed to your existing infrastructure. Indicio is the global expert in mediation, the key technical process of connecting credential issuance and verification to mobile devices.

**Solves the compliance challenges around biometrics and GDPR**\
With Indicio’s Digital Passport, the passenger holds their own biometric data, sharing it with explicit consent. Biometric presentations can be combined and compared with liveness checks to ensure the highest level of authentication, and can be deployed in multiple workflows to counter the risk of generative AI deepfakes.

**Comes with a Mobile SDK**\
So you can quickly and easily implement an Indicio Digital Passport and other verifiable credentials into your apps — we’ve compiled all the code you need for Android and IoS.

**Easy for travelers to use**\
Crucially, an Indicio Digital Passport is easy for a traveler to create and use as its based on familiar mobile technology.<br>

### Authenticated data, biometrics, and real-time consent can be used to streamline the entire travel ribbon, add partners, services, and integrate tourist economy

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfF7BguZ95VK4I2rLH5lpOG3YlIOywxqaCUI7x1SLnUiwUjbIN0aC7n-Yvp6rM65C2hZi7JxeIv5iZFpTm1fcWYyz1-u9kt0oRGg_MwOijEc21JvBaoLjROUzuYMqNz-U7sM7JW=s2048?key=I1wuzXK-ryh0pe2viWD9v6pc" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Citizen ID

## Indicio decentralizes and digitizes your citizen identity for faster, more secure access to government services.

By using verifiable credentials, Indicio offers you a way to issue secure, decentralized digital identities to your citizens that allow them to cryptographically prove their identity for fast and trusted access to government benefits and systems they need.

### Government benefits

* Increase security with phishing-proof verifiable credentials; unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Fight fraud and reduce data breaches by removing reliance on centralized databases for sensitive identity information.
* Provide a better experience for your citizens with fast, secure access to the information they need.
* Save time and money by removing the need to manually issue paper documents
* Protect your systems and staff from deepfakes and fraud with mutual authentication, which establishes a digital two-way verification process before sharing sensitive information.

### Citizen benefits

* Access the benefits you need with less time spent on identity and document verification.
* Reduce identity theft and impersonation attempts with a secure digital identification that cannot be copied by bad actors.
* Reduce dependency on collecting and keeping fragile paper documents for proving identity.
* Prove and verify identity in seconds with these fast, simple, easy-to-use credentials.
* Receive and renew documents with a significantly reduced wait time.

<figure><img src="/files/kXDwuyf7cZNGfUNtUjnB" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Decentralized Ecosystem Governance (DeGov)

## Indicio automates the rules for your decentralized ecosystem for quick and simple administration.

Every decentralized identity system requires established rules for its users. This includes specifying who within the system is permitted to issue credentials and what credentials are necessary for particular actions. DEGov offers an easy method for system operators to modify these rules and implement system-wide updates.

### Organization benefits

* Increased efficiency in creating and governing your decentralized identity solution.
* Offline functionality. Most systems require checking in with a governance authority before acting; Indicio’s system allows for caching the latest rules and enables actions when you don’t have a constant connection.
* Efficiently manage the entire decentralized identity solution and push system-wide changes with automation.
* Reduce liability for both the organization and users of the solution with built in rule-setting and automation. Indicio’s solution is engineered to ensure there is no chance of someone accessing something they shouldn't be able to.

Set up the rules quickly and easily without requiring technical expertise using Indicio’s simple and intuitive interface.

## User benefits

* Offline functionality ensures that you can use your decentralized identity whether you have a connection to the internet or not.
* Fast interaction times with the decentralized identity system through automation.
* Easily set up systems to accept a variety of credentials and allow the user to get more functionality out of credentials they already have.
* Automated rules provide more guardrails and security for the user’s personal information.

## DeGov covers

<figure><img src="/files/ZCe3N9j4vWxRB1dZxBFY" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Border Management

## Indicio enhances your border management strategy with tamper-proof verifiable credentials for identification

By using verifiable credentials, Indicio is able to issue secure decentralized digital identities to your users that allow them to cryptographically prove their identity for more streamlined border crossing.

## Organization benefits

* Bring more efficiency to border crossing with cryptographically verified credentials that can be shared with one tap — instead of paper documents that are more easily lost.
* Fight fraud with tamper-proof credentials that are biometrically tied to an individual and, unlike paper documents, cannot be lost, copied, or stolen.
* Remove your reliance on centralized databases for personal information and reduce liability and storage costs.
* Provide a better experience for your users with fast and secure access to the information they need.
* Automated for a faster and less expensive solution than traditional border management can offer.

## User benefits

* Digitally share your traveler information ahead of time and pass through border management much faster.
* Reduce identity theft and impersonation attempts with secure digital identification that cannot be copied by bad actors.
* Store all the information you need to cross the border in one convenient place no more searching for passports or other documents
* Easy to use interface puts you in control of your personal information.

<figure><img src="/files/uWSUjMyNFGlTlnO5aTbW" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Zero Trust Architecture

## Indicio enhances Zero Trust architecture by providing a more robust identity layer

By using verifiable credentials, Indicio is able to issue secure decentralized digital identities to your users that allow them to cryptographically prove their identity for fast, trusted access to systems and applications they need inside your Zero Trust environment.

## Organization benefits

* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Fight fraud and reduce data breaches by removing the reliance on centralized databases for sensitive identity information.
* Easily manage access and assign roles across your organization.
* Provide a better experience for your users with fast and secure access to the information they need.
* Protect your systems and staff from deepfakes and fraud with mutual authentication, establishing a two-way online verification process before sharing sensitive information.

## User benefits

* Access the applications you need with less time spent on identity and document verification.
* Reduce identity theft and impersonation attempts with secure digital identification that cannot be copied by bad actors.
* Eliminate time-consuming multi-factor authentication.
* Fast, simple, and easy to use, these credentials can contain all the information needed to prove identification across your organization and partner organizations.

<figure><img src="/files/gkRvc7f5ob4fQpKk2NqX" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Web3 Infrastructure

## Share and verify data without the need for direct integrations

Indicio’s verifiable credentials allow you to store data inside a secure credential and share it with anyone who has the verifier software without the need for integrations between systems and databases.

## Organization benefits

* Increase efficiency and eliminate the need for expensive and complex integrations between disparate systems.
* Enable secure login and access through personalized digital identities stored securely on the user’s mobile device. &#x20;
* Remove reliance on centralized databases for storing sensitive information and save your team money, time, and liability.
* Fight fraud and phishing attempts with data that can be cryptographically traced back to its source.
* Store important identity information conveniently in one place and easily share it across your organization and with partners without the need to re-collect data.

## User benefits

* All access information is stored securely on the employee's mobile device, removing the need to carry keys, physical ID cards, or remember passwords.
* Eliminate the hassle of tracking down physical documents and manually filling out paperwork.
* Simple, secure, and easy-to-use interface removes tedious multi-factor authentication and allows for faster data and document sharing.
* Store all of the data you need in one convenient place and share it securely with the tap of a QR code.

<figure><img src="/files/gu8JrmWFZ2AAo4ScP01B" alt=""><figcaption></figcaption></figure>

<br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Government issued credentials

## Indicio simplifies access to government services and streamlines permits and licensing&#x20;

Using verifiable credentials, Indicio is able to issue credentials to citizen mobile devices that allow them to cryptographically prove their identity for access to government services, as well as securely store government-issued permits and licenses.

## Government benefits

* Increase efficiency by providing a passwordless, one-tap verification to give citizens access to government services.
* Increase security with phishing-proof verifiable credentials: unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.&#x20;
* Fight fraud and reduce data breaches by removing reliance on centralized databases for sensitive information.
* Issue and verify tamper-proof citizen documentation, such as permits, licenses, and contracts, in seconds with one scan.
* Protect your systems and citizens from deepfakes with mutual authentication, establishing a two-way online verification process before sharing sensitive information.

## Citizen benefits

* Access government benefits faster and spend less time on document verification and more time addressing your needs.
* Remove the need to remember passwords or provide multiple documents for accessing government services.
* Reduce identity theft and impersonation attempts with a secure digital identification that cannot be copied by bad actors.
* Easily store all your permits and licenses in one place and eliminate the hassle of tracking down physical documents and paperwork.

<figure><img src="/files/8RLO65uVcfebN25Uve4v" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio Proven ®

Unlocking efficiency and savings across industries and sectors

<div align="left"><figure><img src="/files/NuLlbxPe34MrK79qwZOI" alt="" width="188"><figcaption></figcaption></figure></div>

<figure><img src="/files/wO5xnFwMOyOOKzOBXJNy" alt=""><figcaption></figcaption></figure>

## About Indicio Proven ®&#x20;

A complete end-to-end solution, Proven is designed to provide the widest possible range of options to build, deploy, scale, and manage verifiable credential ecosystems, and is interoperable and compatible with current and emerging global protocols and standards for decentralized identity, including the European Union’s new standards for digital identity (eIDAS) and digital wallets (EUDI).

It’s easy to implement and scale, from simple use cases to managing national and global identity verification, and unlike many digital credential solutions that claim to be decentralized, with Indicio technology, you are always in full control of your data.&#x20;

## Benefits

* Verifiable credentials can hold all kinds of valuable information in a tamper-proof way, as any attempt to alter that information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* Mutual authentication allows you to always able to verify who you are sharing data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.&#x20;
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is more secure — no need for third parties to store the data in centralized databases to manage authentication.&#x20;
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Protect biometric systems and data from AI deepfakes.

## Seamless, streamlined, and secure identity verification

* **Indicio Proven is the most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0.**\
  It gives you maximum speed and flexibility to build, launch, scale, and manage verifiable credential ecosystems.
* **It’s built for interoperability.**\
  Indicio Proven works with existing and emerging global standards, including EU eIDAS and EUDI digital wallets.
* **It’s fast to implement.**\
  Integrate Proven with your current systems and can be configured in days—not months.
* **It’s easy to scale.**\
  Go from a simple pilot to national or global identity verification without starting over.
* **Verifiable credentials are a breakthrough.**\
  Gartner calls them “magnitudes of improvement in terms of efficiency, cost and assurance” in its 2024 Market Report for decentralized identity.
* **Deploy your way.**\
  Use Indicio Proven on premises, in AWS, Azure, Google Cloud, Oracle, or with any provider you choose.

## What's included

**Issuer & Verifier Agents**\
The software needed to create, issue, and verify credentials.

**Mobile App & Mediator**\
The software to download, store, and use credentials on mobile devices.

**Verifiable Credential Schema**\
Flexible template for creating credentials.

**Verifiable Data Registry or Network**\
Make use of a robust and stable distributed ledger, professionally managed by Indicio, choose the provider or registry technology that works best for you, or have us build your own network.

**Technical support & training**\
Indicio Proven includes personalized onboarding, comprehensive documentation, and expert-led training to ensure your team is set up for success at every stage.

## [Book a demo ](https://indicio.tech/contact/)

Learn how easy it is to get started, use, and generate value using Indicio Proven!

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>

<br>


# Features

Indicio Proven is the world’s most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0.

<figure><img src="/files/9dpkthQZe2fwLlkYRrvh" alt=""><figcaption></figcaption></figure>

### **Indicio Proven** ® **Highlights**

* **Secure credential issuance and data verification**
  * Enterprises, Governments, and organizations of all sizes can use Indicio Proven to issue and verify tamper-proof credentials in a secure and privacy-preserving way.
* **Standards-driven interoperability**
  * Proven provides unmatched interoperability by supporting multiple standards, including AnonCreds, W3C Verifiable Credentials, DIDComm, and emerging standards like SD-JWT and OpenID for Verifiable Credentials (OID4VC).
* **Global standards**
  * Organizations can design credentials tailored to their needs, leveraging the specific strengths of various formats. Proven complies with global data protection standards including eIDAS, EUDI, and industry specific technology standards. Including W3C Verifiable Credentials, Open Badges 3.0 from 1EdTech, and IATA One ID and ICAO DTC for travel.
* **Customizable deployment**
  * Proven is designed for flexibility, offering both a SaaS platform model or allowing deployment via APIs in various environments, including on-premise, cloud-based, or hybrid setups.
* **Plug-and-play integration**
  * Indicio Proven works seamlessly with the Indicio Network and other decentralized identity ecosystems. It offers pre-built integrations for developers to easily add decentralized identity to their applications. With easy integration into your existing technologies, Indicio Proven can be configured and operational in days, not months.
* **Privacy by design**&#x20;
  * Indicio Proven ensures that data and identity information are shared exclusively between trusted Issuers, Holders, and Verifiers within your ecosystem. Unlike other solutions claiming to use verifiable credentials, Indicio never collects, holds, manages, or accesses your data - delivering true decentralization.
* **Secure credential management**
  * Indicio Proven enables full lifecycle management of credentials, including issuance, revocation, and expiration. Organizations can define policies for credential management, ensuring compliance with industry standards and internal requirements for credential authenticity and validity.
* **Customizable governance**
  * Users can configure and manage their own trust frameworks, including selecting roots of trust, defining credential schemas, and customizing credential verification logic. This flexibility supports a wide range of use cases, such as identity verification, secure access management, and compliance monitoring.
* **Multi-tenant support**
  * Indicio’s infrastructure is built for global scale and to handle high volumes of credential issuance and verification–fast. A single Indicio Proven instance can support multiple clients (tenants) in a single environment. Each organization can then securely manage its own decentralized identity (DID) configurations, verifiable credentials, and trust frameworks without interfering with other tenants, ensuring privacy and data isolation.
* **Customization and configuration**
  * Indicio Proven can be configured by each customer to match specific business needs, such as selecting roots of trust, defining credential schemas, and managing the lifecycle of digital identities and verifiable credentials. This flexibility enables various use cases, from KYC processes to digital access management.
* **APIs for external integration**
  * Easily integrate Proven into your existing systems with secure, standards-based APIs for credential issuance and verification.
* **UI for issuance and verification**
  * Issue and verify verifiable credentials through a simple, user-friendly interface—no technical setup required.
* **Customer chat using basic message**
  * Communicate directly with your customers through secure, in-app messaging powered by decentralized identity.
* **Award-Winning technology**&#x20;
  * Indicio Proven stands as the most advanced platform for decentralized identity powered by verifiable credentials and has been recognized by Gartner, KuppingerCole, and Constellation Research, among others, for our customer deployments

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Proven Feature Checklist

Indicio takes great pride to ensure that all areas of Proven are up to date with global standards. Here you can see what these standards are that our product includes.&#x20;

* [Proven Credential Formats](/product/indicio-proven-r/features/proven-feature-checklist/proven-credential-formats)
* [Proven Protocols](/product/indicio-proven-r/features/proven-feature-checklist/proven-communication-protocols-technology)
* [Proven Features](/product/indicio-proven-r/features/proven-feature-checklist/proven-features)
* [Proven Standards](/product/indicio-proven-r/features/proven-feature-checklist)
* [Proven Software](/product/indicio-proven-r/features/proven-feature-checklist/proven-software)
* [Proven Trust Establishment](/product/indicio-proven-r/features/proven-feature-checklist/proven-trust-establishment)


# Proven Credential Formats

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio is compliant with all of the following credential formats! </p>

<table data-header-hidden data-full-width="false"><thead><tr><th width="327.6953125" valign="middle"></th><th width="395.58203125"></th></tr></thead><tbody><tr><td valign="middle"><strong>Proven Credential Format</strong></td><td><strong>Details</strong></td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> SD-JWT VC</td><td>JWT-based verifiable credentials support selective disclosure.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> mdoc / mDL</td><td>Indicio is compliant with ISO/IEC 18013-5, which outlines a secure digital credential to represent a person’s mobile identity documents or driving license information on a smartphone or other digital device.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> AnonCreds</td><td>AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> W3C VCDM (JSON-LD)</td><td>A lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> W3C VC compliant</td><td>Indicio is compliant with the W3C standard for Verifiable Credentials.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Open Badges 3.0</td><td>The world's leading format for digital badges is often used to prove educational achievements, such as transcripts, diplomas, and certifications.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Digital Travel Credentials (ICAO DTC)</td><td>These are digital representations of travel documents, such as passports, that are designed to streamline and enhance the travel process.</td></tr><tr><td valign="middle"><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> IATA One ID</td><td><em>IATA's One ID initiative</em> aims to streamline passenger journey with advance sharing of information and a contactless process at the airport.</td></tr></tbody></table>

<h3 align="center">Don’t see the credential format you need? <a href="https://indicio.tech/contact/">Let’s chat.</a><br></h3>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>

<br>


# Proven Communication Protocols / Technology

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio offers the following communication protocols &#x26; technology</p>

<table data-header-hidden><thead><tr><th width="307.4765625">Protocols/Technology</th><th width="449.203125">Details</th></tr></thead><tbody><tr><td><strong>Protocols/Technology</strong></td><td><strong>Details</strong></td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> OpenID for Verifiable Credentials (OID4VC)</td><td>This empowers End-Users to directly present identity information to Verifiers.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> DIDComm V1.0 Protocols</td><td>DIDComm provides a profile for supporting the Wallet and Credential Interaction (WACI) Protocols for both Issuance and Presentation Exchange.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> BLE</td><td>Bluetooth Low Energy, a low energy networking technology, is used for communicating between decentralized identity agents.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> NFC</td><td>Near Field Communication is a short-range wireless technology that allows devices, like smartphones, to communicate with each other when they are in very close proximity.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> WiFi Aware</td><td>WiFi Aware, or Neighbor Awareness Networking, enables devices to securely discover, pair, and communicate with nearby devices to securely establish peer-to-peer (P2P) connections between Wi-Fi devices.</td></tr></tbody></table>

<h3 align="center">Ready to learn more? <a href="https://indicio.tech/contact/">Let’s chat.</a><br></h3>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Proven Features

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio Proven includes all these features! </p>

| **Proven Feature**                                                                                          | **Details**                                                                                                                                                                 |
| ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> API for external integration                | A set of rules and specifications that allow different software systems to interact and exchange data.                                                                      |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Proven Controller API                       | An API for the management of Verifiable Credentials.                                                                                                                        |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> UI for credential issuance and verification | Intuitive interface used to create and authenticate credentials.                                                                                                            |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Proven Controller UI                        | An intuitive user Interface used for managing Verifiable Credentials.                                                                                                       |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Governance Editor/Interpreter               | Simple interface used for rules implementation in a decentralized ecosystem.                                                                                                |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> DID resolution via Universal Resolver       | This resolves Decentralized Identifiers (DIDs) across many different DID methods.                                                                                           |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Indy Networks                               | A variety of networks used for hosting your solution, including Indicio MainNet, Indicio DemoNet, Indicio TestNet, Indicio TempNet, Sovrin Ledgers, CANdy, Lissi, Ethereum. |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Web-based (ledgerless)                      | Choose to use no ledger for your decentralized identity solution using DID:webvh.                                                                                           |
| <img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Customer chat using basic messages          | This is a chat function for users to connect through DIDComm.                                                                                                               |

<h3 align="center">Get started with Indicio Proven Today! <a href="https://indicio.tech/contact/">Let’s chat.</a></h3>

<br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>

<br>


# Proven Standards

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio is compliant with all of the following standards &#x26; legislation! </p>

<table data-header-hidden><thead><tr><th width="358"></th><th></th></tr></thead><tbody><tr><td><strong>Proven Legislation/Standard</strong></td><td><strong>Details</strong></td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> eIDAS 2.0</td><td>Indicio is compliant with the updated version of the original eIDAS (Electronic Identification, Authentication, and Trust Services) regulation.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> EUDI</td><td>Indicio complies with the regulations set out by the EU for digital identity wallets.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> EUDI ARF</td><td>Indicio is built to standards and specifications laid out by the EUDI Architecture and Reference Framework</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Aries Interop Profile (AIP) 1.0</td><td>A clearly defined set of versions of RFCs allows Aries agent builders to target their agent implementation when they wish it to be interoperable with other agents</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Aries Interop Profile (AIP) 2.0</td><td>It provides a clearly defined set of versions of RFCs for Aries agent builders to target their agent implementation when they wish it to be interoperable with other agents. It includes out-of-band for connection reuse as part of the protocol.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> DIF Credential Trust Establishment V1.0</td><td>A practical, interoperable building block  supports multiple different kinds of trust-decision Trust Establishment solutions.</td></tr></tbody></table>

<h3 align="center">Let's get started on your project today! <a href="https://indicio.tech/contact/">Let’s chat.</a><br></h3>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Proven Software

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio Proven offers all the following software options! </p>

<table data-header-hidden><thead><tr><th width="299"></th><th></th></tr></thead><tbody><tr><td><strong>Proven Software Offering</strong></td><td><strong>Details</strong></td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Aries Cloud Agent Python</td><td>An easy to use enterprise SSI agent used to build decentralized trust services using any language that supports sending or receiving HTTP requests.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Aries Askar</td><td>A secure (encrypted at rest) storage and a key management service suitable to use with Hyperledger Aries agents and other digital trust agents.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Holdr+ wallet</td><td>A digital wallet built on Hyperledger Aries.<br></td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Holdr Mobile SDK</td><td>Software created to build Verifiable Credential functionality into your existing applications.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Proven Mobile Verifier</td><td>Software used to validate Verifiable Credentials.</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> Proven Cloud-scale Mediator</td><td>Software used to deliver messages in a decentralized ecosystem.</td></tr></tbody></table>

<h3 align="center">Put Indico Proven to work in your project today! <a href="https://indicio.tech/contact/">Let’s chat.</a><br></h3>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Proven Trust Establishment

<p align="center"><img src="/files/18cwNkcm5U6dmd8r6a3Q" alt="" data-size="original"></p>

<p align="center">Indicio proven includes all of these trust establishment options! </p>

<table data-header-hidden><thead><tr><th width="244.828125"></th><th></th></tr></thead><tbody><tr><td><strong>Proven Trust Establishment</strong></td><td><strong>Details</strong></td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:sov</td><td>A DID method for interacting with ledgers similar to the Sovrin Network</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:indy</td><td>A DID method for interacting with Hypereldger Indy networks</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:key</td><td>A DID method for Static Cryptographic Keys</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:peer v. 1, 2, and 4</td><td>A DID method for most private relationships between people, organizations, and things</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:web (resolution only)</td><td>A DID method using a web domain's existing reputation</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> did:webvh</td><td>A version of did:web extended to include the Verifiable History of the DID</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> x.509 certificates</td><td>Certificates issued by Certificate Authorities for establishing trust and identity of software</td></tr><tr><td><img src="/files/Joe5M3RNr4MY6FBmfJlC" alt="" data-size="line"> OpenID Federation</td><td>Trust Anchors mediate trust for a federation of collaborating parties</td></tr></tbody></table>

<h3 align="center">Trust us to help you build your ideal solution! <a href="https://indicio.tech/contact/">Let’s chat.</a><br></h3>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio Proven® Global Interoperability

As the world continues to adapt the use of digital identity and credentials, Indicio takes great care to ensure we continue to remain on top of global interoptibility. Below is a current look at how Proven is global. This will continue to grow, expand, and include many more across the world.&#x20;

<figure><img src="/files/km8R8ujkusj35ByeoFto" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio Proven ® for Travel

<div align="left"><figure><img src="/files/g0bZzBBJHVjNV45KLZXl" alt="" width="375"><figcaption></figcaption></figure></div>

A complete verifiable credential solution for identity and data

## **Seamless, Streamlined, and Secure Identity Verification**

Indicio Proven is the world’s most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0.&#x20;

It is designed to provide the widest possible range of options to build, deploy, scale, and manage verifiable credential ecosystems.

It is built to be interoperable and compatible with current and emerging global protocols and standards for decentralized identity. This includes the European Union’s new standards for digital identity (eIDAS) and digital wallets (EUDI).

It is easy to implement — a platformless solution that can work with your existing systems — and it is configurable in days rather than months.

It is easy to scale from simple use cases to managing national and global identity verification.

Verifiable credentials are a powerful new way to authenticate identity and data. As Gartner Research notes in its 2024 Market Report for Decentralized Identity, they represent “magnitudes of improvement in terms of efficiency, cost and assurance.”

Indicio Proven allows you to build in a way that works best for you, with flexible deployment options; including on premises, in Amazon Web Services, Azure, Google Marketplace, Oracle, or a provider of your choice.

## What's Included

**Issuer & Verifier Agents**\
The software needed to create, issue, and verify credentials.

**Mobile App & Mediator**\
The software to download, store, and use credentials on mobile devices.

**Verifiable Credential Schema**\
Flexible template for creating credentials.

**Distributed Ledger Network**\
Make use of a robust and stable distributed ledger, professionally managed by Indicio, choose the provider that works best for you, or have us build your own distributed ledger network.

**Technical Support & Training**

Experienced staff and engineers available to answer any questions through a variety of contact methods.

## Benefits

Seamless authentication with government-grade digital identity enables digital transformation across the travel ribbon to remove the following: friction, error from manual data entry, and delay from manual security touchpoints. This can be done without airlines and airports having to manage their passengers’ personal data.

With an Indicio Digital Passport, travelers can share their biographic and biometric information before arrival, enabling pre-authorized travel and seamless border crossing.

Because passengers can hold and share authenticated biometric and biographic data from a verifiable digital passport, airports can streamline check-in, baggage management, access to lounges, and boarding. This means reduced congestion and anxiety for travelers and increased airport capacity without requiring additional resources.

Airlines can know that every traveler has been precleared to board international flights, reducing the risk of fines for inadmissible travelers. Airlines can always and instantly know their customers when they log in to airline websites and use loyalty programs — and customers can be sure they are logging into their airlines.

## Unlocking efficiency, savings across industries and sectors

Indicio has years of experience developing and implementing verifiable credential solutions for global enterprises and governments. Here are just a few examples.

<figure><img src="/files/u1MESND0lZjan1XBTpmk" alt=""><figcaption></figcaption></figure>

## Travel, Hospitality, & Tourism

Indicio is the leading developer of award-winning decentralized identity solutions for the air transport sector, and Indicio Proven® provides multiple ways to deploy verifiable credentials for seamless, secure, identity authentication with privacy-preserving features.&#x20;

For complex information flows where security is critical, Indicio developed and deployed the world’s first Digital Travel Credential based on the International Civil Aviation Organization (ICAO) standards.&#x20;

This “government-grade” digital identity enables passengers to convert their passports into authenticated digital credentials that can be used for pre-authorization for travel and seamless border crossing. Our DTC technology is being implemented by airlines and governments around the world, and is being extended to include immigration visas, airport lounge access, hotel check-in, and customer loyalty programs.

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUe0Bi8TGDf5sBhPWCh_0a3DvZD6BEnpz1Wou1NiaWoYDQ-kuI95AGrs_JX20ORsBj9ntBkHKAnFKtQuQkpQ-FR8hGh5nTxSV0thZt5RJdtp9W5mktFoGYeQT54vo2X8CsptXhjA=s2048?key=ACUHcvIy51ILmsFxvto0zw" alt=""><figcaption></figcaption></figure>

## Customers

Our customers are using Indicio Proven to create simple solutions to complex information problems, replacing manual processes, reducing error and friction, and developing markets through portable trust. Here are a few examples.

### Aruba

\
With the innovation provided though Indicio Proven, Aruba was able to streamline the border control process, resulting in a transformation to international travel. It heralds the arrival of seamless digital travel, where travelers get to hold their data on their mobile devices and present it for instant cryptographic verification. This streamlines the journey from booking to arrival; reduces waiting times, especially at border crossings; provides data privacy for the traveler; and provides better security for airlines, airports, and governments.

### SITA

\
With the digital travel credential (DTC), Indicio and SITA have applied decentralized identity technology to enable pre-authorized travel and seamless border crossing using verifiable credentials. The process is simple, fast, secure, and reduces the often-stressful experience of travel. As a result, it will drive the adoption of the technology in air travel and show the world how verifiable identity and data can be easily applied to everything. SITA and Indicio are continuing to work together to expand a<br>

<br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>

<br>


# Indicio Proven Auth

Quickly configure Single Sign-On (SSO) to use a verifiable credential for login

## Easier, faster, more secure authentication

Indicio Proven Auth allows you to quickly configure single sign-on (SSO) with policy-driven authorization so that your customers or end users can login with portable digital identities instead of usernames and passwords. It allows you to easily implement policies that define access rules dynamically. No more one-size-fits-all permissions. No more access silos.

With Proven Auth, you can use dynamic access rules that respond instantly when a verifiable credential is presented. Instead of granting broad permissions, you can enforce fine-grained policies that determine exactly what each person should access based on their role, credentials, and other verified attributes.

1. **Issue verifiable credentials** using Indico Proven to employees, customers, partners, or have your contractors issue them to their employees that contains information that would affect their access. This could include things like their role, location, years of experience, certifications or other relevant information.
2. **Integrate Proven Auth with policy engines** like Amazon Verified Permissions or Abacus and write policies based on your business’ needs.
3. **Grant access based on their verified attributes** so instead of using static, pre-configured access roles, the world of tools and systems people can access is set up for them in minutes, without needing to log into anything.

When logging into an application, Proven Auth checks to see if the credential issuer is valid and provides the destination system with the necessary data about who you are and what you should have access to. Proven Auth doesn’t need to have seen your credential before to do this.

### Features

* Comes with Keycloak for identity access management but is easily configurable to use other software.
* Combine popular protocols (e.g. OIDC, SAML) with widely-used policy engines (such as Amazon Verifiable Permissions or Abacus) for role- or user-based authorization decisions based on the attributes of a verifiable credential.
* Unlike conventional identity provision, Proven Auth enables systems to allow access based on credentials they have never seen before provided they trust the source (e.g., government-issued ID).&#x20;
* Credentials can be quickly configured to handle complex information flows, making it easier to implement least-privilege access for zero trust.
* Superior to Passkeys because 1) they do not need to be enrolled; 2) they are able to hold contextually useful information that can be shared by consent, thereby simplifying compliance.

### Benefits

* Replaces weak passwords and weak second-factor authentication for better security.
* No tracking by centralized third-party identity providers.
* No worries if a federated identity provider goes dark.
* Reduces the steps for authentication in a zero-trust architecture model.
* Program with governance rules for least-privilege access.
* More powerful than passkeys and don’t require enrollment.
* Simpler, more secure user experience.
* Get ahead of the portable digital identity transformation in the European Union (eIDAS, EUDI), the travel sector, and in mobile driver’s licenses.
* Get all these features faster and cheaper than conventional identity access management solutions.

### &#x20;Proven Auth Workflow

<figure><img src="/files/CJW77IHctfkj8jW7Cw6o" alt=""><figcaption></figcaption></figure>

1. The issuer assembles all the necessary identity information to prove who a user is.
2. The information is stored inside a verifiable credential and issued to the end user’s mobile device.
3. Personally identifiable information is deleted from the issuer’s systems, removing liability and lessening risk of breach
4. The credential is stored securely in a digital wallet on the user’s phone, and can be accessed and shared either partially or in full to prove identity.
5. The user can now share this information to securely login to a variety of services such as gmail, slack, teams, and more with the quick scan of a QR code, instead of remembering passwords or relying on third party identity providers who can experience outages or issues.

### &#x20;How to use Proven Auth to configure Single Sign-On (SSO) to use a verifiable credential

<figure><img src="/files/O8trSUUajWarzWnHS1S2" alt=""><figcaption></figcaption></figure>

### Why use a verifiable credential for SSO?

<br>

<figure><img src="/files/uEDZW8oPcQYlOaXRP4cm" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Deployment and Integration

Indicio Proven can be deployed on premise, in cloud, or as SaaS. Server APIs to control the agent to connect, issue credentials, verify credentials, or securely message.

Indicio Proven eliminates the need for direct integrations or third-party data management, streamlining data sharing, and ensuring compliance with data protection regulations. Credential schemas are fully configurable, supporting the issuance of a wide range of data types. The software can be deployed on-premises, in a private cloud, or with any major cloud provider.

### Hosting options

Proven is offered as either a fully-hosted solution for quick setup, eliminating the need for complex configuration and maintenance or can be self-hosted.

* **Proven Enterprise (SaaS):** Indicio Proven Enterprise offers efficient integration of scalable and secure decentralized identity management into existing systems and workflows. It allows organizations to easily issue, verify, and manage verifiable credentials while maintaining privacy and compliance with global standards. With multi-tenant support and flexible configuration options, it provides a comprehensive platform for businesses to adopt and extend decentralized identity solutions.
* **Proven Core (API):** Indicio Proven Core delivers organizations the ability to self-host and manage decentralized identity solutions on their own infrastructure. It offers a set of robust APIs that allow businesses to issue, verify, and manage verifiable credentials while maintaining control over security, data, and compliance. This version is ideal for organizations that require customization, on-premise deployment, or integration with existing internal systems without relying on a cloud-based service.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Request Access to Proven API Documentation

Please complete the form below and within 24 hours you will be provided a unique link to gain access to Indicio's  API documentation and guided tutorials.&#x20;

<figure><img src="/files/B7BHAJtsl6tRx6HXmzFF" alt=""><figcaption></figcaption></figure>

<h3 align="center"><a href="https://4frvz.share.hsforms.com/2w6Wtg0j3S5KgLnxihT3SDg">Please complete this form now! </a></h3>


# Mobile Solutions

**Remove reliance on centralized databases**

The ability to hold personal identity or other data in this decentralized way removes the need for centralized databases of customer personal data or login information, reducing liability and the risk of data breaches.&#x20;

## Features

* Share data and identity with trusted connections.
* Collect credentials to store locally and share by consent.
* Secure, peer-to-peer messaging.
* Intuitive interface built for accessibility and convenience.
* Customizable branding and functionality (paid upgrades).

### Learn more:&#x20;

* [Indicio Holdr+](/product/mobile-solutions/holdr+/indicio-holdr+-r) - our ready to download digital wallet (in Apple and Android app stores).
* [Proven Mobile SDK](/product/mobile-solutions/mobile-sdk/indicio-proven-r-mobile-sdk) - a ready-to-use SDK to power your own wallet!\ <br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Mobile SDK


# Indicio Proven® Mobile SDK

Add digital wallet functionality for verifiable credentials directly into your existing applications

<img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUdSI9FGlaHuDKzQOqtZyw28Cd03z_conDs7q_XeZx23Oe2TUI_G0SpHvXzPEURq8QrtF9MFrH74Rv90NW7psG9UOoMhBgZ-ZC1ql6cEL0DXUFI_8-ZVMJcVx_CiMtXd_hBp0wxNvA=s2048?key=y13mXS11SPl02HlUyOsvshIu" alt="" data-size="original">

[**Proven Mobile SDK**](https://indicio.tech/mobile-software-development-kit/)**:** All the code you need in one place to implement decentralized identity&#x20;

The Indicio Proven Mobile SDK removes a critical blocker to deploying verifiable credential solutions  — the lack of a single source for all the code needed to build customized apps with interoperable digital wallets.&#x20;

Whether Android or iOS, the Proven Mobile SDK enables your developers to easily add wallet and verifiable credential functionality to your applications without having to learn new programming languages or practices or having to develop complicated, multi-app workflows.

### Features

* **Multiple libraries:**&#x20;
  * The SDK contains packages for Swift, Kotlin, and React Native — all compiled from a single code base, making it easy to develop apps for both iOS and Android.
* **Support for multiple credential types, protocols, governance:**&#x20;
  * AnonCreds, SD-JWTs, and JWT-VCs ,JSON-LD . OID4VC; DEGov (Decentralized Ecosystem Governance, based on DIF Credential Trust Establishment).
* **Secure communications:** &#x20;
  * Enable secure communication through DIDComm protocols in your application, including both wallet to wallet and enterprise to wallet.
* **Incorporate liveness checks into your application**
  * Indicio’s “bring your own biometrics” is a transformational way to manage biometric privacy and security, enabling a person to combine a liveness check with an authenticated biometric from a credential. Can be included in SDK with a license.

    <br>

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfHkc55Pbb6Z4g8ZvTf6eUkrVRMX_qVhe_h0kul7oSBDxvbFWhPa64sKM8anipBZJinjmtLdLsOz0HlG2-hTYvs0jxA8sVNFZPVwvFa3ap9MVDkkmNmPPz4oVCnTgI9PvaCpi5e4g=s2048?key=y13mXS11SPl02HlUyOsvshIu" alt="" width="188"><figcaption><p>Combining biographic data<br>with biometrics in a verifiable<br>increases efficiency and<br>security for all parties.</p></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Holdr+


# Indicio Holdr+ ®

Integrate digital identity wallet functionality into existing applications or download our existing wallet app today.

## Indicio’s powerful digital wallet — Holdr+ &#x20;

### An easy-to-use, secure digital identity wallet for verifiable credentials

<figure><img src="/files/KfIyzDyLyXu9IrYMSjFx" alt=""><figcaption></figcaption></figure>

### **Holdr+** ®&#x20;

With Holdr+, Indicio has your digital wallet needs covered.&#x20;

* Holdr+ allows someone using a mobile device to receive, hold, and present verifiable credentials and to create and establish secure, mutually authenticated communication between parties.
  * Supports governance file establishing who trusted issuers of credentials are.
  * Supports a variety of credential types and protocols including OID4VCI, OID4VP, AnonCreds, SD-JWTs, JSON-LD, and Open Badges 3.0.
  * Compliant with W3C Verifiable Credential Standards and the only wallet compatible with the DIF Credential Trust Establishment specification.&#x20;
* Indicio’s fully deployed mobile digital wallet application is available to download in the app stores today!&#x20;
* **Download on** [**Apple**](https://apps.apple.com/us/app/holdr/id1620628623) **or** [**Android**](https://play.google.com/store/apps/details?id=tech.indicio.holdrplus)**.**

**A “must have” capability**&#x20;

Gartner Research describes a digital wallet as a “must-have” capability in its 2024 Market Report on Decentralized Identity, predicting that “by 2026, at least 500 million smartphone users will be regularly making verifiable claims using a digital identity wallet built on distributed ledger technology.

**More than just a digital wallet**

The plus in Holdr+ means you’ve got more than just a digital wallet: you’ve got a way to turn a mobile devices into a secure data platform that’s able to deploy the functionality of an API while delivering much better security.&#x20;

The combination of secure messaging and verifiable credentials turns your customer into their own digital platform. With Holdr+, your customer becomes their own digital platform.&#x20;

* Your customer controls their data.&#x20;
* They are able to communicate securely with your business and partner organizations.
* Personalization by consent enables a new level of customer experience through instant data sharing.
* No direct integrations to share data or verify identity between different systems.

<figure><img src="/files/hy3f37aRUfkAhiPl6gE0" alt=""><figcaption></figcaption></figure>

**Secure authentication**

With Holdr+, you can use DIDComm for secure, instant messaging, where each party is able to cryptographically authenticate the other before sharing critical data.&#x20;

**Bring your own biometrics**

With Holdr+, you can combine a biometric template with a liveness check when identity assurance and security are critical. This is also a simple and highly effective way to mitigate the threat of AI-generated deepfakes.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Holdr + EUDI

## Building to EUDI specifications with Proven

### Streamline your digital identity systems and build to new European standards

<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUeHgk3-5j9P8p4XMoZ-VMTahn2bsqVh6iNHP59zeV43GAUX7_S5QqXYsV9AG0rb06W7synmf5CmkoK2dybJ1sLi6AIOL7F_-djRDhFMdzIhIYZiZyS_cUxwMQB5X_1AsucRZu2H=s2048?key=OTtCuGbh3taFeS99EWKiRomr" alt=""><figcaption></figcaption></figure>

### Indicio makes EUDI work for you.

Europe’s new frameworks for trusted digital identities, eIDAS 2.0 and the European Digital Identity Wallet (EUDI), are laying the groundwork for faster, more privacy-preserving digital identity verification. Indicio Proven simplifies and accelerates the implementation of your digital identity solutions to meet these new specifications (most implementations within 12-48 hours).

### The goals set for eIDAS and EUDI by the EU

* Create secure, cross-border digital identities that meet the demands of both private and public sectors.
* Eliminate unnecessary data sharing and provide Europeans with full control over their data while accessing online services.
* Create the technical foundations and a clear legal framework for people, companies, and public administrations to access services safely and conduct transactions online.
* Establish mutual recognition for electronic IDs issued by European countries.
* Develop a technology-neutral framework that does not favor any particular technical solution for electronic ID implementation.
* Create a universal, trustworthy, and secure European digital identity wallet standard.

### How Indicio can help with enterprise-ready solutions for easy deployment

* Indicio offers a complete suite of products built to the new European specifications, including a digital wallet and system for issuing, verifying, and managing digital identity credentials, all from a simple interface.
* You will be able to use these credentials to prove identity across your organization with the tap of a screen; no more passwords, multi-factor authentication, or reliance on third-party providers and databases.
* Users store their credentials locally and maintain complete control over their personal information.
* Indicio’s pre-built solutions and simple integrations reduce your team’s development costs and time investment.

### Thinking global

* Europe is just the beginning – Indicio’s credentials are compatible with systems both inside and outside of Europe, preparing you for the next generation of digital trust that is usable across the globe.
* Indicio’s team monitors global standards and regulations to ensure that your solution maintains maximum interoperability.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Request Access to Holdr+ Guided Tutorials

Please complete the form below and within 24 hours you will be provided a unique link to gain access to Indicio's Guided Tutorials.&#x20;

<figure><img src="/files/B7BHAJtsl6tRx6HXmzFF" alt=""><figcaption></figcaption></figure>

<h3 align="center"><a href="https://4frvz.share.hsforms.com/2w6Wtg0j3S5KgLnxihT3SDg">Please complete this form now! </a></h3>


# Indicio Academy

Accelerate your journey with verifiable credentials and decentralized identity through expert-led training and on-demand resources.

The Indicio Academy is a structured learning hub that equips teams with the knowledge to confidently use and integrate Indicio Proven into real-world applications. It combines expert instruction with practical exercises to ensure both technical and non-technical users can deploy verifiable credential solutions effectively.

Whether you're new to decentralized identity or ready to scale your credential-based solutions, the Indicio Academy provides the knowledge, tools, and hands-on experience you need to succeed with Indicio Proven.

### **What you'll learn**

Our curriculum is designed to meet you where you are—from first-time implementers to experienced developers.

Modules include:

* **Foundations of Decentralized Identity**\
  Understand key concepts, standards, and ecosystem roles.
* **Using Indicio Proven**\
  Learn how to issue, verify, and manage verifiable credentials through Proven’s intuitive UI and APIs.
* **Integration and Deployment**\
  Explore best practices for integrating Proven into your business processes and digital systems.
* **Advanced Topics**\
  Dive into technical topics like DIDComm, credential schemas, trust registries, and interoperability.

### **Who will benefit from these courses?**

* IT Leaders and Solution Architects.
* Product Managers and Innovation Teams.
* Developers and Integrators.
* Government and Enterprise Stakeholders.

### **Get Started Today**

Ready to learn more?\
**Contact your account manager** or **email us** to enroll.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Infrastructure

Step-by-step guides and tutorials to help you launch, integrate, and scale with Indicio Proven

Indicio Proven is built to make decentralized identity simple, secure, and practical. Whether you're a business leader, developer, or solution architect, our getting started resources give you the tools to move fast and build with confidence.

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/ztUuRfB96QXapUvSJ5GQ" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/ztUuRfB96QXapUvSJ5GQ)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/QAnXIDi46TTtnNWi3uTk" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/QAnXIDi46TTtnNWi3uTk)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/k83unURagajrvrxtxe6b" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/k83unURagajrvrxtxe6b)
{% endcontent-ref %}


# AWS Install


# AWS Marketplace

## Installing and Configuring Proven

This document will guide you through the steps to deploy and configure Proven in Google Cloud using Indicio Proven from the GC Marketplace. The first part of this document is intended to be a “quick start” to get you up and running quickly, then you can look at the indicated appendices for more details if needed.

## Creating the VM instance (Defaults will work for all items not included in these instructions)

1. Navigate to the Google Cloud Console, <https://console.cloud.google.com/>
2. Select the project that you want the Proven instance to reside in.
3. In the Navigation Menu (top left), go to **Compute Engine** > **VM Instances**
   1. If it’s a new project, click “Enable”
4. Click **CREATE INSTANCE**
   1. From the left menu select “**Marketplace**”.
   2. In the “**Search Marketplace**” field type “**Proven**” and hit enter.
   3. Select “**Indicio Proven**”.
   4. Click **GET STARTED** to configure your Proven VM as a trial, or click **LAUNCH** if you have already done the trial.
      1. If a trial, agree to the agreements then click **DEPLOY.**
      2. For new projects, click “Enable” to enable the required APIs.
5. Change the **Deployment nam**e if desired. This will be the name of your VM instance.
6. Select and record your **Zone** choice for later use.
7. For **Machine type** choose a machine with at least 2 vCPU’s and 4G memory. For example, these defaults should be adequate:
   1. Set **Series** to E2
   2. Set **Machine type** to e2-medium
8. Under **Boot disk** it is recommended to select a disk at least **50GB** in size. (default)
9. You can set a static IP address later if desired. It is not available for change at this phase unless you have already pre-configured a static IP for use here. (This can be accomplished by creating a static external IP in your default VPC in a separate tab.)
10. Scroll to the bottom, check the box to accept the terms of service, then click **DEPLOY**.
11. After deployment is complete:
    1. Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
    2. In the right panel - **Click on the instance name** to bring up details about the Proven instance you just deployed
    3. Click **EDIT**
    4. Scroll down to **Networking** and under **Firewalls** check the boxes that will allow HTTP and HTTPS traffic.
    5. Click **SAVE**
    6. Click **VM instances** (in the left menu)
    7. Record the **External IP** address of your Proven instance for later use.

## Configure DNS (see appendix A for an example DNS setup option)

1. Add a DNS entry for Proven.

## Configure the VM

1. Navigate back to the Google Cloud console
2. SSH into the VM 1. Select Compute engine > VM instances Then for \[your-proven-instance] click **SSH**
3. Enter these commands in your instance to make it so that the “proven.service” starts up automatically after every server reboot.

   ```
    cd /opt/indicio/proven-release-docker
    sudo systemctl enable proven
   ```
4. Run this command for Proven.

   ```
    sudo cp staging.env .env
   ```
5. Run the command `ip a` and record the private ip address of your primary network interface (ens4). This local IP address will be used in the next step.
6. Edit the .env file to fit your environment. -> `sudo vim .env`\
   Shown below are the minimal fields needing configured, their default values, and short descriptions. The remaining fields are described in Appendix B.

&#x20;   PROVEN\_ISSUER\_SERVER\_NAME=proven.dev.indiciotech.io         Use your DNS entry or the IP address for the issuer. Do not include “http\://” or a trailing slash

&#x20;   PROVEN\_ISSUER\_SEED=         Must be 32 alphanumeric characters. Has to have “--seed “ at the start. If you do not have a seed, you may leave this blank if this is a testing environment and if blank make sure to perform step 7. For a production environment, see Appendix D.

&#x20;   TAILS\_URL=<http://10.128.15.205:6543>         Replace the IP address on this line with your local IP address. Leave the port as 6543.

&#x20;   NODE\_ENV=production

&#x20;   PROVEN\_ISSUER\_API\_DB\_PASSWORD=provenapi         Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_AGENT\_DB\_PASSWORD=provenagent         Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_PROXY\_DB\_PASSWORD=provenagent         Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_AGENT\_LABEL=Proven         This is what you want the issuer name to show up as on other agents’ connection list. Change this so that agents can tell the difference between Proven issuers.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b         For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters. Encryption key.

&#x20;   PROVEN\_ADMIN\_PASSWORD=         Must be added and must be 15 characters long.

&#x20;   PROVEN\_ISSUER\_WEB\_ROOT=<https://proven.dev.indiciotech.io>         If you have a DNS name, change localhost to the issuer DNS name with https\://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.

&#x20;   PROVEN\_ISSUER\_JWT\_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq         For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_SESSION\_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5         For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=54234625127cb22694ff0e27cc14b685         For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

7. For an example of a configured .env file, please see Appendix B.
8. Run the following command:
   1. sudo systemctl start proven
   2. Start a new SSH window if you want to monitor the progress of the starting of Proven.
      1. sudo systemctl status proven
      2. On error, return to the original ssh window, wait for the process to stop, then try again.
9. INFORMATIONAL NOTES: “proven.service” is a linux service file that makes it easy to start and stop your proven instance. It usually takes a minute or two for Proven to be ready for use. The following are some tips and FUTURE commands that you can run if you need to manage the proven service,
   1. IMPORTANT: Do NOT stop the service in the middle of its initial starting time. You have a chance of interrupting the install process and it will corrupt files that will need to be removed before restarting.
   2. **For later use** to stop the proven service: `sudo systemctl stop proven`
   3. **For later use** to restart the proven service: `sudo systemctl stop proven` `sudo systemctl start proven`

## Accessing Proven

You should now be able to navigate to your Proven issuer in a web browser, using its DNS Name or ip address.

## (OPTIONAL) In this version of Proven, only the “User” credential is included. If you would like to add more credentials, follow the steps in Appendix C now.

## Creating and Anchoring your Issuer DID

1. If you left the ISSUER seed variable blank during step 4d, this step is required
2. Run the following commands from the google cloud SSH window:
   1. **sudo docker-compose -f docker-compose.live.yml exec proven-issuer-api node firstimesetup.js**
   2. Agree to the Transaction Author Agreement
   3. To anchor the new DID which is now displayed -> open <https://selfserve.indiciotech.io>
   4. Select the Indicio DemoNet option from the Network dropdown box. DemoNet is the default used in Proven, but please select TestNet if you changed the .env file to that one. You will need to use a different tool if your identity network is not an Indicio network.
   5. Copy the new DID and Verkey displayed on the Proven window, to the DID and Verkey fields of the Selfserve form.
   6. Click Submit
   7. Return to the Proven SSH window and enter ‘y’ to indicate having anchored the Endorser DID.
   8. Wait while the Credential definitions are created for you.
   9. When you see **Completed**, then press enter to continue.
3. Your Proven instance is now ready to go!
4. To try out Proven with a user credential do the following:
   1. Install the latest Holdr+ app on your mobile device.
   2. Navigate to your Proven IP address or DNS url.
   3. Using your mobile Holdr+ app, scan the QR code displayed.
      1. This creates a connection between your mobile device and the Proven Issuer
      2. Troubleshooting Tip: If you see "Loading Please wait" for a long time at this point, try refreshing the browser page. If that doesn’t fix the problem then you might have an issue with your DNS setup that is causing the problem.
   4. Change the IP address in your browser by adding “/admin” to the end of it.
   5. Login using the following credentials:
      1. Username: admin
      2. Password:
   6. You should now see the Issuer admin interface.
   7. Click on CONTACTS in the left menu
   8. Click on the most recent contact.
   9. Under choose credential, select “user”
      1. Hint: if the “user” option is not in the list, refresh the page and try again
   10. Fill in the fields
   11. Click “Send”
   12. You should now see a notification of a new credential on your mobile device (go to the home screen to see notifications on Holdr+)
   13. Click “view” to view the credential offer.
   14. Scroll to the bottom of the Credential offer and click “Accept”
   15. After the credential is added to your wallet, click ‘Done’.
   16. You now have Proven Issuer working!

## Appendix A - DNS Setup Example

To setup DNS for Proven on Google’s Cloud DNS, (by creating a new subdomain of your existing domain) do the following:

1. Go to GCP’s **Cloud DNS** section in **Network services** (Navigation Menu > Networking > Network Services > Cloud DNS)
2. Click **Create Zone** if a new Zone is desired. Otherwise, if a zone is already created, click on the zone name then skip to step 3.
   1. Give the zone a name. This name is just how it will appear in the list and need not necessarily match the new subdomain.
   2. For **DNS name,** enter a new subdomain. (In the example configuration below, using the domain dev.indiciotech.io means we want to create a new **dev** subdomain of the existing indiciotech.io domain)
   3. Click **Create**
   4. Here’s an example configuration:
   5.
   6. To “activate” this new subdomain in GC, you need to register the subdomain in your existing domain (i.e. at your registrar).
      1. Click the name of the new zone you just created.
      2. Click on **REGISTRAR SETUP** (upper right of the screen) to find the items needing added to the new NS record, then add the domain’s DNS Name Server entries to your registrar.
3. Click **Add Standard**
   1. Create a DNS Name for proven and record it for later use (e.g. proven.dev.indiciotech.io)
   2. Defaults are okay
   3. Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
   4. Click “Create”

## Appendix B - Environment file variable descriptions plus an example file.

1. Full list of .env file variable descriptions

PROVEN\_ISSUER\_SSL\_DOMAIN\_PATH=

Path to Issuer SSL certificate. If not defined, creates a self-signed cert. If using certbot, leave blank before running certbot.

PROVEN\_ISSUER\_SERVER\_NAME=proven.dev.indiciotech.io

Use your DNS entry for the issuer in place of “localhost.” Do not include “http\://” or a trailing slash

PROVEN\_ISSUER\_HTTPS\_PORT=443

The port that the issuer uses for https connections.

PROVEN\_ISSUER\_HTTP\_PORT=80

The port that the issuer uses for http connections.

GENESIS\_URL=<https://raw.githubusercontent.com/Indicio-tech/indicio-network/main>

/genesis\_files/pool\_transactions\_testnet\_genesis

The URL to the Genesis pool file. Must be a URL. Do not include a trailing slash. The default connects to the testnet, make sure to adjust this for the network you are connecting to.

PROVEN\_ISSUER\_SEED=

Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Typically only used in Live environments.

TEST\_SEED=

Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Not necessary.

TAILS\_URL=<http://10.128.15.205:6543>

Replace the IP address with your local IP address on this line.

DISABLE\_SSL\_CHECK=true

NODE\_ENV=development

Possible values: production, development

GOVERNANCE\_PATH=<http://localhost:3100/api/governance-framework>

Where governance details are downloaded from. Can use DNS name, but typically left as localhost.

PROVEN\_ISSUER\_API\_DB\_HOST=db

Local database

PROVEN\_ISSUER\_API\_DB=provenapi

Local database

PROVEN\_ISSUER\_API\_DB\_USERNAME=provenapi

Local database

PROVEN\_ISSUER\_API\_DB\_PASSWORD=provenapi

Local database

PROVEN\_ISSUER\_AGENT\_DB=provenagent

Local database

PROVEN\_ISSUER\_AGENT\_DB\_HOST=db

Local database

PROVEN\_ISSUER\_AGENT\_DB\_USERNAME=provenagent

Local database

PROVEN\_ISSUER\_AGENT\_DB\_PASSWORD=provenagent

Local database

PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_USERNAME=development

Local database

PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_PASSWORD=development

Local database

PROVEN\_ISSUER\_AGENT\_LABEL=Proven

This is what you want the issuer name to show up as on other agents’ connection list.

PROVEN\_ISSUER\_ENC\_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b

Encryption key. Must be 32 alphanumeric characters.

PROVEN\_ISSUER\_PROXY\_DB=postgres\://provenproxy:provenproxy\@db:5432/provenproxy

PROVEN\_ISSUER\_WEB\_ROOT=<https://issuer.dev.indiciotech.io>

If you have a DNS name, change localhost to the issuer DNS name with https\://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.

PROVEN\_ISSUER\_JWT\_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq

Must be 32 alphanumeric characters.

PROVEN\_ISSUER\_SESSION\_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5

Must be 32 alphanumeric characters.

PROVEN\_ISSUER\_ENC\_KEY=54234625127cb22694ff0e27cc14b685

Must be 32 alphanumeric characters.

ISSUER\_RECAPTCHA\_SITEKEY=

Paste in your saved recaptcha site key that you created in step 3

ISSUER\_RECAPTCHA\_SECRETKEY=

Paste in your saved recaptcha secret key that you created in step 3

SCHEMA\_USER=Gj39gdivhMneKBaamMsX7P:2:User:1.0

**Here is an example of a configured .env:**

PROVEN\_ISSUER\_SSL\_DOMAIN\_PATH=

PROVEN\_ISSUER\_SERVER\_NAME=issuer-proven-test.dev.indiciotech.io

PROVEN\_ISSUER\_HTTPS\_PORT=443

PROVEN\_ISSUER\_HTTP\_PORT=80

PROVEN\_SESSION\_MAXAGE=86400000

WDS\_SOCKET\_PORT=0

WDS\_SOCKET\_HOST=0.0.0.0

WDS\_SOCKET\_PATH=sockjs-node

GENESIS\_URL=<https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_demonet_genesis>

PROVEN\_ISSUER\_SEED=

TEST\_SEED=

TAILS\_URL=<http://10.128.15.205:6543>

DISABLE\_SSL\_CHECK=true

NODE\_ENV=development

GOVERNANCE\_PATH=<http://localhost:3100/api/governance-framework>

PROVEN\_ISSUER\_API\_DB\_HOST=db

PROVEN\_ISSUER\_API\_DB=provenapi

PROVEN\_ISSUER\_API\_DB\_USERNAME=provenapi

PROVEN\_ISSUER\_API\_DB\_PASSWORD=provenapi

PROVEN\_ISSUER\_AGENT\_DB=provenagent

PROVEN\_ISSUER\_AGENT\_DB\_HOST=db

PROVEN\_ISSUER\_AGENT\_DB\_USERNAME=provenagent

PROVEN\_ISSUER\_AGENT\_DB\_PASSWORD=provenagent

PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_USERNAME=development

PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_PASSWORD=development

PROVEN\_ISSUER\_AGENT\_LABEL=Proven

PROVEN\_ISSUER\_ENC\_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b

PROVEN\_ISSUER\_PROXY\_DB=postgres\://provenproxy:provenproxy\@db:5432/provenproxy

PROVEN\_ISSUER\_WEB\_ROOT=<https://issuer-proven-test.dev.indiciotech.io>

PROVEN\_ISSUER\_JWT\_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq

PROVEN\_ISSUER\_SESSION\_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5

PROVEN\_ISSUER\_ENC\_KEY=54234625127cb22694ff0e27cc14b685

ISSUER\_RECAPTCHA\_SITEKEY=6LcokwUmAAAAAOg8mC4bXpRObIMVpB6LsFvzty3e

ISSUER\_RECAPTCHA\_SECRETKEY=6LcokwUmAAAAAIcuLhLZ\_Vgd\_6TUhOj0E9QcBAXS

SCHEMA\_USER=Gj39gdivhMneKBaamMsX7P:2:User:1.0

## Appendix C - Add a new credential type

Proven ships with just a User credential by default. The following details the instructions for adding a new credential type to the list of credentials managed by your instance of Proven. These instructions just include the method needed for altering the Proven configuration to include an existing schema and do not include the instructions for building and adding a schema to an identity network. Please contact <support@indicio.tech> for more information.

These instructions are an example of how to add an employment schema to your instance of Proven.

1. Find the Schema ID of the credential you would like to add to Proven.
   1. For this example, we use the employment schema **4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0** which is from the Indicio DemoNet.
2. Update the environment file with the schema:
   1. **sudo vi .env**
   2. Add a line right after the SCHEMA\_USER line
      1. **SCHEMA\_EMPLOYMENT=4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0**
   3. Save and exit
3. Update the common-services.yml file to pass the schema variable to the proven-issuer-api service:
   1. **sudo vi common-services.yml**
   2. Locate the line containing **SCHEMA\_USER** in the file. (It’s about a third of the way through the file.)
   3. Below that line, add the following line:
      1. **- SCHEMA\_EMPLOYMENT=${SCHEMA\_EMPLOYMENT}**
   4. Save and exit
4. Update the schema definition files with the new schema:
   1. **sudo vi config/proven-issuer-api/schemas.json**\
      {\
      &#x20;   "schemas": \[\
      &#x20;       {\
      &#x20;           "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0"\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0"\
      &#x20;       }\
      &#x20;   ]\
      }
   2. **sudo vi config/proven-issuer-api/schemas-verification.json**\
      {\
      &#x20;   "schemaList": \[\
      &#x20;       {\
      &#x20;           "verification\_label": "User - Full Disclosure",\
      &#x20;           "schema\_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "username",\
      &#x20;               "user\_email",\
      &#x20;               "user\_id",\
      &#x20;               "user\_roles"\
      &#x20;           ]\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "verification\_label": "User - Username and User Email",\
      &#x20;           "schema\_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "username",\
      &#x20;               "user\_email"\
      &#x20;           ]\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "verification\_label": "Employment - Full Disclosure",\
      &#x20;           "schema\_id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "employer\_region",\
      &#x20;               "employment\_type",\
      &#x20;               "employee\_given\_names",\
      &#x20;               "employer\_country",\
      &#x20;               "employment\_postal\_code",\
      &#x20;               "employment\_start\_date",\
      &#x20;               "employer\_postal\_code",\
      &#x20;               "employment\_country",\
      &#x20;               "employment\_role",\
      &#x20;               "employer\_city",\
      &#x20;               "employer\_address",\
      &#x20;               "employment\_role\_description",\
      &#x20;               "employee\_surnames",\
      &#x20;               "employer\_name",\
      &#x20;               "employment\_city",\
      &#x20;               "employment\_region",\
      &#x20;               "employment\_address"\
      &#x20;           ]\
      &#x20;       }\
      &#x20;   ]\
      }
   3. Save and exit
5. WARNING: The following commands do a complete reset of your Proven Agent. This means that all of your previous connections and issued credentials will no longer be accessible. This also means that you might need to re-anchor a new DID to the ledger (unless you are using a static DID in the .env file). If you are adding the new credential type before starting Proven for the first time, then you can ignore this warning and ignore the following steps.
6. Reset your proven agent so that the new credential schema will be usable by your Proven agent:
   1. **sudo systemctl stop proven**
   2. **sudo docker-compose -f docker-compose.live.yml down -v**
   3. **sudo rm -rf postgres-db**
   4. **sudo systemctl start proven**
7. Return to main instructions and continue.

## Appendix D - Issuer DID setup

For help with setting up your own Issuer DID, please contact us: <support@indicio.tech>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Google Cloud Installs


# Node Installation Guide

## Installing and Configuring NoDe 20.04

**Indicio NoDe 20.04 GC User Guide**

This document describes the steps to take to deploy your own NoDe 20.04 Indy Node from Google Cloud Marketplace using the Indy Node Image provided by Indicio, PBC.

Please read all instructions before attempting to create an Indy Node, as there are many steps that vary from default values. Unless otherwise noted, these instructions do not include items that work with default or blank values. If you wish to create your own complete Indy Network, you will need to create multiple NoDe instances, and a full overview can be found in the [NoDe Network Creation Guide](https://docs.google.com/document/u/1/d/1xto8vYZrkkWXMoZv4H4u8Q1n-GaLMUj0VE8LXm0aOFM/edit).

## Pre-deployment

### Project

1. Create a new GC Project for your node. 1. From the GC console (<https://console.cloud.google.com/>), select the drop down next to Google Cloud in the upper right 2. Click **New Project** in the upper left of the pop-up 3. All configurations are your choice, click **CREATE** when done

### Networks

1. Before creating the instance, you must configure the default and also an additional VPC network for your new node.
2. From the Navigation Menu, scroll over **VPC network** and select **VPC networks** (If you haven’t already, you will need to click **ENABLE** to use the compute engine API)
3. Before you begin, decide on a region to run your VM in that matches the jurisdiction of your company's corporate offices. Record the region selected for use throughout these instructions. You will use this same region later in the instructions when required.
4. Under VPC networks click **default** to edit the network configurations:
5. Click on the **SUBNETS** tab and then on **ADD SUBNET** and input the following values
   1. **Name** - client-subnet-9702 (or make a name according to your needs, making sure it is descriptive)
   2. **Region** - Your selected region
   3. **IPv4 range** - 10.0.1.0/24 (or enter another valid range according to your needs)
6. Click **ADD**
7. Click the back arrow next to **VPC network details** to go back to VPC Networks
8. Click **CREATE VPC NETWORK** at the top of the screen to create a network for your node connection on your node.
   1. **Name** - your choice (e.g. node-vpc)
   2. Under **Subnet creation mode** select **Custom**
   3. Expand the **New subnet** section and enter the following values
      1. **Name** - your choice (e.g. node-subnet-9701)
      2. **Region** - Your selected region
      3. **IPv4 range** - Type in a valid new subnet block. (e.g. 10.0.2.0/24)
      4. Click **DONE**
   4. For **Dynamic routing mode** select **Regional**
   5. Click **CREATE**

### Static IP addresses

1. Navigate to VPC network then select **IP addresses** from the menu
2. Click **RESERVE EXTERNAL STATIC IP ADDRESS**
   1. **Name** - node-external-ip or your choice
   2. **Network Service Tier** - Standard
   3. **Region** - Your selected region
   4. **Attached to** - None (it will be attached to your vm later during your creation of the main node vm)
   5. Click **RESERVE**
3. Click **RESERVE EXTERNAL STATIC IP ADDRESS**
   1. **Name** - client-external-ip or your choice
   2. **Network Service Tier** - Standard
   3. **Region** - Your selected region
   4. **Attached to** - None (it will be attached to your vm later during your creation of the main node vm)
   5. Click **RESERVE**

### Firewalls

1. Navigate back to **VPC network** then **VPC networks**
2. Under VPC networks click **default** to edit the network configurations for the NoDe’s “client” connection.
3. Click the **FIREWALLS** tab at the top of the page, and then click **ADD FIREWALL RULE** to add SSH access through the Client VPC. Use the following values in the fields below:
   1. **Name** - your choice (e.g. ssh-for-admin-access)
   2. **Direction of traffic** - Ingress
   3. **Action on match** - Allow
   4. **Targets** - All instances in the network
   5. **Source filter** - IPv4 ranges
   6. **Source IPv4 ranges** - Enter the public IP addresses or ranges for your Node Administrators. (e.g. 67.199.174.247/32)
   7. **Protocols and ports** - Specified protocols and ports
      1. Select the **TCP** check box and enter 22 for the port
   8. Click **Create**
4. Click **Add firewall rule**. Use the following values in the fields below:
   1. **Name** - your choice (e.g. client-access-9702)
   2. **Network** - default (should already be set)
   3. **Targets** - All instances in the network
   4. **Source filter** - IPv4 ranges
   5. **Source IPv4 ranges** - 0.0.0.0/0
   6. **Protocols and ports** - Specified protocols and ports
      1. Select the **TCP** check box and enter 9702 for the port.
   7. Click **Create**
5. Navigate back to **VPC Network** then **VPC Networks**
6. Click on the **node-vpc network** then click **Firewalls**
7. Ask your network administrator for a list of node IPs to add to your whitelist as part of the following steps. For each node IP on the network, do the following.
   1. Click **Add firewall rule**
      1. **Name** - Name (alias) of the node you are adding
      2. **Network** - node-vpc
      3. **Direction of traffic** - Ingress
      4. **Action on match** - Allow
      5. **Targets** - All instances in the network
      6. **Source filter** - IPv4 ranges
      7. **Source IPv4 ranges** - Enter the public IP address matching the Node name that you are adding. (e.g. 68.179.145.150/32)
      8. **Protocols and ports** - Specified protocols and ports
         1. Select the **TCP** check box and enter 9701 for the port
      9. Click **Create**
8. Repeat the last set of steps for each node in the node list, changing the node Name and IP address for each new rule (you may omit your own address)
9. **NOTE:** If you do not yet have a list of Network nodes and IP’s for the network you will be joining, you can do that part later. For now, just open up port 9701 to “all” source IP’s (0.0.0.0/0) in the same way you did that for port 9702 in the “client” firewall. Be sure to enter the appropriate firewall entries when you get the list.

### Snapshots

1. From the Navigation Menu, select **Compute Engine** then **Snapshots**
   1. Select the **SNAPSHOT SCHEDULES** tab then click **CREATE SNAPSHOT SCHEDULE**
   2. **Name** - your choice (e.g. 'nodesnapweekly')
   3. **Region** - Select the same region chosen earlier in this guide.
   4. **Snapshot location** - Regional (default location)
   5. **Schedule frequency** - Weekly (then your choice of day and time.)
   6. **Autodelete snapshots after** - 60 days
   7. **Deletion rule** - your choice (e.g. Select Delete snapshots older than 60 days to remove the snapshots every 2 months)
   8. Click **CREATE**

## Creating the VM Instance

1. From the Navigation Menu, select **Compute Engine**, then select **VM instances**
2. Click **Create Instance** at the top of the page
3. Select **Marketplace** in the left hand menu
4. In the search bar, type **Indicio NoDe** and hit enter
5. Select the option that is named **Indicio NoDe (Ubuntu 20.04)**
6. Click **GET STARTED**
7. Agree to the terms by checking the box and clicking **AGREE**
8. Click **DEPLOY**
9. **Deployment name** - \<your company name>
   1. This name will become the name of your node on the network as well (the node ALIAS) so including your company name in this is desired. Do NOT use "Indicio", "Sovrin”, “IDunion”, "CANDY", or the network owner's name in this name.
   2. i.e. use “\<company name>", "\<company name>-node", "\<company name>-TestNet-Node", "\<company name>-TestNet-Node1", or something similar
10. Choose and record a zone from the same region as you used previously in this document (ex. us-east4-c)
11. Machine configuration
    1. **Network Technical Governance requirements determine the values in this step.** 2 vCPUs and 8G memory are the minimum requirements for Indicio Networks.
    2. **Series** - N2
    3. **Machine Type** - n2-standard-2 (2 vCPUs and 8G memory)
12. Boot disk
    1. **Boot disk type** - Standard persistent disk is adequate.
    2. **Size** - 250 GB
13. Network interfaces
    1. Expand and change the existing default network interface. This will be your “client” interface.
       1. **Network** - default (or client-vpc)
       2. **Subnetwork** - select the subnet you created earlier for the Client (client-subnet-9702 10.0.1.0/24)
       3. **External IP** - select the external client IP you created earlier (client-external-ip)
       4. Click **DONE** (For this network interface)
    2. Click **Add A Network Interface** to add a second network interface. (Required)
       1. **Network** - node-vpc
       2. **Subnetwork** - select the subnet you created earlier for the node (node-subnet-9701)
       3. **Primary internal IP** - select the internal node IP you created earlier
       4. **External IP** - select the external node IP you created earlier
       5. Click **DONE**
    3. Click "Deploy" to create the new NoDe GC VM instance.

## Optional configurations prior to initiating the validator node. (skip this step if desired)

1. Once the VM is created, navigate to Compute Engine>VM instances
2. Click on the name of the VM you just created to access it’s settings
3. Click **Edit** at the top of the page
4. To set up ssh keys:
   1. Scroll down to **Security and access**
   2. Check the **Block project-wide SSH keys** (recommended)
   3. Enter a public SSH key for each Admin user (at least your own)
      1. Click **+ ADD ITEM** for each SSH key.
   4. To create an SSH key:
      1. You can use the following command to create a new SSH key pair on Linux or MAC that will work for this step. `ssh-keygen -P "" -t rsa -b 4096 -m pem -f ~/pems/gcnode.pem`
      2. Once a public key is created the following example can be used on MAC or Linux to display the public key and copy it to the form: `cat ~/pems/gcnode.pem.pub`
      3. Copy the results of the previous step and paste it into the space provided, being careful NOT to copy any leading or trailing whitespace.
5. To enable deletion protection:
   1. Under Basic information select the **Enable deletion protection** box (recommended)

## Connecting to the VM

1. SSH into your new node VM
   1. You can navigate to **Compute Engine** then **VM instances** then click **SSH** towards the right of your NoDe Instance
   2. OR you can use the SSH key access setup from an earlier optional step.
2. Setup 2FA for SSH access to the Node for your base user.
   1. Install Google Authenticator, Duo, or Authy on your phone.
   2. Configure the authenticator to allow both password and SSH key login with 2FA by changing the following file:
      1. sudo vim /etc/ssh/sshd\_config
      2. uncomment the following line at the bottom of the file: `AuthenticationMethods publickey,keyboard-interactive`
      3. :wq
      4. sudo systemctl restart sshd
   3. Setup your base user to use 2FA by running the following from a terminal:
      1. google-authenticator
      2. Answer "y" to all questions asked during the setup
      3. Save the secret key, verification code and scratch codes in a safe place. These are all just for your user and can be used to login or to recover as needed.
      4. On your phone app add an account and then scan the barcode or enter the 16 character secret key from the previous steps output.
      5. Reboot the instance and login to make sure 2FA is configured properly.
3. Add other administrative users:
   1. Send the other new admin users the following instructions for generating their own SSH keys:
      1. ssh-keygen -P "" -t rsa -b 4096 -m pem -f \~/pems/gcnode.pem
      2. Have the new users send you their public key (e.g. gcnode.pem.pub if they do the above command)
      3. Also have them send you their Public IP address so that you can add it to the GC firewall to allow them access. Optionally, have them send a preferred username also.
   2. Add their IP addresses to the GC firewall:
      1. From the GC VPC Networks screen (GC main menu -> VPC network->VPC networks), click on your Client VPC (e.g. client-vpc-9702)
      2. Click the "Firewall rules" tab (in about the middle of the screen).
      3. Click on the name of the rule that allows port 22 access for your admins (e.g. ssh-for-admin-access)
      4. Click "EDIT" at the top of the screen.
      5. Scroll down to the list of Source IP ranges and add the new Admins' IP addresses.
      6. Click "SAVE" (Note: Restart is not needed. As soon as you save, they should have access.)
   3. Add the users to the server:
      1. Login to the node as the base user.
      2. Run the following commands, substituting the username in for \<newuser>
      3. sudo adduser \<newuser>
         1. You can safely ignore messages like “sent invalidate(passwd) request, exiting“
         2. For “Enter new UNIX password:” input “password1” (This will be changed later)
         3. Enter a name (optional)
         4. Defaults are fine for the rest
      4. sudo usermod -aG sudo \<newuser>
      5. Then create a file in the newusers home directory:
         1. sudo mkdir /home/\<newuser>/.ssh
         2. sudo chown \<newuser>:\<newuser> /home/\<newuser>/.ssh
         3. sudo vim /home/\<newuser>/.ssh/authorized\_keys
         4. Paste the users public key into the open file and then save it (:wq)
         5. sudo chown \<newuser>:\<newuser> /home/\<newuser>/.ssh/authorized\_keys
      6. Repeat the above for each new admin user you create.
   4. The new users are now able to login. Since 2FA is required, when you send the password to each of the new users, also send the following instructions (HINT: fill in the username, Client IP address, and password for them with the correct values):
      1. Thanks for agreeing to help with the administration of our Indy Validator Node. Please login to the node, change your password, and setup Two Factor Authentication (2FA) using the following instructions:
      2. ssh -i \<your private SSH key file> \<username>@\<Client IP Addr>
      3. Type in password1 for your password
      4. On successful login, type in "passwd" to change your password on the Validator Node. Please use a unique password of sufficient length and store it in a secure place (i.e. a password manager).
      5. To set up 2FA, type in "google-authenticator"
         1. Answer "y" to all questions asked during the setup
         2. Save the secret key, verification code, and scratch codes in a safe place. These are all for your user and can be used to login or to recover as needed.
      6. Install Google Authenticator, Duo, Authy, or other google-authenticator compatible app on your phone or device. 2. On your 2FA phone app, add an account, and then scan the barcode or enter the 16 character secret key from step 4’s output. 3. Log out and then log back in to check and make sure it worked!

## Configuring the VM

1. Complete the network setup process
   1. Run the Oneshot startup process
      1. sudo /opt/indy-startup/Oneshot.sh
   2. sudo netplan generate
   3. sudo netplan apply
   4. sudo add-apt-repository "deb <http://security.ubuntu.com/ubuntu> bionic-security main"
2. Before proceeding, verify the network directory name for the network that you will be joining with your network administrator. The default used for NoDe is “itn” which is the directory name for the Indicio TestNet. If you will be joining a different network, please run the following command (substitute in your network directory name for “\<network>”).
   1. **sudo -i -u indy sed -i -re "s/(NETWORK\_NAME = ')\w+/\1\<network>/" /etc/indy/indy\_config.py**
   2. For example, for the Indicio DemoNet, the directory name is “idn” and the command would be `sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\\w+/\\1idn/" /etc/indy/indy_config.py`
3. **NOTE:** The genesis files are pre-installed to the correct places if you are joining one of the Indicio networks, but if you are joining a different network, then please use the genesis files provided by your network administrator and install them in the directory name they provided.
4. Run the following command
   1. **sudo -i -u indy init\_indy\_node \<ALIAS> \<node ip> \<node port> \<client ip> \<client port>**
   2. TIP: run ip a to find your IP addresses needed here.
   3. For example: sudo -i -u indy init\_indy\_node Node8 10.0.2.2 9701 10.0.1.2 9702
   4. You can view an example that is tailored to your system by running the following
      1. cat /opt/indy-startup/init\_indy\_node\_example
   5. Save the above init\_indy\_node command and all of the output in a safe place. You will need it later during onboarding and other actions.
5. IPTables DDOS protection (required for most Indy Networks)
   1. sudo sed -i -re "s/(^CLIENT\_CONNECTIONS\_LIMIT=).\*$/\115000/" /etc/indy/indy.env
   2. sudo DEBIAN\_FRONTEND=noninteractive apt install -y -q iptables-persistent
   3. sudo setup\_indy\_node\_iptables
6. Since your node is Ubuntu 20.04 based, if you are joining a network that has Ubuntu 16.04 nodes on it (or has in the past) you must run the following:
   1. echo "REV\_STRATEGY\_USE\_COMPAT\_ORDERING = True" | sudo tee -a /etc/indy/indy\_config.py
   2. If you are unsure, please check with your network administrator.
7. Run the Technical Verification Script on the validator node:
   1. Download this script, upload it to your Validator node, and set the execution flag on it:
      1. ubuntu\@validator$ cd \~
      2. ubuntu\@validator$ curl -O <https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/nodeop-tools/nodeop-tech-check.py>
      3. ubuntu\@validator$ chmod +x nodeop-tech-check.py
      4. Execute it, answering the questions that it asks. There are no wrong answers; please be honest. Questions that can be answered by scripting are automatically completed for you.
      5. ubuntu\@validator$ sudo python3 ./nodeop-tech-check.py
      6. After the script completes, copy the output beginning at '== Results for "A Node Operator MUST" ==', and paste it into an email addressed to <support@indicio.tech> then send it.
8. From this step onward you will need 2 machines, the Node VM that you just configured, and a separate machine to install and run the Indy CLI on: such as your workstation or a VM specifically for network administration tasks.
9. On the machine you’ve chosen for the CLI, install indy-cli using instructions from Appendix A at this link: [Indicio SelfServe Instructions](https://docs.google.com/document/d/18-8MiRRuxVHn-FFWyd8LHukPNl_WNzo-tJtXK9bmZfY/edit)
10. Create a JSON Config file containing your taaAcceptanceMechanism. (You can also add plugins to this config file, but for now just set it up as basic as possible.) `vi ~/cliconfig`
    1. This example cliconfig file contains the line that sets the AML:

```
    {
        "taaAcceptanceMechanism": "for_session"
    }
```

11. To start the indy-cli using your new config file, run the following: `indy-cli --config ~/cliconfig`
12. Next, generate a Steward DID using the CLI machine you just installed. This will comprise a public and private key pair, generated from a seed. Knowing your seed will allow you to regenerate the key on demand. *To keep this secure, you will need to have a* ***very*** *secure Steward seed that is not easy to guess.*
    1. sudo apt install pwgen
    2. pwgen -s 32 1
    3. Record the output of the above command as the “Steward Seed”
13. Next we run the indy-cli command line CLI by entering: `indy-cli --config ~/cliconfig`
14. In the command line, enter the following to create your pool configuration and your wallet locally. When creating your wallet, you will need to provide a "key" that is any string desired. It will be the encryption key of your local wallet.

```
indy> pool create &lt;pool name (e.g. itn)&gt;
gen_txn_file=pool_transactions_&lt;Network Name (e.g. TestNet)&gt;\_genesis
indy> wallet create &lt;wallet name (e.g. itn_wallet)&gt; key
```

15. Open your wallet and create a DID based on the “Steward Seed” created earlier.

```
    indy> wallet open &lt;wallet_name&gt; key
    indy> did new &lt;Steward Seed&gt; metadata=”steward DID”
```

16. Provide Information to Trustees
    1. At this point you should have the following data available:
       1. Your Steward verkey and DID
       2. The Validator ‘node IP address’
       3. The Validator ‘client IP address’
       4. The Validator ‘node port’
       5. The Validator ‘client port’
       6. The Validator alias
       7. The Validator verkey
       8. The BLS key
    2. Please go to the [Node Operator Validator Registration form](https://docs.google.com/forms/d/e/1FAIpQLSeGNlKIAk13av0Fu0wg_Q9Q-cBhSOlt3LCFbdU8_0fGotNJ_Q/viewform) for Indicio networks (or the equivalent for the network you are joining) and provide the requested information.

**Note:** You are done with the first part of the installation and onboarding. Send an email to <support@indicio.tech> (or the equivalent) and the network administrator staff will help you to set up the rest.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Proven Installation Guide

## Installing and Configuring Proven

This document will guide you through the steps to deploy and configure Proven in Google Cloud using Indicio Proven from the GC Marketplace. The first part of this document is intended to be a “quick start” to get you up and running quickly, then you can look at the indicated appendices for more details if needed.

**Get the most of your Indicio Proven**

Indicio is here to help you on every step of your journey and is offering Google Cloud customers exclusive access and discounts to Indicio’s expert support and training. Get your critical technical questions answered from our experienced support team. Help your development, sales, and marketing teams get up to speed with the fundamentals of the technology and communication of Trusted Digital Ecosystems by taking advantage of our instructor-led workshops and certifications from the [Indicio Academy](https://indicio.tech/indicio-academy/). Learn more about these exclusive discounts and [benefits for Google Cloud customers](http://indicio.tech/proven-sandbox-google-cloud) and [contact us](https://indicio.tech/contact/) today!

## Creating the VM instance (Defaults will work for all items not included in these instructions)

1. Navigate to the Google Cloud Console, <https://console.cloud.google.com/>
2. Select the project that you want the Proven instance to reside in.
3. In the Navigation Menu (top left), go to **Compute Engine** > **VM Instances**
   1. If it’s a new project, click “Enable”
4. Click **CREATE INSTANCE**
   1. From the left menu select “**Marketplace**”.
   2. In the “**Search Marketplace**” field type “**Proven**” and hit enter.
   3. Select “**Indicio Proven**”.
   4. Click **GET STARTED** to configure your Proven VM as a trial, or click **LAUNCH** if you have already done the trial.
      1. If a trial, agree to the agreements then click **DEPLOY.**
      2. For new projects, click “Enable” to enable the required APIs.
5. Change the **Deployment nam**e if desired. This will be the name of your VM instance.
6. Select and record your **Zone** choice for later use.
7. For **Machine type** choose a machine with at least 2 vCPU’s and 4G memory. For example, these defaults should be adequate:
   1. Set **Series** to E2
   2. Set **Machine type** to e2-medium
8. Under **Boot disk** it is recommended to select a disk at least **50GB** in size. (default)
9. You can set a static IP address later if desired. It is not available for change at this phase unless you have already pre-configured a static IP for use here. (This can be accomplished by creating a static external IP in your default VPC in a separate tab.)
10. Scroll to the bottom, check the box to accept the terms of service, then click **DEPLOY**.
11. After deployment is complete:
    1. Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
    2. In the right panel - **Click on the instance name** to bring up details about the Proven instance you just deployed
    3. Click **EDIT**
    4. Scroll down to **Networking** and under **Firewalls** check the boxes that will allow HTTP and HTTPS traffic.
    5. Click **SAVE**
    6. Click **VM instances** (in the left menu)
    7. Record the **External IP** address of your Proven instance for later use.

## Configure DNS (see appendix A for an example DNS setup option)

1. Add a DNS entry for Proven.

## Configure the VM

1. Navigate back to the Google Cloud console
2. SSH into the VM 1. Select Compute engine > VM instances Then for \[your-proven-instance] click **SSH**
3. Enter these commands in your instance to make it so that the “proven.service” starts up automatically after every server reboot.

   ```
    cd /opt/indicio/proven-release-docker
    sudo systemctl enable proven
   ```
4. Run this command for Proven.

   ```
    sudo cp staging.env .env
   ```
5. Run the command `ip a` and record the private ip address of your primary network interface (ens4). This local IP address will be used in the next step.
6. Edit the .env file to fit your environment. -> `sudo vim .env`\
   Shown below are the minimal fields needing configured, their default values, and short descriptions. The remaining fields are described in Appendix B.

&#x20;   PROVEN\_ISSUER\_SERVER\_NAME=proven.dev.indiciotech.io\
&#x20;       Use your DNS entry or the IP address for the issuer. Do not include “http\://” or a trailing slash

&#x20;   PROVEN\_ISSUER\_SEED=\
&#x20;       Must be 32 alphanumeric characters. Has to have “--seed “ at the start. If you do not have a seed, you may leave this blank if this is a testing environment and if blank make sure to perform step 7. For a production environment, see Appendix D.

&#x20;   TAILS\_URL=<http://10.128.15.205:6543>\
&#x20;       Replace the IP address on this line with your local IP address. Leave the port as 6543.

&#x20;   NODE\_ENV=production

&#x20;   PROVEN\_ISSUER\_API\_DB\_PASSWORD=provenapi\
&#x20;       Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_AGENT\_DB\_PASSWORD=provenagent\
&#x20;       Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_PROXY\_DB\_PASSWORD=provenagent\
&#x20;       Local database password. For security purposes, this MUST be changed.

&#x20;   PROVEN\_ISSUER\_AGENT\_LABEL=Proven\
&#x20;       This is what you want the issuer name to show up as on other agents’ connection list. Change this so that agents can tell the difference between Proven issuers.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b\
&#x20;       For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters. Encryption key.

&#x20;   PROVEN\_ADMIN\_PASSWORD=\
&#x20;       Must be added and must be 15 characters long.

&#x20;   PROVEN\_ISSUER\_WEB\_ROOT=<https://proven.dev.indiciotech.io>\
&#x20;       If you have a DNS name, change localhost to the issuer DNS name with https\://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.

&#x20;   PROVEN\_ISSUER\_JWT\_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq\
&#x20;       For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_SESSION\_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5\
&#x20;       For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=54234625127cb22694ff0e27cc14b685\
&#x20;       For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

8. Run the following command:
   1. sudo systemctl start proven
   2. Start a new SSH window if you want to monitor the progress of the starting of Proven.
      1. sudo systemctl status proven
      2. On error, return to the original ssh window, wait for the process to stop, then try again.
9. INFORMATIONAL NOTES: “proven.service” is a linux service file that makes it easy to start and stop your proven instance. It usually takes a minute or two for Proven to be ready for use. The following are some tips and FUTURE commands that you can run if you need to manage the proven service,
   1. IMPORTANT: Do NOT stop the service in the middle of its initial starting time. You have a chance of interrupting the install process and it will corrupt files that will need to be removed before restarting.
   2. **For later use** to stop the proven service: `sudo systemctl stop proven`
   3. **For later use** to restart the proven service: `sudo systemctl stop proven` `sudo systemctl start proven`

## Accessing Proven

You should now be able to navigate to your Proven issuer in a web browser, using its DNS Name or ip address.

## (OPTIONAL) In this version of Proven, only the “User” credential is included. If you would like to add more credentials, follow the steps in Appendix C now.

## Creating and Anchoring your Issuer DID

1. If you left the ISSUER seed variable blank during step 4d, this step is required
2. Run the following commands from the google cloud SSH window:
   1. **sudo docker-compose -f docker-compose.live.yml exec proven-issuer-api node firstimesetup.js**
   2. Agree to the Transaction Author Agreement
   3. To anchor the new DID which is now displayed -> open <https://selfserve.indiciotech.io>
   4. Select the Indicio DemoNet option from the Network dropdown box. DemoNet is the default used in Proven, but please select TestNet if you changed the .env file to that one. You will need to use a different tool if your identity network is not an Indicio network.
   5. Copy the new DID and Verkey displayed on the Proven window, to the DID and Verkey fields of the Selfserve form.
   6. Click Submit
   7. Return to the Proven SSH window and enter ‘y’ to indicate having anchored the Endorser DID.
   8. Wait while the Credential definitions are created for you.
   9. When you see **Completed**, then press enter to continue.
3. Your Proven instance is now ready to go!
4. To try out Proven with a user credential do the following:
   1. Install the latest Holdr+ app on your mobile device.
   2. Navigate to your Proven IP address or DNS url.
   3. Using your mobile Holdr+ app, scan the QR code displayed.
      1. This creates a connection between your mobile device and the Proven Issuer
      2. Troubleshooting Tip: If you see "Loading Please wait" for a long time at this point, try refreshing the browser page. If that doesn’t fix the problem then you might have an issue with your DNS setup that is causing the problem.
   4. Change the IP address in your browser by adding “/admin” to the end of it.
   5. Login using the following credentials:
      1. Username: admin
      2. Password:
   6. You should now see the Issuer admin interface.
   7. Click on CONTACTS in the left menu
   8. Click on the most recent contact.
   9. Under choose credential, select “user”
      1. Hint: if the “user” option is not in the list, refresh the page and try again
   10. Fill in the fields
   11. Click “Send”
   12. You should now see a notification of a new credential on your mobile device (go to the home screen to see notifications on Holdr+)
   13. Click “view” to view the credential offer.
   14. Scroll to the bottom of the Credential offer and click “Accept”
   15. After the credential is added to your wallet, click ‘Done’.
   16. You now have Proven Issuer working!

## Appendix A - DNS Setup Example

To setup DNS for Proven on Google’s Cloud DNS, (by creating a new subdomain of your existing domain) do the following:

1. Go to GCP’s **Cloud DNS** section in **Network services** (Navigation Menu > Networking > Network Services > Cloud DNS)
2. Click **Create Zone** if a new Zone is desired. Otherwise, if a zone is already created, click on the zone name then skip to step 3.
   1. Give the zone a name. This name is just how it will appear in the list and need not necessarily match the new subdomain.
   2. For **DNS name,** enter a new subdomain. (In the example configuration below, using the domain dev.indiciotech.io means we want to create a new **dev** subdomain of the existing indiciotech.io domain)
   3. Click **Create**
   4. Here’s an example configuration:
   5.
   6. To “activate” this new subdomain in GC, you need to register the subdomain in your existing domain (i.e. at your registrar).
      1. Click the name of the new zone you just created.
      2. Click on **REGISTRAR SETUP** (upper right of the screen) to find the items needing added to the new NS record, then add the domain’s DNS Name Server entries to your registrar.
3. Click **Add Standard**
   1. Create a DNS Name for proven and record it for later use (e.g. proven.dev.indiciotech.io)
   2. Defaults are okay
   3. Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
   4. Click “Create”

## Appendix B - Environment file variable descriptions plus an example file.

1. Full list of .env file variable descriptions

&#x20;   PROVEN\_ISSUER\_SSL\_DOMAIN\_PATH=\
&#x20;       Path to Issuer SSL certificate. If not defined, creates a self-signed cert. If using certbot, leave blank before running certbot.

&#x20;   PROVEN\_ISSUER\_SERVER\_NAME=proven.dev.indiciotech.io\
&#x20;       Use your DNS entry for the issuer in place of “localhost.” Do not include “http\://” or a trailing slash

&#x20;   PROVEN\_ISSUER\_HTTPS\_PORT=443\
&#x20;       The port that the issuer uses for https connections.

&#x20;   PROVEN\_ISSUER\_HTTP\_PORT=80\
&#x20;       The port that the issuer uses for http connections.

&#x20;   GENESIS\_URL=<<https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis\\_files/pool\\_transactions\\_testnet\\_genesis\\>
&#x20;       The URL to the Genesis pool file. Must be a URL. Do not include a trailing slash. The default connects to the testnet, make sure to adjust this for the network you are connecting to.

&#x20;   PROVEN\_ISSUER\_SEED=\
&#x20;       Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Typically only used in Live environments.

&#x20;   TEST\_SEED=\
&#x20;       Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Not necessary.

&#x20;   TAILS\_URL=<http://10.128.15.205:6543>\
&#x20;       Replace the IP address with your local IP address on this line.

&#x20;   DISABLE\_SSL\_CHECK=true     NODE\_ENV=development\
&#x20;       Possible values: production, development

&#x20;   GOVERNANCE\_PATH=<http://localhost:3100/api/governance-framework>\
&#x20;       Where governance details are downloaded from. Can use DNS name, but typically left as localhost.

&#x20;   PROVEN\_ISSUER\_API\_DB\_HOST=db\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_API\_DB=provenapi\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_API\_DB\_USERNAME=provenapi\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_API\_DB\_PASSWORD=provenapi\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_DB=provenagent\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_DB\_HOST=db\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_DB\_USERNAME=provenagent\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_DB\_PASSWORD=provenagent\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_USERNAME=development\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_ADMIN\_DB\_PASSWORD=development\
&#x20;       Local database

&#x20;   PROVEN\_ISSUER\_AGENT\_LABEL=Proven\
&#x20;       This is what you want the issuer name to show up as on other agents’ connection list.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b\
&#x20;       Encryption key. Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_PROXY\_DB=postgres\://provenproxy:provenproxy\@db:5432/provenproxy

&#x20;   PROVEN\_ISSUER\_WEB\_ROOT=<https://issuer.dev.indiciotech.io>\
&#x20;       If you have a DNS name, change localhost to the issuer DNS name with https\://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.

&#x20;   PROVEN\_ISSUER\_JWT\_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq\
&#x20;       Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_SESSION\_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5\
&#x20;       Must be 32 alphanumeric characters.

&#x20;   PROVEN\_ISSUER\_ENC\_KEY=54234625127cb22694ff0e27cc14b685\
&#x20;       Must be 32 alphanumeric characters.

&#x20;   ISSUER\_RECAPTCHA\_SITEKEY=\
&#x20;       Paste in your saved recaptcha site key that you created in step 3

&#x20;   ISSUER\_RECAPTCHA\_SECRETKEY=\
&#x20;       Paste in your saved recaptcha secret key that you created in step 3

&#x20;   SCHEMA\_USER=Gj39gdivhMneKBaamMsX7P:2:User:1.0

## Appendix C - Add a new credential type

Proven ships with just a User credential by default. The following details the instructions for adding a new credential type to the list of credentials managed by your instance of Proven. These instructions just include the method needed for altering the Proven configuration to include an existing schema and do not include the instructions for building and adding a schema to an identity network. Please contact <support@indicio.tech> for more information.

These instructions are an example of how to add an employment schema to your instance of Proven.

1. Find the Schema ID of the credential you would like to add to Proven.
   1. For this example, we use the employment schema **4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0** which is from the Indicio DemoNet.
2. Update the environment file with the schema:
   1. **sudo vi .env**
   2. Add a line right after the SCHEMA\_USER line
      1. **SCHEMA\_EMPLOYMENT=4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0**
   3. Save and exit
3. Update the common-services.yml file to pass the schema variable to the proven-issuer-api service:
   1. **sudo vi common-services.yml**
   2. Locate the line containing **SCHEMA\_USER** in the file. (It’s about a third of the way through the file.)
   3. Below that line, add the following line:
      1. **- SCHEMA\_EMPLOYMENT=${SCHEMA\_EMPLOYMENT}**
   4. Save and exit
4. Update the schema definition files with the new schema:
   1. **sudo vi config/proven-issuer-api/schemas.json**\
      {\
      &#x20;   "schemas": \[\
      &#x20;       {\
      &#x20;           "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0"\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0"\
      &#x20;       }\
      &#x20;   ]\
      }
   2. **sudo vi config/proven-issuer-api/schemas-verification.json**\
      {\
      &#x20;   "schemaList": \[\
      &#x20;       {\
      &#x20;           "verification\_label": "User - Full Disclosure",\
      &#x20;           "schema\_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "username",\
      &#x20;               "user\_email",\
      &#x20;               "user\_id",\
      &#x20;               "user\_roles"\
      &#x20;           ]\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "verification\_label": "User - Username and User Email",\
      &#x20;           "schema\_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "username",\
      &#x20;               "user\_email"\
      &#x20;           ]\
      &#x20;       },\
      &#x20;       {\
      &#x20;           "verification\_label": "Employment - Full Disclosure",\
      &#x20;           "schema\_id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0",\
      &#x20;           "schema\_attributes": \[\
      &#x20;               "employer\_region",\
      &#x20;               "employment\_type",\
      &#x20;               "employee\_given\_names",\
      &#x20;               "employer\_country",\
      &#x20;               "employment\_postal\_code",\
      &#x20;               "employment\_start\_date",\
      &#x20;               "employer\_postal\_code",\
      &#x20;               "employment\_country",\
      &#x20;               "employment\_role",\
      &#x20;               "employer\_city",\
      &#x20;               "employer\_address",\
      &#x20;               "employment\_role\_description",\
      &#x20;               "employee\_surnames",\
      &#x20;               "employer\_name",\
      &#x20;               "employment\_city",\
      &#x20;               "employment\_region",\
      &#x20;               "employment\_address"\
      &#x20;           ]\
      &#x20;       }\
      &#x20;   ]\
      }
   3. Save and exit
5. WARNING: The following commands do a complete reset of your Proven Agent. This means that all of your previous connections and issued credentials will no longer be accessible. This also means that you might need to re-anchor a new DID to the ledger (unless you are using a static DID in the .env file). If you are adding the new credential type before starting Proven for the first time, then you can ignore this warning and ignore the following steps.
6. Reset your proven agent so that the new credential schema will be usable by your Proven agent:
   1. **sudo systemctl stop proven**
   2. **sudo docker-compose -f docker-compose.live.yml down -v**
   3. **sudo rm -rf postgres-db**
   4. **sudo systemctl start proven**
7. Return to main instructions and continue.

## Appendix D - Issuer DID setup

For help with setting up your own Issuer DID, please contact us: <support@indicio.tech>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Mediator Installation Guide

## Installing and Configuring ACA-Py Mediator

This document will guide you through the steps to deploy and configure the Proven Mediator in Google Cloud using Indicio Proven ACA-Py Mediator from the GC Marketplace. The first part of this document is intended to be a “quick start” to get you up and running quickly, then you can look at the indicated appendices for more details if needed.

**Get the most of your Indicio Proven ACA-Py Mediator**

Indicio is here to help you on every step of your journey and is offering Google Cloud customers exclusive access and discounts to Indicio's expert support and training. Get your critical technical questions answered from our experienced support team. Help your development, sales, and marketing teams get up to speed with the fundamentals of the technology and communication of Trusted Digital Ecosystems by taking advantage of our instructor-led workshops and certifications from the Indicio Academy. Learn more about these exclusive discounts and benefits for Google Cloud customers and contact us today!

***

## Prerequisites

1. You will need a DNS name for your new mediator. This is mentioned before you begin as informational because you will probably want to create a static IP address during the installation process and because you will need the ability to add the DNS name to your registrar.

## Create the VM instance (Defaults will work for all items not included in these instructions)

1. Navigate to the Google Cloud Console, <https://console.cloud.google.com/>
2. Select or create the project that you want the Mediator instance to reside in.
3. In the Navigation Menu (top left), go to **Compute Engine > VM Instances**
4. Click **CREATE INSTANCE** on the top bar
5. From the left menu select **Marketplace**.
6. In the **Search Marketplace** field type **Proven** and hit enter.
   1. Select **Indicio Proven ACA-Py Mediator**.
   2. Click **GET STARTED** then **AGREE** (as needed)
   3. Click **DEPLOY** (or LAUNCH) to configure your mediator VM.
7. Change the **Deployment name** if desired.
8. Select and Record your Zone choice for later use.
9. Under **Machine type** choose a machine with at least 2 vCPU’s and 2G memory. For example:
   1. Set **Series** to E2
   2. Set **Machine type** to e2-small
10. Under **Boot Disk** it is recommended to select a disk at least 10GB in size. (default)
11. Under **Networking -> External IP** set a static IP address (recommended), this can also be done later if desired.
12. Click **DEPLOY**.
13. After deployment is complete, do the following from the right panel:
    1. Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
    2. Click on the instance name to bring up details about the Mediator instance you just deployed
    3. Click “edit”
    4. Scroll down to **Networking** and under **Network interfaces -> Firewalls** check the boxes that will allow HTTP and HTTPS traffic.
    5. Click **SAVE**
    6. Click **VM instances**
    7. Record the **External IP address** of your Mediator instance for later use. \\

## Configure DNS (see appendix A)

1. Add a DNS entry for your new mediator.

## Configure the VM

1. SSH into the VM
   1. From **Compute Engine > VM instances >** \[instance name] click **SSH** towards the top of the screen
2. Change directories to the mediator service directory `cd /opt/indicio/aries-mediator-service`
3. Configure the environment by doing the following: `sudo cp .env.sample .env`
4. Edit the .env file to fit your environment:

&#x20;   MEDIATOR\_CONTROLLER\_ADMIN\_API\_KEY=\<your choice>\
&#x20;       You can generate strong tokens for production with OpenSSL: `openssl rand 32 -hex`\
&#x20;   MEDIATOR\_AGENT\_ADMIN\_API\_KEY=\<your choice>\
&#x20;       You can generate strong tokens for production with OpenSSL: `openssl rand 32 -hex`\
&#x20;   MEDIATOR\_ALIAS=\
&#x20;       Can be any string. (e.g. MyProdMediator1)\
&#x20;   LOG\_LEVEL=\
&#x20;       Can be ERROR, WARNING, or INFO, depending on your preference. Note: INFO level produces the largest log file.\
&#x20;   SITE\_ADDRESS=\
&#x20;       This is the complete mediator DNS Name you configured in a previous step.\
&#x20;   MEDIATOR\_URL=\
&#x20;       This is the same as SITE\_ADDRESS, except add https\:// to the front of it.\
&#x20;   EMAIL\_ADDRESS=\
&#x20;       The email you want log information sent to.\
&#x20;   MEDIATOR\_AGENT\_LABEL=\
&#x20;       This is what you want the mediator name to show up as on other agents.

5. Here is an example of a configured .env file using a local database: `MEDIATOR_CONTROLLER_ADMIN_API_KEY=openssl-secure-key-a<br> MEDIATOR_AGENT_ADMIN_API_KEY=openssl-secure-key-b<br> MEDIATOR_ALIAS=Indicio Mediator<br> LOG_LEVEL=WARNING<br> SITE_ADDRESS=indiciomediator.dev.indiciotech.io<br> MEDIATOR_URL=https://indiciomediator.dev.indiciotech.io<br> EMAIL_ADDRESS=example@indicio.tech<br> MEDIATOR_AGENT_LABEL=IndicioMediator`
6. For instructions or help configuring the mediator to use a remote database, please contact <support@indicio.tech>, but to get started, please see the complete list of other possible config options in Appendix B.
7. To start the Mediator, run these commands

```
    cd /opt/indicio/aries-mediator-service
    sudo docker-compose up
```

8. For **future** starts/stops of your mediator you can use the mediator service. (The first time, you needed to run it manually from the command line so that you could see and copy the invitation as described in the next step.)\
   `sudo systemctl start mediator`\
   `sudo systemctl stop mediator`\
   `sudo systemctl restart mediator`

## Using your new mediator:

1. You should see an **Invitation URL** in the mess of activity that occurs during startup. Just scroll up a ways and you will see it. Copy and save this invitation for later use.
   1. If you open the mediator link generated, you should see the following message:

      "You have received a connection invitation. To accept the invitation, paste it into your agent application."
2. Update the configuration files of your agents to use the new mediator invitation. For example, to update a Proven issuer to use your new mediator:
   1. In the /opt/indicio/proven-release-docker/common-services.yml file change all instances of **MEDIATOR\_INVITE** to be the new mediator invitation. Then run the following commands on the Proven Issuer server.\
      `docker-compose down -v`\
      `docker-compose build`\
      `docker-compose up`

## Appendix A - DNS Setup Example

To setup DNS for your new Mediator on Google’s Cloud DNS, (by creating a new subdomain of your existing domain) do the following:

1. Go to GCP’s **Cloud DNS** section in **Network services** (Navigation Menu > Networking > Network Services > Cloud DNS)
2. Click **Create Zone** if a new Zone is desired. Otherwise, if a zone is already created, click on the zone name then skip to step 3.
   1. Give the zone a name. This name is just how it will appear in the list and need not necessarily match the new subdomain.
   2. For \*\*DNS name, \*\*enter a new subdomain. (In the example configuration below, using the domain dev.indiciotech.io means we want to create a new **dev** subdomain of the existing indiciotech.io domain)
   3. Click **Create**
   4. To “activate” this new subdomain in GC, you need to register the subdomain in your existing domain (i.e. at your registrar).
      1. Click the name of the new zone you just created.
      2. Click on **REGISTRAR SETUP** (upper right of the screen) to find the items needing added to the new NS record, then add the domain’s DNS Name Server entries to your registrar.
3. Click **Add Standard**
   1. Create a DNS Name for proven and record it for later use (e.g. mediator.dev.indiciotech.io)
   2. Defaults are ok
   3. Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
   4. Click “Create”

## APPENDIX B - More .env Configuration Options

&#x20;   CA\_CERT=\
&#x20;       This is the path to the SSL certificate for the remote database. You MUST specify a file, otherwise the mediator will not work at all if using a remote database. If you do not wish to use a certificate (they will not work with the setup detailed in this documentation), you will need to specify an empty file. Example: `./server-ca.pem`\
&#x20;   POSTGRESQL\_HOST=\
&#x20;       The hostname or ip address of the remote database. IP address will not work if you are using SSL, as SSL requires a FQDN. Postgresql options should not be set if using a local database.\
&#x20;   POSTGRESQL\_USER=\
&#x20;       The username of an account on the remote database. This can be the same user as the Admin User. Postgresql options should not be set if using a local database.\
&#x20;   POSTGRESQL\_PASSWORD=\
&#x20;       The password to the account on the remote database instance. MUST BE IN SINGLE QUOTES (eg: ‘samplepassword’) Postgresql options should not be set if using a local database.\
&#x20;   POSTGRESQL\_ADMIN\_USER=\
&#x20;       This is the username for the Administrator account on the remote database. It is “postgres” by default. Postgresql options should not be set if using a local database.\
&#x20;   POSTGRESQL\_ADMIN\_PASSWORD=\
&#x20;       This is the password for the Administrator account on the remote database. Postgresql options should not be set if using a local database.\
&#x20;   MEDIATOR\_WALLET\_NAME=\
&#x20;       Use a descriptive name\
&#x20;   MEDIATOR\_WALLET\_KEY=\
&#x20;       Use a secure string, we recommend a randomly generated 32 character string

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Network Installs


# Indicio DemoNet

### Your enterprise-grade network for demonstrating reliable, powerful decentralized identity solutions.

The Indicio DemoNet uses the open-source technology of Hyperledger Indy, Aries and Ursa to provide a stable network platform for demonstrating your decentralized identity solution.

Combined with access to our team of experienced engineers, you’ll have the hands-on support you need to showcase your innovation.

### Start writing to the DemoNet today!

It’s easy to start using the Indicio DemoNet, just follow these steps:

Create a public DID (decentralized identifier). This can be done with the [indy-cli](https://github.com/hyperledger-archives/indy-sdk/blob/main/cli/README.md), with the [Aries Toolbox](https://github.com/hyperledger-archives/aries-toolbox), or by [following these instructions](https://docs.google.com/document/d/18-8MiRRuxVHn-FFWyd8LHukPNl_WNzo-tJtXK9bmZfY/edit?tab=t.0#heading=h.wpvhq7vcr5ab).

After you create your public DID complete this form. Select “DemoNet” from the dropdown to get your DID written to the Network.

[**LEARN MORE**](https://selfserve.indiciotech.io/)

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio MainNet

### Your enterprise-grade network for delivering fast, powerful decentralized identity solutions.

## What is a decentralized network?

Using a decentralized network provides a layer of cryptographic trust and a source of truth for your solutions. Through cryptography and metadata you can always be sure on who issued a credential and that the information has not been tampered with. No personal data is ever written to the ledger.

Decentralized networks remove the need for personal data to be stored in siloed databases. In doing this, they provide a simple way to comply with data privacy law and remove the risk from data being stored in third-party databases.

The Indicio MainNet provides a home for your solutions no matter your use case, industry, or organization type. Our architects and engineers have years of experience and are standing by to help you build and deploy your solution on our world renowned network.

Indicio has three public networks you can use for your solutions the MainNet, DemoNet, and TestNet. We also provide private networks for internal testing or development – reach out to ask us more about a private network.

## Why use Indicio’s network

### Stable

Our professionally managed network ensures you have a dependable, stable place to build mission critical products and services. Over the last four years we have had 100% uptime across all three networks.

### Robust

Indicio has nodes across five continents, providing a robust decentralized network you can rely on. Learn more about hosting a node and joining the Indicio Network Consortium.

### Privacy Protection

No personal data is ever written to a distributed network. The end user holds and has full control over their data, including who they share it with and how it is shared. Decentralized networks replace storing personal data in risky siloed or third-party databases. They provide a simple way for you to comply with evolving data privacy laws.

Become a Transaction Endoser to start writing to the MainNet today. Complete the [Request Form](https://indicio.tech/indicio-mainnet/)

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Private networks

### Your own internal network specially designed for your needs.

### What is a private network?

A private network refers to a network that requires permission to use. These “permissioned” networks allow companies or organizations with shared and specific interests and goals to provide verifiable information to their customers or stakeholders. You could, for example, use a private network for managing a supply chain, a government may want to control a private network for a particular purpose, or someone could spin up a private network to conduct specific testing.

Private networks gain power through using interoperable agents. This means that credentials created for use on one private network could have the option to also be verified on other networks, whether public or private. This creates a “network-of-networks effect,” and ensures long-term business flexibility.

[Learn More about networks](https://indicio.tech/what-does-the-ledger-do-anyway/)

## Why go private?

Make your network for your own use. Governments, scientists, financial institutions, enterprise services, and specialized groups and services need to have control over where the network is hosted, which organizations are part of their network, who can write to the ledger, and how the network is governed. With our customizable Private Network Services, you can have this control.

### Get To Market Fast

We’ll get your network up and running in days. We understand the importance of being agile in today’s market and we’ve assembled an [industry-leading team](https://indicio.tech/about/) of engineers who will set up your network quickly and efficiently. We have your service support and advice—every step of the way.

### Build today

With a private network, you can start building and testing your Trusted Data Ecosystem before deploying them in public. You get to understand the the innovative [potential of decentralized identity](https://indicio.tech/what-is-decentralized-identity/) from the inside. Set up the governance that meets your and your customers’ needs.

### Make it interoperable

You want your network to be private; trust us, you also need it to be interoperable. [We build](https://indicio.tech/indicio-testnet/) on Hyperledger Indy, the most widely used interoperable platform for decentralized identity. We give you the added functionality and business flexibility that a stand-alone network can’t provide.

[Contact Us Today](https://indicio.tech/contact/)

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Indicio Testnet

## Indicio TestNet

#### Your enterprise-grade network for exploring new ideas for powerful decentralized identity solutions.

The Indicio TestNet is a free to use community resource built on the open-source technology of Hyperledger [Indy](https://www.lfdecentralizedtrust.org/projects/hyperledger-indy), [Aries](https://www.lfdecentralizedtrust.org/projects/aries) and [Ursa](https://www.lfdecentralizedtrust.org/projects). It provides a neutral, independent, and reliable decentralized network for the exchange of verifiable credentials.

Combine the TestNet with optional support from our team of experienced engineers, and you’ll have everything you need to start building on a network you can depend on!

## Start writing to the TestNet today!

To begin using the TestNet, follow these steps:

1. Create a public DID (decentralized identifier). This can be done with the [indy-cli](https://github.com/hyperledger-archives/indy-sdk/blob/main/cli/README.md), with the [Aries Toolbox](https://github.com/hyperledger-archives/aries-toolbox), an app of your choice, or by [following these instructions](https://docs.google.com/document/d/18-8MiRRuxVHn-FFWyd8LHukPNl_WNzo-tJtXK9bmZfY/edit?tab=t.0#heading=h.wpvhq7vcr5ab).
2. Then, [click here](https://selfserve.indiciotech.io/) to get the DID written to the TestNet.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Why use the Indicio Network?

### Dependable & Consistent

Our expertly managed network provides you with a reliable and consistent environment to develop mission-critical products and services. Boasting an impressive track record of 100% uptime across the networks over the past four years, you can count on our dedicated network professionals.

### Expert support

Indicio’s team of industry professionals have years of experience working with decentralized identity and delivering solutions that are in use around the world. They can help you migrate an existing project or start a new one and ensure you have everything you need to succeed.

### Global Coverage

With strategically positioned nodes Indicio provides an unparalleled decentralized network that both meets and elevates your ambitions with steadfast reliability. Unlock even greater advantages by becoming a Node Operator.

### Scalable Solutions

Elevate your business with networks designed to grow alongside you, seamlessly accommodating the needs of organizations and solutions of all sizes and sectors. Take advantage of our TestNet and DemoNet at no cost

### Privacy Protection

By embracing decentralized networks, you significantly reduce the risks tied to storing personal data in vulnerable siloed environments or third-party databases. This approach fortifies your data protection and streamlines your ability to stay compliant with the ever-evolving landscape of data privacy regulations.

### Multiple Networks

Indicio runs three public networks, the MainNet for hosting your solutions, the DemoNet for demoing solutions, and the TestNet for building your solutions. We also provide private networks for internal development. The TestNet and DemoNet are free to use and, if you’re a Node Operator, include free support.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Knowledge Center

Discover a range of educational resources—from technical papers to core concepts—that will help you learn, build, deploy, and scale with Indicio Proven.

[Glossary](/product/knowledge-center/glossary)

[Indicio Whitepapers](broken://pages/DCCA8rr2LwEn4KTVOrG6)

[Other Resources](broken://pages/4FxT5JskPorKo2h9zH0x)


# Indicio FAQ's

<details>

<summary>What is Indicio Proven?</summary>

Indicio Proven provides comprehensive Verifiable Credential solutions for rapid, remote onboarding, seamless account access and reusable (with expiration) Know-Your-Customer (KYC) checks. By issuing a biometric template as a Verifiable Credential, institutions have a powerful way to verify liveness without having to store biometric data — and they can implement simple, instant workflows to defeat AI-generated identity fraud.

</details>

<details>

<summary>What are the benefits of using Indicio Proven over traditional authentication methods?</summary>

* Verifiable Credentials can store all kinds of valuable information in a tamper-proof way, as any attempt to alter the information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* Mutual authentication enables you to verify who you share data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is secure — no need for third parties or to store the data in centralized databases to manage authentication.
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Protect your systems from AI deepfakes with Verifiable Credentials that cannot be replicated by A

</details>

<details>

<summary>What is the user experience like with Indicio Proven?</summary>

Users experience a simple workflow that easily navigates the user from beginning to end without confusion. The program is designed to ensure the user can easily access and review all their information and fully understand a request before accepting/denying.

</details>

<details>

<summary>What are the other benefits of Indicio Proven?</summary>

* **Secure Credential Issuance and Data Verification**
  * Enterprises, Governments, and organizations of all sizes can use Indicio Proven to issue and verify tamper-proof credentials for authenticating identities in a secure and privacy-preserving way.
* **Interoperability**
  * Proven provides unmatched interoperability by supporting multiple standards, including AnonCreds, W3C Verifiable Credentials, DIDComm, and emerging standards like SD-JWT and OpenID for Verifiable Credentials (OID4VC).
* **Global Standards**
  * Proven also complies with global data protection standards including eIDAS, EUDI, and industry specific technology standards. Including W3C Verifiable Credentials, Open Badges 3.0 from 1EdTech, and IATA One ID and ICAO DTC for travel
* **Customizable Deployments**
  * Proven is designed for flexibility, offering both a SaaS platform model or allowing deployment via APIs in various environments, including on-premise, cloud-based, or hybrid setups
* **Plug-and-Play Integration**
  * Indicio Proven works seamlessly with the Indicio Network and other decentralized identity ecosystems. It offers pre-built integrations for developers to easily add decentralized identity to their applications.
* **Privacy-First Design**
  * Proven ensures that users maintain control over their data, aligning with principles of self-sovereign identity (SSI). It supports use cases that comply with data privacy regulations.
* **Secure Credential Management**
  * Indicio Proven enables full lifecycle management of credentials, including issuance, revocation, and expiration. Organizations can define policies for credential management, ensuring compliance with industry standards and internal requirements for credential authenticity and validity.
* **Customizable Governance**
  * Users can configure and manage their own trust frameworks, including selecting roots of trust, defining credential schemas, and customizing credential verification logic. This flexibility supports a wide range of use cases, such as identity verification, secure access management, and compliance monitoring
* **Multi-Tenant Support**
  * A single Indicio Proven instance can support multiple clients (tenants) in a single environment. Each organization can then securely manage its own decentralized identity (DID) configurations, verifiable credentials, and trust frameworks without interfering with other tenants, ensuring privacy and data isolation
* **Customization and Configuration**
  * Indicio Proven can be configured by each customer to match specific business needs, such as selecting roots of trust, defining credential schemas, and managing the lifecycle of digital identities and verifiable credentials. This flexibility enables various use cases, from KYC processes to digital access management
* **APIs for external integration**
* **UI for issuance and verification**
* **Customer chat using basic message**

</details>

<details>

<summary>What is a verifiable credential, and why is it important?</summary>

Think of a Verifiable Credential as a container for sharing digital information. An organization — say a passport office — puts your information in this container and ships it to you and sends the shipping manifest, so to speak, to a distributed, blockchain ledger, so that its origin can be recorded and independently checked. You carry this container around on your mobile phone in a digital wallet application. You use biometrics to access it. And you present this container and the information in it (or parts thereof) when your passport or your identity needs to be authenticated.&#x20;

The party authenticating your container checks the shipping manifest to confirm the origin of your credential. Additionally, because the information in the container has been digitally signed at the time it was created and issued, the authenticating party can be certain that the information hasn’t been tampered with. Altering the information would break the digital signatures and the container.&#x20;

You can see all this happening in the diagram below:

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfNv7xbZzksg8OKnle0mDC-3dyli4Ywi6ifYvhqXbVLUsM4D-Qjqg7e_N9AeM9kq1DVC-8UKx6ZK25KDlICCQEmowCScoCMU6lW9VvsC6W1gfJHCR9mf_mAi7zg5gNNGNPuMi2wPw?key=Xj9tSpwIZDrWc7RNao8pbqAX" alt=""><figcaption></figcaption></figure>

<br>

</details>

<details>

<summary>What technologies is Indicio Proven compatible with?</summary>

* Proven is interoperable and compatible with:
  * Current and emerging global protocols, specifications, and standards for decentralized identity.
  * The European Union’s new regulations for digital identity ([eIDAS](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation)) and digital wallets ([EUDI)](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation)

</details>

<details>

<summary>How does Indicio Proven differ from other verifiable credential solutions?</summary>

* Fully decentralized, leveraging open-source technologies like Hyperledger Aries and AnonCreds.
* Designed for cross-network and cross-ledger compatibility, ensuring vendor-agnostic solutions
* Utilizes Zero-Knowledge Proofs (ZKPs) for selective disclosure, ensuring no centralized storage of personal data.
* Enhances user privacy and security by allowing individuals to:
  * Share only the necessary information.
  * Avoid exposing all personal details.
* Tailored for industries requiring high-trust digital credentials,&#x20;
  * government, enterprise, and travel sectors.&#x20;
* Proven enables the creation of Trusted Digital Ecosystems for immediately actionable data.
* Cloud-agnostic and supports multiple networks,&#x20;
* Allows organizations to build, deploy, scale, and manage Verifiable Credential ecosystems without being tied to a specific cloud provider.
* Built on open standards, with community-driven development, ensuring transparency and continuous improvement.&#x20;
* Open-source foundation fosters innovation and collaboration within the decentralized identity community.

</details>

<details>

<summary>How does Indicio Proven work?</summary>

Proven™ is a complete solution for building decentralized identity using Verifiable Credentials to authenticate and create immediately actionable data

Indicio Proven ™ is also

* Easy to integrate into existing systems
* Built on interoperable components, open source code, and open standards
* Fully customizable — deploy how you choose; customers own their solutions; there is no vendor lock-in

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXfxBHxhLPvHodiTIHuO7I0rCwn0jr5v-avHbFrm2VK4sL2-JLh8ZIuX3tAbJFphE0xpXwQObM3XOfzKm9Noz3C1JdDt86V4_C4rtk4AU7zl9XZ0KqNJyl5jBzbzj3tbQk3fpaBBtQ?key=Xj9tSpwIZDrWc7RNao8pbqAX" alt=""><figcaption></figcaption></figure>

</details>

<details>

<summary>Who can use Indicio Proven?</summary>

The short answer is everyone, our current pricing model is catered to enterprise and government sized organizations, but we are adding more tiers of Proven that will soon be more SMB friendly.

</details>

<details>

<summary>How does Indicio Proven improve user privacy?</summary>

Indicio Proven will only share information that is approved by the owner. If they did not approve the credential to be shared it will not be shared. Since the information is not stored directly in the digital wallet but coded into the blockchain, it is nearly impossible for anyone to hack into the system and gain access to the private information.&#x20;

The Personal identity information (PII) is stored in the credential in the wallet on the user's device. It is very important to understand that no PII is ever posted to the ledger. What is posted publicly to the ledger is basically a template for what the credential should look like, as well as information that the verifier needs to verify the credential, but none of the values of the credential are on the ledger.

</details>

<details>

<summary>What digital wallets are compatible with Indicio Proven?</summary>

Proven is compatible with all wallets built using Hyperledger Aries

</details>

<details>

<summary>Is Indicio Proven compliant with industry standards?</summary>

Yes, Indicio is compliant with both US and EU standards.

</details>

<details>

<summary>How is Indicio Proven implemented in an organization?</summary>

Indicio will work with your technical team to learn about your needs and the best path to a fast and effective integration.. We offer a variety of levels of technical support to ensure that we can meet your team's deadlines and goals.

</details>

<details>

<summary>Can Indicio Proven integrate with existing identity management systems?</summary>

Yes, Indicio Proven is designed for seamless integration with any existing digital identity provider or data source. It complements your current systems without requiring major changes or replacements, making it easy to adopt decentralized identity solutions.

</details>

<details>

<summary>Does Indicio Proven require specialized infrastructure?</summary>

No, Indicio Proven includes all necessary components—software, network, and digital wallet—eliminating the need for any specialized infrastructure. It is hardware-agnostic and can operate with your existing devices and systems.

</details>

<details>

<summary>How does Indicio Proven enhance security compared to traditional systems?</summary>

Indicio Proven leverages decentralized identity, meaning personal information is stored and controlled by the individual rather than a central database. This significantly reduces the risk of hacking or data breaches. Additionally, identity verification is strengthened by binding biometric data to biographical information, helping to prevent fraud and impersonation.

</details>

<details>

<summary>Is training required for users and administrators?</summary>

Administrators will receive hands-on training during the implementation process. This includes access to tutorial documents that are shared as a continually reference to the process to ensure easy to learn programming.&#x20;

Users will not need special training because of the simple, intuitive interface.

</details>

<details>

<summary>Can Indicio Proven support multiple credentials for a single user?</summary>

Yes, There is no limit to the number of credentials that a user may have in their wallet.

</details>

<details>

<summary>What support is available for organizations implementing Indicio Proven?</summary>

Indicio is part of the implementation process from step one to finish. We have a dedicated team that will work with you along each step advising of best practices and helping you work through any questions. Each project has a dedicated project manager who will have regular check ins and updates. Post launch our team will remain available to help tackle any unforeseen issues.

</details>

<details>

<summary>What happens if a user loses their phone with their credential?</summary>

When you lose your phone, one item of concern is whether your credentials and other data are safe.&#x20;

There are several layers of protection in place:

1. Your phone should be protected by a passcode and potentially your biometrics, such as a face image or your fingerprint.&#x20;
2. Our wallet applications also include a pin code (which should not be the same as your phone pin) and use the same biometrics as your device (so a hacker would have to beat the biometrics at least twice).&#x20;
3. For truly sensitive operations, the workflows involved in presenting this data (in order to impersonate you) can be paired with a liveness check and biometric comparison between the face on an identity credential and one captured by the phone’s camera.

When a device is lost, you can revoke the credentials that are stored in that wallet, making them useless even if the device and wallet are compromised. This is similar to how, if you lose a credit or debit card, you go to the card provider and ask them to turn it off.

The restoration experience, at the most basic level, is to go to the issuers and have the credentials reissued. This is what most credential issuers do today.

</details>

<details>

<summary>What happens if a thief steals a phone with an Indicio Proven credential? Would they gain access to the primary user's systems?</summary>

Biometric binding and liveness checks ensure that it is you who is using your phone and digital wallet app. The Verifiable Credentials stored on the phone can be revoked, removing them from the stolen device, and quickly reissued to your new device.

</details>

<details>

<summary>How does Indicio Proven use a ledger (and what is stored on the ledger)?</summary>

**The ledger offers four important elements when building a decentralized identity solution, these being:**

1. Immutability: The data cannot be changed — by anyone.
2. Tamper resistance: A distributed ledger makes it very difficult for a malicious actor to break in and change material.
3. High availability: If one node on the network goes down for any reason, there are plenty of others to receive data from.
4. Geopolitical and infrastructure diversity: By hosting the ledger on servers located in multiple geographic areas and by diverse organizations, network resilience to technical problems is maximized — and this contributes to high availability.

The following information — and only this information — is, typically, stored on the ledger:<br>

1. **DIDs for an Organization, Company, or Institution**
   1. These are used to verify credentials from a particular issuer; the endpoint allows you to communicate with that issuer.
2. **Credential Schemas**
   1. A credential contains information and Schemas define the different fields containing that information.
3. **Credential Definitions**
   1. These are specific to the use of the [AnonCreds](https://www.hyperledger.org/use/anoncreds) credential format with [Hyperledger Indy](https://www.hyperledger.org/use/hyperledger-indy). Credential Definitions link a cryptographic key to each of the attributes in a Credential Schema. This allows a holder of a credential to share information in privacy-preserving ways, such as through selective disclosure (only a single attribute is shared) or a predicate proof (an attribute value can be numerically assessed without the actual value being disclosed, such as >21 or <21 for purchasing items that have legal age requirements).
4. **Revocation Registry Accumulators**&#x20;
   1. This provides a way of signaling which credentials are valid by keeping track of which credentials have been revoked and which have not been revoked. The revocation registry accumulator is a way of proving your credential is valid.

<br>

</details>

<details>

<summary>What’s not on the ledger?</summary>

1. Personally Identifying Information (PII)
   1. No PII or personal data of any kind is recorded on the ledger.
2. Credential Issuance
   1. No information about the issuance of any individual credential is recorded on the ledger.
3. The Verifiable Credential
   1. Verifiable credentials are not written to or stored on the ledger in any context.

One of the most powerful features of decentralized identity is that you can create an ecosystem of  millions of people using millions of credentials with only three or four writes to the ledger: the credential type, the schema, the credential definition, the issuer DID, and the revocation registry<br>

</details>

<details>

<summary>How do we ensure no personal identifying information ends up on the ledger?</summary>

Distributed ledger networks prescribe rules for who can write and what can be written (no PII!) to a ledger and these rules are enforceable through legal agreement. These governance rules typically require that writes to a ledger must be approved by a Transaction Endorser.

Some great blogs about the topic are: [What does the ledger do? ](https://indicio.tech/blog/what-does-the-ledger-do-anyway/) And[ Why a ledger?](https://indicio.tech/blog/why-a-ledger/)

</details>

<details>

<summary>What server/agents are needed for Indicio Proven?</summary>

The server recommended may change as technology evolves but right now we recommend&#x20;

* 50 GB Hard drive SSD
* AWS Type: c6i.larg

</details>

<details>

<summary>What are the costs involved in implementing Indicio Proven?</summary>

The costs can vary based on the use case you are looking to cover and what you may already have in place. Such as cloud based or on premises hosting, do you have tech that Proven needs to integrate with, how many users are expected, etc.

</details>

<details>

<summary>What if a smartphone isn’t available for login?</summary>

While a smart phone is required to access Proven mobile, there are some use cases where the service provider can have kiosks on site that the customer can use that will allow them to take advantage of the product and process.

</details>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Glossary

Get clear, concise definitions of key terms in decentralized identity and verifiable credentials with the Indicio Glossary—your go-to resource for understanding the Proven platform and ecosystem.

#### **AnonCreds**

A privacy-preserving credential format that enables selective disclosure, allowing users to share only the information needed without revealing everything on a credential.

#### **Decentralized Ecosystem Governance (DEGov)**

A governance model—based on a DIF standard—that defines machine-readable rules and policies for credential ecosystems, allowing systems to self-update without third-party arbitration; supported by Indicio Proven's “Governance Wizard.”

#### **Digital Travel Credential**

An ICAO-standardized digital representation of a traveler’s passport that can be securely stored and presented via a mobile device.

#### **Digital Wallet**

An application that stores, manages, and presents verifiable credentials securely, typically installed on a mobile device.

#### **DIDComm**

A secure messaging protocol that allows identity agents (wallets, issuers, verifiers, mediators) to communicate directly and privately using DIDs.

#### **Distributed Ledger**

A decentralized database maintained by a network of nodes, ensuring transparency, immutability, and shared control over data.

#### **Distributed Ledger Network**

A professionally managed network of distributed ledgers, such as the Indicio Network, used for anchoring credentials and public identifiers (DIDs).

#### **eIDAS**

An EU regulation that governs electronic identification and trust services, enabling cross-border digital identity recognition across member states.

#### **eUDI (European Unique Digital Identity)**

A standardized digital identity framework under eIDAS 2.0 that includes support for verifiable credentials and wallet-based identity.

#### **Holder**

The individual or organization that receives, controls, and presents verifiable credentials using a secure wallet.

#### **Holdr+**

A robust and scalable mobile wallet developed by Indicio to enable secure credential storage, messaging, and presentation in decentralized systems.

#### **Hyperledger Indy**

An open-source, purpose-built distributed ledger designed for decentralized identity, enabling secure, privacy-respecting credential exchange.

#### **Issuer**

The trusted party or organization that creates and issues verifiable credentials to users (Holders).

#### **JSON-LD (JavaScript Object Notation for Linked Data)**

A machine-readable data format used for expressing credentials and DIDs in a structured, interoperable way.

#### **Mediator**

A service that supports mobile wallets in maintaining secure communication with issuers and verifiers when the wallet is offline or intermittently connected.

#### **Mobile Driver’s Licence (mDL)**

A digital version of a government-issued driver's license that can be presented and verified securely using a mobile device.

#### **Open Badges**

Digital credentials designed for education and training that use open standards to verify achievements and skills.

#### **Open Source**

Software with publicly available source code, allowing anyone to inspect, modify, and contribute to its development.

#### **Open Standards**

Publicly available specifications (like W3C or DIF standards) that ensure interoperability and avoid vendor lock-in.

#### **OpenID**

A widely adopted authentication protocol that enables users to log in and share identity information securely across services.

#### **OpenID4VCI (OpenID for Verifiable Credential Issuance)**

A protocol that standardizes how verifiable credentials are issued using OpenID flows.

#### **OpenID4VP (OpenID for Verifiable Presentations)**

A protocol for presenting verifiable credentials in a secure, privacy-respecting way using OpenID-based interactions.

#### **Protocol**

A set of technical rules that govern how data is transmitted and understood between systems—such as how credentials are issued, verified, or messaged.

#### **SD-JWT (Selective Disclosure JSON Web Token)**

A credential format that enables selective disclosure and cryptographic privacy using JWT technology.

#### **Verifiable Credential Schema**

A flexible, reusable template that defines the structure and data fields for a specific type of verifiable credential.

#### **Verifier**

The party or system that checks the authenticity and integrity of a presented credential using established trust frameworks and cryptographic proofs.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Technology

Dive deeper into key concepts and technologies behind decentralized identity with in-depth explanations and advanced insights on key technologies and concepts for secure, privacy-preserving solutions.

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/Ud6RmahqGrsq6EZgGLMB" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/Ud6RmahqGrsq6EZgGLMB)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/cj7sJQRhfEkqwe6CU3T0" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/cj7sJQRhfEkqwe6CU3T0)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/2J9nlQegWkvV1C0Cf3oH" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/2J9nlQegWkvV1C0Cf3oH)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/LX0ebMRHSI8KJfkja5sP" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/LX0ebMRHSI8KJfkja5sP)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/oULiYKCaV5XCir9C5Z5t" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/oULiYKCaV5XCir9C5Z5t)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/eNuaxcLUMjsjoXiSLSPe" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/eNuaxcLUMjsjoXiSLSPe)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/TaF6NMXIgBpAfRkfZNzU" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/TaF6NMXIgBpAfRkfZNzU)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/rrLFCcQSfM8qZ6LbBrn2" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/rrLFCcQSfM8qZ6LbBrn2)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/reZACM1WMgkEnsRbJdoz" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/reZACM1WMgkEnsRbJdoz)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/AVZa7KNSsIDgQr0iRZuh" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/AVZa7KNSsIDgQr0iRZuh)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/z86sUHUkn2EB8Mn2UcLn" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/z86sUHUkn2EB8Mn2UcLn)
{% endcontent-ref %}

{% content-ref url="/spaces/YBAM94M94UfHSNmBoAFa/pages/QIcP3TLViAkK77N1HQnf" %}
[Broken mention](broken://spaces/YBAM94M94UfHSNmBoAFa/pages/QIcP3TLViAkK77N1HQnf)
{% endcontent-ref %}


# Agent

In the context of decentralized identity and verifiable credentials, an "agent" refers to the software that acts on behalf of a person or organization or device to manage the issuance, holding, and verifying of digital verifiable credentials in secure and trusted interactions.&#x20;

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Credential Types

Indicio uses a variety of credential types, exchanges, and representations to provide the best solution to fit our customer's needs.

The technical specification or structure that defines how credential data is encoded, presented, and exchanged. Credential formats ensure that the data within a verifiable credential can be securely issued, shared, and verified across different systems. Key aspects of a credential format include how the data is digitally signed, the cryptographic techniques used, and how privacy-preserving features like selective disclosure or zero-knowledge proofs are implemented.

Indicio provides robust support for a variety of credential formats, enabling organizations to choose the format that best aligns with their use case and interoperability requirements including:

* **JSON-LD (Linked Data):** A format that integrates with semantic web technologies, allowing credentials to include rich metadata and context for better interoperability.
* **SD-JWT (Selective Disclosure JWT):** A JWT-based format with added support for selective disclosure, enabling granular control over what information is shared from a credential.
* **mDL:** Supports proximity based sharing of driver license.
* **Open Badges 3.0:** Supports educational achievements.
* **DTC for digital passports (ICAO DTC Type 1 compliant):** A digital travel credential derived from the data inside a user's passport to be easily held and shared before traveling.
* **DTA for digital visas:** Digital Travel Authorization that is easily digitized and shared before the traveler arrives and goes through customs or security.
* **DIF Presentation Exchange:** a codified presentation definition format for verifiers to use to articulate proof requirements.
* **W3C Verifiable Credential standards compliant:** A set of standards developed by the World Wide Web Consortium to enable the issuance, sharing, and verifiaction of digital credentials in a privacy respecting manner.
* **AnonCreds:** A privacy-preserving format that supports privacy-preserving features such as selective disclosure, predicate proofs, and zero-knowledge proofs, allowing users to share only the necessary information from a credential without revealing the entire dataset. JSON Web Tokens (JWT): A widely-used format based on JSON that is compact and easy to process, suitable for web-based applications and lightweight implementations.
* **BBS+: A** secure, multi-message digital signature protocol, supporting proving knowledge of a signature.

By offering this flexibility, Indicio empowers organizations to build decentralized identity solutions that are secure, private, and interoperable across diverse systems and industries.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# DIDComm

DIDComm — short for Decentralized Identifier Communication — provides a method for creating a direct, secure line of communication between the owners of Decentralized Identifiers (DIDs). But DIDComm is more than just a mechanism for an individual message, it’s a framework for safe, structured interactions built on decentralization technology.

DIDComm creates an encrypted communications channel for issuing, presenting, and verifying a verifiable credential. It provides maximal security for these processes by allowing each party to mutually authenticate each other before sharing information. It allows for rich, consent-based communication that facilitates the creations of trusted relationships between passengers and airlines and other partners. This is the foundation for a new level of customer personalization that no other exchange protocol provides

<figure><img src="/files/o1CwfCMegMdb8sVcBBbm" alt=""><figcaption></figcaption></figure>

In this framework each holder of a DID agrees to accept a connection and enables communication along that channel, whether it be through a website, email, mobile push notifications, QR codes, or a text message. These connections benefit from the built-in features of DIDComm technology, including message encryption, mutual authentication, and message routing.

While some interactions happen entirely within DIDComm protocol messages, such as identity verification and connection creation, DIDComm protocols can also be used to facilitate interactions within other protocols. For example, a video conference call or a phone call could be coordinated using DIDComm protocols to make use of the trust provided by the DIDComm relationship.

A key use for DIDComm is in the communication of verifiable credentials. In the annotated stack diagram from Trust Over IP (below) we can see the role that DIDComm could play in its architectural design.

<figure><img src="/files/IP8Y9sQtd6SjDqiHJDGA" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# DID Methods

\#DID Methods

The DID method specifies how DIDs and DID documents are created, resolved, updated, and deactivated. We recommend and use DID methods that allow for communication endpoints even if the use case doesn’t require them. Their presence will make innovation easier in the future. We also, generally, recommend and use DID methods that provide high durability through writing to a distributed ledger. Proven supports multiple DID methods, which promotes interoperability with multiple DID-based solutions.

* did:sov
* did:key
* did:peer
* did:web (resolution only)
* DID resolution via Universal Resolver

#### DID methods (server registration or creation)

* did:sod
* did:key
* did:jwk
* did:indy

#### DID methods (server resolution of external DIDs)

* did:sov
* did:key
* did:jwk
* did:indy

#### DID methods (server registration or creation)

* did:key
* did:peer1
* did:peer2

#### DID methods (server resolution of external DIDs)

* did:key
* did:peer1
* did:peer2
* did:sov
* did:indy
* did:jwk

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Governance

Indicio’s solution is unmatched in the market, offering a truly decentralized approach that eliminates the need for a centralized trust registry. It implements the DIF Credential Trust Establishment specification, setting a new standard for governance automation in verifiable credential ecosystems.\
This innovative approach empowers ecosystems to grow efficiently, securely, and without reliance on centralized third-party services, ensuring a frictionless flow of trusted information.

Indicio uses machine-readable governance to simplify and automate ecosystem rules. Machine-readable governance encodes human-made governance decisions and rules into a machine-readable format, enabling automated implementation. These rules often include trust lists of approved credential issuers and verifiers, streamlining ecosystem management. This is calle

* **DEGov:** A standard for Machine-Readable Governance from the Decentralized Identity Foundation (DIF) standard, integrates traditional governance (e.g., system control) with technical policies, rules, and procedures specific to verifiable credential ecosystems. Its data format is compatible with ToIP Trust Registries, ensuring broad interoperability.

## Governance Editor & Interpreter

Indicio’s governance solution provides an unparalleled framework for managing decentralized ecosystems with two key components:

1. **Governance Editor:** A user-friendly interface designed to simplify and accelerate the creation of governance files, making it easy to encode governance rules in machine-readable formats.
2. **Governance Interpreter:** Enables agents to interpret governance files and assess whether actions—such as issuing or verifying a credential—comply with the established governance rules in a decentralized ecosystem.

By streamlining the creation and enforcement of governance rules, Indicio empowers organizations to implement robust governance quickly and efficiently. No other company offers a comparable solution, positioning Indicio as the emerging standard for governance in the decentralized identity space.

Governance Wizard: An enhancement to DEGov in Indicio Proven with a user-friendly interface enabling seamless creation and updates of governance files.

**Key Benefits**

* **Simplified Implementation:** Governance rules are easily linked to ecosystem actions, such as issuing and verifying credentials, fostering ecosystem growth.
* **Real-Time Updates:** Rapid changes can be propagated across the ecosystem or jurisdiction, eliminating delays caused by third-party updates.
* **Error-Free Coordination:** Rules and permissions can be choreographed efficiently and accurately, reducing the potential for miscommunication or errors.
* **Hierarchical Rules:** Governance rules can be structured hierarchically, such as global > national > local, for flexibility and scalability.
* **Offline Functionality:** Cached files ensure governance rules remain accessible even when offline.
* **Portable Trust Lists:** Trust lists are portable, eliminating risks of centralized registries imposing fees or slowing down information flow.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Interoperability

Life online would be impossible without interoperability. Without TCP/IP (Transmission Control Protocol/Internet Protocol), a shared set of standards and rules allowing computers to communicate with each other, there would be no internet. Without HTML—Hypertext Markup Language— there would be no World Wide Web. And, as you read this— almost certainly in HTML on the WWW through TCP/IP—a new set of protocols are being built and adopted which aim to create interoperability around new technologies for digital Identity, data sharing, verification, and trust.

What does it mean to have a digital identity? The inter- net and the web evolved with effective ways to identify computers and websites but less so the people using them. Arguably, email addresses became the first way to establish human identity. They are the key building block for creating and accessing user accounts, often as login credentials, in tandem with passwords.

Whether as an email address leased from an email pro- vider, or as a user account brokered by an email account, these digital identities are not owned by us. They can be revoked. Because they are easy to create, they often require additional personal information to be verifiable. All this real-world and virtual data is stored by the “identity leasing agencies”—the myriad companies and services we use online through email and user accounts. This includes the metadata we generate by being online, which is aggre- gated, packaged, and sold on to other parties for undisclosed purposes, but which frequently include marketing and advertising. We must give prior consent to our data being used in this way in order to lease our digital identities. \
\
While all of this is presented as either mostly benign or mildly annoying, and unavoidable—a trade-off for the plenitude of goods and efficiencies online—the system isdesigned to fail. Emails are easy to find or guess. Passwords, if easy to remember, are easy to hack. People are easily “phished”into giving up personally-identifying information that can be used to replicate their identity online. Identity fraud is endemic to this system. \
\
Data breaches are frequent and expensive, a combination of the cost of lost data, the cost of being fined for losing the data, the cost of meeting increasingly stringent data privacy mandates, the cost of implementing better security, and the reputational cost of lost trust from losing all your customer data. In this system of centralized databases, each identity can be a single point of failure for the entire system. \
\
Federated identity, once thought of as a solution, replicates the under- lying problem with higher stakes: if something goes wrong, you lose access to everything tied to your digital identity. New, decentralized identity technologies mean that we can completely overhaul this system. We can establish digital uniqueness independent of any third party. We can generate the kind of verification that enables trust without storing personal information on third-party databases.

Verifiable credentials provide the authentication needed to establish trust in each other and in the data we need to share. They mitigate the compliance burden; they make digital life simpler. Imagine being able to log into any site or service by scanning a QR code. Imagine a world where you can forget your passwords...forever. With the bureaucracy of verification removed and the barrier to trust lifted, the transformation of the digital economy through trusted digital ecosystems can begin. But only if verifiable credentials are interoperable.

## Seven aspects of interoperability

All systems are the result of design and technical choices. In designing for interoperability, the following technical aspects of a decentralized identity system must align. Note that some elements in this list (DID methods, some credential formats, etc.) require dependent infrastructure such as a ledger or web-hosted assets. Each element of dependent infrastructure in an interaction must be accessible and acceptable to each party. The scope of interoperability will likely change over time:

Convergence in one area can effectively eliminate its potential for incompatibility, while new technology may introduce new areas of incompatibility. Consider this list as a snapshot in time, subject to adjustment as circumstances require.

1. **DID methods**&#x20;

The fully interoperable stack must be able to resolve the DIDs used by all involved parties. With the number of DID methods available, this is no small feat. The Universal Resolver can solve some of this problem, but only with careful management to avoid relying on the trust of an externally managed system. To trust the results of any given Universal Resolver resolution, one must trust that the code operates properly. To trust the results of a Universal Resolver run by another party, you must trust the other party to have both sufficient security to prevent outside manipulation and to not manipulate the results themselves. This trust is possible but it is not automatic.

2. **Content encryption key types**

Information between parties is usually encrypted; there- fore, each party must use compatible encryption keys and a compatible encryption scheme to allow decryption by the other party. Encryption at this level is used to encrypt protocol messaging and credential communication back and forth between parties. &#x20;

3. **Communication protocols**&#x20;

The methods of communication used between issuers, holders, and verifiers must be common between the parties in any given interaction. Different protocols can be used in each exchange as appropriate, but the combination of protocols must form a continuous chain of communication extending to all parties. Examples of these protocols are CHAPI, OpenID Connect, and DIDComm. &#x20;

4. **Credential format and signature types**&#x20;

The credential format used must be acceptable to all parties. Credential formats include JSON-LD (as depicted in the W3C Verifiable Credential Data Model specification), and JSON-based formats including JWT and AnonCreds. Credentials must also use signature types acceptable to all parties. Signature types include CL-signatures, BBS+, and Linked Data Signatures. Credential revocation methods must also be understood and testable by all parties.

5. **Credential access / storage (wallet)**

This may or may not be an issue, depending on how credentials are transferred from one party to another. If transferred directly to and from storage and not via another protocol, the data access needs to be compatible. &#x20;

6. **Credential protocols and coordination formats**&#x20;

The parties involved in exchanging credentials must communicate with each other about the credential. This includes communicating about the type and content of the credential before it is transferred. Even with identical credential formats, these protocols must be compatible to enable a transaction. Examples of these protocols and formats are the Aries Issue Credential and Present Proof protocols, The W3C Verifiable Presentation Request Specification, and the DIF Credential Manifest and Presentation Exchange formats. &#x20;

7. **Compatible governance / trust**&#x20;

With digital credentials, the issue of trust is critical but often ignored. Which issuer is the verifier willing to trust? This answer is solved through governance, machine-readable governance, and trust registries.

***

### **Examples**

* **Aries Interop Profile (AIP) 1.0:** This is a leading interoperability standard that is used to ensure a wide range of interoperability between verifiable credential ecosystems. This standard makes it possible for the software components of different ecosystems to “talk” to each other in a way they understand and exchange information.
* **AIP 2.0 Significant coverage**
* **OID4VCI**
* **OID4VP**
* **DIF Credential Trust Establishment V1.0**
* **eIDAS 2.0 compatibility (H2 2024)**
* **ToIP Machine Readable Governance**
* **OWF Credo**
* **Aries Cloud Agent Python (ACA-Py) V0.9.0**

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Mediator

Mediation provides a secure, encrypted, fixed end point for message relay to mobile devices.

This software enables mobile devices to securely and reliably connect with credential issuers and verifiers using DIDComm. This component is not required for OID4VC-only interactions. Since mobile devices lack fixed IP addresses, our Cloud Scale Mediator Agent ensures seamless management of tens of thousands of simultaneous active users.&#x20;

Keys are stored following industry best practices, and all messages are encrypted both in transit and at rest. The mediator cannot access the contents of messages exchanged between clients.

It automatically scales with traffic demand and has been rigorously tested to handle exceptionally high volumes.

&#x20;Indicio Proven includes a cloud-scale mediator to support customer application at scale.

<figure><img src="/files/TkkT83U6HUkCjSZNlDfP" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# OpenID

Open ID for Verifiable Credentials (OID4VC) Protocol that allows claims to be presented in the form of a verifiable credential on top of Oauth 2.0. OID4VC is a popular format in Europe that we provide to customers who need the capacity to interact with these systems. However, we note that this format is limited and does not provide the capacities that provide important benefits to financial service use cases due to the absence of secure, bidirectional communication (mutual authentication, notification and confirmation, security). Issuing and verifying credentials (such as SD-JWTs) via OID4VC in addition to using DIDComm broadens compatibility and increases flexibility when working with partners.

The OpenID communication [protocols](https://openid.net/sg/openid4vc/), consisting of OpenID4VCI (Verifiable Credential Issuance) and OpenID4VP (Verifiable Credential Presentation), are required by the  European Digital Identity Architecture and Reference Framework and are included in the EUDI specification.&#x20;

These protocols enable verifiable digital identity credentials to be issued to a digital wallet and then be presented from that digital wallet to a relying party for verification. Through these mechanisms,  European citizens can use digital identity credentials to access government services, prove their age, hold mobile driver’s licenses, and cross borders.

In addition to our ongoing support for selective disclosure in AnonCreds, Indicio now also supports the new SD JWT (Selective Disclosure JWT) credential format. Selective disclosure is a feature that allows credential holders to present specific information in a credential for verification (instead of having to disclose all the information in the credential at once). This feature is key to meeting the European Union’s [requirements](https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/Security+and+Privacy) for data minimization and privacy in eIDAS.

<br>

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Protocols


# Schemas

Schemas define credential attribute names and attribute types. Indicio Proven uses standards based credential schemas, such as ICAO-DTC, mDL, etc. or custom schemas. This acts as a sort of blueprint of what the verified credential will contain. The scheme outlines the basics of what data is required to truely identify the person being presented via VC.&#x20;

For example: the scheme will require Name, DOB, Issue date of the ID used to make the credential

Any information that can be conveyed through a credential schema is now verifiable, along with the source of that information. Trust lists for issuers and complex information flows and approvals are managed by machine-readable governance files directly sent to the agent software of each participant in the credential ecosystem.

You can learn more about credential schemes and see examples on the [DIF. ](https://identity.foundation/credential-schemas/)

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Secure Storage

#### Aries Askar

Indicio integrates Aries Askar across its suite of solutions, leveraging its compatibility with different database backends to provide flexibility for customers with unique storage needs. This is the foundational secure storage of Indicio's agents and mediators, ensuring the protection and accessibility of credentials, schemas, and cryptographic keys.

Aries Askar is a part of the Hyperledger Aries ecosystem, designed to handle secure storage and cryptographic operations essential for decentralized identity frameworks. Askar efficiently handles wallet operations like key generation, signing, and verification while maintaining the highest security standards.

It supports secure DIDComm message exchange, credential issuance, and verification, enabling seamless and trusted interactions. Scalable and robust, Aries Askar ensures Indicio's solutions meet the demands of enterprise and ecosystem-level applications.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Standards and Specifications

Indicio Proven is built to support an array of leading global specifications and open standards to ensure maximum interoperability.

<figure><img src="/files/cnEujGHfBxkjikLi5CBw" alt=""><figcaption></figcaption></figure>

* 1 Ed Tech [Open Badges](https://www.1edtech.org/standards/open-badges) 3.0 Specification.
* Internet Engineering Task Force [SD-JWT and SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) specifications.
* LF Decentralized Trust [Indy Working Group ](https://lf-hyperledger.atlassian.net/wiki/spaces/indy/overview)Node, Plenum, Cryptography.
* International Civil Aviation Organization (ICAO) [Digital Travel Credential](https://www.icao.int/Security/FAL/TRIP/PublishingImages/Pages/Publications/Guiding%20core%20principles%20for%20the%20development%20of%20a%20Digital%20Travel%20Credential%20%20%28DTC%29.PDF) (DTC) standard.
* LF Decentralized Trust [Aries Working Group](https://lf-hyperledger.atlassian.net/wiki/spaces/ARIES/overview).
* LF Decentralized Trust.
* [Membership Marketing Committee](https://www.hyperledger.org/).
* LF Decentralized Trust [Identity Implementers Working Group](https://lf-hyperledger.atlassian.net/wiki/spaces/HYP/overview?mode=global).
* [Open Wallet Foundation](https://github.com/openwallet-foundation/bifold-wallet) Aries Cloud Agent Python agents (ACA-Py) Bifold Wallet (built on Credo - formerly Aries Framework Javascript).
* [OpenID for Verifiable Credentials](https://openid.net/sg/openid4vc/) (OID4VC) Communication protocol.
* Decentralized Identity Foundation [DIDComm Working Group](https://identity.foundation/didcomm-messaging/spec/) DIDComm.
* Decentralized Identity Foundation [Trust Establishment Working Group](https://identity.foundation/trust-establishment/) Decentralized Ecosystem Governance.
* Trust Over IP Foundation [Utility Foundry Working Group](https://lf-toip.atlassian.net/wiki/spaces/HOME/overview?mode=global).
* World wide Web Consortium, [Verifiable Credentials model and DID Specifications](https://www.w3.org/TR/vc-data-model-2.0/).
* EU Digital Identity Wallet (EUDI).\
  [EU Digital Identity Wallet Pilot implementation](https://digital-strategy.ec.europa.eu/en/policies/eudi-wallet-implementation).

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Verifiable Data Registry (VDR)

Indicio supports multi-ledger functionality and capabilities based on the needs of the customer.

Indicio uses Hyperledger Indy, private or public networks,  or other ledgers when requested. Support for ledgerless operation is also offered. Use of a ledger provides the availability, durability, and redundancy necessary to support a robust identity ecosystem.

While we support alternative non-ledger-based solutions (see DID:WEBVH below), we highly recommend the robust Hyperledger Indy identity ledger.

* **Hyperledger Indy Networks:** Hyperledger Indy is the leading open-source code for distributed ledgers. A distributed ledger provides a way to find credential issuers (through public DIDs) and perform the cryptography necessary to verify credentials. Using a distributed ledger provides a high level of cryptographic trust, information security, and network resilience.

Indicio Proven is also compatible with

* Sovrin Ledgers
* CANdy
* Lissi
* Ethereum
* (Non-Ledger) KERI
* **Indicio Network:** Indicio’s public-permissioned ledgers are built on Hyperledger Indy to provide a versatile platform for designing, testing, demonstrating, launching, and supporting decentralized identity solutions. With nodes spanning five continents and a global consortium of over 20 members, our team brings unparalleled expertise in managing Indy networks.

**Value:**

* **Enterprise-grade:** They are professionally-supported to deliver mission-critical deployments.
* **Energy efficient:** Ledgers for identity do not require proof-of-work and are low energy in operation (a write to the ledger is equivalent to a web search in energy consumption) with guaranteed 99.97% uptime.
* **Network monitoring:** Indicio has developed a range of network support tools to monitor network performance.
* **Easy to use:** A transaction wizard simplifies writing transactions to the ledger.
* **Easy to run:** Indicio NoDeTM (Node on Demand) is a cloud product that simplifies creating and setting up network nodes.
* **Private network opportunities:** Indicio has the capacity to develop and run private networks for any organization.

Our Enterprise-grade distributed ledger network is based on Hyperledger Indy and is composed of four professionally-managed networks:

* **Indicio TestNet:** A platform for proof-of-concept for development and testing, supported by Indicio’s engineering team.
* **Indicio DemoNet:** A platform to showcase demonstrations.
* **Indicio MainNet:** A platform to run enterprise-grade, mission-critical identity products and services with full, professional support.
* **Indicio TempNet Service:** A network for destructively testing performance, scaling, and security to discover weaknesses.

## DID:WEBVH:

DID:WEBVH stands for DID:WEB with Verifiable History. It is an evolution of the DID:WEB method, designed to address some of its limitations by incorporating a verifiable history component, enhancing trust, and ensuring the integrity of decentralized identity systems. The DID:WEB method enables organizations to create decentralized identifiers (DIDs) that are resolvable using standard web infrastructure. These identifiers are hosted on web servers and can be accessed via HTTP(S), making them straightforward to implement and compatible with existing internet technologies.

Indicio supports DID:WEBVH as part of its commitment to offering flexible and interoperable decentralized identity solutions. By integrating DID:WEBVH, Indicio allows organizations to benefit from:

* Plug-and-play root-of-trust options.
* Enhanced security and transparency for DID management.
* Compatibility with both centralized and decentralized ecosystems.

## Key Features for DID:WEBVH

1. **Immutable Records:** All changes to the DID Document are logged and cryptographically secured, preventing unauthorized alterations.
2. **Enhanced Trust:** By providing a verifiable history, DID:WEBVH mitigates reliance on central web servers and enhances the trustworthiness of DID:WEB implementations.
3. **Interoperability:** It retains compatibility with existing web technologies while adding layers of decentralized trust.
4. **Scalability:** Useful for organizations that need a practical, scalable DID method but require enhanced accountability and transparency.

<figure><img src="/files/yaRvybxuMO1Qc2HAWLHy" alt="" width="244"><figcaption></figcaption></figure>


# Introduction

#### The global leader in verifiable digital identity solutions, trusted by enterprises and governments worldwide to streamline operations, eliminate errors, and prevent fraud. <a href="#the-global-leader-in-verifiable-digital-identity-solutions-trusted-by-enterprises-and-governments-wo" id="the-global-leader-in-verifiable-digital-identity-solutions-trusted-by-enterprises-and-governments-wo"></a>

Indicio’s Proven APIs offer a simple, effective way to integrate the ability to issue, hold, share, and verify decentralized Verifiable Credentials for proving identity information directly into your existing systems. Built on open-source technology, Indicio’s solutions are interoperable with W3C standards, EUDI, SD-JWTs, AnonCreds, DIDComm, and more, ensuring that your systems will work around the globe.​Functionality includes:

* Completely decentralized — eliminate your reliance on centralized databases for sensitive user identity information
* Hosting options — Build on premises, in the cloud, or managed by Indicio, our team offers maximum flexibility
* Pre-set use cases and schemas — Build your own custom solution or choose from one of Indicio’s templates to get started fast
* Automated Governance — quickly create the rules for your system and implement them system wide with a few clicks
* Offline identity verification — Use your credentials where and when you need them, even if you or the verifier can’t connect to the internet

If you want to learn more about Indicio or discuss the information contained please complete the following form to schedule time with a member of our team.

### ​[Schedule time with our team now](https://indicio.tech/contact/) <a href="#schedule-time-with-our-team-now" id="schedule-time-with-our-team-now"></a>

### ​ <a href="#schedule-time-with-our-team-now" id="schedule-time-with-our-team-now"></a>

​​​​​![](https://images.gitbook.com/__img/dpr=2,width=760,onerror=redirect,format=auto,signature=675869877/https%3A%2F%2Fcontent.gitbook.com%2Fcontent%2F8PD5wsbi2h3HIurvbzMX%2Fblobs%2FkQ8vEOBr2ksl5xT8e6av%2Fimage.png)​​

The documents contained on these pages are intellectual property of Indicio and are not to be duplicated or shared. By requesting access to these pages you agreed tho these terms and conditions.<br>


# Indicio Proven ®

Unlocking efficiency and savings across industries and sectors

<figure><img src="/files/av6F6BvA3JprJShrFDO0" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/ubJpxEs3waTTMaq6sAH1" alt=""><figcaption></figcaption></figure>

## About Indicio Proven ®&#x20;

A complete end-to-end solution, Proven is designed to provide the widest possible range of options to build, deploy, scale, and manage verifiable credential ecosystems, and is interoperable and compatible with current and emerging global protocols and standards for decentralized identity, including the European Union’s new standards for digital identity (eIDAS) and digital wallets (EUDI).

It’s easy to implement and scale, from simple use cases to managing national and global identity verification, and unlike many digital credential solutions that claim to be decentralized, with Indicio technology, you are always in full control of your data.&#x20;

## Benefits

* Verifiable credentials can hold all kinds of valuable information in a tamper-proof way, as any attempt to alter that information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* Mutual authentication allows you to always able to verify who you are sharing data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.&#x20;
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is more secure — no need for third parties to store the data in centralized databases to manage authentication.&#x20;
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Protect biometric systems and data from AI deepfakes.

### Seamless, streamlined, and secure identity verification <a href="#seamless-streamlined-and-secure-identity-verification" id="seamless-streamlined-and-secure-identity-verification"></a>

* **Indicio Proven is the most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0.** It gives you maximum speed and flexibility to build, launch, scale, and manage verifiable credential ecosystems.
* **It’s built for interoperability.** Indicio Proven works with existing and emerging global standards, including EU eIDAS and EUDI digital wallets.
* **It’s fast to implement.** Integrate Proven with your current systems and can be configured in days—not months.
* **It’s easy to scale.** Go from a simple pilot to national or global identity verification without starting over.
* **Verifiable credentials are a breakthrough.** Gartner calls them “magnitudes of improvement in terms of efficiency, cost and assurance” in its 2024 Market Report for decentralized identity.
* **Deploy your way.** Use Indicio Proven on premises, in AWS, Azure, Google Cloud, Oracle, or with any provider you choose.

### What's included <a href="#whats-included" id="whats-included"></a>

**Issuer & Verifier Agents**\
The software needed to create, issue, and verify credentials.

**Mobile App & Mediator**\
The software to download, store, and use credentials on mobile devices.

**Verifiable Credential Schema**\
Flexible template for creating credentials.

**Verifiable Data Registry or Network**\
Make use of a robust and stable distributed ledger, professionally managed by Indicio, choose the provider or registry technology that works best for you, or have us build your own network.

**Technical support & training**\
Indicio Proven includes personalized onboarding, comprehensive documentation, and expert-led training to ensure your team is set up for success at every stage.

### ​[Book a demo ](https://indicio.tech/contact/)​ <a href="#book-a-demo" id="book-a-demo"></a>

Learn how easy it is to get started, use, and generate value using Indicio Proven!​

<figure><img src="/files/JMjcubUeTE7Oln0A9dej" alt=""><figcaption></figcaption></figure>


# Introduction to Proven

### A complete verifiable credential solution for identity and data <a href="#a-complete-verifiable-credential-solution-for-identity-and-data" id="a-complete-verifiable-credential-solution-for-identity-and-data"></a>

#### Seamless, streamlined, and secure identity verification <a href="#seamless-streamlined-and-secure-identity-verification" id="seamless-streamlined-and-secure-identity-verification"></a>

Indicio Proven is the world’s most advanced platform for decentralized identity using verifiable credentials and Open Badges 3.0.

It is designed to provide the widest possible range of options to build, deploy, scale, and manage verifiable credential ecosystems.

It is built to be interoperable and compatible with current and emerging global protocols and standards for decentralized identity, including the European Union’s new standards for digital identity (eIDAS) and digital wallets (EUDI).

It’s easy to implement — a platform that can work with your existing systems, and it is configurable in days rather than months.

And it’s easy to scale from simple use cases to managing national and global identity verification.

Verifiable credentials are a powerful new way to authenticate identity and data. As **Gartner Research** notes in its **2024 Market Report for Decentralized Identity**, they represent “magnitudes of improvement in terms of efficiency, cost and assurance.”

Indicio Proven allows you to build in a way that works best for you, with flexible deployment options, including on premises, in **Amazon Web Services, Azure, Google Marketplace, Oracle, or a provider of your choice.**

### What's included <a href="#whats-included" id="whats-included"></a>

#### Issuer & Verifier Agents <a href="#issuer-and-verifier-agents" id="issuer-and-verifier-agents"></a>

The software needed to create, issue, and verify credentials.

#### Mobile App & Mediator <a href="#mobile-app-and-mediator" id="mobile-app-and-mediator"></a>

The software to download, store, and use credentials on mobile devices.

#### Verifiable Credential Schema <a href="#verifiable-credential-schema" id="verifiable-credential-schema"></a>

Flexible template for creating credentials.

#### Distributed Ledger Network <a href="#distributed-ledger-network" id="distributed-ledger-network"></a>

Make use of a robust and stable distributed ledger, professionally managed by Indicio, choose the provider that works best for you, or have us build your own distributed ledger network.

#### Technical support & training <a href="#technical-support-and-training" id="technical-support-and-training"></a>

### Benefits <a href="#benefits" id="benefits"></a>

* Verifiable credentials can hold all kinds of valuable information in a way that any attempt to alter that information breaks the credential.
* Instant, cryptographic proof of who issued a credential, and that the person presenting it is the rightful owner — an identity fraud killer.
* You are always able to verify who you share data with before sharing it — and they you.
* Data is shareable across disparate systems without direct integration.
* Data is immediately actionable — if you trust the source of the credential, you can trust the data.
* Data is secure — no need for third parties to store the data in centralized databases to manage authentication.
* Takes the hassle out of data privacy compliance — a person is in control of their data and can share it by consent.
* Verifiable credentials can protect biometric data from AI deepfakes.


# Proven Integration Guide

The following document describes the major steps to integrate with Proven and incorporate verifiable credentials and decentralized identity into your software, solutions, and workflows. This guide covers all of the necessary information in recommended order and assumes you have general software development knowledge and only an introductory level understanding of decentralized identity technology.

This guide starts with an introduction to decentralized identity technology and guides you through architecting your solution. Next, set up a development environment, learn the API and SDK calls, and implement your integration. As your integration nears completion, configure your staging and production environments and test what you’ve developed. Finally, launch, evaluate, maintain, and update your solution.

Feel free to skip sections you already understand or to jump straight to what you want to learn. Remember, this is a guide to help you understand how your solution could be implemented, but you should consider your specific requirements, make adjustments, and customize as necessary.

Introduction to Decentralized Identity

Decentralized identity provides a way for people, organizations, devices, and even AI agents to identify themselves digitally.

It also provides a way to reliably trust the information presented by a person or device or a device that has a digital identity.

It does this by issuing digitally-signed data in the form of Verifiable Credentials that can be held in digital wallets.

The digital signatures ensure that the issuer of the Verifiable Credential can be cryptographically identified and verified and that the integrity of the data in the credential can be verified (i.e., that it hasn’t been altered).

Thus, if you trust the issuer of the credential, you can trust the information stored in the credential.

This enables digital identity and data to be shared and verified in a fully portable and seamless manner, without reference to certificate authorities, identity providers, or “phoning home” to the source of the data or cross-checking against the same data held in a centralized database.

One consequence of decentralized identity is that Verifiable Credentials allow data to be held by the owner (the holder) of the data, typically on their mobile device. This allows people to control who they share their data with and to share it in ways that, depending on the Verifiable Credential format, maximize privacy through selective disclosure and zero-knowledge proofs.

This means that decentralized identity solves key challenges for data privacy regulations, such as the European Union’s GDPR.

A Verifiable Credential holder can only share their data by consent. They can share data selectively or through zero-knowledge proofs to preserve privacy. This meets the GDPR minimization requirements for consent, data, and purpose (an organization explicitly receives consent from the data owner to use their data, limits the amount of personal data requested, and ties it to a specific use). By being able to verify data cryptographically without needing to centrally store that data, Verifiable Credentials also meet GDPR requirements for security.

There are two additional important elements to a credential ecosystem. The first of these is governance. Governance involves establishing and automating trust within a credential use case: Who are the trusted issuers of credentials? Who are the trusted verifiers? What information needs to be presented?

These rules are published in machine-readable files by the natural authority for the ecosystem.

The second element is how trust is operationally determined, or in other words, how is the cryptography to verify a credential facilitated? The information about credential issuers (such as DIDs and public keys), schemas, revocation, and the linkages between these data types needs to be stored in a trusted location called a Verifiable Data Registry. There are many ways to do this. Three of the most common ways include:

1. Blockchain distributed ledger. The advantage of using a distributed ledger is that it provides credential resilience and longevity.
2. Witness networks. Instead of using a network of nodes to run a ledger, a collection of devices can use other conventions or software to store, secure, and share registry info.
3. Other trust mechanisms. Some methods of storing registry information are simpler than ledgers or witness networks and establish trust in other ways. For example, hosting the information on a web server and using DNS infrastructure to establish trust is relatively straightforward. Depending on the server infrastructure, this may be less robust than a ledger or witness network.

In summary, decentralized identity removes the inherently vulnerable processes generally used to identify people and organizations online — processes otherwise known as centralized and federated identity.

With the vulnerabilities eliminated, identity and data can be easily and instantly shared and authenticated anywhere using fraud- and AI-resistant ways.

## Architect Your Integration&#x20;

Now that you have learned about the basics of decentralized identity, you’re ready to architect your solution to incorporate decentralized identity and verifiable credentials.

Some of the key decisions that you need to make include which DID method(s), schema(s), credential format(s), and protocol(s) to use. You need to assess how many issuers and verifiers are required, how these software agents integrate with existing systems, what wallet(s) and application(s) to use, and a strategy for trust establishment.&#x20;

### DID Methods&#x20;

DID methods are important because they are used to uniquely identify your software and set up the cryptography at the heart of decentralized identity. They are tied to your trust establishment mechanism. Sometimes they are also tied to credential formats and communication protocols due to the choices developers make when developing decentralized identity software packages.

Some popular choices include did:web and did:webvh, did:key, did:sov and did:indy, did:ion, and did:ethr.

It is important to note that some decentralized identity systems do not utilize DIDs for identifiers, cryptography, or trust establishment (e.g. mdoc/mDL).&#x20;

### Schemas&#x20;

One of the most important elements of your integration are the schemas of the verifiable credentials. A schema defines the attributes or data fields in a verifiable credential. These determine which “packets” of information you need to make reusable and verifiable around your system. For example, if you were working with an educational ecosystem, you might need schemas for student IDs, tuition receipts, class completion certificates, and diplomas.

Once you’ve identified which schemas you need, you’ll want to identify any existing schemas that you can or need to use. If a suitable or required schema doesn’t exist, you’ll need to create one, which involves specifying which attributes to include in the schema and naming it.

Sample User Schema:

```
{
  "attr_names": [
    "user_email",
    "username",
    "user_id",
    "user_roles"
  ],
  "name": "User",
  "version": "1.0"
}
```

<https://indyscan.indiciotech.io/tx/IND_DEMONET/domain/47432>&#x20;

### Credential Formats&#x20;

For encoding your schema into credentials, you will need to select one or more credential formats. Each format has pros and cons that may make some formats more suitable than others for your specific use cases.

The choice of credential format may be influenced by factors such as regulatory requirements, jurisdictional constraints, privacy and data protection considerations, and interoperability requirements with existing ecosystems or partners. Indicio can assist in navigating these considerations and selecting formats that align with your technical and compliance needs.

There are currently four major verifiable credential formats in widespread use; but, like many other technologies, there will be future updates, additions, and competing specifications to consider. After integrating Proven into your solution, you’ll need to schedule a periodic review of available credential formats.

#### mdoc/mDL (ISO 18013-5)&#x20;

Mdoc refers to a mobile document, and mDL refers specifically to a mobile driver’s license as defined by the ISO/IEC 18013-5 standard. These formats are primarily used for government-issued digital identity documents, including driver’s licenses and other official credentials.&#x20;

Implementing mdoc and mDL support is more complex than many other credential formats. It typically requires CBOR-based binary encoding, integration with certificate-based public key infrastructure (PKI), and conformance to ecosystem-specific trust frameworks. In addition, participation in many mdoc and mDL ecosystems may require formal approvals or certification processes, particularly for government and regulated deployments.

#### SD-JWT VCs

SD-JWT Verifiable Credentials are based on the JSON Web Token (JWT) standard and use selective disclosure mechanisms to allow holders to reveal only specific claims during presentation. The format is simpler to implement than some other credential types because it builds on widely adopted JWT tooling and web security primitives.&#x20;

SD-JWT VCs are among the formats approved for use within the eIDAS 2.0 and EUDI Wallet ecosystems. However, they do not currently provide native support for zero-knowledge proofs or cryptographic unlinkability across presentations. As a result, deployments that require reduced correlation across repeated use often rely on issuing credentials in batches or using additional operational controls.

#### JSON-LD VCs (W3C VCs)

JSON-LD Verifiable Credentials are defined by the W3C Verifiable Credentials Data Model and use JSON-LD to represent credential data in a flexible, extensible format. They are commonly used in decentralized identity systems and support a wide range of credential types and use cases.

JSON-LD credentials can be issued to a holder and presented across systems without being bound to a single platform. However, in their base form, they do not provide native support for selective disclosure or zero-knowledge proofs. Implementations that require these privacy-preserving features typically rely on additional cryptographic extensions or alternative credential formats.

#### AnonCreds&#x20;

AnonCreds (Anonymous Credentials) are a credential format designed to provide strong privacy guarantees, including selective disclosure, zero-knowledge proofs, and cryptographic unlinkability across repeated presentations, making them well-suited for privacy-sensitive use cases. Many current implementations rely on supporting infrastructure such as distributed ledgers for credential metadata and revocation, as well as DIDComm-based communication protocols.&#x20;

### Protocols

There are some major protocols in use with verifiable credentials, which are used for issuing credentials, requesting and sharing presentations, and, with DIDComm, performing other operations related to decentralized identity. Typically, implementations start with one or a small number of protocols. Additional protocols can be added later to improve system interoperability or when they’re needed for their unique capabilities. They can also be added to create implementations with novel properties.

#### OID4VC

OID4VC (OpenID for Verifiable Credentials) defines standardized protocols for both verifiable credential issuance (OID4VCI) and verifiable credential presentation (OID4VP). It builds on OpenID and OAuth flows that are already familiar to many developers, making integration straightforward. Because it leverages existing authentication patterns and infrastructure, OID4VC enables secure credential exchange with minimal additional overhead. One con to using OID4VC is that it does not establish a persistent connection, so additional interactions will require new URLs.&#x20;

#### DIDComm

DIDComm includes protocols for issuance and verification, among others. DIDComm’s major strength is that it can maintain a persistent connection, which allows two connected agents to carry out additional operations and utilize established trust over time.

#### BLE, NFC, WiFi Aware

While implemented in different ways, these are all “proximity” protocols–protocols used when two software agents are within close range of each other. This is simultaneously their strength and weakness.

#### DC API

The Digital Credentials (DC) API is supported by both Android and iOS and allows for simpler verifiable credential support on websites.

### Issuers

After you have determined how to manage all of the previous considerations, you can plan for credential issuance in your solution. Generally speaking, you need one credential issuing agent for each distinct entity making verifiable statements. You also need to consider where in your workflow you need to collect and validate data and when it needs to be issued to a holder’s wallet. This will determine where code updates or additions will need to be made in your existing system.&#x20;

### Verifiers

The next step is to plan for credential verification in your solution. Again, generally speaking, you need one verifying agent for each entity that needs to verify credential data (through the use of verifiable presentations). For each verifier, determine which credentials and credential attributes you need. You need to decide where in your workflows the data needs to be verified and ingested so you can plan for updates or additions.

### Wallet and Application Strategy

When considering your wallet and application strategy, there are several important questions to answer. Will you use an existing wallet (such as Holdr+)? Will you white-label an existing wallet? Will you build or modify an app to include wallet functionality using an SDK (such as Indicio’s Holdr SDK)? Do you need to support multiple apps or wallets?&#x20;

### Trust Establishment

Aside from the cryptography involved with issuing and verifying credentials, you also need a way to identify which parties are trusted. There are various ways to do this, including DIF Credential Trust Establishment, ToIP Trust Registries, x.509 certificate chains with VICAL, and OAuth.

## Configure Development Environment

To integrate with Proven, you will need to install your own copy of Proven and configure it to meet your specific needs. The following instructions are one way you can install Proven by yourself. If you need assistance or other installation options, please get in touch with us — Proven works with a wide variety of hosting options.

Follow the instructions in the GC Proven User Installation Guide to get a baseline Proven installed.
\
Using the example instructions in the above document as a guide, add one or more schemas as needed for your application.

You might also need to add an invitation for use by your application. Use the following steps if needed:

1. Log in to the Proven UI.
2. Click **INVITATIONS** in the main menu.
3. Click the large **+** button in the lower right corner.
4. Fill in the fields. Start with the following common values, then adjust to your preferences as needed:
   1. OOB Invitation: **True**
   2. Protocol: **DID Exchange 1.1**
   3. Alias: your choice, used to refer to the invitation within Proven
   4. Invitation Mode: **Multi**
   5. Uses: leave blank for no limit or enter a specific number (e.g. 5000) to cap how many times the invitation will be used
   6. Accept: **Auto**
   7. Public: **False**
   8. Their Role: your choice, could be used to categorize connections
   9. Their Label: your choice, usually used by other agents as a friendly name for this agent
   10. Workflow Status: **Active**
   11. Description: your choice, usually a short reminder of what this invitation was created for
   12. Purpose: your choice, this is a unique “handle” to use when linking invitations to specific workflows or behavior
   13. Active Starting Time: unused in this version
   14. Active Ending Time: unused in this version
   15. Once the invitation is created, click on the new invitation, then copy the new invitation URL into your application.

Congratulations, you now have an instance of Proven that you can use for learning, experimentation, and development!

## Learn Proven API and Holdr SDK Calls

Once you’ve architected your solution and configured an instance of Proven to use in development, it’s time to learn how to use Proven and the Holdr SDK.

### Proven&#x20;

The [Indicio Proven API Tutorial](https://indicio.gitbook.io/indicio-api-docs/sDoMLaDjYpI97bDybeEO/indicio-proven-r/how-to-guides/indicio-proven-api-tutorial) demonstrates how to connect, issue, and verify an AnonCreds credential using a Proven Agent and the Holdr+ Mobile Wallet application.

See [API Calls for OID4VCI and OID4VP SDJWT](https://indicio.gitbook.io/indicio-api-docs/sDoMLaDjYpI97bDybeEO/indicio-proven-r/how-to-guides/api-calls-for-oid4vci-and-oid4vp-sdjwt) for instructions to issue and verify an SD-JWT VC or JWT VC using a Proven Agent and then using the SDK.

See [Indicio Proven API Documentation](https://indicio.gitbook.io/indicio-api-docs/sDoMLaDjYpI97bDybeEO/indicio-proven-r/how-to-guides/indicio-proven-api-documentation#credentials-read-credential-issuance-by-id-json-ld) to view the API calls to issue and verify JSON-LD type credentials using a Proven Agent.

You can also refer to the [Indicio Proven API Reference](https://indicio.gitbook.io/indicio-api-docs/sDoMLaDjYpI97bDybeEO/indicio-proven-r/how-to-guides/indicio-proven-api-documentation) to learn more about individual API calls.

### Holdr SDK

The Holdr [Mobile SDK Documentation](https://indicio.gitbook.io/indicio-api-docs/sDoMLaDjYpI97bDybeEO/mobile-solutions/mobile-sdk) describes how to install, configure, and use the Holdr SDK.

## Implement Your Integration&#x20;

Now that you have a solution architecture, a development system, and some experience with Proven and the Holdr SDK, you are ready to implement your integration.

We’ll describe a process that works well for us and then share some useful tips, hints, and information.

### A Basic Integration Process

We like to follow these high-level steps during our integrations:

1. Publish schemas and configure your Proven agent(s) to use them.
2. Issue a test credential using dummy data to an existing wallet (such as Holdr+).
3. Use Holdr+ to present the test credential to your Proven verifier.
4. Write code in your existing system to retrieve and collect data for a credential and then call the Proven API to issue the credential to the existing wallet.
5. Write code in your system to receive webhooks. Try out these endpoints manually.
6. Configure the webhooks in your Proven verifier to send verifiable presentation data to your system’s new endpoints.
7. Now that real credential data can be used to create credentials and real presentation data can be ingested by your system, you can start working on your own wallet application instead of using Holdr+.
8. Create a white label version of Holdr+, add the Holdr SDK to your existing application, or begin coding a new application using the Holdr SDK.

### Integration Tips, Hints, and Information

Keep the following tips and information in mind while you are integrating decentralized identity into your solution using Proven:<br>

1. (Developer) licenses
   1. Expiration - Proven licenses include an expiration date. To ensure that your solution is running within its license agreement and continues to function, make careful note of when your software license expires.
   2. Renewal - Although your license includes a short grace period, you will have more success if you begin the renewal process before your grace period begins so that your renewed license is ready to go right when you need it.
   3. Enforcement - Indicio Proven and the Indicio Holdr SDK will stop working after their license grace periods expire, usually after 60 days.&#x20;
2. Development tips & tricks
   1. Source control - We recommend keeping your code in a source control solution to make sure that your code is versioned and backed up.
   2. Backups - We also recommend performing periodic backups of the different parts of your solution to help provide a robust system that can survive most emergencies or disasters.
3. Indicio Support
   1. For any support-related issues that you encounter, please feel free to directly contact anyone at Indicio that you already have contact with, or use our Indicio support email, <support@indicio.tech>, to share your issues and we will get back to you as soon as we can.
4. Testing during development
   1. Unit/integration/E2E testing
      1. Although there is a later section focused entirely on testing, it is wise to write many of your tests (both automated and test scripts for humans) during your development phase.
   2. Happy/unhappy path testing
      1. During the development process, it is also wise to record what successful and unsuccessful outcomes are possible and how to trigger those behaviors. Having repeatable test scripts to periodically check your system will be valuable.

Configure Staging Environment

Now that your solution has been developed and integrated with Proven, it is time to build a staging environment for testing of a production-like environment (which can also be used for demonstrations). While it’s possible to use the Proven instance created for development for this purpose, we recommend using a different environment for staging so that development efforts do not compromise your efforts to test and demonstrate your solution.

The Proven Staging environment is built in the same way as instructed in the Configure Development Environment section. Be sure to add all schemas that were included and needed from your development environment and remember to incorporate any learnings that you have experienced along the way.

The Proven Staging environment should be nearly an exact replica of what you built for Development. If you are using Hyperledger Indy as your VDR, you will want to configure your staging environment to use a stable network (such as the Indicio DemoNet) or, for testing that is closer to production configuration, a production network (such as the Indicio MainNet). The schemas used in development can be reused and simply added to the Proven Staging instance as needed (although the schema ID may be different if you are using a different network than you did in development), but the invitations will be different.

Configure Production Environment

Once you have completed the Staging phase, it’s time to begin the production phase.

The Proven Production environment is built the same as the Proven Staging environment but with a few additional recommended security hardening measures to ensure resilience, integrity, and operational reliability.

**Proven Server Hardening Recommendations:**

1. Secure passwords
   1. Follow the instructions for setting up Proven to ensure that all passwords included in Proven are secure.
2. Firewall
   1. Enforce a strict default-deny inbound policy.
   2. Allow only the minimum required ports (e.g., 80, 443, 22 and possibly 8150 if needed for swagger API access).
   3. Restrict SSH access to trusted IPs.
   4. DDoS protection - Implement request-rate limiting on ingress with a cloud-native tool like Cloud Armor.
3. Monitoring
   1. Implement real-time monitoring for at least the following:
      1. CPU
      2. memory
      3. disk space
      4. network behavior
   2. Daily Checks
      1. A daily smoke test helps ensure that your services are always available for your customers.
4. OS Security
   1. Apply all OS security patches regularly
5. Access control
   1. Limit the number of users with access to the server (but have at least two).
6. Enforce MFA for all admin accounts.
   1. Backups
7. Automated daily backups.

Testing Before Launch

Testing your verifiable credential solution and workflows should include standard testing procedures as well as tests to cover some unique decentralized identity considerations.

### Standard Testing&#xD;

There are a number of testing practices that we recommend in order to ensure that a solution is complete, robust, and resilient.

#### Code Tests&#xD;

We recommend unit, integration, and end-to-end (E2E) tests of your code to verify that new functionality works and that you don’t have regressions.

#### Technical Tests&#xD;

Conduct performance and security tests of your system.

**Performance tests:**

* Load testing
* Stress testing
* Spike testing
* Endurance testing
* Scalability testing

**Security tests:**

* Penetration testing
* Vulnerability scanning
* Fuzz testing
* Risk assessments

#### Usability and Approval

Conduct user and acceptance tests to ensure the solution is usable and that you’ve delivered a satisfactory end product.

### Decentralized Identity Testing

There are some unique considerations for testing solutions and workflows that include decentralized identity.

#### VDR (Verifiable Data Registry)

VDRs underpin the trust of your solution, so reliability, security, and compliance are especially important. This also means that it is riskier to “roll your own” implementation and the focus of your efforts should be on properly installing, configuring, and testing an existing registry solution. Some key things to test include correct operation, performance, availability, and data minimization. As some VDRs (such as Hyperledger Indy) use nonstandard ports, you will need to ensure that your firewall rules allow access to the VDR.

#### Schemas

Schemas are crucial for semantic interoperability of issued credentials, so it is important that validation, governance, and interoperability are tested. Begin testing by ensuring the different parts of your system are using matching schema IDs.

#### Revocation

Revocation allows trust in the system to increase because it provides a way to handle inaccurate or expired information. Testing for resilience, availability, and performance is especially crucial for revocation.

#### Mediator

Because mediators provide stable endpoints and collect messages for your mobile software, making sure they are stable and performing well is crucial. Indicio can assist with generating load to test mediator capacity and stability.

#### Interoperability Testing

If your solution is open to multiple parties, apps, or software versions, you’ll need to test the various combinations that could occur in real-world usage. Using official test suites is very useful for interoperability testing.

#### DPIA (Data Protection Impact Assessment)

Certain deployments, particularly in regulated or government environments, may require a Data Protection Impact Assessment. Your organization can approach Indicio for guidance and assistance, including supporting documentation on processing purposes, data flows, and technical safeguards, as well as explanations of how verifiable credential-based designs support privacy-by-design and data minimization principles.

#### Governance

Governance defines how trust is established, enforced, and maintained over time within a verifiable credential ecosystem. At a minimum, your system should explicitly control which credential issuers are trusted and under what conditions their credentials are accepted.

Beyond issuer trust, governance considerations typically include policy enforcement, operational readiness, onboarding and offboarding of participants, transparency into trust decisions, and alignment with applicable legal and contractual frameworks. These elements should be clearly defined and validated before production deployment to ensure consistent and predictable behavior across environments.

## Launch&#x20;

If you have existing deployment and launch procedures in place, it is wise to continue using them. The following launch steps or considerations will help ensure that the additional decentralized identity integration also goes smoothly.

### Phased Approach

Consider a soft or incremental launch, where a limited set of users or features is introduced at one time in order to reduce the risk of the new launch.

### Technical Preparation

Your technical team should be prepared to support the launch of your integrated solution by having monitoring configured, a support plan in place, and establishing rollback or contingency plans if anything goes wrong during or following the launch.

### Training and Other Materials

There is more to a successful launch than the technical rollout of new technology. Operations, support, customer service, and even marketing and sales departments should be aware of and prepare new processes and materials for the changes introduced with decentralized identity.

* **Change management** so everyone involved, especially customer-facing employees, knows what has been updated and can guide users to successfully use the system.
* **Training materials** for those with a role that requires more than simple awareness of the updated solution.
* **Quick start guides** may be useful for employees or customers.
* **Full instructions** are useful for documenting workflows and providing detailed guidance.
* **FAQs** provide guidance in an easy-to-digest format.
* **Signage** is often necessary where solutions have a physical presence.
* **Promotion** can be key to the success or failure of a new solution launch. If the public is unaware of or doesn’t understand the new offering, it may fail to meet utilization goals.
* **Marketing and sales** materials are important for solutions that need to be sold before they are utilized by end users.

## After Launch

### Gather Data and Feedback

Collecting and analyzing data from monitoring systems allows you to gauge the solution’s performance.

After the solution has launched, it is also important to immediately and then periodically gather feedback from those using and supporting the system to gauge their impressions and identify any signs of trouble.

### Applying Security Updates

Security updates are regularly released for nearly all actively maintained software, and Proven and the software it relies on are no exception. We recommend establishing a monthly (at a minimum) cadence of applying security updates.

### Updating Your Software

You will need to consider at least two major portions of your solution that might need to be updated:

Proven Updates: Updates to Proven will include improvements and new features that you might want to add to your solution. Regularly check for updates to Proven and consider if and when to upgrade to later versions.

Solution Updates: Your solution might need changes and improvements. Establish a regular evaluation of your solution and perhaps a roadmap for the development of improvements and upgrades.

## Summary

Integrating Proven allows you to add powerful decentralized identity functionality to your solution using familiar patterns, such as APIs and SDKs, unit and integration tests, Docker and Kubernetes, and more. As with all guides, however, this guide cannot describe every situation, requirement, step, or potential solution. Contact us if you have questions or would like assistance integrating Proven into your solution.


# How to Guides


# Proven User Guide

Indicio Proven™ provides the tools to establish a Trusted Digital Ecosystem (TDE). Out of the box, you can issue, verify, and manage user credentials. Once you have a user credential, other workflows become possible because you can trust you are working with a known person or agent. The issuer’s role is to send invitations to the contacts to offer them user credentials. The issuer also manages contacts.

## Home

After logging into the Admin screen, you will land on the home page. To issue yourself a User credential first select the User credential from the dropdown list. If the user credential does not appear, then a browser refresh might be required. Then click Issue. Scan the displayed QR code with your mobile identity wallet app. Complete the form, then click Send. Accept the offered credential on your mobile device.

## Invitations

This selection just shows a list of all invitation QR codes that have been generated by this instance of Proven.

## Contacts

Contacts are connections between the Proven Issuer and other agent applications. Not all software includes an editable label; therefore, some contacts will show the name of the software rather than the name of the person. The following information is displayed when first clicking into Contacts:

* **Contact Name**: The name of the mobile app user
* **Connection Status:**
  * **Invite**: an invitation has been sent
  * **Request**: the second party has received the invite and is requesting a connection.
  * **Response**: the system has responded with details to finish setting up the connection.
  * **Active**: the second party has acknowledged the connection.
* **Created At**: the date and time the invitation was sent.

Click on a specific contact to view more information. You can use this interface to issue credentials to Users who have connected to Proven using the main URL. At the bottom of the screen, there is a section of all the credentials issued to a user. To view more detailed information on any issued credential, click on it. This displays things such as the credential name, ID, state, and date created. It also displays certain attributes, such as the different parts of the user credential and the date the credential was validated.

## Credentials

A credential is encrypted data. When the Credentials tab is displayed it shows one of the following in the Status column:

* **Offer Sent:** A credential is created, and a connection is sent to the mobile app user
* **Credential Acked**: The mobile app user has acknowledged the offer and sent a request for a credential.
* **Credential Issued:** the system has created a credential

Click on any credential to view more information

## Issuing Credentials

A credential can be issued by using the Workflow section on the Home page or a similar method on the selected Contact page. Both methods offer a drop-down menu to choose the credential, but the Workflow section requires establishing a connection via the displayed QR code after selecting the credential from the menu. Subsequently, a form appears for the user to provide attribute values for the selected credential. After submitting the form, the credential will be issued.

It's important to note that while most credentials follow this flow, some credentials (e.g. Email) may require additional steps before issuance.

## Users

Users have access to the Proven Issuer admin system and can be created by anyone with the Admin role. Idicio uses a third party, Kekcloak to manage users. To manage users, follow the steps below.

## Create New Users

1. Log in to Keycloak. The address is <https://yourURL/identiy>.

2. Change the realm to **Indicio Proven**. (Image 1)<br>

   <figure><img src="/files/1oSiyGwTcdYzoy3ExBI5" alt=""><figcaption><p>Image 1: Indicio Proven realm</p></figcaption></figure>

3. Click on **Users**. (Image 2)

4. Click **Add user**. (Image 2)<br>

   <figure><img src="/files/PmVIK4SkMdVwrn4BNyLt" alt=""><figcaption><p>Image 2: Add user</p></figcaption></figure>

5. Enter the **Username**. (Image 3)

6. The other fields are optional, but may be useful: (Image 3)
   1. **Email**
   2. **First name**
   3. **Last name**

7. Click **Create**. (Image 3)<br>

   <figure><img src="/files/4PxHd7LNhCUyV2G6I6Zz" alt=""><figcaption><p>Image 3: User information</p></figcaption></figure>

8. Click the **Credentials** tab. (Image 4)

9. Click **Set password**. (Image 4)<br>

   <figure><img src="/files/fEGru24Dvfz3Vha2o4ID" alt=""><figcaption><p>Image 4: Credentials tab</p></figcaption></figure>

10. Enter the information in the box that opens: (Image 5)
    1. **Password**
    2. **Password confirmation**
    3. Turn on **Temporary**. This requires the user to reset his or her password when they log in the first time.
    4. Click **Save**.<br>

       <figure><img src="/files/tBTiybfqJl9nGPBQ4A98" alt=""><figcaption><p>Image 5: Add password</p></figcaption></figure>

11. Click the **Role Mapping** tab. (Image 6)

12. Click **Assign Role**. (Image 6)<br>

    <figure><img src="/files/ys6lV7jCEupYuEsKj91c" alt=""><figcaption><p>Image 6: Role mapping tab</p></figcaption></figure>

13. Select **Filter by Realm Role** from the drop-down. (Image 7)

14. Click on all desired roles: (Image 7)
    1. **admin:**
       1. This role can do all regular agent functions: connections, DID creation, credential issuance and presentation, messaging, governance file management, schema management
       2. This role can also create and revoke API keys (only for their own wallet(s); in contrast, super-admins can create/revoke API keys for any subwallet)
    2. **offline\_access:** This is a KeyCloak role and Indicio does not make use of it.
    3. **super-admin:**
       1. This role is for management of multitenancy
       2. Super admins can create subwallets, query all subwallets, and create and revoke API keys for all subwallets
       3. Highest level of privilege
       4. Does not encompass admin privileges; if you want multitenancy management and regular agent privileges, you need both super-admin and admin
    4. **technician:**
       1. This role is a reduced version of admin privileges; it can do messaging, connections (can't delete a contact), credential issuance (can't delete a received credential), credential presentation, can't manage governance files, can't create a did, can manage invitations (can't delete an invitation), can't manage schemas (only read them), can't manage settings, can't manage its own API keys
       2. Overall, can't delete resources. A technician can do issuance and presentations, but an admin role is needed for the full issuance setup if a new schema needs to be created
       3. Regarding the differences between Admin and Technician roles, Simon is a better resource than me since he wrote that code
    5. [**uma\_authorization**](#user-content-fn-1)[^1]**:** This is a KeyCloak role and Indicio does not make use of it.

15. Click **Assign**. (Image 7)

    <figure><img src="/files/FRCmAOHKIp8goRUS087p" alt=""><figcaption><p>Image 7: Roles</p></figcaption></figure>

16. Click on the **Groups** tab. If a group doesn't exist, you may need to [create a group](#create-new-group).

17. Click **Join Group**.

18. Select any groups applicable. (Image 8)

19. Click **Join**. (Image 8)<br>

    <figure><img src="/files/O6ubONy2ptZcaSsAdoXq" alt=""><figcaption><p>Image 8: Join group</p></figcaption></figure>

Invitations are only valid for 24 hours after they are issued. If the new user doesn’t sign in within that time period, press the envelope in the Resend column to reissue the invite. Usernames are established as new users log in for the first time.

## Edit Users

You can edit the following items for users. Refer to the Create New Users section for help.&#x20;

1. Log in to Keycloak.
2. Click **Users** in the left menu.
3. Click on the user you wish to edit.
   1. Edit the user’s name or email.
   2. Reset the user’s password
   3. Add or remove roles.
   4. Add or remove groups.

## Delete Users

If you wish to delete a user, follow the steps below:

1. Log in to Keycloak.
2. Click **Users** in the left menu.
3. Click on the three vertical dots found to the right of the user.
4. Click **Delete**.
5. Confirm you want to delete the user.

## Create New Group

Groups define how user access is managed. Each wallet (aka agent) has its own group. A user be assigned to the correct group to have access to the wallet.

1. Log in to Keycloak.
2. Go to **Groups** found in the left menu.
3. Click **Create group.**
4. Assign a **Name**.
5. Click **Create**.
6. Click on the group you just created.
7. Select the **Members** tab.
   1. Click **Add members**.
   2. Add any desired users in the dialog that appears. These are the users that should have access to the wallet that will be associated with this group
   3. Click **Add**.
8. Go to **Attributes** tab.
   1. Click **Add attributes**.
   2. Key: proven\_group\_id
   3. value: \[WalletNameHere]
   4. Click **Save**.

## Settings

**In Settings**, an admin can customize the screen to match the branding of the organization. Below are the options and descriptions:

* **Organization Details:**
  * **Organization name**: as it appears below the logo on the left
  * **Website title:** name as it appears on the browser’s tab
* **Change Logo**: This takes any properly formatted image file which is transparent or has a background that matches the admin system background (the default background color is white, #ffffff):
  * **Change logo**: on email stream and on the left.
  * **Change logo 192 x 192:** used when a mobile device is used instead of a desktop.
  * **Change logo 512 x 512:** used for mobile devices.
  * **Update favicon.io:** image found next to the name in the browser’s tab.
* **Web App Manifest:** The web app manifest provides app information to devices which treat the admin portal as a single-page application (such as mobile devices).
  * **Short name**
  * **Full name**
  * **Theme color**
  * **Background color**
* **SMTP Configuration:** This is the email account used when sending credentials and invitations to users. It must be set up before any credential invitations can be issued. If your company has a no-reply email, it is acceptable to use it here.
  * **Host:** mandatory field — the hostname or IP address to connect to (defaults to ‘localhost’).
  * **Mail Username:** mandatory field — the username (for Gmail accounts, mail username must be the same as the user email, e.g., <johndoe@example.com>).
  * **User email:** mandatory field — the user email
  * **User password:** mandatory field — the password for the email account (or an app password if a Gmail account is used)
  * **Port:** optional field — the port which the email system uses to accept email sending requests (defaults to 587 if Encryption Type is false or 465 if true).
  * **Encryption:** optional field — if true, the connection will use TLS when connecting to server. If false, (the default), then TLS is entered if the server supports the STARTTLS extension. In most cases, set this value to true if you are connecting to port 465. For port 587 or 25 keep it false.
* **Theme:** The theme changes the colors of the different elements. Below is a list of the possibilities and the elements affected:
  * **Primary color:** action buttons (submit, confirm, save, edit, etc.), current tab color, and username.
  * **Secondary color:** hover-over tab, tooltip symbols.
  * **Tertiary color:** home page hover-over color.
  * **Neutral color:** disabled buttons and form elements.
  * **Negative color:** warnings that pop up, delete buttons, cancel buttons.
  * **Warning color:** undo buttons.
  * **Positive color:** successes that pop up.
  * **Text color:** all text with the exception of tooltips.
  * **Text light:** text on buttons
  * **Border:** most of the border lines found in the application; it uses a full CSS declaration, such as “1pxsolid #ddd.”
  * **Drop shadow:** some of the various boxes in the application; they require a full CSS declaration, such as “3px 3px 3px rgba(0, 0, 0, 0.3).”
  * **Primary background:** background of all the boxes.
  * **Secondary background:** every other row of the tables.

Click **Save** when all desired changes are made

<figure><img src="/files/3QqwPPkutORKhrX3fORE" alt=""><figcaption></figcaption></figure>

[^1]:


# Proven User Tutorial

### Introduction <a href="#introduction" id="introduction"></a>

Indicio Proven™ provides the tools to establish a Trusted Digital Ecosystem (TDE). You can immediately issue, verify, and manage credentials. While the options are almost limitless, this tutorial will lead you through a simple workflow that illustrates some of Proven’s core capabilities.

## Install the Holdr+ Mobile Wallet

In order to interact with Proven, please download and install the free Holdr+ wallet from either the [Apple App Store](https://apps.apple.com/us/app/holdr/id1620628623) or the [Google Play Store](https://play.google.com/store/apps/details?id=tech.indicio.holdrplus).&#x20;

1. Swipe past the first two images and click **Get Started** on the third image as shown below.

<figure><img src="/files/E7GLr8t6gALZOTf5f6s6" alt=""><figcaption></figcaption></figure>

2. Read and accept the **Terms of Use** and the **Privacy Policy**. Check the box verifying you've read, understand, and accept the terms.
3. Click **Continue** for both the **Terms** and the **Privacy** policies.

<figure><img src="/files/liuhDw2TQO3OYqPkSEqr" alt=""><figcaption></figcaption></figure>

## Configure Your Holdr+ Mobile Wallet

1. Enter **First Name** and **Last name** (first image below).
2. Choose a **PIN** (second image).
3. When you are done, you will see your empty wallet home screen (third image).

<figure><img src="/files/udwGVK31IoydnNtwMeEq" alt=""><figcaption></figcaption></figure>

## Issuance - Log in to Proven

The next step is to log in to Proven.

1. Visit: <https://your.url.com/admin>
2. Username: admin
3. Password: 123!@#!@#QWEqwe

<figure><img src="/files/6bmuhGS3CwDu9xt9tZZF" alt=""><figcaption></figcaption></figure>

## Issuance - Select a Credential to Offer

On the Proven UI home page, select a credential to issue from the top drop down and click on **Issue**.

We selected **Employment** because it looks similar to a lot of different types of credentials.

<figure><img src="/files/EpHKzCjzkZ82sCFY5Usu" alt=""><figcaption></figcaption></figure>

## Issuance - Connect Using the QR Code in Proven

Proven will display a QR code that your mobile wallet can use to connect after you've selected a credential.

<figure><img src="/files/oTNSjk1CbaLP2iJxSG7K" alt=""><figcaption></figcaption></figure>

## Issuance - Connect Using the QR Code in Proven

1. In the Holdr+ wallet, click on the **Connect** button found in the bottom center of the screen.
2. Click **Scan a code**.
3. Scan the QR code.
4. You will see a new connection added to your Holdr+ home screen.

<figure><img src="/files/0lmXDCDsHHWzQThPOhIS" alt=""><figcaption></figcaption></figure>

## Issuance - Enter Credential Data

After connecting, Proven will display a form with all of the different attributes for the credential you selected. Fill in these fields and click **Send**. Entering fake data is acceptable.

<figure><img src="/files/W48Ff7tCYhR7TPeGRxP0" alt=""><figcaption></figcaption></figure>

## Issuance - Receive a Credential Offer

Proven displays a success message that says a credential offer was sent.

Holdr+ will display the offer on your home screen. Click **View** to see the details.

<figure><img src="/files/DyAUk1SCFmTGeCFsL8ag" alt=""><figcaption></figcaption></figure>

## Issuance - Review and Accept the Credential Offer

1. Click on the card to see the credential details.
2. Click **Accept** to add the credential to your wallet.
3. You can see the credential on your wallet screen.

<figure><img src="/files/PLy6DZ3d1Ae485kd3Qob" alt=""><figcaption></figcaption></figure>

## Issuance - Review Your Credential

After accepting the credential, Proven displays a success message.

Click on a credential in your Holdr+ wallet to view the details at any time.

<figure><img src="/files/fGqYBi8Gowon9MGifSye" alt=""><figcaption></figcaption></figure>

## Issuance - View Issued Credentials

View the list of issued credentials by clicking **Credentials** in the left menu.

<figure><img src="/files/B7E5XgMLkpZVbBC9vd6V" alt=""><figcaption></figcaption></figure>

Click on a credential in the list to view its details. General credential information and a list of attributes and their values are displayed on the credential details screen.

<figure><img src="/files/tunSCEs0sH0hqaVq9cDY" alt=""><figcaption></figcaption></figure>

## Sign out of Proven

Sign out of Proven by clicking on the icon in the top right corner of the screen.

<figure><img src="/files/spxQHOjMHZdCe92ylmBU" alt=""><figcaption></figcaption></figure>


# Proven Mobile SDK

## Proven Mobile SDK Documentation

The Indicio Holdr SDK (Software Development Kit) supports Android and iOS platforms and provides holder capabilities that are compatible with many Aries protocols. Consumption of the Holdr SDK will allow an application to have its own Aries Askar wallet for holding digital credentials that conform to the Anoncreds specification, communicate with ledgers through IndyVDR, and generate zero trust proofs for information verification through Anoncreds-RS.

### Supported Aries protocols:

* Did Exchange 1.0
* Out Of Band 1.1
* Coordinate Mediation 1.0
* Pickup 2.0
* Issue Credential 2.0
* Present Proof 2.0

### Supported DID methods:

* Did:Peer:1
* Did:Peer:2
* Did:Key

### Supported credential formats:

* Anoncreds

## API Overview

Sudo Typescript syntax is used to express the API. Any parameter that could be undefined is optional in Kotlin and React Native. Due to limitations with Swift code generation, not all Swift functions have default parameters when a value is optional and will need to have nil provided explicitly. A function using the await keyword is async in React Native and Swift and suspended in Kotlin.

[Agent API](#agent)

[DidExchange API](#didexchange)

[OutOfBand API](#out-of-band)

[Credentials API](#credentials)

[Proofs API](#proofs)

[Routing API](#routing)

[Events API](#events)

## Agent

### async agent.start(): void

Starts the agent and connects to the default mediator if a mediation configuration is provided.

```
await agent.start(
    timeout: 10_000 // Optional -- time limit in MS to connect to mediator
)
```

### async agent.stop(): void

Stops all even listeners and websockets and properly closes the wallet’s database files, so the agent can be used later.

```
await agent.stop()
```

### async agent.delete(): void

Deletes the agent and all data associated with it, essentially resetting the wallet.

```
await agent.delete()
```

## DidExchange

### async didExchange.acceptOutOfBandInvitation(): DidExchangeRecord

Sends a `didExchange` request to the agent associated with the provided out-of-band record.

```
const didExchangeRecord = await agent.didExchange.acceptOutOfBandInvitation(
    outOfBandRecord: OutOfBandRecord, // Record id (String) in React Native
    autoAcceptConnection: Boolean | undefined,
    label: String | undefined,
    alias: String | undefined,
    routingParam: Routing | undefined // Not available in React Native
)
```

### async didExchange.acceptResponse(): DidExchangeRecord

Completes the `didExchange` handshake by sending a complete message to the agent associated with the provided `didExchangeId`.

```
const didExchangeRecord = await agent.didExchange.acceptResponse(
    didExchangeId: String
)
```

### async didExchange.requestConnection(): DidExchangeRecord

Used when the auto-accept connection is disabled on the agent. This function is used to complete the started `didExchange` process once an out-of-band invitation has been processed, and a `didExchange` record is created but not auto-accepted.

```
const didExchangeRecord = await agent.didExchange(
    didExchangeId: String,
    outOfBandId: String,
    routingParam: Routing | undefined // Not available in React Native
)
```

### async didExchange.sendPing(): TrustPingMessage

Used to send a trust ping to another agent to ensure we can reach the agent.

```
const trustPingMessage = await agent.didExchange.sendPing(
    exchangeId: String,
    responseRequested: Boolean,
    returnRouting: Boolean
)
```

### async didExchange.returnWhenIsConnected(): DidExchangeStateChangedEvent?

Waits until the provided `didExchangeId` reaches a state of `Done` or until the provided timeout is reached.

```
const didExchangeStateChangedEvent: DidExchangeStateChangedEvent? = await agent.didExchange.returnWhenIsConnected(
    didExchangeId: String,
    timeOutMs: Number | Long
)
```

### async didExchange.getAll(): Array\[DidExchangeRecord]

Retrieves all `didExchange` records.

```
const records: Array<DidExchangeRecord> = await agent.didExchange.getAll()
```

### async didExchange.findAllByQuery(): Array\[DidExchangeRecord]

Finds all records that have tags matching the given query.

```
const records: Array<DidExchangeRecord> = await agent.didExchange.findAllByQuery(
    query: Query // Record<String, String> in React Native. Malformed Query will throw
)
```

### async didExchange.getById(): DidExchangeRecord

Retrieves the record with the provided ID or throws a `RecordNotFoundError`.

```
const record = await agent.didExchange.getById(
    didExchangeId: String
)
```

### async didExchange.findById(): DidExchangeRecord?

Finds the record with the given ID or returns `null` if not found.

```
const record: DidExchangeRecord? = await agent.didExchange.findById(
    didExchangeId: String
)
```

### async didExchange.deleteById(): void

Deletes the record with the given ID or throws `RecordNotFoundError` if it does not exist.

```
await agent.didExchange.deleteById(
    didExchangeId: String
)
```

### async didExchange.findAllByOutOfBandId(): Array\[DidExchangeRecord]

Finds all records associated with the given out-of-band ID.

```
const records: Array<DidExchangeRecord> = await agent.didExchange.getAllByOutOfBandId(
  outOfBandId: String
)
```

### async didExchange.findByDid(): DidExchangeRecord?

Finds the record associated with the provided Did.

```
const record: DidExchangeRecord? = await agent.didExchange.findByDid(
    did: String
)
```

### async didExchange.findByInvitationDid(): DidExchangeRecord?

Finds the record whose invitation contained the provided Did.

```
const record: DidExchangeRecord? = await agent.didExchange.findByInvitationDid(
    did: String
)
```

## Out Of Band

### async outOfBand.createInvitation(): OutOfBandRecord

Creates an out-of-band invitation and corresponding out-of-band record that is returned.

```
const record = await agent.outOfBand.createInvitation(
    label: String | undefined,
    alias: String | undefined,
    goalCode: String | undefined,
    goal: String | undefined,
    handShake: Boolean | undefined,
    messages: Array<BaseMessage> | undefined,
    multiUseInvitation: Boolean | undefined,
    autoAcceptConnection: Boolean | undefined,
    routingParam: Routing | undefined, // Not available in React Native
    appendedAttachment: Array<Attachment> | undefined
)
```

### outOfBand.parseInvitation(): OutOfBandInvitationMessage

Parses a URL encoded invitation into an `OutOfBandInvitationMessage`.

```
const message = agent.outOfBand.parseInvitation(
    invitationUrl: String
)
```

### async outOfBand.receiveInvitation(): AcceptInvitationResponse

Processes the provided invitation and potentially starts or completes `didExchange` protocol.

```
const invitationResponse = await agent.outOfBand.receiveInvitation(
    invitation: OutOfBandInvitationMessage,
    label: String | undefined,
    alias: String | undefined,
    autoAcceptConnection: Boolean | undefined,
    reuseConnection: Boolean | undefined,
    routingParam: Routing | undefined, // Not available in React Native
    acceptInvitationTimeOutMs = Number | Long | undefined
)
```

### async outOfBand.receiveImplicitInvitation(): AcceptInvitationResponse

Processes an invitation where the invitation message is not present and the agent is implicitly invited.

```
const invitationResponse = await agent.outOfBand.receiveImplicitInvitation(
    label: String | undefined,
    alias: String | undefined,
    autoAcceptConnection: Boolean | undefined,
    reuseConnection: Boolean | undefined,
    routingParam: Routing | undefined, // Not available in React Native
    acceptInvitationTimeOutMs: Number | Long | null,
    did: String,
    handShakeProtocol: Array<String> | null
)
```

### async outOfBand.acceptInvitation(): AcceptInvitationResponse

Accepts the invitation of an existing out-of-band record. It is not commonly used.

```
const invitationResponse = await agent.outOfBand.acceptInvitation(
    outOfBand: String,
    autoAcceptConnection: Boolean,
    reuseConnection: Boolean,
    label: String,
    alias: String | null,
    routingParam: Routing | null,
    timeOutMs: Number | undefined
)
```

### async outOfBand.findByInvitationId(): OutOfBandRecord?

Finds the out-of-band record with the corresponding invitation ID, or returns `null`.

```
const record: OutOfBandRecord? = await agent.outOfBand.findByReceivedInvitationId(
    receivedInvitationId: String
)
```

### async outOfBand.findByCreatedInvitationId(): OutOfBandRecord?

Finds the out-of-band record that corresponds to the invitation with the given ID that we have created, or returns `null`.

```
const record: OutOfBandRecord? = await agent.outOfBand.findByCreatedInvitationId(
    createdInvitationId: String
)
```

### async outOfBand.getAll(): Array\[OutOfBandRecord]

Retrieves all of the out-of-band records held by the agent.

```
const records: Array<OutOfBandRecord> = await agent.outOfBand.getAll()
```

### async outOfBand.getAllByQuery(): Array\[OutOfBandRecord]

Retrieves all out-of-band records that match the provided query.

```
const records: Array<OutOfBandRecord> = await agent.outOfBand.getAllByQuery(
    query: Query // Record<String, String> in React Native. Malformed Query will throw
)
```

### async outOfBand.getById(): OutOfBandRecord

Retrieves the record with the provided ID or throws `RecordNotFoundError`.

```
const record = await agent.outOfBand.getById(
    outOfBandId: String
)
```

### async outOfBand.findById(): OutOfBandRecord?

Finds the record with the given ID or returns `null`.

```
const record: OutOfBandRecord? = await agent.outOfBand.findById(
    outOfBandId: String
)
```

### async outOfBand.deleteById(): void

Deletes the record with the given ID or throws `RecordNotFoundError` if no such record exists.

```
await agent.outOfBand.deleteById(
    outOfBandId: String
)
```

## Credentials

### async credentials.findAllCredentialsBySchemaId(): Array\[CredentialRecord]

Finds all credentials whose schema ID matches the provided schema ID.

```
const records: Array<CredentialRecord> = await agent.credentials.findAllCredentialsBySchemaId(
    schemaId: String
)
```

### async credentials.proposeCredential(): CredentialExchangeRecord

Sends a proposal to the connection with the associated `didExchangeId` that we want the specified credential from.

```
const records: Array<CredentialRecord> = await agent.credentials.findAllCredentialsBySchemaId(
    schemaId: String
)
```

### async credentials.acceptOffer(): CredentialExchangeRecord

Accepts the offer associated with the provided credential exchange record.

```
const record = await agent.credentials.acceptOffer(
    credentialExchangeId: String,
    autoAcceptCredential: Boolean | undefined,
    comment: String | null | undefined
)
```

### async credentials.acceptCredential(): CredentialExchangeRecord

Accepts the issue credential and saves it to the agent's wallet.

```
const record = agent.credentials.acceptCredential(
    credentialExchangeId: String
)
```

### async credentials.findByRecordId(): CredentialExchangeRecord?

Finds the record with the given ID or returns `null`.

```
const record: CredentialExchangeRecord? = await agent.credentials.findByRecordId(
    credentialExchangeId: String
)
```

### async credentials.findAllByState(): Array\[CredentialExchangeRecord]

Finds all credentials whose exchange state matches the provided state.

```
const records: Array<CredentialExchangeRecord> = await agent.credentials.findAllByState(
    state: CredentialState
)
```

### async credentials.findAllByStateAndDidExchangeId(): Array\[CredentialExchangeRecord]

Finds all records whose state matches the given state and came from the connection associated with the given `didExchangeId`.

```
const records: Array<CredentialExchangeRecord> = await agent.credentials.findAllByStateAndDidExchangeId(
    state: CredentialState,
    didExchangeId: String
)
```

### async credentials.getAll(): Array\[CredentialExchangeRecord]

Retrieves all of the `credentialExchangeRecords`.

```
const records: Array<CredentialExchangeRecord> = await agent.credentials.getAll()
```

### async credentials.findByThreadIdAndDidExchangeId(): CredentialExchangeRecord?

Finds the credential exchange record that has matching `threadId` and `didExchangeId` (optional) or returns `null`.

```
const record = await agent.credentials.findByThreadIdAndDidExchangeId(
    threadId: String,
    didExchangeId: String | null
)
```

### async credentials.getByThreadIdAndDidExchangeId(): CredentialExchangeRecord

Retrieves the credential exchange record that has matching `threadId` and `didExchangeId` (optional): otherwise it throws `RecordNotFoundError`.

## Proofs

### async proofs.autoAcceptProof(): ProofRecord

Attempts to auto-accept the proof with the provided ID from the provided `didExchange` connection, it will throw `ProvenError` if the proof cannot be satisfied.

```
const record = await agent.proofs.autoAcceptProof(
    proofId: String,
    exchangeId: String
)
```

### async proofs.acceptProof(): ProofRecord

Accepts the given proof using the provided credential selections, it will throw `ProvenError` if the credential selection is invalid or insufficient.

```
const record = await agent.proofs.acceptProof(
    proofData: PresentationData
)
```

### async proofs.getCredentialsForProofRequest(): PresentationData

Retrieves a mapping of proof requests to valid credentials for the request that require further selection. Throws `RecordNotFoundError` if the proof cannot be satisfied with the agent's current credentials.

```
const creds = await agent.proofs.getCredentialsForProofRequest(
    proofId: String,
    exchangeId: String,
    nonRevoked: Boolean | undefined
)
```

### async proofs.autoSelectCredentialsForProofRequest(): PresentationData

Finds credentials that satisfy the proof request and automatically selects valid credentials if there are multiple options. Throws `RecordNotFoundError` if the proof cannot be satisfied with the agent's current credentials.

```
const creds = await agent.proofs.autoSelectCredentialsForProofRequest(
    proofId: String,
    exchangeId: String,
    nonRevoked: Boolean | undefined
)
```

### async proofs.getProofRequestsForConnection(): Array\[ProofRecord]

Retrieves the proof records for a given connection from the `didExchange ID`.

```
const records: Array<ProofRecord> = await agent.proofs.getProofRequestsForConnection(
    didExchangeId: String
)
```

## Routing

### async routing.initialize(): void

Starts or resumes the mediation to the default `mediator`. Called in `agent.start` by default.

```
await agent.routing.initialize()
```

### async routing.initiateMessagePickup(): void

Instructs the agent to attempt to pick up messages from the provided `mediator` record or the default mediator if not provided.

```
await agent.routing.initiateMessagePickup(
    mediator: MediationRecord | null | undefined // Record id is used in React Native
)
```

### async routing.findDefaultMediator(): MediationRecord?

Finds the default mediator if one is set, otherwise returns `null`.

```
const record: MediationRecord? = await agent.routing.findDefaultMediator()
```

### async routing.discoverMediation(): MediationRecord?

Finds the default mediator’s record. If the default mediator is found but not granted, this will throw `ProvenError`.

```
const record: MediationRecord? = await agent.routing.discoverMediation()
```

### async routing.setDefaultMediator(): MediationRecord

Sets the default mediator.

```
const record = await agent.routing.setDefaultMediator(
    mediation: MediationRecord | String // Provide the record or the record id. React native only uses Id
)
```

### async routing.requestMediation(): MediationRecord

Requests mediation from the given `didExchange` connection.

```
const record = await agent.routing.requestMediation(
    didExchange: DidExchangeRecord | String // Provide the record or the record id. React native only uses Id
)
```

### async routing.getByExchangeId(): MediationRecord

Retrieves the mediation record with the provided `didExchange` ID or throws `RecordNotFoundError`.

```
const record = await agent.routing.getByExchangeId(
    exchangeId: String
)
```

### async routing.findByExchangeId(): MediationRecord

Finds the mediation record with the given `didExchange` ID or returns `null` if not found.

```
const record: MediationRecord? = await agent.routing.findByExchangeId(
    exchangeId: String
)
```

### async routing.getMediators(): Array\[MediationRecord]

Retrieves all of the meditation records.

```
const records: Array<MediationRecord> = await agent.routing.getMediators()
```

### async routing.findDefaultMediatorExchange(): DidExchangeRecord?

Finds the `didExchange` record for the default mediator or returns `null` if not found

```
const record: DidExchangeRecord? = await agent.routing.findDefaultMediatorExchange()
```

### async routing.provision(): MediationRecord?

Attempts to complete the mediation request from the provided `didExchange` record in the given time. If it doesn’t complete, it will throw `CancellatinException`.

```
const record: MediationRecord? = await agent.routing.provision(
    didExchangeRecord: DidExchangeRecord,
    timeOutMs: Number | Long | undefined
)
```

### async routing.getRouting(): Routing

Retrieves the routing for this mediator. This is not available in React Native.

```
const routing = await agent.routing.getRouting(
    mediatorId: String,
    useDefaultMediator: Boolean | undefined
)
```

## Basic Messaging

### async basicMessages.send(): BasicMessageRecord

Sends a basic message to another connection.

```
const sentMessageRecord = await agent.basicMessages.send(
    didExchangeId: String, // ID of target
    content: String, // Message content to be sent
    locale: String = "en", // L10nDecorator version (defaults to "en")
    comment: String? // Comment on message
)
```

### async basicMessages.findById(): BasicMessageRecord

Finds a basic message record by ID.

```
const basicMessage = await agent.basicMessages.findById(
    basicMessageRecordId: String // Record ID to be retrieved
)
```

### async basicMessages.getAll(): Array

Retrieves all basic messages.

```
const basicMessages = await agent.basicMessages.getAll()
```

### async basicMessages.findByComment(): Array

Finds all basic messages with matching comments.

```
const basicMessages = await agent.basicMessages.findByComment(
    comment: String // Comment to search for
)
```

### async basicMessages.findByDidExchangeId(): Array

Finds all basic messages from the recipient.

```
const basicMessages = await agent.basicMessages.findByDidExchangeId(
    didExchangeId: String // Exchange ID to look for
)
```

### async basicMessages.findByRole(): Array

Finds all basic messages that match the role.

```
const basicMessages = await agent.basicMessages.findByRole(
    role: BasicMessageRole // Role to look for
)
```

## Events

#### React Native

React Native events take a callback function and return a function to remove the callback.

```
const remove = agent.events.registerDidExchangeHandler((event) => {
    console.log("Got a didExchange event")
})

remove() // cancels the event callback
```

The events that can have a handler registered are:&#x20;

* `registerDidExchangeHandler`
* `registerProofsHandler`
* `registerCredentialsHandler`
* `registerAgentHandler`
* `registerBasicMessageHandler`
* `registerRecordHandler`
* `registerWebSocketHandler`

#### Kotlin

Directly retrieve the event flow and use Kotlin's flow API using the events API. There is also a provided co-routine context on the events object.

```
/ May not be defined if there were issues with agent initialization
val didExchange: DidExchangeEvents? = agent.events.getDidExchangeEvents()

agent.events.scope.launch {
    didExchange.events.onEach{
        println("Got a didExchange event")
    }.collect() // Make sure to call collect or events will not be processed
}

```

The events that can be retrieved in Kotlin are the following:&#x20;

* `getDidExchangeEvents`
* `getAgentEvents`
* `getCredentialEvents`
* `getEventBusEvents` (Record update events)
* `getMessageEvents` (Events for all messages)
* `getProofEvents`
* `getBasicMessageEvents`
* `getTrustPingEvents`
* `getWebSocketEvents`

#### Swift

The following methods wrap events so you can easily listen to them without a third-party library or if you are using Objective-C:

* `onDidExchangeStateChanged`
* `onCredentialStateChanged`
* `onTrustPingEvent`
* `onAgentEvent`&#x20;
* `onRecordEvent`
* `onProofEvent`
* `onWebsocketEvent`
* `onBasicMessageEvent`

**Swift**

```
let removeListener = agent.events.onDidExchangeStateChanged { event in
  // Handle DidExchangeStateChangedEvent here
}
// Remove listener when no longer needed
removeListener(nil)
```

<figure><img src="/files/EEQp0oJJojvK2fP96rHq" alt=""><figcaption></figcaption></figure>


# Indicio Proven API Tutorial

This tutorial goes through a series of steps to exercise a few of the key features of the Proven API and help you begin to construct your own workflows.

### The three major features that will be exercised are:

1. [Connecting](#connecting)
2. [Issuing a credential](#issuing-a-credential)
3. [Verifying a credential](#verifying-a-credential)

## Connecting

### Call the Invitation API

To connect, one agent must issue an invitation to the other. Generally, the server agent issues an invitation to the mobile agent by displaying an invitation URL encoded in a QR code.

#### Request an invitation URL from the Proven API using the invitations API.<br>

1. Use the following API endpoint: <https://your.url.com/api/v1/invitations>.
2. Set your `x-api-key` header to: `9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW` (or your production API key).
3. Submit the following as the POST body:

```
{
  "contact_id": "",
  "alias": "API Invitation",
  "invitation_type": "CV1",
  "invitation_mode": "once",
  "accept": "auto",
  "public": false,
  "invitation_role": "Holder",
  "invitation_label": "CV1",
  "invitation_status": "active",
  "invitation_description": "Invitation created through API",
  "invitation_active_starting_at": null,
  "invitation_active_ending_at": null,
  "uses_allowed": ""
}
```

The API will respond with something similar to the following:

```
{"invitation_url":"https://proven.mediator.indiciotech.io?c_i=eyJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9jb25uZWN0aW9ucy8xLjAvaW52aXRhdGlvbiIsICJAaWQiOiAiNmQ0Y2QxZjYtNWJmMi00MjQ3LTg1ZmQtY2UxNzk5MjYyNDY3IiwgInJlY2lwaWVudEtleXMiOiBbIkFjOTFEWHE2ZEZzWXBZcmMyVlMzWDRrUnhHWGZtaGhaVXo1NUpSUkdSdkF5Il0sICJyb3V0aW5nS2V5cyI6IFsiRXJLRGVkNkQ1Tm9nUXpMVlBwczlrcFNXYWdxTndiVlE4RXpIcGdoTHE4UlQiLCAiMkRBQjZNU2V2bnFjc2ZoMzJIOEFrdlBIcHNzVmY3Wnl0UlZHOThTdXZXUjUiXSwgImxhYmVsIjogIlByb3ZlbiIsICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9wcm92ZW4ubWVkaWF0b3IuaW5kaWNpb3RlY2guaW8ifQ==","invitation_id":52,"contact_id":""}
```

## Establish the Connection

Once you have an invitation, use it to establish a connection between the two agents.

Use the `invitation_url` from the API response and provide it to a connecting agent such as Holdr+ using Postman:

* When working with Postman, you can copy the `invitation_url` and use a website such as <https://www.qr-code-generator.com/> to create and display a QR code that mobile agents like Holdr+ can read.
* Use Holdr+ to read the QR code by clicking on **Connect** in the middle of the bottom menu and pointing the camera at the QR code.

After the connecting agent reads the QR code and connects, you should see the most recent connection in Proven under **Contacts**.

### ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcfUgMV4NY5--9VAVW6jYJTdbg4aItDb-qL_8xLzb5zFRGjRKGgBHObTSnle47CklSa4HW1lAa59UUA_VmglfuO8P5d5Xgxe7rA1v2Xx5oMbIONxcD4MRh7i91H24pH3glUiOzjMQ?key=tN6hXHaeHvJsPlNsI6ko1g)

![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXeyYPjGpHQE4EQviUFuaY0lrmXMdN2bPsI5jhxUDwGMctmJlcROxx11eXfk_NngUZqXiYGPgZ7DjgTMh90Bz_SCNcNOLrfpNkl6V-UQYDfpdIIEQ23zQVxzRKHMKSGvqhdDCRw3bQ?key=tN6hXHaeHvJsPlNsI6ko1g)

## Issuing a Credential

After establishing a connection, perform the first of two key operations by issuing a credential.

Send a credential offer to a particular contact using the credentials API.

1. Use the following API endpoint: <https://your.url.com/api/v1/credentials>.
2. Set your `x-api-key` header to: `9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW` (or your production API key).
3. Submit the following as the POST body (notice the `invitation_id` **OR** `contact_id` should match what you used in the invitations API call above):

```
{
"invitation_id": 52,
"contact_id": "",
"schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",
"attributes": [
  {
    "name": "user_email",
    "value": "mike@indicio.tech"
  },
  {
    "name": "username",
    "value": "mike.ebert"
  },
  {
    "name": "user_id",
    "value": "1"
  },
  {
    "name": "user_roles",
    "value": "admin"
  }
]
}
```

The API will respond with the following message:

```
{
  "success": "Credential was offered"
}
```

The connected agent will receive a credential offer. In Holdr+, you will see a notification on the home screen. Click on it to view the offer details and to click **Accept** or **Decline**.

Accept the credential offer so that you can use it in the verification step.

### ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcCdyGovMZXPJgzJPGQflmGuZvHjgr5A4mtuXfzTnpSZzGUHS-F_GzblS9hslvG_16T5Cd8Ha-eNQqw5AfswvJabFtqDhFaCnxbqsXE9RdwC4K0GCZF4pu_em6Bs5Wqmm_PEsC9BQ?key=tN6hXHaeHvJsPlNsI6ko1g)

## Verifying a Credential

### Request a Verification

After establishing a connection, the second key operation to perform is to verify a credential. In this tutorial, you will verify the credential you just issued in the previous step using the verifications API.<br>

1. Use the following API endpoint: <https://your.url.com/api/v1/verifications>.
2. Set your `x-api-key` header to: `9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW` (or your production API key).
3. Submit the following as the POST body (notice the `invitation_id` **OR** `contact_id` should match what you used in the invitations API call above):

```
{
  "invitation_id": 52,
  "contact_id": "",
  "schemas": [
      {
          "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",
          "schema_attributes": [
              "user_email"
          ]
      }
  ],
  "timeout": "10",
  "rule": "no rule"
}
```

The API will respond with something similar to the following:

```
[
  {
      "verification_id": 3,
      "connection_id": "27194181-8bf5-4207-aad3-51e7ad7bbea5",
      "contact_id": null,
      "invitation_id": 52,
      "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",
      "schema_attributes": [
          "user_email"
      ],
      "timeout": 10,
      "rule": "no rule",
      "meta_data": null,
      "complete": false,
      "result": false,
      "result_string": "Pending",
      "result_data": null,
      "presentation_exchange_id": [
          "911fe7d1-1485-4997-99d8-ef858c9eab64"
      ],
      "error": "",
      "created_at": "2024-01-16T21:05:23.816Z",
      "updated_at": "2024-01-16T21:05:27.000Z"
  }
]
```

The connected agent will receive a presentation request. In Holdr+, you will see a notification on the home screen that you can click to view the request details and to click **Accept** or **Decline**.

Accept the request to send your credential information so that you can view it in the next step.

### ![](https://lh7-rt.googleusercontent.com/docsz/AD_4nXcCdyGovMZXPJgzJPGQflmGuZvHjgr5A4mtuXfzTnpSZzGUHS-F_GzblS9hslvG_16T5Cd8Ha-eNQqw5AfswvJabFtqDhFaCnxbqsXE9RdwC4K0GCZF4pu_em6Bs5Wqmm_PEsC9BQ?key=tN6hXHaeHvJsPlNsI6ko1g)

### Request the Status of the Verification(s)

After requesting the presentation of a credential from the connected agent (and sharing it if you are the one controlling the connected agent), you can request the verification result.&#x20;

If the user responds quickly or you set a long timeout, it is possible to get the presentation data back in the verification request itself. However, in most cases, you have to request the data at a later time.<br>

1. Request the result of a verification from the verifications API using the GET method and a URL that contains the verification ID number. For example, the `verification_id` is `3` as seen in the response in the [Request a Verification](#request-a-verification) section.
2. Use the following API endpoint with the correct ID in the URL: <https://your.url.com/api/v1/verifications/3>.
3. Set your `x-api-key` header to: `9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW` (or your production API key).

The API will respond with something similar to the following:

```
{
  "verification_id": 3,
  "connection_id": "27194181-8bf5-4207-aad3-51e7ad7bbea5",
  "contact_id": null,
  "invitation_id": 52,
  "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",
  "schema_attributes": [
      "user_email"
  ],
  "timeout": 10,
  "rule": "no rule",
  "meta_data": null,
  "complete": true,
  "result": true,
  "result_string": "Verified",
  "result_data": [
      {
          "name": "user_email",
          "value": "mike@indicio.tech"
      }
  ],
  "presentation_exchange_id": [
      "911fe7d1-1485-4997-99d8-ef858c9eab64"
  ],
  "error": "",
  "created_at": "2024-01-16T21:05:23.816Z",
  "updated_at": "2024-01-16T21:05:33.964Z"
}
```

Note the result\_data. You can now see the value of each of the attributes that you requested and use them for other credentials or in other parts of your existing or new systems.

<figure><img src="/files/RKtJGoYy6BqpLFJWMEpU" alt=""><figcaption></figcaption></figure>


# Indicio Proven API Documentation

## General Information

### HTTP Headers

All “v1” APIs require an “x-api-key” header to be set on the request. The “x-api-key” is not just used for authorization; it’s also used to determine which wallet will complete the request.

### Wallet ID

Proven supports a multi-tenant environment by default, even if you only intend to use a single wallet for this installed agent. Each wallet is identified by a wallet ID. Because these wallet IDs are linked to the API key(s) you will create, you don’t have to pay close attention to the wallet ID when using the API.

## Multi-Tenancy

Proven can support multiple instances and various configurations of decentralized identity software on a single machine. Each software installation is referred to as an agent, and each logical subdivision of the software is referred to as a wallet; in other words, one installation can be configured to act as several independent copies of decentralized identity software. This concept of having multiple software units running independently on the same machine is called multi-tenancy.<br>

Proven manages multi-tenancy by associating each wallet with a user group and allowing the administrator to assign users to groups (and thereby wallets). Thus, each installation can have multiple wallets, multiple users per wallet, and multiple wallets per user.<br>

Wallet authentication in Proven is handled via OpenID Connect, and the user's group is determined by the IAM service (Keycloak is the default for Proven). The IAM service provides the user's group and permissions, which Proven uses to determine the appropriate wallet for the user's operations.

## Managing Wallets

### Login

To log in, navigate to [http://your-domain-name.com/auth/login](http://localhost/auth/login). You will be redirected from Proven to a Keycloak login page, where you will log in with the user “indicio” and password “adminadminadmin”. After successful authentication, you will be redirected back to Proven. Keycloak will pass an OpenID Connect token, which will log the user in automatically. You will then see the Proven dashboard with the user “indicio” logged in.

### Create Wallets and API Keys

To manage wallets and their API keys, navigate to the Proven “Multi-tenancy” page. Click “Create Subwallet” to generate a new wallet.

To create an API key, select the wallet to which the new API key will belong from the drop-down menu and check the roles that the API key will have. After creation, store the API key and its ID securely (this is the only time that the API key will be available). To revoke an API key, use the API key ID and Wallet ID to indicate which API key will be revoked.

### Managing Users

Proven-UI does not have any pages for managing users. To manage users, you must use the Keycloak admin console. The linking of users to wallets requires the group ID entered into Keycloak.

### Adding Users to a Wallet

To add users to a new wallet, follow these steps:

1. Create a New Group in Keycloak:
   1. Select the “Indicio Proven Realm”
   2. Click on “Groups” in the left menu
   3. Click on the “Create group” button and name the group. The group name must match the wallet name that was created
   4. Click on the new group in the list of groups
   5. Click on the “Attributes” tab
   6. Click on “Add attributes”
   7. Enter "proven\_group\_id" as the key and the wallet name as the Value
   8. Click the “Save” button
2. Add New Users to the Group:
   1. Select the “Indicio Proven Realm”
   2. Click on “Users” in the left menu
   3. Select the user to add to the wallet
   4. Click on the “Groups” tab
   5. Click on the “Join Group” button
   6. Select the group(s) (which correspond to wallets) that you would like to add the user to
   7. Click the “Join” button
3. Log in to Proven:
   1. The first user to log in to the new wallet must have the “super-admin” role to complete the linking of the user group to the wallet.
   2. The super-admin user must simply log in to Proven to complete this operation.

By following these steps, the new user group and its associated users will be created and associated with the specified wallet.

### Using API Key Endpoints

In addition to an administrative UI, Proven offers an API for the programmatic execution of agent operations. Its OpenAPI specification can be found at [http://your-domain-name.com/api/doc](http://localhost/api/doc) of the server you are working with.

Proven uses API keys to authenticate requests to the API and authorize the API user's access to the requested resource. Proven uses the API key to determine the user's group and permissions, which are used to determine the appropriate wallet for the user's operations.

### Environment Variables

To use API keys, you must set the following environment variable:

| **Variable**     | **Explanation**                                                |
| ---------------- | -------------------------------------------------------------- |
| PROVEN\_API\_KEY | The base API key needed for management of wallets and API keys |

### API Key Creation Using the Swagger UI:

To create a new API key, you will need the base wallet API key. The base wallet API key is used to create wallets and their associated API keys. It can be found in the .env file as PROVEN\_API\_KEY.

Once you have the base wallet API key, you will need to be authorized before you can create new API keys.&#x20;

1. Click the “Authorize” button at the top right of the page.&#x20;
2. Enter the API key in the “Value” field.
3. Click the “Authorize” button.

Wallet API keys are used to authenticate requests to the Proven API. To create a new API key using Swagger, navigate to [http://your-domain-name.com/api/doc](http://localhost/api/doc).&#x20;

1. Create a new wallet if it is not already created.
2. Navigate to the API Keys tab and click the “Create API Key” button.&#x20;
3. Enter the wallet\_id for the wallet to which the API key will belong.
4. Click the “Create” button.&#x20;
5. The API key will be displayed in the table. Copy the API key and store it securely.

API keys are not stored by Proven; after the first creation of the key, there is no way to retrieve it. If the API key is lost, a new one must be created. Proven API requests must include the key in the request headers.

API keys have associated roles, which determine multitenancy privileges in the following manner:

* super-admin: Can create and revoke API keys for any wallet with any set of roles
* admin: Can create and revoke API keys in their wallet for any set of roles that are the same or a subset of its own
* technician and other limited roles: Have no multitenancy privileges

{% hint style="info" %}
The base API key is used to allow the base admin user to create and manage wallets and their API keys. The base admin user cannot perform most wallet API operations; to use most of the API, a wallet and its API key are needed.
{% endhint %}

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXci7uNcnHPYSpT84lZnP7wHJ462WDHcI-VS0wEKs5TVoZuPoUjZLh8QTdPjHm1FPiKcwUL2O6j2t2eHIEeGCDU_DZHNNkW7OApDuvBjucZbwE7_HZ9ypmET2QWEAnN6Z9v9_JV5Qw?key=RLV7pWjM_6NM2OYMxXIgxQ" alt=""><figcaption></figcaption></figure>

## API Key Flow Explanation:

1. User Requests API Key: The user requests to generate an API key.
2. Generate Random String: The API generates an opaque random string using a secure random source.
3. Present API Key: The API presents the random string (API key) to the user.
4. Store API Key Securely: The user stores the API key securely.
5. HMAC the String: The API HMACs the string with a secret.
6. Store HMACed Value: The API stores the HMACed value in the database.
7. Send API Request: The user sends an API request with the API key in the headers.
8. HMAC the Received Key: The API HMACs the received API key with the same secret.
9. Check User Role: The API checks the user's role.
10. Look Up HMACed Value: The API looks up the HMACed value in the database.
11. Return Metadata: The database returns metadata if the key is valid and not revoked.
12. Process Request: The API processes the request and returns the response to the user if the role is valid.
13. Return Error: The API returns an error if the role is invalid.

### Distinction Between HTTP Endpoints:

* Internal: Accessible using the Base API Key
  * Wallet creation
  * API Key creation and revocation
* External: Accessible through the use of wallet API Keys (which are created by the Base API Key for a particular wallet) or by a User in the Proven UI (which accesses information via the Proven WS API)
  * All other API endpoints

## API Contents

## Proven DIDComm APIs

### Basic Messages

#### Basic Message - Create Basic Message

```
/api/v1/messages - POST
```

This endpoint creates a Basic Message record that handles sending messages to currently active connection(s) or future active connection(s) until the request record reaches a completed state.&#x20;

### **Request Body Information:**

<table data-header-hidden><thead><tr><th></th><th width="190"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>message</td><td>string</td><td>Hello world!</td><td>Message content</td></tr></tbody></table>

**Response Body Information:**

<table data-header-hidden><thead><tr><th></th><th width="191"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>success</td><td>string</td><td>Message was sent!</td><td>Success message</td></tr></tbody></table>

### Sample Response Body:

```
{ "success": "Message was sent!" }
```

### Basic Message - Read All Basic Messages

```
/api/v1/messages - GET
```

This endpoint fetches all Basic Message records.

**Request Body Information:**

No request body

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>id</td><td>integer</td><td>123</td><td>Primary identifier for record</td></tr><tr><td>message_id</td><td>string</td><td>2ff097c3-5b65-4c25-a836-e2e3edb8195e</td><td>Unique identifier for exchange message</td></tr><tr><td>contact_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>message</td><td>string</td><td>Hello World!</td><td>Message content</td></tr><tr><td>state</td><td>string</td><td>sent</td><td>Current state of Basic Message request record</td></tr><tr><td>sent_time</td><td>string</td><td>2024-12-30T13:17:40.107Z</td><td>Date/time the message was sent to connection (ACA-Py field) </td></tr><tr><td>locale</td><td>string</td><td>null</td><td>Not used at present</td></tr><tr><td>wallet_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Identifier of the wallet used to process the request. The wallet used is determined by the x-api-key.</td></tr><tr><td>created_at</td><td>string</td><td>2024-12-30T13:17:40.108Z</td><td>Date of creation for the Basic Message record</td></tr><tr><td>updated_at</td><td>string</td><td>2024-12-30T13:17:40.108Z</td><td>Date the Basic Message record was last updated</td></tr></tbody></table>

### Sample Response Body:

```
[
   {
       "id": 1,
       "message_id": "",
       "contact_id": "199e022b-bb4c-4ae4-99fe-395b50ad4b66",
       "invitation_id": 1,
       "message": "Multiple Contact Hello World!",
       "state": "sent",
       "sent_time": "2024-12-30T13:17:40.107Z",
       "locale": "",
       "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
       "created_at": "2024-12-30T13:17:40.108Z",
       "updated_at": "2024-12-30T13:17:40.648Z"
   }
]
```

### Basic Message - Read Basic Message by ID

```
/api/v1/messages/<id> - GET
```

This endpoint fetches a Basic Message record by its ID.

**Request Body Information:**

No request body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>id</td><td>integer</td><td>123</td><td>Primary identifier for record</td></tr><tr><td>message_id</td><td>string</td><td>2ff097c3-5b65-4c25-a836-e2e3edb8195e</td><td>Unique identifier for exchange message</td></tr><tr><td>contact_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>message</td><td>string</td><td>Hello World!</td><td>Message content</td></tr><tr><td>state</td><td>string</td><td>sent</td><td>Current state of Basic Message request record</td></tr><tr><td>sent_time</td><td>string</td><td>2024-12-30T13:17:40.107Z</td><td>Date/time the message was sent to connection (ACA-Py field) </td></tr><tr><td>locale</td><td>string</td><td>null</td><td>Not used at present</td></tr><tr><td>wallet_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Identifier of the wallet used to process the request. The wallet used is determined by the x-api-key.</td></tr><tr><td>created_at</td><td>string</td><td>2024-12-30T13:17:40.108Z</td><td>Date of creation for the Basic Message record</td></tr><tr><td>updated_at</td><td>string</td><td>2024-12-30T13:17:40.108Z</td><td>Date the Basic Message record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
  {
      "id": 1,
      "message_id": "",
      "contact_id": "199e022b-bb4c-4ae4-99fe-395b50ad4b66",
      "invitation_id": 1,
      "message": "Multiple Contact Hello World!",
      "state": "sent",
      "sent_time": "2024-12-30T13:17:40.107Z",
      "locale": "",
      "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
      "created_at": "2024-12-30T13:17:40.108Z",
      "updated_at": "2024-12-30T13:17:40.648Z"
    }
```

## Connections

### Connections - Read All Connections

```
/api/v1/connections - GET
```

This endpoint fetches all connections, and includes parameters for pagination purposes.

### **Request URL Parameters Information:**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>sort-field</td><td>text</td><td>contact_id</td><td>Optional, any of the field names listed in the "Create invitation" POST body plus invitation_id</td></tr><tr><td>sort-direction</td><td>text</td><td>ASC</td><td>Optional, ASC or DESC</td></tr><tr><td>page-size</td><td>int</td><td>10</td><td>Optional, how many items should be returned in a page</td></tr><tr><td>current-page</td><td>int</td><td>2</td><td>Optional, the current page to retrieve</td></tr><tr><td>item-count</td><td>int</td><td>10</td><td>Optional, the total number of items</td></tr></tbody></table>

### **Sample URLs:**

```
https://your-domain-name.com/api/v1/connections?sort-field=contact_id&sort-direction=ASC&page-size=10&current-page=2
```

#### **Request Body Information:**

No request body

### **Response Body Information:**

The response body has three sections:

* Params: The pagination and sorting parameters
  * `"sort": “DESC”`
  * &#x20;`"pageSize": "10"`
  * `"currentPage": 1`
  * &#x20;`"pageCount": 1`
  * &#x20;`"itemCount": 1`
* Rows: The array of records
  * Each row in the rows array has the properties found in the table below.
* Count: The number of items returned
  * `“count”: 3`

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>connection_id</td><td>string</td><td>d61b698f-2eb4-438d-bec0-a7f88bcb47f0</td><td>Unique and primary identifier for the connection</td></tr><tr><td>state</td><td>string</td><td>active</td><td>Invitation, init, request, response, active, error, deleted</td></tr><tr><td>my_did</td><td>string</td><td>TP1jLwshBSSUArz154iLg2</td><td>Decentralized identifier</td></tr><tr><td>alias</td><td>string</td><td>Proven</td><td>String for how this connection could be labeled in the receiving agent</td></tr><tr><td>request_id</td><td>string</td><td>5f2b5d38-b3ad-43af-9b50-98df250e600e</td><td>ACA-Py field</td></tr><tr><td>invitation_key</td><td>string</td><td>7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7</td><td>ACA-Py field tied to the invitation used to establish the connection</td></tr><tr><td>invitation_msg_id</td><td>string</td><td>afbc12b7-28fa-4936-bf11-748148a98ffc</td><td>ACA-Py field tied to the invitation</td></tr><tr><td>invitation_mode</td><td>string</td><td>once</td><td>once, multi</td></tr><tr><td>invitation_url</td><td>string</td><td>https://&#x3C;domain>?oob=&#x3C;base64 invitation></td><td>Invitation_url used to establish the connection</td></tr><tr><td>invitation</td><td>object</td><td>{...}</td><td>Raw invitation data used by the receiving agent to connect</td></tr><tr><td>accept</td><td>string</td><td>auto</td><td>ACA-Py field/parameter </td></tr><tr><td>initiator</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>their_role</td><td>string</td><td>inviter</td><td>inviter, invitee</td></tr><tr><td>their_did</td><td>string</td><td>PhTeNogZWHmjCqiyPr8cds</td><td>Connecting wallet’s DID (sender or receiver, depending on who generated the invitation)</td></tr><tr><td>their_public_did</td><td>string</td><td>null</td><td>Connecting wallet’s Public DID (sender or receiver, depending on who generated the invitation)</td></tr><tr><td>their_label</td><td>string</td><td>Holdr+</td><td>Label used by this wallet to identify this connection</td></tr><tr><td>routing_state</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>inbound_connection_id</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>error_msg</td><td>string</td><td>null</td><td>Error message provided by ACA-Py during exchange</td></tr><tr><td>contact_id</td><td>string</td><td>0846c509-4a6e-4022-bebd-e2e9ff63b747</td><td>Identifier of the Contact tied to this connection</td></tr><tr><td>discover_features</td><td>array</td><td>[...]</td><td>List of available features for this connection</td></tr><tr><td>wallet_id</td><td>string</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Unique identifier of the wallet tied to this connection</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-30T10:37:30.734Z</td><td>Date/time of creation for the connection record</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-30T10:37:31.686Z</td><td>Date/time the connection record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "params": {
      "sort": [
          [
              [
                  "updated_at",
                  "DESC"
              ]
          ]
      ],
      "pageSize": "2",
      "currentPage": 2,
      "pageCount": 2,
      "itemCount": 3
  },
  "rows": [
      {
          "connection_id": "65eb5586-e519-441d-a05c-c3c697ecd97a",
          "state": "active",
          "my_did": "TP1jLwshBSSUArz154iLg2",
          "alias": "Proven",
          "request_id": "5f2b5d38-b3ad-43af-9b50-98df250e600e",
          "invitation_key": "7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7",
          "invitation_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
          "invitation_mode": "once",
          "invitation_url": "https://hard-tiger-38.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJhZmJjMTJiNy0yOGZhLTQ5MzYtYmYxMS03NDgxNDhhOThmZmMiLCAibGFiZWwiOiAiUHJpbWFyeVdhbGxldCIsICJoYW5kc2hha2VfcHJvdG9jb2xzIjogWyJodHRwczovL2RpZGNvbW0ub3JnL2RpZGV4Y2hhbmdlLzEuMCJdLCAic2VydmljZXMiOiBbeyJpZCI6ICIjaW5saW5lIiwgInR5cGUiOiAiZGlkLWNvbW11bmljYXRpb24iLCAicmVjaXBpZW50S2V5cyI6IFsiZGlkOmtleTp6Nk1ra2hmdFFqTkF6TkdZdzl2U1RLV25rZEVRTVJkenBYVG9Bd3dwNFF0YlJQU1YjejZNa2toZnRRak5Bek5HWXc5dlNUS1dua2RFUU1SZHpwWFRvQXd3cDRRdGJSUFNWIl0sICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9oYXJkLXRpZ2VyLTM4LnR1bjIuaW5kaWNpb3RlY2guaW8ifV19",
          "invitation": {
              "@type": "https://didcomm.org/out-of-band/1.1/invitation",
              "@id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
              "label": "PrimaryWallet",
              "handshake_protocols": [
                  "https://didcomm.org/didexchange/1.0"
              ],
              "services": [
                  {
                      "id": "#inline",
                      "type": "did-communication",
                      "recipientKeys": [
                          "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV"
                      ],
                      "serviceEndpoint": "https://hard-tiger-38.tun2.indiciotech.io"
                  }
              ]
          },
          "accept": "auto",
          "initiator": null,
          "their_role": "inviter",
          "their_did": "PhTeNogZWHmjCqiyPr8cds",
          "their_public_did": null,
          "their_label": "PrimaryWallet",
          "routing_state": null,
          "inbound_connection_id": null,
          "error_msg": null,
          "contact_id": "0846c509-4a6e-4022-bebd-e2e9ff63b747",
          "transaction_role": null,
          "discovered_features": [...],
          "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
          "created_at": "2024-12-30T10:37:30.734Z",
          "updated_at": "2024-12-30T10:37:31.686Z"
      }
  ],
  "count": 3
}
```

## Connections - Read Connection by ID

```
/api/v1/connections/<connection_id> - GET
```

This endpoint fetches a connection record by its `connection_id`.

**Request Body Information:**

No request body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>connection_id</td><td>string</td><td>d61b698f-2eb4-438d-bec0-a7f88bcb47f0</td><td>Unique and primary identifier for the connection</td></tr><tr><td>state</td><td>string</td><td>active</td><td>Invitation, init, request, response, active, error, deleted</td></tr><tr><td>my_did</td><td>string</td><td>TP1jLwshBSSUArz154iLg2</td><td>Decentralized identifier</td></tr><tr><td>alias</td><td>string</td><td>Proven</td><td>String for how this connection could be labeled in the receiving agent</td></tr><tr><td>request_id</td><td>string</td><td>5f2b5d38-b3ad-43af-9b50-98df250e600e</td><td>ACA-Py field</td></tr><tr><td>invitation_key</td><td>string</td><td>7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7</td><td>ACA-Py field tied to the invitation used to establish the connection</td></tr><tr><td>invitation_msg_id</td><td>string</td><td>afbc12b7-28fa-4936-bf11-748148a98ffc</td><td>ACA-Py field tied to the invitation</td></tr><tr><td>invitation_mode</td><td>string</td><td>once</td><td>once, multi</td></tr><tr><td>invitation_url</td><td>string</td><td>https://&#x3C;domain>?oob=&#x3C;base64 invitation></td><td>Invitation_url used to establish the connection</td></tr><tr><td>invitation</td><td>object</td><td>{...}</td><td>Raw invitation data used by the receiving agent to connect</td></tr><tr><td>accept</td><td>string</td><td>auto</td><td>ACA-Py field/parameter </td></tr><tr><td>initiator</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>their_role</td><td>string</td><td>inviter</td><td>inviter, invitee</td></tr><tr><td>their_did</td><td>string</td><td>PhTeNogZWHmjCqiyPr8cds</td><td>Connecting wallet’s DID (sender or receiver, depending on who generated the invitation)</td></tr><tr><td>their_public_did</td><td>string</td><td>null</td><td>Connecting wallet’s Public DID (sender or receiver, depending on who generated the invitation)</td></tr><tr><td>their_label</td><td>string</td><td>Holdr+</td><td>Label used by this wallet to identify this connection</td></tr><tr><td>routing_state</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>inbound_connection_id</td><td>string</td><td>null</td><td>ACA-Py field</td></tr><tr><td>error_msg</td><td>string</td><td>null</td><td>Error message provided by ACA-Py during exchange</td></tr><tr><td>contact_id</td><td>string</td><td>0846c509-4a6e-4022-bebd-e2e9ff63b747</td><td>Identifier of the Contact this connection is tied to</td></tr><tr><td>discover_features</td><td>array</td><td>[...]</td><td>List of available features for this connection</td></tr><tr><td>wallet_id</td><td>string</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Unique identifier of the wallet this connection is tied to</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-30T10:37:30.734Z</td><td>Date/time of creation for the connection record</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-30T10:37:31.686Z</td><td>Date/time the connection record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
      "connection_id": "65eb5586-e519-441d-a05c-c3c697ecd97a",
      "state": "active",
      "my_did": "TP1jLwshBSSUArz154iLg2",
      "alias": "Proven",
      "request_id": "5f2b5d38-b3ad-43af-9b50-98df250e600e",
      "invitation_key": "7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7",
      "invitation_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
      "invitation_mode": "once",
      "invitation_url": "https://hard-tiger-38.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJhZmJjMTJiNy0yOGZhLTQ5MzYtYmYxMS03NDgxNDhhOThmZmMiLCAibGFiZWwiOiAiUHJpbWFyeVdhbGxldCIsICJoYW5kc2hha2VfcHJvdG9jb2xzIjogWyJodHRwczovL2RpZGNvbW0ub3JnL2RpZGV4Y2hhbmdlLzEuMCJdLCAic2VydmljZXMiOiBbeyJpZCI6ICIjaW5saW5lIiwgInR5cGUiOiAiZGlkLWNvbW11bmljYXRpb24iLCAicmVjaXBpZW50S2V5cyI6IFsiZGlkOmtleTp6Nk1ra2hmdFFqTkF6TkdZdzl2U1RLV25rZEVRTVJkenBYVG9Bd3dwNFF0YlJQU1YjejZNa2toZnRRak5Bek5HWXc5dlNUS1dua2RFUU1SZHpwWFRvQXd3cDRRdGJSUFNWIl0sICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9oYXJkLXRpZ2VyLTM4LnR1bjIuaW5kaWNpb3RlY2guaW8ifV19",
      "invitation": {
          "@type": "https://didcomm.org/out-of-band/1.1/invitation",
          "@id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
          "label": "PrimaryWallet",
          "handshake_protocols": [
              "https://didcomm.org/didexchange/1.0"
          ],
          "services": [
              {
                  "id": "#inline",
                  "type": "did-communication",
                  "recipientKeys": [ "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV"
                  ],
                  "serviceEndpoint": "https://hard-tiger-38.tun2.indiciotech.io"
              }
          ]
      },
      "accept": "auto",
      "initiator": null,
      "their_role": "inviter",
      "their_did": "PhTeNogZWHmjCqiyPr8cds",
      "their_public_did": null,
      "their_label": "PrimaryWallet",
      "routing_state": null,
      "inbound_connection_id": null,
      "error_msg": null,
      "contact_id": "0846c509-4a6e-4022-bebd-e2e9ff63b747",
      "transaction_role": null,
      "discovered_features": [...],
      "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
      "created_at": "2024-12-30T10:37:30.734Z",
      "updated_at": "2024-12-30T10:37:31.686Z"
  }
```

## Context

#### Context - Save JSON-LD Context File

```
/api/v1/context - POST
```

This endpoint saves a JSON-LD context file.

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>context_file_id</td><td>string</td><td>test.json</td><td>File name of the JSON-LD context file to save</td></tr><tr><td>file</td><td>object</td><td>{...}</td><td>Object containing JSON-LD contexts</td></tr></tbody></table>

### **Request Body Sample:**

```
 {
  "context_file_id": "test.json",
  "file": {
    "@context": {
      "GenericCredential": {
        "@id": "https://example.com/indicio#GenericCredential",
        "@context": {
          "name": "http://schema.org/name",
          "givenName": "http://schema.org/givenName",
          "familyName": "http://schema.org/familyName",
          "identifier": "https://example.com/indicio#identifier",
          "date": {
            "@id": "http://schema.org/date",
            "@type": "http://www.w3.org/2001/XMLSchema#date"
          },
          "description": "http://schema.org/description"
        }
      }
    }
  }
}
```

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>success</td><td>string</td><td>Context file was posted</td><td>Success message</td></tr></tbody></table>

### **Sample Response Body:**

```
{ "success": "Context file was posted" }
```

Credentials

#### Credentials - Create Credential Issuance (JSON-LD)

```
/api/v1/credentials/json-ld - POST
```

This endpoint creates an Issuance request record that handles issuing credentials (JSON-LD) for currently active connection(s) or future active connection(s) until the request record reaches a completed state.

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="172"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>context</td><td>array</td><td>https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json</td><td>Contexts of the credential</td></tr><tr><td>label</td><td>string</td><td>Drivers License</td><td>Credentials label</td></tr><tr><td>issuer_name</td><td>string</td><td>Proven</td><td>Name of the issuer</td></tr><tr><td>type</td><td>array</td><td>[...]</td><td>Types of the credential</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>The “name” accepts string data type only. The “value” accepts string, object, and array data types</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>no rule</td><td>Rules enforced for this request (future feature)</td></tr><tr><td>did</td><td>string</td><td>did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt</td><td>Decentralized identifier used to sign the credential</td></tr><tr><td>proofType</td><td>string</td><td>Ed25519Signature2020</td><td>Type of proof to generate to sign the credential. Defaults to Ed25519Signature2018</td></tr></tbody></table>

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>request_id</td><td>integer</td><td>1</td><td>Records primary key</td></tr><tr><td>connection_id</td><td>string</td><td>f7699aa9-beec-4e0c-868d-eb3766ad2f64</td><td>Connection used for this request, determined by invitation_id and contact_id</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>context</td><td>array</td><td>https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json</td><td>Contexts of the credential</td></tr><tr><td>label</td><td>string</td><td>Drivers License</td><td>Credentials label</td></tr><tr><td>type</td><td>array</td><td>[...]</td><td>Types of the credential</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>The “name” accepts string data type only. The “value” accepts string, object, and array data types</td></tr><tr><td>wallet_id</td><td>string</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>issuer_name</td><td>string</td><td>Proven</td><td>Name of the issuer</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules enforced for this request (future feature)</td></tr><tr><td>meta_data</td><td>object</td><td>{...}</td><td>Metadata for this credential</td></tr><tr><td>state</td><td>string</td><td>offer_sent</td><td>ACA-Py field - null means no issuance has been triggered yet, likely due to no available connection</td></tr><tr><td>complete</td><td>boolean</td><td>false</td><td>This field does not indicate successful issuance, only that the request record has finished its process.</td></tr><tr><td>result</td><td>boolean</td><td>false</td><td>Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>“Pending”</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>credential_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each issued credential</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing request record</td></tr><tr><td>issuer_did</td><td>string</td><td>did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt</td><td>Issuer’s decentralized identifier</td></tr><tr><td>proof_type</td><td>string</td><td>Ed25519Signature2020</td><td>Type of proof to generate to sign the credential - defaults to Ed25519Signature2018.</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
      "request_id": 1,
      "connection_id": "f7699aa9-beec-4e0c-868d-eb3766ad2f64",
      "contact_id": "",
      "invitation_id": 1,
      "context": [
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
      ],
      "label": "マルチテナント検証_003",
      "type": [
          "OpenBadgeCredential"
      ],
      "attributes": [...],
      "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
      "issuer_name": "PrimaryWallet",
      "timeout": 0,
      "rule": "no rule",
      "meta_data": null,
      "state": null,
      "complete": false,
      "result": false,
      "result_string": "Pending",
      "credential_exchange_id": [
          "fca9d9cb-d93c-4383-bcb3-71454aa5d62c"
      ],
      "error": "",
      "issuer_did": "did:sov:JHQQDXd1MophrGnygoj3L4",
      "proof_type": "Ed25519Signature2018",
      "created_at": "2024-12-31T09:34:31.635Z",
      "updated_at": "2024-12-31T09:34:33.095Z"
  }
]
```

## Credentials - Read Credential Issuance by ID (JSON-LD)

```
/api/v1/credentials/json-ld/<request_id> - GET
```

This endpoint fetches a credential (JSON-LD) Issuance request record by its `request_id`.&#x20;

**Request Body Information:**

No request body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="174"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>request_id</td><td>integer</td><td>1</td><td>Records primary key</td></tr><tr><td>connection_id</td><td>string</td><td>f7699aa9-beec-4e0c-868d-eb3766ad2f64</td><td>Connection used for this request, determined by invitation_id and contact_id</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>context</td><td>array</td><td>https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json</td><td>Contexts of the credential</td></tr><tr><td>label</td><td>string</td><td>Drivers License</td><td>Credentials label</td></tr><tr><td>type</td><td>array</td><td>[...]</td><td>Types of the credential</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>The “name” accepts string data type only.<br>The “value” accepts string, object, and array data types.</td></tr><tr><td>wallet_id</td><td>string</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>issuer_name</td><td>string</td><td>Proven</td><td>Name of the issuer</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules enforced for this request (future feature)</td></tr><tr><td>meta_data</td><td>object</td><td>{...}</td><td>Metadata for this credential</td></tr><tr><td>state</td><td>string</td><td>offer_sent</td><td>Null means no issuance has been triggered yet, likely due to no available connection</td></tr><tr><td>complete</td><td>boolean</td><td>false</td><td>This field does not indicate successful issuance, only that the request record has finished its process.</td></tr><tr><td>result</td><td>boolean</td><td>false</td><td>Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>“Pending”</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>credential_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each issued credential.</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing request record</td></tr><tr><td>issuer_did</td><td>string</td><td>did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt</td><td>Issuer’s decentralized identifier</td></tr><tr><td>proof_type</td><td>string</td><td>Ed25519Signature2020</td><td>Type of proof to generate to sign the credential. Defaults to Ed25519Signature2018</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
      "request_id": 1,
      "connection_id": "f7699aa9-beec-4e0c-868d-eb3766ad2f64",
      "contact_id": "",
      "invitation_id": 1,
      "context": [
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json"
      ],
      "label": "マルチテナント検証_003",
      "type": [
          "OpenBadgeCredential"
      ],
      "attributes": [...],
      "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
      "issuer_name": "PrimaryWallet",
      "timeout": 0,
      "rule": "no rule",
      "meta_data": null,
      "state": null,
      "complete": false,
      "result": false,
      "result_string": "Pending",
      "credential_exchange_id": [
          "fca9d9cb-d93c-4383-bcb3-71454aa5d62c"
      ],
      "error": "",
      "issuer_did": "did:sov:JHQQDXd1MophrGnygoj3L4",
      "proof_type": "Ed25519Signature2018",
      "created_at": "2024-12-31T09:34:31.635Z",
      "updated_at": "2024-12-31T09:34:33.095Z"
  }
]
```

## Credentials - Create Credential Issuance (AnonCred)

```
/api/v1/credentials - POST
```

This endpoint creates an Issuance request record that handles issuing credentials (AnonCred) for currently active connection(s) or future active connection(s) until the request record reaches a completed state.

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>schema_id</td><td>text</td><td>KT4LtL7HEMePqQSyKVof7g:2:Email:1.0</td><td>Credentials schema</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>List of schema attribute names and their values </td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>no rule</td><td>Rules enforced for this request (future feature)</td></tr></tbody></table>

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>request_id</td><td>integer</td><td>123</td><td>Issuance request record primary key</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Ties record to the connection used to complete the request</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>schema_id</td><td>text</td><td>KT4LtL7HEMePqQSyKVof7g:2:Email:1.0</td><td>Credentials schema</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>List of schema attribute names and their values </td></tr><tr><td>wallet_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>no rule</td><td>Rules enforced for this request (future feature)</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for this credential</td></tr><tr><td>state</td><td>string</td><td>offer_sent</td><td>Null means no issuance has been triggered yet, likely due to no available connection.</td></tr><tr><td>complete</td><td>boolean</td><td>false</td><td>This field does not indicate successful issuance, only that the request record has finished its process.</td></tr><tr><td>result</td><td>boolean</td><td>false</td><td>Indicates successful issuance result. This field should be used alongside “complete” to determine if you have a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>“Pending”</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>credential_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each issued credential.</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
    "request_id": 1,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "contact_id": "",
    "invitation_id": 1,
    "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0",
    "attributes": [
      {
        "name": "local_part",
        "value": "alice"
      },
      {
        "name": "domain",
        "value": "example.com"
      },
      {
        "name": "address",
        "value": "alice@example.com"
      },
      {
        "name": "verified_at",
        "value": "1670296277"
      }
    ],
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "timeout": 1,
    "rule": "no rule",
    "meta_data": null,
    "state": null,
    "complete": false,
    "result": false,
    "result_string": "Pending",
    "credential_exchange_id": [
      "5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134"
    ],
    "error": "",
    "created_at": "2025-01-03T12:57:35.090Z",
    "updated_at": "2025-01-03T12:57:37.842Z"
  }
]
```

## Credentials - Read Credential Issuance by ID (AnonCred)

```
/api/v1/credential-records/<request_id> - GET
```

This endpoint fetches a credential Issuance record by its `request_id`.

**Request Body Information:**

No request body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>request_id</td><td>integer</td><td>123</td><td>Issuance request record primary key</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Identifier that ties this record to a connection</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>schema_id</td><td>text</td><td>KT4LtL7HEMePqQSyKVof7g:2:Email:1.0</td><td>Credentials schema</td></tr><tr><td>attributes</td><td>array</td><td>[{“name”: “first_name”, “value”: “Alice”}]</td><td>List of schema attribute names and their values </td></tr><tr><td>wallet_id</td><td>string</td><td>199e022b-bb4c-4ae4-99fe-395b50ad4b66</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record</td></tr><tr><td>rule</td><td>string</td><td>no rule</td><td>Rules enforced for this request (future feature)</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for this credential</td></tr><tr><td>state</td><td>string</td><td>offer_sent</td><td>Null means no issuance has been triggered yet, likely due to no available connection.</td></tr><tr><td>complete</td><td>boolean</td><td>false</td><td>This field does not indicate successful issuance, only that the request record has finished its process.</td></tr><tr><td>result</td><td>boolean</td><td>false</td><td>Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record</td></tr><tr><td>result_string</td><td>string</td><td>“Pending”</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>credential_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each issued credential</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2024-12-31T09:34:31.635Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
    "request_id": 1,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "contact_id": "",
    "invitation_id": 1,
    "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0",
    "attributes": [
      {
        "name": "local_part",
        "value": "alice"
      },
      {
        "name": "domain",
        "value": "example.com"
      },
      {
        "name": "address",
        "value": "alice@example.com"
      },
      {
        "name": "verified_at",
        "value": "1670296277"
      }
    ],
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "timeout": 1,
    "rule": "no rule",
    "meta_data": null,
    "state": null,
    "complete": false,
    "result": false,
    "result_string": "Pending",
    "credential_exchange_id": [
      "5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134"
    ],
    "error": "",
    "created_at": "2025-01-03T12:57:35.090Z",
    "updated_at": "2025-01-03T12:57:37.842Z"
  }
```

## Credentials - Read All Credential Records

```
/api/v1/credentials - GET
```

This endpoint fetches all Credential records.

**Request Body Information:**

No request body

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>credential_exchange_id</td><td>string</td><td>5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134</td><td>Primary identifier for the credential record</td></tr><tr><td>wallet_id</td><td>string</td><td>f20823bb-9079-4026-b9dc-a7f410af5141</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>credential_id</td><td>string</td><td>null</td><td>Unique ID for held credentials</td></tr><tr><td>revocation_id</td><td>string</td><td>null</td><td>Identifier used for credential revocation</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Unique identifier that ties a connection to this record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the credential</td></tr><tr><td>thread_id</td><td>string</td><td>a6ab28e8-1576-4174-8083-e52752327057</td><td>Thread identifier for the credential</td></tr><tr><td>parent_thread_id</td><td>string</td><td>null</td><td>Parent thread identifier for the credential</td></tr><tr><td>schema_id</td><td>string</td><td>KT4LtL7HEMePqQSyKVof7g:2:Email:1.0</td><td>Credentials schema</td></tr><tr><td>credential_definition_id</td><td>string</td><td>JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default</td><td>Credential definition generated via the schema_id</td></tr><tr><td>revoc_reg_id</td><td>string</td><td>null</td><td>Field used for credential revocation</td></tr><tr><td>revoked</td><td>boolean</td><td>null</td><td>Field used for credential revocation</td></tr><tr><td>attributes</td><td>object</td><td>{...}</td><td>Credentials attributes and their values</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-03T12:57:37.827Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-03T12:57:37.827Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
    "credential_exchange_id": "5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134",
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "credential_id": null,
    "revocation_id": null,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "state": "done",
    "thread_id": "a6ab28e8-1576-4174-8083-e52752327057",
    "parent_thread_id": null,
    "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0",
    "credential_definition_id": "JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default",
    "revoc_reg_id": null,
    "revoked": null,
    "created_at": "2025-01-03T12:57:37.827Z",
    "updated_at": "2025-01-03T13:05:35.231Z",
    "attributes": null
  }
]
```

## Credentials - Read Credential Record By ID

```
/api/v1/credentials/<credential_definition_id> - GET
```

This endpoint fetches a Credential record by its `credential_definition_id`.

**Request Body Information:**

No Request body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="200"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>credential_exchange_id</td><td>string</td><td>5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134</td><td>Primary identifier for the credential record</td></tr><tr><td>wallet_id</td><td>string</td><td>f20823bb-9079-4026-b9dc-a7f410af5141</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>credential_id</td><td>string</td><td>null</td><td>Unique ID for held credentials</td></tr><tr><td>revocation_id</td><td>string</td><td>null</td><td>Identifier used for credential revocation</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Unique identifier that ties a connection to this record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the credential</td></tr><tr><td>thread_id</td><td>string</td><td>a6ab28e8-1576-4174-8083-e52752327057</td><td>Thread identifier for the credential</td></tr><tr><td>parent_thread_id</td><td>string</td><td>null</td><td>Parent thread identifier for the credential</td></tr><tr><td>schema_id</td><td>string</td><td>KT4LtL7HEMePqQSyKVof7g:2:Email:1.0</td><td>Credentials schema</td></tr><tr><td>credential_definition_id</td><td>string</td><td>JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default</td><td>Credential definition generated via the schema_id</td></tr><tr><td>revoc_reg_id</td><td>string</td><td>null</td><td>Field used for credential revocation</td></tr><tr><td>revoked</td><td>boolean</td><td>null</td><td>Field used for credential revocation</td></tr><tr><td>attributes</td><td>object</td><td>{...}</td><td>Credential’s attributes and their values</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-03T12:57:37.827Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-03T12:57:37.827Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
    "credential_exchange_id": "5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134",
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "credential_id": null,
    "revocation_id": null,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "state": "done",
    "thread_id": "a6ab28e8-1576-4174-8083-e52752327057",
    "parent_thread_id": null,
    "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0",
    "credential_definition_id": "JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default",
    "revoc_reg_id": null,
    "revoked": null,
    "created_at": "2025-01-03T12:57:37.827Z",
    "updated_at": "2025-01-03T13:05:35.231Z",
    "attributes": null
}
```

## DIDs

## DIDs - Create New DID

```
/api/v1/create-did - POST
```

This endpoint creates a new decentralized identifier (DID).

**Request Body Information:**

No request body

### **Response Body Information:**

| **Field name** | <p><strong>Expected type/</strong></p><p><strong>values</strong></p> | **Examples**                                | **Notes**                          |
| -------------- | -------------------------------------------------------------------- | ------------------------------------------- | ---------------------------------- |
| did            | string                                                               | AwUCmb3ahPhiYVaik3wD7                       | Decentralized identifier           |
| verkey         | string                                                               | 6RCKgJhNz76u98RpzVYMrrXDEgPn3hZ5mvwyJnjvevP | DID’s verkey                       |
| posture        | string                                                               | wallet\_only                                | Posture of the DID                 |
| key\_type      | string                                                               | ed25519                                     | Type of key used for the DID       |
| method         | string                                                               | sov                                         | Method used for generating the DID |
| metadata       | object                                                               | {...}                                       | Metadata for the DID               |

### **Sample Response Body:**

```
{
  "did": "AwUCmb3ahPhiYVaik3wD7",
  "verkey": "6RCKgJhNz76u98RpzVYMrrXDEgPn3hZ5mvwyJnjvevP",
  "posture": "wallet_only",
  "key_type": "ed25519",
  "method": "sov",
  "metadata": {}
}
```

## DIDs - Set Public DID

```
/api/v1/set-public-did - POST
```

This endpoint sets a public decentralized identifier (DID).

**Request URL Parameters Information:**

| **Field name** | **Expected type/ values** | **Examples**           | **Notes**         |
| -------------- | ------------------------- | ---------------------- | ----------------- |
| DID            | text                      | XhvSpiDsLVmStHa19VC4hJ | DID set as public |

**Request Body Information:**

No request body

**Sample URLs:**

```
https://your-domain-name.com/api/v1/set-public-did?DID=WSPiMexQfuVrR9wMQbg5F7
```

### **Response Body Information:**

| **Field name** | **Expected type/ values** | **Examples**                                 | **Notes**                          |
| -------------- | ------------------------- | -------------------------------------------- | ---------------------------------- |
| did            | string                    | XhvSpiDsLVmStHa19VC4hJ                       | DID set as public                  |
| verkey         | string                    | HjfSSD6DDPfAME5Th5NTESEoToJgVWqUo7u81euPGX7K | DID’s verkey                       |
| posture        | string                    | posted                                       | Posture of the DID                 |
| key\_type      | string                    | ed25519                                      | Type of key used for the DID       |
| method         | string                    | sov                                          | Method used for generating the DID |
| metadata       | object                    | {...}                                        | Metadata for the DID               |

### **Sample Response Body:**

```
{
  "did": "XhvSpiDsLVmStHa19VC4hJ",
  "verkey": "HjfSSD6DDPfAME5Th5NTESEoToJgVWqUo7u81euPGX7K",
  "posture": "posted",
  "key_type": "ed25519",
  "method": "sov",
  "metadata": {
    "posted": true
  }
}
```

## Email

#### Email - Verify Email Addresses

```
/api/v1/emails/verify - POST
```

This endpoint verifies multiple email addresses using the SMTP configurations.&#x20;

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="158"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>emails</td><td>array</td><td>[ {“email”: “alice@example.com”} ]</td><td>List of emails to verify</td></tr></tbody></table>

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="159"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>success</td><td>string</td><td>“All emails sent successfully”</td><td>Success message</td></tr></tbody></table>

### **Sample Response Body:**

```
{
    "success": "All emails sent successfully!"
}
```

## Invitations

#### Invitations - Create New Invitation

```
/api/v1/invitations - POST
```

This endpoint creates a new invitation of type OOB or CV1.

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_type</td><td>text</td><td>OOB</td><td>CV1 or OOB (Connections v. 1 or Out of Band)</td></tr><tr><td>contact_id</td><td>text</td><td>blank</td><td>Optional contact string used for calls that require a known contact</td></tr><tr><td>handshake_protocol</td><td>text</td><td>https://didcomm.org/didexchange/1.1</td><td>Protocol used to generate the invitation</td></tr><tr><td>alias</td><td>text</td><td>Acme Issuer</td><td>String for how this connection could be labeled in the receiving agent. Technically optional, but probably a bad idea to leave empty</td></tr><tr><td>invitation_mode</td><td>text</td><td>Once</td><td>Multi, Once (or "Static," but for developers use only). TODO: Multi requires the use of a multi-use webhook in order for the other APIs to work.</td></tr><tr><td>accept</td><td>text</td><td>Auto</td><td>Auto, Manual</td></tr><tr><td>public</td><td>boolean</td><td>false</td><td>true or false</td></tr><tr><td>invitation_role</td><td>text</td><td>blank</td><td>Optional string describing this connection's role (such as "holder")</td></tr><tr><td>invitation_label</td><td>text</td><td>Create Account</td><td>Optional string for naming this invitation in the sending agent</td></tr><tr><td>invitation_status</td><td>text</td><td>blank</td><td>Optional; Active, Inactive, Deleted; this is not an ACA-Py field, but allows our controller to utilize invitations intelligently. Defaults to Active</td></tr><tr><td>invitation_description</td><td>text</td><td>blank</td><td>Optional string describing the purpose of this invitation</td></tr><tr><td>invitation_active_starting_at</td><td>timestamp</td><td>blank</td><td>Optional unix timestamp stating when the controller should begin recognizing this invitation as active. If not provided, set to the current time. Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>invitation_active_ending_at</td><td>timestamp</td><td>blank</td><td>Optional unix timestamp stating when the controller should stop recognizing this invitation as active. Can be null (doesn't end). Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>uses_allowed</td><td>int</td><td>blank</td><td>Optional number of uses the controller will allow this invitation. Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr></tbody></table>

### **Sample Request Bodies:**

Invitation with connection reuse:

```
{ 
  "contact_id": "contact123", 
  "handshake_protocol": "https://didcomm.org/didexchange/1.1",
  "invitation_type": "OOB", 
  "invitation_mode": "once", 
  "public": true, 
  "accept": "auto",
  "alias": "API invitation with connection reuse"
  "invitation_role": "Holder",
  "invitation_label": "API Invite",
  "invitation_description": "Invitation created through API", 
  "invitation_status": "active", 
  "invitation_active_starting_at": null, 
  "invitation_active_ending_at": null, 
  "invitation_uses_allowed": null
}
```

Invitation without connection reuse:

```
{ 
  "contact_id": "contact123",
  "handshake_protocol": "https://didcomm.org/didexchange/1.1",
  "invitation_type": "OOB", 
  "invitation_mode": "once", 
  "public": false, 
  "accept": "auto",
  "alias": "API invitation without connection reuse"
  "invitation_role": "Holder",
  "invitation_label": "API Invite",
  "invitation_description": "Invitation created through API", 
  "invitation_status": "active", 
  "invitation_active_starting_at": null, 
  "invitation_active_ending_at": null, 
  "invitation_uses_allowed": null
}
```

Invitation with multi-use:

```
{ 
  "contact_id": "contact123",
  "handshake_protocol": "https://didcomm.org/didexchange/1.1",
  "invitation_type": "OOB", 
  "invitation_mode": "multi", 
  "public": false, 
  "accept": "auto",
  "alias": "API invitation with multi-use"
  "invitation_role": "Holder",
  "invitation_label": "API Invite", 
  "invitation_description": "Invitation created through API", 
  "invitation_status": "active", 
  "invitation_active_starting_at": null, 
  "invitation_active_ending_at": null, 
  "invitation_uses_allowed": null
}
```

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_url</td><td>text</td><td>https://proven.mediator.indiciotech.io?oob...</td><td>Invitation URL (currently formatted for either connections v. 1 or OOB)</td></tr><tr><td>invitation_id</td><td>int</td><td>37</td><td>ID to keep track of this particular invitation</td></tr><tr><td>contact_id</td><td>text</td><td>“contact123”</td><td>Contact ID specified during the creation of this invitation</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "invitation_url": "https://proven.mediator.indiciotech.io?c_i=...",
  "invitation_id": 37,
  "contact_id": "49"
}
```

## Invitations - Accept Invitation

```
/api/v1/invitations/accept - POST
```

This endpoint accepts an invitation of type CV1 or OOB.

### **Request Body Information**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_url</td><td>text</td><td>https://proven.mediator.indiciotech.io?oob...</td><td>Properly encoded connections v. 1 or OOB invitation</td></tr></tbody></table>

### **Sample Request Body:**

```
{ 
  "invitation_url": "https://proven.mediator.indiciotech.io?c_i...",   
}
```

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>success</td><td>boolean</td><td>true</td><td>Signals successful invitation acceptance</td></tr><tr><td>invitation_record</td><td>object</td><td>{...}</td><td>Invitation record data object</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "success": true,
  "invitation_record": {
      "state": "deleted",
      "created_at": "2024-12-30T10:37:30.751037Z",
      "updated_at": "2024-12-30T10:37:30.751037Z",
      "trace": false,
      "oob_id": "2f5ce0d7-dfd4-4aef-871f-eb0a522a2f52",
      "invi_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
      "invitation": {...},
      "connection_id": "65eb5586-e519-441d-a05c-c3c697ecd97a",
      "role": "receiver",
      "multi_use": false
  }
}
```

## Invitations - Read All Invitations

```
/api/v1/invitations - GET
```

This endpoint fetches all invitations, and includes parameters for pagination purposes.&#x20;

**Requests URL Parameters Information:**

URL parameters should be hyphen-separated in case they ever interact with a system that needs to be search-engine-indexed.

<table data-header-hidden><thead><tr><th width="174"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>sort-field</td><td>text</td><td>contact_id</td><td>Optional, any of the field names listed in the "Create invitation" POST body plus invitation_id</td></tr><tr><td>sort-direction</td><td>text</td><td>ASC</td><td>Optional, ASC or DESC</td></tr><tr><td>page-size</td><td>int</td><td>10</td><td>Optional, how many items should be returned in a page</td></tr><tr><td>current-page</td><td>int</td><td>2</td><td>Optional, the current page to retrieve</td></tr><tr><td>item-count</td><td>int</td><td>10</td><td>Optional, the total number of items</td></tr></tbody></table>

### **Sample URLs:**

```
https://your-domain-name.com/api/v1/invitations?sort-field=contact_id&sort-direction=ASC&page-size=10&current-page=2
```

```
https://your-domain-name.com/api/v1/invitations?page-size=50&current-page=5
```

**Response Body Information:**

The Response Body has three sections:

* Params: The pagination and sorting parameters:
  * `"sort": “DESC”`
  * `pageSize": "10"`
  * `"currentPage": 1`
  * `"pageCount": 1`
  * `"itemCount": 1`
* Rows: The array of invitations
  * Each row in the rows array has the properties found in the table below.
* Count: The number of items returned:
  * `“count”: 1`

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>int</td><td>4325</td><td>Integer used as the primary identifier for this record</td></tr><tr><td>oob_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify an Out of Band (OOB) connection</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Contact ID string</td></tr><tr><td>connection_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify a CV1 connection</td></tr><tr><td>my_did</td><td>text</td><td>did:sov:&#x3C;did></td><td>Public DID (empty if invitation is not public)</td></tr><tr><td>alias</td><td>text</td><td>Acme Issuer</td><td>String for how this connection should be "named"</td></tr><tr><td>invitation_key</td><td>text</td><td>did:key:&#x3C;...></td><td>Invitation Key managed by agent</td></tr><tr><td>invitation_mode</td><td>text</td><td>Once</td><td>Multi, Once (or "Static," but for developers use only)</td></tr><tr><td>invitation_url</td><td>text</td><td>https://&#x3C;domain>?oob=&#x3C;base64 invitation></td><td>Invitation URL (CV1 or OOB)</td></tr><tr><td>invitation_msg_id</td><td>text</td><td>afbc12b7-28fa-4936-bf11-748148a98ffc</td><td>Unique Identifier for invitation exchange</td></tr><tr><td>invitation</td><td>obj</td><td>{...}</td><td>Invitation data object</td></tr><tr><td>wallet_id</td><td>text</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Identifier for the wallet the invitation belongs to</td></tr><tr><td>accept</td><td>text</td><td>auto</td><td>auto, manual</td></tr><tr><td>their_role</td><td>text</td><td>sender</td><td>Role of agent that generated the invitation</td></tr><tr><td>their_label</td><td>text</td><td>Primary Wallet</td><td>Label of agent/wallet that generated the invitation</td></tr><tr><td>service_endpoint</td><td>text</td><td>https://hard-tiger-38.tun2.indiciotech.io</td><td>Endpoint used for serving the Invitation URL</td></tr><tr><td>domain</td><td>text</td><td><p>hard-tiger-38.tun2.indiciotech.io</p><p><br></p></td><td>Domain parsed from service_endpoint</td></tr><tr><td>path</td><td>text</td><td>/path</td><td>Path parsed from service_endpoint</td></tr><tr><td>workflow_status</td><td>text</td><td>active</td><td>active, inactive (managed by controller)</td></tr><tr><td>state</td><td>text</td><td>deleted</td><td>State of the invitation (managed by ACA-Py agent)</td></tr><tr><td>description</td><td>text</td><td>General purpose issuer</td><td>Optional string describing the purpose of this invitation</td></tr><tr><td>active_starting_at</td><td>timestamp</td><td>2024-12-30T10:36:52.443Z</td><td>Optional unix timestamp stating when the controller should begin recognizing this invitation as active. If not provided, set to the current time. Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>active_ending_at</td><td>timestamp</td><td>null</td><td>Optional unix timestamp stating when the controller should stop recognizing this invitation as active. Can be null (doesn't end). Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>uses_allowed</td><td>int</td><td>100</td><td>Optional number of uses the controller will allow for this invitation. Caution, the controller can be bypassed and does not strictly control ACA-Py. The null value signals an infinite use invitation.</td></tr><tr><td>uses_total</td><td>int</td><td>43</td><td>Number of times this invitation has been used</td></tr><tr><td>created_at</td><td>timestamp</td><td><p>"2024-12-30T10:36:52.466Z"</p><p><br></p></td><td>Date of creation for the invitation record (controller level)</td></tr><tr><td>updated_at</td><td>timestamp</td><td>"2024-12-30T10:36:52.466Z"</td><td>Date the invitation record was last updated (controller level)</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "params": {
      "sort": [
          [
              [
                  "updated_at",
                  "DESC"
              ]
          ]
      ],
      "pageSize": "10",
      "currentPage": 1,
      "pageCount": 1,
      "itemCount": 1
  },
  "rows": [
      {
          "invitation_id": 1,
          "oob_id": "c2e4e2d2-eb01-4065-94e3-6d4c0e17d537",
          "contact_id": "199e022b-bb4c-4ae4-99fe-395b50ad4b66",
          "connection_id": "f7699aa9-beec-4e0c-868d-eb3766ad2f64",
          "my_did": "",
          "alias": "Proven",
          "invitation_key": "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV",
          "invitation_mode": "once",
          "invitation_url": "https://hard-tiger-38.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJhZmJjMTJiNy0yOGZhLTQ5MzYtYmYxMS03NDgxNDhhOThmZmMiLCAibGFiZWwiOiAiUHJpbWFyeVdhbGxldCIsICJoYW5kc2hha2VfcHJvdG9jb2xzIjogWyJodHRwczovL2RpZGNvbW0ub3JnL2RpZGV4Y2hhbmdlLzEuMCJdLCAic2VydmljZXMiOiBbeyJpZCI6ICIjaW5saW5lIiwgInR5cGUiOiAiZGlkLWNvbW11bmljYXRpb24iLCAicmVjaXBpZW50S2V5cyI6IFsiZGlkOmtleTp6Nk1ra2hmdFFqTkF6TkdZdzl2U1RLV25rZEVRTVJkenBYVG9Bd3dwNFF0YlJQU1YjejZNa2toZnRRak5Bek5HWXc5dlNUS1dua2RFUU1SZHpwWFRvQXd3cDRRdGJSUFNWIl0sICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9oYXJkLXRpZ2VyLTM4LnR1bjIuaW5kaWNpb3RlY2guaW8ifV19",
          "invitation_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
          "invitation": {...},
          "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
          "accept": "auto",
          "their_role": "sender",
          "their_label": "PrimaryWallet",
          "service_endpoint": "https://hard-tiger-38.tun2.indiciotech.io",
          "domain": "hard-tiger-38.tun2.indiciotech.io",
          "path": "",
          "workflow_status": "inactive",
          "state": "deleted",
          "description": "",
          "active_starting_at": "2024-12-30T10:36:52.443Z",
          "active_ending_at": n
```

## Invitations - Read Invitation by ID

```
/api/v1/invitations/<invitation_id> - GET
```

This endpoint fetches a single invitation record by its `invitation_id`.

**Request Body Information:**

No Request Body

### Response Body Information:

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>int</td><td>4325</td><td>Integer used as the primary identifier for this record</td></tr><tr><td>oob_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify an Out of Band (OOB) connection</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Contact ID string</td></tr><tr><td>connection_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify a CV1 connection</td></tr><tr><td>my_did</td><td>text</td><td>did:sov:&#x3C;did></td><td>Public DID (empty if invitation is not public)</td></tr><tr><td>alias</td><td>text</td><td>Acme Issuer</td><td>String for how this connection should be "named"</td></tr><tr><td>invitation_key</td><td>text</td><td>did:key:&#x3C;...></td><td>Invitation Key managed by agent</td></tr><tr><td>invitation_mode</td><td>text</td><td>Once</td><td>Multi, Once (or "Static," but for developers use only)</td></tr><tr><td>invitation_url</td><td>text</td><td>https://&#x3C;domain>?oob=&#x3C;base64 invitation></td><td>Invitation URL (CV1 or OOB)</td></tr><tr><td>invitation_msg_id</td><td>text</td><td>afbc12b7-28fa-4936-bf11-748148a98ffc</td><td>Unique Identifier for invitation exchange</td></tr><tr><td>invitation</td><td>obj</td><td>{...}</td><td>Invitation data object</td></tr><tr><td>wallet_id</td><td>text</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Identifier for the wallet the invitation belongs to</td></tr><tr><td>accept</td><td>text</td><td>auto</td><td>auto, manual</td></tr><tr><td>their_role</td><td>text</td><td>sender</td><td>Role of the agent that generated the invitation</td></tr><tr><td>their_label</td><td>text</td><td>Primary Wallet</td><td>Label of the agent/wallet that generated the invitation</td></tr><tr><td>service_endpoint</td><td>text</td><td>https://hard-tiger-38.tun2.indiciotech.io</td><td>Endpoint used for serving the Invitation URL</td></tr><tr><td>domain</td><td>text</td><td><p>hard-tiger-38.tun2.indiciotech.io</p><p><br></p></td><td>Domain parsed from service_endpoint</td></tr><tr><td>path</td><td>text</td><td>/path</td><td>Path parsed from service_endpoint</td></tr><tr><td>workflow_status</td><td>text</td><td>active</td><td>active, inactive (managed by controller)</td></tr><tr><td>state</td><td>text</td><td>deleted</td><td>State of the invitation (managed by ACA-Py agent)</td></tr><tr><td>description</td><td>text</td><td>General purpose issuer</td><td>Optional string describing the purpose of this invitation</td></tr><tr><td>active_starting_at</td><td>timestamp</td><td>2024-12-30T10:36:52.443Z</td><td>Optional unix timestamp stating when the controller should begin recognizing this invitation as active. If not provided, set to the current time. Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>active_ending_at</td><td>timestamp</td><td>null</td><td>Optional unix timestamp stating when the controller should stop recognizing this invitation as active. Can be null (doesn't end). Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>uses_allowed</td><td>int</td><td>100</td><td>Optional number of uses the controller will allow for this invitation. Caution, the controller can be bypassed and does not strictly control ACA-Py. The null value signals an infinite use invitation.</td></tr><tr><td>uses_total</td><td>int</td><td>43</td><td>Number of times this invitation has been used</td></tr><tr><td>created_at</td><td>timestamp</td><td><p>"2024-12-30T10:36:52.466Z"</p><p><br></p></td><td>Date of creation for the invitation record (controller level)</td></tr><tr><td>updated_at</td><td>timestamp</td><td>"2024-12-30T10:36:52.466Z"</td><td>Date the invitation record was last updated (controller level)</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "invitation_id": 1,
  "oob_id": "c2e4e2d2-eb01-4065-94e3-6d4c0e17d537",
  "contact_id": "199e022b-bb4c-4ae4-99fe-395b50ad4b66",
  "connection_id": "f7699aa9-beec-4e0c-868d-eb3766ad2f64",
  "my_did": "",
  "alias": "Proven",
  "invitation_key": "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV",
  "invitation_mode": "once",
  "invitation_url": "https://hard-tiger-38.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJhZmJjMTJiNy0yOGZhLTQ5MzYtYmYxMS03NDgxNDhhOThmZmMiLCAibGFiZWwiOiAiUHJpbWFyeVdhbGxldCIsICJoYW5kc2hha2VfcHJvdG9jb2xzIjogWyJodHRwczovL2RpZGNvbW0ub3JnL2RpZGV4Y2hhbmdlLzEuMCJdLCAic2VydmljZXMiOiBbeyJpZCI6ICIjaW5saW5lIiwgInR5cGUiOiAiZGlkLWNvbW11bmljYXRpb24iLCAicmVjaXBpZW50S2V5cyI6IFsiZGlkOmtleTp6Nk1ra2hmdFFqTkF6TkdZdzl2U1RLV25rZEVRTVJkenBYVG9Bd3dwNFF0YlJQU1YjejZNa2toZnRRak5Bek5HWXc5dlNUS1dua2RFUU1SZHpwWFRvQXd3cDRRdGJSUFNWIl0sICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9oYXJkLXRpZ2VyLTM4LnR1bjIuaW5kaWNpb3RlY2guaW8ifV19",
  "invitation_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
  "invitation": {
      "@type": "https://didcomm.org/out-of-band/1.1/invitation",
      "@id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
      "label": "PrimaryWallet",
      "handshake_protocols": [
          "https://didcomm.org/didexchange/1.0"
      ],
      "services": [
          {
              "id": "#inline",
              "type": "did-communication",
              "recipientKeys": [
                  "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV"
              ],
              "serviceEndpoint": "https://hard-tiger-38.tun2.indiciotech.io"
          }
      ]
  },
  "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
  "accept": "auto",
  "their_role": "sender",
  "their_label": "PrimaryWallet",
  "service_endpoint": "https://hard-tiger-38.tun2.indiciotech.io",
  "domain": "hard-tiger-38.tun2.indiciotech.io",
  "path": "",
  "workflow_status": "inactive",
  "state": "deleted",
  "description": "",
  "active_starting_at": "2024-12-30T10:36:52.443Z",
  "active_ending_at": null,
  "uses_allowed": 1,
  "uses_total": 1,
  "created_at": "2024-12-30T10:36:52.466Z",
  "updated_at": "2024-12-30T10:37:31.732Z"
}
```

## Invitations - Update Invitation Record

```
/api/v1/invitations/<invitation_id> - PUT
```

This endpoint updates an existing invitation record by using its `invitation_id`.

**Request Body Information:**

The following fields can be selectively provided:

<table data-header-hidden><thead><tr><th width="173"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>workflow_status</td><td>string</td><td>inactive</td><td>Controls usage and availability of invitation (controller level only) </td></tr><tr><td>description</td><td>string</td><td>Updating invitation description via API</td><td>Invitation’s general use description</td></tr><tr><td>active_starting_at</td><td>timestamp</td><td>2024-12-30T10:36:52.466Z</td><td>Controls invitation’s workflow_status (active or inactive) (controller level only)</td></tr><tr><td>active_ending_at</td><td>string</td><td>2025-12-30T10:36:52.466Z</td><td>Controls invitation’s workflow_status (active or inactive) (controller level only)</td></tr><tr><td>uses_allowed</td><td>integer</td><td>20</td><td>Limits the usage of multi-use invitations. Single-use invitations default to 1 and cannot be updated (controller level only).</td></tr></tbody></table>

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>int</td><td>4325</td><td>Integer used as the primary identifier for this record</td></tr><tr><td>oob_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify an Out of Band (OOB) connection</td></tr><tr><td>contact_id</td><td>text</td><td>contact123</td><td>Contact ID string</td></tr><tr><td>connection_id</td><td>text</td><td>db6da148-33ee-4108-96d9-f39bee835981</td><td>ID used to identify a CV1 connection</td></tr><tr><td>my_did</td><td>text</td><td>did:sov:&#x3C;did></td><td>Public DID (empty if invitation is not public)</td></tr><tr><td>alias</td><td>text</td><td>Acme Issuer</td><td>String for how this connection should be "named" or referred to, especially in the UI</td></tr><tr><td>invitation_key</td><td>text</td><td>did:key:&#x3C;...></td><td>Invitation Key managed by agent</td></tr><tr><td>invitation_mode</td><td>text</td><td>Once</td><td>Multi, Once (or "Static," but for developers use only)</td></tr><tr><td>invitation_url</td><td>text</td><td>https://&#x3C;domain>?oob=&#x3C;base64 invitation></td><td>Invitation URL (CV1 or OOB)</td></tr><tr><td>invitation_msg_id</td><td>text</td><td>afbc12b7-28fa-4936-bf11-748148a98ffc</td><td>Unique Identifier for invitation exchange</td></tr><tr><td>invitation</td><td>obj</td><td>{...}</td><td>Invitation data object </td></tr><tr><td>wallet_id</td><td>text</td><td>eea19d5b-cbfc-44a0-9406-a9bddcbe3994</td><td>Identifier for the wallet the invitation belongs to</td></tr><tr><td>accept</td><td>text</td><td>auto</td><td>auto, manual</td></tr><tr><td>their_role</td><td>text</td><td>sender</td><td>Role of agent that generated the invitation</td></tr><tr><td>their_label</td><td>text</td><td>Primary Wallet</td><td>Label of agent/wallet that generated the invitation</td></tr><tr><td>service_endpoint</td><td>text</td><td>https://hard-tiger-38.tun2.indiciotech.io</td><td>Endpoint used for serving the Invitation URL</td></tr><tr><td>domain</td><td>text</td><td>hard-tiger-38.tun2.indiciotech.io</td><td>Domain parsed from service_endpoint</td></tr><tr><td>path</td><td>text</td><td>/path</td><td>Path parsed from service_endpoint</td></tr><tr><td>workflow_status</td><td>text</td><td>active</td><td>active, inactive (managed by controller) </td></tr><tr><td>state</td><td>text</td><td>deleted</td><td>State of the invitation (managed by ACA-Py agent)</td></tr><tr><td>description</td><td>text</td><td>General purpose issuer</td><td>Optional string describing the purpose of this invitation</td></tr><tr><td>active_starting_at</td><td>timestamp</td><td>2024-12-30T10:36:52.443Z</td><td>Optional unix timestamp stating when the controller should begin recognizing this invitation as active. If not provided, set to the current time. Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>active_ending_at</td><td>timestamp</td><td>null</td><td>Optional unix timestamp stating when the controller should stop recognizing this invitation as active. Can be null (does not end). Caution, the controller can be bypassed and does not strictly control ACA-Py.</td></tr><tr><td>uses_allowed</td><td>int</td><td>100</td><td>Optional number of uses the controller will allow for this invitation. Caution, the controller can be bypassed and does not strictly control ACA-Py. The null value signals an infinite use invitation.</td></tr><tr><td>uses_total</td><td>int</td><td>43</td><td>Number of times this invitation has been used</td></tr><tr><td>created_at</td><td>timestamp</td><td><p>"2024-12-30T10:36:52.466Z"</p><p><br></p></td><td>Date of creation for the invitation record (controller level)</td></tr><tr><td>updated_at</td><td>timestamp</td><td>"2024-12-30T10:36:52.466Z"</td><td>Date the invitation record was last updated (controller level)</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "invitation_id": 1,
  "oob_id": "c2e4e2d2-eb01-4065-94e3-6d4c0e17d537",
  "contact_id": "199e022b-bb4c-4ae4-99fe-395b50ad4b66",
  "connection_id": "f7699aa9-beec-4e0c-868d-eb3766ad2f64",
  "my_did": "",
  "alias": "Proven",
  "invitation_key": "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV",
  "invitation_mode": "once",
  "invitation_url": "https://hard-tiger-38.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJhZmJjMTJiNy0yOGZhLTQ5MzYtYmYxMS03NDgxNDhhOThmZmMiLCAibGFiZWwiOiAiUHJpbWFyeVdhbGxldCIsICJoYW5kc2hha2VfcHJvdG9jb2xzIjogWyJodHRwczovL2RpZGNvbW0ub3JnL2RpZGV4Y2hhbmdlLzEuMCJdLCAic2VydmljZXMiOiBbeyJpZCI6ICIjaW5saW5lIiwgInR5cGUiOiAiZGlkLWNvbW11bmljYXRpb24iLCAicmVjaXBpZW50S2V5cyI6IFsiZGlkOmtleTp6Nk1ra2hmdFFqTkF6TkdZdzl2U1RLV25rZEVRTVJkenBYVG9Bd3dwNFF0YlJQU1YjejZNa2toZnRRak5Bek5HWXc5dlNUS1dua2RFUU1SZHpwWFRvQXd3cDRRdGJSUFNWIl0sICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9oYXJkLXRpZ2VyLTM4LnR1bjIuaW5kaWNpb3RlY2guaW8ifV19",
  "invitation_msg_id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
  "invitation": {
      "@type": "https://didcomm.org/out-of-band/1.1/invitation",
      "@id": "afbc12b7-28fa-4936-bf11-748148a98ffc",
      "label": "PrimaryWallet",
      "handshake_protocols": [
          "https://didcomm.org/didexchange/1.0"
      ],
      "services": [
          {
              "id": "#inline",
              "type": "did-communication",
              "recipientKeys": [
                  "did:key:z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV#z6MkkhftQjNAzNGYw9vSTKWnkdEQMRdzpXToAwwp4QtbRPSV"
              ],
              "serviceEndpoint": "https://hard-tiger-38.tun2.indiciotech.io"
          }
      ]
  },
  "wallet_id": "eea19d5b-cbfc-44a0-9406-a9bddcbe3994",
  "accept": "auto",
  "their_role": "sender",
  "their_label": "PrimaryWallet",
  "service_endpoint": "https://hard-tiger-38.tun2.indiciotech.io",
  "domain": "hard-tiger-38.tun2.indiciotech.io",
  "path": "",
  "workflow_status": "inactive",
  "state": "deleted",
  "description": "Updating invitation description via API",
  "active_starting_at": "2024-12-30T10:36:52.443Z",
  "active_ending_at": null,
  "uses_allowed": 1,
  "uses_total": 1,
  "created_at": "2024-12-30T10:36:52.466Z",
  "updated_at": "2024-12-30T10:37:31.732Z"
}
```

## Invitations - Delete Invitation

```
/api/v1/invitations/<invitation_id> - DELETE
```

This endpoint deletes an invitation record by providing its `invitation_id`.&#x20;

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="160"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>success</td><td>string</td><td>“Invitation 2 was deleted successfully!”</td><td>Success message</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "success": "Invitation 2 was deleted successfully!"
}
```

## Presentations

#### Presentations - Read All Presentations

```
/api/v1/presentations - GET
```

This endpoint fetches all presentation records.

**Request Body Information:**

No Request Body

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="179"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td>Examples</td><td><strong>Notes</strong></td></tr><tr><td>presentation_exchange_id</td><td>string</td><td>349c7662-6837-4274-b213-355dab5d92f2</td><td>Primary identifier used for the presentation record</td></tr><tr><td>wallet_id</td><td>string</td><td>f20823bb-9079-4026-b9dc-a7f410af5141</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>trace</td><td>boolean</td><td>false</td><td>Not used at present</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Unique identifier used for tying a connection to the presentation record</td></tr><tr><td>role</td><td>string</td><td>verifier</td><td>Role of the presentation</td></tr><tr><td>verified</td><td>boolean</td><td>true</td><td>Indicates a verified presentation</td></tr><tr><td>presentation_created_at</td><td>timestamp</td><td>2025-01-06T10:16:26.561Z</td><td>ACA-Py field</td></tr><tr><td>presentation_updated_at</td><td>timestamp</td><td>2025-01-06T10:16:26.561Z</td><td>ACA-Py field</td></tr><tr><td>presentation_request_dict</td><td>object</td><td>{...}</td><td>ACA-Py field</td></tr><tr><td>initiator</td><td>string</td><td>self</td><td>Initiator of the presentation</td></tr><tr><td>presentation_request</td><td>object</td><td>{...}</td><td>Request object of the presentation</td></tr><tr><td>state</td><td>string</td><td>request-sent</td><td>Current state of the presentation</td></tr><tr><td>thread_id</td><td>string</td><td>85e6c895-be08-4c1d-be5d-91ccd902b62c</td><td>Thread identifier for the presentation</td></tr><tr><td>auto_present</td><td>boolean</td><td>false</td><td>Parameter for automatically presenting the presentation</td></tr><tr><td>presentation</td><td>object</td><td>null</td><td>Main presentation data</td></tr><tr><td>contact_label</td><td>string</td><td>Alice Smith</td><td>Contact label for the presentation</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Identifier that ties the presentation to a contact</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T10:16:26.647Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T10:16:26.647Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
    "presentation_exchange_id": "349c7662-6837-4274-b213-355dab5d92f2",
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "trace": false,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "role": "verifier",
    "verified": false,
    "presentation_created_at": "2025-01-06T10:16:26.561Z",
    "presentation_updated_at": "2025-01-06T10:16:26.561Z",
    "presentation_request_dict": {
      "@type": "https://didcomm.org/present-proof/2.0/request-presentation",
      "@id": "85e6c895-be08-4c1d-be5d-91ccd902b62c",
      "comment": "Requesting Presentation v2.0",
      "will_confirm": true,
      "formats": [
        {
          "attach_id": "indy",
          "format": "hlindy/proof-req@v2.0"
        }
      ],
      "request_presentations~attach": [
        {
          "@id": "indy",
          "mime-type": "application/json",
          "data": {
            "base64": "eyJuYW1lIjogIlByb29mIFJlcXVlc3QgdjIiLCAibm9uY2UiOiAiMTQ0MTI3ODcxMzAxMjI1NTU3MTQzNTcyMjUxODkxNjk4MDIyMTE1OTM4MTA1MTY1MjI3MTQ0MjAyMzYyNDM0OTI0MTMxMTA4MjAyNTYyMDMxMzQzNDY1ODEwODIyOTc4ODIxMCIsICJyZXF1ZXN0ZWRfcHJlZGljYXRlcyI6IHt9LCAicmVxdWVzdGVkX2F0dHJpYnV0ZXMiOiB7IjljOGM5YTVlLTg4YzctNGIxNy05ODk4LTExYzVhMTZiNzRjNiI6IHsibmFtZXMiOiBbInZlcmlmaWVkX2F0IiwgImxvY2FsX3BhcnQiLCAiYWRkcmVzcyIsICJkb21haW4iXSwgInJlc3RyaWN0aW9ucyI6IFt7InNjaGVtYV9pZCI6ICJLVDRMdEw3SEVNZVBxUVN5S1ZvZjdnOjI6RW1haWw6MS4wIn1dfX0sICJ2ZXJzaW9uIjogIjEuMCJ9"
          }
        }
      ]
    },
    "initiator": "self",
    "presentation_request": {
      "name": "Proof Request v2",
      "nonce": "1441278713012255571435722518916980221159381051652271442023624349241311082025620313434658108229788210",
      "requested_predicates": {},
      "requested_attributes": {
        "9c8c9a5e-88c7-4b17-9898-11c5a16b74c6": {
          "names": [
            "verified_at",
            "local_part",
            "address",
            "domain"
          ],
          "restrictions": [
            {
              "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0"
            }
          ]
        }
      },
      "version": "1.0"
    },
    "state": "request-sent",
    "thread_id": "85e6c895-be08-4c1d-be5d-91ccd902b62c",
    "auto_present": false,
    "presentation": null,
    "contact_label": "Alice Smith",
    "contact_id": "90c98aa3-5ef4-4f1a-8107-05cc0b08ed8b",
    "created_at": "2025-01-06T10:16:26.647Z",
    "updated_at": "2025-01-06T10:16:26.647Z"
  }
]
```

## Presentations - Read Presentation by ID

```
/api/v1/presentations/<presentation_exchange_id> - GET
```

This endpoint fetches a presentation record by its `presentation_exchange_id`.

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="178"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>presentation_exchange_id</td><td>string</td><td>349c7662-6837-4274-b213-355dab5d92f2</td><td>Primary identifier used for the presentation record</td></tr><tr><td>wallet_id</td><td>string</td><td>f20823bb-9079-4026-b9dc-a7f410af5141</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>trace</td><td>boolean</td><td>false</td><td>Not used at present</td></tr><tr><td>connection_id</td><td>string</td><td>cdcff763-5616-4a43-90ee-b0a38e0f6646</td><td>Unique identifier used for tying a connection to the presentation record</td></tr><tr><td>role</td><td>string</td><td>verifier</td><td>Role of the presentation</td></tr><tr><td>verified</td><td>boolean</td><td>true</td><td>Indicates a verified presentation</td></tr><tr><td>presentation_created_at</td><td>timestamp</td><td>2025-01-06T10:16:26.561Z</td><td>ACA-Py field</td></tr><tr><td>presentation_updated_at</td><td>timestamp</td><td>2025-01-06T10:16:26.561Z</td><td>ACA-Py field</td></tr><tr><td>presentation_request_dict</td><td>object</td><td>{...}</td><td>ACA-Py field</td></tr><tr><td>initiator</td><td>string</td><td>self</td><td>Initiator of the presentation</td></tr><tr><td>presentation_request</td><td>object</td><td>{...}</td><td>Request object of the presentation</td></tr><tr><td>state</td><td>string</td><td>request-sent</td><td>Current state of the presentation</td></tr><tr><td>thread_id</td><td>string</td><td>85e6c895-be08-4c1d-be5d-91ccd902b62c</td><td>Thread identifier for the presentation</td></tr><tr><td>auto_present</td><td>boolean</td><td>false</td><td>Parameter for automatically presenting the presentation</td></tr><tr><td>presentation</td><td>object</td><td>null</td><td>Main presentation data</td></tr><tr><td>contact_label</td><td>string</td><td>Alice Smith</td><td>Contact label for the presentation</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Identifier that ties the presentation to a contact</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T10:16:26.647Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T10:16:26.647Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
    "presentation_exchange_id": "349c7662-6837-4274-b213-355dab5d92f2",
    "wallet_id": "f20823bb-9079-4026-b9dc-a7f410af5141",
    "trace": false,
    "connection_id": "cdcff763-5616-4a43-90ee-b0a38e0f6646",
    "role": "verifier",
    "verified": false,
    "presentation_created_at": "2025-01-06T10:16:26.561Z",
    "presentation_updated_at": "2025-01-06T10:16:26.561Z",
    "presentation_request_dict": {
      "@type": "https://didcomm.org/present-proof/2.0/request-presentation",
      "@id": "85e6c895-be08-4c1d-be5d-91ccd902b62c",
      "comment": "Requesting Presentation v2.0",
      "will_confirm": true,
      "formats": [
        {
          "attach_id": "indy",
          "format": "hlindy/proof-req@v2.0"
        }
      ],
      "request_presentations~attach": [
        {
          "@id": "indy",
          "mime-type": "application/json",
          "data": {
            "base64": "eyJuYW1lIjogIlByb29mIFJlcXVlc3QgdjIiLCAibm9uY2UiOiAiMTQ0MTI3ODcxMzAxMjI1NTU3MTQzNTcyMjUxODkxNjk4MDIyMTE1OTM4MTA1MTY1MjI3MTQ0MjAyMzYyNDM0OTI0MTMxMTA4MjAyNTYyMDMxMzQzNDY1ODEwODIyOTc4ODIxMCIsICJyZXF1ZXN0ZWRfcHJlZGljYXRlcyI6IHt9LCAicmVxdWVzdGVkX2F0dHJpYnV0ZXMiOiB7IjljOGM5YTVlLTg4YzctNGIxNy05ODk4LTExYzVhMTZiNzRjNiI6IHsibmFtZXMiOiBbInZlcmlmaWVkX2F0IiwgImxvY2FsX3BhcnQiLCAiYWRkcmVzcyIsICJkb21haW4iXSwgInJlc3RyaWN0aW9ucyI6IFt7InNjaGVtYV9pZCI6ICJLVDRMdEw3SEVNZVBxUVN5S1ZvZjdnOjI6RW1haWw6MS4wIn1dfX0sICJ2ZXJzaW9uIjogIjEuMCJ9"
          }
        }
      ]
    },
    "initiator": "self",
    "presentation_request": {
      "name": "Proof Request v2",
      "nonce": "1441278713012255571435722518916980221159381051652271442023624349241311082025620313434658108229788210",
      "requested_predicates": {},
      "requested_attributes": {
        "9c8c9a5e-88c7-4b17-9898-11c5a16b74c6": {
          "names": [
            "verified_at",
            "local_part",
            "address",
            "domain"
          ],
          "restrictions": [
            {
              "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0"
            }
          ]
        }
      },
      "version": "1.0"
    },
    "state": "request-sent",
    "thread_id": "85e6c895-be08-4c1d-be5d-91ccd902b62c",
    "auto_present": false,
    "presentation": null,
    "contact_label": "Alice Smith",
    "contact_id": "90c98aa3-5ef4-4f1a-8107-05cc0b08ed8b",
    "created_at": "2025-01-06T10:16:26.647Z",
    "updated_at": "2025-01-06T10:16:26.647Z"
  }
```

## TAA

## TAA - Fetch the TAA

```
/api/v1/fetch-taa - POST
```

This endpoint fetches the Transaction Author Agreement (TAA) from the ledger configured in the Proven environment (.env) file.

**Request Body Information:**

No Request Body

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="173"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>aml_record</td><td>object</td><td>{...}</td><td>(Acceptance Mechanism List) Recognized by the network for use in the TAA </td></tr><tr><td>taa_record</td><td>object</td><td>{...}</td><td>Main TAA data</td></tr><tr><td>taa_required</td><td>boolean</td><td>true</td><td>Indicates a required TAA</td></tr><tr><td>taa_accepted</td><td>object</td><td>{...}</td><td>Includes data about the accepted TAA (mechanism, time)</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "aml_record": {
    "aml": {...},
    "amlContext": "...",
    "version": "1.0"
  },
  "taa_record": {
    "digest": "...",
    "ratification_ts": ...,
    "text": "...",
    "version": "1.3"
  },
  "taa_required": true,
  "taa_accepted": null
}
```

## TAA - Accept TAA

```
/api/v1/accept-taa - POST
```

This endpoint accepts the Transaction Author Agreement (TAA) using the provided TAA data.

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="175"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>mechanism</td><td>string</td><td>“on_file”</td><td>Mechanism used for the TAA</td></tr><tr><td>text</td><td>string</td><td>“Indicio Transaction Author Agreement….”</td><td>Transaction Author Agreement</td></tr><tr><td>version</td><td>string</td><td>1.3</td><td>Version of the Transaction Author Agreement</td></tr></tbody></table>

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>aml_record</td><td>object</td><td>{...}</td><td>(Acceptance Mechanism List) Recognized by the network for use in the TAA </td></tr><tr><td>taa_record</td><td>object</td><td>{...}</td><td>Main TAA data</td></tr><tr><td>taa_required</td><td>boolean</td><td>true</td><td>Indicates a required TAA</td></tr><tr><td>taa_accepted</td><td>object</td><td>{...}</td><td>Includes data about the accepted TAA (mechanism, time)</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "aml_record": {
    "aml": {...},
    "amlContext": "...",
    "version": "1.0"
  },
  "taa_record": {
    "digest": "...",
    "ratification_ts": ...,
    "text": "...",
    "version": "1.3"
  },
  "taa_required": true,
  "taa_accepted": {...}
```

## Verifications

## Verifications - Create Verification Request (AnonCred)

```
/api/v1/verifications - POST
```

This endpoint creates a Verification (AnonCred) request record that handles verifying credentials for currently active connection(s) or future active connection(s) until the request record reaches a completed state.&#x20;

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="177"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>schemas</td><td>array</td><td>[{...}, {...}]</td><td>Contains schema IDs and their attributes</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record before responding</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for this verification request</td></tr></tbody></table>

### **Sample Request Bodies:**

```
{
  "invitation_id": 1,
  "contact_id": "",
  "schemas": [
    {
      "schema_id": "Bo6yctq8hivGZWyaZcneJf:2:User:1.0",
      "schema_attributes": [
        "Username"
      ]
    }
  ],
  "timeout": "15",
  "rule": "no rule"
}
```

```
{
  "invitation_id": 1,
  "contact_id": "123",
  "schemas": [
    {
      "schema_attributes": {
        "domain": {
          "restrictions": [
            {
              "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Email:1.0"
            }
          ]
        },
        "address": {
          "restrictions": [
            {}
          ]
        },
        "age": {
          "restrictions": []
        },
        "race": {}
      }
    }
  ],
  "timeout": "15",
  "rule": "no rule"
}
```

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>verification_id</td><td>integer</td><td>10</td><td>Primary identifier for the verification request record</td></tr><tr><td>connection_id</td><td>string</td><td>e2aed3c4-c0a1-4711-902e-f0a9eba618da</td><td>Identifier that ties the used connection to the verification request record</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>schema_id</td><td>string</td><td>null</td><td>Schema used for the verification request</td></tr><tr><td>schema_attributes</td><td>object</td><td>{...}</td><td>Contains the schema attributes and their restrictions, if any are provided</td></tr><tr><td>wallet_id</td><td>string</td><td>407e6215-17c5-4c81-901e-d75d9cc1a75a</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request waited for a completed request record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for the verification request record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the verification</td></tr><tr><td>complete</td><td>boolean</td><td>true</td><td>This field does not indicate a verified presentation, only that the request record has finished its process. </td></tr><tr><td>result</td><td>boolean</td><td>true</td><td>Indicates a verified presentation. This field should be used alongside “complete” to determine a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>Verified</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>result_data</td><td>array</td><td>[...]</td><td>Contains the verified attributes</td></tr><tr><td>presentation_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each proof request</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing the request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
    "verification_id": 1,
    "connection_id": "e2aed3c4-c0a1-4711-902e-f0a9eba618da",
    "contact_id": "",
    "invitation_id": 1,
    "schema_id": null,
    "schema_attributes": {
      "Username": {
        "restrictions": [
          {
            "schema_id": "Bo6yctq8hivGZWyaZcneJf:2:User:1.0"
          }
        ]
      }
    },
    "wallet_id": "407e6215-17c5-4c81-901e-d75d9cc1a75a",
    "timeout": 15,
    "rule": "no rule",
    "meta_data": null,
    "state": "done",
    "complete": true,
    "result": true,
    "result_string": "Verified",
    "result_data": [
      {
        "name": "Username",
        "value": "AliceSmith"
      }
    ],
    "presentation_exchange_id": [
      "02ac589b-5463-4b0f-97a0-211221aaa54e"
    ],
    "error": "",
    "created_at": "2025-01-06T11:51:10.169Z",
    "updated_at": "2025-01-06T11:51:13.765Z"
  }
]
```

## Verifications - Read Verification by ID

```
/api/v1/verifications/<verification_id> - GET
```

This endpoint allows you to retrieve an AnonCred verification request record by its ID.

### **Response Body Information:**

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>verification_id</td><td>integer</td><td>10</td><td>Primary identifier for the verification request record</td></tr><tr><td>connection_id</td><td>string</td><td>e2aed3c4-c0a1-4711-902e-f0a9eba618da</td><td>Identifier that ties the used connection to the verification request record</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>schema_id</td><td>string</td><td>null</td><td>Schema used for the verification request</td></tr><tr><td>schema_attributes</td><td>object</td><td>{...}</td><td>Contains the schema attributes and their restrictions, if any are provided</td></tr><tr><td>wallet_id</td><td>string</td><td>407e6215-17c5-4c81-901e-d75d9cc1a75a</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request waited for a completed request record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for the verification request record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the verification</td></tr><tr><td>complete</td><td>boolean</td><td>true</td><td>This field does not indicate a verified presentation, only that the request record has finished its process. </td></tr><tr><td>result</td><td>boolean</td><td>true</td><td>Indicates a verified presentation. This field should be used alongside “complete” to determine a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>Verified</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>result_data</td><td>array</td><td>[...]</td><td>Contains the verified attributes</td></tr><tr><td>presentation_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each proof request</td></tr><tr><td>error</td><td>string</td><td>“Public DID not set.”</td><td>Error message caught while processing the request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
    "verification_id": 1,
    "connection_id": "e2aed3c4-c0a1-4711-902e-f0a9eba618da",
    "contact_id": "",
    "invitation_id": 1,
    "schema_id": null,
    "schema_attributes": {
      "Username": {
        "restrictions": [
          {
            "schema_id": "Bo6yctq8hivGZWyaZcneJf:2:User:1.0"
          }
        ]
      }
    },
    "wallet_id": "407e6215-17c5-4c81-901e-d75d9cc1a75a",
    "timeout": 15,
    "rule": "no rule",
    "meta_data": null,
    "state": "done",
    "complete": true,
    "result": true,
    "result_string": "Verified",
    "result_data": [
      {
        "name": "Username",
        "value": "AliceSmith"
      }
    ],
    "presentation_exchange_id": [
      "02ac589b-5463-4b0f-97a0-211221aaa54e"
    ],
    "error": "",
    "created_at": "2025-01-06T11:51:10.169Z",
    "updated_at": "2025-01-06T11:51:13.765Z"
}
```

## Verifications - Create Verification Request (JSON-LD)

```
/api/v1/verifications/json-ld - POST
```

This endpoint creates a Verification (JSON-LD) request record that handles verifying credentials for currently active connection(s) or future active connection(s) until the request record reaches a completed state.&#x20;

### **Request Body Information:**

<table data-header-hidden><thead><tr><th width="173"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>definitions</td><td>array</td><td>[{...}, {...}]</td><td>Definitions for the verification request. Contains context, attributes, and label</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request will wait for a completed record before responding</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr></tbody></table>

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>verification_id</td><td>integer</td><td>10</td><td>Primary identifier for the verification request record</td></tr><tr><td>connection_id</td><td>string</td><td>e2aed3c4-c0a1-4711-902e-f0a9eba618da</td><td>Identifier that ties the used connection to the verification request record</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>context</td><td>array</td><td>[“...”, “...”]</td><td>List of contexts used for this verification record</td></tr><tr><td>attributes</td><td>array</td><td>[...]</td><td>List of attributes to be verified</td></tr><tr><td>wallet_id</td><td>string</td><td>407e6215-17c5-4c81-901e-d75d9cc1a75a</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>label</td><td>string</td><td>Email</td><td>Label for the verification request record</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request waited for a completed request record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for the verification request record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the verification request record</td></tr><tr><td>complete</td><td>boolean</td><td>true</td><td>This field does not indicate a verified request record, only that the request record has finished its process. </td></tr><tr><td>result</td><td>boolean</td><td>true</td><td>Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>Verified</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>result_data</td><td>array</td><td>[...]</td><td>Contains the verified attributes</td></tr><tr><td>presentation_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each proof request</td></tr><tr><td>error</td><td>string</td><td>“Controller Error! ….”</td><td>Error message caught while processing the request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
[
  {
    "verification_id": 1,
    "connection_id": "e2aed3c4-c0a1-4711-902e-f0a9eba618da",
    "contact_id": "",
    "invitation_id": 1,
    "context": [
      "https://www.w3.org/2018/credentials#VerifiableCredential",
      "https://www.w3.org/2018/credentials/v1",
      "https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential"
    ],
    "attributes": [
      "id",
      "criteria"
    ],
    "wallet_id": "407e6215-17c5-4c81-901e-d75d9cc1a75a",
    "label": "your label here",
    "timeout": 15,
    "rule": "no rule",
    "meta_data": null,
    "state": "done",
    "complete": true,
    "result": false,
    "result_string": "Not Verified",
    "result_data": null,
    "presentation_exchange_id": [
      "52778677-a7be-4017-9b21-d146372f07e8"
    ],
    "error": "",
    "created_at": "2025-01-06T13:40:59.623Z",
    "updated_at": "2025-01-06T13:41:02.640Z"
  }
]
```

## Verifications - Read Verifications By ID (JSON-LD)

```
/api/v1/verifications/json-ld/<verification_id> - GET
```

This endpoint fetches a JSON-LD verification request record by using its `verification_id`.

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th width="176"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>verification_id</td><td>integer</td><td>10</td><td>Primary identifier for the verification request record</td></tr><tr><td>connection_id</td><td>string</td><td>e2aed3c4-c0a1-4711-902e-f0a9eba618da</td><td>Identifier that ties the used connection to the verification request record</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>context</td><td>array</td><td>[“...”, “...”]</td><td>List of contexts used for the verification record</td></tr><tr><td>attributes</td><td>array</td><td>[...]</td><td>List of attributes to be verified</td></tr><tr><td>wallet_id</td><td>string</td><td>407e6215-17c5-4c81-901e-d75d9cc1a75a</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>label</td><td>string</td><td>Email</td><td>Label for the verification request record</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request waited for a completed request record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for the verification request record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the verification request record</td></tr><tr><td>complete</td><td>boolean</td><td>true</td><td>This field does not indicate a verified request record, only that the request record has finished its process. </td></tr><tr><td>result</td><td>boolean</td><td>true</td><td>Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>Verified</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>result_data</td><td>array</td><td>[...]</td><td>Contains the verified attributes</td></tr><tr><td>presentation_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each proof request</td></tr><tr><td>error</td><td>string</td><td>“Controller Error! ….”</td><td>Error message caught while processing the request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "verification_id": 1,
  "connection_id": "e2aed3c4-c0a1-4711-902e-f0a9eba618da",
  "contact_id": null,
  "invitation_id": 1,
  "context": [
    "https://www.w3.org/2018/credentials#VerifiableCredential",
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential"
  ],
  "attributes": [
    "id",
    "criteria"
  ],
  "wallet_id": "407e6215-17c5-4c81-901e-d75d9cc1a75a",
  "label": "your label here",
  "timeout": 15,
  "rule": "no rule",
  "meta_data": null,
  "state": "done",
  "complete": true,
  "result": false,
  "result_string": "Not Verified",
  "result_data": null,
  "presentation_exchange_id": [
    "52778677-a7be-4017-9b21-d146372f07e8"
  ],
  "error": "",
  "created_at": "2025-01-06T13:40:59.623Z",
  "updated_at": "2025-01-06T13:41:02.640Z"
}
```

<figure><img src="/files/nH8WXmsWonMcbGXU57u2" alt=""><figcaption></figcaption></figure>


# mdoc/mDL

Proven and the Holdr SDK provide the capability to issue, hold, and verify credentials in the mdoc/mDL format over a variety of protocols. The following documentation describes how to use Proven for the server portions of mdoc/mDL workflows.

There are currently four categories of APIs for working with mdoc/mDL credentials over OID4VC: Keys, Schemas, Issuance, and Verification. These categories of APIs should be approached sequentially, e.g. it doesn't work to use the verification APIs if you haven't configured keys.

## Keys

### Key Initialization

Provision mDoc issuer key material so that you can securely issue mdoc and mDL credentials.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/setup/mdoc' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "force": false 
}'
```

#### Request (POST)

* `force` {boolean}: Whether to force the creation of a new key or not. Use false for first-time initialization or in case you don't want to overwrite the key (if one exists). Use true to rotate the key.

#### Response

* `key_id` {string}: This string will allow you to identify the key that the system is using for mdoc, allowing you assess the state of the system (e.g., are we still using the same key as 6 months ago?). Useful to save. Sample: `8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001`&#x20;
* `cert_id` {string}: This string will allow you to identify the certificate that the system is using to identify itself to other entities, allowing you to assess the state of the system (e.g. is this the endpoint or agent I think it is?). Useful to save. Sample: `6af84a3c-b6e9-4b1c-844a-6ce6a1f2d002`
* `message` {string}: Human readable text that describes the result of the operation (e.g., mDoc issuer keys provisioned successfully). Sample: `mDoc issuer keys provisioned successfully.`

### Key Status

Use this API to check whether the agent has been initialized with mdoc issuer key material and is ready to issue credentials.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/status/mdoc' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request

No request body or parameters.

#### Response

* `keys` {array of objects}: The key(s) currently provisioned for mdoc issuance. Each object contains:
  * `key_id` {string}: The identifier of the provisioned key. Sample: `8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001`
  * `cert_id` {string}: The identifier of the certificate associated with this key. Sample: `6af84a3c-b6e9-4b1c-844a-6ce6a1f2d002`
* `defaultCertificate` {object}: The certificate currently designated as the default for mdoc issuance.
  * `cert_id` {string}: The identifier of the default certificate. Sample: `6af84a3c-b6e9-4b1c-844a-6ce6a1f2d002`
  * `key_id` {string}: The identifier of the key associated with this certificate. Sample: `8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001`
  * `subject_dn` {string}: The subject distinguished name of the certificate. Sample: `CN=Proven mDoc Issuer`
  * `issuer_dn` {string}: The issuer distinguished name of the certificate. Sample: `CN=Proven mDoc Issuer`
* `trustAnchors` {array}: The trust anchors configured for this issuer. Empty if none have been configured.

## Schemas

### Setup a Schema

Use this API to configure the system to issue credentials of a particular schema, i.e. set things up so you can issue mDLs, passports, national IDs, etc.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/credentials-supported/mdoc' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "doctype": "org.iso.18013.5.1.mDL",
  "label": "Mobile Driver'\''s License",
  "description": "ISO 18013-5 Mobile Driver'\''s License" 
}'
```

#### Request (POST)

* `doctype` {string} **Required**: The mdoc document type identifier (e.g., `org.iso.18013.5.1.mDL`).
* `label` {string}: A human-readable name for this credential type (e.g., `Mobile Driver's License`).
* `description` {string}: A human-readable description of this credential type (e.g., `ISO 18013-5 Mobile Driver's License`).
* `display` {array of objects}: Display metadata for the credential type, used for rendering in wallets and verifier UIs.
* `verification_method` {string}: The verification method to use when signing credentials of this type.
* `issuer_id` {string}: The DID or identifier of the issuer for this credential type.
* `claims_schema` {object}: An object defining the namespaces and claims this credential type supports.
* `vc_additional_data` {object}: Additional data to include in the credential.
* `cryptographic_binding_methods_supported` {array of strings}: Cryptographic binding methods supported for this credential type.
* `cryptographic_suites_supported` {array of strings}: Cryptographic suites supported for this credential type.
* `proof_types_supported` {object}: Proof types supported for this credential type.

#### Response

* `agentRecord` {object}: The record created in the agent.
  * `supported_cred_id` {string}: Unique identifier for this credential type in the agent. Sample: `9fd5ef9d-b8b8-4f52-b6a9-95b9ce4f6f8a`
  * `identifier` {string}: The doctype string used as the credential type identifier. Sample: `org.iso.18013.5.1.mDL`
  * `format` {string}: The credential format. Always `mso_mdoc` for mdoc credentials.
  * `display` {array of objects}: Display metadata as stored in the agent.
  * `format_data` {object}: The doctype and claims as stored in the agent.
* `dbConfig` {object}: The configuration record stored in the Proven database.
  * `config_id` {string}: Unique identifier for this configuration record. Sample: `c4d8f7f2-f8d0-4d0b-93d0-9f9f31a5c003`
  * `wallet_id` {string}: The wallet this configuration is associated with. Sample: `wallet-123`
  * `doctype` {string}: The document type identifier as provided in the request.
  * `supported_cred_id` {string}: Matches the `supported_cred_id` in `agentRecord`.
  * `format` {string}: The credential format. Always `mso_mdoc`.
  * `label` {string}: The human-readable label as provided in the request.
  * `description` {string}: The human-readable description as provided in the request.
  * `created_at` {string}: ISO 8601 timestamp of when the record was created.
  * `updated_at` {string}: ISO 8601 timestamp of when the record was last updated.

### List Schemas

#### Example curl Command:

```

curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/credentials-supported/mdoc' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (GET)

Optional query parameters:

* `doctype` {string}: Filter results to a specific document type.
* `config_id` {string}: Filter results to a specific configuration record.

#### Response

Returns an array of configuration objects, each with the same fields as the `dbConfig` object in the POST response above.

## Issuance

Use this API to create a credential exchange and generate an offer that can be delivered to a holder's wallet.

### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/issue' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "supported_cred_id": "9fd5ef9d-b8b8-4f52-b6a9-95b9ce4f6f8a",
  "credential_subject": {
    "family_name": "Doe",
    "given_name": "Jane",
    "birth_date": "1990-01-15",
    "issue_date": "2026-03-10",
    "expiry_date": "2031-03-10",
    "issuing_country": "US",
    "issuing_authority": "State DMV",
    "document_number": "DL123456",
    "driving_privileges": "A,B,C",
    "un_distinguishing_sign": "USA",
    "sex": "2",
    "height": "170",
    "eye_colour": "BLU",
    "birth_place": "New York",
    "resident_city": "Springfield",
    "resident_state": "IL",
    "resident_postal_code": "62701",
    "resident_country": "US",
    "nationality": "US",
    "age_over_18": "true",
    "portrait": ""
  }
}'
```

### Request (POST)

* `supported_cred_id` {string}: The ID of the registered credential type to issue, obtained from the Schema Setup step. Sample: `9fd5ef9d-b8b8-4f52-b6a9-95b9ce4f6f8a`
* `credential_subject` {object}: The claims to include in the credential. Keys should match the claims defined when the credential type was registered. For an mDL, common fields include `family_name`, `given_name`, `birth_date`, `issue_date`, `expiry_date`, `issuing_country`, `issuing_authority`, `document_number`, `driving_privileges`, `un_distinguishing_sign`, and `portrait`.
* `did` {string}: The DID to associate with the credential subject.
* `verification_method` {string}: The verification method to use for signing this credential. If omitted, the system uses the verification method configured for the credential type.
* `pin` {string}: An optional user PIN for the credential offer, adding an extra layer of security to the issuance flow.
* `label` {string}: A human-readable label for this credential exchange.
* `connection_id` {string}: The connection ID to associate with this credential exchange.

### Response

* `offer` {object}: The credential offer object, suitable for delivery to a holder's wallet.
  * `credential_issuer` {string}: The URL of the credential issuer. Sample: `https://example/oid4vc/tenant/c286d1c7-c548-48d1-8580-76d3fe317bff`
  * `credentials` {array of strings}: The credential type identifiers included in this offer. For an mDL this will be `["org.iso.18013.5.1.mDL"]`.
  * `grants` {object}: The grant types available for this offer. For mdoc/mDL issuance, this will contain a pre-authorized code grant.
    * `urn:ietf:params:oauth:grant-type:pre-authorized_code` {object}: The pre-authorized code grant.
      * `pre-authorized_code` {string}: The pre-authorized code the holder's wallet uses to retrieve the credential. Sample: `iQ7DWmf2vjogMtQ_bdrDQg`
      * `user_pin_required` {boolean}: Whether the holder is required to supply a PIN to redeem the offer.
* `credential_offer` {string}: A URL-encoded `openid-credential-offer://` URI. This is typically rendered as a QR code or deep link for the holder's wallet to scan or tap.
* `exchange` {object}: The credential exchange record created by this request.
  * `exchange_id` {string}: Unique identifier for this exchange. Sample: `921786c9-dd65-473a-bebf-e5283d689c96`
  * `supported_cred_id` {string}: The credential type ID used for this exchange, matching the value from the request.
  * `credential_subject` {object}: The claims as provided in the request.
  * `verification_method` {string}: The verification method that will be used to sign the credential. Sample: `did:key:zDnaevgeiLuxFHYTHCHb1eAr489xPuCy3pDamtiGe5pWPvU41#zDnaevgeiLuxFHYTHCHb1eAr489xPuCy3pDamtiGe5pWPvU41`
  * `issuer_id` {string}: The DID of the issuer. Sample: `did:key:zDnaevgeiLuxFHYTHCHb1eAr489xPuCy3pDamtiGe5pWPvU41`
  * `state` {string}: The current state of the exchange. Will be `created` immediately after issuance is initiated.
  * `created_at` {string}: ISO 8601 timestamp of when the exchange was created.
  * `updated_at` {string}: ISO 8601 timestamp of when the exchange was last updated.

## Verification

Verification is a multi-step process. First, you create a presentation definition that describes what claims you want to verify. Then, you use that definition to create a presentation request, which generates a URI that can be delivered to a holder's wallet (e.g., as a QR code). Finally, after the holder responds, you retrieve the presentation results.

### Create a Presentation Definition

Use this API to define what credentials and claims you want to request from a holder.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
    "pres_def": {
        "input_descriptors": [
            {
                "id": "org.iso.18013.5.1.mDL",
                "format": {
                    "mso_mdoc": {
                        "alg": ["ES256"]
                    }
                },
                "constraints": {
                    "limit_disclosure": "required",
                    "fields": [
                        {
                            "path": ["$['\''org.iso.18013.5.1'\'']['\''given_name'\'']"]
                        },
                        {
                            "path": ["$['\''org.iso.18013.5.1'\'']['\''family_name'\'']"]
                        }
                    ]
                }
            }
        ]
    }
}'
```

#### Request (POST)

`pres_def` {object}: The presentation definition object, following the DIF Presentation Exchange specification.

* `id` {string}: An optional identifier for the presentation definition. If omitted, the system will generate one.
* `purpose` {string}: A human-readable string describing the purpose of the verification request.
* `input_descriptors` {array of objects}: One or more descriptors specifying what credentials and claims are required.
  * `id` {string}: An identifier for this input descriptor. For mdoc, typically the doctype (e.g., `org.iso.18013.5.1.mDL`).
  * `format` {object}: Specifies the credential format. For mdoc verification, use `"mso_mdoc": { "alg": ["ES256"] }`.
  * `constraints` {object}: Defines the constraints on the requested claims.
    * `limit_disclosure` {string}: Set to `"required"` to ensure only the requested claims are disclosed.
    * `fields` {array of objects}: The specific claims to request. Each field has a `path` array using JSONPath notation. For mdoc claims, use the namespace-qualified syntax: `$['org.iso.18013.5.1']['claim_name']`.

#### Response

* `pres_def_id` {string}: The system-generated identifier for this presentation definition. Save this — you will need it to create a presentation request. Sample: `42c870ae-b605-4121-b5e3-1e6bb3a00c6f`
* `pres_def` {object}: The presentation definition as stored, including any system-generated fields such as `id`.
* `wallet_id` {string}: The wallet associated with this definition. Sample: `c286d1c7-c548-48d1-8580-76d3fe317bff`
* `created_at` {string}: ISO 8601 timestamp of when the record was created.
* `updated_at` {string}: ISO 8601 timestamp of when the record was last updated.

### List Presentation Definitions

Retrieve all presentation definitions registered for your wallet.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (GET)

No request body or parameters.

#### Response

Returns an array of presentation definition objects, each with the same fields as the POST response for creating a presentation definition above.

### Get a Single Presentation Definition

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions/{pres_def_id}' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (GET)

* `pres_def_id` {string} (path parameter, required): The identifier of the presentation definition to retrieve.

#### Response

Returns a single presentation definition object with the same fields as the POST response for creating a presentation definition above.

### Delete a Presentation Definition

#### Example curl Command:

```
curl --location --request DELETE 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions/{pres_def_id}' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (DELETE)

* `pres_def_id` {string} (path parameter, required): The identifier of the presentation definition to delete.

#### Response

* Only an HTTP status response code is returned.

### Create a Presentation Request

Use this API to generate a presentation request from a previously created presentation definition. The response includes a URI that can be rendered as a QR code or delivered as a deep link for the holder's wallet to scan.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/request' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
    "pres_def_id": "42c870ae-b605-4121-b5e3-1e6bb3a00c6f",
    "vp_formats": {
        "mso_mdoc": {
            "alg": ["ES256"]
        }
    }
}'
```

#### Request (POST)

* `pres_def_id` {string}: The identifier of the presentation definition to use, obtained from Step 1. Sample: `42c870ae-b605-4121-b5e3-1e6bb3a00c6f`
* `vp_formats` {object}: The verifiable presentation formats to accept. For mdoc verification, use `"mso_mdoc": { "alg": ["ES256"] }`.

#### Response

* `request_uri` {string}: A URL-encoded `openid4vp://` URI. This is typically rendered as a QR code or deep link for the holder's wallet to scan or tap. Sample: `openid4vp://?client_id=did%3Ajwk%3A...&request_uri=https%3A//example/oid4vc/tenant/.../oid4vp/request/43050ce4-bfb4-4454-b5de-9bbd1c564a85`
* `request` {object}: The presentation request record.
  * `request_id` {string}: Unique identifier for this request. Sample: `43050ce4-bfb4-4454-b5de-9bbd1c564a85`
  * `pres_def_id` {string}: The presentation definition used for this request.
  * `vp_formats` {object}: The verifiable presentation formats as provided in the request.
  * `created_at` {string}: ISO 8601 timestamp of when the request was created.
  * `updated_at` {string}: ISO 8601 timestamp of when the request was last updated.
* `presentation` {object}: The presentation exchange record created by this request.
  * `presentation_id` {string}: Unique identifier for this presentation exchange. Use this to poll for results. Sample: `5e871b45-3821-4a94-8695-303517939afb`
  * `pres_def_id` {string}: The presentation definition used.
  * `request_id` {string}: The request that initiated this presentation exchange.
  * `state` {string}: The current state of the presentation. Will be `request-created` immediately after the request is made.
  * `created_at` {string}: ISO 8601 timestamp of when the presentation exchange was created.
  * `updated_at` {string}: ISO 8601 timestamp of when the presentation exchange was last updated.

### Retrieve Presentation Results

After the holder's wallet responds to the presentation request, use this API to retrieve all of the results.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/presentations' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (GET)

Optional query parameters:

* `sort-field` {string}: The field to sort by (default `updated_at`).
* `sort-direction` {string}: Sort direction, `ASC` or `DESC` (default `DESC`).
* `page-size` {integer}: Number of results per page (default `20`).
* `current-page` {integer}: The page number to retrieve (default `1`).
* `item-count` {integer}: The total number of items.
* `state-filter` {string}: Filter results to a specific state (e.g., `done`, `request-created`).
* `contact-id` {string}: Filter results to a specific contact.

#### Response

* `params` {object}: The pagination and filter parameters applied to the query.
* `rows` {array of objects}: The presentation records. Key fields on each record include:
  * `presentation_exchange_id` {string}: Unique identifier for the presentation exchange.
  * `state` {string}: The current state (e.g., `request-created`, `done`).
  * `verified` {boolean}: Whether the presented credentials were successfully verified.
  * `role` {string}: The role in the exchange (e.g., `verifier`).
  * `presentation` {object}: The presented credentials, if available.
  * `created_at` {string}: ISO 8601 timestamp of when the record was created.
  * `updated_at` {string}: ISO 8601 timestamp of when the record was last updated.
* `count` {integer}: The total number of presentation records.

### Get a Single Presentation

After the holder's wallet responds to the presentation request, use this API to retrieve a specific result.

#### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/presentations/{presentation_exchange_id}' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
```

#### Request (GET)

* `presentation_exchange_id` {string} (path parameter, required): The identifier of the presentation exchange to retrieve.

#### Response

Returns a single presentation record with the same fields as described in the list response above.


# SD-JWT VCs

## Issuance

#### Create Credential-Supported (Schema):

* Before issuing a credential, you will need to create the “blueprint” (AKA class, schema, credential-type, etc.). See the following code example.&#x20;

### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/credentials-supported' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "format": "vc+sd-jwt",
  "id": "IDCard",
  "format_data": {
      "vct": "ExampleIDCard",
      "claims": {
          "given_name": {
              "mandatory": true,
              "value_type": "string"
          },
          "family_name": {
              "mandatory": true,
              "value_type": "string"
          },
          "something_nested": {
              "key1": {
                  "key2": {
                      "key3": {
                          "mandatory": true,
                          "value_type": "string"
                      }
                  }
              }
          },
          "age_equal_or_over": {
              "12": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "14": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "16": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "18": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "21": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "65": {
                  "mandatory": true,
                  "value_type": "boolean"
              }
          }
      }
  },
  "vc_additional_data": {
      "sd_list": [
          "/given_name",
          "/family_name",
          "/age_equal_or_over/12",
          "/age_equal_or_over/14",
          "/age_equal_or_over/16",
          "/age_equal_or_over/18",
          "/age_equal_or_over/21",
          "/age_equal_or_over/65"
      ]
  }
}'
```

### Request:

* `format` {string}: The format of the credential. Will always be `vc+sd-jwt` for issuing SD-JWTs.
* `id` {string}: The name of the credential (unique to Proven).
* `format_data.cryptographic_binding_methods_supported` {object}: Not currently in use; should be ignored.
* `format_data.display` {object}: Not currently in use; should be ignored.
* `format_data.vct` {object}: String or url that identifies the type of SD-JWT.
* `format_data.claims` {object}: An object with the body of your credential. The `mandatory` (optional) field signifies if the field is required to issue the credential. The `value_type` (optional) is the `data_type` of the field. It can accept the following types: string, number, and image media types such as image/jpeg as defined in IANA media type registry for images (<https://www.iana.org/assignments/media-types/media-types.xhtml#image>). Other values may also be used.
* `vc_additional_data.sd_list` {array}: Paths to values that can be asked for specifically and/or omitted. If the path to a value is not in the `sd_list`, then the value will be present each time that credential is presented.

### Response:

* `supported_cred_id` {string}: You will need this for the next step, so make sure to copy it.

### Issue Credential:

* After creating the credential supported, you will see a `supported_cred_id`. Make sure to copy it, as you will need it in the following step.&#x20;
* Now that you have your `credential_supported` record, you will be able to issue credentials using that `credential_supported`.

### Example curl Command:

```
curl --location 'https://buckets4life.
    share.zrok.io/api/v1/oid4vci/issue' \
--header 'x-api-key:
    HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUj
    Wqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie:
    sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIV
    TRBiNBL.
    DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2
    FM7zltk0' \
--data '{
    "supported_cred_id":
        "4e1a5734-629d-41ae-abc1-345732ce75
        ab",
    "credential_subject": {
        "given_name": "Alice",
        "family_name": "Smith",
        "something_nested": {
            "key1": {
                "key2": {
                    "key3": "something
                        nested"
                }
            }
        },
        "source_document_type": "id_card",
        "age_equal_or_over": {
            "12": true,
            "14": true,
            "16": true,
            "18": true,
            "21": true,
            "65": false
        }
    }
}'
```

### Request:

* `supported_cred_id` {string}: This is the `supported_cred_id` you copied from the previous step.
* `credential_subject` {object}: It should match your `credential_supported.format_data.claims` object from the previous step. However, instead of having an object with `value_type` or `mandatory`, you will have the key equal to the value.

### Response:

* In the response you will see an `offer_uri`. This can be either turned into a QR code or put into the SDK to accept the offer and receive the credential. If you hit the `GET https://{{host}}/api/v1/oid4vci/exchanges` endpoint, then you will be able to check on the status of your credential request.&#x20;

## Presentation (Verifying the Credential)

#### Presentation Definition (Schema):

* Before you can present a credential, you will need to create the “blueprint” (AKA class, schema, credential-type, etc.). Use the following example to complete the step.&#x20;

### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "pres_def": {
      "purpose": "Present basic profile info",
      "id": "<<put uuid_v4 here>>",
      "input_descriptors": [
          {
              "format": {
                  "vc+sd-jwt": {}
              },
              "id": "ID Card",
              "name": "Profile",
              "purpose": "Present basic profile info",
              "constraints": {
                  "limit_disclosure": "required",
                  "fields": [
                      {
                          "path": [
                              "$.vct"
                          ]
                      },
                      {
                          "path": [
                              "$.given_name"
                          ]
                      },
                      {
                          "path": [
                              "$.family_name"
                          ]
                      },
                      {
                          "path": [
                              "$.something_nested.key1.key2.key3"
                          ]
                      }
                  ]
              }
          }
      ]
  }
}'
```

* `pres_def.purpose` {string}: Enter a useful description of this presentation definition.&#x20;
* `pres_def.id`: This is a unique UUID for presentation definition.
* `pres_def.input_descriptors` {array}:  This is an array of credentials you will need for this presentation.&#x20;
  * `format` will be the credential type
  * `id` must not conflict with other IDs in `input_descriptors`
  * `name` will be a human-friendly name for you
  * `purpose` will also be a human-friendly field for you
* `pres_def.input_descriptors.constraints.limit_discolsure` {boolean}:&#x20;
  * `required` : This indicates that the [Conformant Consumer](https://identity.foundation/presentation-exchange/spec/v2.0.0/#term:conformant-consumer) MUST limit submitted fields to those listed in the fields array (if present). [Conformant Consumers](https://identity.foundation/presentation-exchange/spec/v2.0.0/#term:conformant-consumers) are not required to implement support for this value, but they MUST understand this value sufficiently to return nothing (or cease the interaction with the [Verifier](https://identity.foundation/presentation-exchange/spec/v2.0.0/#term:verifier)) if they do not implement it.
  * `preferred`: This indicates that the [Conformant Consumer](https://identity.foundation/presentation-exchange/spec/v2.0.0/#term:conformant-consumer) SHOULD limit submitted fields to those listed in the fields array (if present).
* `pres_def.input_descriptors.constraints.fields` {array}:  These are objects with the path to the values you would like to see when they are disclosed.

### Presentation Request:

After creating the presentation definition, you will see a `pres_def_id`. Make sure to copy it, as you will need it in the following step.&#x20;

Now that you have your presentation definition record, you will be able to present credentials using that presentation definition.

### Example curl Command:

```
curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/request' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "pres_def_id": "51bcd5fb-a95a-4650-808f-d9ed91847d51",
  "vp_formats": {
      "vc+sd-jwt": {
          "sd-jwt_alg_values": [
              "ES256",
              "ES384"
          ],
          "kb-jwt_alg_values": [
              "ES256",
              "ES384"
          ]
      }
  }
}'
```

### Request:

* `pres_def_id` {string}: Copy the `pres_def_id` from the previous step.
* Keep the rest of this request the same.&#x20;

### Response:

In the response, you will see a `request_uri`. This can be either turned into a QR code or put into the SDK to accept the presentation and send the credential. If you hit the `GET https://{{host}}/api/v1/oid4vp/presentations` endpoint, then you will be able to check on the status of your credential presentation.

## Verifications - Read Verifications By ID (JSON-LD)

```
/api/v1/verifications/json-ld/<verification_id> - GET
```

This endpoint fetches a JSON-LD verification request record by using its `verification_id`.

### **Response Body Information:**

The response body is an array of records. The following information is the data of each record:

<table data-header-hidden><thead><tr><th></th><th width="147"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Field name</strong></td><td><strong>Expected type/ values</strong></td><td><strong>Examples</strong></td><td><strong>Notes</strong></td></tr><tr><td>verification_id</td><td>integer</td><td>10</td><td>Primary identifier for the verification request record</td></tr><tr><td>connection_id</td><td>string</td><td>e2aed3c4-c0a1-4711-902e-f0a9eba618da</td><td>Identifier that ties the used connection to the verification request record</td></tr><tr><td>contact_id</td><td>string</td><td>contact123</td><td>Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority</td></tr><tr><td>invitation_id</td><td>integer</td><td>123</td><td>Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority</td></tr><tr><td>context</td><td>array</td><td>[“...”, “...”]</td><td>List of contexts used for the verification record</td></tr><tr><td>attributes</td><td>array</td><td>[...]</td><td>List of attributes to be verified</td></tr><tr><td>wallet_id</td><td>string</td><td>407e6215-17c5-4c81-901e-d75d9cc1a75a</td><td>Identifier that ties this record to an existing wallet</td></tr><tr><td>label</td><td>string</td><td>Email</td><td>Label for the verification request record</td></tr><tr><td>timeout</td><td>integer</td><td>10</td><td>Number of seconds the initial request waited for a completed request record</td></tr><tr><td>rule</td><td>string</td><td>“no rule”</td><td>Rules for the verification request</td></tr><tr><td>meta_data</td><td>object</td><td>null</td><td>Metadata for the verification request record</td></tr><tr><td>state</td><td>string</td><td>done</td><td>Current state of the verification request record</td></tr><tr><td>complete</td><td>boolean</td><td>true</td><td>This field does not indicate a verified request record, only that the request record has finished its process. </td></tr><tr><td>result</td><td>boolean</td><td>true</td><td>Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.</td></tr><tr><td>result_string</td><td>string</td><td>Verified</td><td>Custom string for helping to define the state of the request</td></tr><tr><td>result_data</td><td>array</td><td>[...]</td><td>Contains the verified attributes</td></tr><tr><td>presentation_exchange_id</td><td>array</td><td>[...]</td><td>Contains unique IDs for each proof request</td></tr><tr><td>error</td><td>string</td><td>“Controller Error! ….”</td><td>Error message caught while processing the request record</td></tr><tr><td>created_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was created</td></tr><tr><td>updated_at</td><td>timestamp</td><td>2025-01-06T11:51:10.169Z</td><td>Date/time this record was last updated</td></tr></tbody></table>

### **Sample Response Body:**

```
{
  "verification_id": 1,
  "connection_id": "e2aed3c4-c0a1-4711-902e-f0a9eba618da",
  "contact_id": null,
  "invitation_id": 1,
  "context": [
    "https://www.w3.org/2018/credentials#VerifiableCredential",
    "https://www.w3.org/2018/credentials/v1",
    "https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential"
  ],
  "attributes": [
    "id",
    "criteria"
  ],
  "wallet_id": "407e6215-17c5-4c81-901e-d75d9cc1a75a",
  "label": "your label here",
  "timeout": 15,
  "rule": "no rule",
  "meta_data": null,
  "state": "done",
  "complete": true,
  "result": false,
  "result_string": "Not Verified",
  "result_data": null,
  "presentation_exchange_id": [
    "52778677-a7be-4017-9b21-d146372f07e8"
  ],
  "error": "",
  "created_at": "2025-01-06T13:40:59.623Z",
  "updated_at": "2025-01-06T13:41:02.640Z"
}
```

<figure><img src="/files/AT6rY1DOR8yVo5rsaNQ0" alt=""><figcaption></figcaption></figure>


# Proven Webhook Documentation

## Proven Webhook Documentation

## Overview

Webhooks provide real-time notifications about events on Proven agents. They are delivered as HTTP POST requests to a configured endpoint.

### Webhook Structure

#### Headers:

| **Header**      | **Example Value** | **Description**               |
| --------------- | ----------------- | ----------------------------- |
| Content-Type    | application/json  | Request content type          |
| X-API-Key       | 24680AEIOUY       | Authentication key            |
| User-Agent      | node-fetch/1.0    | Client identifier             |
| Content-Length  | 1584              | Request body size in bytes    |
| Accept-Encoding | gzip,deflate      | Supported compression methods |

**Payload Format:**

```
{
  "event": "event_type",
  "webhook": {
// Event-specific data
  }
}
```

## Webhook Events

Description: This is triggered when a connection is fully established.

Event Type: `connection:completed`

**Payload Example:**

```
{
  "event": "connection:completed",
  "webhook": {
    "connection_id": "13eeacd4-0c4e-495e-81cc-d66c6eeb8545",
    "invitation_key": "2St9MAnpToLcnUxhfskNBYgNxzS4vzAy42kSWPF8AY9e",
    "invitation_msg_id": "7f7392eb-a334-43c9-bdb0-b1a109de1f91",
    "contact_id": null,
    "purpose": "invitation purpose",
    "wallet_id": "f161e7a3-9a88-4f2c-a988-cc9cf3fbea2f",
    "discovered_features": [
      {
        "pid": "https://didcomm.org/present-proof/2.0",
        "roles": [
          "prover",
          "verifier"
        ]
      },
      // ... additional protocol features
    ]
  }
}
```

## AnonCred/JSON-LD Credential Issued

Description: This is triggered when a credential is successfully issued.

Event Type: `credentials:done`

**Payload Example:**

```
{
  "event": "credentials:done",
  "webhook": {
    "state": "done",
    "connection_id": "13eeacd4-0c4e-495e-81cc-d66c6eeb8545",
    "cred_ex_id": "794657e2-187e-4642-b5f2-77dd27138a49",
    "thread_id": "d92933ef-74d8-4e53-9d4a-6526feb991c5",
    "wallet_id": "f161e7a3-9a88-4f2c-a988-cc9cf3fbea2f",
    "role": "issuer",
    "initiator": "self",
    "created_at": "2025-03-13T22:14:41.138935Z",
    "updated_at": "2025-03-13T22:15:02.479961Z",
    "credential_id": null
  }
}
```

## AnonCred/JSON-LD Presentation Verified

Description: This is triggered when a presentation is successfully verified.

Event Type: `presentation:verified`

**Payload Example:**

```
{
  "event": "presentation:verified",
  "webhook": {
    "state": "done",
    "connection_id": "13eeacd4-0c4e-495e-81cc-d66c6eeb8545",
    "pres_ex_id": "7ec0d756-58e8-402d-9688-2dc4cd48cf17",
    "thread_id": "00b7fe05-79a1-44a8-91bd-8f0fe47f249d",
    "wallet_id": "f161e7a3-9a88-4f2c-a988-cc9cf3fbea2f",
    "role": "verifier",
    "initiator": "self",
    "verified": "true",
    "created_at": "2025-03-13T22:15:04.202161Z",
    "updated_at": "2025-03-13T22:15:14.343137Z"
  }
}
```

## OID4VC Issued

Description: This is triggered when a credential is successfully issued.

Event Type: `oid4vc-credential:issued`

**Payload Example:**

```
{
  event: 'oid4vc-credential:issued',
  webhook: {
    exchange_id: 'd3e347d2-e6df-45cf-bb02-27a929311260',
    supported_cred_id: '413f8b60-6587-40bd-95ee-58797c3d6543',
    credential_subject: {
      given_name: 'Alice',
      family_name: 'Smith',
      something_nested: { key1: { key2: { key3: 'something nested' } } },
      source_document_type: 'id_card',
      age_equal_or_over: {
        '12': true,
        '14': true,
        '16': true,
        '18': true,
        '21': true,
        '65': false
      }
    },
    verification_method: 'did:sov:NQ6iZJjvwdMzedXHzxX1vf#key-1',
    state: 'issued',
    issuer_id: 'did:sov:NQ6iZJjvwdMzedXHzxX1vf',
    code: 'Naqioo54ryqIAbNbfcWYTg',
    token: 'eyJ0eXAiOiAiSldUIiwgImtpZCI6ICJkaWQ6c292Ok5RNmlaSmp2d2RNemVkWEh6eFgxdmYja2V5LTEiLCAiYWxnIjogIkVkRFNBIn0.eyJpZCI6ICJkM2UzNDdkMi1lNmRmLTQ1Y2YtYmIwMi0yN2E5MjkzMTEyNjAiLCAiZXhwIjogMTc0MjA3NDM2Mn0.JffFZI7MgkWyZDLckUpY75flch4HdMqIHnUh1suHAoOOjjQ0OD9nNCNChNl5uCHrWZnrxsT9nQl-npZGqGDIDA'
  }
}
```

## OID4VCP Verified

Description: This is triggered when a presentation is successfully verified.

Event Type: `presentation:verified`

**Payload Example:**

```
{
  event: 'oid4vc-presentation:verified',
  webhook: {
    pres_def_id: 'b1c679d4-6edb-4d22-ba65-553dd7f6ef0a',
    presentation_id: '28e70110-57b4-494e-b13b-aa728eac88c4',
    request_id: '00f70502-0618-4b9e-af9f-e8af07f6edcd',
    matched_credentials: {
      'ID Card': {
        something_nested: { key1: { key2: { key3: 'something nested' } } },
        source_document_type: 'id_card',
        age_equal_or_over: {},
        sub: 'did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IkFlRzUyZk9oVnliN2VsYWtxVEFwc25ab2RCMkhuRGQ0YzE0d2NtRTRsOWMiLCJ5IjoiLW5VTmljSi0yUVV0UTNaVjBSc0NMMzNEVmVtcFNNUXBheG04VWQ0ZXlSayJ9',
        cnf: {
          kid: 'did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IkFlRzUyZk9oVnliN2VsYWtxVEFwc25ab2RCMkhuRGQ0YzE0d2NtRTRsOWMiLCJ5IjoiLW5VTmljSi0yUVV0UTNaVjBSc0NMMzNEVmVtcFNNUXBheG04VWQ0ZXlSayJ9#0'
        },
        vct: 'testCard',
        iss: 'did:sov:NQ6iZJjvwdMzedXHzxX1vf',
        iat: 1741987962,
        given_name: 'Alice',
        family_name: 'Smith'
      }
    },
    state: 'presentation-valid'
  }
}
```

## Basic Message Received

Description: This is triggered when a presentation is successfully verified.

Event Type: `webhook:basic-message`

**Payload Example:**

```
{
  event: 'basic-message:received',
  webhook: {
    connection_id: '9775b821-be93-4980-94d9-e3deaf6698d3',
    message_id: '4a977851-e5be-40fd-b3d6-3e01ae249c77',
    content: 'New',
    state: 'received',
    sent_time: '2025-03-14T02:28:57.839Z',
    locale: 'en',
    wallet_id: '122b480d-2813-42b5-9146-2d359a5dd807'
  }
}
```

## Authentication

* Header: `x-api-key` (optional)
* Example: `x-api-key: 24680AEIOUY`

## Security Considerations

* Use the `x-api-key` header (recommended).
* Use HTTPS for all endpoints.
* Verify request signatures if available.
* Validate JSON schema of incoming payloads.

<figure><img src="/files/3ejMu6CsO02lHQ7FZviY" alt=""><figcaption></figcaption></figure>


# API Reference

The following sections are an engineering focused API guide to Indicio Proven.&#x20;

The Indicio proven API is secured using an API key, which must be included in the request header as x-api-key.&#x20;

To add the API key, click the "Authorize" button and enter your API key.


# Subwallet   super Admin role only

Authenticate with base API key

## Create a new subwallet

> This endpoint allows you to create a new subwallet by providing a wallet name and an optional label.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Subwallet - super-admin role only","description":"Authenticate with base API key"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/subwallet/create":{"post":{"summary":"Create a new subwallet","description":"This endpoint allows you to create a new subwallet by providing a wallet name and an optional label.","tags":["Subwallet - super-admin role only"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","required":["wallet_name"],"properties":{"wallet_name":{"type":"string","description":"The name of the subwallet to be created."},"label":{"type":"string","description":"An optional label for the subwallet."}}}}}},"responses":{"201":{"description":"Subwallet created successfully","content":{"application/json":{"schema":{"type":"object","properties":{"wallet_id":{"type":"string","description":"The ID of the created subwallet."},"token":{"type":"string","description":"A token for the created subwallet."}}}}}},"400":{"description":"Subwallet creation failed due to missing wallet name.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string","description":"Error message indicating the reason for failure."}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal server error while creating subwallet.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve all subwallets

> This endpoint allows you to retrieve all subwallets created under this base admin.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Subwallet - super-admin role only","description":"Authenticate with base API key"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/subwallets":{"get":{"summary":"Retrieve all subwallets","description":"This endpoint allows you to retrieve all subwallets created under this base admin.","tags":["Subwallet - super-admin role only"],"responses":{"200":{"description":"Retrieved subwallets successfully","content":{"application/json":{"schema":{"type":"array","items":{"type":"object","properties":{"wallet_id":{"type":"string","description":"The ID of the retrieved subwallet."},"token":{"type":"string","description":"A token for the retrieved subwallet."},"label":{"type":"string","description":"A label for the retrieved subwallet."}}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal server error while retrieving subwallets.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve subwallet by wallet\_id

> This endpoint allows you to retrieve a subwallet by its wallet\_id

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Subwallet - super-admin role only","description":"Authenticate with base API key"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/subwallets/{wallet_id}":{"get":{"summary":"Retrieve subwallet by wallet_id","description":"This endpoint allows you to retrieve a subwallet by its wallet_id","tags":["Subwallet - super-admin role only"],"parameters":[{"in":"path","name":"id","required":true,"schema":{"type":"string"},"description":"The ID of the subwallet"}],"responses":{"200":{"description":"A subwallet record","content":{"application/json":{"schema":{"type":"object","properties":{"wallet_id":{"type":"string","description":"The ID of the retrieved subwallet."},"token":{"type":"string","description":"A token for the retrieved subwallet."},"label":{"type":"string","description":"A label for the retrieved subwallet."}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"Subwallet record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal server error while retrieving a subwallet.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Create a new API key

> Generates a new API key and stores its HMAC in the database. API key names must be unique per wallet.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Subwallet - super-admin role only","description":"Authenticate with base API key"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/apikey/create":{"post":{"summary":"Create a new API key","description":"Generates a new API key and stores its HMAC in the database. API key names must be unique per wallet.","tags":["Subwallet - super-admin role only"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"wallet_id":{"type":"string","description":"The ID of the wallet for which the API key is being created."},"name":{"type":"string","description":"A descriptive label for the API key."},"roles":{"type":"array","items":{"type":"string"},"description":"The roles associated with the API key."},"expires_at":{"type":"string","format":"date-time","nullable":true,"description":"Optional ISO-8601 timestamp when the API key expires. Omit or set to null for no expiration."}}}}}},"responses":{"200":{"description":"API key successfully created.","content":{"application/json":{"schema":{"type":"object","properties":{"api_key":{"type":"string","description":"The generated API key."},"key_id":{"type":"string","description":"The ID of the stored HMACed API key."},"name":{"type":"string","description":"The saved label for the API key."},"status":{"type":"string","description":"Status message."},"expires_at":{"type":"string","format":"date-time","nullable":true,"description":"The selected expiration timestamp, if provided."}}}}}},"400":{"description":"Bad request. Missing or invalid parameters.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string","description":"Error message."}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal server error.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string","description":"Error message."}}}}}}}}}}}
```

## Revoke an API key

> This endpoint revokes an API key by deleting it for the specified wallet and name.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Subwallet - super-admin role only","description":"Authenticate with base API key"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/apikey/revoke":{"post":{"summary":"Revoke an API key","description":"This endpoint revokes an API key by deleting it for the specified wallet and name.","tags":["Subwallet - super-admin role only"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","required":["wallet_id","name"],"properties":{"wallet_id":{"type":"string","description":"The ID of the wallet associated with the API key."},"name":{"type":"string","description":"The name of the API key to be revoked."}}}}}},"responses":{"200":{"description":"API key successfully revoked","content":{"application/json":{"schema":{"type":"object","properties":{"status":{"type":"string","description":"Status message indicating the API key was successfully revoked."}}}}}},"400":{"description":"Bad request. Missing or invalid parameters.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string","description":"Error message indicating what went wrong."}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"API key record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal server error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# Basic Messages

Endpoints for sending and retrieving basic messages

## Get all messages

> This endpoint retrieves all messages.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Basic Messages","description":"Endpoints for sending and retrieving basic messages"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/messages":{"get":{"summary":"Get all messages","description":"This endpoint retrieves all messages.","tags":["Basic Messages"],"responses":{"200":{"description":"A list of messages","content":{"application/json":{"schema":{"type":"object","properties":{"basicMessages":{"type":"array","items":{"type":"object"}}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Send a basic message

> This endpoint allows you to send a basic message.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Basic Messages","description":"Endpoints for sending and retrieving basic messages"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/messages":{"post":{"summary":"Send a basic message","description":"This endpoint allows you to send a basic message.","tags":["Basic Messages"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"invitation_id":{"type":"integer","description":"The ID of the invitation."},"contact_id":{"type":"string","description":"The ID of the contact."},"message":{"type":"string","description":"The message content."}}}}}},"responses":{"200":{"description":"Message sent successfully","content":{"application/json":{"schema":{"type":"object","properties":{"success":{"type":"string"}}}}}},"400":{"description":"Bad request. Invalid parameters.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Get a message by ID

> This endpoint retrieves a message by its ID.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Basic Messages","description":"Endpoints for sending and retrieving basic messages"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/messages/{id}":{"get":{"summary":"Get a message by ID","description":"This endpoint retrieves a message by its ID.","tags":["Basic Messages"],"parameters":[{"in":"path","name":"id","required":true,"schema":{"type":"string"},"description":"The ID of the message to retrieve."}],"responses":{"200":{"description":"A message object","content":{"application/json":{"schema":{"type":"object","properties":{"invitation_id":{"type":"integer","description":"The ID of the invitation."},"contact_id":{"type":"string","description":"The ID of the contact."},"message":{"type":"string","description":"The message content."}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"Message not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# Connections

Endpoints for managing connections

## Get all connections

> This endpoint retrieves all connections.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Connections","description":"Endpoints for managing connections"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/connections":{"get":{"summary":"Get all connections","description":"This endpoint retrieves all connections.","tags":["Connections"],"parameters":[{"in":"query","name":"sort-field","schema":{"type":"string"},"description":"The field to sort by (default updated_at)."},{"in":"query","name":"sort-direction","schema":{"type":"string"},"description":"The direction to sort (ASC or DESC, default DESC)."},{"in":"query","name":"page-size","schema":{"type":"integer"},"description":"The number of connections per page (default 20)."},{"in":"query","name":"current-page","schema":{"type":"integer"},"description":"The current page number (default 1)."},{"in":"query","name":"item-count","schema":{"type":"integer"},"description":"The total number of items."},{"in":"query","name":"state-filter","schema":{"type":"string"},"description":"If provided, returns only connections with this state."},{"in":"query","name":"contact-id","schema":{"type":"string"},"description":"If provided, returns only connections for this contact_id."}],"responses":{"200":{"description":"A list of connections","content":{"application/json":{"schema":{"type":"object","properties":{"params":{"type":"object","properties":{"sort":{"type":"array","items":{"type":"string"}},"pageSize":{"type":"string"},"currentPage":{"type":"integer"},"pageCount":{"type":"integer"},"itemCount":{"type":"integer"},"stateFilter":{"type":"string","nullable":true},"contactIdFilter":{"type":"string","nullable":true}}},"rows":{"type":"array","items":{"type":"object","properties":{"connection_id":{"type":"string"},"state":{"type":"string"},"my_did":{"type":"string"},"alias":{"type":"string"},"request_id":{"type":"string"},"invitation_key":{"type":"string"},"invitation_msg_id":{"type":"string"},"invitation_mode":{"type":"string"},"invitation_url":{"type":"string"},"invitation":{"type":"object","properties":{"@type":{"type":"string"},"@id":{"type":"string"},"label":{"type":"string"},"handshake_protocols":{"type":"array","items":{"type":"string"}},"services":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"type":{"type":"string"},"recipientKeys":{"type":"array","items":{"type":"string"}},"serviceEndpoint":{"type":"string"}}}}}},"accept":{"type":"string"},"initiator":{"type":"string"},"their_role":{"type":"string"},"their_did":{"type":"string"},"their_public_did":{"type":"string"},"their_label":{"type":"string"},"routing_state":{"type":"string"},"inbound_connection_id":{"type":"string"},"error_msg":{"type":"string"},"contact_id":{"type":"string"},"transaction_role":{"type":"string"},"discovered_features":{"type":"array","items":{"type":"object","properties":{"pid":{"type":"string"},"roles":{"type":"array","items":{"type":"string"}}}}},"wallet_id":{"type":"string"},"created_at":{"type":"string"},"updated_at":{"type":"string"}}}}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Get a connection by ID

> This endpoint retrieves a connection by its id.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Connections","description":"Endpoints for managing connections"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/connections/{connection_id}":{"get":{"summary":"Get a connection by ID","description":"This endpoint retrieves a connection by its id.","tags":["Connections"],"parameters":[{"in":"path","name":"connection_id","required":true,"schema":{"type":"string"},"description":"The connection id of the connection to retrieve."}],"responses":{"200":{"description":"Connection record retrieved successfully","content":{"application/json":{"schema":{"type":"object","properties":{"connection_id":{"type":"string"},"state":{"type":"string"},"my_did":{"type":"string"},"alias":{"type":"string"},"request_id":{"type":"string"},"invitation_key":{"type":"string"},"invitation_msg_id":{"type":"string"},"invitation_mode":{"type":"string"},"invitation_url":{"type":"string"},"invitation":{"type":"object","properties":{"@type":{"type":"string"},"@id":{"type":"string"},"label":{"type":"string"},"handshake_protocols":{"type":"array","items":{"type":"string"}},"services":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"type":{"type":"string"},"recipientKeys":{"type":"array","items":{"type":"string"}},"serviceEndpoint":{"type":"string"}}}}}},"accept":{"type":"string"},"initiator":{"type":"string"},"their_role":{"type":"string"},"their_did":{"type":"string"},"their_public_did":{"type":"string"},"their_label":{"type":"string"},"routing_state":{"type":"string"},"inbound_connection_id":{"type":"string"},"error_msg":{"type":"string"},"contact_id":{"type":"string"},"transaction_role":{"type":"string"},"discovered_features":{"type":"array","items":{"type":"object","properties":{"pid":{"type":"string"},"roles":{"type":"array","items":{"type":"string"}}}}},"wallet_id":{"type":"string"},"created_at":{"type":"string"},"updated_at":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"Connection not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# Context

Endpoints for managing contexts

## Get all JSON-LD context files for a specific wallet

> This endpoint retrieves all JSON-LD context files for the authenticated wallet.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Context","description":"Endpoints for managing contexts"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/context":{"get":{"summary":"Get all JSON-LD context files for a specific wallet","description":"This endpoint retrieves all JSON-LD context files for the authenticated wallet.","tags":["Context"],"responses":{"200":{"description":"A list of JSON-LD context files for the wallet","content":{"application/json":{"schema":{"type":"array","items":{"type":"object"}}}}},"401":{"description":"Unauthorized"},"500":{"description":"Internal Server Error","content":{"application/json":{}}}}}}}}
```

## Save a JSON-LD context file for a specific wallet

> This endpoint saves a JSON-LD context file for a specific wallet.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Context","description":"Endpoints for managing contexts"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/context":{"post":{"summary":"Save a JSON-LD context file for a specific wallet","description":"This endpoint saves a JSON-LD context file for a specific wallet.","tags":["Context"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"context_file_id":{"type":"string","description":"The filename of the JSON-LD context file to save."},"file":{"type":"object","properties":{"@context":{"type":"object","description":"The JSON-LD context."}}}}}}}},"responses":{"200":{"description":"Context saved successfully","content":{"application/json":{}}},"400":{"description":"Bad Request"},"401":{"description":"Unauthorized"},"500":{"description":"Internal Server Error"}}}}}}
```

## Get a JSON-LD context file by ID for a specific wallet

> This endpoint retrieves a JSON-LD context file by its ID for the authenticated wallet.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Context","description":"Endpoints for managing contexts"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/context/{context_file_id}":{"get":{"summary":"Get a JSON-LD context file by ID for a specific wallet","description":"This endpoint retrieves a JSON-LD context file by its ID for the authenticated wallet.","tags":["Context"],"parameters":[{"in":"path","name":"context_file_id","required":true,"schema":{"type":"string"},"description":"The ID of the JSON-LD context file to retrieve."}],"responses":{"200":{"description":"JSON-LD context file retrieved successfully","content":{"application/json":{"schema":{"type":"object"}}}},"401":{"description":"Unauthorized"},"404":{"description":"Context file not found"},"500":{"description":"Internal Server Error"}}}}}}
```

## Get all JSON-LD context files from all wallets

> This endpoint retrieves all JSON-LD context files from all wallets (static route).

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Context","description":"Endpoints for managing contexts"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/context":{"get":{"summary":"Get all JSON-LD context files from all wallets","description":"This endpoint retrieves all JSON-LD context files from all wallets (static route).","tags":["Context"],"responses":{"200":{"description":"A list of all JSON-LD context files","content":{"application/json":{"schema":{"type":"array","items":{"type":"object"}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{}}}}}}}}
```


# Credentials

Endpoints for issuing and retrieving credentials

## Issue JSON-LD credentials

> This endpoint issues JSON-LD credentials.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials/json-ld":{"post":{"summary":"Issue JSON-LD credentials","description":"This endpoint issues JSON-LD credentials.","tags":["Credentials"],"parameters":[{"in":"query","name":"timeout","required":false,"schema":{"type":"integer"},"description":"The timeout for the credential issuance (seconds)."}],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"invitation_id":{"type":"number","nullable":true,"description":"The invitation ID."},"contact_id":{"type":"string","nullable":true,"description":"The contact ID."},"revocation_def_id":{"type":"string","nullable":true,"description":"The ID of status list definition to enable revocation"},"credential":{"type":"object","description":"The credential object.","properties":{"@context":{"type":"array","items":{"type":"string"},"description":"The contexts of the credential."},"issuanceDate":{"type":"string","format":"date-time","description":"The issuance date of the credential."},"validFrom":{"type":"string","format":"date-time","description":"The valid from date of the credential."},"awardedDate":{"type":"string","format":"date-time","description":"The awarded date of the credential."},"expirationDate":{"type":"string","format":"date-time","description":"The expiration date of the credential."},"validUntil":{"type":"string","format":"date-time","description":"The valid until date of the credential."},"type":{"type":"array","items":{"type":"string"},"description":"The types of the credential."},"description":{"type":"string","description":"The description of the credential."},"name":{"type":"string","description":"The name of the credential."},"issuer":{"type":"object","description":"The issuer of the credential.","properties":{"id":{"type":"string","description":"The identifier of the issuer"},"type":{"type":"array","items":{"type":"string"},"description":"The types of the issuer."},"name":{"type":"string","description":"The name of the issuer."},"description":{"type":"string","description":"The description of the issuer."},"url":{"type":"string","description":"The URL of the issuer."},"email":{"type":"string","description":"The email of the issuer."},"image":{"type":"object","description":"The image of the issuer.","properties":{"id":{"type":"string","description":"The ID of the image."},"type":{"type":"string","description":"The type of the image."},"caption":{"type":"string","description":"The caption of the image."}}}}},"credentialSubject":{"type":"object","description":"The credential subject.","properties":{"type":{"type":"array","items":{"type":"string"},"description":"The types of the credential subject."},"achievement":{"type":"object","description":"The achievement of the credential subject.","properties":{"id":{"type":"string","description":"The ID of the achievement."},"name":{"type":"string","description":"The name of the achievement."},"description":{"type":"string","description":"The description of the achievement."},"criteria":{"type":"object","description":"The criteria of the achievement.","properties":{"type":{"type":"string","description":"The type of the criteria."},"narrative":{"type":"string","description":"The narrative of the criteria."}}},"image":{"type":"object","description":"The image of the achievement.","properties":{"id":{"type":"string","description":"The ID of the image."},"type":{"type":"string","description":"The type of the image."}}},"type":{"type":"array","items":{"type":"string"},"description":"The types of the achievement."}}}}}}},"proofType":{"type":"string","description":"The proofType for the credential issuance"},"rule":{"type":"string","description":"The rule for the credential issuance."}}}}}},"responses":{"200":{"description":"JSON-LD credential issued successfully","content":{"application/json":{"schema":{"type":"object","properties":{"record":{"type":"object"}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"422":{"description":"Unprocessable Entity.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve a JSON-LD credential by ID

> This endpoint retrieves a JSON-LD credential by its ID using the provided API key.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials/json-ld/{request_id}":{"get":{"summary":"Retrieve a JSON-LD credential by ID","description":"This endpoint retrieves a JSON-LD credential by its ID using the provided API key.","tags":["Credentials"],"parameters":[{"in":"path","name":"request_id","required":true,"schema":{"type":"string"},"description":"The ID of the credential."}],"responses":{"200":{"description":"JSON-LD credential retrieved successfully","content":{"application/json":{"schema":{"type":"object","properties":{"record":{"type":"object","description":"The retrieved JSON-LD credential record."}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"JSON-LD credential record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve all credentials

> This endpoint retrieves all credentials associated with the provided API.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials":{"get":{"summary":"Retrieve all credentials","description":"This endpoint retrieves all credentials associated with the provided API.","tags":["Credentials"],"parameters":[{"in":"query","name":"sort-field","schema":{"type":"string"},"description":"The field to sort by (default updated_at)."},{"in":"query","name":"sort-direction","schema":{"type":"string"},"description":"The direction to sort (ASC or DESC, default DESC)."},{"in":"query","name":"page-size","schema":{"type":"integer"},"description":"The number of credentials per page (default 20)."},{"in":"query","name":"current-page","schema":{"type":"integer"},"description":"The current page number (default 1)."},{"in":"query","name":"item-count","schema":{"type":"integer"},"description":"The total number of items."},{"in":"query","name":"state-filter","schema":{"type":"string"},"description":"If provided, returns only credentials with this state."},{"in":"query","name":"contact-id","schema":{"type":"string"},"description":"If provided, returns only credentials for this contact_id."}],"responses":{"200":{"description":"A paginated list of credentials","content":{"application/json":{"schema":{"type":"object","properties":{"params":{"type":"object","properties":{"sort":{"type":"array","items":{"type":"array","items":{"type":"string"}}},"pageSize":{"type":"integer"},"currentPage":{"type":"integer"},"pageCount":{"type":"integer"},"itemCount":{"type":"integer"},"stateFilter":{"type":"string","nullable":true},"contactIdFilter":{"type":"string","nullable":true}}},"rows":{"type":"array","items":{"type":"object"}},"count":{"type":"integer"}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Issue a new AnonCred credential

> This endpoint allows you to add a new credential request.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials":{"post":{"summary":"Issue a new AnonCred credential","description":"This endpoint allows you to add a new credential request.","tags":["Credentials"],"parameters":[{"in":"query","name":"timeout","required":false,"schema":{"type":"integer"},"description":"The timeout for the credential issuance (seconds)."}],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"invitation_id":{"type":"integer","description":"The ID of the invitation."},"contact_id":{"type":"string","description":"The ID of the contact."},"schema_id":{"type":"string","description":"The ID of the schema."},"attributes":{"type":"array","description":"A list of objects representing the attributes for the credential.","items":{"type":"object","properties":{"name":{"type":"string","description":"The name of the attribute."},"value":{"type":"string","description":"The value of the attribute."}}}},"rule":{"type":"string","description":"The rule for the credential issuance."}}}}}},"responses":{"200":{"description":"AnonCred credential issuance record was created","content":{"application/json":{"schema":{"type":"object","properties":{"record":{"type":"object"}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"422":{"description":"Unprocessable Entity.","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve a credential by its credential definition ID

> This endpoint retrieves a specific credential by its credential exchange ID.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials/{credential_exchange_id}":{"get":{"summary":"Retrieve a credential by its credential definition ID","description":"This endpoint retrieves a specific credential by its credential exchange ID.","tags":["Credentials"],"parameters":[{"in":"path","name":"credential_exchange_id","required":true,"schema":{"type":"string"},"description":"The credential exchange ID."}],"responses":{"200":{"description":"A credential object","content":{"application/json":{"schema":{"type":"object","properties":{"credential":{"type":"object"}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"Credential record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Remove PII from a credential

> This endpoint manually removes PII from a credential record.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials/{credential_exchange_id}/pii":{"post":{"summary":"Remove PII from a credential","description":"This endpoint manually removes PII from a credential record.","tags":["Credentials"],"parameters":[{"in":"path","name":"credential_exchange_id","required":true,"schema":{"type":"string"},"description":"The credential exchange ID."}],"responses":{"200":{"description":"PII removed successfully","content":{"application/json":{"schema":{"type":"object","properties":{"message":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"Credential record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Retrieve an AnonCred credential record by ID

> This endpoint retrieves an AnonCred credential record by its ID using the provided API key.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credential-records/{request_id}":{"get":{"summary":"Retrieve an AnonCred credential record by ID","description":"This endpoint retrieves an AnonCred credential record by its ID using the provided API key.","tags":["Credentials"],"parameters":[{"in":"path","name":"request_id","required":true,"schema":{"type":"string"},"description":"The ID of the credential record."}],"responses":{"200":{"description":"Credential record retrieved successfully","content":{"application/json":{"schema":{"type":"object","properties":{"record":{"type":"object","description":"The retrieved AnonCred credential record."}}}}}},"401":{"description":"Unauthorized."},"404":{"description":"AnonCred credential record not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Revoke an issued AnonCred credential

> This endpoint allows you to revoke a credential by providing the connection and credential exchange IDs.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Credentials","description":"Endpoints for issuing and retrieving credentials"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/credentials/anoncreds/revoke":{"post":{"summary":"Revoke an issued AnonCred credential","description":"This endpoint allows you to revoke a credential by providing the connection and credential exchange IDs.","tags":["Credentials"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"connection_id":{"type":"string","description":"The connection ID associated with the credential."},"credential_exchange_id":{"type":"string","description":"The credential exchange ID of the credential to revoke."}}}}}},"responses":{"200":{"description":"Credential revocation request accepted or already revoked","content":{"application/json":{"schema":{"type":"object","properties":{"success":{"type":"boolean"},"message":{"type":"string"}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized"},"422":{"description":"Unprocessable Entity","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# DIDs

Endpoints for managing Decentralized Identifiers (DIDs)

## Create a new DID

> This endpoint creates a new Decentralized Identifier (DID) using the provided API key.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"DIDs","description":"Endpoints for managing Decentralized Identifiers (DIDs)"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/create-did":{"post":{"summary":"Create a new DID","description":"This endpoint creates a new Decentralized Identifier (DID) using the provided API key.","tags":["DIDs"],"responses":{"200":{"description":"DID created successfully","content":{"application/json":{"schema":{"type":"object","properties":{"did":{"type":"object","properties":{"did":{"type":"string","description":"The created DID."},"verkey":{"type":"string","description":"The verification key for the DID."},"posture":{"type":"string","description":"The posture of the DID."},"key_type":{"type":"string","description":"The type of key used for the DID."},"method":{"type":"string","description":"DID method."},"metadata":{"type":"object","description":"Additional metadata for the DID."}}}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Set a public DID

> This endpoint sets a public Decentralized Identifier (DID) using the provided API key and DID.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"DIDs","description":"Endpoints for managing Decentralized Identifiers (DIDs)"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/set-public-did":{"post":{"summary":"Set a public DID","description":"This endpoint sets a public Decentralized Identifier (DID) using the provided API key and DID.","tags":["DIDs"],"parameters":[{"in":"query","name":"DID","required":true,"schema":{"type":"string"},"description":"The DID to be set as public."}],"responses":{"200":{"description":"DID set as public successfully","content":{"application/json":{"schema":{"type":"object","properties":{"did":{"type":"object","description":"The public DID."}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```

## Create a new did:indy DID

> This endpoint creates a new Decentralized Identifier (DID) using the provided API key.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"DIDs","description":"Endpoints for managing Decentralized Identifiers (DIDs)"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/did/indy":{"post":{"summary":"Create a new did:indy DID","description":"This endpoint creates a new Decentralized Identifier (DID) using the provided API key.","tags":["DIDs"],"responses":{"200":{"description":"DID created successfully","content":{"application/json":{"schema":{"type":"object","properties":{"did":{"type":"string","description":"The created DID."}}}}}},"401":{"description":"Unauthorized."},"412":{"description":"The TAA must be signed before calling this endpoint","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# Email

Endpoints for email verification

## Perform bulk credential issuance based on the valid email addresses

> This endpoint performs bulk credential issuance based on the valid email addresses.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Email","description":"Endpoints for email verification"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/api/v1/emails/verify":{"post":{"summary":"Perform bulk credential issuance based on the valid email addresses","description":"This endpoint performs bulk credential issuance based on the valid email addresses.","tags":["Email"],"requestBody":{"required":true,"content":{"application/json":{"schema":{"type":"object","properties":{"emails":{"type":"array","items":{"type":"object","properties":{"email":{"type":"string","description":"The email address to be verified as one of the bulk credential recipient."},"schema_id":{"type":"string","description":"The schema ID of the credential to be issued."},"time_to_accept":{"type":"number","description":"The number of days for the recipient to accept the credential."},"attributes":{"type":"array","items":{"type":"object","properties":{"name":{"type":"string"},"value":{"type":"string"}}},"description":"The attributes of the credential."}}}}}}}}},"responses":{"200":{"description":"Email verification successful","content":{"application/json":{"schema":{"type":"object","properties":{"emailsSuccess":{"type":"array","items":{"type":"string"}},"emailsFailure":{"type":"array","items":{"type":"string"}},"invalidEmails":{"type":"array","items":{"type":"string"}}}}}}},"400":{"description":"Bad Request","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"401":{"description":"Unauthorized."},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```


# Governance

Endpoints for fetching governance files

## Get governance file by filename

> This endpoint retrieves a governance file by its filename.

```json
{"openapi":"3.0.0","info":{"title":"Proven API","version":"1.0.0"},"tags":[{"name":"Governance","description":"Endpoints for fetching governance files"}],"servers":[{"url":"https://proven-4-2-test.proven.indicio.tech"}],"security":[{"ApiKeyAuth":[]}],"components":{"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","in":"header","name":"x-api-key"}}},"paths":{"/governance/files/{filename}":{"get":{"summary":"Get governance file by filename","description":"This endpoint retrieves a governance file by its filename.","tags":["Governance"],"parameters":[{"in":"path","name":"filename","required":true,"schema":{"type":"string"},"description":"The filename of the governance file to retrieve."}],"responses":{"200":{"description":"Governance file retrieved successfully","content":{"application/json":{"schema":{"type":"object"}}}},"404":{"description":"Governance file not found","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}},"500":{"description":"Internal Server Error","content":{"application/json":{"schema":{"type":"object","properties":{"error":{"type":"string"}}}}}}}}}}}
```




---

[Next Page](/llms-full.txt/1)