1 of 36

Indicio Proven ®

Unlocking efficiency and savings across industries and sectors

About Indicio Proven ®

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

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

Benefits

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

Indicio Proven is the most advanced solution for decentralized identity using verifiable credentials and Open Badges 3.0. It gives you maximum speed and flexibility to build, launch, scale, and manage verifiable credential ecosystems.
It’s built for interoperability. Indicio Proven works with existing and emerging global standards, including EU eIDAS and EUDI digital wallets.
It’s fast to implement. Integrate Proven with your current systems and can be configured in days—not months.

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

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

Verifiable Credential Schema Flexible template for creating credentials.

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

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

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

Introduction to Proven

A complete verifiable credential solution for identity and data

Seamless, streamlined, and secure identity verification

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

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

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

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

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

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

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

What's included

Issuer & Verifier Agents

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

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.

Proven Integration Guide

The following document describes the major steps to integrate with Proven and incorporate verifiable credentials and decentralized identity into your software, solutions, and workflows. This guide covers all of the necessary information in recommended order and assumes you have general software development knowledge and only an introductory level understanding of decentralized identity technology.

This guide starts with an introduction to decentralized identity technology and guides you through architecting your solution. Next, set up a development environment, learn the API and SDK calls, and implement your integration. As your integration nears completion, configure your staging and production environments and test what you’ve developed. Finally, launch, evaluate, maintain, and update your solution.

Feel free to skip sections you already understand or to jump straight to what you want to learn. Remember, this is a guide to help you understand how your solution could be implemented, but you should consider your specific requirements, make adjustments, and customize as necessary.

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.

How to Guides

Proven User Guide

Indicio Proven™ provides the tools to establish a Trusted Digital Ecosystem (TDE). Out of the box, you can issue, verify, and manage user credentials. Once you have a user credential, other workflows become possible because you can trust you are working with a known person or agent. The issuer’s role is to send invitations to the contacts to offer them user credentials. The issuer also manages contacts.

Home

After logging into the Admin screen, you will land on the home page. To issue yourself a User credential first select the User credential from the dropdown list. If the user credential does not appear, then a browser refresh might be required. Then click Issue. Scan the displayed QR code with your mobile identity wallet app. Complete the form, then click Send. Accept the offered credential on your mobile device.

Invitations

This selection just shows a list of all invitation QR codes that have been generated by this instance of Proven.

Contacts

Contacts are connections between the Proven Issuer and other agent applications. Not all software includes an editable label; therefore, some contacts will show the name of the software rather than the name of the person. The following information is displayed when first clicking into Contacts:

Contact Name: The name of the mobile app user
Connection Status:
- Invite: an invitation has been sent
- Request: the second party has received the invite and is requesting a connection.
- Response: the system has responded with details to finish setting up the connection.
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

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.
1. Edit the user’s name or email.

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.

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.

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

Click Save when all desired changes are made

Proven User Tutorial

Introduction

Indicio Proven™ provides the tools to establish a Trusted Digital Ecosystem (TDE). You can immediately issue, verify, and manage credentials. While the options are almost limitless, this tutorial will lead you through a simple workflow that illustrates some of Proven’s core capabilities.

Install the Holdr+ Mobile Wallet

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

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. Check the box verifying you've read, understand, and accept the terms.
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.

Indicio Proven API Tutorial

This tutorial goes through a series of steps to exercise a few of the key features of the Proven API and help you begin to construct your own workflows.

The three major features that will be exercised are:

Connecting
Issuing a credential
Verifying a credential

Connecting

Call the Invitation API

To connect, one agent must issue an invitation to the other. Generally, the server agent issues an invitation to the mobile agent by displaying an invitation URL encoded in a QR code.

Use the following API endpoint: .
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 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: .
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

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

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 section.
Use the following API endpoint with the correct ID in the URL: .
Set your x-api-key header to: 9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW

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.

Proven Webhook Documentation

Webhooks provide real-time notifications about events on Proven agents. They are delivered as HTTP POST requests to a configured endpoint.

API Reference

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

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

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

Subwallet super Admin role only

Authenticate with base API key

Basic Messages

Endpoints for sending and retrieving basic messages

Connections

Endpoints for managing connections

Context

Endpoints for managing contexts

Credentials

Endpoints for issuing and retrieving credentials

DIDs

Endpoints for managing Decentralized Identifiers (DIDs)

Email

Endpoints for email verification

Governance

Endpoints for fetching governance files

Invitations

Endpoints for creating and managing invitations

Indicio Proven API Tutorial

This tutorial goes through a series of steps to exercise a few of the key features of the Proven API and help you begin to construct your own workflows.

The three major features that will be exercised are:

Connecting
Issuing a credential
Verifying a credential

Connecting

Call the Invitation API

To connect, one agent must issue an invitation to the other. Generally, the server agent issues an invitation to the mobile agent by displaying an invitation URL encoded in a QR code.

Use the following API endpoint: .
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 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: .
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

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.

Use the following API endpoint: .
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

The API will respond with something similar to the following:

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.

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 section.
Use the following API endpoint with the correct ID in the URL: .
Set your x-api-key header to: 9^2m@qw2w885dKXxaup6TQ&CQT4@=RNW

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.

Proven User Guide

Home

Invitations

This selection just shows a list of all invitation QR codes that have been generated by this instance of Proven.

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.
Created At: the date and time the invitation was sent.

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

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

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.
1. Edit the user’s name or email.

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.

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.

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

Click Save when all desired changes are made

SD-JWT VCs

Issuance

Create Credential-Supported (Schema):

Before issuing a credential, you will need to create the “blueprint” (AKA class, schema, credential-type, etc.). See the following code example.

Example curl Command:

curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/credentials-supported' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "format": "vc+sd-jwt",
  "id": "IDCard",
  "format_data": {
      "vct": "ExampleIDCard",
      "claims": {
          "given_name": {
              "mandatory": true,
              "value_type": "string"
          },
          "family_name": {
              "mandatory": true,
              "value_type": "string"
          },
          "something_nested": {
              "key1": {
                  "key2": {
                      "key3": {
                          "mandatory": true,
                          "value_type": "string"
                      }
                  }
              }
          },
          "age_equal_or_over": {
              "12": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "14": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "16": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "18": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "21": {
                  "mandatory": true,
                  "value_type": "boolean"
              },
              "65": {
                  "mandatory": true,
                  "value_type": "boolean"
              }
          }
      }
  },
  "vc_additional_data": {
      "sd_list": [
          "/given_name",
          "/family_name",
          "/age_equal_or_over/12",
          "/age_equal_or_over/14",
          "/age_equal_or_over/16",
          "/age_equal_or_over/18",
          "/age_equal_or_over/21",
          "/age_equal_or_over/65"
      ]
  }
}'

Request:

format {string}: The format of the credential. Will always be vc+sd-jwt for issuing SD-JWTs.
id {string}: The name of the credential (unique to Proven).
format_data.cryptographic_binding_methods_supported {object}: Not currently in use; should be ignored.
format_data.display {object}: Not currently in use; should be ignored.
format_data.vct {object}: String or url that identifies the type of SD-JWT.
format_data.claims {object}: An object with the body of your credential. The mandatory (optional) field signifies if the field is required to issue the credential. The value_type (optional) is the data_type of the field. It can accept the following types: string, number, and image media types such as image/jpeg as defined in IANA media type registry for images (). Other values may also be used.
vc_additional_data.sd_list {array}: Paths to values that can be asked for specifically and/or omitted. If the path to a value is not in the sd_list, then the value will be present each time that credential is presented.

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

After creating the credential supported, you will see a supported_cred_id. Make sure to copy it, as you will need it in the following step.
Now that you have your credential_supported record, you will be able to issue credentials using that credential_supported.

supported_cred_id {string}: This is the supported_cred_id you copied from the previous step.
credential_subject {object}: It should match your credential_supported.format_data.claims object from the previous step. However, instead of having an object with value_type or mandatory, you will have the key equal to the value.

In the response you will see an offer_uri. This can be either turned into a QR code or put into the SDK to accept the offer and receive the credential. If you hit the GET https://{{host}}/api/v1/oid4vci/exchanges endpoint, then you will be able to check on the status of your credential request.

Before you can present a credential, you will need to create the “blueprint” (AKA class, schema, credential-type, etc.). Use the following example to complete the step.

pres_def.purpose {string}: Enter a useful description of this presentation definition.
pres_def.id: This is a unique UUID for presentation definition.
pres_def.input_descriptors {array}: This is an array of credentials you will need for this presentation.

After creating the presentation definition, you will see a pres_def_id. Make sure to copy it, as you will need it in the following step.

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

pres_def_id {string}: Copy the pres_def_id from the previous step.
Keep the rest of this request the same.

In the response, you will see a request_uri. This can be either turned into a QR code or put into the SDK to accept the presentation and send the credential. If you hit the GET https://{{host}}/api/v1/oid4vp/presentations endpoint, then you will be able to check on the status of your credential presentation.

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

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

mdoc/mDL

Proven and the Holdr SDK provide the capability to issue, hold, and verify credentials in the mdoc/mDL format over a variety of protocols. The following documentation describes how to use Proven for the server portions of mdoc/mDL workflows.

There are currently four categories of APIs for working with mdoc/mDL credentials over OID4VC: Keys, Schemas, Issuance, and Verification. These categories of APIs should be approached sequentially, e.g. it doesn't work to use the verification APIs if you haven't configured keys.

Keys

Key Initialization

Provision mDoc issuer key material so that you can securely issue mdoc and mDL credentials.

Example curl Command:

curl --location 'https://buckets4life.share.zrok.io/api/v1/oid4vci/setup/mdoc' \
--header 'x-api-key: HuNsaIP9w0LsM5vqRhWprqLShgWLvb2yMAyuYUjWqd4=' \
--header 'Content-Type: application/json' \
--header 'Cookie: sessionId=s%3AIxantPaS5ZGMmrHZDetRQHQIVTRBiNBL.DAjBpQO8pxrjJdM4jQUYJU%2FlxzGAGIJcUzM%2FM7zltk0' \
--data '{
  "force": false 
}'

Request (POST)

force {boolean}: Whether to force the creation of a new key or not. Use false for first-time initialization or in case you don't want to overwrite the key (if one exists). Use true to rotate the key.

Response

key_id {string}: This string will allow you to identify the key that the system is using for mdoc, allowing you assess the state of the system (e.g., are we still using the same key as 6 months ago?). Useful to save. Sample: 8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001
cert_id {string}: This string will allow you to identify the certificate that the system is using to identify itself to other entities, allowing you to assess the state of the system (e.g. is this the endpoint or agent I think it is?). Useful to save. Sample: 6af84a3c-b6e9-4b1c-844a-6ce6a1f2d002
message {string}: Human readable text that describes the result of the operation (e.g., mDoc issuer keys provisioned successfully). Sample: mDoc issuer keys provisioned successfully.

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

No request body or parameters.

keys {array of objects}: The key(s) currently provisioned for mdoc issuance. Each object contains:
- key_id {string}: The identifier of the provisioned key. Sample: 8d3e8f18-5e7d-4f1a-a72b-1db2f1d0c001
- cert_id

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

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

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

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

Verification is a multi-step process. First, you create a presentation definition that describes what claims you want to verify. Then, you use that definition to create a presentation request, which generates a URI that can be delivered to a holder's wallet (e.g., as a QR code). Finally, after the holder responds, you retrieve the presentation results.

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

pres_def {object}: The presentation definition object, following the DIF Presentation Exchange specification.

id {string}: An optional identifier for the presentation definition. If omitted, the system will generate one.
purpose {string}: A human-readable string describing the purpose of the verification request.
input_descriptors {array of objects}: One or more descriptors specifying what credentials and claims are required.

