Differences in response to /agent/command/connection/receive-invitation

[tdiesler]

I see some differences in the response payload to /connection/receive-invitation running @T001-RFC0160

A: acapy-agent B: acapy-java-agent

Req: POST http://0.0.0.0:9030/agent/command/connection/receive-invitation/ {'data': "{'@id': 'b4d3f551-f74d-4f65-bec3-9e33890d2ef1', '@type': 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation', 'label': 'aca-py.Acme', 'recipientKeys': ['6w449mzkczScDdz7mycS22cAdg9K8H5XNmuYqJfmAceS'], 'serviceEndpoint': 'http://host.docker.internal:9021'}"}
A: Res: 200 {'accept': 'manual', 'connection_id': 'd8af6c67-9bd7-49fd-866d-bf45e857cceb', 'connection_protocol': 'connections/1.0', 'created_at': '2022-07-27T06:47:27.182095Z', 'invited_key': '6w449mzkczScDdz7mycS22cAdg9K8H5XNmuYqJfmAceS',   'invited_mode': 'once',    'invited_msg_id': 'b4d3f551-f74d-4f65-bec3-9e33890d2ef1', 'rfc23_state': 'invited-received', 'routing_state': 'none', 'state': 'invited',    'their_label': 'aca-py.Acme', 'their_role': 'inviter', 'updated_at': '2022-07-27T06:47:27.182095Z'}
B: Res: 200 {'accept': 'manual', 'connection_id': '810b3d9c-258d-4f9f-83e7-69b485e7523b', 'connection_protocol': 'connections/1.0', 'created_at': '2022-07-27T06:51:06.714864Z', 'invitation_key': 'zFBshFpG82HAUkoWkyqZbkbupCW8sXoDW1KZzMBpXKd', 'invitation_mode': 'once', 'invitation_msg_id': '5da55229-4045-4354-9e43-7fcd92c628d8',                                 'routing_state': 'none', 'state': 'invitation',                               'their_role': 'inviter', 'updated_at': '2022-07-27T06:51:06.714864Z'}

The Swagger UI suggest that B would be correct, and attributes should indeed be called invitation_foo instead of invited_foo

{
  "accept": "auto",
  "alias": "Bob, providing quotes",
  "connection_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "connection_protocol": "connections/1.0",
  "created_at": "2021-12-31T23:59:59Z",
  "error_msg": "No DIDDoc provided; cannot connect to public DID",
  "inbound_connection_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "invitation_key": "H3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV",
  "invitation_mode": "once",
  "invitation_msg_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "my_did": "WgWxqztrNooG92RXvxSTWv",
  "request_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "rfc23_state": "invitation-sent",
  "routing_state": "active",
  "state": "active",
  "their_did": "WgWxqztrNooG92RXvxSTWv",
  "their_label": "Bob",
  "their_public_did": "2cpBmR3FqGKWi5EyUbpRY8",
  "their_role": "requester",
  "updated_at": "2021-12-31T23:59:59Z"
}

rfc23_state and their_label is missing from the java-acapy response.

Is this significant?

[tdiesler]

Similar to connection/accept-invitation, I see ...

A: Req: POST http://0.0.0.0:9030/agent/command/connection/accept-invitation/ {'id': 'd8af6c67-9bd7-49fd-866d-bf45e857cceb'}
A: Res: 200 {'accept': 'manual', 'connection_id': 'd8af6c67-9bd7-49fd-866d-bf45e857cceb', 'connection_protocol': 'connections/1.0', 'created_at': '2022-07-27T06:47:27.182095Z', 'invitation_key': '6w449mzkczScDdz7mycS22cAdg9K8H5XNmuYqJfmAceS', 'invitation_mode': 'once', 'invitation_msg_id': 'b4d3f551-f74d-4f65-bec3-9e33890d2ef1', 'my_did': '8mZsVwfQVaSBgHjrTjouq7', 'requested_id': '6f14a757-7041-4610-ac26-dc79f8e84b82', 'rfc23_state': 'requested-sent', 'routing_state': 'none', 'state': 'requested', 'their_label': 'aca-py.Acme', 'their_role': 'inviter', 'updated_at': '2022-07-27T06:47:28.279227Z'}

B: Req: POST http://0.0.0.0:9030/agent/command/connection/accept-invitation/ {'id': '810b3d9c-258d-4f9f-83e7-69b485e7523b'}
B: Res: 200 {'accept': 'manual', 'connection_id': '810b3d9c-258d-4f9f-83e7-69b485e7523b', 'connection_protocol': 'connections/1.0', 'created_at': '2022-07-27T06:51:06.714864Z', 'invitation_key': 'zFBshFpG82HAUkoWkyqZbkbupCW8sXoDW1KZzMBpXKd',  'invitation_mode': 'once', 'invitation_msg_id': '5da55229-4045-4354-9e43-7fcd92c628d8', 'my_did': 'K5mwBAwi1QeV12ULBKZkPi', 'request_id': 'c21fa9d6-ca11-45f6-8c4f-d2127860e26c',                                    'routing_state': 'none', 'state': 'request',                                 'their_role': 'inviter', 'updated_at': '2022-07-27T06:51:06.753661Z'}

A: requested_id B: request_id

A: 'state': 'requested' B: 'state': 'request'

[tdiesler]

Is this perhaps the result of acapy_backchannel.agent_state_translation?

[tdiesler]

Aren't these state translation steps against the idea of interoperability testing? In a real world scenario, there would be agentA talking to agentB with no such state translations.

Also, I noticed that the response message to agent/command/connection/{id} duplicates attributes that are already present in the acapy response to connections/{id}, namely connection_id and state

Ideally I'd think, the harness as well as all agent implementations would adhere to the same protocol spec, which defines message content and sequence. Is this something we'd like to work towards i.e. get rid of additional/special attribute mappings and other message transformations?