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...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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.
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.
Endpoints for sending and retrieving basic messages
Endpoints for managing contexts
Endpoints for email verification
Authenticate with base API key
Endpoints for managing Decentralized Identifiers (DIDs)
Endpoints for fetching governance files
Endpoints for creating and managing invitations
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.
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.
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.
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 , with the , or by .
After you create your public DID complete this form. Select “DemoNet” from the dropdown to get your DID written to the Network.
Digital identity for citizen services, reducing fraud.
Replace your passwords with credentials Unlike passwords, credentials cannot be lost, stolen, or copied, and don’t require your employees to remember them.
Access management Both physical and digital access management can be done through credentials for enhanced security — and unlike access cards, credentials cannot be lost, stolen, or copied.
Manage social and welfare programs By issuing each citizen a credential you can reduce fraud in aid / benefits applications.
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.
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.
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.
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.
Discover a range of educational resources—from technical papers to core concepts—that will help you learn, build, deploy, and scale with Indicio Proven.
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.
Remove your reliance on centralized databases for personal information and reduce liability and storage costs.
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:
Create a public DID (decentralized identifier). This can be done with the , with the , an app of your choice, or by .
Then, to get the DID written to the TestNet.
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.
Share data and identity with trusted connections.
Collect credentials to store locally and share by consent.
Secure, peer-to-peer messaging.
Please complete the form below and within 24 hours you will be provided a unique link to gain access to Indicio's Guided Tutorials.
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
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.
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.
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 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.
Endpoints for issuing and retrieving credentials
Endpoints for managing connections








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

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.
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
Share proof of employment with partner organizations, such as insurance companies, with the tap of a button.
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.
Intuitive interface built for accessibility and convenience.
Customizable branding and functionality (paid upgrades).
Indicio Holdr+ - our ready to download digital wallet (in Apple and Android app stores).
Proven Mobile SDK - a ready-to-use SDK to power your own wallet!
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.
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.
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.
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.
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.
Know that your personal information is secure because there is no centralized database of logins and passwords.
Simple, secure, and easy to use interface removes tedious multi-factor authentication.
Fight impersonation attacks with credentials that can only be presented by the person they are issued to.
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.
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.
Indicio Proven is the world’s most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0.
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
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 requirements for data minimization and privacy in eIDAS.
Indicio proven includes all of these trust establishment options!
Proven Trust Establishment
Details
did:sov
A DID method for interacting with ledgers similar to the Sovrin Network
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.
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.
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.
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.
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.
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.
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.
Easily store all your permits and licenses in one place and eliminate the hassle of tracking down physical documents and paperwork.
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.
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.
Indicio uses a variety of credential types, exchanges, and representations to provide the best solution to fit our customer's needs.
The technical specification or structure that defines how credential data is encoded, presented, and exchanged. Credential formats ensure that the data within a verifiable credential can be securely issued, shared, and verified across different systems. Key aspects of a credential format include how the data is digitally signed, the cryptographic techniques used, and how privacy-preserving features like selective disclosure or zero-knowledge proofs are implemented.
Indicio provides robust support for a variety of credential formats, enabling organizations to choose the format that best aligns with their use case and interoperability requirements including:
JSON-LD (Linked Data): A format that integrates with semantic web technologies, allowing credentials to include rich metadata and context for better interoperability.
SD-JWT (Selective Disclosure JWT): A JWT-based format with added support for selective disclosure, enabling granular control over what information is shared from a credential.
mDL: Supports proximity based sharing of driver license.
Open Badges 3.0: Supports educational achievements.
DTC for digital passports (ICAO DTC Type 1 compliant): A digital travel credential derived from the data inside a user's passport to be easily held and shared before traveling.
DTA for digital visas: Digital Travel Authorization that is easily digitized and shared before the traveler arrives and goes through customs or security.
DIF Presentation Exchange: a codified presentation definition format for verifiers to use to articulate proof requirements.
W3C Verifiable Credential standards compliant: A set of standards developed by the World Wide Web Consortium to enable the issuance, sharing, and verifiaction of digital credentials in a privacy respecting manner.
AnonCreds: A privacy-preserving format that supports privacy-preserving features such as selective disclosure, predicate proofs, and zero-knowledge proofs, allowing users to share only the necessary information from a credential without revealing the entire dataset. JSON Web Tokens (JWT): A widely-used format based on JSON that is compact and easy to process, suitable for web-based applications and lightweight implementations.
BBS+: A secure, multi-message digital signature protocol, supporting proving knowledge of a signature.
By offering this flexibility, Indicio empowers organizations to build decentralized identity solutions that are secure, private, and interoperable across diverse systems and industries.
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.
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.
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 Proven offers all the following software options!
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
Data is shareable across disparate systems without direct integration.
Add digital wallet functionality for verifiable credentials directly into your existing applications
Proven Mobile SDK: 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:
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.
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.
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.
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.
Indicio’s governance solution provides an unparalleled framework for managing decentralized ecosystems with two key components:
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.
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’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.
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.
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.
#DID Methods
The DID method specifies how DIDs and DID documents are created, resolved, updated, and deactivated. We recommend and use DID methods that allow for communication endpoints even if the use case doesn’t require them. Their presence will make innovation easier in the future. We also, generally, recommend and use DID methods that provide high durability through writing to a distributed ledger. Proven supports multiple DID methods, which promotes interoperability with multiple DID-based solutions.
did:sov
did:key
did:peer
did:web (resolution only)
DID resolution via Universal Resolver
did: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
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.
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.
Automated rules provide more guardrails and security for the user’s personal information.
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.
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.
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.
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.
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.
Fast, simple, and easy to use, these credentials can contain all the information needed to prove identification across your organization and partner organizations.
Indicio Proven is built to support an array of leading global specifications and open standards to ensure maximum interoperability.
1 Ed Tech Open Badges 3.0 Specification.
Internet Engineering Task Force SD-JWT and SD-JWT VC specifications.
LF Decentralized Trust Indy Working Group Node, Plenum, Cryptography.
International Civil Aviation Organization (ICAO) (DTC) standard.
LF Decentralized Trust .
LF Decentralized Trust.
.
LF Decentralized Trust .
Aries Cloud Agent Python agents (ACA-Py) Bifold Wallet (built on Credo - formerly Aries Framework Javascript).
(OID4VC) Communication protocol.
Decentralized Identity Foundation DIDComm.
Decentralized Identity Foundation Decentralized Ecosystem Governance.
Trust Over IP Foundation .
World wide Web Consortium, .
EU Digital Identity Wallet (EUDI). .
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.
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
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.
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.
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.
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.
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.
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.
A professionally managed network of distributed ledgers, such as the Indicio Network, used for anchoring credentials and public identifiers (DIDs).
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.
Improving the customer experience without sacrificing security or privacy
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
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.
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.
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.
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
Unlocking efficiency and savings across industries and sectors
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.
Verifiable credentials can hold all kinds of valuable information in a tamper-proof way, as any attempt to alter that information breaks the credential.
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.
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.”
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
Eliminate redundant paperwork and manual processes
Integrate digital identity wallet functionality into existing applications or download our existing wallet app today.
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.
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.
Indicio Proven includes all these features!
Unlocking efficiency and savings across industries and sectors
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.
Verifiable credentials can hold all kinds of valuable information in a tamper-proof way, as any attempt to alter that information breaks the credential.
Indicio is compliant with all of the following credential formats!
Quickly configure Single Sign-On (SSO) to use a verifiable credential for login
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.
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.
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.
Integrate into existing systems easily and enable a robust identity layer for Zero Trust architecture.














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.

Receive and renew documents with a significantly reduced wait time.


