# Aries Framework Go Interop status: DID-Exchange with Aries Cloudagent Python

Aries interop has in many ways been a shifting target, as work within and between projects has advanced the design of RFCs and specs, with AIP2.0 being as-yet a work in progress. While ACA-Py supports AIP1.0 and is targeting AIP2.0, AFGO targets AIP2.0 only, meaning afgo interop with ACA-Py is a moving target, as ACA-Py introduces features, options etc to support AIP2.0. To allow work to proceed in afgo on both AIP2.0 and interop, afgo targets AIP2.0 by default, and has a build flag (or in go terms, a build tag) to instead target interop with ACA-Py.

The build flag is necessary as AIP1.0 and AIP2.0 are not generally compatible - so as ACA-Py moves towards AIP2.0, it presents a moving target for afgo, with clean alignment with AIP2.0 in some parts, and requiring afgo temporarily step away from AIP2.0 in others. The latter cases sit behind the build flag.

## Behaviour Changes Behind Interop Build Flag

With the build flag `ACAPyInterop` enabled, afgo:

- Does not expect `did` fields in didcomm messages to be DIDs, so it can accept "naked" Sovrin DID method-specific identifiers in the messages sent by ACA-Py.
- Stephen: Fix in ACA-Py to make these DIDs, triggered by the AIP20 flag. I believe these will be did:key DIDs (vs. Sovrin DID method-specific)
- Similarly, chops the DIDs it puts in messages sent to ACA-Py, so those 'DIDs' match the format of a Sovrin method-specific identifier.
- Stephen: These should be did:key DIDs from AF-Go, correct? If not, what DID method would are they? Regardless, ACA-Py needs to be update to accept the current "naked keys" and DIDs of any (known) flavour, handled by the ACA-Py DID resolver. Do we need to raise an issue for this Ian?
- Uses did:sov for private, local 'peer-like' DIDs, which contravenes the [Sovrin DID Method Spec](https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html).
- Stephen: That's just wrong!! :-) Definitely needs to be fixed, perhaps based on the `--aip20` flag if that has worked in the path.
- Accepts did documents that match the DID Spec's v0.11 JSON-LD vocabulary, but not the v1 JSON-LD vocabulary, despite using the v1 namespace.
- Stephen: Another bad one. Definitely needs to be fixed, perhaps based on the `--aip20` flag if that has worked in the past.
- Uses IndyAgent service type instead of following [RFC0067](https://github.com/hyperledger/aries-rfcs/tree/master/features/0067-didcomm-diddoc-conventions/README.md).
- Stephen: This is a change needed based on the `--aip20` flag.
- Uses raw (base58) recipient and routing keys in service, instead of following [RFC0067](https://github.com/hyperledger/aries-rfcs/tree/master/features/0067-didcomm-diddoc-conventions/README.md) in accordance with [RFC0360](https://github.com/hyperledger/aries-rfcs/blob/master/features/0360-use-did-key/README.md).
- Stephen: This is a changed needed based on the `--aip20` flag.
- Signs `did_doc~attach` attachment contents, in keeping with older revisions of RFC0023, before [a recent change](https://github.com/hyperledger/aries-rfcs/commit/d9d072832353a6a11e7dae28ca313fde3474cc63#diff-1db1c2a11b3ff24b00b257fa3f000fd596cc70bcba3e228e22a45c0f0ffaec07) (which is part of the [AIP2.0 version of DID-Exchange](https://github.com/hyperledger/aries-rfcs/tree/d50fe1e38c9720344123146c31fbf7ad8e78b345/features/0023-did-exchange)).
- Stephen: This can be just changed in ACA-Py (without the `-aaip20` flag) as DID Exchange is only used in `--aip20`.

As ACA-Py continues moving towards AIP2.0, these 'hacks' behind the interop flag will be removed bit-by-bit from afgo, until both projects are achieving interop without needing to deviate from AIP2.0 to do so.

## Test Suite

Instead of using the `afgo-master` agent in the Aries Agent Test Harness, use `afgo-interop`.

### Results

<details>
<summary>AFGO - AFGO</summary>

$ ./manage run -d afgo-master -t @RFC0023 -t ~@wip
  Acme - afgo-master
  Bob - afgo-master
...
Failing scenarios:
  features/0023-did-exchange.feature:69 ... with an implicit invitation
  features/0023-did-exchange.feature:84 ... with an implicit invitation with role reversal
5 scenarios passed, 2 failed

$ ./manage run -d afgo-interop -t @RFC0023 -t ~@wip
  Acme - afgo-interop
  Bob - afgo-interop
Failing scenarios:
  features/0023-did-exchange.feature:69 ... with an implicit invitation
  features/0023-did-exchange.feature:84 ... with an implicit invitation with role reversal
5 scenarios passed, 2 failed

</details>

Implicit invitation fails in all cases, as the afgo backchannel does not support the `has a resolvable DID` operation.

<details>
<summary>AFGO - ACA-Py, with the interop build flag enabled</summary>

$ ./manage run -d afgo-interop -b acapy -t @RFC0023 -t ~@wip
  Acme - afgo-interop
  Bob - acapy
...
Failing scenarios:
  features/0023-did-exchange.feature:39 ... with an explicit invitation with a public DID
  features/0023-did-exchange.feature:69 ... with an implicit invitation
  features/0023-did-exchange.feature:84 ... with an implicit invitation with role reversal
4 scenarios passed, 3 failed

$ ./manage run -d afgo-interop -a acapy -t @RFC0023 -t ~@wip
  Acme - acapy
  Bob - afgo-interop
...
Failing scenarios:
  features/0023-did-exchange.feature:54 ... with an explicit invitation with a public DID with role reversal
  features/0023-did-exchange.feature:69 ... with an implicit invitation
  features/0023-did-exchange.feature:84 ... with an implicit invitation with role reversal
4 scenarios passed, 3 failed

</details>

Explicit invitation with public DID fails if aca-py sends the invitation, as afgo fails to resolve the aca-py agent's public sov DID. This is not an aca-py issue, the test harness afgo agent is simply not configured to connect to the test harness sovrin network.

<details>
<summary>AFGO - ACA-Py, without the interop build flag enabled</summary>

$ ./manage run -d afgo-master -a acapy -t @RFC0023 -t ~@wip
  Acme - acapy
  Bob - afgo-master
...
0 scenarios passed, 7 failed
$ ./manage run -d afgo-master -b acapy -t @RFC0023 -t ~@wip
  Acme - afgo-master
  Bob - acapy
...
0 scenarios passed, 7 failed

</details>