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