did:jwk




























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.

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.
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.
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.
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.
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.
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
Field boundaries
Financial and compliance data
Insurance
Land data
Livestock data
Soil 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.
“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.
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.
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.
Proven Expertise: Trusted by industry leaders, including SITA, IATA, and governments, for its secure, scalable verifiable credential solutions.
Account recovery is a critical process for financial institutions, yet it often causes frustration for customers and operational inefficiencies for banks. Traditional recovery methods rely heavily on outdated mechanisms such as knowledge-based authentication (KBA) and manual identity verification, which introduce challenges:
Compliance Strain: Regulatory requirements around data privacy and security intensify the need for robust and auditable solutions.
Customer Friction: Long wait times and multiple verification steps create frustration, reducing customer satisfaction and loyalty.
Security Risks: KBA and other traditional methods are vulnerable to fraud, phishing, and social engineering attacks.
Operational Costs: Manual verification processes demand significant resources and time, driving up costs for banks.
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.
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.
Sovrin Ledgers
CANdy
Lissi
Ethereum
(Non-Ledger) KERI
Indicio Network: Indicio’s public-permissioned ledgers are built on Hyperledger Indy to provide a versatile platform for designing, testing, demonstrating, launching, and supporting decentralized identity solutions. With nodes spanning five continents and a global consortium of over 20 members, our team brings unparalleled expertise in managing Indy networks.
Value:
Enterprise-grade: They are professionally-supported to deliver mission-critical deployments.
Energy efficient: Ledgers for identity do not require proof-of-work and are low energy in operation (a write to the ledger is equivalent to a web search in energy consumption) with guaranteed 99.97% uptime.
Network monitoring: Indicio has developed a range of network support tools to monitor network performance.
Easy to use: A transaction wizard simplifies writing transactions to the ledger.
Easy to run: Indicio NoDeTM (Node on Demand) is a cloud product that simplifies creating and setting up network nodes.
Private network opportunities: Indicio has the capacity to develop and run private networks for any organization.
Our Enterprise-grade distributed ledger network is based on Hyperledger Indy and is composed of four professionally-managed networks:
Indicio TestNet: A platform for proof-of-concept for development and testing, supported by Indicio’s engineering team.
Indicio DemoNet: A platform to showcase demonstrations.
Indicio MainNet: A platform to run enterprise-grade, mission-critical identity products and services with full, professional support.
Indicio TempNet Service: A network for destructively testing performance, scaling, and security to discover weaknesses.
DID:WEBVH 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.
Immutable Records: All changes to the DID Document are logged and cryptographically secured, preventing unauthorized alterations.
Enhanced Trust: By providing a verifiable history, DID:WEBVH mitigates reliance on central web servers and enhances the trustworthiness of DID:WEB implementations.
Interoperability: It retains compatibility with existing web technologies while adding layers of decentralized trust.
Scalability: Useful for organizations that need a practical, scalable DID method but require enhanced accountability and transparency.
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.
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.
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!


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

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
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!
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.
No direct integrations to share data or verify identity between different systems.
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.

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:
How the holder’s consent to share their data is obtained.
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 how to spot a fake ID. 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 until the end of 2020 to include permission for digital and mobile drivers licenses. But the federal government leaves the issuing of driver’s licenses to each state, meaning that the state governments also have to vote on implementation; as of August 2024, only 13 have passed legislation to start issuing mDLs.
If they are being issued by your state they are not currently a replacement for your license, but an additional way to represent it, meaning that you will likely still have a physical license somewhere. This could be another reason that many haven’t adopted them, they see it as an add-on that is unnecessary.
It's important to remember that this technology is still new. Many people might not understand or trust it yet, but as the world shifts to be more digital, it will be a big part of how we prove our identity moving forward.
If you are part of an organization looking into mDL technology, or a better way to prove your identity online, Indicio can help! Get in touch with our team of experts today.
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.
Proven Feature
Details
API for external integration
A set of rules and specifications that allow different software systems to interact and exchange data.
Proven Controller API
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.
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.
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!


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
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).
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.
Replaces weak passwords and weak second-factor authentication for better security.
No tracking by centralized third-party identity providers.
No worries if a federated identity provider goes dark.
Reduces the steps for authentication in a zero-trust architecture model.
Program with governance rules for least-privilege access.
More powerful than passkeys and don’t require enrollment.
Simpler, more secure user experience.
Get ahead of the portable digital identity transformation in the European Union (eIDAS, EUDI), the travel sector, and in mobile driver’s licenses.
Get all these features faster and cheaper than conventional identity access management solutions.
The issuer assembles all the necessary identity information to prove who a user is.
The information is stored inside a verifiable credential and issued to the end user’s mobile device.
Personally identifiable information is deleted from the issuer’s systems, removing liability and lessening risk of breach
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.
did:indy
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


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.


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


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.




Indicio Proven comes ready with everything you need to create, exchange, and verify digital credentials in a secure, privacy-preserving manner.
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.
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.
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 .
Swipe past the first two images and click Get Started on the third image as shown below.
Read and accept the Terms of Use and the Privacy Policy
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.
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.





















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.










































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.
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.
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.
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.
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.
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.
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.
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
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
Click Continue for both the Terms and the Privacy policies.
Enter First Name and Last name (first image below).
Choose a PIN (second image).
When you are done, you will see your empty wallet home screen (third image).
The next step is to log in to Proven.
Visit: https://your.url.com/admin
Username: admin
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.
In the Holdr+ wallet, click on the Connect button found in the bottom center of the screen.
Click Scan a code.
Scan the QR code.
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.
Click on the card to see the credential details.
Click Accept to add the credential to your wallet.
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.

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.
The Open Badges 3.0 specification, created by the global educational nonprofit, 1EdTech, solved these challenges by updating the specification to align with the W3C Verifiable Credential Data Model.
Now, a badge can be issued directly to a recipient’s digital wallet application on a mobile device. And, as a badge is digitally signed, it cannot be altered or tampered with once it has been created.
As 1EdTech , 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.”
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.
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.
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
LinkedIn posting



















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!
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.
Navigate to the Google Cloud Console,
Select or create the project that you want the Mediator instance to reside in.
In the Navigation Menu (top left), go to Compute Engine > VM Instances
Click CREATE INSTANCE on the top bar
Add a DNS entry for your new mediator.
SSH into the VM
From Compute Engine > VM instances > [instance name] click SSH towards the top of the screen
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.
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
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.
To start the Mediator, run these commands
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
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.
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."
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:
Go to GCP’s Cloud DNS section in Network services (Navigation Menu > Networking > Network Services > Cloud DNS)
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.
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
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.
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.
Webhooks provide real-time notifications about events on Proven agents. They are delivered as HTTP POST requests to a configured endpoint.

From the left menu select Marketplace.
In the Search Marketplace field type Proven and hit enter.
Select Indicio Proven ACA-Py Mediator.
Click GET STARTED then AGREE (as needed)
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:
Set Series to E2
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:
Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
Click on the instance name to bring up details about the Mediator instance you just deployed
Click “edit”
Scroll down to Networking and under Network interfaces -> Firewalls check the boxes that will allow HTTP and HTTPS traffic.
Click SAVE
Click VM instances
Record the External IP address of your Mediator instance for later use. \
sudo cp .env.sample .envEdit the .env file to fit your environment:
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
Click Create
To “activate” this new subdomain in GC, you need to register the subdomain in your existing domain (i.e. at your registrar).
Click the name of the new zone you just created.
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
Create a DNS Name for proven and record it for later use (e.g. mediator.dev.indiciotech.io)
Defaults are ok
Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
Click “Create”

cd /opt/indicio/aries-mediator-service
sudo docker-compose upUse the following API endpoint: https://your.url.com/api/v1/invitations.
Set your x-api-key header to: 9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW (or your production API key).
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.
Use the following API endpoint: https://your.url.com/api/v1/credentials.
Set your x-api-key header to: 9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW (or your production API key).
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.
Use the following API endpoint: https://your.url.com/api/v1/verifications.
Set your x-api-key header to: 9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW (or your production API key).
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.
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.
Use the following API endpoint with the correct ID in the URL: https://your.url.com/api/v1/verifications/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.
{
"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"
}X-API-Key
24680AEIOUY
Authentication key
User-Agent
node-fetch/1.0
Client identifier
Content-Length
1584
Request body size in bytes
Accept-Encoding
gzip,deflate
Supported compression methods
Payload Format:
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.
Header
Example Value
Description
Content-Type
application/json
Request content type
{
"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'
}
}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.
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.
This selection just shows a list of all invitation QR codes that have been generated by this instance of Proven.
Contacts are connections between the Proven Issuer and other agent applications. Not all software includes an editable label; therefore, some contacts will show the name of the software rather than the name of the person. The following information is displayed when first clicking into Contacts:
Contact Name: The name of the mobile app user

