-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Update] Update AATH backchannel to build image #1221
Conversation
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
This looks really good IMO. Good work and thanks for working on it! |
I poked Shel on Discord--if we wanted we could add a second image that only gets build on release. It's a little bit more work (and could be a separate item if we want), but could be a good idea potentially. |
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
@JamesKEbert hey, this one is ready for review. I believe the updated CI/CD should let us support the multi-version testing style that you suggested. Pls see my MR overview. So i think the changes for this PR are complete, more changes needed in the upstream AATH PR to support the multi-version testing. tbh, we won't know for sure that this is all working until we merge it in and start getting tagged versions of the image. If it fails for whatever reason, i will iterate on it quickly of course. |
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Forgive me for making indirectly related changes, but when testing acapy, i found some issues with our did:peer implementations. My latest commit should address them: a3c1984 Will test in acapy now. |
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
ok with my latest changes, we get very close to successful RFC0023 tests with acapy. we fail on the final step when we try to decode their DIDDoc within the DIDExchange Request they sent us... we fail here because they are using legacy DIDDocs when we are expecting a modern diddoc structure.. i suspect this is related to acapy using unqualified DIDs in these requests. i'll see if there's a way to run the tests with acapy using qualified did:peers rather than unqualified. for instance, acapy will send me back this request:
the did is
this matches our |
The AATH CI pieces look good to me, even if we accidentally did something wrong with the CI I am A-okay with us doing followup fixes there 👍 |
As for the DID Exchange issues w/ACA-Py, the DIDDoc appears to be eventually resolved in /aries_vcx/src/protocols/did_exchange/state_machine/responder/response_sent/mod.rs The DIDDoc format corresponds to RFC 0067, but that RFC hasn't been officially accepted/adopted, so I am unsure as to whether or not this is acceptable/expected/ideal behavior. From your POV, is this a sufficient DIDDoc inside of Aries VCX? |
@JamesKEbert thanks for taking a look. yea i think we are doing what the DIDExchange spec defines. Essentially:
The RFC from my reading says that implementors should either:
So in the case of doing pure did:peer:4 exchanges with ACApy, we should be good, as we will hit case 2 and be able to properly resolve the DID; i've also looked at acapy code to confirm this. However when acapy is using an unqualified DID and goes with case 1, then they will attach the weird old/legacy/aries version of a DIDDocument, which does not match the real spec: https://www.w3.org/TR/did-core/#did-document-properties I had a look at how acapy handles this situation (i.e. acapy handling receiving and processing a DIDExchange request in case 2). The following happens:
long story short; acapy will proactively handle both by converting the legacy format into the correct format. So i suppose aries-vcx should consider whether it should handle this legacy doc and try convert it? i think it probably should... |
Signed-off-by: George Mulhearn <gmulhearn@anonyome.com>
Supporting DIDExchange v1.1 will also improve our interop with acapy: #1228 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Good work on this!
The main change here is to add a new CI/CD job to build and publish our backchannel image. then this image can be consumed in the AATH repo, rather than us having to synchronise code between here and AATH repo. The CI/CD should do the following:
main
whenever we push to main branch. themain
tagged image will therefore be the "latest and greatest"0.64
. these are our "stable release" tag imagesNote that i haven't done github workflows before, so please carefully check that what i've done is sane... i've mostly tried to match some of the existing patterns in the workflows main yaml.
Other Changes
Fixes for ACAPY compatibility
I've also made some changes to get a bit more interop with ACApy. particularly around the DIDExchange suite of interop tests.
new approach is tested upstream in the AATH: hyperledger/aries-agent-test-harness#833