Support for HTTP-over-DIDComm

[bryce-mcmath]

Just checking to see if ACA-Py currently supports this RFC at all or if it could:
https://github.com/hyperledger/aries-rfcs/tree/main/features/0335-http-over-didcomm

I didn't find anything related in the docs at aca-py.org but I thought I would ask anyway.

We (BC Wallet team) are looking at using it for app attestation background communication between the wallet and a controller. Currently the messages are being sent via BasicMessage but it's a little ugly that way and we have been searching for another approach. The above RFC was suggested by Stephen Curran

If it's not currently available in ACA-Py someone from the BC Wallet team is happy to take it on with a bit of guidance.

[dbluhm]

This is not currently implemented in ACA-Py. I don't know anything about the details of app attestation but I question whether using the http-over-didcomm approach is the right one, personally. Neither would I recommend using basic message this way 😅

HTTP over DIDComm is an interesting idea and I'm sure it can be done but there are challenges. Where HTTP is a strictly synchronous protocol with a request and a response, DIDComm at its core is asynchronous. Message order and timeliness are not explicitly guaranteed by the protocol itself. This mismatch in goals can be a pain; again, we've done it -- the Coordinate Mediation protocol contains request-response style messages; the Aries Toolbox plugin (now deprecated) also had many request-response style messages -- but challenges can arise, especially as you factor in clustering.

Why not create a new protocol? This comes with a bit of overhead in that you must write the protocol but, as far as I'm aware, RFC 0335 is not implemented by any agent implementations. Creating and implementing a purpose-built protocol would not present any more of an interop challenge than special basic messages or adding HTTP over DIDComm while being semantically cleaner than basic messages and dramatically simpler than HTTP over DIDComm.

cc @TelegramSam

[swcurran]

Actually RFC 0335 is implemented in Aries Framework Go, and they reported some success with it — when the project was active. RFC 0335 HTTP over DIDComm is a two message protocol, so the message ordering is not a big concern, and the request/response nature of the protocol is fits nicely in this and other use cases.

We considered writing another protocol that would mimic the current use of “basic message”, and that would be easy enough. However, in addition to getting agreement on the new protocol (not hard), we’d have to create a controller-based coordination between each app attestation request and app attenstion (response), each sent using a different protocol instance — coordination that HTTP over DIDComm solves. Further, the suggestion from the BC Wallet team was for payload of the protocol be left up to the controllers interacting — again, something aligned with HTTP over DIDComm.

I think it is the right way to handle this, and other similar controller-to-controller interactions, where Aries is just the conduit. AFAIK — that was the reason the protocol was designed, and it worked well for the Aries Framework Go team.

[swcurran]

Closing this as the plan is now to add support for a DRPC Protocol.

Added issue #2695 to replace this one.