Connection Status:
Invite: an invitation has been sent
Request: the second party has received the invite and is requesting a connection.
Response: the system has responded with details to finish setting up the connection.
Active: the second party has acknowledged the connection.
Created At: the date and time the invitation was sent.
Click on a specific contact to view more information. You can use this interface to issue credentials to Users who have connected to Proven using the main URL. At the bottom of the screen, there is a section of all the credentials issued to a user. To view more detailed information on any issued credential, click on it. This displays things such as the credential name, ID, state, and date created. It also displays certain attributes, such as the different parts of the user credential and the date the credential was validated.
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.
Log in to Keycloak. The address is https://yourURL/identiy.
Change the realm to Indicio Proven. (Image 1)
Click on Users. (Image 2)
Click Add user. (Image 2)
Enter the Username. (Image 3)
The other fields are optional, but may be useful: (Image 3)
First name
Last name
Click Create. (Image 3)
Click the Credentials tab. (Image 4)
Click Set password. (Image 4)
Enter the information in the box that opens: (Image 5)
Password
Password confirmation
Turn on Temporary. This requires the user to reset his or her password when they log in the first time.
Click the Role Mapping tab. (Image 6)
Click Assign Role. (Image 6)
Select Filter by Realm Role from the drop-down. (Image 7)
Click on all desired roles: (Image 7)
admin:
This role can do all regular agent functions: connections, DID creation, credential issuance and presentation, messaging, governance file management, schema management
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)
Click Assign. (Image 7)
Click on the Groups tab. If a group doesn't exist, you may need to .
Click Join Group.
Select any groups applicable. (Image 8)
Click Join. (Image 8)
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.
Log in to Keycloak.
Click Users in the left menu.
Click on the user you wish to edit.
Edit the user’s name or email.
Reset the user’s password
Add or remove roles.
Add or remove groups.
If you wish to delete a user, follow the steps below:
Log in to Keycloak.
Click Users in the left menu.
Click on the three vertical dots found to the right of the user.
Click Delete.
Confirm you want to delete the user.
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.
Log in to Keycloak.
Go to Groups found in the left menu.
Click Create group.
Assign a Name.
Click Create.
Click on the group you just created.
Select the Members tab.
Click Add members.
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
Click Add.
Go to Attributes tab.
Click Add attributes.
Key: proven_group_id
value: [WalletNameHere]
In Settings, an admin can customize the screen to match the branding of the organization. Below are the options and descriptions:
Organization Details:
Organization name: as it appears below the logo on the left
Website title: name as it appears on the browser’s tab
Change Logo: This takes any properly formatted image file which is transparent or has a background that matches the admin system background (the default background color is white, #ffffff):
Change logo: on email stream and on the left.
Change logo 192 x 192: used when a mobile device is used instead of a desktop.
Change logo 512 x 512: used for mobile devices.
Update favicon.io: image found next to the name in the browser’s tab.
Web App Manifest: The web app manifest provides app information to devices which treat the admin portal as a single-page application (such as mobile devices).
Short name
Full name
Theme color
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).
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:
Click Save when all desired changes are made

Click Save.
offline_access: This is a KeyCloak role and Indicio does not make use of it.
super-admin:
This role is for management of multitenancy
Super admins can create subwallets, query all subwallets, and create and revoke API keys for all subwallets
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
technician:
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
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
Regarding the differences between Admin and Technician roles, Simon is a better resource than me since he wrote that code
uma_authorization: This is a KeyCloak role and Indicio does not make use of it.
Click Save.
Background color
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.
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.









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!
Navigate to the Google Cloud Console, https://console.cloud.google.com/
Select the project that you want the Proven instance to reside in.
In the Navigation Menu (top left), go to Compute Engine > VM Instances
If it’s a new project, click “Enable”
Click CREATE INSTANCE
From the left menu select “Marketplace”.
In the “Search Marketplace” field type “Proven” and hit enter.
Select “Indicio Proven”.
Change the Deployment name if desired. This will be the name of your VM instance.
Select and record your Zone choice for later use.
For Machine type choose a machine with at least 2 vCPU’s and 4G memory. For example, these defaults should be adequate:
Set Series to E2
Set Machine type to e2-medium
Under Boot disk it is recommended to select a disk at least 50GB in size. (default)
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.)
Scroll to the bottom, check the box to accept the terms of service, then click DEPLOY.
After deployment is complete:
Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
In the right panel - Click on the instance name to bring up details about the Proven instance you just deployed
Click EDIT
Add a DNS entry for Proven.
Navigate back to the Google Cloud console
SSH into the VM 1. Select Compute engine > VM instances Then for [your-proven-instance] click SSH
Enter these commands in your instance to make it so that the “proven.service” starts up automatically after every server reboot.
Run this command for Proven.
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.
Run the following command:
sudo systemctl start proven
Start a new SSH window if you want to monitor the progress of the starting of Proven.
sudo systemctl status proven
You should now be able to navigate to your Proven issuer in a web browser, using its DNS Name or ip address.
If you left the ISSUER seed variable blank during step 4d, this step is required
Run the following commands from the google cloud SSH window:
sudo docker-compose -f docker-compose.live.yml exec proven-issuer-api node firstimesetup.js
Agree to the Transaction Author Agreement
To setup DNS for Proven on Google’s Cloud DNS, (by creating a new subdomain of your existing domain) do the following:
Go to GCP’s Cloud DNS section in Network services (Navigation Menu > Networking > Network Services > Cloud DNS)
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.
Give the zone a name. This name is just how it will appear in the list and need not necessarily match the new subdomain.
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.
Find the Schema ID of the credential you would like to add to Proven.
For this example, we use the employment schema 4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0 which is from the Indicio DemoNet.
Update the environment file with the schema:
For help with setting up your own Issuer DID, please contact us:

Click GET STARTED to configure your Proven VM as a trial, or click LAUNCH if you have already done the trial.
If a trial, agree to the agreements then click DEPLOY.
For new projects, click “Enable” to enable the required APIs.
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 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.
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,
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.
For later use to stop the proven service: sudo systemctl stop proven
For later use to restart the proven service: sudo systemctl stop proven sudo systemctl start proven
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:
Install the latest Holdr+ app on your mobile device.
Navigate to your Proven IP address or DNS url.
Using your mobile Holdr+ app, scan the QR code displayed.
This creates a connection between your mobile device and the Proven Issuer
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.
Change the IP address in your browser by adding “/admin” to the end of it.
Login using the following credentials:
Username: admin
Password:
You should now see the Issuer admin interface.
Click on CONTACTS in the left menu
Click on the most recent contact.
Under choose credential, select “user”
Hint: if the “user” option is not in the list, refresh the page and try again
Fill in the fields
Click “Send”
You should now see a notification of a new credential on your mobile device (go to the home screen to see notifications on Holdr+)
Click “view” to view the credential offer.
Scroll to the bottom of the Credential offer and click “Accept”
After the credential is added to your wallet, click ‘Done’.
You now have Proven Issuer working!
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).
Click the name of the new zone you just created.
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
Create a DNS Name for proven and record it for later use (e.g. proven.dev.indiciotech.io)
Defaults are okay
Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
Click “Create”
Add a line right after the SCHEMA_USER line
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:
sudo vi common-services.yml
Locate the line containing SCHEMA_USER in the file. (It’s about a third of the way through the file.)
Below that line, add the following line:
- SCHEMA_EMPLOYMENT=${SCHEMA_EMPLOYMENT}
Save and exit
Update the schema definition files with the new schema:
sudo vi config/proven-issuer-api/schemas.json { "schemas": [ { "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0" }, { "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0" } ] }
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" ] } ] }
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:
sudo systemctl stop proven
sudo docker-compose -f docker-compose.live.yml down -v
sudo rm -rf postgres-db
sudo systemctl start proven
Return to main instructions and continue.

