This document outlines best practices and guidelines to be considered and implemented when integrating an existing system with Aries Cloudagent. Architecture Generally speaking, a web application that leverages Aries agents is structured as follows: Agent: this service is used by the web application to interact with a Ledger and other agents connected to the same ledger. It is generally not controlled directly by the web application frontend, instead requests to the agent come from a controller service. Controller: this service provides the business logic for the web application, and acts as bridge between the frontend and the agent. The controller usually exposes appropriate APIs that the frontend will use to perform common business tasks as well as agent-related tasks such as requesting the creation of a new connection, etc. The controller is also tasked with tracking and managing all of the information that is required for the business processes to be implemented and work successfully. Frontend: this service is what the users see and interact with, commonly something that is displayed in a web browser. The above components may be at times partially consolidated or further split into separate services, the purpose of this overview is to explain the separation of concerns of these three macro-areas.

Current State When onboarding a new standalone Issuer to an Aries VCR instance (e.g.: OrgBook), an out-of-band step is required to establish the connection between the Issuer agent and the Aries VCR agent that will receive the credentials. This task needs to be completed by a developer with access to the administrative API for the Aries VCR agent, and one with access to the administrative API for the Issuer agent. Either developer will initiate the process by manually generating a new connection invitation on the agent they manage, and send the resulting payload to their counterpart, who will manually submit a request to their agent to accept the connection invitation. The invitation payload is transmitted using a method (e.g.: email, chat client) that might have some degree of risk involved with a third party malicious actor intercepting it and connecting to either agent instead of the expected party. Proposed Solution The use of a Business Partner Agent as base for both the Aries VCR and Issuer will mitigate the issues present in the current state as: either agent will be able to initiate a connection invitation by finding the target agent on a public/authorized list of connections (like in a directory)

Background Aries Cloudagent Python recently introduced the ability for non-privileged agents (from here on: author) to request endorsement of transactions that need to be written to the ledger by an agent (from here on: endorser) with ledger write privileges. A common use case for this functionality is for an organization running an agency of authors (that can be created/destroyed without needing any write interaction with the ledger) and a single instance of an endorser agent that acts as a gateway for all write needs: registering the author's DID on the ledger endorse writing a new schema to the ledger endorse writing a new credential definition to the ledger endorse writing a new revocation registry definition to the ledger

When using Aries Cloudagent Python (ACA-Py) most of the interactions with other agents occur on a connection, established beforehand and persisted across interactions. There are, however, scenarios where a connection-less interaction is useful, if not preferable. With ACA-Py the only type of connection-less interaction supported "out-of-the-box" is submitting proof requests. Service Decorator When utilizing a connection-less proof request, the verifier is identified by the presence of a service decorator section in the received proof request, rather than a connection identifier. The end result, however, is the same: the prover/holder knows where to send the proof, even if a connection with the verifier was not established ahead of time. See this link for reference. Structure of the Request