pres_def_id {string}: The system-generated identifier for this presentation definition. Save this — you will need it to create a presentation request. Sample: 42c870ae-b605-4121-b5e3-1e6bb3a00c6f
pres_def {object}: The presentation definition as stored, including any system-generated fields such as id.

Retrieve all presentation definitions registered for your wallet.

No request body or parameters.

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

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

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

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

Only an HTTP status response code is returned.

Use this API to generate a presentation request from a previously created presentation definition. The response includes a URI that can be rendered as a QR code or delivered as a deep link for the holder's wallet to scan.

pres_def_id {string}: The identifier of the presentation definition to use, obtained from Step 1. Sample: 42c870ae-b605-4121-b5e3-1e6bb3a00c6f
vp_formats {object}: The verifiable presentation formats to accept. For mdoc verification, use "mso_mdoc": { "alg": ["ES256"] }.

request_uri {string}: A URL-encoded openid4vp:// URI. This is typically rendered as a QR code or deep link for the holder's wallet to scan or tap. Sample: openid4vp://?client_id=did%3Ajwk%3A...&request_uri=https%3A//example/oid4vc/tenant/.../oid4vp/request/43050ce4-bfb4-4454-b5de-9bbd1c564a85
request {object}: The presentation request record.

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

Optional query parameters:

sort-field {string}: The field to sort by (default updated_at).
sort-direction {string}: Sort direction, ASC or DESC (default DESC).

params {object}: The pagination and filter parameters applied to the query.
rows {array of objects}: The presentation records. Key fields on each record include:
- presentation_exchange_id {string}: Unique identifier for the presentation exchange.

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.

KYC

Field: given_names

Field Type: String
Description: Customer's first and middle names

Field: gender_legal

Field Type: M for male, F for female, or X for not specified
Description: Individual's sex.

Field Type: String
Description: Name of the credit score agency

Field Type: Unix timestamp UTC
Description: Date of experiation for id.

Field Type: String
Description: Previous employer's name of a customer

Field Type: Yes or No
Description: Indicate whether extended due diligence has been performed.

Field Type: Unix timestamp UTC
Description: Date of Birth

Field Type: String
Description: Rate of risk

Field Type: Yes or No
Description: Indicate whether standard due diligence has been performed.

Field Type: Alpha-Numeric
Description: Postal code of a customer address

Field Type: Yes or No
Description: Mark if an account is verified or not

Field Type: Integer
Description: Annual volume of a customer's income

Field Type: Integer
Description: Current amount of accounts balances

Field Type: String
Description: Current employer's name of a customer

Field Type: Unix timestamp UTC
Description: Credential's date of issuance

Field Type: String
Description: Type of an identity document

Field Type: String
Description: Customer address proving method

Field Type: Yes or No
Description: Mark if the previous employment of a customer is verified or not

Field Type: Unix timestamp UTC
Description: Date of the first working day

Field Type: Alpha-Numeric
Description: A number that must uniquely identify a particular document issued to a customer.

Field Type: Unix timestamp UTC
Description: Date of the first working day at the previous place of work

Field Type: Yes or No
Description: Mark if the current employment of a customer is verified or not

Field Type: String
Description: Family last name or surname

Field Type: Integer
Description: Customer's phone number

Field Type: String
Description: Customer's email

Field Type: String
Description: Customer state, province or region code

Field Type: Integer
Description: Customer credit score

Field Type: Yes or No
Description: Mark the status if blacklists checked or not

Field Type: Integer
Description: Average amount of accounts balances for 6 month

Field Type: String
Description: Customer's street address

Field Type: Yes or No
Description: Mark if customer address is verified or not

Field Type: String
Description: Customer income currency

Field Type: String
Description: Customer city name

Field Type: Yes or No
Description: Mark if customer income is verified or not

Field Type: String with encoded .jpg or .jp2 passport image
Description: A color photo of customer

Some attributes are part of the underlying ARIES Credential Protocol. For example the following values are associated with the credential

"schema_id": string, identifier of schema
"cred_def_id": string, identifier of credential definition, which includes the issuer's DID

Driver's License

Field: document_type_indicator

Field Type: text
Description: Type of record being issued.
Examples: DRIVING LICENSE, LEARNING PERMIT, IDENTIFICATION CARD, or COMERRICAL DRIVER's LICENSE

Field: surname

Field Type: text
Description: Family last name or surname

Field Type: text
Description: First and middle names

Field Type: Unix timestamp UTC
Description: Date of Birth

Field Type: Unix timestamp UTC
Description: Date of issuance for Driver's License

Field Type: Unix timestamp UTC
Description: Date of experiation for Driver's License

Field Type: text
Description: The authorized agent orgnization that issues driver licenses and/or idnetification cards

Field Type: Alpha-Numeric
Description: An id that uniquely identifies the individual by the issuing authority

Field Type: numeric
Description: A number that must uniquely identify a particular document issued to an individual.

Field Type:
Description: A color photo of the individual

Field Type:
Description: The signature of the individual

Field Type: text
Description: Street address including apartment number of individual

Field Type: text
Description: City of individual

Field Type: text;
Description: State, province, or region code of individual

Field Type: Alpha-Numeric
Description: Postal code of address of individual

Field Type: text;
Description: Code of country of address of individual

Field Type: text; comma separated list with space
Description: Vehicle types the driver is authorized to operate
Example: A, D

Field Type: text; comma separated list with space
Description: Codes specifying additional privileges granted to the individual
Example: M, S

Field Type: text; comma separated list
Description: Codes used to indicate restrictions or conditions that apply to the individual. If no restrictions or conditions apply to the individual, "NONE" shall be indicated.
Example: corrective lenses, sunrise to sunset driving only

Field Type: M for male, F for female, or X for not specified
Description: Individual's sex

Field Type: numeric
Description: The individual's height in inches. It is recommended that if height_cm exists, that height_inches exist.
Example: 73

Field Type: numeric
Description: The individual's height in cm. It is recommended that if height_inches exists, that height_cm exist.
Example: 185

Field Type: text
Description: The individual's eye color
Example: brown

Field Type: text
Description: The individual's hair color
Example: brown

Field Type: text
Description: The individual's place of birth
Example: New York, USA

Field Type: Colon, semicolon list with spaces. Date is stored in Unix timestamp UTC.
Description: Category date of first issue
Example: D:unavail ; C:1633932000

Field Type: Colon, semicolon list with spaces. Date is stored in Unix timestamp UTC.
Description: Category date of expiry
Example: D:1633932000 ; C:1633932000

Field Type: numeric
Description: The individual's weight in pounds. It is recommended that if weight_kilograms exists, that weight_pounds exist.
Example: 185

Field Type: numeric
Description: The individual's height in cm. It is recommended that if weight_pounds exists, that weight_kilograms exist.
Example: 84

Field Type: text
Description: The individual's race

Field Type: Alpha-Numeric
Description: Letters and/or numbers that identifies when, where, and by whom the license / ID card was made.

Field Type: Use the appropriate two-character code
Description: The issuing jurisdiction. The may provide examples of issuing jurisidictions.

Field Type: text
Description: If the individual is an Organ Donor. ORGAN DONOR is to be explictly spelled out so there is no ambiguity to the individual their status, otherwise the field should be left blank.
Example: ORGAN DONOR

Field Type: text
Description: The word "VETERAN" is required.
Example: VETERAN

Field Type: text
Description: F = compliant. (Required for DHS Compliant licenses)
Example: F

Field Type: MMDDCCYY
Description: (Required for DHS Compliant licenses)
Example: 09302010

Field Type: Unix timestamp UTC
Description: Hazmat endorsement expiration date

Field Type: text
Description: (Required for DHS Compliant licenses)
Example: 1

Some attributes are part of the underlying ARIES Credential Protocol. For example the following values are associated with the credential

"schema_id": string, identifier of schema
"cred_def_id": string, identifier of credential definition, which includes the issuer's DID

Indicio Proven API Documentation

General Information

HTTP Headers

All “v1” APIs require an “x-api-key” header to be set on the request. The “x-api-key” is not just used for authorization; it’s also used to determine which wallet will complete the request.

Wallet ID

Proven supports a multi-tenant environment by default, even if you only intend to use a single wallet for this installed agent. Each wallet is identified by a wallet ID. Because these wallet IDs are linked to the API key(s) you will create, you don’t have to pay close attention to the wallet ID when using the API.

Multi-Tenancy

Proven can support multiple instances and various configurations of decentralized identity software on a single machine. Each software installation is referred to as an agent, and each logical subdivision of the software is referred to as a wallet; in other words, one installation can be configured to act as several independent copies of decentralized identity software. This concept of having multiple software units running independently on the same machine is called multi-tenancy.

Proven manages multi-tenancy by associating each wallet with a user group and allowing the administrator to assign users to groups (and thereby wallets). Thus, each installation can have multiple wallets, multiple users per wallet, and multiple wallets per user.

Wallet authentication in Proven is handled via OpenID Connect, and the user's group is determined by the IAM service (Keycloak is the default for Proven). The IAM service provides the user's group and permissions, which Proven uses to determine the appropriate wallet for the user's operations.

Managing Wallets

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:
1. Select the “Indicio Proven Realm”
2. Click on “Groups” in the left menu
3. Click on the “Create group” button and name the group. The group name must match the wallet name that was created

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

In addition to an administrative UI, Proven offers an API for the programmatic execution of agent operations. Its OpenAPI specification can be found at of the server you are working with.

Proven uses API keys to authenticate requests to the API and authorize the API user's access to the requested resource. Proven uses the API key to determine the user's group and permissions, which are used to determine the appropriate wallet for the user's operations.

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

To create a new API key, you will need the base wallet API key. The base wallet API key is used to create wallets and their associated API keys. It can be found in the .env file as PROVEN_API_KEY.

Once you have the base wallet API key, you will need to be authorized before you can create new API keys.

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:

get

This endpoint retrieves all connections.

Authorizations

x-api-keystringRequired

Query parameters

sort-fieldstringOptional

The field to sort by (default updated_at).

sort-directionstringOptional

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

page-sizeintegerOptional

The number of connections per page (default 20).

current-pageintegerOptional

The current page number (default 1).

item-countintegerOptional

The total number of items.

state-filterstringOptional

If provided, returns only connections with this state.

contact-idstringOptional

If provided, returns only connections for this contact_id.

Responses

200

A list of connections

application/json

sortstring[]Optional

pageSizestringOptional

currentPageintegerOptional

pageCountintegerOptional

itemCountintegerOptional

stateFilterstring · nullableOptional

contactIdFilterstring · nullableOptional

connection_idstringOptional

statestringOptional

my_didstringOptional

aliasstringOptional

request_idstringOptional

invitation_keystringOptional

invitation_msg_idstringOptional

invitation_modestringOptional

invitation_urlstringOptional

@typestringOptional

@idstringOptional

labelstringOptional

handshake_protocolsstring[]Optional

idstringOptional

typestringOptional

recipientKeysstring[]Optional

serviceEndpointstringOptional

acceptstringOptional

initiatorstringOptional

their_rolestringOptional

their_didstringOptional

their_public_didstringOptional

their_labelstringOptional

routing_statestringOptional

inbound_connection_idstringOptional

error_msgstringOptional

contact_idstringOptional

transaction_rolestringOptional

pidstringOptional

rolesstring[]Optional

wallet_idstringOptional

created_atstringOptional

updated_atstringOptional

401

Unauthorized.

No content

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

get/api/v1/connections

GET /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
}

get

This endpoint retrieves a connection by its id.

Authorizations

x-api-keystringRequired

Path parameters

connection_idstringRequired

The connection id of the connection to retrieve.

Responses

200

Connection record retrieved successfully

application/json

connection_idstringOptional

statestringOptional

my_didstringOptional