cd /opt/indicio/proven-release-docker
sudo systemctl enable proven sudo cp staging.env .envCredential Definitions
These are specific to the use of the AnonCreds credential format with Hyperledger Indy. Credential Definitions link a cryptographic key to each of the attributes in a Credential Schema. This allows a holder of a credential to share information in privacy-preserving ways, such as through selective disclosure (only a single attribute is shared) or a predicate proof (an attribute value can be numerically assessed without the actual value being disclosed, such as >21 or <21 for purchasing items that have legal age requirements).
Revocation Registry Accumulators
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.
Before issuing a credential, you will need to create the “blueprint” (AKA class, schema, credential-type, etc.). See the following code example.
format {string}: The format of the credential. Will always be vc+sd-jwt for issuing SD-JWTs.
id
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.
Provision mDoc issuer key material so that you can securely issue mdoc and mDL credentials.
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.
format_data.cryptographic_binding_methods_supported {object}: Not currently in use; should be ignored.
format_data.display {object}: Not currently in use; should be ignored.
format_data.vct {object}: String or url that identifies the type of SD-JWT.
format_data.claims {object}: An object with the body of your credential. The mandatory (optional) field signifies if the field is required to issue the credential. The value_type (optional) is the data_type of the field. It can accept the following types: string, number, and image media types such as image/jpeg as defined in IANA media type registry for images (https://www.iana.org/assignments/media-types/media-types.xhtml#image). Other values may also be used.
vc_additional_data.sd_list {array}: Paths to values that can be asked for specifically and/or omitted. If the path to a value is not in the sd_list, then the value will be present each time that credential is presented.
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.
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 MUST limit submitted fields to those listed in the fields array (if present). 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 ) if they do not implement it.
preferred
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.
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:
Field name
Expected type/ values
Examples
Notes
verification_id
integer
10
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"
]
}
}'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{
"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"
}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
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:
trustAnchors {array}: The trust anchors configured for this issuer. Empty if none have been configured.
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).
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.
agentRecord {object}: The record created in the agent.
supported_cred_id {string}: Unique identifier for this credential type in the agent. Sample: 9fd5ef9d-b8b8-4f52-b6a9-95b9ce4f6f8a
identifier {string}: The doctype string used as the credential type identifier. Sample: org.iso.18013.5.1.mDL
format {string}: The credential format. Always mso_mdoc for mdoc credentials.
display {array of objects}: Display metadata as stored in the agent.
format_data {object}: The doctype and claims as stored in the agent.
dbConfig {object}: The configuration record stored in the Proven database.
config_id {string}: Unique identifier for this configuration record. Sample: c4d8f7f2-f8d0-4d0b-93d0-9f9f31a5c003
wallet_id {string}: The wallet this configuration is associated with. Sample:
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, 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.
offer {object}: The credential offer object, suitable for delivery to a holder's wallet.
credential_issuer {string}: The URL of the credential issuer. Sample: https://example/oid4vc/tenant/c286d1c7-c548-48d1-8580-76d3fe317bff
credentials {array of strings}: The credential type identifiers included in this offer. For an mDL this will be ["org.iso.18013.5.1.mDL"].
grants {object}: The grant types available for this offer. For mdoc/mDL issuance, this will contain a pre-authorized code grant.
urn:ietf:params:oauth:grant-type:pre-authorized_code {object}: The pre-authorized code grant.
pre-authorized_code {string}: The pre-authorized code the holder's wallet uses to retrieve the credential. Sample:
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.
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.
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
pres_def_id {string}: The system-generated identifier for this presentation definition. Save this — you will need it to create a presentation request. Sample: 42c870ae-b605-4121-b5e3-1e6bb3a00c6f
pres_def {object}: The presentation definition as stored, including any system-generated fields such as id.
wallet_id {string}: The wallet associated with this definition. Sample: c286d1c7-c548-48d1-8580-76d3fe317bff
created_at {string}: ISO 8601 timestamp of when the record was created.
updated_at {string}: ISO 8601 timestamp of when the record was last updated.
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.
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.
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).
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.
params {object}: The pagination and filter parameters applied to the query.
rows {array of objects}: The presentation records. Key fields on each record include:
presentation_exchange_id {string}: Unique identifier for the presentation exchange.
state {string}: The current state (e.g., request-created, done).
verified {boolean}: Whether the presented credentials were successfully verified.
role {string}: The role in the exchange (e.g., verifier).
presentation {object}: The presented credentials, if available.
created_at {string}: ISO 8601 timestamp of when the record was created.
updated_at {string}: ISO 8601 timestamp of when the record was last updated.
count {integer}: The total number of presentation records.
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.
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
}'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='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.
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.
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.
Navigate to the Google Cloud Console,
Select the project that you want the Proven instance to reside in.
In the Navigation Menu (top left), go to Compute Engine > VM Instances
8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001subject_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
wallet-123doctype {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.
iQ7DWmf2vjogMtQ_bdrDQguser_pin_required {boolean}: Whether the holder is required to supply a PIN to redeem the offer.
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.
path$['org.iso.18013.5.1']['claim_name']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.
Primary identifier for the verification request record
connection_id
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
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

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:
Blockchain distributed ledger. The advantage of using a distributed ledger is that it provides credential resilience and longevity.
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.
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:
Log in to the Proven UI.
Click INVITATIONS in the main menu.
Click the large + button in the lower right corner.
Fill in the fields. Start with the following common values, then adjust to your preferences as needed:
OOB Invitation: True
Protocol: DID Exchange 1.1
Alias: your choice, used to refer to the invitation within Proven
Invitation Mode: Multi
Uses: leave blank for no limit or enter a specific number (e.g. 5000) to cap how many times the invitation will be used
Accept: Auto
Public: False
Their Role: your choice, could be used to categorize connections
Their Label: your choice, usually used by other agents as a friendly name for this agent
Workflow Status: Active
Description: your choice, usually a short reminder of what this invitation was created for
Purpose: your choice, this is a unique “handle” to use when linking invitations to specific workflows or behavior
Active Starting Time: unused in this version
Active Ending Time: unused in this version
Once the invitation is created, click on the new invitation, then copy the new invitation URL into your application.
Congratulations, you now have an instance of Proven that you can use for learning, experimentation, and development!
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 Indicio Proven API Tutorial demonstrates how to connect, issue, and verify an AnonCreds credential using a Proven Agent and the Holdr+ Mobile Wallet application.
See API Calls for OID4VCI and OID4VP SDJWT for instructions to issue and verify an SD-JWT VC or JWT VC using a Proven Agent and then using the SDK.
See Indicio Proven API Documentation to view the API calls to issue and verify JSON-LD type credentials using a Proven Agent.
You can also refer to the Indicio Proven API Reference to learn more about individual API calls.
The Holdr Mobile SDK Documentation 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:
Publish schemas and configure your Proven agent(s) to use them.
Issue a test credential using dummy data to an existing wallet (such as Holdr+).
Use Holdr+ to present the test credential to your Proven verifier.
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.
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.
Keep the following tips and information in mind while you are integrating decentralized identity into your solution using Proven:
(Developer) licenses
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.
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.
Enforcement - Indicio Proven and the Indicio Holdr SDK will stop working after their license grace periods expire, usually after 60 days.
Development tips & tricks
Source control - We recommend keeping your code in a source control solution to make sure that your code is versioned and backed up.
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
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, , to share your issues and we will get back to you as soon as we can.
Testing during development
Unit/integration/E2E testing
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.
Happy/unhappy path testing
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:
Secure passwords
Follow the instructions for setting up Proven to ensure that all passwords included in Proven are secure.
Firewall
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
Implement real-time monitoring for at least the following:
CPU
memory
OS Security
Apply all OS security patches regularly
Access control
Limit the number of users with access to the server (but have at least two).
Enforce MFA for all admin accounts.
Backups
Automated daily backups.
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
Scalability 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.
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.
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.
{
"attr_names": [
"user_email",
"username",
"user_id",
"user_roles"
],
"name": "User",
"version": "1.0"
}If it’s a new project, click “Enable”
Click CREATE INSTANCE
From the left menu select “Marketplace”.
In the “Search Marketplace” field type “Proven” and hit enter.
Select “Indicio Proven”.
Click GET STARTED to configure your Proven VM as a trial, or click LAUNCH if you have already done the trial.
If a trial, agree to the agreements then click DEPLOY.
For new projects, click “Enable” to enable the required APIs.
Change the Deployment name if desired. This will be the name of your VM instance.
Select and record your Zone choice for later use.
For Machine type choose a machine with at least 2 vCPU’s and 4G memory. For example, these defaults should be adequate:
Set Series to E2
Set Machine type to e2-medium
Under Boot disk it is recommended to select a disk at least 50GB in size. (default)
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.)
Scroll to the bottom, check the box to accept the terms of service, then click DEPLOY.
After deployment is complete:
Note the link for instructions for creating a static IP address if needed (on the right under “Suggested next steps”)
In the right panel - Click on the instance name to bring up details about the Proven instance you just deployed
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.
Add a DNS entry for Proven.
Navigate back to the Google Cloud console
SSH into the VM 1. Select Compute engine > VM instances Then for [your-proven-instance] click SSH
Enter these commands in your instance to make it so that the “proven.service” starts up automatically after every server reboot.
cd /opt/indicio/proven-release-docker
sudo systemctl enable provenRun this command for Proven.
sudo cp staging.env .envRun 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.
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=http://10.128.15.205:6543 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=https://proven.dev.indiciotech.io If you have a DNS name, change localhost to the issuer DNS name with https://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.
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.
For an example of a configured .env file, please see Appendix B.
Run the following command:
sudo systemctl start proven
Start a new SSH window if you want to monitor the progress of the starting of Proven.
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,
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.
For later use to stop the proven service: sudo systemctl stop proven
You should now be able to navigate to your Proven issuer in a web browser, using its DNS Name or ip address.
If you left the ISSUER seed variable blank during step 4d, this step is required
Run the following commands from the google cloud SSH window:
sudo docker-compose -f docker-compose.live.yml exec proven-issuer-api node firstimesetup.js
Agree to the Transaction Author Agreement
To anchor the new DID which is now displayed -> open
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:
Install the latest Holdr+ app on your mobile device.
Navigate to your Proven IP address or DNS url.
Using your mobile Holdr+ app, scan the QR code displayed.
To setup DNS for Proven on Google’s Cloud DNS, (by creating a new subdomain of your existing domain) do the following:
Go to GCP’s Cloud DNS section in Network services (Navigation Menu > Networking > Network Services > Cloud DNS)
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.
Give the zone a name. This name is just how it will appear in the list and need not necessarily match the new subdomain.
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).
Click the name of the new zone you just created.
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
Create a DNS Name for proven and record it for later use (e.g. proven.dev.indiciotech.io)
Defaults are okay
Set the “IPv4 Address” to the “External IP address” of the VM you created earlier.
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_files/pool_transactions_testnet_genesis
The URL to the Genesis pool file. Must be a URL. Do not include a trailing slash. The default connects to the testnet, make sure to adjust this for the network you are connecting to.
PROVEN_ISSUER_SEED=
Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Typically only used in Live environments.
TEST_SEED=
Must be 32 alphanumeric characters. Has to have “--seed “ at the start. Not necessary.
TAILS_URL=http://10.128.15.205:6543
Replace the IP address with your local IP address on this line.
DISABLE_SSL_CHECK=true
NODE_ENV=development
Possible values: production, development
GOVERNANCE_PATH=http://localhost:3100/api/governance-framework
Where governance details are downloaded from. Can use DNS name, but typically left as localhost.
PROVEN_ISSUER_API_DB_HOST=db
Local database
PROVEN_ISSUER_API_DB=provenapi
Local database
PROVEN_ISSUER_API_DB_USERNAME=provenapi
Local database
PROVEN_ISSUER_API_DB_PASSWORD=provenapi
Local database
PROVEN_ISSUER_AGENT_DB=provenagent
Local database
PROVEN_ISSUER_AGENT_DB_HOST=db
Local database
PROVEN_ISSUER_AGENT_DB_USERNAME=provenagent
Local database
PROVEN_ISSUER_AGENT_DB_PASSWORD=provenagent
Local database
PROVEN_ISSUER_AGENT_ADMIN_DB_USERNAME=development
Local database
PROVEN_ISSUER_AGENT_ADMIN_DB_PASSWORD=development
Local database
PROVEN_ISSUER_AGENT_LABEL=Proven
This is what you want the issuer name to show up as on other agents’ connection list.
PROVEN_ISSUER_ENC_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b
Encryption key. Must be 32 alphanumeric characters.
PROVEN_ISSUER_PROXY_DB=postgres://provenproxy:provenproxy@db:5432/provenproxy
PROVEN_ISSUER_WEB_ROOT=https://issuer.dev.indiciotech.io
If you have a DNS name, change localhost to the issuer DNS name with https://. Otherwise, change it to your VM’s external IP. Do not have a trailing slash.
PROVEN_ISSUER_JWT_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq
Must be 32 alphanumeric characters.
PROVEN_ISSUER_SESSION_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5
Must be 32 alphanumeric characters.
PROVEN_ISSUER_ENC_KEY=54234625127cb22694ff0e27cc14b685
Must be 32 alphanumeric characters.
ISSUER_RECAPTCHA_SITEKEY=
Paste in your saved recaptcha site key that you created in step 3
ISSUER_RECAPTCHA_SECRETKEY=
Paste in your saved recaptcha secret key that you created in step 3
SCHEMA_USER=Gj39gdivhMneKBaamMsX7P:2:User:1.0
Here is an example of a configured .env:
PROVEN_ISSUER_SSL_DOMAIN_PATH=
PROVEN_ISSUER_SERVER_NAME=issuer-proven-test.dev.indiciotech.io
PROVEN_ISSUER_HTTPS_PORT=443
PROVEN_ISSUER_HTTP_PORT=80
PROVEN_SESSION_MAXAGE=86400000
WDS_SOCKET_PORT=0
WDS_SOCKET_HOST=0.0.0.0
WDS_SOCKET_PATH=sockjs-node
PROVEN_ISSUER_SEED=
TEST_SEED=
TAILS_URL=http://10.128.15.205:6543
DISABLE_SSL_CHECK=true
NODE_ENV=development
GOVERNANCE_PATH=http://localhost:3100/api/governance-framework
PROVEN_ISSUER_API_DB_HOST=db
PROVEN_ISSUER_API_DB=provenapi
PROVEN_ISSUER_API_DB_USERNAME=provenapi
PROVEN_ISSUER_API_DB_PASSWORD=provenapi
PROVEN_ISSUER_AGENT_DB=provenagent
PROVEN_ISSUER_AGENT_DB_HOST=db
PROVEN_ISSUER_AGENT_DB_USERNAME=provenagent
PROVEN_ISSUER_AGENT_DB_PASSWORD=provenagent
PROVEN_ISSUER_AGENT_ADMIN_DB_USERNAME=development
PROVEN_ISSUER_AGENT_ADMIN_DB_PASSWORD=development
PROVEN_ISSUER_AGENT_LABEL=Proven
PROVEN_ISSUER_ENC_KEY=1ae2e84429d3447aa9aa8e38ea84fa6b
PROVEN_ISSUER_PROXY_DB=postgres://provenproxy:provenproxy@db:5432/provenproxy
PROVEN_ISSUER_WEB_ROOT=https://issuer-proven-test.dev.indiciotech.io
PROVEN_ISSUER_JWT_SECRET=Zu0gPaBdGSP8dfgoK6C1vlBLaXOh6gGq
PROVEN_ISSUER_SESSION_SECRET=Xn2r5u8xjAgD7G39jjdSgVkYp3s6v9y5
PROVEN_ISSUER_ENC_KEY=54234625127cb22694ff0e27cc14b685
ISSUER_RECAPTCHA_SITEKEY=6LcokwUmAAAAAOg8mC4bXpRObIMVpB6LsFvzty3e
ISSUER_RECAPTCHA_SECRETKEY=6LcokwUmAAAAAIcuLhLZ_Vgd_6TUhOj0E9QcBAXS
SCHEMA_USER=Gj39gdivhMneKBaamMsX7P:2:User:1.0
Proven ships with just a User credential by default. The following details the instructions for adding a new credential type to the list of credentials managed by your instance of Proven. These instructions just include the method needed for altering the Proven configuration to include an existing schema and do not include the instructions for building and adding a schema to an identity network. Please contact support@indicio.tech for more information.
These instructions are an example of how to add an employment schema to your instance of Proven.
Find the Schema ID of the credential you would like to add to Proven.
For this example, we use the employment schema 4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0 which is from the Indicio DemoNet.
Update the environment file with the schema:
sudo vi .env
Add a line right after the SCHEMA_USER line
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:
sudo vi common-services.yml
Locate the line containing SCHEMA_USER in the file. (It’s about a third of the way through the file.)
Below that line, add the following line:
Update the schema definition files with the new schema:
sudo vi config/proven-issuer-api/schemas.json { "schemas": [ { "id": "Gj39gdivhMneKBaamMsX7P:2:User:1.0" }, { "id": "4rZRryzpji8LUwuvKRVdzU:2:Employment:1.0" } ] }
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" ] } ] }
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:
sudo systemctl stop proven
sudo docker-compose -f docker-compose.live.yml down -v
sudo rm -rf postgres-db
Return to main instructions and continue.
For help with setting up your own Issuer DID, please contact us: support@indicio.tech
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.
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
Before creating the instance, you must configure the default and also an additional VPC network for your new node.
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)
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.
Under VPC networks click default to edit the network configurations:
Click on the SUBNETS tab and then on ADD SUBNET and input the following values
Name - client-subnet-9702 (or make a name according to your needs, making sure it is descriptive)
Region - Your selected region
IPv4 range - 10.0.1.0/24 (or enter another valid range according to your needs)
Click ADD
Click the back arrow next to VPC network details to go back to VPC Networks
Click CREATE VPC NETWORK at the top of the screen to create a network for your node connection on your node.
Name - your choice (e.g. node-vpc)
Under Subnet creation mode select Custom
Expand the New subnet section and enter the following values
Navigate to VPC network then select IP addresses from the menu
Click RESERVE EXTERNAL STATIC IP ADDRESS
Name - node-external-ip or your choice
Network Service Tier - Standard
Navigate back to VPC network then VPC networks
Under VPC networks click default to edit the network configurations for the NoDe’s “client” connection.
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:
From the Navigation Menu, select Compute Engine then Snapshots
Select the SNAPSHOT SCHEDULES tab then click CREATE SNAPSHOT SCHEDULE
Name - your choice (e.g. 'nodesnapweekly')
From the Navigation Menu, select Compute Engine, then select VM instances
Click Create Instance at the top of the page
Select Marketplace in the left hand menu
In the search bar, type Indicio NoDe and hit enter
Once the VM is created, navigate to Compute Engine>VM instances
Click on the name of the VM you just created to access it’s settings
Click Edit at the top of the page
To set up ssh keys:
SSH into your new node VM
You can navigate to Compute Engine then VM instances then click SSH towards the right of your NoDe Instance
OR you can use the SSH key access setup from an earlier optional step.
Setup 2FA for SSH access to the Node for your base user.
Complete the network setup process
Run the Oneshot startup process
sudo /opt/indy-startup/Oneshot.sh
sudo netplan generate
To start the indy-cli using your new config file, run the following: indy-cli --config ~/cliconfig
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.
sudo apt install pwgen
Open your wallet and create a DID based on the “Steward Seed” created earlier.
Provide Information to Trustees
At this point you should have the following data available:
Your Steward verkey and DID
The Validator ‘node IP address’
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.
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.
Did Exchange 1.0
Out Of Band 1.1
Coordinate Mediation 1.0
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.
disk space
network behavior
Daily Checks
A daily smoke test helps ensure that your services are always available for your customers.
For later use to restart the proven service: sudo systemctl stop proven sudo systemctl start proven
This creates a connection between your mobile device and the Proven Issuer
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.
Change the IP address in your browser by adding “/admin” to the end of it.
Login using the following credentials:
Username: admin
Password:
You should now see the Issuer admin interface.
Click on CONTACTS in the left menu
Click on the most recent contact.
Under choose credential, select “user”
Hint: if the “user” option is not in the list, refresh the page and try again
Fill in the fields
Click “Send”
You should now see a notification of a new credential on your mobile device (go to the home screen to see notifications on Holdr+)
Click “view” to view the credential offer.
Scroll to the bottom of the Credential offer and click “Accept”
After the credential is added to your wallet, click ‘Done’.
You now have Proven Issuer working!
Click “Create”
- SCHEMA_EMPLOYMENT=${SCHEMA_EMPLOYMENT}
Save and exit
Save and exit
sudo systemctl start proven

