Support for connectionless proof request

[pstuermlinger]

Hello,

I've got a verification service which provides an invitation in the format didcomm://192.168.56.1?m=eyJAdHlwZSI6ImRpZD...7fX19.

The base64 decodes to:

{
  "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation",
  "@id": "2f237261-b670-46c3-98ed-398a36d0e05c",
  "request_presentations~attach": [
    {
      "@id": "libindy-request-presentation-0",
      "mime-type": "application/json",
      "data": {
        "base64": "ewogICJuYW1lIjogIlByb29mIHJlcXVlc3QiLAogICJub25fcmV2b2tlZCI6IHsKICAgICJmcm9tIjogMCwKICAgICJ0byI6IDE2NzM5NTI2MTIKICB9LAogICJub25jZSI6ICI1NjA0NzUxODkiLAogICJyZXF1ZXN0ZWRfYXR0cmlidXRlcyI6IHsKICAgICJJZEF0dHJpYnV0ZU5hbWUiOiB7CiAgICAgICJuYW1lcyI6IFsKICAgICAgICAiZmlyc3ROYW1lIiwKICAgICAgICAiZmFtaWx5TmFtZSIsCiAgICAgICAgImRhdGVPZkJpcnRoIiwKICAgICAgICAiZGF0ZU9mRXhwaXJ5IgogICAgICBdLAogICAgICAicmVzdHJpY3Rpb25zIjogWwogICAgICAgIHsKICAgICAgICAgICJjcmVkX2RlZl9pZCI6ICJGbmhZcGJScXVRZTZUYUVDZ2RZeFk1OjM6Q0w6MTI6ZGVmYXVsdCIKICAgICAgICB9CiAgICAgIF0KICAgIH0sCiAgICAiZ3Vlc3RBdHRyaWJ1dGVOYW1lIjogewogICAgICAibmFtZXMiOiBbCiAgICAgICAgImZpcnN0TmFtZSIsCiAgICAgICAgImxhc3ROYW1lIiwKICAgICAgICAidGl0bGUiLAogICAgICAgICJlbWFpbCIsCiAgICAgIF0sCiAgICAgICJyZXN0cmljdGlvbnMiOiBbCiAgICAgICAgewogICAgICAgICAgImNyZWRfZGVmX2lkIjogIkZuaFlwYlJxdVFlNlRhRUNnZFl4WTU6MzpDTDoxNzpndWVzdC1sb2NhbC1hYmMwMDEiCiAgICAgICAgfQogICAgICBdCiAgICB9CiAgfSwKICAicmVxdWVzdGVkX3ByZWRpY2F0ZXMiOiB7fSwKICAidmVyc2lvbiI6ICIxLjAiCn0="
      }
    }
  ],
  "~service": {
    "recipientKeys": [
      "B47YV1iNuYdJs181yrQBbqL5Du8YXnoFzvggkCiUsCvq"
    ],
    "routingKeys": [],
    "serviceEndpoint": "http://192.168.56.1:10004",
    "endpointName": "Verification Agent"
  },
  "~thread": {
    "thid": "2f237261-b670-46c3-98ed-398a36d0e05c",
    "sender_order": 0,
    "received_orders": {}
  }
}

Currently (v0.5.6), when I pass the url to Add connection, I get the following error: E0117 10:54:05.700420 13 server.go:72] Returning GQL error connect-0: input: connect http conn serve: http conn serve: invitation translate: invalid invitation url format

Are there any plans to allow this?

[github-actions[bot]]

Issue created by pstuermlinger

[lainio]

Hi, and thank you for your feedback! Highly appreciated.

It will help us to test this: What agent is the verifier? ACAPy, something else?

I have to check the Aries protocol descriptions because, at first glance, the actual message is just the plain proof request. I suppose the thread.ID would be the connection_id, i.e., pairwise?

I'll get back to you when I have done some studies.

[pstuermlinger]

Hi lainio, thanks for your quick response! Yes the verifier is an ACA-Py 0.7.5.

The message is a connectionless proof request and the information within the ~service decorator is everything needed to reply to the verifier.

The thread id is the same thread id from the response of ACA-Py when you create the proof request via POST /present-proof/create-request.

[lauravuo]

Hi @pstuermlinger Unfortunately Findy Agency does not yet support connectionless proof requests 🙁 Let's see if we can fit this to our roadmap in near future 🙂

[pstuermlinger]

That's a pitty. Any chance OOB could work? I saw there were some PRs at findy-vault. But I'm not sure how mature this feature is already and what exactly to pass into the "Add connection" textfield.

[lainio]

My intuition was at least half right. This is not a straightforward OOB case, but it's related to ~service decorator.

Here is a good summary of connectionless proof of request with ACAPy.

Because the service decorator is at the proposed state, and the connectionless request overlaps with OOB invitations, I would like to ask how important this feature is for you and what is your commitment to the findy-agency?

The actual service decorator doesn't seem such a big task at first glance, but as we all know devil lives in the details.

Anyway, I'll look into this more carefully and get back to you: what, when, how, you know 😃

[lauravuo]

That's a pitty. Any chance OOB could work? I saw there were some PRs at findy-vault. But I'm not sure how mature this feature is already and what exactly to pass into the "Add connection" textfield.

There has been done some initial work to core and vault to support out-of-band-invitations. Nevertheless, current implementation does not yet know how to parse and pass on the attached proof request, so I am afraid the parsing with the attached content will fail no matter if you use the URL or JSON format.

[pstuermlinger]

My intuition was at least half right. This is not a straightforward OOB case, but it's related to ~service decorator.

Here is a good summary of connectionless proof of request with ACAPy.

Because the service decorator is at the proposed state, and the connectionless request overlaps with OOB invitations, I would like to ask how important this feature is for you and what is your commitment to the findy-agency?

The actual service decorator doesn't seem such a big task at first glance, but as we all know devil lives in the details.

Anyway, I'll look into this more carefully and get back to you: what, when, how, you know 😃

AFAIK the ~service is mainly understood by mobile agents like Lissi, Trinsic and Esatus. Funny enough, ACA-Py itself does not have an endpoint to input such a message.

We're using Findy currently for internal development and showcase demos, since the network is highly restricted an we can't use any native mobile agent here. Findy is great to circumvent this problem.

Now we already started to implement a connectionfull present-proof as fallback mechanism.

Thanks @lainio and @lauravuo for your help!

Closing since all my questions have been answered.