aliasstringOptional

request_idstringOptional

invitation_keystringOptional

invitation_msg_idstringOptional

invitation_modestringOptional

invitation_urlstringOptional

@typestringOptional

@idstringOptional

labelstringOptional

handshake_protocolsstring[]Optional

idstringOptional

typestringOptional

recipientKeysstring[]Optional

serviceEndpointstringOptional

acceptstringOptional

initiatorstringOptional

their_rolestringOptional

their_didstringOptional

their_public_didstringOptional

their_labelstringOptional

routing_statestringOptional

inbound_connection_idstringOptional

error_msgstringOptional

contact_idstringOptional

transaction_rolestringOptional

pidstringOptional

rolesstring[]Optional

wallet_idstringOptional

created_atstringOptional

updated_atstringOptional

401

Unauthorized.

No content

404

Connection not found

application/json

errorstringOptionalExample: Connection record not found

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

get/api/v1/connections/{connection_id}

GET /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"
  }
}

post

This endpoint creates a new invitation of type OOB.

Authorizations

x-api-keystringRequired

Body

invitation_typestringRequired

The type of the invitation (OOB).

Default: OOB

contact_idstringOptional

The ID of the contact.

Default: undefined

handshake_protocolstringOptional

The handshake protocol for OOB invitations.

Default: undefined

aliasstringOptional

The alias for the invitation.

Default: undefined

invitation_modestringOptional

The mode of the invitation.

Default: undefined

acceptstringOptional

The accept criteria for the invitation.

Default: true

publicbooleanOptional

Whether the invitation is public.

Default: false

invitation_rolestringOptional

The role of the invitation.

Default: undefined

invitation_labelstringOptional

The label of the invitation.

Default: undefined

invitation_statusstringOptional

The status of the invitation.

Default: undefined

invitation_descriptionstringOptional

The description of the invitation.

Default: undefined

purposestringOptional

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

Default: undefined

invitation_active_starting_atstring · date-timeOptional

The start time of the invitation's active period.

Default: undefined

invitation_active_ending_atstring · date-timeOptional

The end time of the invitation's active period.

Default: undefined

uses_allowednumberOptional

The number of uses allowed for the invitation.

Default: undefined

Responses

200

Invitation created successfully

application/json

invitation_urlstringOptionalExample:

https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl19

invitation_idintegerOptionalExample: 1

contact_idstringOptional

400

Bad Request

application/json

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

401

Unauthorized.

No content

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

post/api/v1/invitations

POST /api/v1/invitations HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: */*
Content-Length: 422

{
  "contact_id": "",
  "alias": "API Invitation",
  "invitation_type": "OOB",
  "handshake_protocol": "https://didcomm.org/didexchange/1.1",
  "invitation_mode": "once",
  "accept": "auto",
  "public": false,
  "invitation_role": "Holder",
  "invitation_label": "OOB",
  "invitation_status": "active",
  "invitation_description": "Invitation created through API",
  "purpose": "",
  "invitation_active_starting_at": null,
  "invitation_active_ending_at": null,
  "uses_allowed": 1
}

{
  "invitation_url": "https://fresh-fox-61.tun2.indiciotech.io?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICIzMzAyMDMyZC05MTA4LTQ4YzMtYmM3ZC1mZjZiNzU1ZDcyMmQiLCAibGFiZWwiOiAiT09CIiwgImhhbmRzaGFrZV9wcm90b2NvbHMiOiBbImh0dHBzOi8vZGlkY29tbS5vcmcvZGlkZXhjaGFuZ2UvMS4xIl0sICJzZXJ2aWNlcyI6IFsiZGlkOnNvdjo5NUxBeVFpdE5oNWtWYWF5Q0ZDOVMyIl19",
  "invitation_id": 1,
  "contact_id": ""
}

post

This endpoint issues JSON-LD credentials.

Authorizations

x-api-keystringRequired

Query parameters

timeoutintegerOptional

The timeout for the credential issuance (seconds).

Example: 30

Body

invitation_idnumber · nullableOptional

The invitation ID.

Example: 1

contact_idstring · nullableOptional

The contact ID.

revocation_def_idstring · nullableOptional

The ID of status list definition to enable revocation

@contextstring[]Optional

The contexts of the credential.

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

issuanceDatestring · date-timeOptional

The issuance date of the credential.

Example: 2024-11-29T21:07:11Z

validFromstring · date-timeOptional

The valid from date of the credential.

Example: 2024-11-29T11:34:20Z

awardedDatestring · date-timeOptional

The awarded date of the credential.

Example: 2024-11-29T21:07:11Z

expirationDatestring · date-timeOptional

The expiration date of the credential.

Example: 2030-11-29T11:34:20Z

validUntilstring · date-timeOptional

The valid until date of the credential.

Example: 2030-11-29T11:34:20Z

typestring[]Optional

The types of the credential.

Example: ["OpenBadgeCredential"]

descriptionstringOptional

The description of the credential.

Example: Awesome Credential Description

namestringOptional

The name of the credential.

Example: New Awesome JSON-LD Credential

idstringOptional

The identifier of the issuer

Example: did:indy:<namespace>:5uF3EGLPkBccqMhEfX2JS8

typestring[]Optional

The types of the issuer.

Example: ["Profile"]

namestringOptional

The name of the issuer.

Example: Awesome Issuer Name

descriptionstringOptional

The description of the issuer.

Example: An awesome Issuer who Issues awesome credentials.

urlstringOptional

The URL of the issuer.

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

emailstringOptional

The email of the issuer.

Example: issuer-contact@example.org

idstringOptional

The ID of the image.

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

typestringOptional

The type of the image.

Example: Image

captionstringOptional

The caption of the image.

Example: Awesome Issuer Logo

typestring[]Optional

The types of the credential subject.

Example: ["AchievementSubject"]

idstringOptional

The ID of the achievement.

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

namestringOptional

The name of the achievement.

Example: Your name

descriptionstringOptional

The description of the achievement.

Example: Your description

typestringOptional

The type of the criteria.

Example: Criteria

narrativestringOptional

The narrative of the criteria.

Example: Your narrative

idstringOptional

The ID of the image.

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

typestringOptional

The type of the image.

Example: Image

typestring[]Optional

The types of the achievement.

Example: ["Achievement"]

proofTypestringOptional

The proofType for the credential issuance

Example: Ed25519Signature2020

rulestringOptional

The rule for the credential issuance.

Example: string

Responses

200

JSON-LD credential issued successfully

application/json

recordobjectOptional

400

Bad Request

application/json

errorstringOptionalExample: string

401

Unauthorized.

No content

422

Unprocessable Entity.

application/json

errorstringOptionalExample: string

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error.

post/api/v1/credentials/json-ld

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

post

This endpoint allows you to trigger an AnonCred verification flow.

Authorizations

x-api-keystringRequired

Query parameters

timeoutintegerOptional

The timeout for the verification (seconds).

Example: 30

Body

invitation_idinteger · nullableOptional

The ID of the invitation.

contact_idstringOptional

The ID of the contact.

schema_idstringOptional

The ID of the schema.

restrictionsobject[]Optional

raceobjectOptional

rulestringOptional

The rule for the verification.

Responses

200

AnonCred verification flow triggered successfully

application/json

verification_idintegerOptional

The ID of the verification

Example: 1

connection_idstring · nullableOptional

The connection ID

Example: bd8d1663-38ac-46c8-9314-7d26bf731c88

contact_idstringOptional

The contact ID

invitation_idinteger · nullableOptional

The invitation ID

Example: 1

schema_idstring · nullableOptional

The schema ID

schema_attributesobjectOptional

The schema attributes for verification

wallet_idstringOptional

The wallet ID

Example: 70b6a0d2-628a-4de6-af96-144100f74878

rulestringOptional

The verification rule

Example: no rule

meta_dataobject · nullableOptional

Additional metadata

statestring · nullableOptional

The verification state

Example: done

completebooleanOptional

Whether verification is complete

Example: false

resultbooleanOptional

The verification result

Example: false

result_stringstringOptional

Human readable verification result

Example: Pending

namestringOptional

valuestringOptional

presentation_exchange_idstring[]Optional

Presentation exchange IDs

errorstringOptional

Error message if any

created_atstring · date-timeOptional

Creation timestamp

Example: 2025-07-08T21:54:59.969Z

updated_atstring · date-timeOptional

Update timestamp

Example: 2025-07-08T21:55:01.017Z

400

Bad request.

application/json

errorstringOptionalExample: string

401

Unauthorized.

No content

500

Internal server error

application/json

errorstringOptionalExample: Internal server error

post/api/v1/verifications

POST /api/v1/verifications HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: */*
Content-Length: 167

{
  "invitation_id": 1,
  "contact_id": "",
  "schemas": [
    {
      "schema_attributes": {
        "domain": {
          "restrictions": [
            {
              "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0"
            }
          ]
        }
      }
    }
  ],
  "rule": "no rule"
}

{
  "verification_id": 1,
  "connection_id": "bd8d1663-38ac-46c8-9314-7d26bf731c88",
  "contact_id": "",
  "invitation_id": 1,
  "schema_id": null,
  "schema_attributes": {
    "domain": {
      "restrictions": [
        {
          "schema_id": "E8BS9Fcg3cu2m9Dwaa3hVG:2:Email:1.0"
        }
      ]
    }
  },
  "wallet_id": "70b6a0d2-628a-4de6-af96-144100f74878",
  "rule": "no rule",
  "meta_data": null,
  "state": null,
  "complete": false,
  "result": false,
  "result_string": "Pending",
  "result_data": null,
  "presentation_exchange_id": [
    "531298a5-31a6-4f2b-9dec-80c8c9e1d9de"
  ],
  "error": "",
  "created_at": "2025-07-08T21:54:59.969Z",
  "updated_at": "2025-07-08T21:55:01.017Z"
}

get

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

Authorizations

x-api-keystringRequired

Path parameters

verification_idstringRequired

The ID of the verification.

Example: 1

Responses

200

JSON-LD verification record retrieved successfully

application/json

verification_idintegerOptional

The ID of the verification

Example: 1

connection_idstring · nullableOptional

The connection ID

Example: bd8d1663-38ac-46c8-9314-7d26bf731c88

contact_idstringOptional

The contact ID

invitation_idinteger · nullableOptional

The invitation ID

Example: 1

schema_idstring · nullableOptional

The schema ID

schema_attributesobjectOptional

The schema attributes for verification

wallet_idstringOptional

The wallet ID

Example: 70b6a0d2-628a-4de6-af96-144100f74878

rulestringOptional

The verification rule

Example: no rule

meta_dataobject · nullableOptional

Additional metadata

statestring · nullableOptional

The verification state

Example: done

completebooleanOptional

Whether verification is complete

Example: false

resultbooleanOptional

The verification result

Example: false

result_stringstringOptional

Human readable verification result

Example: Pending

namestringOptional

valuestringOptional

presentation_exchange_idstring[]Optional

Presentation exchange IDs

errorstringOptional

Error message if any

created_atstring · date-timeOptional

Creation timestamp

Example: 2025-07-08T21:54:59.969Z

updated_atstring · date-timeOptional

Update timestamp

Example: 2025-07-08T21:55:01.017Z

400

Bad request.

application/json

errorstringOptionalExample: string

401

Unauthorized.

No content

404

JSON-LD verification record not found

application/json

errorstringOptionalExample: JSON-LD verification record not found

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

get/api/v1/verifications/json-ld/{verification_id}

GET /api/v1/verifications/json-ld/{verification_id} HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*