Name - your choice (e.g. node-subnet-9701)
Region - Your selected region
IPv4 range - Type in a valid new subnet block. (e.g. 10.0.2.0/24)
Click DONE
For Dynamic routing mode select Regional
Click CREATE
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
Name - client-external-ip or your choice
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
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
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:
Name - your choice (e.g. client-access-9702)
Network - default (should already be set)
Targets - All instances in the network
Source filter - IPv4 ranges
Source IPv4 ranges - 0.0.0.0/0
Protocols and ports - Specified protocols and ports
Select the TCP check box and enter 9702 for the port.
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.
Click Add firewall rule
Name - Name (alias) of the node you are adding
Network - node-vpc
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 address matching the Node name that you are adding. (e.g. 68.179.145.150/32)
Protocols and ports - Specified protocols and ports
Select the TCP check box and enter 9701 for the port
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.
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
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>
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.
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
Network Technical Governance requirements determine the values in this step. 2 vCPUs and 8G memory are the minimum requirements for Indicio Networks.
Series - N2
Machine Type - n2-standard-2 (2 vCPUs and 8G memory)
Boot disk
Boot disk type - Standard persistent disk is adequate.
Size - 250 GB
Network interfaces
Expand and change the existing default network interface. This will be your “client” interface.
Network - default (or client-vpc)
Subnetwork - select the subnet you created earlier for the Client (client-subnet-9702 10.0.1.0/24)
External IP - select the external client IP you created earlier (client-external-ip)
Click DONE (For this network interface)
Click Add A Network Interface to add a second network interface. (Required)
Network - node-vpc
Subnetwork - select the subnet you created earlier for the node (node-subnet-9701)
Primary internal IP - select the internal node IP you created earlier
Click "Deploy" to create the new NoDe GC VM instance.
Scroll down to Security and access
Check the Block project-wide SSH keys (recommended)
Enter a public SSH key for each Admin user (at least your own)
Click + ADD ITEM for each SSH key.
To create an SSH key:
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
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
Copy the results of the previous step and paste it into the space provided, being careful NOT to copy any leading or trailing whitespace.
To enable deletion protection:
Under Basic information select the Enable deletion protection box (recommended)
Install Google Authenticator, Duo, or Authy on your phone.
Configure the authenticator to allow both password and SSH key login with 2FA by changing the following file:
sudo vim /etc/ssh/sshd_config
uncomment the following line at the bottom of the file: AuthenticationMethods publickey,keyboard-interactive
:wq
sudo systemctl restart sshd
Setup your base user to use 2FA by running the following from a terminal:
google-authenticator
Answer "y" to all questions asked during the setup
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:
Send the other new admin users the following instructions for generating their own SSH keys:
ssh-keygen -P "" -t rsa -b 4096 -m pem -f ~/pems/gcnode.pem
Have the new users send you their public key (e.g. gcnode.pem.pub if they do the above command)
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.
Add their IP addresses to the GC firewall:
From the GC VPC Networks screen (GC main menu -> VPC network->VPC networks), click on your Client VPC (e.g. client-vpc-9702)
Click the "Firewall rules" tab (in about the middle of the screen).
Click on the name of the rule that allows port 22 access for your admins (e.g. ssh-for-admin-access)
Add the users to the server:
Login to the node as the base user.
Run the following commands, substituting the username in for <newuser>
sudo adduser <newuser>
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):
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:
ssh -i <your private SSH key file> <username>@<Client IP Addr>
Type in password1 for your password
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>”).
sudo -i -u indy sed -i -re "s/(NETWORK_NAME = ')\w+/\1<network>/" /etc/indy/indy_config.py
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
sudo -i -u indy init_indy_node <ALIAS> <node ip> <node port> <client ip> <client port>
TIP: run ip a to find your IP addresses needed here.
For example: sudo -i -u indy init_indy_node Node8 10.0.2.2 9701 10.0.1.2 9702
You can view an example that is tailored to your system by running the following
cat /opt/indy-startup/init_indy_node_example
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)
sudo sed -i -re "s/(^CLIENT_CONNECTIONS_LIMIT=).*$/\115000/" /etc/indy/indy.env
sudo DEBIAN_FRONTEND=noninteractive apt install -y -q iptables-persistent
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:
echo "REV_STRATEGY_USE_COMPAT_ORDERING = True" | sudo tee -a /etc/indy/indy_config.py
If you are unsure, please check with your network administrator.
Run the Technical Verification Script on the validator node:
Download this script, upload it to your Validator node, and set the execution flag on it:
ubuntu@validator$ cd ~
ubuntu@validator$ curl -O https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/nodeop-tools/nodeop-tech-check.py
ubuntu@validator$ chmod +x nodeop-tech-check.py
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.
ubuntu@validator$ sudo python3 ./nodeop-tech-check.py
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
This example cliconfig file contains the line that sets the AML:
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 ‘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 <pool name (e.g. itn)>
gen_txn_file=pool_transactions_<Network Name (e.g. TestNet)>\_genesis
indy> wallet create <wallet name (e.g. itn_wallet)> key indy> wallet open <wallet_name> key
indy> did new <Steward Seed> metadata=”steward DID”
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
registerAgentHandler
registerBasicMessageHandler
registerRecordHandler
registerWebSocketHandler
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
getEventBusEvents (Record update events)
getMessageEvents (Events for all messages)
getProofEvents
getBasicMessageEvents
getTrustPingEvents
getWebSocketEvents
The following methods wrap events so you can easily listen to them without a third-party library or if you are using Objective-C:
onDidExchangeStateChanged
onCredentialStateChanged
onTrustPingEvent
onAgentEvent
onRecordEvent
onProofEvent
onWebsocketEvent
onBasicMessageEvent
Swift
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)External IP - select the external node IP you created earlier
Click DONE
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 "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:
sudo mkdir /home/<newuser>/.ssh
sudo chown <newuser>:<newuser> /home/<newuser>/.ssh
sudo vim /home/<newuser>/.ssh/authorized_keys
Paste the users public key into the open file and then save it (:wq)
sudo chown <newuser>:<newuser> /home/<newuser>/.ssh/authorized_keys
Repeat the above for each new admin user you create.
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"
Answer "y" to all questions asked during the setup
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!

