Only this pageAll pages
Powered by GitBook
Couldn't generate the PDF for 126 pages, generation stopped at 100.
Extend with 50 more pages.
1 of 100

Indicio Docs Site V3

Product

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Developer

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

AWS Install

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.

  • 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.

  • 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.

Patient benefits

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.

  • Protect yourself from deepfakes and stop fraud with mutual authentication that allows both parties to verify each other’s credentials before exchanging sensitive information.

  • 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.

  • Provide a better customer experience by removing passwords and tedious multi-factor authentication, allowing customers fast and secure access to accounts.

  • 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.

  • 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.

  • Credentials can be coded to expire.

  • 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.

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.

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.

  • For customers

    Reusable KYC processes for faster onboarding and compliance.

    Create once, use often

    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.

    Google Cloud Installs

    How to Guides

    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.

    • 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.

    Proven Software

    Indicio Proven offers all the following software options!

    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.

    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.

    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.

    Credentials

    Endpoints for issuing and retrieving credentials

    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.

    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.

    Automated rules provide more guardrails and security for the user’s personal information.

    User benefits

    DeGov covers

    Please complete this form now!

    Glossary
    Indicio Whitepapers
    Other Resources

    A secure (encrypted at rest) storage and a key management service suitable to use with Hyperledger Aries agents and other digital trust agents.

    Holdr+ wallet

    A digital wallet built on Hyperledger Aries.

    Holdr Mobile SDK

    Software created to build Verifiable Credential functionality into your existing applications.

    Proven Mobile Verifier

    Software used to validate Verifiable Credentials.

    Proven Cloud-scale Mediator

    Software used to deliver messages in a decentralized ecosystem.

    Proven Software Offering

    Details

    Aries Cloud Agent Python

    An easy to use enterprise SSI agent used to build decentralized trust services using any language that supports sending or receiving HTTP requests.

    Aries Askar

    Put Indico Proven to work in your project today!

    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.

    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.

    • 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.

    • 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

    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.

    • Proven Credential Formats

    • Proven Protocols

    Education

    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.

    • Immediate proof of degrees and accreditation

    • Prove specific skills with microcredentials

    Indicio Testnet

    The Indicio TestNet is a free to use community resource built on the open-source technology of Hyperledger , and . 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!

    To begin using the TestNet, follow these steps:

    1. Create a public DID (decentralized identifier). This can be done with the , with the , an app of your choice, or by .

    Proven Features
    Proven Standards
    Proven Software
    Proven Trust Establishment
    Share proof of employment with partner organizations, such as insurance companies, with the tap of a button.

    For Employees

    Let’s chat.

    API Reference

    The following sections are an engineering focused API guide to Indicio Proven.

    The Indicio proven API is secured using an API key, which must be included in the request header as x-api-key.

    To add the API key, click the "Authorize" button and enter your API key.

    Eliminate redundant paperwork and manual processes

    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.

    • 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.

    • Provide a more convenient and automated information sharing process for faculty and 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.

    • 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.

    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

    Verifiable credentials

    Indicio adds functionality to your student ID

    For Educational Institutions

    For Students

    Customer Success

    Then, click here to get the DID written to the TestNet.

    Indicio TestNet

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

    Start writing to the TestNet today!

    Indy
    Aries
    Ursa
    indy-cli
    Aries Toolbox
    following these instructions

    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

    Network Installs

    did:peer

  • did:web (resolution only)

  • DID resolution via Universal Resolver

    • did:sod

    • did:key

    • did:jwk

    • did:indy

    • did:sov

    • did:key

    • did:jwk

    • did:indy

    • did:key

    • did:peer1

    • did:peer2

    • did:key

    • did:peer1

    • did:peer2

    • did:sov

    • did:indy

    • did:jwk

    DID methods (server registration or creation)

    DID methods (server resolution of external DIDs)

    DID methods (server registration or creation)

    DID methods (server resolution of external DIDs)

    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.

    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

    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.

    1. 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.

    1. Communication protocols

    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.

    1. Credential format and signature types

    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.

    1. 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.

    1. Credential protocols and coordination formats

    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.

    1. Compatible governance / trust

    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.


    • 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

    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.

    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.

    • 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.

    • Easily revocable – No requirement to change access rights, passwords, or collect keys when an employee leaves.

    • 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.

    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.

    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).

    • - our ready to download digital wallet (in Apple and Android app stores).

    • - a ready-to-use SDK to power your own wallet!

    Features

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

    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

      • 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

      • 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

    Governance

    Endpoints for fetching governance files

    Context

    Endpoints for managing contexts

    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.

    • 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.

    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

  • Seven aspects of interoperability

    Examples

    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.

  • Fight impersonation attacks with credentials that can only be presented by the person they are issued to.

    How does Proven Auth Work?

    Organization benefits

    User benefits

    Contact Us Today To Get Started

    Learn more:

    Indicio Holdr+
    Proven Mobile SDK
    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

    How ProvenAI Works

    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.

    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.

    • 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).

    • 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.

    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

    Email

    Endpoints for email verification

    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.

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

    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.”

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

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

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

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

    Indicio Proven ® for Travel

    A complete verifiable credential solution for identity and data

    Indicio Proven is the world’s most advanced solution 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. 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.

    Biometric Verification

    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.

    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.

    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.

  • 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.

  • 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.

  • 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.
  • 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.

  • Features

    Benefits

    Proven Auth Workflow

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

    Why use a verifiable credential for SSO?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    AnonCreds

    Decentralized Ecosystem Governance (DEGov)

    Digital Travel Credential

    Digital Wallet

    DIDComm

    Distributed Ledger

    Distributed Ledger Network

    eIDAS

    eUDI (European Unique Digital Identity)

    Holder

    Holdr+

    Hyperledger Indy

    Issuer

    JSON-LD (JavaScript Object Notation for Linked Data)

    Mediator

    Mobile Driver’s Licence (mDL)

    Open Badges

    Open Source

    Open Standards

    OpenID

    OpenID4VCI (OpenID for Verifiable Credential Issuance)

    OpenID4VP (OpenID for Verifiable Presentations)

    Protocol

    SD-JWT (Selective Disclosure JSON Web Token)

    Verifiable Credential Schema

    Verifier

    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.

    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.

    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.

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

    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.

    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.

    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.

    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

    Seamless, Streamlined, and Secure Identity Verification

    What's Included

    Benefits

    Unlocking efficiency, savings across industries and sectors

    Travel, Hospitality, & Tourism

    Customers

    Aruba

    SITA

    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.

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

    Biometric verification without the risk of having to store biometric data

    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.

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

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

    Flexible template for creating credentials.

    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.

    • 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.

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

    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.

    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.

    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.

    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.

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

    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.

    Proven Communication Protocols / Technology

    Indicio offers the following communication protocols & technology

    Protocols/Technology

    Details

    OpenID for Verifiable Credentials (OID4VC)

    This empowers End-Users to directly present identity information to Verifiers.

    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.

    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

    Subwallet super Admin role only

    Authenticate with base API key

    Proven Trust Establishment

    Indicio proven includes all of these trust establishment options!

    Digital Passports

    • 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.

    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.

    Web3 Infrastructure

    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.

    • 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.

    Invitations

    Endpoints for creating and managing invitations

    Citizen ID

    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.

    • Increase security with phishing-proof verifiable credentials; unlike passwords or physical keys, these credentials cannot be lost, stolen, or copied.

    • Fight fraud and reduce data breaches by removing reliance on centralized databases for sensitive identity information.

    DIDs

    Endpoints for managing Decentralized Identifiers (DIDs)

    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.

    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.

  • What's included

    Issuer & Verifier Agents

    Mobile App & Mediator

    Verifiable Credential Schema

    Distributed Ledger Network

    Technical support & training

    Benefits

    Unlocking efficiency, savings across industries and sectors

    Travel, Hospitality, & Tourism

    Banking & Finance

    Customers

    Agriculture

    Education

    AI & IoT

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

    Privacy Protection

    Request Form

    A DID method for interacting with Hypereldger Indy networks

    did:key

    A DID method for Static Cryptographic Keys

    did:peer v. 1, 2, and 4

    A DID method for most private relationships between people, organizations, and things

    did:web (resolution only)

    A DID method using a web domain's existing reputation

    did:webvh

    A version of did:web extended to include the Verifiable History of the DID

    x.509 certificates

    Certificates issued by Certificate Authorities for establishing trust and identity of software

    OpenID Federation

    Trust Anchors mediate trust for a federation of collaborating parties

    Proven Trust Establishment

    Details

    did:sov

    A DID method for interacting with ledgers similar to the Sovrin Network

    did:indy

    Trust us to help you build your ideal solution!

    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.

    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.

    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.

    Benefits

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

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

    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.

    • 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.

    Share and verify data without the need for direct integrations

    Organization benefits

    User benefits

    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.

    • 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.

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

    Government benefits

    Citizen benefits

    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.

    DIDComm V1.0 Protocols

    DIDComm provides a profile for supporting the Wallet and Credential Interaction (WACI) Protocols for both Issuance and Presentation Exchange.

    BLE

    Bluetooth Low Energy, a low energy networking technology, is used for communicating between decentralized identity agents.

    NFC

    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.

    WiFi Aware

    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.

    Ready to learn more? Let’s chat.

    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.

    • 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.

    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.

    • , created by the global educational nonprofit, , solved these challenges by updating the specification to align with the .

    • 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.

    • 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.”

    • 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.

    • 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.

    • The ability to issue micro credentials

    • The ability to create profiles

    • Bulk issuance and messaging

    • DIDComm is available as an option, allowing personalized interaction

    Introduction

    The global leader in verifiable digital identity solutions, trusted by enterprises and governments worldwide to streamline operations, eliminate errors, and prevent fraud.

    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.

    ​​​​​​​

    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.

    Border Management

    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.

    • 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.

    Holdr + EUDI

    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).

    • 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.

    Connections

    Endpoints for managing connections

    Introduction

    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.

    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.

    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.

    As 1EdTech says, 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.”

  • 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.

  • LinkedIn posting

    For Students

    Advantages of Implementing Open Badges 3.0 as Verifiable Credentials

    Why Verifiable Credentials and Open Badges 3.0?

    Indicio’s Implementation of OpenBadges 3.0

    Additional features for Openbages in Indicio Proven

    The Open Badges 3.0 specification
    1EdTech
    W3C Verifiable Credential Data Model
    Let’s chat.

    Mobile SDK

    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    space
    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.

    • 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.

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

    Organization benefits

    User benefits

    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.

    • 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.

    • 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.

    Building to EUDI specifications with Proven

    Streamline your digital identity systems and build to new European standards

    Indicio makes EUDI work for you.

    The goals set for eIDAS and EUDI by the EU

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

    Thinking global

    About Us

    Public Benefit Corporation

    ​Schedule time with our team now

    ​

    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.

    • 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.

    • 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.

    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

    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.

    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 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 . 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.

    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 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 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! .

    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.

    Proven Credential Formats

    Indicio is compliant with all of the following credential formats!

    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.

    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.

    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.

    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.

    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.

    Indicio Proven includes a cloud-scale mediator to support customer application at scale.

    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.

    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

    Fast, simple, and easy to use, these credentials can contain all the information needed to prove identification across your organization and partner organizations.

    User benefits

    The benefits

    Why are these mDLs not commonplace?

    how to spot a fake ID
    until the end of 2020
    13 have passed
    Get in touch with our team of experts today
    DIF.
    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.
    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:

    The API will respond with something similar to the following:

    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.

    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):

    The API will respond with the following message:

    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.

    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.

    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):

    The API will respond with something similar to the following:

    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.

    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.

    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.

    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 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:

    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.

    The three major features that will be exercised are:

    Connecting

    Call the Invitation API

    Connecting
    Issuing a credential
    Verifying a credential
    {
      "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": ""
    }
    {"invitation_url":"https://proven.mediator.indiciotech.io?c_i=eyJAdHlwZSI6ICJkaWQ6c292OkJ6Q2JzTlloTXJqSGlxWkRUVUFTSGc7c3BlYy9jb25uZWN0aW9ucy8xLjAvaW52aXRhdGlvbiIsICJAaWQiOiAiNmQ0Y2QxZjYtNWJmMi00MjQ3LTg1ZmQtY2UxNzk5MjYyNDY3IiwgInJlY2lwaWVudEtleXMiOiBbIkFjOTFEWHE2ZEZzWXBZcmMyVlMzWDRrUnhHWGZtaGhaVXo1NUpSUkdSdkF5Il0sICJyb3V0aW5nS2V5cyI6IFsiRXJLRGVkNkQ1Tm9nUXpMVlBwczlrcFNXYWdxTndiVlE4RXpIcGdoTHE4UlQiLCAiMkRBQjZNU2V2bnFjc2ZoMzJIOEFrdlBIcHNzVmY3Wnl0UlZHOThTdXZXUjUiXSwgImxhYmVsIjogIlByb3ZlbiIsICJzZXJ2aWNlRW5kcG9pbnQiOiAiaHR0cHM6Ly9wcm92ZW4ubWVkaWF0b3IuaW5kaWNpb3RlY2guaW8ifQ==","invitation_id":52,"contact_id":""}
    {
    "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"
      }
    ]
    }
    {
      "success": "Credential was offered"
    }
    {
      "invitation_id": 52,
      "contact_id": "",
      "schemas": [
          {
              "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0",
              "schema_attributes": [
                  "user_email"
              ]
          }
      ],
      "timeout": "10",
      "rule": "no rule"
    }
    [
      {
          "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"
      }
    ]
    {
      "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"
    }

    Request an invitation URL from the Proven API using the invitations API.

    Establish the Connection

    Issuing a Credential

    Verifying a Credential

    Request a Verification

    Request the Status of the Verification(s)

    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.

    AnonCreds

    AnonCreds is a VC format that adds important privacy-protecting ZKP (zero-knowledge proof) capabilities to the core VC assurances.

    W3C VCDM (JSON-LD)

    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.

    W3C VC compliant

    Indicio is compliant with the W3C standard for Verifiable Credentials.

    Open Badges 3.0

    The world's leading format for digital badges is often used to prove educational achievements, such as transcripts, diplomas, and certifications.

    Digital Travel Credentials (ICAO DTC)

    These are digital representations of travel documents, such as passports, that are designed to streamline and enhance the travel process.

    IATA One ID

    IATA's One ID initiative aims to streamline passenger journey with advance sharing of information and a contactless process at the airport.

    Proven Credential Format

    Details

    SD-JWT VC

    JWT-based verifiable credentials support selective disclosure.

    mdoc / mDL

    Don’t see the credential format you need?

    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.

  • 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.

  • Hosting options

    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.

    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.

    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.

    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.

    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.

    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.

    1. 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.

    1. Enhanced Security Measures:

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

    • 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.

    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.

    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.

    Indicio Proven ®

    Unlocking efficiency and savings across industries and sectors

    About Indicio Proven ®

    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.

    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.

    • 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.

    • 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.

    • 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.

    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.

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

    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.

    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.

    • 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.

    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

    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.

    “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.

    Indicio Proven ®

    Unlocking efficiency and savings across industries and sectors

    About Indicio Proven ®

    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.

    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.

    • 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.

    • 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.

    • 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.

    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.

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

    Government issued credentials

    Indicio simplifies access to government services and streamlines permits and licensing

    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.

    • 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.

    • 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.

    A Complete Ecosystem

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

    1. Issuer

    The issuer is an entity that creates and provides verifiable credentials to holders.

    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.

    The holder is the individual or entity that owns and controls the verifiable credential.

    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.

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

    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.

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

    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.

    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:

    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.

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

    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 .

    • 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.

    Proven Features

    Indicio Proven includes all these features!

    Proven Feature

    Details

    API for external integration

    A set of rules and specifications that allow different software systems to interact and exchange data.

    Standards and Specifications

    Indicio Proven is built to support an array of leading global specifications and open standards to ensure maximum interoperability.

    • 1 Ed Tech 3.0 Specification.

    • Internet Engineering Task Force specifications.

    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.

  • Indicio TempNet Service: A network for destructively testing performance, scaling, and security to discover weaknesses.

    Scalability: Useful for organizations that need a practical, scalable DID method but require enhanced accountability and transparency.

    DID:WEBVH:

    Key Features for DID:WEBVH

    Proven Expertise: Trusted by industry leaders, including SITA, IATA, and governments, for its secure, scalable verifiable credential solutions.
    Operational Costs: Manual verification processes demand significant resources and time, driving up costs for banks.

    Why Indicio Proven?

    Challenge: Stress-free account recovery in banking

    Benefits for Banks

    Field boundaries

  • Financial and compliance data

  • Insurance

  • Land data

  • Livestock data

  • Soil data

  • A seamless way to control and share authenticated data

    Customer Success

    Easily store all your permits and licenses in one place and eliminate the hassle of tracking down physical documents and paperwork.

    Citizen benefits

    Let’s chat.

    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.

  • Seamless, streamlined, and secure identity verification

    What's included

    ​Book a demo ​

    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.

  • Seamless, streamlined, and secure identity verification

    What's included

    Book a demo

    • 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.

    2. Holder

    3. Verifier

    4. Governance Rules

    5. Mediator

    6. Verifiable Data Registry or Network

    Key Interactions

    Indicio Network
    LF Decentralized Trust Indy Working Group Node, Plenum, Cryptography.
  • International Civil Aviation Organization (ICAO) Digital Travel Credential (DTC) standard.

  • LF Decentralized Trust Aries Working Group.

  • LF Decentralized Trust.

  • Membership Marketing Committee.

  • LF Decentralized Trust Identity Implementers Working Group.

  • Open Wallet Foundation Aries Cloud Agent Python agents (ACA-Py) Bifold Wallet (built on Credo - formerly Aries Framework Javascript).

  • OpenID for Verifiable Credentials (OID4VC) Communication protocol.

  • Decentralized Identity Foundation DIDComm Working Group DIDComm.

  • Decentralized Identity Foundation Trust Establishment Working Group Decentralized Ecosystem Governance.

  • Trust Over IP Foundation Utility Foundry Working Group.

  • World wide Web Consortium, Verifiable Credentials model and DID Specifications.

  • EU Digital Identity Wallet (EUDI). EU Digital Identity Wallet Pilot implementation.

  • Open Badges
    SD-JWT and SD-JWT VC

    Proven Controller API

    An API for the management of Verifiable Credentials.

    UI for credential issuance and verification

    Intuitive interface used to create and authenticate credentials.

    Proven Controller UI

    An intuitive user Interface used for managing Verifiable Credentials.

    Governance Editor/Interpreter

    Simple interface used for rules implementation in a decentralized ecosystem.

    DID resolution via Universal Resolver

    This resolves Decentralized Identifiers (DIDs) across many different DID methods.

    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.

    Web-based (ledgerless)

    Choose to use no ledger for your decentralized identity solution using DID:webvh.

    Customer chat using basic messages

    This is a chat function for users to connect through DIDComm.

    Get started with Indicio Proven Today! Let’s chat.

    Indicio Holdr+ ®

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

    Indicio’s powerful digital wallet — Holdr+

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

    Holdr+ ®

    With Holdr+, Indicio has your digital wallet needs covered.

    • 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.

    • Indicio’s fully deployed mobile digital wallet application is available to download in the app stores today!

    • Download on or .

    A “must have” capability

    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.

    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.

    • Your customer controls their data.

    • 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.

    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.

    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.

    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

    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 of engineers who will set up your network quickly and efficiently. We have your service support and advice—every step of the way.

    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 from the inside. Set up the governance that meets your and your customers’ needs.

    You want your network to be private; trust us, you also need it to be interoperable. 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.

    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, with the Aries Toolbox, or by following these instructions.

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

    LEARN MORE

    Proven User Tutorial

    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.

    In order to interact with Proven, please download and install the free Holdr+ wallet from either the or the .

    1. Swipe past the first two images and click Get Started on the third image as shown below.

    Indicio Proven® Mobile SDK

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

    : All the code you need in one place to implement decentralized identity

    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.

    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.

    • Multiple libraries:

    Introduction to Proven

    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.”

    Build today

    Make it interoperable

    potential of decentralized identity
    We build
    Contact Us Today
    No direct integrations to share data or verify identity between different systems.
    Apple
    Android
    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.

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

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

    Flexible template for creating credentials.

    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.

    • 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.

    A complete verifiable credential solution for identity and data

    Seamless, streamlined, and secure identity verification

    What's included

    Issuer & Verifier Agents

    Mobile App & Mediator

    Verifiable Credential Schema

    Distributed Ledger Network

    Technical support & training

    Benefits

    Read and accept the Terms of Use and the Privacy Policy. Check the box verifying you've read, understand, and accept the terms.
  • Click Continue for both the Terms and the Privacy policies.

    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).

    The next step is to log in to Proven.

    1. Visit: https://your.url.com/admin

    2. Username: admin

    3. Password: 123!@#!@#QWEqwe

    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.

    Proven will display a QR code that your mobile wallet can use to connect after you've selected a credential.

    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.

    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.

    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.

    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.

    After accepting the credential, Proven displays a success message.

    Click on a credential in your Holdr+ wallet to view the details at any time.

    View the list of issued credentials by clicking Credentials in the left menu.

    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.

    Sign out of Proven by clicking on the icon in the top right corner of the screen.

    Introduction

    Install the Holdr+ Mobile Wallet

    Apple App Store
    Google Play Store

    Configure Your Holdr+ Mobile Wallet

    Issuance - Log in to Proven

    Issuance - Select a Credential to Offer

    Issuance - Connect Using the QR Code in Proven

    Issuance - Connect Using the QR Code in Proven

    Issuance - Enter Credential Data

    Issuance - Receive a Credential Offer

    Issuance - Review and Accept the Credential Offer

    Issuance - Review Your Credential

    Issuance - View Issued Credentials

    Sign out of Proven

    • 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:

    • AnonCreds, SD-JWTs, and JWT-VCs ,JSON-LD . OID4VC; DEGov (Decentralized Ecosystem Governance, based on DIF Credential Trust Establishment).

  • Secure communications:

    • 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.

  • Combining biographic data with biometrics in a verifiable increases efficiency and security for all parties.

    Features

    Proven Mobile SDK

    Proven Standards

    Indicio is compliant with all of the following standards & legislation!

    Proven Legislation/Standard

    Details

    eIDAS 2.0

    Indicio is compliant with the updated version of the original eIDAS (Electronic Identification, Authentication, and Trust Services) regulation.

    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.

    • IT Leaders and Solution Architects.

    • Product Managers and Innovation Teams.

    • Developers and Integrators.

    • Government and Enterprise Stakeholders.

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

    Holdr+

    EUDI

    Indicio complies with the regulations set out by the EU for digital identity wallets.

    EUDI ARF

    Indicio is built to standards and specifications laid out by the EUDI Architecture and Reference Framework

    Aries Interop Profile (AIP) 1.0

    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

    Aries Interop Profile (AIP) 2.0

    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.

    DIF Credential Trust Establishment V1.0

    A practical, interoperable building block supports multiple different kinds of trust-decision Trust Establishment solutions.

    Let's get started on your project today!

    Who will benefit from these courses?

    Get Started Today

    Let’s chat.

    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

    Payload Format:

    Description: This is triggered when a connection is fully established.

    Event Type: connection:completed

    Payload Example:

    Description: This is triggered when a credential is successfully issued.

    Event Type: credentials:done

    Payload Example:

    Description: This is triggered when a presentation is successfully verified.

    Event Type: presentation:verified

    Payload Example:

    Description: This is triggered when a credential is successfully issued.

    Event Type: oid4vc-credential:issued

    Payload Example:

    Description: This is triggered when a presentation is successfully verified.

    Event Type: presentation:verified

    Payload Example:

    Description: This is triggered when a presentation is successfully verified.

    Event Type: webhook:basic-message

    Payload Example:

    • Header: x-api-key (optional)

    • Example: x-api-key: 24680AEIOUY

    • Use the x-api-key header (recommended).

    • Use HTTPS for all endpoints.

    • Verify request signatures if available.

    Validate JSON schema of incoming payloads.

    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

    Webhook Events

    AnonCred/JSON-LD Credential Issued

    AnonCred/JSON-LD Presentation Verified

    OID4VC Issued

    OID4VCP Verified

    Basic Message Received

    Authentication

    Security Considerations

    {
      "event": "event_type",
      "webhook": {
    // Event-specific data
      }
    }
    {
      "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
        ]
      }
    }
    {
      "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
      }
    }
    {
      "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"
      }
    }
    {
      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'
      }
    }
    {
      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'
      }
    }
    {
      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'
      }
    }

    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.

    Here are a few examples:

    • AI

    • Travel and Tourism

    Government Services
    Education
    Banking
    Biometric Verification
    Access Management
    Open Badges
    Financial Services
    Mobile Driver's Licenses
    Enterprise Solutions
    Healthcare Credentials
    Employee Credentials
    Digital Passports
    Citizen ID
    Decentralized Ecosystem Governance
    Border Management
    Zero Trust Architecture
    Web3 Infrastructure
    Government issued credentials

    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.

    • 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.

    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

    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 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.

    1. Log in to Keycloak. The address is https://yourURL/identiy.

    2. Change the realm to Indicio Proven. (Image 1)

    3. Click on Users. (Image 2)

    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.

    You can edit the following items for users. Refer to the Create New Users section for help.

    1. Log in to Keycloak.

    2. Click Users in the left menu.

    3. Click on the user you wish to edit.

    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

    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

    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

    Click Save when all desired changes are made

    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.

    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 (). 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.

    • supported_cred_id {string}: You will need this for the next step, so make sure to copy it.

    • 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.

    • Now that you have your credential_supported record, you will be able to issue credentials using that credential_supported.

    • 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.

    • 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.

    • 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.

    • pres_def.purpose {string}: Enter a useful description of this presentation definition.

    • 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.

    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.

    Now that you have your presentation definition record, you will be able to present credentials using that presentation definition.

    • pres_def_id {string}: Copy the pres_def_id from the previous step.

    • Keep the rest of this request the same.

    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.

    This endpoint fetches a JSON-LD verification request record by using its verification_id.

    The response body is an array of records. The following information is the data of each record:

    Response: the system has responded with details to finish setting up the connection.
  • Active: the second party has acknowledged the connection.

  • Click Add user. (Image 2)
    Image 2: Add user
  • Enter the Username. (Image 3)

  • The other fields are optional, but may be useful: (Image 3)

    1. Email

    2. First name

    3. Last name

  • Click Create. (Image 3)

    Image 3: User information

  • Click the Credentials tab. (Image 4)

  • Click Set password. (Image 4)

    Image 4: Credentials tab
  • 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.

  • Click the Role Mapping tab. (Image 6)

  • Click Assign Role. (Image 6)

    Image 6: Role mapping tab
  • Select Filter by Realm Role from the drop-down. (Image 7)

  • 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

    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

    5. uma_authorization: This is a KeyCloak role and Indicio does not make use of it.

  • Click Assign. (Image 7)

    Image 7: Roles
  • Click on the Groups tab. If a group doesn't exist, you may need to create a group.

  • Click Join Group.

  • Select any groups applicable. (Image 8)

  • Click Join. (Image 8)

    Image 8: Join group
  • Edit the user’s name or email.
  • Reset the user’s password

  • Add or remove roles.

  • Add or remove groups.

  • .
  • Confirm you want to delete the user.

  • Name
    .
  • Click Create.

  • Click on the group you just created.

  • 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.

  • Go to Attributes tab.

    1. Click Add attributes.

    2. Key: proven_group_id

    3. value: [WalletNameHere]

    4. Click Save.

  • 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.

  • Credentials

    Issuing Credentials

    Users

    Create New Users

    Edit Users

    Delete Users

    Create New Group

    Settings

    Image 1: Indicio Proven realm
  • 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}:

    • required : This indicates that the Conformant Consumer MUST limit submitted fields to those listed in the fields array (if present). 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) if they do not implement it.

    • preferred: This indicates that the 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.

  • string

    e2aed3c4-c0a1-4711-902e-f0a9eba618da

    Identifier that ties the used connection to the verification request record

    contact_id

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    context

    array

    [“...”, “...”]

    List of contexts used for the verification record

    attributes

    array

    [...]

    List of attributes to be verified

    wallet_id

    string

    407e6215-17c5-4c81-901e-d75d9cc1a75a

    Identifier that ties this record to an existing wallet

    label

    string

    Email

    Label for the verification request record

    timeout

    integer

    10

    Number of seconds the initial request waited for a completed request record

    rule

    string

    “no rule”

    Rules for the verification request

    meta_data

    object

    null

    Metadata for the verification request record

    state

    string

    done

    Current state of the verification request record

    complete

    boolean

    true

    This field does not indicate a verified request record, only that the request record has finished its process.

    result

    boolean

    true

    Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.

    result_string

    string

    Verified

    Custom string for helping to define the state of the request

    result_data

    array

    [...]

    Contains the verified attributes

    presentation_exchange_id

    array

    [...]

    Contains unique IDs for each proof request

    error

    string

    “Controller Error! ….”

    Error message caught while processing the request record

    created_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was last updated

    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
            }
        }
    }'
    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"
                              ]
                          }
                      ]
                  }
              }
          ]
      }
    }'
    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"
              ]
          }
      }
    }'
    /api/v1/verifications/json-ld/<verification_id> - GET

    Field name

    Expected type/ values

    Examples

    Notes

    verification_id

    integer

    10

    Primary identifier for the verification request record

    {
      "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"
    }

    Response:

    Issue Credential:

    Example curl Command:

    Request:

    Response:

    Presentation (Verifying the Credential)

    Presentation Definition (Schema):

    Example curl Command:

    Presentation Request:

    Example curl Command:

    Request:

    Response:

    Verifications - Read Verifications By ID (JSON-LD)

    Response Body Information:

    Sample Response Body:

    https://www.iana.org/assignments/media-types/media-types.xhtml#image

    connection_id

    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.

    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

    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

    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

    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. 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')

    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

    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. 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.

    1. Complete the network setup process

      1. Run the Oneshot startup process

        1. sudo /opt/indy-startup/Oneshot.sh

    1. To start the indy-cli using your new config file, run the following: indy-cli --config ~/cliconfig

    2. 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. Open your wallet and create a DID based on the “Steward Seed” created earlier.

    1. Provide Information to Trustees

      1. At this point you should have the following data available:

        1. Your Steward verkey and DID

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

    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. Learn more about these exclusive discounts and benefits for Google Cloud customers and contact us 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.

    5. Change the Deployment name 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

    1. Add a DNS entry for Proven.

    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.

    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

    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.

    TAILS_URL= Replace the IP address on this line with your local IP address. Leave the port as 6543.

    NODE_ENV=production

    PROVEN_ISSUER_API_DB_PASSWORD=provenapi Local database password. For security purposes, this MUST be changed.

    PROVEN_ISSUER_AGENT_DB_PASSWORD=provenagent Local database password. For security purposes, this MUST be changed.

    PROVEN_ISSUER_PROXY_DB_PASSWORD=provenagent Local database password. For security purposes, this MUST be changed.

    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.

    PROVEN_ISSUER_ENC_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters. Encryption key.

    PROVEN_ADMIN_PASSWORD= Must be added and must be 15 characters long.

    PROVEN_ISSUER_WEB_ROOT= 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 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    PROVEN_ISSUER_SESSION_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    PROVEN_ISSUER_ENC_KEY=54234625127cb22694ff0e27cc14b685 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    1. 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.

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

    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

    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.

    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= 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= 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= 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

    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 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:

    For help with setting up your own Issuer DID, please contact us:

    Conformant Consumer
    Highest level of privilege
  • Does not encompass admin privileges; if you want multitenancy management and regular agent privileges, you need both super-admin and admin

  • Regarding the differences between Admin and Technician roles, Simon is a better resource than me since he wrote that code

    Image 5: Add password
    Select “Indicio Proven”.
  • 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.

  • Click EDIT
  • Scroll down to Networking and under Firewalls check the boxes that will allow HTTP and HTTPS traffic.

  • Click SAVE

  • Click VM instances (in the left menu)

  • Record the External IP address of your Proven instance for later use.

  • Run this command for Proven.
  • 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.

  • 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.

  • sudo systemctl status proven
  • On error, return to the original ssh window, wait for the process to stop, then try again.

  • 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

  • Agree to the Transaction Author Agreement
  • To anchor the new DID which is now displayed -> open https://selfserve.indiciotech.io

  • 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.

  • Copy the new DID and Verkey displayed on the Proven window, to the DID and Verkey fields of the Selfserve form.

  • Click Submit

  • Return to the Proven SSH window and enter ‘y’ to indicate having anchored the Endorser DID.

  • Wait while the Credential definitions are created for you.

  • When you see Completed, then press enter to continue.

  • Your Proven instance is now ready to go!

  • 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!

  • 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)

  • Click Create

  • Here’s an example configuration:

  • 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.

  • 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”

  • sudo vi .env

  • Add a line right after the SCHEMA_USER line

    1. SCHEMA_EMPLOYMENT=4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0

  • Save and exit

  • 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

  • Update the schema definition files with the new schema:

    1. sudo vi config/proven-issuer-api/schemas.json { "schemas": [ { "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0" }, { "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0" } ] }

    2. sudo vi config/proven-issuer-api/schemas-verification.json { "schemaList": [ { "verification_label": "User - Full Disclosure", "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0", "schema_attributes": [ "username", "user_email", "user_id", "user_roles" ] }, { "verification_label": "User - Username and User Email", "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0", "schema_attributes": [ "username", "user_email" ] }, { "verification_label": "Employment - Full Disclosure", "schema_id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0", "schema_attributes": [ "employer_region", "employment_type", "employee_given_names", "employer_country", "employment_postal_code", "employment_start_date", "employer_postal_code", "employment_country", "employment_role", "employer_city", "employer_address", "employment_role_description", "employee_surnames", "employer_name", "employment_city", "employment_region", "employment_address" ] } ] }

    3. Save and exit

  • 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.

  • 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

  • Return to main instructions and continue.

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

    Configure the VM

    Accessing Proven

    (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

    Appendix A - DNS Setup Example

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

    Appendix C - Add a new credential type

    Appendix D - Issuer DID setup

    http://10.128.15.205:6543
    https://proven.dev.indiciotech.io
    http://10.128.15.205:6543
    http://localhost:3100/api/governance-framework
    https://issuer.dev.indiciotech.io
    support@indicio.tech
    support@indicio.tech
     cd /opt/indicio/proven-release-docker
     sudo systemctl enable proven
     sudo cp staging.env .env
    IPv4 range - 10.0.1.0/24 (or enter another valid range according to your needs)
    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

  • For Dynamic routing mode select Regional

  • Click CREATE

  • Network Service Tier - Standard
  • Region - Your selected region

  • Attached to - None (it will be attached to your vm later during your creation of the main node vm)

  • Click RESERVE

  • 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

  • Name - your choice (e.g. ssh-for-admin-access)

  • Direction of traffic - Ingress

  • Action on match - Allow

  • Targets - All instances in the network

  • Source filter - IPv4 ranges

  • Source IPv4 ranges - Enter the public IP addresses or ranges for your Node Administrators. (e.g. 67.199.174.247/32)

  • Protocols and ports - Specified protocols and ports

    1. Select the TCP check box and enter 22 for the port

  • Click Create

  • 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

  • Navigate back to VPC Network then VPC Networks

  • Click on the node-vpc network then click Firewalls

  • 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

  • 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)

  • 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.

  • Region - Select the same region chosen earlier in this guide.

  • Snapshot location - Regional (default location)

  • Schedule frequency - Weekly (then your choice of day and time.)

  • Autodelete snapshots after - 60 days

  • Deletion rule - your choice (e.g. Select Delete snapshots older than 60 days to remove the snapshots every 2 months)

  • Click CREATE

  • In the search bar, type Indicio NoDe and hit enter
  • Select the option that is named Indicio NoDe (Ubuntu 20.04)

  • Click GET STARTED

  • Agree to the terms by checking the box and clicking AGREE

  • Click DEPLOY

  • 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

  • Choose and record a zone from the same region as you used previously in this document (ex. us-east4-c)

  • 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)

  • Boot disk

    1. Boot disk type - Standard persistent disk is adequate.

    2. Size - 250 GB

  • 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. Click "Deploy" to create the new NoDe GC VM instance.

    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

  • To enable deletion protection:

    1. Under Basic information select the Enable deletion protection box (recommended)

  • 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.

  • 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. 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>

    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>

  • sudo netplan generate
  • sudo netplan apply

  • sudo add-apt-repository "deb http://security.ubuntu.com/ubuntu bionic-security main"

  • 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

  • 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.

  • 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.

  • 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

  • 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.

  • 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

      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 then send it.

  • 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.

  • On the machine you’ve chosen for the CLI, install indy-cli using instructions from Appendix A at this link: Indicio SelfServe Instructions

  • 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:

  • sudo apt install pwgen
  • pwgen -s 32 1

  • Record the output of the above command as the “Steward Seed”

  • Next we run the indy-cli command line CLI by entering: indy-cli --config ~/cliconfig

  • 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.

  • The Validator ‘node IP address’
  • The Validator ‘client IP address’

  • The Validator ‘node port’

  • The Validator ‘client port’

  • The Validator alias

  • The Validator verkey

  • The BLS key

  • Please go to the Node Operator Validator Registration form for Indicio networks (or the equivalent for the network you are joining) and provide the requested information.

  •     {
            "taaAcceptanceMechanism": "for_session"
        }
    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
        indy> wallet open &lt;wallet_name&gt; key
        indy> did new &lt;Steward Seed&gt; metadata=”steward DID”

    Static IP addresses

    Firewalls

    Snapshots

    Creating the VM Instance

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

    Connecting to the VM

    Configuring the VM

    support@indicio.tech
    Primary internal IP - select the internal node IP you created earlier
  • External IP - select the external node IP you created earlier

  • Click DONE

  • Copy the results of the previous step and paste it into the space provided, being careful NOT to copy any leading or trailing whitespace.

  • On your phone app add an account and then scan the barcode or enter the 16 character secret key from the previous steps output.

  • Reboot the instance and login to make sure 2FA is configured properly.

  • Click on the name of the rule that allows port 22 access for your admins (e.g. ssh-for-admin-access)
  • Click "EDIT" at the top of the screen.

  • Scroll down to the list of Source IP ranges and add the new Admins' IP addresses.

  • Click "SAVE" (Note: Restart is not needed. As soon as you save, they should have access.)

  • You can safely ignore messages like “sent invalidate(passwd) request, exiting“

  • For “Enter new UNIX password:” input “password1” (This will be changed later)

  • Enter a name (optional)

  • Defaults are fine for the rest

  • sudo usermod -aG sudo <newuser>

  • 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

  • Repeat the above for each new admin user you create.

  • Type in password1 for your password
  • 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).

  • 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.

  • 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!

  • https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/nodeop-tools/nodeop-tech-check.py
    support@indicio.tech

    Indicio FAQ's

    What is Indicio Proven?

    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.

    What are the benefits of using Indicio Proven over traditional authentication methods?

    • 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.

    What is the user experience like with Indicio Proven?

    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.

    What are the other benefits of Indicio Proven?

    • 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.

    What is a verifiable credential, and why is it important?

    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.

    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.

    You can see all this happening in the diagram below:

    What technologies is Indicio Proven compatible with?

    • Proven is interoperable and compatible with:

      • Current and emerging global protocols, specifications, and standards for decentralized identity.

    How does Indicio Proven differ from other verifiable credential solutions?

    • Fully decentralized, leveraging open-source technologies like Hyperledger Aries and AnonCreds.

    • Designed for cross-network and cross-ledger compatibility, ensuring vendor-agnostic solutions

    How does Indicio Proven work?

    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

    Who can use Indicio Proven?

    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.

    How does Indicio Proven improve user privacy?

    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.

    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.

    What digital wallets are compatible with Indicio Proven?

    Proven is compatible with all wallets built using Hyperledger Aries

    Is Indicio Proven compliant with industry standards?

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

    How is Indicio Proven implemented in an organization?

    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.

    Can Indicio Proven integrate with existing identity management systems?

    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.

    Does Indicio Proven require specialized infrastructure?

    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.

    How does Indicio Proven enhance security compared to traditional systems?

    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.

    Is training required for users and administrators?

    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.

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

    Can Indicio Proven support multiple credentials for a single user?

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

    What support is available for organizations implementing Indicio Proven?

    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.

    What happens if a user loses their phone with their credential?

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

    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.

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

    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.

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

    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.

    What’s not on the ledger?

    1. Personally Identifying Information (PII)

      1. No PII or personal data of any kind is recorded on the ledger.

    How do we ensure no personal identifying information ends up on the ledger?

    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: And

    What server/agents are needed for Indicio Proven?

    The server recommended may change as technology evolves but right now we recommend

    • 50 GB Hard drive SSD

    • AWS Type: c6i.larg

    What are the costs involved in implementing Indicio Proven?

    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.

    What if a smartphone isn’t available for login?

    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.

  • 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

  • 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

  • The European Union’s new regulations for digital identity (eIDAS) and digital wallets (EUDI)

  • 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,

    • government, enterprise, and travel sectors.

  • Proven enables the creation of Trusted Digital Ecosystems for immediately actionable data.

  • Cloud-agnostic and supports multiple networks,

  • 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.

  • Open-source foundation fosters innovation and collaboration within the decentralized identity community.

  • 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

  • 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).
  • 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.

  • High availability: If one node on the network goes down for any reason, there are plenty of others to receive data from.

  • 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:

    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 credential format with . 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

      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.

    Credential Issuance

    1. No information about the issuance of any individual credential is recorded on the ledger.

  • 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

    What does the ledger do?
    Why a ledger?
    AnonCreds
    Hyperledger Indy

    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.

    5. Change the Deployment name 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

    1. Add a DNS entry for Proven.

    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.

    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

    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.

    TAILS_URL= Replace the IP address on this line with your local IP address. Leave the port as 6543.

    NODE_ENV=production

    PROVEN_ISSUER_API_DB_PASSWORD=provenapi Local database password. For security purposes, this MUST be changed.

    PROVEN_ISSUER_AGENT_DB_PASSWORD=provenagent Local database password. For security purposes, this MUST be changed.

    PROVEN_ISSUER_PROXY_DB_PASSWORD=provenagent Local database password. For security purposes, this MUST be changed.

    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.

    PROVEN_ISSUER_ENC_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters. Encryption key.

    PROVEN_ADMIN_PASSWORD= Must be added and must be 15 characters long.

    PROVEN_ISSUER_WEB_ROOT= 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 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    PROVEN_ISSUER_SESSION_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    PROVEN_ISSUER_ENC_KEY=54234625127cb22694ff0e27cc14b685 For Security purposes, this value MUST be changed. Must be 32 alphanumeric characters.

    1. For an example of a configured .env file, please see Appendix B.

    2. Run the following command:

      1. sudo systemctl start proven

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

    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

    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.

    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=

    /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=

    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=

    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=

    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=

    PROVEN_ISSUER_SEED=

    TEST_SEED=

    TAILS_URL=

    DISABLE_SSL_CHECK=true

    NODE_ENV=development

    GOVERNANCE_PATH=

    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=

    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

    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 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:

    For help with setting up your own Issuer DID, please contact us:

    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.

    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.

    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).

    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:

    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 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.

    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 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.

    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 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 (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.

    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 (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.

    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.

    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.

    The Digital Credentials (DC) API is supported by both Android and iOS and allows for simpler verifiable credential support on websites.

    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.

    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.

    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?

    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.

    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.

    Congratulations, you now have an instance of Proven that you can use for learning, experimentation, and development!

    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.

    The demonstrates how to connect, issue, and verify an AnonCreds credential using a Proven Agent and the Holdr+ Mobile Wallet application.

    See for instructions to issue and verify an SD-JWT VC or JWT VC using a Proven Agent and then using the SDK.

    See to view the API calls to issue and verify JSON-LD type credentials using a Proven Agent.

    You can also refer to the to learn more about individual API calls.

    The Holdr describes how to install, configure, and use the Holdr SDK.

    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.

    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.

    Keep the following tips and information in mind while you are integrating decentralized identity into your solution using Proven:

    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.

    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.

    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

    Testing your verifiable credential solution and workflows should include standard testing procedures as well as tests to cover some unique decentralized identity considerations.

    There are a number of testing practices that we recommend in order to ensure that a solution is complete, robust, and resilient.

    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.

    Conduct performance and security tests of your system.

    Performance tests:

    • Load testing

    • Stress testing

    • Spike testing

    • Endurance testing

    Security tests:

    • Penetration testing

    • Vulnerability scanning

    • Fuzz testing

    • Risk assessments

    Conduct user and acceptance tests to ensure the solution is usable and that you’ve delivered a satisfactory end product.

    There are some unique considerations for testing solutions and workflows that include decentralized identity.

    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 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 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.

    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.

    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.

    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 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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

  • Write code in your system to receive webhooks. Try out these endpoints manually.

  • Configure the webhooks in your Proven verifier to send verifiable presentation data to your system’s new endpoints.

  • 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+.

  • 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.

  • Enforcement - Indicio Proven and the Indicio Holdr SDK will stop working after their license grace periods expire, usually after 60 days.

  • 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.

  • 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.

  • 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.

  • Enforce a strict default-deny inbound policy.
  • Allow only the minimum required ports (e.g., 80, 443, 22 and possibly 8150 if needed for swagger API access).

  • Restrict SSH access to trusted IPs.

  • DDoS protection - Implement request-rate limiting on ingress with a cloud-native tool like Cloud Armor.

  • 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.

  • OS Security

    1. Apply all OS security patches regularly

  • Access control

    1. Limit the number of users with access to the server (but have at least two).

  • Enforce MFA for all admin accounts.

    1. Backups

  • Automated daily backups.

  • Scalability testing

    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.

  • Architect Your Integration

    DID Methods

    Schemas

    Credential Formats

    mdoc/mDL (ISO 18013-5)

    SD-JWT VCs

    JSON-LD VCs (W3C VCs)

    AnonCreds

    Protocols

    OID4VC

    DIDComm

    BLE, NFC, WiFi Aware

    DC API

    Issuers

    Verifiers

    Wallet and Application Strategy

    Trust Establishment

    Configure Development Environment

    Learn Proven API and Holdr SDK Calls

    Proven

    Holdr SDK

    Implement Your Integration

    A Basic Integration Process

    Integration Tips, Hints, and Information

    Configure Staging Environment

    Configure Production Environment

    Testing Before Launch

    Standard Testing

    Code Tests

    Technical Tests

    Usability and Approval

    Decentralized Identity Testing

    VDR (Verifiable Data Registry)

    Schemas

    Revocation

    Mediator

    Interoperability Testing

    DPIA (Data Protection Impact Assessment)

    Governance

    Launch

    Phased Approach

    Technical Preparation

    Training and Other Materials

    After Launch

    Gather Data and Feedback

    Applying Security Updates

    Updating Your Software

    Summary

    https://indyscan.indiciotech.io/tx/IND_DEMONET/domain/47432
    Indicio Proven API Tutorial
    API Calls for OID4VCI and OID4VP SDJWT
    Indicio Proven API Documentation
    Indicio Proven API Reference
    Mobile SDK Documentation
    Select “Indicio Proven”.
  • 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.

  • Click EDIT
  • Scroll down to Networking and under Firewalls check the boxes that will allow HTTP and HTTPS traffic.

  • Click SAVE

  • Click VM instances (in the left menu)

  • Record the External IP address of your Proven instance for later use.

  • Run this command for Proven.
  • 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.

  • 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.

  • 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.

  • 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

  • Agree to the Transaction Author Agreement
  • To anchor the new DID which is now displayed -> open https://selfserve.indiciotech.io

  • 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.

  • Copy the new DID and Verkey displayed on the Proven window, to the DID and Verkey fields of the Selfserve form.

  • Click Submit

  • Return to the Proven SSH window and enter ‘y’ to indicate having anchored the Endorser DID.

  • Wait while the Credential definitions are created for you.

  • When you see Completed, then press enter to continue.

  • Your Proven instance is now ready to go!

  • 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!

  • 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)

  • Click Create

  • Here’s an example configuration:

  • 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.

  • 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”

  • sudo vi .env

  • Add a line right after the SCHEMA_USER line

    1. SCHEMA_EMPLOYMENT=4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0

  • Save and exit

  • 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

  • Update the schema definition files with the new schema:

    1. sudo vi config/proven-issuer-api/schemas.json { "schemas": [ { "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0" }, { "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0" } ] }

    2. sudo vi config/proven-issuer-api/schemas-verification.json { "schemaList": [ { "verification_label": "User - Full Disclosure", "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0", "schema_attributes": [ "username", "user_email", "user_id", "user_roles" ] }, { "verification_label": "User - Username and User Email", "schema_id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0", "schema_attributes": [ "username", "user_email" ] }, { "verification_label": "Employment - Full Disclosure", "schema_id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0", "schema_attributes": [ "employer_region", "employment_type", "employee_given_names", "employer_country", "employment_postal_code", "employment_start_date", "employer_postal_code", "employment_country", "employment_role", "employer_city", "employer_address", "employment_role_description", "employee_surnames", "employer_name", "employment_city", "employment_region", "employment_address" ] } ] }

    3. Save and exit

  • 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.

  • 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

  • Return to main instructions and continue.

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

    Configure the VM

    Accessing Proven

    (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

    Appendix A - DNS Setup Example

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

    Appendix C - Add a new credential type

    Appendix D - Issuer DID setup

    http://10.128.15.205:6543
    https://proven.dev.indiciotech.io
    https://raw.githubusercontent.com/Indicio-tech/indicio-network/main
    http://10.128.15.205:6543
    http://localhost:3100/api/governance-framework
    https://issuer.dev.indiciotech.io
    https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/genesis_files/pool_transactions_demonet_genesis
    http://10.128.15.205:6543
    http://localhost:3100/api/governance-framework
    https://issuer-proven-test.dev.indiciotech.io
    support@indicio.tech
    support@indicio.tech
    {
      "attr_names": [
        "user_email",
        "username",
        "user_id",
        "user_roles"
      ],
      "name": "User",
      "version": "1.0"
    }
     cd /opt/indicio/proven-release-docker
     sudo systemctl enable proven
     sudo cp staging.env .env

    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.

    Please complete this form now!

    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

    • 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.

    Use this API to check whether the agent has been initialized with mdoc issuer key material and is ready to issue credentials.

    No request body or parameters.

    • 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

    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.

    • 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).

    • 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

    Optional query parameters:

    • doctype {string}: Filter results to a specific document type.

    • config_id {string}: Filter results to a specific configuration record.

    Returns an array of configuration objects, each with the same fields as the dbConfig object in the POST response above.

    Use this API to create a credential exchange and generate an offer that can be delivered to a holder's wallet.

    • 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

    • 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

    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.

    Use this API to define what credentials and claims you want to request from a holder.

    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.

    • 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.

    Retrieve all presentation definitions registered for your wallet.

    No request body or parameters.

    Returns an array of presentation definition objects, each with the same fields as the POST response for creating a presentation definition above.

    • pres_def_id {string} (path parameter, required): The identifier of the presentation definition to retrieve.

    Returns a single presentation definition object with the same fields as the POST response for creating a presentation definition above.

    • pres_def_id {string} (path parameter, required): The identifier of the presentation definition to delete.

    • Only an HTTP status response code is returned.

    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.

    • 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"] }.

    • 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.

    After the holder's wallet responds to the presentation request, use this API to retrieve all of the results.

    Optional query parameters:

    • sort-field {string}: The field to sort by (default updated_at).

    • sort-direction {string}: Sort direction, ASC or DESC (default DESC).

    • 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

    After the holder's wallet responds to the presentation request, use this API to retrieve a specific result.

    • presentation_exchange_id {string} (path parameter, required): The identifier of the presentation exchange to retrieve.

    Returns a single presentation record with the same fields as described in the list response above.

    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, 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.

    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 for data minimization and privacy in eIDAS.

    Basic Messages

    Endpoints for sending and retrieving basic messages

    requirements
    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.

  • 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.

  • 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.

  • ,
    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.

  • 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.

    • 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'].

    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.

  • 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.

  • 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.

  • {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.

  • Key Status

    Example curl Command:

    Request

    Response

    Schemas

    Setup a Schema

    Example curl Command:

    Request (POST)

    Response

    List Schemas

    Example curl Command:

    Request (GET)

    Response

    Issuance

    Example curl Command:

    Request (POST)

    Response

    Verification

    Create a Presentation Definition

    Example curl Command:

    Request (POST)

    Response

    List Presentation Definitions

    Example curl Command:

    Request (GET)

    Response

    Get a Single Presentation Definition

    Example curl Command:

    Request (GET)

    Response

    Delete a Presentation Definition

    Example curl Command:

    Request (DELETE)

    Response

    Create a Presentation Request

    Example curl Command:

    Request (POST)

    Response

    Retrieve Presentation Results

    Example curl Command:

    Request (GET)

    Response

    Get a Single Presentation

    Example curl Command:

    Request (GET)

    Response

    curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/status/mdoc' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    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" 
    }'
    
    curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/credentials-supported/mdoc' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    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": ""
      }
    }'
    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'\'']"]
                            }
                        ]
                    }
                }
            ]
        }
    }'
    curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions/{pres_def_id}' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    curl --location --request DELETE 'https://buckets4life.share.zrok.io/api/v1/oid4vp/presentation-definitions/{pres_def_id}' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    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"]
            }
        }
    }'
    curl --location 'https://buckets4life.share.zrok.io/api/v1/presentations' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='
    curl --location 'https://buckets4life.share.zrok.io/api/v1/presentations/{presentation_exchange_id}' \
    --header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4='

    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

    • Did:Peer:1

    • Did:Peer:2

    • Did:Key

    • Anoncreds

    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.

    Starts the agent and connects to the default mediator if a mediation configuration is provided.

    Stops all even listeners and websockets and properly closes the wallet’s database files, so the agent can be used later.

    Deletes the agent and all data associated with it, essentially resetting the wallet.

    Sends a didExchange request to the agent associated with the provided out-of-band record.

    Completes the didExchange handshake by sending a complete message to the agent associated with the provided didExchangeId.

    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.

    Used to send a trust ping to another agent to ensure we can reach the agent.

    Waits until the provided didExchangeId reaches a state of Done or until the provided timeout is reached.

    Retrieves all didExchange records.

    Finds all records that have tags matching the given query.

    Retrieves the record with the provided ID or throws a RecordNotFoundError.

    Finds the record with the given ID or returns null if not found.

    Deletes the record with the given ID or throws RecordNotFoundError if it does not exist.

    Finds all records associated with the given out-of-band ID.

    Finds the record associated with the provided Did.

    Finds the record whose invitation contained the provided Did.

    Creates an out-of-band invitation and corresponding out-of-band record that is returned.

    Parses a URL encoded invitation into an OutOfBandInvitationMessage.

    Processes the provided invitation and potentially starts or completes didExchange protocol.

    Processes an invitation where the invitation message is not present and the agent is implicitly invited.

    Accepts the invitation of an existing out-of-band record. It is not commonly used.

    Finds the out-of-band record with the corresponding invitation ID, or returns null.

    Finds the out-of-band record that corresponds to the invitation with the given ID that we have created, or returns null.

    Retrieves all of the out-of-band records held by the agent.

    Retrieves all out-of-band records that match the provided query.

    Retrieves the record with the provided ID or throws RecordNotFoundError.

    Finds the record with the given ID or returns null.

    Deletes the record with the given ID or throws RecordNotFoundError if no such record exists.

    Finds all credentials whose schema ID matches the provided schema ID.

    Sends a proposal to the connection with the associated didExchangeId that we want the specified credential from.

    Accepts the offer associated with the provided credential exchange record.

    Accepts the issue credential and saves it to the agent's wallet.

    Finds the record with the given ID or returns null.

    Finds all credentials whose exchange state matches the provided state.

    Finds all records whose state matches the given state and came from the connection associated with the given didExchangeId.

    Retrieves all of the credentialExchangeRecords.

    Finds the credential exchange record that has matching threadId and didExchangeId (optional) or returns null.

    Retrieves the credential exchange record that has matching threadId and didExchangeId (optional): otherwise it throws RecordNotFoundError.

    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.

    Accepts the given proof using the provided credential selections, it will throw ProvenError if the credential selection is invalid or insufficient.

    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.

    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.

    Retrieves the proof records for a given connection from the didExchange ID.

    Starts or resumes the mediation to the default mediator. Called in agent.start by default.

    Instructs the agent to attempt to pick up messages from the provided mediator record or the default mediator if not provided.

    Finds the default mediator if one is set, otherwise returns null.

    Finds the default mediator’s record. If the default mediator is found but not granted, this will throw ProvenError.

    Sets the default mediator.

    Requests mediation from the given didExchange connection.

    Retrieves the mediation record with the provided didExchange ID or throws RecordNotFoundError.

    Finds the mediation record with the given didExchange ID or returns null if not found.

    Retrieves all of the meditation records.

    Finds the didExchange record for the default mediator or returns null if not found

    Attempts to complete the mediation request from the provided didExchange record in the given time. If it doesn’t complete, it will throw CancellatinException.

    Retrieves the routing for this mediator. This is not available in React Native.

    Sends a basic message to another connection.

    Finds a basic message record by ID.

    Retrieves all basic messages.

    Finds all basic messages with matching comments.

    Finds all basic messages from the recipient.

    Finds all basic messages that match the role.

    React Native events take a callback function and return a function to remove the callback.

    The events that can have a handler registered are:

    • registerDidExchangeHandler

    • registerProofsHandler

    • registerCredentialsHandler

    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.

    The events that can be retrieved in Kotlin are the following:

    • getDidExchangeEvents

    • getAgentEvents

    • getCredentialEvents

    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

    Swift

    registerAgentHandler

  • registerBasicMessageHandler

  • registerRecordHandler

  • registerWebSocketHandler

  • getEventBusEvents (Record update events)

  • getMessageEvents (Events for all messages)

  • getProofEvents

  • getBasicMessageEvents

  • getTrustPingEvents

  • getWebSocketEvents

  • onAgentEvent

  • onRecordEvent

  • onProofEvent

  • onWebsocketEvent

  • onBasicMessageEvent

  • await agent.start(
        timeout: 10_000 // Optional -- time limit in MS to connect to mediator
    )
    await agent.stop()
    await agent.delete()
    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
    )
    const didExchangeRecord = await agent.didExchange.acceptResponse(
        didExchangeId: String
    )
    const didExchangeRecord = await agent.didExchange(
        didExchangeId: String,
        outOfBandId: String,
        routingParam: Routing | undefined // Not available in React Native
    )
    const trustPingMessage = await agent.didExchange.sendPing(
        exchangeId: String,
        responseRequested: Boolean,
        returnRouting: Boolean
    )
    const didExchangeStateChangedEvent: DidExchangeStateChangedEvent? = await agent.didExchange.returnWhenIsConnected(
        didExchangeId: String,
        timeOutMs: Number | Long
    )
    const records: Array<DidExchangeRecord> = await agent.didExchange.getAll()
    const records: Array<DidExchangeRecord> = await agent.didExchange.findAllByQuery(
        query: Query // Record<String, String> in React Native. Malformed Query will throw
    )
    const record = await agent.didExchange.getById(
        didExchangeId: String
    )
    const record: DidExchangeRecord? = await agent.didExchange.findById(
        didExchangeId: String
    )
    await agent.didExchange.deleteById(
        didExchangeId: String
    )
    const records: Array<DidExchangeRecord> = await agent.didExchange.getAllByOutOfBandId(
      outOfBandId: String
    )
    const record: DidExchangeRecord? = await agent.didExchange.findByDid(
        did: String
    )
    const record: DidExchangeRecord? = await agent.didExchange.findByInvitationDid(
        did: String
    )
    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
    )
    const message = agent.outOfBand.parseInvitation(
        invitationUrl: String
    )
    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
    )
    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
    )
    const invitationResponse = await agent.outOfBand.acceptInvitation(
        outOfBand: String,
        autoAcceptConnection: Boolean,
        reuseConnection: Boolean,
        label: String,
        alias: String | null,
        routingParam: Routing | null,
        timeOutMs: Number | undefined
    )
    const record: OutOfBandRecord? = await agent.outOfBand.findByReceivedInvitationId(
        receivedInvitationId: String
    )
    const record: OutOfBandRecord? = await agent.outOfBand.findByCreatedInvitationId(
        createdInvitationId: String
    )
    const records: Array<OutOfBandRecord> = await agent.outOfBand.getAll()
    const records: Array<OutOfBandRecord> = await agent.outOfBand.getAllByQuery(
        query: Query // Record<String, String> in React Native. Malformed Query will throw
    )
    const record = await agent.outOfBand.getById(
        outOfBandId: String
    )
    const record: OutOfBandRecord? = await agent.outOfBand.findById(
        outOfBandId: String
    )
    await agent.outOfBand.deleteById(
        outOfBandId: String
    )
    const records: Array<CredentialRecord> = await agent.credentials.findAllCredentialsBySchemaId(
        schemaId: String
    )
    const records: Array<CredentialRecord> = await agent.credentials.findAllCredentialsBySchemaId(
        schemaId: String
    )
    const record = await agent.credentials.acceptOffer(
        credentialExchangeId: String,
        autoAcceptCredential: Boolean | undefined,
        comment: String | null | undefined
    )
    const record = agent.credentials.acceptCredential(
        credentialExchangeId: String
    )
    const record: CredentialExchangeRecord? = await agent.credentials.findByRecordId(
        credentialExchangeId: String
    )
    const records: Array<CredentialExchangeRecord> = await agent.credentials.findAllByState(
        state: CredentialState
    )
    const records: Array<CredentialExchangeRecord> = await agent.credentials.findAllByStateAndDidExchangeId(
        state: CredentialState,
        didExchangeId: String
    )
    const records: Array<CredentialExchangeRecord> = await agent.credentials.getAll()
    const record = await agent.credentials.findByThreadIdAndDidExchangeId(
        threadId: String,
        didExchangeId: String | null
    )
    const record = await agent.proofs.autoAcceptProof(
        proofId: String,
        exchangeId: String
    )
    const record = await agent.proofs.acceptProof(
        proofData: PresentationData
    )
    const creds = await agent.proofs.getCredentialsForProofRequest(
        proofId: String,
        exchangeId: String,
        nonRevoked: Boolean | undefined
    )
    const creds = await agent.proofs.autoSelectCredentialsForProofRequest(
        proofId: String,
        exchangeId: String,
        nonRevoked: Boolean | undefined
    )
    const records: Array<ProofRecord> = await agent.proofs.getProofRequestsForConnection(
        didExchangeId: String
    )
    await agent.routing.initialize()
    await agent.routing.initiateMessagePickup(
        mediator: MediationRecord | null | undefined // Record id is used in React Native
    )
    const record: MediationRecord? = await agent.routing.findDefaultMediator()
    const record: MediationRecord? = await agent.routing.discoverMediation()
    const record = await agent.routing.setDefaultMediator(
        mediation: MediationRecord | String // Provide the record or the record id. React native only uses Id
    )
    const record = await agent.routing.requestMediation(
        didExchange: DidExchangeRecord | String // Provide the record or the record id. React native only uses Id
    )
    const record = await agent.routing.getByExchangeId(
        exchangeId: String
    )
    const record: MediationRecord? = await agent.routing.findByExchangeId(
        exchangeId: String
    )
    const records: Array<MediationRecord> = await agent.routing.getMediators()
    const record: DidExchangeRecord? = await agent.routing.findDefaultMediatorExchange()
    const record: MediationRecord? = await agent.routing.provision(
        didExchangeRecord: DidExchangeRecord,
        timeOutMs: Number | Long | undefined
    )
    const routing = await agent.routing.getRouting(
        mediatorId: String,
        useDefaultMediator: Boolean | undefined
    )
    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
    )
    const basicMessage = await agent.basicMessages.findById(
        basicMessageRecordId: String // Record ID to be retrieved
    )
    const basicMessages = await agent.basicMessages.getAll()
    const basicMessages = await agent.basicMessages.findByComment(
        comment: String // Comment to search for
    )
    const basicMessages = await agent.basicMessages.findByDidExchangeId(
        didExchangeId: String // Exchange ID to look for
    )
    const basicMessages = await agent.basicMessages.findByRole(
        role: BasicMessageRole // Role to look for
    )
    const remove = agent.events.registerDidExchangeHandler((event) => {
        console.log("Got a didExchange event")
    })
    
    remove() // cancels the event callback
    / 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
    }
    
    let removeListener = agent.events.onDidExchangeStateChanged { event in
      // Handle DidExchangeStateChangedEvent here
    }
    // Remove listener when no longer needed
    removeListener(nil)

    Supported DID methods:

    Supported credential formats:

    API Overview

    Agent

    async agent.start(): void

    async agent.stop(): void

    async agent.delete(): void

    DidExchange

    async didExchange.acceptOutOfBandInvitation(): DidExchangeRecord

    async didExchange.acceptResponse(): DidExchangeRecord

    async didExchange.requestConnection(): DidExchangeRecord

    async didExchange.sendPing(): TrustPingMessage

    async didExchange.returnWhenIsConnected(): DidExchangeStateChangedEvent?

    async didExchange.getAll(): Array[DidExchangeRecord]

    async didExchange.findAllByQuery(): Array[DidExchangeRecord]

    async didExchange.getById(): DidExchangeRecord

    async didExchange.findById(): DidExchangeRecord?

    async didExchange.deleteById(): void

    async didExchange.findAllByOutOfBandId(): Array[DidExchangeRecord]

    async didExchange.findByDid(): DidExchangeRecord?

    async didExchange.findByInvitationDid(): DidExchangeRecord?

    Out Of Band

    async outOfBand.createInvitation(): OutOfBandRecord

    outOfBand.parseInvitation(): OutOfBandInvitationMessage

    async outOfBand.receiveInvitation(): AcceptInvitationResponse

    async outOfBand.receiveImplicitInvitation(): AcceptInvitationResponse

    async outOfBand.acceptInvitation(): AcceptInvitationResponse

    async outOfBand.findByInvitationId(): OutOfBandRecord?

    async outOfBand.findByCreatedInvitationId(): OutOfBandRecord?

    async outOfBand.getAll(): Array[OutOfBandRecord]

    async outOfBand.getAllByQuery(): Array[OutOfBandRecord]

    async outOfBand.getById(): OutOfBandRecord

    async outOfBand.findById(): OutOfBandRecord?

    async outOfBand.deleteById(): void

    Credentials

    async credentials.findAllCredentialsBySchemaId(): Array[CredentialRecord]

    async credentials.proposeCredential(): CredentialExchangeRecord

    async credentials.acceptOffer(): CredentialExchangeRecord

    async credentials.acceptCredential(): CredentialExchangeRecord

    async credentials.findByRecordId(): CredentialExchangeRecord?

    async credentials.findAllByState(): Array[CredentialExchangeRecord]

    async credentials.findAllByStateAndDidExchangeId(): Array[CredentialExchangeRecord]

    async credentials.getAll(): Array[CredentialExchangeRecord]

    async credentials.findByThreadIdAndDidExchangeId(): CredentialExchangeRecord?

    async credentials.getByThreadIdAndDidExchangeId(): CredentialExchangeRecord

    Proofs

    async proofs.autoAcceptProof(): ProofRecord

    async proofs.acceptProof(): ProofRecord

    async proofs.getCredentialsForProofRequest(): PresentationData

    async proofs.autoSelectCredentialsForProofRequest(): PresentationData

    async proofs.getProofRequestsForConnection(): Array[ProofRecord]

    Routing

    async routing.initialize(): void

    async routing.initiateMessagePickup(): void

    async routing.findDefaultMediator(): MediationRecord?

    async routing.discoverMediation(): MediationRecord?

    async routing.setDefaultMediator(): MediationRecord

    async routing.requestMediation(): MediationRecord

    async routing.getByExchangeId(): MediationRecord

    async routing.findByExchangeId(): MediationRecord

    async routing.getMediators(): Array[MediationRecord]

    async routing.findDefaultMediatorExchange(): DidExchangeRecord?

    async routing.provision(): MediationRecord?

    async routing.getRouting(): Routing

    Basic Messaging

    async basicMessages.send(): BasicMessageRecord

    async basicMessages.findById(): BasicMessageRecord

    async basicMessages.getAll(): Array

    async basicMessages.findByComment(): Array

    async basicMessages.findByDidExchangeId(): Array

    async basicMessages.findByRole(): Array

    Events

    React Native

    Kotlin

    Swift

    Agent API
    DidExchange API
    OutOfBand API
    Credentials API
    Proofs API
    Routing API
    Events API

    Issue JSON-LD credentials

    post

    This endpoint issues JSON-LD credentials.

    Authorizations
    x-api-keystringRequired
    Query parameters
    timeoutintegerOptional

    The timeout for the credential issuance (seconds).

    Example: 30
    Body
    Responses
    200

    JSON-LD credential issued successfully

    application/json
    recordobjectOptional
    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    422

    Unprocessable Entity.

    application/json
    errorstringOptionalExample: string
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error.
    post/api/v1/credentials/json-ld

    Retrieve a JSON-LD credential by ID

    get

    This endpoint retrieves a JSON-LD credential by its ID using the provided API key.

    Authorizations
    x-api-keystringRequired
    Path parameters
    request_idstringRequired

    The ID of the credential.

    Example: 1
    Responses
    200

    JSON-LD credential retrieved successfully

    application/json
    recordobjectOptional

    The retrieved JSON-LD credential record.

    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    404

    JSON-LD credential record not found

    application/json
    errorstringOptionalExample: JSON-LD credential record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/credentials/json-ld/{request_id}

    Retrieve all credentials

    get

    This endpoint retrieves all credentials associated with the provided API.

    Authorizations
    x-api-keystringRequired
    Query parameters
    sort-fieldstringOptional

    The field to sort by (default updated_at).

    sort-directionstringOptional

    The direction to sort (ASC or DESC, default DESC).

    page-sizeintegerOptional

    The number of credentials per page (default 20).

    current-pageintegerOptional

    The current page number (default 1).

    item-countintegerOptional

    The total number of items.

    state-filterstringOptional

    If provided, returns only credentials with this state.

    contact-idstringOptional

    If provided, returns only credentials for this contact_id.

    Responses
    200

    A paginated list of credentials

    application/json
    itemsstring[]Optional
    pageSizeintegerOptional
    currentPageintegerOptional
    pageCountintegerOptional
    itemCountintegerOptional
    stateFilterstring · nullableOptional
    contactIdFilterstring · nullableOptional
    rowsobject[]Optional
    countintegerOptional
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: API key record not found
    get/api/v1/credentials

    Issue a new AnonCred credential

    post

    This endpoint allows you to add a new credential request.

    Authorizations
    x-api-keystringRequired
    Query parameters
    timeoutintegerOptional

    The timeout for the credential issuance (seconds).

    Example: 30
    Body
    invitation_idintegerOptional

    The ID of the invitation.

    contact_idstringOptional

    The ID of the contact.

    schema_idstringOptional

    The ID of the schema.

    namestringOptional

    The name of the attribute.

    valuestringOptional

    The value of the attribute.

    rulestringOptional

    The rule for the credential issuance.

    Responses
    200

    AnonCred credential issuance record was created

    application/json
    recordobjectOptional
    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    422

    Unprocessable Entity.

    application/json
    errorstringOptionalExample: string
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/credentials

    Retrieve a credential by its credential definition ID

    get

    This endpoint retrieves a specific credential by its credential exchange ID.

    Authorizations
    x-api-keystringRequired
    Path parameters
    credential_exchange_idstringRequired

    The credential exchange ID.

    Example: 1
    Responses
    200

    A credential object

    application/json
    credentialobjectOptional
    401

    Unauthorized.

    No content

    404

    Credential record not found

    application/json
    errorstringOptionalExample: Credential record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/credentials/{credential_exchange_id}

    Remove PII from a credential

    post

    This endpoint manually removes PII from a credential record.

    Authorizations
    x-api-keystringRequired
    Path parameters
    credential_exchange_idstringRequired

    The credential exchange ID.

    Example: 02189932-52ac-4f9d-bf84-1fcfb7c67fa1
    Responses
    200

    PII removed successfully

    application/json
    messagestringOptionalExample: Credential PII removed
    401

    Unauthorized.

    No content

    404

    Credential record not found

    application/json
    errorstringOptionalExample: Credential record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/credentials/{credential_exchange_id}/pii

    Retrieve an AnonCred credential record by ID

    get

    This endpoint retrieves an AnonCred credential record by its ID using the provided API key.

    Authorizations
    x-api-keystringRequired
    Path parameters
    request_idstringRequired

    The ID of the credential record.

    Example: 1
    Responses
    200

    Credential record retrieved successfully

    application/json
    recordobjectOptional

    The retrieved AnonCred credential record.

    401

    Unauthorized.

    No content

    404

    AnonCred credential record not found

    application/json
    errorstringOptionalExample: AnonCred credential record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/credential-records/{request_id}

    Revoke an issued AnonCred credential

    post

    This endpoint allows you to revoke a credential by providing the connection and credential exchange IDs.

    Authorizations
    x-api-keystringRequired
    Body
    connection_idstringOptional

    The connection ID associated with the credential.

    credential_exchange_idstringOptional

    The credential exchange ID of the credential to revoke.

    Responses
    200

    Credential revocation request accepted or already revoked

    application/json
    successbooleanOptional
    messagestringOptional
    400

    Bad Request

    application/json
    errorstringOptional
    401

    Unauthorized

    No content

    422

    Unprocessable Entity

    application/json
    errorstringOptional
    500

    Internal Server Error

    application/json
    errorstringOptional
    post/api/v1/credentials/anoncreds/revoke

    Get governance file by filename

    get

    This endpoint retrieves a governance file by its filename.

    Authorizations
    x-api-keystringRequired
    Path parameters
    filenamestringRequired

    The filename of the governance file to retrieve.

    Responses
    200

    Governance file retrieved successfully

    application/json
    objectOptional
    404

    Governance file not found

    application/json
    errorstringOptionalExample: Governance file not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/governance/files/{filename}

    Get all JSON-LD context files for a specific wallet

    get

    This endpoint retrieves all JSON-LD context files for the authenticated wallet.

    Authorizations
    x-api-keystringRequired
    Responses
    200

    A list of JSON-LD context files for the wallet

    application/json
    object[]Optional
    401

    Unauthorized

    No content

    500

    Internal Server Error

    application/json
    get/api/v1/context

    Save a JSON-LD context file for a specific wallet

    post

    This endpoint saves a JSON-LD context file for a specific wallet.

    Authorizations
    x-api-keystringRequired
    Body
    context_file_idstringOptional

    The filename of the JSON-LD context file to save.

    Example: test.json
    @contextobjectOptional

    The JSON-LD context.

    Example: {"GenericCredential":{"@id":"https://example.com/indicio#GenericCredential","@context":{"name":"http://schema.org/name","familyName":"http://schema.org/familyName","givenName":"http://schema.org/givenName","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"}}}
    Responses
    200

    Context saved successfully

    application/json
    400

    Bad Request

    No content

    401

    Unauthorized

    No content

    500

    Internal Server Error

    No content

    post/api/v1/context

    Get a JSON-LD context file by ID for a specific wallet

    get

    This endpoint retrieves a JSON-LD context file by its ID for the authenticated wallet.

    Authorizations
    x-api-keystringRequired
    Path parameters
    context_file_idstringRequired

    The ID of the JSON-LD context file to retrieve.

    Responses
    200

    JSON-LD context file retrieved successfully

    application/json
    objectOptional
    401

    Unauthorized

    No content

    404

    Context file not found

    No content

    500

    Internal Server Error

    No content

    get/api/v1/context/{context_file_id}

    Get all JSON-LD context files from all wallets

    get

    This endpoint retrieves all JSON-LD context files from all wallets (static route).

    Authorizations
    x-api-keystringRequired
    Responses
    200

    A list of all JSON-LD context files

    application/json
    object[]Optional
    500

    Internal Server Error

    application/json
    get/context

    Perform bulk credential issuance based on the valid email addresses

    post

    This endpoint performs bulk credential issuance based on the valid email addresses.

    Authorizations
    x-api-keystringRequired
    Body
    emailstringOptional

    The email address to be verified as one of the bulk credential recipient.

    Example: no_reply@indiciotech.io
    schema_idstringOptional

    The schema ID of the credential to be issued.

    Example: E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0
    time_to_acceptnumberOptional

    The number of days for the recipient to accept the credential.

    Example: 518400000
    namestringOptional
    valuestringOptional
    Responses
    200

    Email verification successful

    application/json
    emailsSuccessstring[]Optional
    emailsFailurestring[]Optional
    invalidEmailsstring[]Optional
    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/emails/verify

    Create a new subwallet

    post

    This endpoint allows you to create a new subwallet by providing a wallet name and an optional label.

    Authorizations
    x-api-keystringRequired
    Body
    wallet_namestringRequired

    The name of the subwallet to be created.

    Example: mySubwallet
    labelstringOptional

    An optional label for the subwallet.

    Example: My Subwallet Label
    Responses
    201

    Subwallet created successfully

    application/json
    wallet_idstringOptional

    The ID of the created subwallet.

    Example: 1
    tokenstringOptional

    A token for the created subwallet.

    Example: abcdef123456
    400

    Subwallet creation failed due to missing wallet name.

    application/json
    errorstringOptional

    Error message indicating the reason for failure.

    Example: Subwallet creation failed. Subwallet name is required.
    401

    Unauthorized.

    No content

    500

    Internal server error while creating subwallet.

    application/json
    errorstringOptionalExample: Error creating subwallet
    post/api/subwallet/create

    Retrieve all subwallets

    get

    This endpoint allows you to retrieve all subwallets created under this base admin.

    Authorizations
    x-api-keystringRequired
    Responses
    200

    Retrieved subwallets successfully

    application/json
    wallet_idstringOptional

    The ID of the retrieved subwallet.

    Example: 1
    tokenstringOptional

    A token for the retrieved subwallet.

    Example: abcdef123456
    labelstringOptional

    A label for the retrieved subwallet.

    Example: MySubwallet
    401

    Unauthorized.

    No content

    500

    Internal server error while retrieving subwallets.

    application/json
    errorstringOptionalExample: There was a problem retrieving subwallets
    get/api/subwallets

    Retrieve subwallet by wallet_id

    get

    This endpoint allows you to retrieve a subwallet by its wallet_id

    Authorizations
    x-api-keystringRequired
    Path parameters
    idstringRequired

    The ID of the subwallet

    Responses
    200

    A subwallet record

    application/json
    wallet_idstringOptional

    The ID of the retrieved subwallet.

    Example: 1
    tokenstringOptional

    A token for the retrieved subwallet.

    Example: abcdef123456
    labelstringOptional

    A label for the retrieved subwallet.

    Example: MySubwallet
    401

    Unauthorized.

    No content

    404

    Subwallet record not found

    application/json
    errorstringOptionalExample: Subwallet record not found
    500

    Internal server error while retrieving a subwallet.

    application/json
    errorstringOptionalExample: There was a problem retrieving subwallet
    get/api/subwallets/{wallet_id}

    Create a new API key

    post

    Generates a new API key and stores its HMAC in the database. API key names must be unique per wallet.

    Authorizations
    x-api-keystringRequired
    Body
    wallet_idstringOptional

    The ID of the wallet for which the API key is being created.

    namestringOptional

    A descriptive label for the API key.

    rolesstring[]Optional

    The roles associated with the API key.

    expires_atstring · date-time · nullableOptional

    Optional ISO-8601 timestamp when the API key expires. Omit or set to null for no expiration.

    Responses
    200

    API key successfully created.

    application/json
    api_keystringOptional

    The generated API key.

    key_idstringOptional

    The ID of the stored HMACed API key.

    namestringOptional

    The saved label for the API key.

    statusstringOptional

    Status message.

    expires_atstring · date-time · nullableOptional

    The selected expiration timestamp, if provided.

    400

    Bad request. Missing or invalid parameters.

    application/json
    errorstringOptional

    Error message.

    401

    Unauthorized.

    No content

    500

    Internal server error.

    application/json
    errorstringOptional

    Error message.

    post/api/apikey/create

    Revoke an API key

    post

    This endpoint revokes an API key by deleting it for the specified wallet and name.

    Authorizations
    x-api-keystringRequired
    Body
    wallet_idstringRequired

    The ID of the wallet associated with the API key.

    Example: wallet123
    namestringRequired

    The name of the API key to be revoked.

    Example: CI worker
    Responses
    200

    API key successfully revoked

    application/json
    statusstringOptional

    Status message indicating the API key was successfully revoked.

    400

    Bad request. Missing or invalid parameters.

    application/json
    errorstringOptional

    Error message indicating what went wrong.

    401

    Unauthorized.

    No content

    404

    API key record not found

    application/json
    errorstringOptionalExample: API key record not found
    500

    Internal server error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/apikey/revoke

    Get all invitations

    get

    This endpoint retrieves all invitations associated with the provided API key.

    Authorizations
    x-api-keystringRequired
    Query parameters
    sort-fieldstringOptional

    The field to sort by (default updated_at).

    sort-directionstringOptional

    The direction to sort (ASC or DESC, default DESC).

    page-sizeintegerOptional

    The number of invitations per page (default 20).

    current-pageintegerOptional

    The current page number (default 1).

    item-countintegerOptional

    The total number of items.

    state-filterstringOptional

    If provided, returns only invitations with this state.

    contact-idstringOptional

    If provided, returns only invitations for this contact_id.

    Responses
    200

    A list of invitations

    application/json
    paramsobjectOptional
    countintegerOptional
    rowsobject[]Optional
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/invitations

    Create a new invitation

    post

    This endpoint creates a new invitation of type OOB.

    Authorizations
    x-api-keystringRequired
    Body
    invitation_typestringRequired

    The type of the invitation (OOB).

    Default: OOB
    contact_idstringOptional

    The ID of the contact.

    Default: undefined
    handshake_protocolstringOptional

    The handshake protocol for OOB invitations.

    Default: undefined
    aliasstringOptional

    The alias for the invitation.

    Default: undefined
    invitation_modestringOptional

    The mode of the invitation.

    Default: undefined
    acceptstringOptional

    The accept criteria for the invitation.

    Default: true
    publicbooleanOptional

    Whether the invitation is public.

    Default: false
    invitation_rolestringOptional

    The role of the invitation.

    Default: undefined
    invitation_labelstringOptional

    The label of the invitation.

    Default: undefined
    invitation_statusstringOptional

    The status of the invitation.

    Default: undefined
    invitation_descriptionstringOptional

    The description of the invitation.

    Default: undefined
    purposestringOptional

    The purpose of the invitation (optional unique identifier - if provided, must be unique per wallet).

    Default: undefined
    invitation_active_starting_atstring · date-timeOptional

    The start time of the invitation's active period.

    Default: undefined
    invitation_active_ending_atstring · date-timeOptional

    The end time of the invitation's active period.

    Default: undefined
    uses_allowednumberOptional

    The number of uses allowed for the invitation.

    Default: undefined
    Responses
    200

    Invitation created successfully

    application/json
    invitation_urlstringOptionalExample: https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl19
    invitation_idintegerOptionalExample: 1
    contact_idstringOptional
    400

    Bad Request

    application/json
    errorstringOptionalExample: {"value":"Purpose must be a string","summary":"Purpose field is not a string"}
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/invitations

    Accept an invitation

    post

    This endpoint accepts an invitation of type OOB.

    Authorizations
    x-api-keystringRequired
    Body
    invitation_urlstringOptional

    The URL of the invitation to be accepted.

    Default: undefinedExample: https://example.com/invitation?oob=abc123
    Responses
    200

    Invitation accepted successfully

    application/json
    successbooleanOptional
    invitation_recordobjectOptional
    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/invitations/accept

    Get invitation by ID

    get

    This endpoint retrieves a specific invitation by its ID.

    Authorizations
    x-api-keystringRequired
    Path parameters
    invitation_idstringRequired

    The ID of the invitation.

    Example: 1
    Responses
    200

    Invitation retrieved successfully

    application/json
    invitationobjectOptional

    The retrieved invitation credential record.

    401

    Unauthorized.

    No content

    404

    Invitation not found

    application/json
    warningstringOptionalExample: Invitation record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/invitations/{invitation_id}

    Update an invitation

    put

    This endpoint updates an existing invitation.

    Authorizations
    x-api-keystringRequired
    Path parameters
    invitation_idstringRequired

    The ID of the invitation to update.

    Body
    workflow_statusstringOptional

    The workflow status of the invitation.

    Example: active
    descriptionstringOptional

    The description of the invitation.

    Example: This is an updated invitation.
    purposestringOptional

    The purpose of the invitation (unique identifier).

    Example: verification-demo-2025
    active_starting_atstring · date-timeOptional

    The start time of the invitation.

    Example: 2023-01-01T00:00:00Z
    active_ending_atstring · date-timeOptional

    The end time of the invitation.

    Example: 2030-12-31T23:59:59Z
    uses_allowedintegerOptional

    The number of uses allowed for the invitation.

    Example: 1
    Responses
    200

    Invitation updated successfully

    application/json
    updatedInvitationobjectOptional

    The updated invitation record.

    400

    Bad request. Invalid parameters.

    application/json
    errorstringOptionalExample: string
    404

    Invitation record not found

    application/json
    errorstringOptionalExample: Invitation record not found
    500

    Internal server error

    application/json
    errorstringOptionalExample: Internal server error
    put/api/v1/invitations/{invitation_id}

    Delete an invitation

    delete

    This endpoint deletes an existing invitation.

    Authorizations
    x-api-keystringRequired
    Path parameters
    invitation_idstringRequired

    The ID of the invitation to delete.

    Responses
    200

    Invitation deleted successfully

    application/json
    successstringOptionalExample: Invitation was deleted successfully!
    400

    Bad request. Invalid parameters.

    application/json
    errorstringOptionalExample: string
    404

    Invitation record not found

    application/json
    errorstringOptionalExample: Invitation record not found
    500

    Internal server error

    application/json
    errorstringOptionalExample: Internal server error
    delete/api/v1/invitations/{invitation_id}

    Get invitation by purpose

    get

    Retrieves a specific invitation by its purpose identifier.

    Authorizations
    x-api-keystringRequired
    Path parameters
    purposestringRequired

    The purpose identifier of the invitation.

    Example: demo-1
    Responses
    200

    Invitation retrieved successfully

    application/json
    invitationobjectOptional

    The retrieved invitation credential record.

    400

    Bad request. Invalid parameters.

    application/json
    errorstringOptionalExample: Invalid purpose parameter!
    401

    Unauthorized.

    No content

    404

    Invitation not found

    application/json
    errorstringOptionalExample: Invitation record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/invitations/purpose/{purpose}

    Create a new DID

    post

    This endpoint creates a new Decentralized Identifier (DID) using the provided API key.

    Authorizations
    x-api-keystringRequired
    Responses
    200

    DID created successfully

    application/json
    didstringOptional

    The created DID.

    Example: 95LAyQitNh5kVaayCFC9S2
    verkeystringOptional

    The verification key for the DID.

    Example: 5QFrR2F9H84nF1T6bBiiahWCiDWrxTnHNtF78u7HPCY4
    posturestringOptional

    The posture of the DID.

    Example: wallet_only
    key_typestringOptional

    The type of key used for the DID.

    Example: ed25519
    methodstringOptional

    DID method.

    Example: sov
    metadataobjectOptional

    Additional metadata for the DID.

    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/create-did

    Set a public DID

    post

    This endpoint sets a public Decentralized Identifier (DID) using the provided API key and DID.

    Authorizations
    x-api-keystringRequired
    Query parameters
    DIDstringRequired

    The DID to be set as public.

    Responses
    200

    DID set as public successfully

    application/json
    didobjectOptional

    The public DID.

    400

    Bad Request

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/set-public-did

    Create a new did:indy DID

    post

    This endpoint creates a new Decentralized Identifier (DID) using the provided API key.

    Authorizations
    x-api-keystringRequired
    Responses
    200

    DID created successfully

    application/json
    didstringOptional

    The created DID.

    401

    Unauthorized.

    No content

    412

    The TAA must be signed before calling this endpoint

    application/json
    errorstringOptionalExample: The TAA must be signed before calling this endpoint
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/did/indy

    Get all connections

    get

    This endpoint retrieves all connections.

    Authorizations
    x-api-keystringRequired
    Query parameters
    sort-fieldstringOptional

    The field to sort by (default updated_at).

    sort-directionstringOptional

    The direction to sort (ASC or DESC, default DESC).

    page-sizeintegerOptional

    The number of connections per page (default 20).

    current-pageintegerOptional

    The current page number (default 1).

    item-countintegerOptional

    The total number of items.

    state-filterstringOptional

    If provided, returns only connections with this state.

    contact-idstringOptional

    If provided, returns only connections for this contact_id.

    Responses
    200

    A list of connections

    application/json
    sortstring[]Optional
    pageSizestringOptional
    currentPageintegerOptional
    pageCountintegerOptional
    itemCountintegerOptional
    stateFilterstring · nullableOptional
    contactIdFilterstring · nullableOptional
    connection_idstringOptional
    statestringOptional
    my_didstringOptional
    aliasstringOptional
    request_idstringOptional
    invitation_keystringOptional
    invitation_msg_idstringOptional
    invitation_modestringOptional
    invitation_urlstringOptional
    @typestringOptional
    @idstringOptional
    labelstringOptional
    handshake_protocolsstring[]Optional
    idstringOptional
    typestringOptional
    recipientKeysstring[]Optional
    serviceEndpointstringOptional
    acceptstringOptional
    initiatorstringOptional
    their_rolestringOptional
    their_didstringOptional
    their_public_didstringOptional
    their_labelstringOptional
    routing_statestringOptional
    inbound_connection_idstringOptional
    error_msgstringOptional
    contact_idstringOptional
    transaction_rolestringOptional
    pidstringOptional
    rolesstring[]Optional
    wallet_idstringOptional
    created_atstringOptional
    updated_atstringOptional
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/connections

    Get a connection by ID

    get

    This endpoint retrieves a connection by its id.

    Authorizations
    x-api-keystringRequired
    Path parameters
    connection_idstringRequired

    The connection id of the connection to retrieve.

    Responses
    200

    Connection record retrieved successfully

    application/json
    connection_idstringOptional
    statestringOptional
    my_didstringOptional
    aliasstringOptional
    request_idstringOptional
    invitation_keystringOptional
    invitation_msg_idstringOptional
    invitation_modestringOptional
    invitation_urlstringOptional
    @typestringOptional
    @idstringOptional
    labelstringOptional
    handshake_protocolsstring[]Optional
    idstringOptional
    typestringOptional
    recipientKeysstring[]Optional
    serviceEndpointstringOptional
    acceptstringOptional
    initiatorstringOptional
    their_rolestringOptional
    their_didstringOptional
    their_public_didstringOptional
    their_labelstringOptional
    routing_statestringOptional
    inbound_connection_idstringOptional
    error_msgstringOptional
    contact_idstringOptional
    transaction_rolestringOptional
    pidstringOptional
    rolesstring[]Optional
    wallet_idstringOptional
    created_atstringOptional
    updated_atstringOptional
    401

    Unauthorized.

    No content

    404

    Connection not found

    application/json
    errorstringOptionalExample: Connection record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/connections/{connection_id}

    Get all messages

    get

    This endpoint retrieves all messages.

    Authorizations
    x-api-keystringRequired
    Responses
    200

    A list of messages

    application/json
    basicMessagesobject[]Optional
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/messages

    Send a basic message

    post

    This endpoint allows you to send a basic message.

    Authorizations
    x-api-keystringRequired
    Body
    invitation_idintegerOptional

    The ID of the invitation.

    Example: 1
    contact_idstringOptional

    The ID of the contact.

    messagestringOptional

    The message content.

    Example: your message here
    Responses
    200

    Message sent successfully

    application/json
    successstringOptional
    400

    Bad request. Invalid parameters.

    application/json
    errorstringOptionalExample: string
    401

    Unauthorized.

    No content

    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    post/api/v1/messages

    Get a message by ID

    get

    This endpoint retrieves a message by its ID.

    Authorizations
    x-api-keystringRequired
    Path parameters
    idstringRequired

    The ID of the message to retrieve.

    Responses
    200

    A message object

    application/json
    invitation_idintegerOptional

    The ID of the invitation.

    contact_idstringOptional

    The ID of the contact.

    messagestringOptional

    The message content.

    401

    Unauthorized.

    No content

    404

    Message not found

    application/json
    errorstringOptionalExample: Basic message record not found
    500

    Internal Server Error

    application/json
    errorstringOptionalExample: Internal server error
    get/api/v1/messages/{id}

    API key successfully revoked

    invitation_idnumber · nullableOptional

    The invitation ID.

    Example: 1
    contact_idstring · nullableOptional

    The contact ID.

    revocation_def_idstring · nullableOptional

    The ID of status list definition to enable revocation

    @contextstring[]Optional

    The contexts of the credential.

    Example: ["https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json","https://www.w3.org/ns/credentials/status/v1"]
    issuanceDatestring · date-timeOptional

    The issuance date of the credential.

    Example: 2024-11-29T21:07:11Z
    validFromstring · date-timeOptional

    The valid from date of the credential.

    Example: 2024-11-29T11:34:20Z
    awardedDatestring · date-timeOptional

    The awarded date of the credential.

    Example: 2024-11-29T21:07:11Z
    expirationDatestring · date-timeOptional

    The expiration date of the credential.

    Example: 2030-11-29T11:34:20Z
    validUntilstring · date-timeOptional

    The valid until date of the credential.

    Example: 2030-11-29T11:34:20Z
    typestring[]Optional

    The types of the credential.

    Example: ["OpenBadgeCredential"]
    descriptionstringOptional

    The description of the credential.

    Example: Awesome Credential Description
    namestringOptional

    The name of the credential.

    Example: New Awesome JSON-LD Credential
    idstringOptional

    The identifier of the issuer

    Example: did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8
    typestring[]Optional

    The types of the issuer.

    Example: ["Profile"]
    namestringOptional

    The name of the issuer.

    Example: Awesome Issuer Name
    descriptionstringOptional

    The description of the issuer.

    Example: An awesome Issuer who Issues awesome credentials.
    urlstringOptional

    The URL of the issuer.

    Example: https://www.awesome-issuer-url.com
    emailstringOptional

    The email of the issuer.

    Example: issuer-contact@example.org
    idstringOptional

    The ID of the image.

    Example: https://www.awesome-issuer-url.com/images/issuer-logo.png
    typestringOptional

    The type of the image.

    Example: Image
    captionstringOptional

    The caption of the image.

    Example: Awesome Issuer Logo
    typestring[]Optional

    The types of the credential subject.

    Example: ["AchievementSubject"]
    idstringOptional

    The ID of the achievement.

    Example: https://example.org/achievements/degree
    namestringOptional

    The name of the achievement.

    Example: Your name
    descriptionstringOptional

    The description of the achievement.

    Example: Your description
    typestringOptional

    The type of the criteria.

    Example: Criteria
    narrativestringOptional

    The narrative of the criteria.

    Example: Your narrative
    idstringOptional

    The ID of the image.

    Example: https://example.org/achievements/image.png
    typestringOptional

    The type of the image.

    Example: Image
    typestring[]Optional

    The types of the achievement.

    Example: ["Achievement"]
    proofTypestringOptional

    The proofType for the credential issuance

    Example: Ed25519Signature2020
    rulestringOptional

    The rule for the credential issuance.

    Example: string
    GET /governance/files/{filename} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {}
    {
      "id": 1,
      "context_file_id": "test.json",
      "file": {
        "@context": {
          "GenericCredential": {
            "@id": "https://example.com/indicio#GenericCredential",
            "@context": {
              "name": "http://schema.org/name",
              "familyName": "http://schema.org/familyName",
              "givenName": "http://schema.org/givenName",
              "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"
            }
          }
        }
      },
      "wallet_id": "e3356f7c-37a2-4e38-a9fc-ba2288dc04a2",
      "created_at": "2025-07-10T03:11:52.623Z",
      "updated_at": "2025-07-10T03:11:52.623Z"
    }
    GET /api/v1/context HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    [
      {
        "id": 1,
        "context_file_id": "test.json",
        "file": {
          "@context": {
            "GenericCredential": {
              "@id": "https://example.com/indicio#GenericCredential",
              "@context": {
                "name": "http://schema.org/name",
                "familyName": "http://schema.org/familyName",
                "givenName": "http://schema.org/givenName",
                "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"
              }
            }
          }
        },
        "wallet_id": "e3356f7c-37a2-4e38-a9fc-ba2288dc04a2",
        "created_at": "2025-07-10T03:11:52.623Z",
        "updated_at": "2025-07-10T03:11:52.623Z"
      }
    ]
    POST /api/v1/context HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 448
    
    {
      "context_file_id": "test.json",
      "file": {
        "@context": {
          "GenericCredential": {
            "@id": "https://example.com/indicio#GenericCredential",
            "@context": {
              "name": "http://schema.org/name",
              "familyName": "http://schema.org/familyName",
              "givenName": "http://schema.org/givenName",
              "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"
            }
          }
        }
      }
    }
    GET /api/v1/context/{context_file_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "id": 1,
      "context_file_id": "test.json",
      "file": {
        "@context": {
          "GenericCredential": {
            "@id": "https://example.com/indicio#GenericCredential",
            "@context": {
              "name": "http://schema.org/name",
              "familyName": "http://schema.org/familyName",
              "givenName": "http://schema.org/givenName",
              "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"
            }
          }
        }
      },
      "wallet_id": "e3356f7c-37a2-4e38-a9fc-ba2288dc04a2",
      "created_at": "2025-07-10T03:11:52.623Z",
      "updated_at": "2025-07-10T03:11:52.623Z"
    }
    GET /context HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    [
      {
        "id": 1,
        "context_file_id": "test.json",
        "file": {
          "@context": {
            "GenericCredential": {
              "@id": "https://example.com/indicio#GenericCredential",
              "@context": {
                "name": "http://schema.org/name",
                "familyName": "http://schema.org/familyName",
                "givenName": "http://schema.org/givenName",
                "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"
              }
            }
          }
        },
        "wallet_id": "e3356f7c-37a2-4e38-a9fc-ba2288dc04a2",
        "created_at": "2025-07-10T03:11:52.623Z",
        "updated_at": "2025-07-10T03:11:52.623Z"
      }
    ]
    {
      "emailsSuccess": [
        "text"
      ],
      "emailsFailure": [
        "text"
      ],
      "invalidEmails": [
        "text"
      ]
    }
    POST /api/v1/emails/verify HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 1026
    
    {
      "emails": [
        {
          "email": "no_reply@indiciotech.io",
          "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
          "time_to_accept": 518400000,
          "attributes": [
            {
              "name": "address",
              "value": "your address here"
            },
            {
              "name": "domain",
              "value": "your domain here"
            },
            {
              "name": "verified_at",
              "value": "your timestamp verified_at here"
            },
            {
              "name": "local_part",
              "value": "your local_part here"
            }
          ]
        },
        {
          "email": "no_reply@indiciotech.io",
          "schema_id": "KT4LtL7HEMePqQSyKVof7g:2:Bad_schema:0.0",
          "time_to_accept": 518400000,
          "attributes": [
            {
              "name": "address",
              "value": "your address here"
            },
            {
              "name": "domain",
              "value": "your domain here"
            },
            {
              "name": "verified_at",
              "value": "your timestamp verified_at here"
            },
            {
              "name": "local_part",
              "value": "your local_part here"
            }
          ]
        },
        {
          "email": "email#with-errors.com",
          "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
          "time_to_accept": 518400000,
          "attributes": [
            {
              "name": "address",
              "value": "your address here"
            },
            {
              "name": "domain",
              "value": "your domain here"
            },
            {
              "name": "verified_at",
              "value": "your timestamp verified_at here"
            },
            {
              "name": "local_part",
              "value": "your local_part here"
            }
          ]
        }
      ]
    }
    {
      "wallet_id": 1,
      "token": "abcdef123456"
    }
    {
      "api_key": "abcdef123456",
      "key_id": "key123",
      "name": "CI worker",
      "status": "API key successfully created.",
      "expires_at": "2026-01-01T00:00:00.000Z"
    }
    {
      "status": "text"
    }
    POST /api/subwallet/create HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 58
    
    {
      "wallet_name": "mySubwallet",
      "label": "My Subwallet Label"
    }
    GET /api/subwallets HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    [
      {
        "wallet_id": 1,
        "token": "abcdef123456",
        "label": "MySubwallet"
      }
    ]
    GET /api/subwallets/{wallet_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "wallet_id": 1,
      "token": "abcdef123456",
      "label": "MySubwallet"
    }
    POST /api/apikey/create HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 102
    
    {
      "wallet_id": "wallet123",
      "name": "CI worker",
      "roles": [
        "admin"
      ],
      "expires_at": "2026-01-01T00:00:00.000Z"
    }
    POST /api/apikey/revoke HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 44
    
    {
      "wallet_id": "wallet123",
      "name": "CI worker"
    }
    {
      "params": {
        "sort": [
          [
            [
              "updated_at",
              "DESC"
            ]
          ]
        ],
        "pageSize": 2,
        "currentPage": 1,
        "pageCount": 1,
        "itemCount": 1,
        "stateFilter": null,
        "contactIdFilter": null
      },
      "rows": [
        {
          "invitation_id": 1,
          "oob_id": "ef62b35f-ebd1-4760-89cd-1b33e6506f22",
          "contact_id": null,
          "connection_id": "853dbc66-4daa-45a8-8a6b-3cb81639c108",
          "my_did": "",
          "alias": "Documentation-Example",
          "invitation_key": "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3",
          "invitation_mode": "multi",
          "invitation_url": "https://example/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICI5MGRhNGU1YS0yNzQxLTRlZmUtYWY2ZC0yMTVkMTZhODQyOGEiLCAibGFiZWwiOiAiUHJvdmVuIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWtwYXpVNEVCTVpKU1VDN3VkOHFLMVRhNkwxTGtqMXhUQ1E3OVJMcVZUTHdRMyN6Nk1rcGF6VTRFQk1aSlNVQzd1ZDhxSzFUYTZMMUxrajF4VENRNzlSTHFWVEx3UTMiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL2J1Y2tldHM0bGlmZS5zaGFyZS56cm9rLmlvL2FnZW50In1dfQ",
          "invitation_msg_id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
          "invitation": {
            "@type": "https://didcomm.org/out-of-band/1.1/invitation",
            "@id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
            "label": "Proven",
            "handshake_protocols": [
              "https://didcomm.org/didexchange/1.1"
            ],
            "services": [
              {
                "id": "#inline",
                "type": "did-communication",
                "recipientKeys": [
                  "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3"
                ],
                "serviceEndpoint": "https://example/agent"
              }
            ]
          },
          "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
          "accept": "auto",
          "their_role": "sender",
          "their_label": "Proven",
          "service_endpoint": "https://example/agent",
          "domain": "example",
          "path": "agent",
          "workflow_status": "active",
          "state": "done",
          "description": "",
          "active_starting_at": "2025-06-26T21:49:44.196Z",
          "active_ending_at": null,
          "uses_allowed": null,
          "uses_total": 2,
          "created_at": "2025-06-26T21:49:44.252Z",
          "updated_at": "2025-06-26T22:29:00.649Z"
        }
      ],
      "count": 1
    }
    {
      "invitation_url": "https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl19",
      "invitation_id": 1,
      "contact_id": ""
    }
    {
      "success": true,
      "invitation_record": {
        "state": "deleted",
        "created_at": "2025-06-26T22:28:53.800275Z",
        "updated_at": "2025-06-26T22:28:53.800275Z",
        "trace": false,
        "oob_id": "d8311180-d94f-4480-8f28-dd9dd9257c0c",
        "invi_msg_id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
        "invitation": {
          "@type": "https://didcomm.org/out-of-band/1.1/invitation",
          "@id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
          "label": "Proven",
          "handshake_protocols": [
            "https://didcomm.org/didexchange/1.1"
          ],
          "services": [
            {
              "id": "#inline",
              "type": "did-communication",
              "recipientKeys": [
                "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3"
              ],
              "serviceEndpoint": "https://example/agent"
            }
          ]
        },
        "connection_id": "29821f73-9db4-45d5-aee9-bd5c8bc2213a",
        "role": "receiver",
        "multi_use": false
      }
    }
    {
      "invitation_id": 1,
      "oob_id": "ef62b35f-ebd1-4760-89cd-1b33e6506f22",
      "contact_id": null,
      "connection_id": "853dbc66-4daa-45a8-8a6b-3cb81639c108",
      "my_did": "",
      "alias": "Documentation-Example",
      "invitation_key": "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3",
      "invitation_mode": "multi",
      "invitation_url": "https://example/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICI5MGRhNGU1YS0yNzQxLTRlZmUtYWY2ZC0yMTVkMTZhODQyOGEiLCAibGFiZWwiOiAiUHJvdmVuIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWtwYXpVNEVCTVpKU1VDN3VkOHFLMVRhNkwxTGtqMXhUQ1E3OVJMcVZUTHdRMyN6Nk1rcGF6VTRFQk1aSlNVQzd1ZDhxSzFUYTZMMUxrajF4VENRNzlSTHFWVEx3UTMiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL2J1Y2tldHM0bGlmZS5zaGFyZS56cm9rLmlvL2FnZW50In1dfQ",
      "invitation_msg_id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
      "invitation": {
        "@type": "https://didcomm.org/out-of-band/1.1/invitation",
        "@id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
        "label": "Proven",
        "handshake_protocols": [
          "https://didcomm.org/didexchange/1.1"
        ],
        "services": [
          {
            "id": "#inline",
            "type": "did-communication",
            "recipientKeys": [
              "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3"
            ],
            "serviceEndpoint": "https://example/agent"
          }
        ]
      },
      "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
      "accept": "auto",
      "their_role": "sender",
      "their_label": "Proven",
      "service_endpoint": "https://example/agent",
      "domain": "example",
      "path": "agent",
      "workflow_status": "active",
      "state": "done",
      "description": "This is an updated invitation.",
      "active_starting_at": "2023-01-01T00:00:00.000Z",
      "active_ending_at": "2023-12-31T23:59:59.000Z",
      "uses_allowed": 500,
      "uses_total": 2,
      "created_at": "2025-06-26T21:49:44.252Z",
      "updated_at": "2025-06-26T22:42:13.411Z"
    }
    GET /api/v1/invitations HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    POST /api/v1/invitations HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 422
    
    {
      "contact_id": "",
      "alias": "API Invitation",
      "invitation_type": "OOB",
      "handshake_protocol": "https://didcomm.org/didexchange/1.1",
      "invitation_mode": "once",
      "accept": "auto",
      "public": false,
      "invitation_role": "Holder",
      "invitation_label": "OOB",
      "invitation_status": "active",
      "invitation_description": "Invitation created through API",
      "purpose": "",
      "invitation_active_starting_at": null,
      "invitation_active_ending_at": null,
      "uses_allowed": 1
    }
    POST /api/v1/invitations/accept HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 62
    
    {
      "invitation_url": "https://example.com/invitation?oob=abc123"
    }
    GET /api/v1/invitations/{invitation_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "invitation_id": 1,
      "oob_id": "ef62b35f-ebd1-4760-89cd-1b33e6506f22",
      "contact_id": null,
      "connection_id": "853dbc66-4daa-45a8-8a6b-3cb81639c108",
      "my_did": "",
      "alias": "Documentation-Example",
      "invitation_key": "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3",
      "invitation_mode": "multi",
      "invitation_url": "https://example/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICI5MGRhNGU1YS0yNzQxLTRlZmUtYWY2ZC0yMTVkMTZhODQyOGEiLCAibGFiZWwiOiAiUHJvdmVuIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWtwYXpVNEVCTVpKU1VDN3VkOHFLMVRhNkwxTGtqMXhUQ1E3OVJMcVZUTHdRMyN6Nk1rcGF6VTRFQk1aSlNVQzd1ZDhxSzFUYTZMMUxrajF4VENRNzlSTHFWVEx3UTMiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL2J1Y2tldHM0bGlmZS5zaGFyZS56cm9rLmlvL2FnZW50In1dfQ",
      "invitation_msg_id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
      "invitation": {
        "@type": "https://didcomm.org/out-of-band/1.1/invitation",
        "@id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
        "label": "Proven",
        "handshake_protocols": [
          "https://didcomm.org/didexchange/1.1"
        ],
        "services": [
          {
            "id": "#inline",
            "type": "did-communication",
            "recipientKeys": [
              "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3"
            ],
            "serviceEndpoint": "https://example/agent"
          }
        ]
      },
      "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
      "accept": "auto",
      "their_role": "sender",
      "their_label": "Proven",
      "service_endpoint": "https://example/agent",
      "domain": "example",
      "path": "agent",
      "workflow_status": "active",
      "state": "done",
      "description": "",
      "active_starting_at": "2025-06-26T21:49:44.196Z",
      "active_ending_at": null,
      "uses_allowed": null,
      "uses_total": 2,
      "created_at": "2025-06-26T21:49:44.252Z",
      "updated_at": "2025-06-26T22:29:00.649Z"
    }
    PUT /api/v1/invitations/{invitation_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 213
    
    {
      "workflow_status": "active",
      "description": "This is an updated invitation.",
      "purpose": "verification-demo-2025",
      "active_starting_at": "2023-01-01T00:00:00Z",
      "active_ending_at": "2030-12-31T23:59:59Z",
      "uses_allowed": 1
    }
    DELETE /api/v1/invitations/{invitation_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "success": "Invitation was deleted successfully!"
    }
    GET /api/v1/invitations/purpose/{purpose} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "invitation_id": 1,
      "oob_id": "ef62b35f-ebd1-4760-89cd-1b33e6506f22",
      "contact_id": null,
      "connection_id": "853dbc66-4daa-45a8-8a6b-3cb81639c108",
      "my_did": "",
      "alias": "Documentation-Example",
      "invitation_key": "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3",
      "invitation_mode": "multi",
      "invitation_url": "https://example/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICI5MGRhNGU1YS0yNzQxLTRlZmUtYWY2ZC0yMTVkMTZhODQyOGEiLCAibGFiZWwiOiAiUHJvdmVuIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWtwYXpVNEVCTVpKU1VDN3VkOHFLMVRhNkwxTGtqMXhUQ1E3OVJMcVZUTHdRMyN6Nk1rcGF6VTRFQk1aSlNVQzd1ZDhxSzFUYTZMMUxrajF4VENRNzlSTHFWVEx3UTMiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL2J1Y2tldHM0bGlmZS5zaGFyZS56cm9rLmlvL2FnZW50In1dfQ",
      "invitation_msg_id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
      "invitation": {
        "@type": "https://didcomm.org/out-of-band/1.1/invitation",
        "@id": "90da4e5a-2741-4efe-af6d-215d16a8428a",
        "label": "Proven",
        "handshake_protocols": [
          "https://didcomm.org/didexchange/1.1"
        ],
        "services": [
          {
            "id": "#inline",
            "type": "did-communication",
            "recipientKeys": [
              "did:key:z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3#z6MkpazU4EBMZJSUC7ud8qK1Ta6L1Lkj1xTCQ79RLqVTLwQ3"
            ],
            "serviceEndpoint": "https://example/agent"
          }
        ]
      },
      "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
      "accept": "auto",
      "their_role": "sender",
      "their_label": "Proven",
      "service_endpoint": "https://example/agent",
      "domain": "example",
      "path": "agent",
      "workflow_status": "active",
      "state": "done",
      "description": "",
      "purpose": "demo-1",
      "active_starting_at": "2025-06-26T21:49:44.196Z",
      "active_ending_at": null,
      "uses_allowed": null,
      "uses_total": 2,
      "created_at": "2025-06-26T21:49:44.252Z",
      "updated_at": "2025-06-26T22:29:00.649Z"
    }
    POST /api/v1/create-did HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "did": {
        "did": "95LAyQitNh5kVaayCFC9S2",
        "verkey": "5QFrR2F9H84nF1T6bBiiahWCiDWrxTnHNtF78u7HPCY4",
        "posture": "wallet_only",
        "key_type": "ed25519",
        "method": "sov",
        "metadata": {}
      }
    }
    POST /api/v1/set-public-did?DID=text HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "did": "Efgh86CGr29yoQKXHQraHD",
      "verkey": "8T3KFeLkGk34nDQC1bLwYo2JLXDE6x8qz4z4TrVkaHoU",
      "posture": "posted",
      "key_type": "ed25519",
      "method": "sov",
      "metadata": {
        "posted": true,
        "endpoint": "https://example/agent"
      }
    }
    POST /api/v1/did/indy HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "did": "did:indy:indicio:test:JKdq87RF5kEsfv7b8BAdqs"
    }
    {
      "params": {
        "sort": [
          [
            [
              "updated_at",
              "DESC"
            ]
          ]
        ],
        "pageSize": "1",
        "currentPage": 1,
        "pageCount": 1,
        "itemCount": 1,
        "stateFilter": null,
        "contactIdFilter": null
      },
      "rows": [
        {
          "connection_id": "bd8d1663-38ac-46c8-9314-7d26bf731c88",
          "state": "active",
          "my_did": "did:peer:4zQmaa3MtBR8sPBAzZqVmwYqpjCzm4vAEh7FPMutFq71uHNN:zX4i2p2FcjJFFGYQy3UXZd5LCnUP9t7NenynBWQnmt13wxpMsSkaqGk8rFFk63RFhrCGwgYXpb4UJukfdmWyxcKJwEMSJt2akPvrAfZ3YQ2iAQ5GUgoLsADHbcZBNpPXS2JXH7zNFeq7s1gtSiVfs1otPiSX5PxKkT7czheF9TwszcVGTvAfAGocN2UHKNF2qi77YDsmmkarjDWngKqrzfW7dumgzXyawj7Ne9eRXsAVjCm2QoqU3M5mbTysFziW5GEJwJvAHHjq9nBTgwf3SzTLqGvL86yCnmxMb4zFtKzfi369b9hzVXRiKAoPeeqtvGGQVcSESWQumdfKKgLWFhCuEJowoDpw15WFVmkgiSFsAx14CX4fuq2tUVMmmcpDgH5A6J5qWQYiqPjTNTsm7Cu7jUWDEmvS93G1LcmtM8fno5wGH2Yw5A3qtFywgXs8KeBptpzgLYo37yLe6xxh1g1Z2pn2FGrVWm6AZxgwwyDSDFQGpgbEy2ZP5jmunh3eUgrJPex9aLGUSBrtHyq5g2aN424J3Vg5zbDQ9woAmzaZ97mg3rGWkvcShpiW1gHBXVsvwHXt161xsEq6VL4VhApyy9LCjJHzr25zgDyv8MgzJ",
          "alias": "API Invitation",
          "request_id": "c9babf88-e26d-47e7-b1f8-34645e3385b1",
          "invitation_key": "G9nZtxjCA8FqrUmtyRegi5LrXpxYrsEKoyfBi4kbH5fx",
          "invitation_msg_id": "ce6b9040-09ff-4eab-80c0-c6cb934596ca",
          "invitation_mode": "once",
          "invitation_url": "https://example.com/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJjZTZiOTA0MC0wOWZmLTRlYWItODBjMC1jNmNiOTM0NTk2Y2EiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vCmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWt1YzNjVkN5ZFZma0p4eWNiZXpjWFpBdHJNUUVRR2tVZ1Z2YTdZTGljQ0pUTCN6Nk1rdWMzY1ZDeWRWZmtKeHljYmV6Y1haQXRyTVFFUUdrVWdWemE3WUxpY0NKVEwiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL3NpbW9uZGV2Mi56cm9rLmRldi5pbmRpY2lvdGVjaC5pby9hZ2VudCJ9XX0",
          "invitation": {
            "@type": "https://didcomm.org/out-of-band/1.1/invitation",
            "@id": "ce6b9040-09ff-4eab-80c0-c6cb934596ca",
            "label": "OOB",
            "handshake_protocols": [
              "https://didcomm.org/didexchange/1.1"
            ],
            "services": [
              {
                "id": "#inline",
                "type": "did-communication",
                "recipientKeys": [
                  "did:key:z6Mkuc3cVCydVfkJxycbezcXZAtrMQEQGkUgVza7YLicCJTL#z6Mkuc3cVCydVfkJxycbezcXZAtrMQEQGkUgVza7YLicCJTL"
                ],
                "serviceEndpoint": "https://example.com/agent"
              }
            ]
          },
          "accept": "auto",
          "initiator": null,
          "their_role": "invitee",
          "their_did": "did:peer:1zQmVbupaSwiuhgBVGERqxhGqfy5pQGDd73bLQLrtiat7ygR",
          "their_public_did": null,
          "their_label": "Sim Ios",
          "routing_state": null,
          "inbound_connection_id": null,
          "error_msg": null,
          "contact_id": "4fbbe345-f38c-45b1-8d9b-c33e64ee0518",
          "transaction_role": null,
          "discovered_features": [
            {
              "pid": "https://didcomm.org/coordinate-mediation/1.0",
              "roles": [
                "RECIPIENT",
                "MEDIATOR"
              ]
            },
            {
              "pid": "https://didcomm.org/didexchange/1.1",
              "roles": [
                "requester",
                "responder"
              ]
            },
            {
              "pid": "https://didcomm.org/did-rotate/1.0",
              "roles": [
                "rotating_party",
                "observing_party"
              ]
            },
            {
              "pid": "https://didcomm.org/revocation_notification/1.0",
              "roles": [
                "holder"
              ]
            },
            {
              "pid": "https://didcomm.org/revocation_notification/2.0",
              "roles": [
                "holder"
              ]
            },
            {
              "pid": "https://didcomm.org/issue-credential/2.0",
              "roles": [
                "holder",
                "issuer"
              ]
            },
            {
              "pid": "https://didcomm.org/discover-features/1.0",
              "roles": [
                "requester",
                "responder"
              ]
            },
            {
              "pid": "https://didcomm.org/discover-features/2.0",
              "roles": [
                "requester",
                "responder"
              ]
            },
            {
              "pid": "https://didcomm.org/present-proof/2.0",
              "roles": [
                "prover",
                "verifier"
              ]
            },
            {
              "pid": "https://didcomm.org/messagepickup/1.0",
              "roles": [
                "message_holder",
                "recipient",
                "batch_sender",
                "batch_recipient"
              ]
            },
            {
              "pid": "https://didcomm.org/messagepickup/2.0",
              "roles": [
                "mediator",
                "recipient"
              ]
            },
            {
              "pid": "https://didcomm.org/basicmessage/1.0",
              "roles": [
                "sender",
                "receiver"
              ]
            },
            {
              "pid": "https://didcomm.org/out-of-band/1.1",
              "roles": [
                "sender",
                "receiver"
              ]
            }
          ],
          "wallet_id": "70b6a0d2-628a-4de6-af96-144100f74878",
          "created_at": "2025-07-08T20:51:18.856Z",
          "updated_at": "2025-07-08T21:00:21.741Z"
        }
      ],
      "count": 1
    }
    GET /api/v1/connections HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    GET /api/v1/connections/{connection_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "connection_id": "bd8d1663-38ac-46c8-9314-7d26bf731c88",
      "state": "active",
      "my_did": "did:peer:4zQmaa3MtBR8sPBAzZqVmwYqpjCzm4vAEh7FPMutFq71uHNN:zX4i2p2FcjJFFGYQy3UXZd5LCnUP9t7NenynBWQnmt13wxpMsSkaqGk8rFFk63RFhrCGwgYXpb4UJukfdmWyxcKJwEMSJt2akPvrAfZ3YQ2iAQ5GUgoLsADHbcZBNpPXS2JXH7zNFeq7s1gtSiVfs1otPiSX5PxKkT7czheF9TwszcVGTvAfAGocN2UHKNF2qi77YDsmmkarjDWngKqrzfW7dumgzXyawj7Ne9eRXsAVjCm2QoqU3M5mbTysFziW5GEJwJvAHHjq9nBTgwf3SzTLqGvL86yCnmxMb4zFtKzfi369b9hzVXRiKAoPeeqtvGGQVcSESWQumdfKKgLWFhCuEJowoDpw15WFVmkgiSFsAx14CX4fuq2tUVMmmcpDgH5A6J5qWQYiqPjTNTsm7Cu7jUWDEmvS93G1LcmtM8fno5wGH2Yw5A3qtFywgXs8KeBptpzgLYo37yLe6xxh1g1Z2pn2FGrVWm6AZxgwwyDSDFQGpgbEy2ZP5jmunh3eUgrJPex9aLGUSBrtHyq5g2aN424J3Vg5zbDQ9woAmzaZ97mg3rGWkvcShpiW1gHBXVsvwHXt161xsEq6VL4VhApyy9LCjJHzr25zgDyv8MgzJ",
      "alias": "API Invitation",
      "request_id": "c9babf88-e26d-47e7-b1f8-34645e3385b1",
      "invitation_key": "G9nZtxjCA8FqrUmtyRegi5LrXpxYrsEKoyfBi4kbH5fx",
      "invitation_msg_id": "ce6b9040-09ff-4eab-80c0-c6cb934596ca",
      "invitation_mode": "once",
      "invitation_url": "https://example.com/agent?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJjZTZiOTA0MC0wOWZmLTRlYWItODBjMC1jNmNiOTM0NTk2Y2EiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vCmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFt7ImlkIjogIiNpbmxpbmUiLCAidHlwZSI6ICJkaWQtY29tbXVuaWNhdGlvbiIsICJyZWNpcGllbnRLZXlzIjogWyJkaWQ6a2V5Ono2TWt1YzNjVkN5ZFZma0p4eWNiZXpjWFpBdHJNUUVRR2tVZ1Z2YTdZTGljQ0pUTCN6Nk1rdWMzY1ZDeWRWZmtKeHljYmV6Y1haQXRyTVFFUUdrVWdWemE3WUxpY0NKVEwiXSwgInNlcnZpY2VFbmRwb2ludCI6ICJodHRwczovL3NpbW9uZGV2Mi56cm9rLmRldi5pbmRpY2lvdGVjaC5pby9hZ2VudCJ9XX0",
      "invitation": {
        "@type": "https://didcomm.org/out-of-band/1.1/invitation",
        "@id": "ce6b9040-09ff-4eab-80c0-c6cb934596ca",
        "label": "OOB",
        "handshake_protocols": [
          "https://didcomm.org/didexchange/1.1"
        ],
        "services": [
          {
            "id": "#inline",
            "type": "did-communication",
            "recipientKeys": [
              "did:key:z6Mkuc3cVCydVfkJxycbezcXZAtrMQEQGkUgVza7YLicCJTL#z6Mkuc3cVCydVfkJxycbezcXZAtrMQEQGkUgVza7YLicCJTL"
            ],
            "serviceEndpoint": "https://example.com/agent"
          }
        ],
        "accept": "auto",
        "initiator": null,
        "their_role": "invitee",
        "their_did": "did:peer:1zQmVbupaSwiuhgBVGERqxhGqfy5pQGDd73bLQLrtiat7ygR",
        "their_public_did": null,
        "their_label": "Sim Ios",
        "routing_state": null,
        "inbound_connection_id": null,
        "error_msg": null,
        "contact_id": "4fbbe345-f38c-45b1-8d9b-c33e64ee0518",
        "transaction_role": null,
        "discovered_features": [
          {
            "pid": "https://didcomm.org/coordinate-mediation/1.0",
            "roles": [
              "RECIPIENT",
              "MEDIATOR"
            ]
          },
          {
            "pid": "https://didcomm.org/didexchange/1.1",
            "roles": [
              "requester",
              "responder"
            ]
          },
          {
            "pid": "https://didcomm.org/did-rotate/1.0",
            "roles": [
              "rotating_party",
              "observing_party"
            ]
          },
          {
            "pid": "https://didcomm.org/revocation_notification/1.0",
            "roles": [
              "holder"
            ]
          },
          {
            "pid": "https://didcomm.org/revocation_notification/2.0",
            "roles": [
              "holder"
            ]
          },
          {
            "pid": "https://didcomm.org/issue-credential/2.0",
            "roles": [
              "holder",
              "issuer"
            ]
          },
          {
            "pid": "https://didcomm.org/discover-features/1.0",
            "roles": [
              "requester",
              "responder"
            ]
          },
          {
            "pid": "https://didcomm.org/discover-features/2.0",
            "roles": [
              "requester",
              "responder"
            ]
          },
          {
            "pid": "https://didcomm.org/present-proof/2.0",
            "roles": [
              "prover",
              "verifier"
            ]
          },
          {
            "pid": "https://didcomm.org/messagepickup/1.0",
            "roles": [
              "message_holder",
              "recipient",
              "batch_sender",
              "batch_recipient"
            ]
          },
          {
            "pid": "https://didcomm.org/messagepickup/2.0",
            "roles": [
              "mediator",
              "recipient"
            ]
          },
          {
            "pid": "https://didcomm.org/basicmessage/1.0",
            "roles": [
              "sender",
              "receiver"
            ]
          },
          {
            "pid": "https://didcomm.org/out-of-band/1.1",
            "roles": [
              "sender",
              "receiver"
            ]
          }
        ],
        "wallet_id": "70b6a0d2-628a-4de6-af96-144100f74878",
        "created_at": "2025-07-08T20:51:18.856Z",
        "updated_at": "2025-07-08T21:00:21.741Z"
      }
    }
    {
      "success": "Message was sent!"
    }
    GET /api/v1/messages HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    [
      {
        "id": 1,
        "message_id": "f51902a4-b771-4c1c-8f28-05396c19d3d5",
        "contact_id": "8dba10d6-00d5-4f3a-ac8f-834211c9cbb9",
        "invitation_id": null,
        "message": "Hello Proven",
        "state": "new",
        "sent_time": "2025-06-26T21:53:46.397Z",
        "locale": "en",
        "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
        "created_at": "2025-06-26T21:53:47.282Z",
        "updated_at": "2025-06-26T21:53:47.282Z"
      },
      {
        "id": 2,
        "message_id": "",
        "contact_id": "8dba10d6-00d5-4f3a-ac8f-834211c9cbb9",
        "invitation_id": 1,
        "message": "Hello User",
        "state": "sent",
        "sent_time": "2025-06-26T21:54:49.309Z",
        "locale": "",
        "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
        "created_at": "2025-06-26T21:54:49.311Z",
        "updated_at": "2025-06-26T21:54:49.848Z"
      }
    ]
    POST /api/v1/messages HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 65
    
    {
      "invitation_id": 1,
      "contact_id": "",
      "message": "your message here"
    }
    GET /api/v1/messages/{id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    {
      "id": 1,
      "message_id": "f51902a4-b771-4c1c-8f28-05396c19d3d5",
      "contact_id": "8dba10d6-00d5-4f3a-ac8f-834211c9cbb9",
      "invitation_id": null,
      "message": "Hello Proven",
      "state": "new",
      "sent_time": "2025-06-26T21:53:46.397Z",
      "locale": "en",
      "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
      "created_at": "2025-06-26T21:53:47.282Z",
      "updated_at": "2025-06-26T21:53:47.282Z"
    }
    {
      "request_id": 1,
      "connection_id": "1c50d6e1-5a43-48d8-837e-be3cbc815469",
      "contact_id": "",
      "invitation_id": 1,
      "credential": {
        "name": "New Awesome JSON-LD Credential",
        "type": [
          "OpenBadgeCredential"
        ],
        "issuer": {
          "id": "did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8",
          "url": "https://www.awesome-issuer-url.com",
          "name": "Awesome Issuer Name",
          "type": [
            "Profile"
          ],
          "email": "issuer-contact@example.org",
          "image": {
            "id": "https://www.awesome-issuer-url.com/images/issuer-logo.png",
            "type": "Image",
            "caption": "Awesome Issuer Logo"
          },
          "description": "An awesome Issuer who Issues awesome credentials."
        },
        "@context": [
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://www.w3.org/ns/credentials/status/v1"
        ],
        "validFrom": "2024-11-29T11:34:20Z",
        "validUntil": "2030-11-29T11:34:20Z",
        "awardedDate": "2024-11-29T21:07:11Z",
        "description": "Awesome Credential Description",
        "issuanceDate": "2024-11-29T21:07:11Z",
        "expirationDate": "2030-11-29T11:34:20Z",
        "credentialSubject": {
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "https://example.org/achievements/degree",
            "name": "Your name",
            "type": [
              "Achievement"
            ],
            "image": {
              "id": "https://example.org/achievements/image.png",
              "type": "Image"
            },
            "criteria": {
              "type": "Criteria",
              "narrative": "Your narrative"
            },
            "description": "Your description"
          }
        },
        "rule": "string",
        "wallet_id": "19fa3524-2859-43e2-ac48-2136c9d8a199",
        "meta_data": null,
        "state": "offer-sent",
        "complete": false,
        "result": false,
        "result_string": "Pending",
        "credential_exchange_id": [
          "885b1487-479a-4071-8585-12580b1b0db1"
        ],
        "error": "",
        "proof_type": "Ed25519Signature2020",
        "created_at": "2025-07-09T19:28:02.633Z",
        "updated_at": "2025-07-09T19:28:04.774Z",
        "credential_status": {
          "id": "https://example.com/jsonld-status-list/tenants/19fa3524-2859-43e2-ac48-2136c9d8a199/w3c/status/0#81407",
          "type": "BitstringStatusListEntry",
          "statusPurpose": "revocation",
          "statusListIndex": 81407,
          "statusListCredential": "https://example.com/jsonld-status-list/tenants/19fa3524-2859-43e2-ac48-2136c9d8a199/w3c/status/0"
        }
      }
    }
    {
      "params": {
        "sort": [
          [
            "created_at",
            "DESC"
          ]
        ],
        "pageSize": 20,
        "currentPage": 1,
        "pageCount": 1,
        "itemCount": 1,
        "stateFilter": null,
        "contactIdFilter": null
      },
      "rows": [
        {
          "credential_exchange_id": "02189932-52ac-4f9d-bf84-1fcfb7c67fa1",
          "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
          "credential_id": null,
          "revocation_id": null,
          "connection_id": "0ecc0b3c-4d15-4660-b8da-15d0feeded59",
          "state": "offer-sent",
          "thread_id": "73d4b64f-f570-4970-9603-3381ed9cd440",
          "parent_thread_id": null,
          "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
          "credential_definition_id": "Efgh86CGr29yoQKXHQraHD:3:CL:151:default",
          "revoc_reg_id": null,
          "revoked": null,
          "created_at": "2025-06-26T22:01:05.543Z",
          "updated_at": "2025-06-26T22:01:05.543Z",
          "attributes": null
        }
      ],
      "count": 1
    }
    {
      "request_id": 1,
      "connection_id": "bd8d1663-38ac-46c8-9314-7d26bf731c88",
      "contact_id": "",
      "invitation_id": 1,
      "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
      "attributes": [
        {
          "name": "local_part",
          "value": "timmy"
        },
        {
          "name": "domain",
          "value": "example.com"
        },
        {
          "name": "address",
          "value": "timmy@example.com"
        },
        {
          "name": "verified_at",
          "value": "1670296277"
        }
      ],
      "wallet_id": "70b6a0d2-628a-4de6-af96-144100f74878",
      "rule": "no rule",
      "meta_data": null,
      "state": "offer-sent",
      "complete": false,
      "result": false,
      "result_string": "Pending",
      "credential_exchange_id": [
        "4e49277d-aa3f-4647-9bff-91d9dca8b0c8"
      ],
      "error": "",
      "created_at": "2025-07-08T21:14:59.117Z",
      "updated_at": "2025-07-08T21:15:03.835Z"
    }
    {
      "message": "Revocation request processed successfully."
    }
    POST /api/v1/credentials/json-ld HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 1251
    
    {
      "invitation_id": 1,
      "contact_id": "",
      "revocation_def_id": "",
      "credential": {
        "@context": [
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://www.w3.org/ns/credentials/status/v1"
        ],
        "issuanceDate": "2024-11-29T21:07:11Z",
        "validFrom": "2024-11-29T11:34:20Z",
        "awardedDate": "2024-11-29T21:07:11Z",
        "expirationDate": "2030-11-29T11:34:20Z",
        "validUntil": "2030-11-29T11:34:20Z",
        "type": [
          "OpenBadgeCredential"
        ],
        "description": "Awesome Credential Description",
        "name": "New Awesome JSON-LD Credential",
        "issuer": {
          "id": "did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8",
          "type": [
            "Profile"
          ],
          "name": "Awesome Issuer Name",
          "description": "An awesome Issuer who Issues awesome credentials.",
          "url": "https://www.awesome-issuer-url.com",
          "email": "issuer-contact@example.org",
          "image": {
            "id": "https://www.awesome-issuer-url.com/images/issuer-logo.png",
            "type": "Image",
            "caption": "Awesome Issuer Logo"
          }
        },
        "credentialSubject": {
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "https://example.org/achievements/degree",
            "name": "Your name",
            "description": "Your description",
            "criteria": {
              "type": "Criteria",
              "narrative": "Your narrative"
            },
            "image": {
              "id": "https://example.org/achievements/image.png",
              "type": "Image"
            },
            "type": [
              "Achievement"
            ]
          }
        }
      },
      "proofType": "Ed25519Signature2020",
      "rule": "string"
    }
    GET /api/v1/credentials/json-ld/{request_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    GET /api/v1/credentials HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    POST /api/v1/credentials HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 285
    
    {
      "invitation_id": 1,
      "contact_id": "",
      "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
      "attributes": [
        {
          "name": "local_part",
          "value": "timmy"
        },
        {
          "name": "domain",
          "value": "example.com"
        },
        {
          "name": "address",
          "value": "timmy@example.com"
        },
        {
          "name": "verified_at",
          "value": "1670296277"
        }
      ],
      "rule": "no rule"
    }
    GET /api/v1/credentials/{credential_exchange_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    POST /api/v1/credentials/{credential_exchange_id}/pii HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    GET /api/v1/credential-records/{request_id} HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Accept: */*
    
    POST /api/v1/credentials/anoncreds/revoke HTTP/1.1
    Host: proven-4-2-test.proven.indicio.tech
    x-api-key: YOUR_API_KEY
    Content-Type: application/json
    Accept: */*
    Content-Length: 99
    
    {
      "connection_id": "example-connection_id",
      "credential_exchange_id": "example-credential_exchange_id"
    }
    {
      "request_id": 1,
      "connection_id": "1c50d6e1-5a43-48d8-837e-be3cbc815469",
      "contact_id": "",
      "invitation_id": 1,
      "credential": {
        "name": "New Awesome JSON-LD Credential",
        "type": [
          "OpenBadgeCredential"
        ],
        "issuer": {
          "id": "did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8",
          "url": "https://www.awesome-issuer-url.com",
          "name": "Awesome Issuer Name",
          "type": [
            "Profile"
          ],
          "email": "issuer-contact@example.org",
          "image": {
            "id": "https://www.awesome-issuer-url.com/images/issuer-logo.png",
            "type": "Image",
            "caption": "Awesome Issuer Logo"
          },
          "description": "An awesome Issuer who Issues awesome credentials."
        },
        "@context": [
          "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
          "https://www.w3.org/ns/credentials/status/v1"
        ],
        "validFrom": "2024-11-29T11:34:20Z",
        "validUntil": "2030-11-29T11:34:20Z",
        "awardedDate": "2024-11-29T21:07:11Z",
        "description": "Awesome Credential Description",
        "issuanceDate": "2024-11-29T21:07:11Z",
        "expirationDate": "2030-11-29T11:34:20Z",
        "credentialSubject": {
          "type": [
            "AchievementSubject"
          ],
          "achievement": {
            "id": "https://example.org/achievements/degree",
            "name": "Your name",
            "type": [
              "Achievement"
            ],
            "image": {
              "id": "https://example.org/achievements/image.png",
              "type": "Image"
            },
            "criteria": {
              "type": "Criteria",
              "narrative": "Your narrative"
            },
            "description": "Your description"
          }
        }
      },
      "rule": "string",
      "wallet_id": "19fa3524-2859-43e2-ac48-2136c9d8a199",
      "meta_data": null,
      "state": "offer-sent",
      "complete": false,
      "result": false,
      "result_string": "Pending",
      "credential_exchange_id": [
        "885b1487-479a-4071-8585-12580b1b0db1"
      ],
      "error": "",
      "proof_type": "Ed25519Signature2020",
      "created_at": "2025-07-09T19:28:02.633Z",
      "updated_at": "2025-07-09T19:28:04.774Z",
      "credential_status": {
        "id": "https://example.com/jsonld-status-list/tenants/19fa3524-2859-43e2-ac48-2136c9d8a199/w3c/status/0#81407",
        "type": "BitstringStatusListEntry",
        "statusPurpose": "revocation",
        "statusListIndex": 81407,
        "statusListCredential": "https://example.com/jsonld-status-list/tenants/19fa3524-2859-43e2-ac48-2136c9d8a199/w3c/status/0"
      }
    }
    {
      "credential_exchange_id": "02189932-52ac-4f9d-bf84-1fcfb7c67fa1",
      "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
      "credential_id": null,
      "revocation_id": null,
      "connection_id": "0ecc0b3c-4d15-4660-b8da-15d0feeded59",
      "state": "offer-sent",
      "thread_id": "73d4b64f-f570-4970-9603-3381ed9cd440",
      "parent_thread_id": null,
      "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
      "credential_definition_id": "Efgh86CGr29yoQKXHQraHD:3:CL:151:default",
      "revoc_reg_id": null,
      "revoked": null,
      "created_at": "2025-06-26T22:01:05.543Z",
      "updated_at": "2025-06-26T22:01:05.543Z",
      "attributes": null
    }
    {
      "message": "Credential PII removed"
    }
    {
      "record": {
        "request_id": 1,
        "connection_id": "0ecc0b3c-4d15-4660-b8da-15d0feeded59",
        "contact_id": "8dba10d6-00d5-4f3a-ac8f-834211c9cbb9",
        "invitation_id": 1,
        "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0",
        "attributes": [
          {
            "name": "local_part",
            "value": "timmy"
          },
          {
            "name": "domain",
            "value": "example.com"
          },
          {
            "name": "address",
            "value": "timmy@example.com"
          },
          {
            "name": "verified_at",
            "value": "1670296277"
          }
        ],
        "wallet_id": "6b4ae41c-9c8a-49fd-9efa-fa0436d40b5c",
        "rule": "no rule",
        "meta_data": null,
        "state": "offer-sent",
        "complete": false,
        "result": false,
        "result_string": "Pending",
        "credential_exchange_id": [
          "02189932-52ac-4f9d-bf84-1fcfb7c67fa1"
        ],
        "error": "",
        "created_at": "2025-06-26T22:01:02.677Z",
        "updated_at": "2025-06-26T22:01:05.594Z"
      }
    }

    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.

    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.

    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.

    To log in, navigate to . 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.

    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.

    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.

    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

    By following these steps, the new user group and its associated users will be created and associated with the specified wallet.

    In addition to an administrative UI, Proven offers an API for the programmatic execution of agent operations. Its OpenAPI specification can be found at 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.

    To use API keys, you must set the following environment variable:

    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.

    1. Click the “Authorize” button at the top right of the page.

    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 .

    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.

    3. Enter the wallet_id for the wallet to which the API key will belong.

    4. Click the “Create” button.

    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

    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.

    • Internal: Accessible using the Base API Key

      • Wallet creation

      • API Key creation and revocation

    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.

    Response Body Information:

    This endpoint fetches all Basic Message records.

    Request Body Information:

    No request body

    The response body is an array of records. The following information is the data of each record:

    This endpoint fetches a Basic Message record by its ID.

    Request Body Information:

    No request body

    This endpoint fetches all connections, and includes parameters for pagination purposes.

    No request body

    The response body has three sections:

    • Params: The pagination and sorting parameters

      • "sort": “DESC”

      • "pageSize": "10"

    This endpoint fetches a connection record by its connection_id.

    Request Body Information:

    No request body

    This endpoint saves a JSON-LD context file.

    Credentials

    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.

    This endpoint fetches a credential (JSON-LD) Issuance request record by its request_id.

    Request Body Information:

    No request body

    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.

    The response body is an array of records. The following information is the data of each record:

    This endpoint fetches a credential Issuance record by its request_id.

    Request Body Information:

    No request body

    This endpoint fetches all Credential records.

    Request Body Information:

    No request body

    The response body is an array of records. The following information is the data of each record:

    This endpoint fetches a Credential record by its credential_definition_id.

    Request Body Information:

    No Request body

    This endpoint creates a new decentralized identifier (DID).

    Request Body Information:

    No request body

    This endpoint sets a public decentralized identifier (DID).

    Request URL Parameters Information:

    Request Body Information:

    No request body

    Sample URLs:

    This endpoint verifies multiple email addresses using the SMTP configurations.

    This endpoint creates a new invitation of type OOB or CV1.

    Invitation with connection reuse:

    Invitation without connection reuse:

    Invitation with multi-use:

    This endpoint accepts an invitation of type CV1 or OOB.

    This endpoint fetches all invitations, and includes parameters for pagination purposes.

    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.

    Response Body Information:

    The Response Body has three sections:

    • Params: The pagination and sorting parameters:

      • "sort": “DESC”

      • pageSize": "10"

    This endpoint fetches a single invitation record by its invitation_id.

    Request Body Information:

    No Request Body

    This endpoint updates an existing invitation record by using its invitation_id.

    Request Body Information:

    The following fields can be selectively provided:

    This endpoint deletes an invitation record by providing its invitation_id.

    This endpoint fetches all presentation records.

    Request Body Information:

    No Request Body

    The response body is an array of records. The following information is the data of each record:

    This endpoint fetches a presentation record by its presentation_exchange_id.

    This endpoint fetches the Transaction Author Agreement (TAA) from the ledger configured in the Proven environment (.env) file.

    Request Body Information:

    No Request Body

    This endpoint accepts the Transaction Author Agreement (TAA) using the provided TAA data.

    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.

    The response body is an array of records. The following information is the data of each record:

    This endpoint allows you to retrieve an AnonCred verification request record by its ID.

    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.

    The response body is an array of records. The following information is the data of each record:

    This endpoint fetches a JSON-LD verification request record by using its verification_id.

    The response body is an array of records. The following information is the data of each record:

  • Click on the new group in the list of groups

  • Click on the “Attributes” tab

  • Click on “Add attributes”

  • Enter "proven_group_id" as the key and the wallet name as the Value

  • Click the “Save” button

  • 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

  • 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.

  • The API key will be displayed in the table. Copy the API key and store it securely.

  • HMAC the String: The API HMACs the string with a secret.

  • Store HMACed Value: The API stores the HMACed value in the database.

  • Send API Request: The user sends an API request with the API key in the headers.

  • HMAC the Received Key: The API HMACs the received API key with the same secret.

  • Check User Role: The API checks the user's role.

  • Look Up HMACed Value: The API looks up the HMACed value in the database.

  • Return Metadata: The database returns metadata if the key is valid and not revoked.

  • Process Request: The API processes the request and returns the response to the user if the role is valid.

  • Return Error: The API returns an error if the role is invalid.

  • 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

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    message

    string

    Hello world!

    Message content

    string

    2ff097c3-5b65-4c25-a836-e2e3edb8195e

    Unique identifier for exchange message

    contact_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    message

    string

    Hello World!

    Message content

    state

    string

    sent

    Current state of Basic Message request record

    sent_time

    string

    2024-12-30T13:17:40.107Z

    Date/time the message was sent to connection (ACA-Py field)

    locale

    string

    null

    Not used at present

    wallet_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Identifier of the wallet used to process the request. The wallet used is determined by the x-api-key.

    created_at

    string

    2024-12-30T13:17:40.108Z

    Date of creation for the Basic Message record

    updated_at

    string

    2024-12-30T13:17:40.108Z

    Date the Basic Message record was last updated

    string

    2ff097c3-5b65-4c25-a836-e2e3edb8195e

    Unique identifier for exchange message

    contact_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    message

    string

    Hello World!

    Message content

    state

    string

    sent

    Current state of Basic Message request record

    sent_time

    string

    2024-12-30T13:17:40.107Z

    Date/time the message was sent to connection (ACA-Py field)

    locale

    string

    null

    Not used at present

    wallet_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Identifier of the wallet used to process the request. The wallet used is determined by the x-api-key.

    created_at

    string

    2024-12-30T13:17:40.108Z

    Date of creation for the Basic Message record

    updated_at

    string

    2024-12-30T13:17:40.108Z

    Date the Basic Message record was last updated

    text

    ASC

    Optional, ASC or DESC

    page-size

    int

    10

    Optional, how many items should be returned in a page

    current-page

    int

    2

    Optional, the current page to retrieve

    item-count

    int

    10

    Optional, the total number of items

    "currentPage": 1

  • "pageCount": 1

  • "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

  • string

    active

    Invitation, init, request, response, active, error, deleted

    my_did

    string

    TP1jLwshBSSUArz154iLg2

    Decentralized identifier

    alias

    string

    Proven

    String for how this connection could be labeled in the receiving agent

    request_id

    string

    5f2b5d38-b3ad-43af-9b50-98df250e600e

    ACA-Py field

    invitation_key

    string

    7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7

    ACA-Py field tied to the invitation used to establish the connection

    invitation_msg_id

    string

    afbc12b7-28fa-4936-bf11-748148a98ffc

    ACA-Py field tied to the invitation

    invitation_mode

    string

    once

    once, multi

    invitation_url

    string

    https://<domain>?oob=<base64 invitation>

    Invitation_url used to establish the connection

    invitation

    object

    {...}

    Raw invitation data used by the receiving agent to connect

    accept

    string

    auto

    ACA-Py field/parameter

    initiator

    string

    null

    ACA-Py field

    their_role

    string

    inviter

    inviter, invitee

    their_did

    string

    PhTeNogZWHmjCqiyPr8cds

    Connecting wallet’s DID (sender or receiver, depending on who generated the invitation)

    their_public_did

    string

    null

    Connecting wallet’s Public DID (sender or receiver, depending on who generated the invitation)

    their_label

    string

    Holdr+

    Label used by this wallet to identify this connection

    routing_state

    string

    null

    ACA-Py field

    inbound_connection_id

    string

    null

    ACA-Py field

    error_msg

    string

    null

    Error message provided by ACA-Py during exchange

    contact_id

    string

    0846c509-4a6e-4022-bebd-e2e9ff63b747

    Identifier of the Contact tied to this connection

    discover_features

    array

    [...]

    List of available features for this connection

    wallet_id

    string

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Unique identifier of the wallet tied to this connection

    created_at

    timestamp

    2024-12-30T10:37:30.734Z

    Date/time of creation for the connection record

    updated_at

    timestamp

    2024-12-30T10:37:31.686Z

    Date/time the connection record was last updated

    string

    active

    Invitation, init, request, response, active, error, deleted

    my_did

    string

    TP1jLwshBSSUArz154iLg2

    Decentralized identifier

    alias

    string

    Proven

    String for how this connection could be labeled in the receiving agent

    request_id

    string

    5f2b5d38-b3ad-43af-9b50-98df250e600e

    ACA-Py field

    invitation_key

    string

    7FQqpV7jepn5pf5jmkYwuXgQXrN9QeDSUw2tE8vaWAf7

    ACA-Py field tied to the invitation used to establish the connection

    invitation_msg_id

    string

    afbc12b7-28fa-4936-bf11-748148a98ffc

    ACA-Py field tied to the invitation

    invitation_mode

    string

    once

    once, multi

    invitation_url

    string

    https://<domain>?oob=<base64 invitation>

    Invitation_url used to establish the connection

    invitation

    object

    {...}

    Raw invitation data used by the receiving agent to connect

    accept

    string

    auto

    ACA-Py field/parameter

    initiator

    string

    null

    ACA-Py field

    their_role

    string

    inviter

    inviter, invitee

    their_did

    string

    PhTeNogZWHmjCqiyPr8cds

    Connecting wallet’s DID (sender or receiver, depending on who generated the invitation)

    their_public_did

    string

    null

    Connecting wallet’s Public DID (sender or receiver, depending on who generated the invitation)

    their_label

    string

    Holdr+

    Label used by this wallet to identify this connection

    routing_state

    string

    null

    ACA-Py field

    inbound_connection_id

    string

    null

    ACA-Py field

    error_msg

    string

    null

    Error message provided by ACA-Py during exchange

    contact_id

    string

    0846c509-4a6e-4022-bebd-e2e9ff63b747

    Identifier of the Contact this connection is tied to

    discover_features

    array

    [...]

    List of available features for this connection

    wallet_id

    string

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Unique identifier of the wallet this connection is tied to

    created_at

    timestamp

    2024-12-30T10:37:30.734Z

    Date/time of creation for the connection record

    updated_at

    timestamp

    2024-12-30T10:37:31.686Z

    Date/time the connection record was last updated

    object

    {...}

    Object containing JSON-LD contexts

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    context

    array

    https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json

    Contexts of the credential

    label

    string

    Drivers License

    Credentials label

    issuer_name

    string

    Proven

    Name of the issuer

    type

    array

    [...]

    Types of the credential

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    The “name” accepts string data type only. The “value” accepts string, object, and array data types

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    no rule

    Rules enforced for this request (future feature)

    did

    string

    did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt

    Decentralized identifier used to sign the credential

    proofType

    string

    Ed25519Signature2020

    Type of proof to generate to sign the credential. Defaults to Ed25519Signature2018

    string

    f7699aa9-beec-4e0c-868d-eb3766ad2f64

    Connection used for this request, determined by invitation_id and contact_id

    contact_id

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    context

    array

    https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json

    Contexts of the credential

    label

    string

    Drivers License

    Credentials label

    type

    array

    [...]

    Types of the credential

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    The “name” accepts string data type only. The “value” accepts string, object, and array data types

    wallet_id

    string

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Identifier that ties this record to an existing wallet

    issuer_name

    string

    Proven

    Name of the issuer

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    “no rule”

    Rules enforced for this request (future feature)

    meta_data

    object

    {...}

    Metadata for this credential

    state

    string

    offer_sent

    ACA-Py field - null means no issuance has been triggered yet, likely due to no available connection

    complete

    boolean

    false

    This field does not indicate successful issuance, only that the request record has finished its process.

    result

    boolean

    false

    Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record.

    result_string

    string

    “Pending”

    Custom string for helping to define the state of the request

    credential_exchange_id

    array

    [...]

    Contains unique IDs for each issued credential

    error

    string

    “Public DID not set.”

    Error message caught while processing request record

    issuer_did

    string

    did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt

    Issuer’s decentralized identifier

    proof_type

    string

    Ed25519Signature2020

    Type of proof to generate to sign the credential - defaults to Ed25519Signature2018.

    created_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was created

    updated_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was last updated

    string

    f7699aa9-beec-4e0c-868d-eb3766ad2f64

    Connection used for this request, determined by invitation_id and contact_id

    contact_id

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    context

    array

    https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json

    Contexts of the credential

    label

    string

    Drivers License

    Credentials label

    type

    array

    [...]

    Types of the credential

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    The “name” accepts string data type only. The “value” accepts string, object, and array data types.

    wallet_id

    string

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Identifier that ties this record to an existing wallet

    issuer_name

    string

    Proven

    Name of the issuer

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    “no rule”

    Rules enforced for this request (future feature)

    meta_data

    object

    {...}

    Metadata for this credential

    state

    string

    offer_sent

    Null means no issuance has been triggered yet, likely due to no available connection

    complete

    boolean

    false

    This field does not indicate successful issuance, only that the request record has finished its process.

    result

    boolean

    false

    Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record.

    result_string

    string

    “Pending”

    Custom string for helping to define the state of the request

    credential_exchange_id

    array

    [...]

    Contains unique IDs for each issued credential.

    error

    string

    “Public DID not set.”

    Error message caught while processing request record

    issuer_did

    string

    did:indy:indicio:demo:JcBoFbZQo9yd3SWUc6Lvbt

    Issuer’s decentralized identifier

    proof_type

    string

    Ed25519Signature2020

    Type of proof to generate to sign the credential. Defaults to Ed25519Signature2018

    created_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was created

    updated_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was last updated

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    schema_id

    text

    KT4LtL7HEMePqQSyKVof7g:2:Email:1.0

    Credentials schema

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    List of schema attribute names and their values

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    no rule

    Rules enforced for this request (future feature)

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Ties record to the connection used to complete the request

    contact_id

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    schema_id

    text

    KT4LtL7HEMePqQSyKVof7g:2:Email:1.0

    Credentials schema

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    List of schema attribute names and their values

    wallet_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Identifier that ties this record to an existing wallet

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    no rule

    Rules enforced for this request (future feature)

    meta_data

    object

    null

    Metadata for this credential

    state

    string

    offer_sent

    Null means no issuance has been triggered yet, likely due to no available connection.

    complete

    boolean

    false

    This field does not indicate successful issuance, only that the request record has finished its process.

    result

    boolean

    false

    Indicates successful issuance result. This field should be used alongside “complete” to determine if you have a successful request record.

    result_string

    string

    “Pending”

    Custom string for helping to define the state of the request

    credential_exchange_id

    array

    [...]

    Contains unique IDs for each issued credential.

    error

    string

    “Public DID not set.”

    Error message caught while processing request record

    created_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was created

    updated_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was last updated

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Identifier that ties this record to a connection

    contact_id

    text

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    schema_id

    text

    KT4LtL7HEMePqQSyKVof7g:2:Email:1.0

    Credentials schema

    attributes

    array

    [{“name”: “first_name”, “value”: “Alice”}]

    List of schema attribute names and their values

    wallet_id

    string

    199e022b-bb4c-4ae4-99fe-395b50ad4b66

    Identifier that ties this record to an existing wallet

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record

    rule

    string

    no rule

    Rules enforced for this request (future feature)

    meta_data

    object

    null

    Metadata for this credential

    state

    string

    offer_sent

    Null means no issuance has been triggered yet, likely due to no available connection.

    complete

    boolean

    false

    This field does not indicate successful issuance, only that the request record has finished its process.

    result

    boolean

    false

    Indicates successful issuance result. This field should be used alongside “complete” to determine successful request record

    result_string

    string

    “Pending”

    Custom string for helping to define the state of the request

    credential_exchange_id

    array

    [...]

    Contains unique IDs for each issued credential

    error

    string

    “Public DID not set.”

    Error message caught while processing request record

    created_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was created

    updated_at

    timestamp

    2024-12-31T09:34:31.635Z

    Date/time this record was last updated

    string

    f20823bb-9079-4026-b9dc-a7f410af5141

    Identifier that ties this record to an existing wallet

    credential_id

    string

    null

    Unique ID for held credentials

    revocation_id

    string

    null

    Identifier used for credential revocation

    connection_id

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Unique identifier that ties a connection to this record

    state

    string

    done

    Current state of the credential

    thread_id

    string

    a6ab28e8-1576-4174-8083-e52752327057

    Thread identifier for the credential

    parent_thread_id

    string

    null

    Parent thread identifier for the credential

    schema_id

    string

    KT4LtL7HEMePqQSyKVof7g:2:Email:1.0

    Credentials schema

    credential_definition_id

    string

    JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default

    Credential definition generated via the schema_id

    revoc_reg_id

    string

    null

    Field used for credential revocation

    revoked

    boolean

    null

    Field used for credential revocation

    attributes

    object

    {...}

    Credentials attributes and their values

    created_at

    timestamp

    2025-01-03T12:57:37.827Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-03T12:57:37.827Z

    Date/time this record was last updated

    string

    f20823bb-9079-4026-b9dc-a7f410af5141

    Identifier that ties this record to an existing wallet

    credential_id

    string

    null

    Unique ID for held credentials

    revocation_id

    string

    null

    Identifier used for credential revocation

    connection_id

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Unique identifier that ties a connection to this record

    state

    string

    done

    Current state of the credential

    thread_id

    string

    a6ab28e8-1576-4174-8083-e52752327057

    Thread identifier for the credential

    parent_thread_id

    string

    null

    Parent thread identifier for the credential

    schema_id

    string

    KT4LtL7HEMePqQSyKVof7g:2:Email:1.0

    Credentials schema

    credential_definition_id

    string

    JCuYYsqY1X2QcYpVrSkQwL:3:CL:151:default

    Credential definition generated via the schema_id

    revoc_reg_id

    string

    null

    Field used for credential revocation

    revoked

    boolean

    null

    Field used for credential revocation

    attributes

    object

    {...}

    Credential’s attributes and their values

    created_at

    timestamp

    2025-01-03T12:57:37.827Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-03T12:57:37.827Z

    Date/time this record was last updated

    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

    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

    text

    blank

    Optional contact string used for calls that require a known contact

    handshake_protocol

    text

    https://didcomm.org/didexchange/1.1

    Protocol used to generate the invitation

    alias

    text

    Acme Issuer

    String for how this connection could be labeled in the receiving agent. Technically optional, but probably a bad idea to leave empty

    invitation_mode

    text

    Once

    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.

    accept

    text

    Auto

    Auto, Manual

    public

    boolean

    false

    true or false

    invitation_role

    text

    blank

    Optional string describing this connection's role (such as "holder")

    invitation_label

    text

    Create Account

    Optional string for naming this invitation in the sending agent

    invitation_status

    text

    blank

    Optional; Active, Inactive, Deleted; this is not an ACA-Py field, but allows our controller to utilize invitations intelligently. Defaults to Active

    invitation_description

    text

    blank

    Optional string describing the purpose of this invitation

    invitation_active_starting_at

    timestamp

    blank

    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.

    invitation_active_ending_at

    timestamp

    blank

    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.

    uses_allowed

    int

    blank

    Optional number of uses the controller will allow this invitation. Caution, the controller can be bypassed and does not strictly control ACA-Py.

    int

    37

    ID to keep track of this particular invitation

    contact_id

    text

    “contact123”

    Contact ID specified during the creation of this invitation

    object

    {...}

    Invitation record data object

    text

    ASC

    Optional, ASC or DESC

    page-size

    int

    10

    Optional, how many items should be returned in a page

    current-page

    int

    2

    Optional, the current page to retrieve

    item-count

    int

    10

    Optional, the total number of items

    "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

  • text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify an Out of Band (OOB) connection

    contact_id

    text

    contact123

    Contact ID string

    connection_id

    text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify a CV1 connection

    my_did

    text

    did:sov:<did>

    Public DID (empty if invitation is not public)

    alias

    text

    Acme Issuer

    String for how this connection should be "named"

    invitation_key

    text

    did:key:<...>

    Invitation Key managed by agent

    invitation_mode

    text

    Once

    Multi, Once (or "Static," but for developers use only)

    invitation_url

    text

    https://<domain>?oob=<base64 invitation>

    Invitation URL (CV1 or OOB)

    invitation_msg_id

    text

    afbc12b7-28fa-4936-bf11-748148a98ffc

    Unique Identifier for invitation exchange

    invitation

    obj

    {...}

    Invitation data object

    wallet_id

    text

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Identifier for the wallet the invitation belongs to

    accept

    text

    auto

    auto, manual

    their_role

    text

    sender

    Role of agent that generated the invitation

    their_label

    text

    Primary Wallet

    Label of agent/wallet that generated the invitation

    service_endpoint

    text

    https://hard-tiger-38.tun2.indiciotech.io

    Endpoint used for serving the Invitation URL

    domain

    text

    hard-tiger-38.tun2.indiciotech.io

    Domain parsed from service_endpoint

    path

    text

    /path

    Path parsed from service_endpoint

    workflow_status

    text

    active

    active, inactive (managed by controller)

    state

    text

    deleted

    State of the invitation (managed by ACA-Py agent)

    description

    text

    General purpose issuer

    Optional string describing the purpose of this invitation

    active_starting_at

    timestamp

    2024-12-30T10:36:52.443Z

    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.

    active_ending_at

    timestamp

    null

    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.

    uses_allowed

    int

    100

    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.

    uses_total

    int

    43

    Number of times this invitation has been used

    created_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date of creation for the invitation record (controller level)

    updated_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date the invitation record was last updated (controller level)

    text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify an Out of Band (OOB) connection

    contact_id

    text

    contact123

    Contact ID string

    connection_id

    text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify a CV1 connection

    my_did

    text

    did:sov:<did>

    Public DID (empty if invitation is not public)

    alias

    text

    Acme Issuer

    String for how this connection should be "named"

    invitation_key

    text

    did:key:<...>

    Invitation Key managed by agent

    invitation_mode

    text

    Once

    Multi, Once (or "Static," but for developers use only)

    invitation_url

    text

    https://<domain>?oob=<base64 invitation>

    Invitation URL (CV1 or OOB)

    invitation_msg_id

    text

    afbc12b7-28fa-4936-bf11-748148a98ffc

    Unique Identifier for invitation exchange

    invitation

    obj

    {...}

    Invitation data object

    wallet_id

    text

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Identifier for the wallet the invitation belongs to

    accept

    text

    auto

    auto, manual

    their_role

    text

    sender

    Role of the agent that generated the invitation

    their_label

    text

    Primary Wallet

    Label of the agent/wallet that generated the invitation

    service_endpoint

    text

    https://hard-tiger-38.tun2.indiciotech.io

    Endpoint used for serving the Invitation URL

    domain

    text

    hard-tiger-38.tun2.indiciotech.io

    Domain parsed from service_endpoint

    path

    text

    /path

    Path parsed from service_endpoint

    workflow_status

    text

    active

    active, inactive (managed by controller)

    state

    text

    deleted

    State of the invitation (managed by ACA-Py agent)

    description

    text

    General purpose issuer

    Optional string describing the purpose of this invitation

    active_starting_at

    timestamp

    2024-12-30T10:36:52.443Z

    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.

    active_ending_at

    timestamp

    null

    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.

    uses_allowed

    int

    100

    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.

    uses_total

    int

    43

    Number of times this invitation has been used

    created_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date of creation for the invitation record (controller level)

    updated_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date the invitation record was last updated (controller level)

    string

    Updating invitation description via API

    Invitation’s general use description

    active_starting_at

    timestamp

    2024-12-30T10:36:52.466Z

    Controls invitation’s workflow_status (active or inactive) (controller level only)

    active_ending_at

    string

    2025-12-30T10:36:52.466Z

    Controls invitation’s workflow_status (active or inactive) (controller level only)

    uses_allowed

    integer

    20

    Limits the usage of multi-use invitations. Single-use invitations default to 1 and cannot be updated (controller level only).

    text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify an Out of Band (OOB) connection

    contact_id

    text

    contact123

    Contact ID string

    connection_id

    text

    db6da148-33ee-4108-96d9-f39bee835981

    ID used to identify a CV1 connection

    my_did

    text

    did:sov:<did>

    Public DID (empty if invitation is not public)

    alias

    text

    Acme Issuer

    String for how this connection should be "named" or referred to, especially in the UI

    invitation_key

    text

    did:key:<...>

    Invitation Key managed by agent

    invitation_mode

    text

    Once

    Multi, Once (or "Static," but for developers use only)

    invitation_url

    text

    https://<domain>?oob=<base64 invitation>

    Invitation URL (CV1 or OOB)

    invitation_msg_id

    text

    afbc12b7-28fa-4936-bf11-748148a98ffc

    Unique Identifier for invitation exchange

    invitation

    obj

    {...}

    Invitation data object

    wallet_id

    text

    eea19d5b-cbfc-44a0-9406-a9bddcbe3994

    Identifier for the wallet the invitation belongs to

    accept

    text

    auto

    auto, manual

    their_role

    text

    sender

    Role of agent that generated the invitation

    their_label

    text

    Primary Wallet

    Label of agent/wallet that generated the invitation

    service_endpoint

    text

    https://hard-tiger-38.tun2.indiciotech.io

    Endpoint used for serving the Invitation URL

    domain

    text

    hard-tiger-38.tun2.indiciotech.io

    Domain parsed from service_endpoint

    path

    text

    /path

    Path parsed from service_endpoint

    workflow_status

    text

    active

    active, inactive (managed by controller)

    state

    text

    deleted

    State of the invitation (managed by ACA-Py agent)

    description

    text

    General purpose issuer

    Optional string describing the purpose of this invitation

    active_starting_at

    timestamp

    2024-12-30T10:36:52.443Z

    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.

    active_ending_at

    timestamp

    null

    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.

    uses_allowed

    int

    100

    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.

    uses_total

    int

    43

    Number of times this invitation has been used

    created_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date of creation for the invitation record (controller level)

    updated_at

    timestamp

    "2024-12-30T10:36:52.466Z"

    Date the invitation record was last updated (controller level)

    string

    f20823bb-9079-4026-b9dc-a7f410af5141

    Identifier that ties this record to an existing wallet

    trace

    boolean

    false

    Not used at present

    connection_id

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Unique identifier used for tying a connection to the presentation record

    role

    string

    verifier

    Role of the presentation

    verified

    boolean

    true

    Indicates a verified presentation

    presentation_created_at

    timestamp

    2025-01-06T10:16:26.561Z

    ACA-Py field

    presentation_updated_at

    timestamp

    2025-01-06T10:16:26.561Z

    ACA-Py field

    presentation_request_dict

    object

    {...}

    ACA-Py field

    initiator

    string

    self

    Initiator of the presentation

    presentation_request

    object

    {...}

    Request object of the presentation

    state

    string

    request-sent

    Current state of the presentation

    thread_id

    string

    85e6c895-be08-4c1d-be5d-91ccd902b62c

    Thread identifier for the presentation

    auto_present

    boolean

    false

    Parameter for automatically presenting the presentation

    presentation

    object

    null

    Main presentation data

    contact_label

    string

    Alice Smith

    Contact label for the presentation

    contact_id

    string

    contact123

    Identifier that ties the presentation to a contact

    created_at

    timestamp

    2025-01-06T10:16:26.647Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T10:16:26.647Z

    Date/time this record was last updated

    string

    f20823bb-9079-4026-b9dc-a7f410af5141

    Identifier that ties this record to an existing wallet

    trace

    boolean

    false

    Not used at present

    connection_id

    string

    cdcff763-5616-4a43-90ee-b0a38e0f6646

    Unique identifier used for tying a connection to the presentation record

    role

    string

    verifier

    Role of the presentation

    verified

    boolean

    true

    Indicates a verified presentation

    presentation_created_at

    timestamp

    2025-01-06T10:16:26.561Z

    ACA-Py field

    presentation_updated_at

    timestamp

    2025-01-06T10:16:26.561Z

    ACA-Py field

    presentation_request_dict

    object

    {...}

    ACA-Py field

    initiator

    string

    self

    Initiator of the presentation

    presentation_request

    object

    {...}

    Request object of the presentation

    state

    string

    request-sent

    Current state of the presentation

    thread_id

    string

    85e6c895-be08-4c1d-be5d-91ccd902b62c

    Thread identifier for the presentation

    auto_present

    boolean

    false

    Parameter for automatically presenting the presentation

    presentation

    object

    null

    Main presentation data

    contact_label

    string

    Alice Smith

    Contact label for the presentation

    contact_id

    string

    contact123

    Identifier that ties the presentation to a contact

    created_at

    timestamp

    2025-01-06T10:16:26.647Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T10:16:26.647Z

    Date/time this record was last updated

    object

    {...}

    Main TAA data

    taa_required

    boolean

    true

    Indicates a required TAA

    taa_accepted

    object

    {...}

    Includes data about the accepted TAA (mechanism, time)

    string

    “Indicio Transaction Author Agreement….”

    Transaction Author Agreement

    version

    string

    1.3

    Version of the Transaction Author Agreement

    object

    {...}

    Main TAA data

    taa_required

    boolean

    true

    Indicates a required TAA

    taa_accepted

    object

    {...}

    Includes data about the accepted TAA (mechanism, time)

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    schemas

    array

    [{...}, {...}]

    Contains schema IDs and their attributes

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record before responding

    rule

    string

    “no rule”

    Rules for this verification request

    string

    e2aed3c4-c0a1-4711-902e-f0a9eba618da

    Identifier that ties the used connection to the verification request record

    contact_id

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    schema_id

    string

    null

    Schema used for the verification request

    schema_attributes

    object

    {...}

    Contains the schema attributes and their restrictions, if any are provided

    wallet_id

    string

    407e6215-17c5-4c81-901e-d75d9cc1a75a

    Identifier that ties this record to an existing wallet

    timeout

    integer

    10

    Number of seconds the initial request waited for a completed request record

    rule

    string

    “no rule”

    Rules for the verification request

    meta_data

    object

    null

    Metadata for the verification request record

    state

    string

    done

    Current state of the verification

    complete

    boolean

    true

    This field does not indicate a verified presentation, only that the request record has finished its process.

    result

    boolean

    true

    Indicates a verified presentation. This field should be used alongside “complete” to determine a successful request record.

    result_string

    string

    Verified

    Custom string for helping to define the state of the request

    result_data

    array

    [...]

    Contains the verified attributes

    presentation_exchange_id

    array

    [...]

    Contains unique IDs for each proof request

    error

    string

    “Public DID not set.”

    Error message caught while processing the request record

    created_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was last updated

    string

    e2aed3c4-c0a1-4711-902e-f0a9eba618da

    Identifier that ties the used connection to the verification request record

    contact_id

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    schema_id

    string

    null

    Schema used for the verification request

    schema_attributes

    object

    {...}

    Contains the schema attributes and their restrictions, if any are provided

    wallet_id

    string

    407e6215-17c5-4c81-901e-d75d9cc1a75a

    Identifier that ties this record to an existing wallet

    timeout

    integer

    10

    Number of seconds the initial request waited for a completed request record

    rule

    string

    “no rule”

    Rules for the verification request

    meta_data

    object

    null

    Metadata for the verification request record

    state

    string

    done

    Current state of the verification

    complete

    boolean

    true

    This field does not indicate a verified presentation, only that the request record has finished its process.

    result

    boolean

    true

    Indicates a verified presentation. This field should be used alongside “complete” to determine a successful request record.

    result_string

    string

    Verified

    Custom string for helping to define the state of the request

    result_data

    array

    [...]

    Contains the verified attributes

    presentation_exchange_id

    array

    [...]

    Contains unique IDs for each proof request

    error

    string

    “Public DID not set.”

    Error message caught while processing the request record

    created_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was last updated

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    definitions

    array

    [{...}, {...}]

    Definitions for the verification request. Contains context, attributes, and label

    timeout

    integer

    10

    Number of seconds the initial request will wait for a completed record before responding

    rule

    string

    “no rule”

    Rules for the verification request

    string

    e2aed3c4-c0a1-4711-902e-f0a9eba618da

    Identifier that ties the used connection to the verification request record

    contact_id

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    context

    array

    [“...”, “...”]

    List of contexts used for this verification record

    attributes

    array

    [...]

    List of attributes to be verified

    wallet_id

    string

    407e6215-17c5-4c81-901e-d75d9cc1a75a

    Identifier that ties this record to an existing wallet

    label

    string

    Email

    Label for the verification request record

    timeout

    integer

    10

    Number of seconds the initial request waited for a completed request record

    rule

    string

    “no rule”

    Rules for the verification request

    meta_data

    object

    null

    Metadata for the verification request record

    state

    string

    done

    Current state of the verification request record

    complete

    boolean

    true

    This field does not indicate a verified request record, only that the request record has finished its process.

    result

    boolean

    true

    Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.

    result_string

    string

    Verified

    Custom string for helping to define the state of the request

    result_data

    array

    [...]

    Contains the verified attributes

    presentation_exchange_id

    array

    [...]

    Contains unique IDs for each proof request

    error

    string

    “Controller Error! ….”

    Error message caught while processing the request record

    created_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was last updated

    string

    e2aed3c4-c0a1-4711-902e-f0a9eba618da

    Identifier that ties the used connection to the verification request record

    contact_id

    string

    contact123

    Optional contact ID string used for processing the request record by known contact. Used with invitation_id, has first priority

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    context

    array

    [“...”, “...”]

    List of contexts used for the verification record

    attributes

    array

    [...]

    List of attributes to be verified

    wallet_id

    string

    407e6215-17c5-4c81-901e-d75d9cc1a75a

    Identifier that ties this record to an existing wallet

    label

    string

    Email

    Label for the verification request record

    timeout

    integer

    10

    Number of seconds the initial request waited for a completed request record

    rule

    string

    “no rule”

    Rules for the verification request

    meta_data

    object

    null

    Metadata for the verification request record

    state

    string

    done

    Current state of the verification request record

    complete

    boolean

    true

    This field does not indicate a verified request record, only that the request record has finished its process.

    result

    boolean

    true

    Indicates a verified request record. This field should be used alongside “complete” to determine a successful request record.

    result_string

    string

    Verified

    Custom string for helping to define the state of the request

    result_data

    array

    [...]

    Contains the verified attributes

    presentation_exchange_id

    array

    [...]

    Contains unique IDs for each proof request

    error

    string

    “Controller Error! ….”

    Error message caught while processing the request record

    created_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was created

    updated_at

    timestamp

    2025-01-06T11:51:10.169Z

    Date/time this record was last updated

    Variable

    Explanation

    PROVEN_API_KEY

    The base API key needed for management of wallets and API keys

    /api/v1/messages - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    Field name

    Expected type/values

    Examples

    Notes

    success

    string

    Message was sent!

    Success message

    { "success": "Message was sent!" }
    /api/v1/messages - GET

    Field name

    Expected type/values

    Examples

    Notes

    id

    integer

    123

    Primary identifier for record

    [
       {
           "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"
       }
    ]
    /api/v1/messages/<id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    id

    integer

    123

    Primary identifier for record

      {
          "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"
        }
    /api/v1/connections - GET

    Field name

    Expected type/values

    Examples

    Notes

    sort-field

    text

    contact_id

    Optional, any of the field names listed in the "Create invitation" POST body plus invitation_id

    https://your-domain-name.com/api/v1/connections?sort-field=contact_id&sort-direction=ASC&page-size=10&current-page=2

    Field name

    Expected type/values

    Examples

    Notes

    connection_id

    string

    d61b698f-2eb4-438d-bec0-a7f88bcb47f0

    Unique and primary identifier for the connection

    {
      "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
    }
    /api/v1/connections/<connection_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    connection_id

    string

    d61b698f-2eb4-438d-bec0-a7f88bcb47f0

    Unique and primary identifier for the connection

    {
          "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"
      }
    /api/v1/context - POST

    Field name

    Expected type/values

    Examples

    Notes

    context_file_id

    string

    test.json

    File name of the JSON-LD context file to save

     {
      "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"
            }
          }
        }
      }
    }

    Field name

    Expected type/values

    Examples

    Notes

    success

    string

    Context file was posted

    Success message

    { "success": "Context file was posted" }
    /api/v1/credentials/json-ld - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    Field name

    Expected type/values

    Examples

    Notes

    request_id

    integer

    1

    Records primary key

    [
      {
          "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"
      }
    ]
    /api/v1/credentials/json-ld/<request_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    request_id

    integer

    1

    Records primary key

    [
      {
          "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"
      }
    ]
    /api/v1/credentials - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    Field name

    Expected type/values

    Examples

    Notes

    request_id

    integer

    123

    Issuance request record primary key

    [
      {
        "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"
      }
    ]
    /api/v1/credential-records/<request_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    request_id

    integer

    123

    Issuance request record primary key

    {
        "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"
      }
    /api/v1/credentials - GET

    Field name

    Expected type/values

    Examples

    Notes

    credential_exchange_id

    string

    5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134

    Primary identifier for the credential record

    [
      {
        "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
      }
    ]
    /api/v1/credentials/<credential_definition_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    credential_exchange_id

    string

    5d00c38f-cc6a-4f0c-9dd2-3813c0dd8134

    Primary identifier for the credential record

    {
        "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
    }
    /api/v1/create-did - POST

    Field name

    Expected type/

    values

    Examples

    Notes

    did

    string

    AwUCmb3ahPhiYVaik3wD7

    Decentralized identifier

    {
      "did": "AwUCmb3ahPhiYVaik3wD7",
      "verkey": "6RCKgJhNz76u98RpzVYMrrXDEgPn3hZ5mvwyJnjvevP",
      "posture": "wallet_only",
      "key_type": "ed25519",
      "method": "sov",
      "metadata": {}
    }
    /api/v1/set-public-did - POST

    Field name

    Expected type/ values

    Examples

    Notes

    DID

    text

    XhvSpiDsLVmStHa19VC4hJ

    DID set as public

    https://your-domain-name.com/api/v1/set-public-did?DID=WSPiMexQfuVrR9wMQbg5F7

    Field name

    Expected type/ values

    Examples

    Notes

    did

    string

    XhvSpiDsLVmStHa19VC4hJ

    DID set as public

    {
      "did": "XhvSpiDsLVmStHa19VC4hJ",
      "verkey": "HjfSSD6DDPfAME5Th5NTESEoToJgVWqUo7u81euPGX7K",
      "posture": "posted",
      "key_type": "ed25519",
      "method": "sov",
      "metadata": {
        "posted": true
      }
    }
    /api/v1/emails/verify - POST

    Field name

    Expected type/values

    Examples

    Notes

    emails

    array

    [ {“email”: “alice@example.com”} ]

    List of emails to verify

    Field name

    Expected type/values

    Examples

    Notes

    success

    string

    “All emails sent successfully”

    Success message

    {
        "success": "All emails sent successfully!"
    }
    /api/v1/invitations - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_type

    text

    OOB

    CV1 or OOB (Connections v. 1 or Out of Band)

    { 
      "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
    }
    { 
      "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
    }
    { 
      "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
    }

    Field name

    Expected type/values

    Examples

    Notes

    invitation_url

    text

    https://proven.mediator.indiciotech.io?oob...

    Invitation URL (currently formatted for either connections v. 1 or OOB)

    {
      "invitation_url": "https://proven.mediator.indiciotech.io?c_i=...",
      "invitation_id": 37,
      "contact_id": "49"
    }
    /api/v1/invitations/accept - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_url

    text

    https://proven.mediator.indiciotech.io?oob...

    Properly encoded connections v. 1 or OOB invitation

    { 
      "invitation_url": "https://proven.mediator.indiciotech.io?c_i...",   
    }

    Field name

    Expected type/values

    Examples

    Notes

    success

    boolean

    true

    Signals successful invitation acceptance

    {
      "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
      }
    }
    /api/v1/invitations - GET

    Field name

    Expected type/values

    Examples

    Notes

    sort-field

    text

    contact_id

    Optional, any of the field names listed in the "Create invitation" POST body plus invitation_id

    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

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    int

    4325

    Integer used as the primary identifier for this record

    {
      "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
    /api/v1/invitations/<invitation_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    int

    4325

    Integer used as the primary identifier for this record

    {
      "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"
    }
    /api/v1/invitations/<invitation_id> - PUT

    Field name

    Expected type/values

    Examples

    Notes

    workflow_status

    string

    inactive

    Controls usage and availability of invitation (controller level only)

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    int

    4325

    Integer used as the primary identifier for this record

    {
      "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"
    }
    /api/v1/invitations/<invitation_id> - DELETE

    Field name

    Expected type/values

    Examples

    Notes

    success

    string

    “Invitation 2 was deleted successfully!”

    Success message

    {
      "success": "Invitation 2 was deleted successfully!"
    }
    /api/v1/presentations - GET

    Field name

    Expected type/values

    Examples

    Notes

    presentation_exchange_id

    string

    349c7662-6837-4274-b213-355dab5d92f2

    Primary identifier used for the presentation record

    [
      {
        "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"
      }
    ]
    /api/v1/presentations/<presentation_exchange_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    presentation_exchange_id

    string

    349c7662-6837-4274-b213-355dab5d92f2

    Primary identifier used for the presentation record

    {
        "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"
      }
    /api/v1/fetch-taa - POST

    Field name

    Expected type/values

    Examples

    Notes

    aml_record

    object

    {...}

    (Acceptance Mechanism List) Recognized by the network for use in the TAA

    {
      "aml_record": {
        "aml": {...},
        "amlContext": "...",
        "version": "1.0"
      },
      "taa_record": {
        "digest": "...",
        "ratification_ts": ...,
        "text": "...",
        "version": "1.3"
      },
      "taa_required": true,
      "taa_accepted": null
    }
    /api/v1/accept-taa - POST

    Field name

    Expected type/values

    Examples

    Notes

    mechanism

    string

    “on_file”

    Mechanism used for the TAA

    Field name

    Expected type/values

    Examples

    Notes

    aml_record

    object

    {...}

    (Acceptance Mechanism List) Recognized by the network for use in the TAA

    {
      "aml_record": {
        "aml": {...},
        "amlContext": "...",
        "version": "1.0"
      },
      "taa_record": {
        "digest": "...",
        "ratification_ts": ...,
        "text": "...",
        "version": "1.3"
      },
      "taa_required": true,
      "taa_accepted": {...}
    /api/v1/verifications - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    {
      "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"
    }

    Field name

    Expected type/values

    Examples

    Notes

    verification_id

    integer

    10

    Primary identifier for the verification request record

    [
      {
        "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"
      }
    ]
    /api/v1/verifications/<verification_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    verification_id

    integer

    10

    Primary identifier for the verification request record

    {
        "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"
    }
    /api/v1/verifications/json-ld - POST

    Field name

    Expected type/values

    Examples

    Notes

    invitation_id

    integer

    123

    Optional integer used to process the request record by a connection tied to the invitation_id. Used with contact_id, has second priority

    Field name

    Expected type/values

    Examples

    Notes

    verification_id

    integer

    10

    Primary identifier for the verification request record

    [
      {
        "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"
      }
    ]
    /api/v1/verifications/json-ld/<verification_id> - GET

    Field name

    Expected type/values

    Examples

    Notes

    verification_id

    integer

    10

    Primary identifier for the verification request record

    {
      "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"
    }

    Managing Wallets

    Login

    Create Wallets and API Keys

    Managing Users

    Adding Users to a Wallet

    Using API Key Endpoints

    Environment Variables

    API Key Creation Using the Swagger UI:

    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.

    API Key Flow Explanation:

    Distinction Between HTTP Endpoints:

    API Contents

    Proven DIDComm APIs

    Basic Messages

    Basic Message - Create Basic Message

    Request Body Information:

    Sample Response Body:

    Basic Message - Read All Basic Messages

    Response Body Information:

    Sample Response Body:

    Basic Message - Read Basic Message by ID

    Response Body Information:

    Sample Response Body:

    Connections

    Connections - Read All Connections

    Request URL Parameters Information:

    Sample URLs:

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Connections - Read Connection by ID

    Response Body Information:

    Sample Response Body:

    Context

    Context - Save JSON-LD Context File

    Request Body Information:

    Request Body Sample:

    Response Body Information:

    Sample Response Body:

    Credentials - Create Credential Issuance (JSON-LD)

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Credentials - Read Credential Issuance by ID (JSON-LD)

    Response Body Information:

    Sample Response Body:

    Credentials - Create Credential Issuance (AnonCred)

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Credentials - Read Credential Issuance by ID (AnonCred)

    Response Body Information:

    Sample Response Body:

    Credentials - Read All Credential Records

    Response Body Information:

    Sample Response Body:

    Credentials - Read Credential Record By ID

    Response Body Information:

    Sample Response Body:

    DIDs

    DIDs - Create New DID

    Response Body Information:

    Sample Response Body:

    DIDs - Set Public DID

    Response Body Information:

    Sample Response Body:

    Email

    Email - Verify Email Addresses

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Invitations

    Invitations - Create New Invitation

    Request Body Information:

    Sample Request Bodies:

    Response Body Information:

    Sample Response Body:

    Invitations - Accept Invitation

    Request Body Information

    Sample Request Body:

    Response Body Information:

    Sample Response Body:

    Invitations - Read All Invitations

    Sample URLs:

    Sample Response Body:

    Invitations - Read Invitation by ID

    Response Body Information:

    Sample Response Body:

    Invitations - Update Invitation Record

    Response Body Information:

    Sample Response Body:

    Invitations - Delete Invitation

    Response Body Information:

    Sample Response Body:

    Presentations

    Presentations - Read All Presentations

    Response Body Information:

    Sample Response Body:

    Presentations - Read Presentation by ID

    Response Body Information:

    Sample Response Body:

    TAA

    TAA - Fetch the TAA

    Response Body Information:

    Sample Response Body:

    TAA - Accept TAA

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Verifications

    Verifications - Create Verification Request (AnonCred)

    Request Body Information:

    Sample Request Bodies:

    Response Body Information:

    Sample Response Body:

    Verifications - Read Verification by ID

    Response Body Information:

    Sample Response Body:

    Verifications - Create Verification Request (JSON-LD)

    Request Body Information:

    Response Body Information:

    Sample Response Body:

    Verifications - Read Verifications By ID (JSON-LD)

    Response Body Information:

    Sample Response Body:

    http://your-domain-name.com/auth/login
    http://your-domain-name.com/api/doc
    http://your-domain-name.com/api/doc

    contact_id

    message_id

    message_id

    sort-direction

    state

    state

    file

    contact_id

    connection_id

    connection_id

    contact_id

    connection_id

    connection_id

    wallet_id

    wallet_id

    verkey

    verkey

    contact_id

    invitation_id

    invitation_record

    sort-direction

    oob_id

    oob_id

    description

    oob_id

    wallet_id

    wallet_id

    taa_record

    text

    taa_record

    contact_id

    connection_id

    connection_id

    contact_id

    connection_id

    connection_id

    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.

    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.

    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.

    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.

    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.

    • 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.

  • Benefits

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

    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.

    1. Navigate to the Google Cloud Console,

    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

    1. Add a DNS entry for your new mediator.

    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

    MEDIATOR_CONTROLLER_ADMIN_API_KEY=<your choice> You can generate strong tokens for production with OpenSSL: openssl rand 32 -hex MEDIATOR_AGENT_ADMIN_API_KEY=<your choice> You can generate strong tokens for production with OpenSSL: openssl rand 32 -hex MEDIATOR_ALIAS= Can be any string. (e.g. MyProdMediator1) LOG_LEVEL= Can be ERROR, WARNING, or INFO, depending on your preference. Note: INFO level produces the largest log file. SITE_ADDRESS= This is the complete mediator DNS Name you configured in a previous step. MEDIATOR_URL= This is the same as SITE_ADDRESS, except add https:// to the front of it. EMAIL_ADDRESS= The email you want log information sent to. MEDIATOR_AGENT_LABEL= This is what you want the mediator name to show up as on other agents.

    1. 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

    2. 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.

    3. To start the Mediator, run these commands

    1. 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

    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:

    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.

    CA_CERT= 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 POSTGRESQL_HOST= 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. POSTGRESQL_USER= 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. POSTGRESQL_PASSWORD= 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. POSTGRESQL_ADMIN_USER= 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. POSTGRESQL_ADMIN_PASSWORD= This is the password for the Administrator account on the remote database. Postgresql options should not be set if using a local database. MEDIATOR_WALLET_NAME= Use a descriptive name MEDIATOR_WALLET_KEY= Use a secure string, we recommend a randomly generated 32 character string

    Click CREATE INSTANCE on the top bar
  • From the left menu select Marketplace.

  • 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.

  • Change the Deployment name if desired.

  • Select and Record your Zone choice for later use.

  • 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

  • Under Boot Disk it is recommended to select a disk at least 10GB in size. (default)

  • Under Networking -> External IP set a static IP address (recommended), this can also be done later if desired.

  • Click DEPLOY.

  • 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 the environment by doing the following: sudo cp .env.sample .env

  • Edit the .env file to fit your environment:

    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

    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)

  • Click Create

  • 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.

  • 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”

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

    Configure DNS (see appendix A)

    Configure the VM

    Using your new mediator:

    Appendix A - DNS Setup Example

    APPENDIX B - More .env Configuration Options

    https://console.cloud.google.com/
        cd /opt/indicio/aries-mediator-service
        sudo docker-compose up

    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.