{
  "verification_id": 1,
  "connection_id": "1c50d6e1-5a43-48d8-837e-be3cbc815469",
  "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": [
    "validFrom",
    {
      "issuer": "name"
    },
    {
      "credentialSubject": {
        "achievement": "criteria"
      }
    }
  ],
  "wallet_id": "19fa3524-2859-43e2-ac48-2136c9d8a199",
  "label": "Awesome JSON-LD Credential",
  "rule": "no rule",
  "meta_data": null,
  "state": "done",
  "complete": true,
  "result": true,
  "result_string": "Verified",
  "result_data": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
        "https://www.w3.org/ns/credentials/status/v1",
        "https://w3id.org/security/suites/ed25519-2020/v1"
      ],
      "id": "urn:uuid:e67ecd34-2891-45c5-85bd-84d1e34c0653",
      "type": [
        "VerifiableCredential",
        "OpenBadgeCredential"
      ],
      "issuer": {
        "id": "did:indy:indicio:test:JKdq87RF5kEsfv7b8BAdqs",
        "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."
      },
      "issuanceDate": "2024-11-29T21:07:11Z",
      "expirationDate": "2030-11-29T11:34:20Z",
      "validFrom": "2024-11-29T11:34:20Z",
      "validUntil": "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"
        },
        "id": "did:key:z6MkfsAwW9KmjuMGjeKzYnZ9APMoa6StVxpm9TR91XZYHBKJ"
      },
      "credentialStatus": {
        "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"
      },
      "proof": {
        "type": "Ed25519Signature2020",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:indy:indicio:test:JKdq87RF5kEsfv7b8BAdqs#assert",
        "created": "2025-07-09T19:28:03.680Z",
        "proofValue": "z2BjheUpL2P77hWdd1Snhw94vJzeuUoze5DTCjeHoAgYB2agA4dF1K4s3wdB2JCRS7yoXhGsk63xVBQw6aGnYV6H8"
      },
      "name": "New Awesome JSON-LD Credential",
      "awardedDate": "2024-11-29T21:07:11Z",
      "description": "Awesome Credential Description"
    }
  ],
  "presentation_exchange_id": [
    "188aba4f-7fc9-4040-93fd-37530fa46027"
  ],
  "error": "",
  "created_at": "2025-07-09T19:30:24.271Z",
  "updated_at": "2025-07-09T19:30:38.964Z"
}

post

This endpoint allows you to trigger a JSON-LD verification flow.

Authorizations

x-api-keystringRequired

Query parameters

timeoutintegerOptional

The timeout for the verification (seconds).

Example: 30

Body

invitation_idintegerOptional

The ID of the invitation.

Example: 1

contact_idstringOptional

The ID of the contact.

contextstring[]Optional

A list of context strings.

Example:

["https://www.w3.org/2018/credentials#VerifiableCredential","https://www.w3.org/2018/credentials/v1","https://purl.imsglobal.org/spec/vc/ob/vocab.html#OpenBadgeCredential"]

stringOptional

Other propertiesanyOptional

labelstringOptional

The label for the definition.

Example: Awesome JSON-LD Credential

rulestringOptional

The rule for the verification.

Example: no rule

Responses

200

Verification was triggered

application/json

verification_idintegerOptional

The ID of the verification

Example: 1

connection_idstring · nullableOptional

The connection ID

Example: bd8d1663-38ac-46c8-9314-7d26bf731c88

contact_idstringOptional

The contact ID

invitation_idinteger · nullableOptional

The invitation ID

Example: 1

schema_idstring · nullableOptional

The schema ID

schema_attributesobjectOptional

The schema attributes for verification

wallet_idstringOptional

The wallet ID

Example: 70b6a0d2-628a-4de6-af96-144100f74878

rulestringOptional

The verification rule

Example: no rule

meta_dataobject · nullableOptional

Additional metadata

statestring · nullableOptional

The verification state

Example: done

completebooleanOptional

Whether verification is complete

Example: false

resultbooleanOptional

The verification result

Example: false

result_stringstringOptional

Human readable verification result

Example: Pending

namestringOptional

valuestringOptional

presentation_exchange_idstring[]Optional

Presentation exchange IDs

errorstringOptional

Error message if any

created_atstring · date-timeOptional

Creation timestamp

Example: 2025-07-08T21:54:59.969Z

updated_atstring · date-timeOptional

Update timestamp

Example: 2025-07-08T21:55:01.017Z

400

Bad request.

application/json

errorstringOptionalExample: string

401

Unauthorized.

No content

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

post/api/v1/verifications/json-ld

POST /api/v1/verifications/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: 384

{
  "invitation_id": 1,
  "contact_id": "",
  "definitions": [
    {
      "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": [
        "validFrom",
        {
          "issuer": "name"
        },
        {
          "credentialSubject": {
            "achievement": "criteria"
          }
        }
      ],
      "label": "Awesome JSON-LD Credential"
    }
  ],
  "rule": "no rule"
}

{
  "verification_id": 1,
  "connection_id": "1c50d6e1-5a43-48d8-837e-be3cbc815469",
  "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": [
    "validFrom",
    {
      "issuer": "name"
    },
    {
      "credentialSubject": {
        "achievement": "criteria"
      }
    }
  ],
  "wallet_id": "19fa3524-2859-43e2-ac48-2136c9d8a199",
  "label": "Awesome JSON-LD Credential",
  "rule": "no rule",
  "meta_data": null,
  "state": "done",
  "complete": true,
  "result": true,
  "result_string": "Verified",
  "result_data": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://purl.imsglobal.org/spec/ob/v3p0/context-3.0.3.json",
        "https://www.w3.org/ns/credentials/status/v1",
        "https://w3id.org/security/suites/ed25519-2020/v1"
      ],
      "id": "urn:uuid:e67ecd34-2891-45c5-85bd-84d1e34c0653",
      "type": [
        "VerifiableCredential",
        "OpenBadgeCredential"
      ],
      "issuer": {
        "id": "did:indy:indicio:test:JKdq87RF5kEsfv7b8BAdqs",
        "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."
      },
      "issuanceDate": "2024-11-29T21:07:11Z",
      "expirationDate": "2030-11-29T11:34:20Z",
      "validFrom": "2024-11-29T11:34:20Z",
      "validUntil": "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"
        },
        "id": "did:key:z6MkfsAwW9KmjuMGjeKzYnZ9APMoa6StVxpm9TR91XZYHBKJ"
      },
      "credentialStatus": {
        "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"
      },
      "proof": {
        "type": "Ed25519Signature2020",
        "proofPurpose": "assertionMethod",
        "verificationMethod": "did:indy:indicio:test:JKdq87RF5kEsfv7b8BAdqs#assert",
        "created": "2025-07-09T19:28:03.680Z",
        "proofValue": "z2BjheUpL2P77hWdd1Snhw94vJzeuUoze5DTCjeHoAgYB2agA4dF1K4s3wdB2JCRS7yoXhGsk63xVBQw6aGnYV6H8"
      },
      "name": "New Awesome JSON-LD Credential",
      "awardedDate": "2024-11-29T21:07:11Z",
      "description": "Awesome Credential Description"
    }
  ],
  "presentation_exchange_id": [
    "188aba4f-7fc9-4040-93fd-37530fa46027"
  ],
  "error": "",
  "created_at": "2025-07-09T19:30:24.271Z",
  "updated_at": "2025-07-09T19:30:38.964Z"
}

post

This endpoint fetches the Transaction Author Agreement (TAA) using the provided API key.

Authorizations

x-api-keystringRequired

Responses

200

TAA fetched successfully

application/json

taaobjectOptional

The fetched TAA.

401

Unauthorized.

No content

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

post/api/v1/fetch-taa