This endpoint retrieves all messages.
A list of messages
Unauthorized.
No content
Internal Server Error
Internal server errorGET /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"
}
]This endpoint allows you to send a basic message.
The ID of the invitation.
1The ID of the contact.
The message content.
your message hereMessage sent successfully
Bad request. Invalid parameters.
stringUnauthorized.
No content
Internal Server Error
Internal server errorPOST /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"
}{
"success": "Message was sent!"
}This endpoint retrieves a message by its ID.
The ID of the message to retrieve.
A message object
The ID of the invitation.
The ID of the contact.
The message content.
Unauthorized.
No content
Message not found
Basic message record not foundInternal Server Error
Internal server errorGET /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"
}This endpoint retrieves all JSON-LD context files for the authenticated wallet.
A list of JSON-LD context files for the wallet
Unauthorized
No content
Internal Server Error
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"
}
]This endpoint saves a JSON-LD context file for a specific wallet.
The filename of the JSON-LD context file to save.
test.jsonThe JSON-LD 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"}}}Context saved successfully
Bad Request
No content
Unauthorized
No content
Internal Server Error
No content
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"
}
}
}
}
}{
"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"
}This endpoint retrieves a JSON-LD context file by its ID for the authenticated wallet.
The ID of the JSON-LD context file to retrieve.
JSON-LD context file retrieved successfully
Unauthorized
No content
Context file not found
No content
Internal Server Error
No content
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"
}This endpoint retrieves all JSON-LD context files from all wallets (static route).
A list of all JSON-LD context files
Internal Server Error
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"
}
]This endpoint creates a new Decentralized Identifier (DID) using the provided API key.
DID created successfully
The created DID.
95LAyQitNh5kVaayCFC9S2The verification key for the DID.
5QFrR2F9H84nF1T6bBiiahWCiDWrxTnHNtF78u7HPCY4The posture of the DID.
wallet_onlyThe type of key used for the DID.
ed25519DID method.
sovAdditional metadata for the DID.
Unauthorized.
No content
Internal Server Error
Internal server errorPOST /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": {}
}
}This endpoint sets a public Decentralized Identifier (DID) using the provided API key and DID.
The DID to be set as public.
DID set as public successfully
The public DID.
Bad Request
stringUnauthorized.
No content
Internal Server Error
Internal server errorPOST /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"
}
}This endpoint creates a new Decentralized Identifier (DID) using the provided API key.
DID created successfully
The created DID.
Unauthorized.
No content
The TAA must be signed before calling this endpoint
The TAA must be signed before calling this endpointInternal Server Error
Internal server errorPOST /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"
}This endpoint retrieves a governance file by its filename.
The filename of the governance file to retrieve.
Governance file retrieved successfully
Governance file not found
Governance file not foundInternal Server Error
Internal server errorGET /governance/files/{filename} HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{}This endpoint performs bulk credential issuance based on the valid email addresses.
The email address to be verified as one of the bulk credential recipient.
no_reply@indiciotech.ioThe schema ID of the credential to be issued.
E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0The number of days for the recipient to accept the credential.
518400000Email verification successful
Bad Request
stringUnauthorized.
No content
Internal Server Error
Internal server errorPOST /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"
}
]
}
]
}{
"emailsSuccess": [
"text"
],
"emailsFailure": [
"text"
],
"invalidEmails": [
"text"
]
}This endpoint allows you to create a new subwallet by providing a wallet name and an optional label.
The name of the subwallet to be created.
mySubwalletAn optional label for the subwallet.
My Subwallet LabelSubwallet created successfully
The ID of the created subwallet.
1A token for the created subwallet.
abcdef123456Subwallet creation failed due to missing wallet name.
Error message indicating the reason for failure.
Subwallet creation failed. Subwallet name is required.Unauthorized.
No content
Internal server error while creating subwallet.
Error creating subwalletPOST /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"
}{
"wallet_id": 1,
"token": "abcdef123456"
}This endpoint allows you to retrieve all subwallets created under this base admin.
Retrieved subwallets successfully
The ID of the retrieved subwallet.
1A token for the retrieved subwallet.
abcdef123456A label for the retrieved subwallet.
MySubwalletUnauthorized.
No content
Internal server error while retrieving subwallets.
There was a problem retrieving subwalletsGET /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"
}
]This endpoint allows you to retrieve a subwallet by its wallet_id
The ID of the subwallet
A subwallet record
The ID of the retrieved subwallet.
1A token for the retrieved subwallet.
abcdef123456A label for the retrieved subwallet.
MySubwalletUnauthorized.
No content
Subwallet record not found
Subwallet record not foundInternal server error while retrieving a subwallet.
There was a problem retrieving subwalletGET /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"
}Generates a new API key and stores its HMAC in the database. API key names must be unique per wallet.
The ID of the wallet for which the API key is being created.
A descriptive label for the API key.
The roles associated with the API key.
Optional ISO-8601 timestamp when the API key expires. Omit or set to null for no expiration.
API key successfully created.
The generated API key.
The ID of the stored HMACed API key.
The saved label for the API key.
Status message.
The selected expiration timestamp, if provided.
Bad request. Missing or invalid parameters.
Error message.
Unauthorized.
No content
Internal server error.
Error message.
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"
}{
"api_key": "abcdef123456",
"key_id": "key123",
"name": "CI worker",
"status": "API key successfully created.",
"expires_at": "2026-01-01T00:00:00.000Z"
}This endpoint revokes an API key by deleting it for the specified wallet and name.
The ID of the wallet associated with the API key.
wallet123The name of the API key to be revoked.
CI workerAPI key successfully revoked
Status message indicating the API key was successfully revoked.
Bad request. Missing or invalid parameters.
Error message indicating what went wrong.
Unauthorized.
No content
API key record not found
API key record not foundInternal server error
Internal server errorPOST /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"
}{
"status": "text"
}This endpoint retrieves all invitations associated with the provided API key.
The field to sort by (default updated_at).
The direction to sort (ASC or DESC, default DESC).
The number of invitations per page (default 20).
The current page number (default 1).
The total number of items.
If provided, returns only invitations with this state.
If provided, returns only invitations for this contact_id.
A list of invitations
Unauthorized.
No content
Internal Server Error
Internal server errorGET /api/v1/invitations HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{
"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
}This endpoint creates a new invitation of type OOB.
The type of the invitation (OOB).
OOBThe ID of the contact.
undefinedThe handshake protocol for OOB invitations.
undefinedThe alias for the invitation.
undefinedThe mode of the invitation.
undefinedThe accept criteria for the invitation.
trueWhether the invitation is public.
falseThe role of the invitation.
undefinedThe label of the invitation.
undefinedThe status of the invitation.
undefinedThe description of the invitation.
undefinedThe purpose of the invitation (optional unique identifier - if provided, must be unique per wallet).
undefinedThe start time of the invitation's active period.
undefinedThe end time of the invitation's active period.
undefinedThe number of uses allowed for the invitation.
undefinedInvitation created successfully
https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl191Bad Request
{"value":"Purpose must be a string","summary":"Purpose field is not a string"}Unauthorized.
No content
Internal Server Error
Internal server errorPOST /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
}{
"invitation_url": "https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl19",
"invitation_id": 1,
"contact_id": ""
}This endpoint accepts an invitation of type OOB.
The URL of the invitation to be accepted.
undefinedExample: https://example.com/invitation?oob=abc123Invitation accepted successfully
Bad Request
stringUnauthorized.
No content
Internal Server Error
Internal server errorPOST /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"
}{
"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
}
}This endpoint retrieves a specific invitation by its ID.
The ID of the invitation.
1Invitation retrieved successfully
The retrieved invitation credential record.
Unauthorized.
No content
Invitation not found
Invitation record not foundInternal Server Error
Internal server errorGET /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"
}This endpoint updates an existing invitation.
The ID of the invitation to update.
The workflow status of the invitation.
activeThe description of the invitation.
This is an updated invitation.The purpose of the invitation (unique identifier).
verification-demo-2025The start time of the invitation.
2023-01-01T00:00:00ZThe end time of the invitation.
2030-12-31T23:59:59ZThe number of uses allowed for the invitation.
1Invitation updated successfully
The updated invitation record.
Bad request. Invalid parameters.
stringInvitation record not found
Invitation record not foundInternal server error
Internal server errorPUT /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
}{
"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"
}This endpoint deletes an existing invitation.
The ID of the invitation to delete.
Invitation deleted successfully
Invitation was deleted successfully!Bad request. Invalid parameters.
stringInvitation record not found
Invitation record not foundInternal server error
Internal server errorDELETE /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!"
}Retrieves a specific invitation by its purpose identifier.
The purpose identifier of the invitation.
demo-1Invitation retrieved successfully
The retrieved invitation credential record.
Bad request. Invalid parameters.
Invalid purpose parameter!Unauthorized.
No content
Invitation not found
Invitation record not foundInternal Server Error
Internal server errorGET /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"
}This endpoint issues JSON-LD credentials.
The timeout for the credential issuance (seconds).
30The invitation ID.
1The contact ID.
The ID of status list definition to enable revocation
The contexts of the credential.
["https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json","https://www.w3.org/ns/credentials/status/v1"]The issuance date of the credential.
2024-11-29T21:07:11ZThe valid from date of the credential.
2024-11-29T11:34:20ZThe awarded date of the credential.
2024-11-29T21:07:11ZThe expiration date of the credential.
2030-11-29T11:34:20ZThe valid until date of the credential.
2030-11-29T11:34:20ZThe types of the credential.
["OpenBadgeCredential"]The description of the credential.
Awesome Credential DescriptionThe name of the credential.
New Awesome JSON-LD CredentialThe identifier of the issuer
did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8The types of the issuer.
["Profile"]The name of the issuer.
Awesome Issuer NameThe description of the issuer.
An awesome Issuer who Issues awesome credentials.The URL of the issuer.
https://www.awesome-issuer-url.comThe email of the issuer.
issuer-contact@example.orgThe ID of the image.
https://www.awesome-issuer-url.com/images/issuer-logo.pngThe type of the image.
ImageThe caption of the image.
Awesome Issuer LogoThe types of the credential subject.
["AchievementSubject"]The ID of the achievement.
https://example.org/achievements/degreeThe name of the achievement.
Your nameThe description of the achievement.
Your descriptionThe type of the criteria.
CriteriaThe narrative of the criteria.
Your narrativeThe ID of the image.
https://example.org/achievements/image.pngThe type of the image.
ImageThe types of the achievement.
["Achievement"]The proofType for the credential issuance
Ed25519Signature2020The rule for the credential issuance.
stringJSON-LD credential issued successfully
Bad Request
stringUnauthorized.
No content
Unprocessable Entity.
stringInternal Server Error
Internal server error.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"
}{
"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"
}
}
}This endpoint retrieves a JSON-LD credential by its ID using the provided API key.
The ID of the credential.
1JSON-LD credential retrieved successfully
The retrieved JSON-LD credential record.
Bad Request
stringUnauthorized.
No content
JSON-LD credential record not found
JSON-LD credential record not foundInternal Server Error
Internal server errorGET /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: */*
{
"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"
}
}This endpoint retrieves all credentials associated with the provided API.
The field to sort by (default updated_at).
The direction to sort (ASC or DESC, default DESC).
The number of credentials per page (default 20).
The current page number (default 1).
The total number of items.
If provided, returns only credentials with this state.
If provided, returns only credentials for this contact_id.
A paginated list of credentials
Unauthorized.
No content
Internal Server Error
API key record not foundGET /api/v1/credentials HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{
"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
}This endpoint allows you to add a new credential request.
The timeout for the credential issuance (seconds).
30The ID of the invitation.
The ID of the contact.
The ID of the schema.
The name of the attribute.
The value of the attribute.
The rule for the credential issuance.
AnonCred credential issuance record was created
Bad Request
stringUnauthorized.
No content
Unprocessable Entity.
stringInternal Server Error
Internal server errorPOST /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"
}{
"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"
}This endpoint retrieves a specific credential by its credential exchange ID.
The credential exchange ID.
1A credential object
Unauthorized.
No content
Credential record not found
Credential record not foundInternal Server Error
Internal server errorGET /api/v1/credentials/{credential_exchange_id} HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{
"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
}This endpoint manually removes PII from a credential record.
The credential exchange ID.
02189932-52ac-4f9d-bf84-1fcfb7c67fa1PII removed successfully
Credential PII removedUnauthorized.
No content
Credential record not found
Credential record not foundInternal Server Error
Internal server errorPOST /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: */*
{
"message": "Credential PII removed"
}This endpoint retrieves an AnonCred credential record by its ID using the provided API key.
The ID of the credential record.
1Credential record retrieved successfully
The retrieved AnonCred credential record.
Unauthorized.
No content
AnonCred credential record not found
AnonCred credential record not foundInternal Server Error
Internal server errorGET /api/v1/credential-records/{request_id} HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{
"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"
}
}This endpoint allows you to revoke a credential by providing the connection and credential exchange IDs.
The connection ID associated with the credential.
The credential exchange ID of the credential to revoke.
Credential revocation request accepted or already revoked
Bad Request
Unauthorized
No content
Unprocessable Entity
Internal Server Error
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"
}{
"message": "Revocation request processed successfully."
}This endpoint retrieves all connections.
The field to sort by (default updated_at).
The direction to sort (ASC or DESC, default DESC).
The number of connections per page (default 20).
The current page number (default 1).
The total number of items.
If provided, returns only connections with this state.
If provided, returns only connections for this contact_id.
A list of connections
Unauthorized.
No content
Internal Server Error
Internal server errorGET /api/v1/connections HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*
{
"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
}This endpoint retrieves a connection by its id.
The connection id of the connection to retrieve.
Connection record retrieved successfully
Unauthorized.
No content
Connection not found
Connection record not foundInternal Server Error
Internal server errorGET /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"
}
}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.
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.
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 http://your-domain-name.com/auth/login. You will be redirected from Proven to a Keycloak login page, where you will log in with the user “indicio” and password “adminadminadmin”. After successful authentication, you will be redirected back to Proven. Keycloak will pass an OpenID Connect token, which will log the user in automatically. You will then see the Proven dashboard with the user “indicio” logged in.
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:
Create a New Group in Keycloak:
Select the “Indicio Proven Realm”
Click on “Groups” in the left menu
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.
Click the “Authorize” button at the top right of the page.
Enter the API key in the “Value” field.
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 .
Create a new wallet if it is not already created.
Navigate to the API Keys tab and click the “Create API Key” button.
Enter the wallet_id for the wallet to which the API key will belong.
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
User Requests API Key: The user requests to generate an API key.
Generate Random String: The API generates an opaque random string using a secure random source.
Present API Key: The API presents the random string (API key) to the user.
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
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)
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:
Select the “Indicio Proven Realm”
Click on “Users” in the left menu
Select the user to add to the wallet
Click on the “Groups” tab
Click on the “Join Group” button
Select the group(s) (which correspond to wallets) that you would like to add the user to
Click the “Join” button
Log in to Proven:
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.
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.
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
message_id
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
message_id
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
state
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
state
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
contact_id
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
connection_id
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
connection_id
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
contact_id
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)
connection_id
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
connection_id
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
wallet_id
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
wallet_id
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
verkey
string
6RCKgJhNz76u98RpzVYMrrXDEgPn3hZ5mvwyJnjvevP
DID’s verkey
posture
string
wallet_only
Posture of the DID
key_type
string
ed25519
Type of key used for the DID
method
string
sov
Method used for generating the DID
metadata
object
{...}
Metadata for the DID
verkey
string
HjfSSD6DDPfAME5Th5NTESEoToJgVWqUo7u81euPGX7K
DID’s verkey
posture
string
posted
Posture of the DID
key_type
string
ed25519
Type of key used for the DID
method
string
sov
Method used for generating the DID
metadata
object
{...}
Metadata for the DID
contact_id
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
oob_id
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)
oob_id
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).
oob_id
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)
wallet_id
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
wallet_id
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
connection_id
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
connection_id
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
connection_id
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
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
connection_id
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
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 - POSTField 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 - GETField 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> - GETField 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 - GETField 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¤t-page=2Field name
Expected type/values
Examples
Notes
connection_id
string
d61b698f-2eb4-438d-bec0-a7f88bcb47f0
{
"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> - GETField name
Expected type/values
Examples
Notes
connection_id
string
d61b698f-2eb4-438d-bec0-a7f88bcb47f0
{
"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 - POSTField 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 - POSTField 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
[
{
"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> - GETField name
Expected type/values
Examples
Notes
request_id
integer
1
[
{
"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 - POSTField 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
[
{
"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> - GETField name
Expected type/values
Examples
Notes
request_id
integer
123
{
"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 - GETField 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> - GETField 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 - POSTField 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 - POSTField name
Expected type/ values
Examples
Notes
DID
text
XhvSpiDsLVmStHa19VC4hJ
DID set as public
https://your-domain-name.com/api/v1/set-public-did?DID=WSPiMexQfuVrR9wMQbg5F7Field 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 - POSTField 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 - POSTField 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 - POSTField 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 - GETField 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¤t-page=2https://your-domain-name.com/api/v1/invitations?page-size=50¤t-page=5Field name
Expected type/values
Examples
Notes
invitation_id
int
4325
{
"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> - GETField name
Expected type/values
Examples
Notes
invitation_id
int
4325
{
"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> - PUTField 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
{
"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> - DELETEField name
Expected type/values
Examples
Notes
success
string
“Invitation 2 was deleted successfully!”
Success message
{
"success": "Invitation 2 was deleted successfully!"
}/api/v1/presentations - GETField name
Expected type/values
Examples
Notes
presentation_exchange_id
string
349c7662-6837-4274-b213-355dab5d92f2
[
{
"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> - GETField name
Expected type/values
Examples
Notes
presentation_exchange_id
string
349c7662-6837-4274-b213-355dab5d92f2
{
"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 - POSTField 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 - POSTField 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 - POSTField 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
[
{
"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> - GETField name
Expected type/values
Examples
Notes
verification_id
integer
10
{
"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 - POSTField 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
[
{
"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> - GETField name
Expected type/values
Examples
Notes
verification_id
integer
10
{
"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"
}
contact_id
sort-direction
Unique and primary identifier for the connection
Unique and primary identifier for the connection
file
Records primary key
Records primary key
Issuance request record primary key
Issuance request record primary key
invitation_id
invitation_record
sort-direction
Integer used as the primary identifier for this record
Integer used as the primary identifier for this record
description
Integer used as the primary identifier for this record
Primary identifier used for the presentation record
Primary identifier used for the presentation record
taa_record
text
taa_record
contact_id
Primary identifier for the verification request record
Primary identifier for the verification request record
contact_id
Primary identifier for the verification request record
Primary identifier for the verification request record