ACA-Py (Adaptive Cloud Agent - Python)

ACA-Py is a production-ready, open-source self-sovereign identity (SSI) agent designed for non-mobile decentralized trust services. It is used to build verifiable credential (VC) issuers, holders, and verifiers.

Key Characteristics:

• Deployment: Runs on servers (cloud, enterprise, IoT) and is not intended for mobile devices.
• Integration Model: You build a business logic "controller" in any language that communicates with ACA-Py via HTTP requests and receives webhook notifications. You do not need to know Python to use it.
• Protocol Support: Supports Aries Interop Profile (AIP) 2.0, including protocols for issuing, verifying, and holding credentials.
• Credential Formats: Supports [AnonCreds] and the [W3C Standard Verifiable Credential Data Model] (using JSON-LD with Data Integrity Proofs and BBS+ Signatures).

This workshop provides a hands-on guide to issuing, receiving, holding, requesting, presenting, and verifying AnonCreds Verifiable Credentials using the WebVH (Web Verifiable History) DID method.

It is structured into two parts:

1. WebVH Basics: A non-technical sequence of labs covering the credential lifecycle.
2. OpenAPI (Swagger) Integration: A technical track for automating credential issuance and verification using REST APIs.

Important Sandbox Warning: If using the provided Traction Sandbox, note that the environment is reset on the 1st and 15th of each month, and all work will be deleted. Always save your Wallet ID and Wallet Key securely in a password manager, as they cannot be recovered.

ACA-Py includes several advanced features:

• Plugins: A growing set of extensions for various functionalities.
• Multi-Tenancy: Supports multiple tenants. For management, see the Multi-tenant Documentation or use Traction for an Administrative/Tenant UI.
• SD-JWTs: Supports signing and verifying SD-JWTs.
• Persistence of Mediated Messages: Supports persistent queues using Redis or Kafka via plugins. Without these, messages are stored in an in-memory queue (subject to loss on sudden termination).
• Connection-less Protocols:
  • AIP 1.0: Supported for issue credential and present proof.
  • AIP 2.0 (OOB): Supported for present proof.
• Multi Indy Ledger Support: Automatic detection of multiple ledgers.

ACA-Py documentation is split into two main sources:

1. ACA-Py User Documentation: Hosted at aca-py.org. This is the primary site for end-users.
2. ACA-Py Source Code Internals: Hosted on ReadTheDocs at https://aries-cloud-agent-python.readthedocs.io. This contains technical documentation for the source code internals.

To update the ReadTheDocs documentation, refer to the UpdateRTD.md file in this repository.

ACA-Py supports multi-tenant scenarios where a single, scalable instance of ACA-Py and one database instance can manage separate secure storage (private keys, DIDs, credentials, etc.) for many different actors.

Use Cases:

• Issuer-as-a-Service: An enterprise hosting multiple VC issuers, each with unique identifiers, on one ACA-Py instance.
• Cloud Wallets: Providing a wallet service for many holders (people or organizations) who cannot use mobile devices.

ACA-Py (Adaptive Cloud Agent - Python) is an interoperable toolkit for creating, transmitting, and storing verifiable digital credentials. It provides infrastructure for decentralized, peer-to-peer interactions, including secure storage, key management, and communication protocols.

An ACA-Py agent performs the following core functions:

• Connection Establishment: Enables connections with other DIDComm-based agents using DIDComm encryption envelopes.
• Message Exchange: Executes message protocols between connected agents using DIDComm and other supported protocols.
• Event Notification: Sends notifications regarding protocol events to a controller.
• API Exposure: Provides an API that allows a controller to respond to and direct the handling of protocol events.

WebVH is a DID method that allows issuers to publish AnonCreds objects (such as schemas, credential definitions, and revocation registries) as Attested Resources on a web server.

Unlike blockchain-based ledgers, WebVH uses HTTP-based resolution. It maintains cryptographic integrity through digital signatures (Data Integrity Proofs) and uses witness services for attestation instead of blockchain consensus. This makes it easier to deploy on standard web infrastructure while preserving the privacy features of the AnonCreds protocol.

ACA-Py can be configured as a DIDComm mediator. In this role, the agent receives, stores, and forwards messages to DIDComm agents that lack an addressable Internet endpoint (such as mobile wallets).

Startup options allow ACA-Py to coordinate its mediation role using core DIDComm protocols.

To build a solution with ACA-Py, you implement a business logic "controller". The controller interacts with the ACA-Py instance using a request/response pattern:

1. Outgoing: The controller sends HTTP requests to ACA-Py to trigger actions.
2. Incoming: ACA-Py sends webhook notifications to the controller to report status changes or events.

This abstraction allows developers to focus on high-level business logic using standard web technologies instead of low-level cryptography or Trust over IP protocols.