POST /api/v1/fetch-taa HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Accept: */*

{
  "aml_record": {
    "aml": {
      "at_submission": "The agreement was reviewed by the user and accepted at the time of submission of this transaction.",
      "for_session": "The agreement was reviewed by the user and accepted at some point in the user’s session prior to submission.",
      "on_file": "An authorized person accepted the agreement, and such acceptance is on file with the user’s organization.",
      "product_eula": "The agreement was included in the software product’s terms and conditions as part of a license to the end user.",
      "service_agreement": "The agreement was included in the terms and conditions the user accepted as part of contracting a service.",
      "wallet_agreement": "The agreement was reviewed by the user and this affirmation was persisted in the user’s wallet for use during submission."
    },
    "amlContext": "https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/TAA/AML.md",
    "version": "1.0"
  },
  "taa_record": {
    "digest": "c965dd01fec099ea95babaea3031bc09905432d3d7f1519bc0b99971aece8592",
    "ratification_ts": 1606435200,
    "text": "Indicio Transaction Author Agreement \n\nVersion 1.3\n\n11/10/2020\n\n**Summary:**\n\nThis summary is to help you understand your obligations when writing to the Indicio Network, which is composed of a TestNet, DemoNet, and MainNet. It does not have any legal effect or replace the full legal text of the agreement provided below it.\n\n\n\n*   We define the Transaction Author role (or any role described in this statement that performs the functions of a Transaction Author) as one of using an application to add transactions to the Indicio Network for the purpose of issuing Credentials.  \n \nCredential issuing transactions include, but may not be limited to, writing Schema and Credential Definitions, unprivileged DIDs, altering DID attributes, creating Revocation Registries, and updating Revocation Registries. \n\n*   This agreement grants you the Transaction Author permission to write data to the Indicio Network and its component Networks, the Indicio TestNet, DemoNet, and MainNet under certain terms and conditions.  \n\n*   You represent and warrant that the data you are writing does not violate any applicable laws or infringe the rights of any other party.\n\n     \n\n*   You understand the data you write to the TestNet and DemoNet is public but not permanent, and in accordance with the Indicio TestNet agreement will be erased by periodic resets of the TestNet and DemoNet. \n\n*   You understand that any data you write to the MainNet is public and permanent and cannot be erased. This includes public keys.  \n\n*   If it is determined that the data you wrote violated this agreement, Indicio can impose penalties, including suspension or termination of this agreement, and may take steps to block public access to this data through creating a Tombstone.  \n\n*   Indicio makes no promises about the reliability or correctness of the data stored on the Indicio Network or the operation of the Indicio Network. \n\n**Agreement.**\n\nThis Transaction Author Agreement (the “**Agreement**”) is entered into on the date you accepted this Agreement (the “**Effective Date**”) between Indicio Inc., a Benefit Corporation organized under the laws of the State of Delaware, United States of America (“**Indicio**”), and you (“**Transaction Author**”), either an entity or a natural person acting as an Individual. \n\nIndicio and the Transaction Author are individually referred to herein as a “Party” and collectively as the “Parties.” All references to “you” throughout this Agreement will include that person or entity. You represent that you are authorized to accept this Agreement on that person’s or entity’s behalf, and in the event you or the person or entity violates this Agreement, the person or entity agrees to be responsible to Indicio. \n\nBy clicking “Accept” or similar or writing Transactions to the Indicio Network, the Transaction Author agrees to be bound by this Agreement and all terms incorporated by reference. If the Transaction Author does not agree to this Agreement in its entirety, do not click “Accept” or write Transactions to the Indicio Network. \n\nIf Indicio makes material changes to this Agreement, we will notify you by posting a notice on our website prior to the effective date of the changes. By continuing to act as a Transaction Author or by otherwise writing Transactions on the Indicio Network after we post changes to our website, you agree to be bound by the revised Agreement. \n\n\nWHEREAS, the Transaction Author desires to write Transactions to the Indicio Network\n\n(each a “**Transaction**”); and \n\nWHEREAS, subject to the Transaction Author complying with the terms and conditions of this Agreement, Indicio grants permission to the Transaction Author to write Transactions to the Indicio Network; \n\nFOR GOOD AND VALUABLE CONSIDERATION, THE SUFFICIENCY OF WHICH IS HEREBY ACKNOWLEDGED, THE PARTIES AGREE AS FOLLOWS: \n\n\n## 1. \tDefinitions\n\n*Pertaining to the network:*\n\n\n\n1. \tThe **Indicio Governance Framework** refers to Indicio’s governance public benefit mission, policies, and rules available at LINK or any successor website.  \n\n\n2. \tThe **Indicio Ledger** is the collective term for all the ledgers on the Indicio Network, including the MainNet, DemoNet, and TestNet, and their sub ledgers, viz., pool, admin, main, config., etc. \n\n\n3. \tThe **Indicio Network** is a public, permissioned network built on Hyperledger Indy, Aries, and Ursa, and consisting of a MainNet, DemoNet, and TestNet. It is run by Indicio—the genesis node operator for the Network—and the Node Operators, of which Indicio is also a member. Public refers to being able to read and permissioned refers to the ability to write to the ledger. \n\n\n*Network terminology:* \n\n\n\n4.\tA **Credential** is a digital assertion containing a set of claims about the identity attributes of an entity (as per IETF RFC 3986, Uniform Resource Identifier (URI), an entity is a resource of any kind that can be uniquely and independently identified). \n\n\n\n5. \tA **Credential Definition** is a machine-readable definition of the semantic structure of a Credential based on one or more Credential Schemas.  \n\n\n\n6. \tA **Credential Schema** is a machine-readable definition of the semantics of data structure. Schemas define the attributes in a Credential Definition.  \n\n\n\n7. \tA **DID** is the acronym for decentralized identifier, a unique, permanent URL for an identity. \n\n\n\n8. \tA **DID** Document is a machine-readable document describing the public cryptographic keys, service endpoints, and other metadata associated with a DID. Each DID points to a unique DID document on a ledger.  \n\n\n\n9. \tA **Revocation Registry** is a cryptographic data structure for recording the revocation of credentials. \n\n\n\n10.\t**Permissioned Write Access** refers to a network state where “Public Write Access” is not permitted. In this state, Transaction Authors may only write transactions with a signature from an approving Transaction Endorser. \n\n\n\n11. **Public Write Access** refers to the state that a network is in when anyone can become a Transaction Author and write to the ledger. The Indicio Network does not, in its present state, allow Public Write Access.\n\n\n12. **Public Read Access** means that anyone can access, audit, read, or download content on the Ledger, although there may be a fee to do so. \n\n\n\n13. A **Tombstone** is a technical means of blocking public access to a ledger record without erasing that record. It is used only in the event of impermissible public data being written to the ledger in violation of Transaction Author and Endorser agreements.   \n\n\n\n14. A **Transaction** refers to the act of writing Schemas and Credential Definitions to the ledger for the purpose of issuing Credentials, creating Revocation Registries for the purpose of revoking credentials, updating Revocation Registries, creating a DID, adding or editing attributes to a DID, and rotating a DID’s key.   \n\n\n\n15. A **Transaction Author** refers to an entity using an application to write records to the Indicio Network for the purpose of issuing credentials. Credential issuing transactions include, but may not be limited to, writing Schema and Credential Definitions, creating Revocation Registries, and updating Revocation Registries. They can also write DID transactions to the ledger including DID creation, attribute creation and editing, and key rotation. \n\n\n\n16. A **Transaction Endorser** refers to an entity that is authorized to approve a Transaction Author write to the ledger. \n\n\n\n17. A **Trustee** refers to a person authorized to administer the governance and maintenance of the network. Multiple Trustee signatures are required to perform certain administrative and maintenance functions.\n\n\n*Pertaining to data privacy:*\n\n\n18. **Data Controller**  is defined by the EU General Data Protection Regulation (GDPR), the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data.\n\n\n19. **Data Processor** is defined by the EU General Data Protection Regulation (GDPR), a natural or legal person, public authority, agency, or other body which processes Personal Data on behalf of a Data Controller**.**\n\n\n20. **Data Protection Laws** mean California’s Consumer Privacy Act (CCPA), the European Union’s General Data Protection Regulation (GDPR), and any other national or international data protection and privacy laws, regulations, and regulatory requirements applicable to a party under this Agreement.  \n\n\n\n21. **Personal Data** means information that relates directly or indirectly to a data subject, including without limitation, names, email addresses, postal addresses, identification numbers, location data, online identifiers, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of the data subject. \n\n\n22. **Node Data** means any information which includes any Personal Data that a Node Operator Processes through the Node.\t\n\n\n23. **Permissible Personal Data** refers to the Personal Data that a Transaction Author writes to the Indicio Network that is permitted under this Agreement and Indicio’s Governance Framework, namely, but not limited to, identification numbers and online identifiers. \n\n\n\n24. **Impermissible Personal Data** refers to personal data that is not covered under Permissible Personal Data and should not be written to the ledger \n\n\n\n25. **Process** or **Processing** means any operation or set of operations that is performed on Transaction data, whether or not by automated means, such as the access, collection, use, storage, disclosure, dissemination, combination, recording, organization, structuring, adaption, alteration, copying, transfer, retrieval, consultation, disposal, restriction, erasure and/or destruction of Transaction data. \n\n\n\n\n## 2. \tPermission to write to the Indicio Network \n\n\n1.\tIndicio hereby grants to the Transaction Author a non-exclusive, non-assignable, non-sublicensable, royalty free, and revocable license to write to and use the Indicio Network in accordance with this Agreement and the applicable Indicio Governance Framework or Indicio TestNet Governance Framework. \n\n\n2.\tTransactions can only be authored through Permissioned Write Access, whereby a Transaction Author can only write to the Indicio Network by using an authorized Transaction Endorser.  \n\n\n\n3.\tOnce an initial Transaction has been written to one of the Indicio Networks by the Transaction Author, the Transaction Author is granted permission to make additional Transactions to update the state of a previous Transaction.\n\n\n\n    An update transaction does not remove the initial transaction, which will remain on the Indicio Main Network (MainNet) due to the immutability of the ledger; and a transaction will remain on Indicio Test Network (TestNet) or Demo Network (DemoNet) until it is reset, which will occur at periodic intervals.  \n\n    A Transaction Author may make an update transaction if and only if the Transaction Author was the author of the initial transaction. Update Transactions are Transactions and are subject to all the terms of this Agreement. \n\n\n## 3. \tTransaction Author obligations \n\n\n*Pertaining to all Transactions, a Transaction Author MUST:*\n\n\n\n1. Comply with any requirements imposed by the Transaction Endorser on the Transaction Author.\n1. Not write Impermissible** **Personal Data to the ledger. \n1. Not write data to the ledger that would violate the intellectual property rights of others. \n\n\n\n\n\n\n## 4.\tPenalties for violating Transaction Author Agreement\n\n\n1. \tIn the event that the transaction author intentionally or inadvertently violates the terms of the Transaction Author and Transaction Endorser agreements and writes Impermissible** **Personal Data to the ledger, Indicio reserves the right to act on behalf of the Node Operators and block public access to that data through creating a Tombstone. \n\n\n2. \tDepending on the severity of an infraction or in the event of repeated infractions, Transaction Endorsers may be required to block endorsement of specific Transaction Authors by the Network Trustees. \n\n\n\n## 5.\tData processing and control under GDPR\n\n\n1. \tIndicio will serve as the designated data controller for the Indicio Network; all roles and rules with respect to Transaction Endorsers complying with GDPR are explained in the Indicio Data Processing Agreement. \n\n\n\n\n\n## 6.\t Term and termination \n\n\n1. \tThis Agreement commences on the Effective Date and shall remain in force until terminated by either Party pursuant to this **Section 6 (Term and Termination)**.  \n\n\n\n\n\n2. \tEither Party may terminate this Agreement: (i) if the other Party has materially defaulted in the performance of any of its obligations under this Agreement and has not cured such default within fifteen (15) business days of receipt of written notice from the non-defaulting Party of such default or (ii) immediately in the event of any government sanctions or other legal measures that make it unlawful for Transaction Author to write Transactions to the Indicio Network.  \n\n\n\n3.\tAdditionally, the Transaction Author may terminate this Agreement upon 30 days’ advance written notice to Indicio and ceasing all use of the Indicio Network. \n\n\n4.\tThe Transaction Author Agreement can be immediately terminated by Indicio if the Transaction Author writes Impermissible Personal Data to the ledger.\n\n\n5.\tUpon termination or expiration of this Agreement for any reason, the rights granted to the Transaction Author by Indicio under this Agreement automatically terminate. \n\n\n6. \tSpecific instructions for relinquishing a validator node are described in the document “Node Operator Termination.” \n\n\n\n## 7. Representations and warranties; disclaimer \n\na. By Indicio:\n\n\n1. \tTHE INDICIO NETWORK IS PROVIDED AS-IS WITH ALL FAULTS. TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, INDICIO MAKES NO REPRESENTATION OR WARRANTY CONCERNING THE ACCURACY, RELIABILITY, OR COMPLETENESS OF ANY INFORMATION OR DATA OBTAINED OR DERIVED THROUGH THE USE OF THE INDICIO NETWORK AS THE INDICIO NETWORK OPERATES ON A DISTRIBUTED NETWORK AND INDICIO DOES NOT CONTROL THE INFORMATION OR DATA WRITTEN TO THE INDICIO NETWORK. INDICIO DISCLAIMS ANY OTHER REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ACCURACY OR COMPLETENESS OF DATA. \n\n\n\n2.\tAs the architect of the Indicio Network and administrator of the Indicio Governance and TestNet Frameworks, Indicio is an independent controller of the Personal Data Transactions. In no event will the Indicio be held liable for the actions or omissions of Transaction Author arising out of any Impermissible** **Personal Data that Transaction Author writes to the Indicio Network in breach of this Agreement and the Indicio Governance and TestNet Governance Framework, including but not limited to any Impermissible Personal Data. Notwithstanding the foregoing, if Transaction Author writes Permissible Personal Data to the Indicio Network in express compliance with this Agreement and the Indicio Governance Framework, Indicio is responsible for the lawfulness of such Processing once such Permissible Personal Data is written to the Indicio Network. \n\n\n\nb. By Transaction Author. Transaction Author represents and warrants: \n\n\n3.\tIf a natural person, he or she is 16 years of age or older.  \n\n\n\n4.\tIt has all necessary rights and permissions to write the Transactions. \n\n\n\n5.\tThe Transactions do not and will not violate any applicable law.  \n\n\n\n6.\tThe Transactions will not contain data or information that infringes on or misappropriates the intellectual property rights of any third party. \n\n\n\n7.\tIt understands that the Indicio Network operates on a distributed network and that Indicio disclaims any responsibilities with respect to access of data from the Indicio Network. \n\n\n\n8.\tIt understands and acknowledges that Indicio does not control the transfer of data between Nodes and over communications facilities, including the internet, and that the Indicio Network may be subject to limitations, delays, and other problems inherent in the use of such communications facilities.  \n\n\n\n9.\tIt understands and acknowledges that there is regulatory uncertainty regarding the Indicio Network’s compliance with Data Protection Laws as it relates to Permissioned Write Access, Public Write Access, and Personal Data, including cross-border transfers of data, Processing of Personal Data, the right to effective erasure of data, as well as the scope and nature of Personal Data itself.  \n\n\n\n10.\tIt understands and acknowledges that Indicio may modify, at any time, the terms of this Agreement and any other agreement or document related to the Indicio Network based on new information, guidance, or Data Protection Laws; and  \n\n\n\n11.\tIt understands and acknowledges that a Node Operator and/or Indicio may obscure a Transaction if (i) the Node Operator or Indicio is required to do so by a court order or applicable law or (ii) the Node Operator or Indicio has evidence that the Transaction violates the terms of this Agreement or any applicable law.\n\n\n\n\n\n## 8.\t Indemnification \n\n\n1.\tTo the fullest extent permitted by applicable law, a Transaction Author will indemnify and hold harmless Indicio, and each of its respective officers, directors, agents, partners and employees (individually and collectively, the “**Indicio Parties**”) from and against any losses, liabilities, claims, demands, damages, expenses or costs (“**Claims**”) brought by a third party arising out of or related to (i) Transaction Author’s access to or use of Indicio Network in violation of this Agreement; (ii) Transaction Author’s violation, misappropriation or infringement of any rights of another (including intellectual property rights or privacy rights); or (iii) Transaction Author’s violation of applicable law.\n\n\n2.\tA Transaction Author agrees to promptly notify the Indicio Parties in writing of any Claims, cooperate with the Indicio Parties in defending such Claims and pay all fees, costs and expenses associated with defending such Claims (including attorneys’ fees). Transaction Author also agrees that the Indicio Parties will have sole control of the defense or settlement, at Indicio’s sole option, of any Claims. This indemnity is in addition to, and not in lieu of, any other indemnities set forth in a written agreement between Transaction Author and Indicio or the other Indicio Parties. \n\n\n\n\n## 9.\t Governing law and forum \n\nThis Agreement is governed by the law of the State of Delaware, without reference to conflict of laws principles; provided that, if Transaction Author is a governmental entity, this Agreement is governed by the law in which such governmental entity is established. All disputes arising out of or in connection with this Agreement shall be finally settled by binding arbitration under the Rules of Arbitration of the International Chamber of Commerce (the “**Rules**”) by a single arbitrator appointed in accordance with said Rules. Arbitration proceedings will be held in Washington, DC. Unless the Parties otherwise mutually agree, such arbitration shall be conducted in the English language by electronic exchange of documents and by video conference. The arbitrator shall issue a reasoned decision, including findings of fact and conclusions of law. The arbitrator shall require exchange by the Parties of documents relevant to the issues raised by any claim, defense, or counterclaim or on which the producing Party may rely in support of or in opposition to any claim, defense, or counterclaim, with due regard for eliminating undue burden and expense and the expedited and lower cost nature of arbitration. At the request of a Party, the arbitrator may at his or her discretion order the deposition of witnesses. Depositions shall be limited to a maximum of three depositions per Party, each of a maximum of four hours duration, unless the arbitrator otherwise determines. * ---Demand for arbitration may be initiated by either Party on fifteen (15) days written notice by email to the other Party’s designated representative, together with a written specification of the grounds for the dispute and the relief requested. By agreeing to binding and non-appealable arbitration, each party understands that they each forever give up and waive any right which each Party may have to resolve any such claim, difference or dispute by court or jury trial. Notwithstanding the foregoing, either Party may bring a proceeding seeking equitable or injunctive relief solely and exclusively in the state and federal courts located in Wilmington, Delaware, to prevent the infringement of .intellectual property rights or the disclosure of confidential information. Each Party hereto consents to the exclusive jurisdiction of such courts for the adjudication of any such equitable or injunctive relief, as well as for any such matters that are excluded from or fall outside of this arbitration provision. \n\n\n## 10. \tLimitation of liability \n\nEXCEPT IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, WILLFUL MISCONDUCT OR FRAUD, IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY INDIRECT, INCIDENTAL, EXEMPLARY, PUNITIVE, SPECIAL, OR OTHER CONSEQUENTIAL DAMAGES UNDER THIS AGREEMENT, INCLUDING, WITHOUT LIMITATION, ANY LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR DATA, OR OTHERWISE, EVEN IF THE OTHER PARTY IS EXPRESSLY ADVISED OF THE POSSIBILITY OR LIKELIHOOD OF SUCH DAMAGES. \n\nEXCEPT IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, WILLFUL MISCONDUCT OR FRAUD, IN NO EVENT SHALL EITHER PARTY’S LIABILITY UNDER THIS AGREEMENT EXCEED $250,000 USD IN THE AGGREGATE, PROVIDED THAT THERE WILL BE NO DOLLAR CAP ON LIABILITY FOR DAMAGES ARISING FROM VIOLATIONS OF DATA PROTECTION LAWS. IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, SUCH PARTY’S LIABILITY UNDER THIS AGREEMENT SHALL NOT EXCEED $500,000 USD IN THE AGGREGATE. IN THE EVENT OF EITHER PARTY’S WILLFUL MISCONDUCT OR FRAUD, THERE SHALL BE NO DOLLAR CAP ON SUCH PARTY’S LIABILITY UNDER THIS AGREEMENT. \n\n\n## 11. \tMiscellaneous \n\n\n\n1.\tNotice. Any notice, payment, demand or communication required or permitted to be delivered or given by the provisions of this Agreement shall be deemed to have been effectively delivered or given and received on the date personally or electronically delivered to the respective Party to whom it is directed, or when deposited by registered or certified mail, with postage and charges prepaid and addressed to each respective Party. For the Transaction Author, notices will be sent to the agent service endpoint of the Transaction Author’s DID as long as the Transaction Author authorizes such a connection or sent via another mechanism agreed to by the parties. For Indicio, notices will be sent to Indicio Inc., 1225 13th St. NW, suite 205, Washington, DC, USA. \n\n\n\n2.\tSeverability. If any provision of this Agreement is held invalid, illegal, or unenforceable, the validity, legality, and enforceability of any of the remaining provisions of this Agreement shall not in any way be affected or impaired.  \n\n\n\n3.\tRelationship of the Parties. This Agreement does not create a partnership, franchise, joint venture, agency, fiduciary or employment relationship between the Parties. Neither Party will represent that it has any authority to assume or create any obligation, express or implied, on behalf of the other Party, nor to represent the other Party as agent, employee, franchisee, or in any other capacity. There are no third-party beneficiaries to this Agreement. Neither Party shall make any proposals, promises, warranties, guarantees, or representations on behalf of the other Party or in the other Party’s name.  \n\n\n\n4.\tAssignment. Neither Party will voluntarily, or by operation of law, assign or otherwise transfer this Agreement without the other Party’s express prior written consent which will not be unreasonably withheld, provided that no such consent is required for an assignment or transfer to a wholly or majority owned subsidiary or to a successor in interest by reason of merger or consolidation or sale of all or substantially all of the assets of such Party relating to the subject matter of this Agreement.  \n\n\n\n5.\tWaiver. The waiver by either Party of a breach, default, delay or omission of any of the provisions of this Agreement by the other Party will not be construed as a waiver of any subsequent breach of the same or other provisions. \n\n\n\n6.\tEntire Agreement. This Agreement, including all documents incorporated into this Agreement by reference, constitutes the entire agreement of the Parties with respect to the subject matter of this Agreement, and supersedes any and all prior agreements and understandings of the Parties, whether written or oral, with respect to such subject matter. This Agreement supersedes all prior Transaction Author Agreements between Indicio and the Transaction Author with respect to the subject matter hereof.  \n\n\n\n7.\tModification of This Agreement. Indicio reserves the right to modify this Agreement at any time in accordance with this provision, including, but not limited to, changes in applicable law or guidance from any jurisdiction. Indicio will post an amended version of this Agreement on its website at least thirty (30) days prior to the date on which all Transaction Authors must begin operating under the amendment (the “**Amendment Cutover Date**” ). If a Transaction Author continues to Author Transactions to the Indicio Network after the Amendment Cutover Date, such continued use will constitute acceptance of the amended Agreement.  \n\n\n\n8.\tCounterparts. This Agreement may be executed in two or more counterparts, each of which will be deemed an original, but all of which taken together will constitute one and the same instrument.  \n\n\n\n9.\tSurvival. Any terms that by their nature survive termination or expiration of this Agreement shall survive.  \n\n\n\n10.\tGovernmental Entities. If Transaction Author is a governmental entity and it determines that GDPR does not apply to it and its Processing of Transactions, then:  \n\n\n\n    a.\tto the extent that the GDPR requirements referenced in this Agreement are equivalent to the requirements under Data Protection Laws in its own jurisdiction, it will comply with any such requirements; and  \n\n\n\n    b.\tto the extent that GDPR requirements referenced in this Agreement differ from requirements under Data Protection Laws in its own jurisdiction, it will comply with the requirements under its own legislation.  \n\n",
    "version": "1.3"
  },
  "taa_required": true,
  "taa_accepted": {
    "mechanism": "wallet_agreement",
    "time": 1750982400
  }
}

post

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

Authorizations

x-api-keystringRequired

Body

mechanismstringRequired

Mechanism for accepting TAA.

textstringOptional

The Transaction Author Agreement

versionstringOptional

Version of the TAA

Responses

200

TAA accepted successfully

application/json

taaobjectOptional

The accepted TAA.

401

Unauthorized.

No content

500

Internal Server Error

application/json

errorstringOptionalExample: Internal server error

post/api/v1/accept-taa

POST /api/v1/accept-taa HTTP/1.1
Host: proven-4-2-test.proven.indicio.tech
x-api-key: YOUR_API_KEY
Content-Type: application/json
Accept: */*
Content-Length: 89

