---
tags: aca-py
---

# Connection-Less Proof Requests with ACA-Py
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](https://github.com/hyperledger/aries-rfcs/blob/08653f21a489bf4717b54e4d7fd2d0bdfe6b4d1a/features/0056-service-decorator/README.md) for reference.

## Structure of the Request

{
  "@id": "a376cfa1-5b15-4f41-9e32-7294d7b643b1",
  "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation",
  "request_presentations~attach": [
    {
      "@id": "libindy-request-presentation-0",
      "mime-type": "application/json",
      "data": {
        "base64": "eyJuYW1lIjoiQ29udGFjdCBBZGRyZXNzIiwibmFtZXMiOm51bGwsInZlcnNpb24iOiIxLjEuMCIsIm5vbmNlIjoiNjkwNTQ4MDYyMjU3MTgwOTc0MDA1MzY2IiwicmVxdWVzdGVkX2F0dHJpYnV0ZXMiOnsiYTM1NDU1NTctMTAxZS00MjgxLWE5ZWQtOWRhZWZlMDc3N2Q5Ijp7Im5hbWVzIjpbImdpdmVuX25hbWVzIiwiZmFtaWx5X25hbWUiLCJiaXJ0aGRhdGUiLCJzdHJlZXRfYWRkcmVzcyIsInBvc3RhbF9jb2RlIiwibG9jYWxpdHkiLCJyZWdpb24iLCJjb3VudHJ5Il0sInJlc3RyaWN0aW9ucyI6W3sic2NoZW1hX2lzc3Vlcl9kaWQiOiI4NTQ1OUd4ak55U0o4SHdUVFE0dnE3Iiwic2NoZW1hX25hbWUiOiJ2ZXJpZmllZF9wZXJzb24iLCJzY2hlbWFfdmVyc2lvbiI6IjEuNC4wIn0seyJzY2hlbWFfbmFtZSI6InVudmVyaWZpZWRfcGVyc29uIiwic2NoZW1hX3ZlcnNpb24iOiIwLjEuMCIsImlzc3Vlcl9kaWQiOiJZWEN0WEU0WWhWalVMZ2o1aHJrNE1MIn0seyJzY2hlbWFfbmFtZSI6InVudmVyaWZpZWRfcGVyc29uIiwic2NoZW1hX3ZlcnNpb24iOiIwLjEuMCIsImlzc3Vlcl9kaWQiOiI5d1Z1WVlERUR0cFo2Q1lNcVNpV29wIn1dfX0sInJlcXVlc3RlZF9wcmVkaWNhdGVzIjp7fX0="
      }
    }
  ],
  "comment": null,
  "~service": {
    "recipientKeys": ["HGeUTFuZCM1f2FubVnYGc1xAhgAPEzBFQRcfxcpNjWbm"],
    "routingKeys": null,
    "serviceEndpoint": "https://toip-vc-authn-agent-test.apps.silver.devops.gov.bc.ca"
  }
}

The above example was taken from one of the demo apps using [vc-authn-oidc](https://github.com/bcgov/vc-authn-oidc) for authentication, and provides an example of connection-less proof request.

The notable attributes in the JSON payload are:
- `@id`: this identifies the proof request the holder/prover is responding to
- `request_presentations~attach`: this is the payload describing what needs to be proven (the `base64` attribute can de decoded to read the requested attributes and predicates)
- `~service`: defines where the response to the proof request should be sent for verification, specifying in particular the `serviceEndpoint` (in this case an ACA-Py agent endpoint), the agent's `recipientKeys` and - in case the agent was behind a mediator - the `routingKeys` for the mediator agents (not 100% sure about this aslast bit I have not tested it, but I believe it is correct).

To build a connection-less proof request, the verifier:
1. Will use the `/present-proof/create-request` to generate the payload that will be base64-encoded and placed in the frinal proof-request body
2. Will use the agent's public endpoint to populate the `serviceEndpoint` property in the service decorator, and the agent's public DID `verkey` to populate the `recipientKeys` array.
i. In case of an agent not exposed directly to the web, but behind a mediator, I believe the `serviceEndpoint` would be themediator's and the `routingKeys` array would include the appropriate set of keys to route the request - unsure about how to populate this.