{
  "mechanism": "on_file",
  "text": "Indicio Transaction Author Agreement....",
  "version": "1.3"
}

{
  "aml_record": {
    "aml": {
      "at_submission": "The agreement was reviewed by the user and accepted at the time of submission of this transaction.",
      "for_session": "The agreement was reviewed by the user and accepted at some point in the user’s session prior to submission.",
      "on_file": "An authorized person accepted the agreement, and such acceptance is on file with the user’s organization.",
      "product_eula": "The agreement was included in the software product’s terms and conditions as part of a license to the end user.",
      "service_agreement": "The agreement was included in the terms and conditions the user accepted as part of contracting a service.",
      "wallet_agreement": "The agreement was reviewed by the user and this affirmation was persisted in the user’s wallet for use during submission."
    },
    "amlContext": "https://raw.githubusercontent.com/Indicio-tech/indicio-network/main/TAA/AML.md",
    "version": "1.0"
  },
  "taa_record": {
    "digest": "c965dd01fec099ea95babaea3031bc09905432d3d7f1519bc0b99971aece8592",
    "ratification_ts": 1606435200,
    "text": "Indicio Transaction Author Agreement \n\nVersion 1.3\n\n11/10/2020\n\n**Summary:**\n\nThis summary is to help you understand your obligations when writing to the Indicio Network, which is composed of a TestNet, DemoNet, and MainNet. It does not have any legal effect or replace the full legal text of the agreement provided below it.\n\n\n\n*   We define the Transaction Author role (or any role described in this statement that performs the functions of a Transaction Author) as one of using an application to add transactions to the Indicio Network for the purpose of issuing Credentials.  \n \nCredential issuing transactions include, but may not be limited to, writing Schema and Credential Definitions, unprivileged DIDs, altering DID attributes, creating Revocation Registries, and updating Revocation Registries. \n\n*   This agreement grants you the Transaction Author permission to write data to the Indicio Network and its component Networks, the Indicio TestNet, DemoNet, and MainNet under certain terms and conditions.  \n\n*   You represent and warrant that the data you are writing does not violate any applicable laws or infringe the rights of any other party.\n\n     \n\n*   You understand the data you write to the TestNet and DemoNet is public but not permanent, and in accordance with the Indicio TestNet agreement will be erased by periodic resets of the TestNet and DemoNet. \n\n*   You understand that any data you write to the MainNet is public and permanent and cannot be erased. This includes public keys.  \n\n*   If it is determined that the data you wrote violated this agreement, Indicio can impose penalties, including suspension or termination of this agreement, and may take steps to block public access to this data through creating a Tombstone.  \n\n*   Indicio makes no promises about the reliability or correctness of the data stored on the Indicio Network or the operation of the Indicio Network. \n\n**Agreement.**\n\nThis Transaction Author Agreement (the “**Agreement**”) is entered into on the date you accepted this Agreement (the “**Effective Date**”) between Indicio Inc., a Benefit Corporation organized under the laws of the State of Delaware, United States of America (“**Indicio**”), and you (“**Transaction Author**”), either an entity or a natural person acting as an Individual. \n\nIndicio and the Transaction Author are individually referred to herein as a “Party” and collectively as the “Parties.” All references to “you” throughout this Agreement will include that person or entity. You represent that you are authorized to accept this Agreement on that person’s or entity’s behalf, and in the event you or the person or entity violates this Agreement, the person or entity agrees to be responsible to Indicio. \n\nBy clicking “Accept” or similar or writing Transactions to the Indicio Network, the Transaction Author agrees to be bound by this Agreement and all terms incorporated by reference. If the Transaction Author does not agree to this Agreement in its entirety, do not click “Accept” or write Transactions to the Indicio Network. \n\nIf Indicio makes material changes to this Agreement, we will notify you by posting a notice on our website prior to the effective date of the changes. By continuing to act as a Transaction Author or by otherwise writing Transactions on the Indicio Network after we post changes to our website, you agree to be bound by the revised Agreement. \n\n\nWHEREAS, the Transaction Author desires to write Transactions to the Indicio Network\n\n(each a “**Transaction**”); and \n\nWHEREAS, subject to the Transaction Author complying with the terms and conditions of this Agreement, Indicio grants permission to the Transaction Author to write Transactions to the Indicio Network; \n\nFOR GOOD AND VALUABLE CONSIDERATION, THE SUFFICIENCY OF WHICH IS HEREBY ACKNOWLEDGED, THE PARTIES AGREE AS FOLLOWS: \n\n\n## 1. \tDefinitions\n\n*Pertaining to the network:*\n\n\n\n1. \tThe **Indicio Governance Framework** refers to Indicio’s governance public benefit mission, policies, and rules available at LINK or any successor website.  \n\n\n2. \tThe **Indicio Ledger** is the collective term for all the ledgers on the Indicio Network, including the MainNet, DemoNet, and TestNet, and their sub ledgers, viz., pool, admin, main, config., etc. \n\n\n3. \tThe **Indicio Network** is a public, permissioned network built on Hyperledger Indy, Aries, and Ursa, and consisting of a MainNet, DemoNet, and TestNet. It is run by Indicio—the genesis node operator for the Network—and the Node Operators, of which Indicio is also a member. Public refers to being able to read and permissioned refers to the ability to write to the ledger. \n\n\n*Network terminology:* \n\n\n\n4.\tA **Credential** is a digital assertion containing a set of claims about the identity attributes of an entity (as per IETF RFC 3986, Uniform Resource Identifier (URI), an entity is a resource of any kind that can be uniquely and independently identified). \n\n\n\n5. \tA **Credential Definition** is a machine-readable definition of the semantic structure of a Credential based on one or more Credential Schemas.  \n\n\n\n6. \tA **Credential Schema** is a machine-readable definition of the semantics of data structure. Schemas define the attributes in a Credential Definition.  \n\n\n\n7. \tA **DID** is the acronym for decentralized identifier, a unique, permanent URL for an identity. \n\n\n\n8. \tA **DID** Document is a machine-readable document describing the public cryptographic keys, service endpoints, and other metadata associated with a DID. Each DID points to a unique DID document on a ledger.  \n\n\n\n9. \tA **Revocation Registry** is a cryptographic data structure for recording the revocation of credentials. \n\n\n\n10.\t**Permissioned Write Access** refers to a network state where “Public Write Access” is not permitted. In this state, Transaction Authors may only write transactions with a signature from an approving Transaction Endorser. \n\n\n\n11. **Public Write Access** refers to the state that a network is in when anyone can become a Transaction Author and write to the ledger. The Indicio Network does not, in its present state, allow Public Write Access.\n\n\n12. **Public Read Access** means that anyone can access, audit, read, or download content on the Ledger, although there may be a fee to do so. \n\n\n\n13. A **Tombstone** is a technical means of blocking public access to a ledger record without erasing that record. It is used only in the event of impermissible public data being written to the ledger in violation of Transaction Author and Endorser agreements.   \n\n\n\n14. A **Transaction** refers to the act of writing Schemas and Credential Definitions to the ledger for the purpose of issuing Credentials, creating Revocation Registries for the purpose of revoking credentials, updating Revocation Registries, creating a DID, adding or editing attributes to a DID, and rotating a DID’s key.   \n\n\n\n15. A **Transaction Author** refers to an entity using an application to write records to the Indicio Network for the purpose of issuing credentials. Credential issuing transactions include, but may not be limited to, writing Schema and Credential Definitions, creating Revocation Registries, and updating Revocation Registries. They can also write DID transactions to the ledger including DID creation, attribute creation and editing, and key rotation. \n\n\n\n16. A **Transaction Endorser** refers to an entity that is authorized to approve a Transaction Author write to the ledger. \n\n\n\n17. A **Trustee** refers to a person authorized to administer the governance and maintenance of the network. Multiple Trustee signatures are required to perform certain administrative and maintenance functions.\n\n\n*Pertaining to data privacy:*\n\n\n18. **Data Controller**  is defined by the EU General Data Protection Regulation (GDPR), the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data.\n\n\n19. **Data Processor** is defined by the EU General Data Protection Regulation (GDPR), a natural or legal person, public authority, agency, or other body which processes Personal Data on behalf of a Data Controller**.**\n\n\n20. **Data Protection Laws** mean California’s Consumer Privacy Act (CCPA), the European Union’s General Data Protection Regulation (GDPR), and any other national or international data protection and privacy laws, regulations, and regulatory requirements applicable to a party under this Agreement.  \n\n\n\n21. **Personal Data** means information that relates directly or indirectly to a data subject, including without limitation, names, email addresses, postal addresses, identification numbers, location data, online identifiers, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of the data subject. \n\n\n22. **Node Data** means any information which includes any Personal Data that a Node Operator Processes through the Node.\t\n\n\n23. **Permissible Personal Data** refers to the Personal Data that a Transaction Author writes to the Indicio Network that is permitted under this Agreement and Indicio’s Governance Framework, namely, but not limited to, identification numbers and online identifiers. \n\n\n\n24. **Impermissible Personal Data** refers to personal data that is not covered under Permissible Personal Data and should not be written to the ledger \n\n\n\n25. **Process** or **Processing** means any operation or set of operations that is performed on Transaction data, whether or not by automated means, such as the access, collection, use, storage, disclosure, dissemination, combination, recording, organization, structuring, adaption, alteration, copying, transfer, retrieval, consultation, disposal, restriction, erasure and/or destruction of Transaction data. \n\n\n\n\n## 2. \tPermission to write to the Indicio Network \n\n\n1.\tIndicio hereby grants to the Transaction Author a non-exclusive, non-assignable, non-sublicensable, royalty free, and revocable license to write to and use the Indicio Network in accordance with this Agreement and the applicable Indicio Governance Framework or Indicio TestNet Governance Framework. \n\n\n2.\tTransactions can only be authored through Permissioned Write Access, whereby a Transaction Author can only write to the Indicio Network by using an authorized Transaction Endorser.  \n\n\n\n3.\tOnce an initial Transaction has been written to one of the Indicio Networks by the Transaction Author, the Transaction Author is granted permission to make additional Transactions to update the state of a previous Transaction.\n\n\n\n    An update transaction does not remove the initial transaction, which will remain on the Indicio Main Network (MainNet) due to the immutability of the ledger; and a transaction will remain on Indicio Test Network (TestNet) or Demo Network (DemoNet) until it is reset, which will occur at periodic intervals.  \n\n    A Transaction Author may make an update transaction if and only if the Transaction Author was the author of the initial transaction. Update Transactions are Transactions and are subject to all the terms of this Agreement. \n\n\n## 3. \tTransaction Author obligations \n\n\n*Pertaining to all Transactions, a Transaction Author MUST:*\n\n\n\n1. Comply with any requirements imposed by the Transaction Endorser on the Transaction Author.\n1. Not write Impermissible** **Personal Data to the ledger. \n1. Not write data to the ledger that would violate the intellectual property rights of others. \n\n\n\n\n\n\n## 4.\tPenalties for violating Transaction Author Agreement\n\n\n1. \tIn the event that the transaction author intentionally or inadvertently violates the terms of the Transaction Author and Transaction Endorser agreements and writes Impermissible** **Personal Data to the ledger, Indicio reserves the right to act on behalf of the Node Operators and block public access to that data through creating a Tombstone. \n\n\n2. \tDepending on the severity of an infraction or in the event of repeated infractions, Transaction Endorsers may be required to block endorsement of specific Transaction Authors by the Network Trustees. \n\n\n\n## 5.\tData processing and control under GDPR\n\n\n1. \tIndicio will serve as the designated data controller for the Indicio Network; all roles and rules with respect to Transaction Endorsers complying with GDPR are explained in the Indicio Data Processing Agreement. \n\n\n\n\n\n## 6.\t Term and termination \n\n\n1. \tThis Agreement commences on the Effective Date and shall remain in force until terminated by either Party pursuant to this **Section 6 (Term and Termination)**.  \n\n\n\n\n\n2. \tEither Party may terminate this Agreement: (i) if the other Party has materially defaulted in the performance of any of its obligations under this Agreement and has not cured such default within fifteen (15) business days of receipt of written notice from the non-defaulting Party of such default or (ii) immediately in the event of any government sanctions or other legal measures that make it unlawful for Transaction Author to write Transactions to the Indicio Network.  \n\n\n\n3.\tAdditionally, the Transaction Author may terminate this Agreement upon 30 days’ advance written notice to Indicio and ceasing all use of the Indicio Network. \n\n\n4.\tThe Transaction Author Agreement can be immediately terminated by Indicio if the Transaction Author writes Impermissible Personal Data to the ledger.\n\n\n5.\tUpon termination or expiration of this Agreement for any reason, the rights granted to the Transaction Author by Indicio under this Agreement automatically terminate. \n\n\n6. \tSpecific instructions for relinquishing a validator node are described in the document “Node Operator Termination.” \n\n\n\n## 7. Representations and warranties; disclaimer \n\na. By Indicio:\n\n\n1. \tTHE INDICIO NETWORK IS PROVIDED AS-IS WITH ALL FAULTS. TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW, INDICIO MAKES NO REPRESENTATION OR WARRANTY CONCERNING THE ACCURACY, RELIABILITY, OR COMPLETENESS OF ANY INFORMATION OR DATA OBTAINED OR DERIVED THROUGH THE USE OF THE INDICIO NETWORK AS THE INDICIO NETWORK OPERATES ON A DISTRIBUTED NETWORK AND INDICIO DOES NOT CONTROL THE INFORMATION OR DATA WRITTEN TO THE INDICIO NETWORK. INDICIO DISCLAIMS ANY OTHER REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, ACCURACY OR COMPLETENESS OF DATA. \n\n\n\n2.\tAs the architect of the Indicio Network and administrator of the Indicio Governance and TestNet Frameworks, Indicio is an independent controller of the Personal Data Transactions. In no event will the Indicio be held liable for the actions or omissions of Transaction Author arising out of any Impermissible** **Personal Data that Transaction Author writes to the Indicio Network in breach of this Agreement and the Indicio Governance and TestNet Governance Framework, including but not limited to any Impermissible Personal Data. Notwithstanding the foregoing, if Transaction Author writes Permissible Personal Data to the Indicio Network in express compliance with this Agreement and the Indicio Governance Framework, Indicio is responsible for the lawfulness of such Processing once such Permissible Personal Data is written to the Indicio Network. \n\n\n\nb. By Transaction Author. Transaction Author represents and warrants: \n\n\n3.\tIf a natural person, he or she is 16 years of age or older.  \n\n\n\n4.\tIt has all necessary rights and permissions to write the Transactions. \n\n\n\n5.\tThe Transactions do not and will not violate any applicable law.  \n\n\n\n6.\tThe Transactions will not contain data or information that infringes on or misappropriates the intellectual property rights of any third party. \n\n\n\n7.\tIt understands that the Indicio Network operates on a distributed network and that Indicio disclaims any responsibilities with respect to access of data from the Indicio Network. \n\n\n\n8.\tIt understands and acknowledges that Indicio does not control the transfer of data between Nodes and over communications facilities, including the internet, and that the Indicio Network may be subject to limitations, delays, and other problems inherent in the use of such communications facilities.  \n\n\n\n9.\tIt understands and acknowledges that there is regulatory uncertainty regarding the Indicio Network’s compliance with Data Protection Laws as it relates to Permissioned Write Access, Public Write Access, and Personal Data, including cross-border transfers of data, Processing of Personal Data, the right to effective erasure of data, as well as the scope and nature of Personal Data itself.  \n\n\n\n10.\tIt understands and acknowledges that Indicio may modify, at any time, the terms of this Agreement and any other agreement or document related to the Indicio Network based on new information, guidance, or Data Protection Laws; and  \n\n\n\n11.\tIt understands and acknowledges that a Node Operator and/or Indicio may obscure a Transaction if (i) the Node Operator or Indicio is required to do so by a court order or applicable law or (ii) the Node Operator or Indicio has evidence that the Transaction violates the terms of this Agreement or any applicable law.\n\n\n\n\n\n## 8.\t Indemnification \n\n\n1.\tTo the fullest extent permitted by applicable law, a Transaction Author will indemnify and hold harmless Indicio, and each of its respective officers, directors, agents, partners and employees (individually and collectively, the “**Indicio Parties**”) from and against any losses, liabilities, claims, demands, damages, expenses or costs (“**Claims**”) brought by a third party arising out of or related to (i) Transaction Author’s access to or use of Indicio Network in violation of this Agreement; (ii) Transaction Author’s violation, misappropriation or infringement of any rights of another (including intellectual property rights or privacy rights); or (iii) Transaction Author’s violation of applicable law.\n\n\n2.\tA Transaction Author agrees to promptly notify the Indicio Parties in writing of any Claims, cooperate with the Indicio Parties in defending such Claims and pay all fees, costs and expenses associated with defending such Claims (including attorneys’ fees). Transaction Author also agrees that the Indicio Parties will have sole control of the defense or settlement, at Indicio’s sole option, of any Claims. This indemnity is in addition to, and not in lieu of, any other indemnities set forth in a written agreement between Transaction Author and Indicio or the other Indicio Parties. \n\n\n\n\n## 9.\t Governing law and forum \n\nThis Agreement is governed by the law of the State of Delaware, without reference to conflict of laws principles; provided that, if Transaction Author is a governmental entity, this Agreement is governed by the law in which such governmental entity is established. All disputes arising out of or in connection with this Agreement shall be finally settled by binding arbitration under the Rules of Arbitration of the International Chamber of Commerce (the “**Rules**”) by a single arbitrator appointed in accordance with said Rules. Arbitration proceedings will be held in Washington, DC. Unless the Parties otherwise mutually agree, such arbitration shall be conducted in the English language by electronic exchange of documents and by video conference. The arbitrator shall issue a reasoned decision, including findings of fact and conclusions of law. The arbitrator shall require exchange by the Parties of documents relevant to the issues raised by any claim, defense, or counterclaim or on which the producing Party may rely in support of or in opposition to any claim, defense, or counterclaim, with due regard for eliminating undue burden and expense and the expedited and lower cost nature of arbitration. At the request of a Party, the arbitrator may at his or her discretion order the deposition of witnesses. Depositions shall be limited to a maximum of three depositions per Party, each of a maximum of four hours duration, unless the arbitrator otherwise determines. Demand for arbitration may be initiated by either Party on fifteen (15) days written notice by email to the other Party’s designated representative, together with a written specification of the grounds for the dispute and the relief requested. By agreeing to binding and non-appealable arbitration, each party understands that they each forever give up and waive any right which each Party may have to resolve any such claim, difference or dispute by court or jury trial. Notwithstanding the foregoing, either Party may bring a proceeding seeking equitable or injunctive relief solely and exclusively in the state and federal courts located in Wilmington, Delaware, to prevent the infringement of .intellectual property rights or the disclosure of confidential information. Each Party hereto consents to the exclusive jurisdiction of such courts for the adjudication of any such equitable or injunctive relief, as well as for any such matters that are excluded from or fall outside of this arbitration provision. \n\n\n## 10. \tLimitation of liability \n\nEXCEPT IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, WILLFUL MISCONDUCT OR FRAUD, IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY INDIRECT, INCIDENTAL, EXEMPLARY, PUNITIVE, SPECIAL, OR OTHER CONSEQUENTIAL DAMAGES UNDER THIS AGREEMENT, INCLUDING, WITHOUT LIMITATION, ANY LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR DATA, OR OTHERWISE, EVEN IF THE OTHER PARTY IS EXPRESSLY ADVISED OF THE POSSIBILITY OR LIKELIHOOD OF SUCH DAMAGES. \n\nEXCEPT IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, WILLFUL MISCONDUCT OR FRAUD, IN NO EVENT SHALL EITHER PARTY’S LIABILITY UNDER THIS AGREEMENT EXCEED $250,000 USD IN THE AGGREGATE, PROVIDED THAT THERE WILL BE NO DOLLAR CAP ON LIABILITY FOR DAMAGES ARISING FROM VIOLATIONS OF DATA PROTECTION LAWS. IN THE EVENT OF EITHER PARTY’S GROSS NEGLIGENCE, SUCH PARTY’S LIABILITY UNDER THIS AGREEMENT SHALL NOT EXCEED $500,000 USD IN THE AGGREGATE. IN THE EVENT OF EITHER PARTY’S WILLFUL MISCONDUCT OR FRAUD, THERE SHALL BE NO DOLLAR CAP ON SUCH PARTY’S LIABILITY UNDER THIS AGREEMENT. \n\n\n## 11. \tMiscellaneous \n\n\n\n1.\tNotice. Any notice, payment, demand or communication required or permitted to be delivered or given by the provisions of this Agreement shall be deemed to have been effectively delivered or given and received on the date personally or electronically delivered to the respective Party to whom it is directed, or when deposited by registered or certified mail, with postage and charges prepaid and addressed to each respective Party. For the Transaction Author, notices will be sent to the agent service endpoint of the Transaction Author’s DID as long as the Transaction Author authorizes such a connection or sent via another mechanism agreed to by the parties. For Indicio, notices will be sent to Indicio Inc., 1225 13th St. NW, suite 205, Washington, DC, USA. \n\n\n\n2.\tSeverability. If any provision of this Agreement is held invalid, illegal, or unenforceable, the validity, legality, and enforceability of any of the remaining provisions of this Agreement shall not in any way be affected or impaired.  \n\n\n\n3.\tRelationship of the Parties. This Agreement does not create a partnership, franchise, joint venture, agency, fiduciary or employment relationship between the Parties. Neither Party will represent that it has any authority to assume or create any obligation, express or implied, on behalf of the other Party, nor to represent the other Party as agent, employee, franchisee, or in any other capacity. There are no third-party beneficiaries to this Agreement. Neither Party shall make any proposals, promises, warranties, guarantees, or representations on behalf of the other Party or in the other Party’s name.  \n\n\n\n4.\tAssignment. Neither Party will voluntarily, or by operation of law, assign or otherwise transfer this Agreement without the other Party’s express prior written consent which will not be unreasonably withheld, provided that no such consent is required for an assignment or transfer to a wholly or majority owned subsidiary or to a successor in interest by reason of merger or consolidation or sale of all or substantially all of the assets of such Party relating to the subject matter of this Agreement.  \n\n\n\n5.\tWaiver. The waiver by either Party of a breach, default, delay or omission of any of the provisions of this Agreement by the other Party will not be construed as a waiver of any subsequent breach of the same or other provisions. \n\n\n\n6.\tEntire Agreement. This Agreement, including all documents incorporated into this Agreement by reference, constitutes the entire agreement of the Parties with respect to the subject matter of this Agreement, and supersedes any and all prior agreements and understandings of the Parties, whether written or oral, with respect to such subject matter. This Agreement supersedes all prior Transaction Author Agreements between Indicio and the Transaction Author with respect to the subject matter hereof.  \n\n\n\n7.\tModification of This Agreement. Indicio reserves the right to modify this Agreement at any time in accordance with this provision, including, but not limited to, changes in applicable law or guidance from any jurisdiction. Indicio will post an amended version of this Agreement on its website at least thirty (30) days prior to the date on which all Transaction Authors must begin operating under the amendment (the “**Amendment Cutover Date**” ). If a Transaction Author continues to Author Transactions to the Indicio Network after the Amendment Cutover Date, such continued use will constitute acceptance of the amended Agreement.  \n\n\n\n8.\tCounterparts. This Agreement may be executed in two or more counterparts, each of which will be deemed an original, but all of which taken together will constitute one and the same instrument.  \n\n\n\n9.\tSurvival. Any terms that by their nature survive termination or expiration of this Agreement shall survive.  \n\n\n\n10.\tGovernmental Entities. If Transaction Author is a governmental entity and it determines that GDPR does not apply to it and its Processing of Transactions, then:  \n\n\n\n    a.\tto the extent that the GDPR requirements referenced in this Agreement are equivalent to the requirements under Data Protection Laws in its own jurisdiction, it will comply with any such requirements; and  \n\n\n\n    b.\tto the extent that GDPR requirements referenced in this Agreement differ from requirements under Data Protection Laws in its own jurisdiction, it will comply with the requirements under its own legislation.  \n\n",
    "version": "1.3"
  },
  "taa_required": true,
  "taa_accepted": {
    "mechanism": "wallet_agreement",
    "time": 1750982400
  }
}

Indicio Proven ®

About Indicio Proven ®

Benefits

Introduction to Proven

A complete verifiable credential solution for identity and data

Seamless, streamlined, and secure identity verification

What's included

Issuer & Verifier Agents

Proven Integration Guide

How to Guides

Proven User Guide

Home

Invitations

Contacts

Proven User Tutorial

Introduction

Install the Holdr+ Mobile Wallet

Indicio Proven API Tutorial

The three major features that will be exercised are:

Connecting

Call the Invitation API

Proven Webhook Documentation

API Reference

Subwallet super Admin role only

Basic Messages

Connections

Context

Credentials

DIDs

Email

Governance

Invitations

Indicio Proven ®

About Indicio Proven ®

Benefits

Seamless, streamlined, and secure identity verification

What's included

​​

API Reference

Connections

Introduction to Proven

A complete verifiable credential solution for identity and data

Seamless, streamlined, and secure identity verification

What's included

Issuer & Verifier Agents

Invitations

Basic Messages

Subwallet super Admin role only

DIDs

Governance

Credentials

Mobile App & Mediator

Verifiable Credential Schema

Distributed Ledger Network

Technical support & training

Benefits

How to Guides

Email

Context

Proven User Tutorial

Introduction

Install the Holdr+ Mobile Wallet

Configure Your Holdr+ Mobile Wallet

Issuance - Log in to Proven

Issuance - Select a Credential to Offer

Issuance - Connect Using the QR Code in Proven

Issuance - Connect Using the QR Code in Proven

Issuance - Enter Credential Data

Issuance - Receive a Credential Offer

Issuance - Review and Accept the Credential Offer

Issuance - Review Your Credential

Issuance - View Issued Credentials

Sign out of Proven

Indicio Proven API Tutorial

The three major features that will be exercised are:

Connecting

Call the Invitation API

Proven Webhook Documentation

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

Establish the Connection