rjones (Wed, 22 Apr 2020 18:52:50 GMT):
swcurran
rjones (Wed, 22 Apr 2020 18:53:00 GMT):
Has left the channel.
ianco (Wed, 22 Apr 2020 18:56:02 GMT):
Has joined the channel.
ajayjadhav (Thu, 23 Apr 2020 11:33:29 GMT):
Has joined the channel.
adamjlemmon (Mon, 27 Apr 2020 10:47:47 GMT):
Has joined the channel.
adamjlemmon (Mon, 27 Apr 2020 10:58:34 GMT):
hey guys! Happy Monday. All setup here, we should be able to start meaningfully contributing this week. Enjoy IIW. Speak soon.
EdEykholt (Mon, 27 Apr 2020 14:29:47 GMT):
Has joined the channel.
ianco (Mon, 27 Apr 2020 14:32:15 GMT):
Great! FYI @swcurran checked in some updates over the weekend and I'll have some updates later today
ianco (Mon, 27 Apr 2020 14:32:25 GMT):
Trying to make it more user- and developer-friendly
adamjlemmon (Mon, 27 Apr 2020 19:37:56 GMT):
Fantastic thanks! Will review what was merged earlier.
Audrius (Tue, 28 Apr 2020 11:48:04 GMT):
Has joined the channel.
adamjlemmon (Tue, 05 May 2020 11:10:51 GMT):
Hey @ianco , diving into the open issues now to find a best place to get started. Shall I grab one of the earlier `Expansion to cover AIP 1.0...` ones that don't seem to have been started yet?
adamjlemmon (Tue, 05 May 2020 11:23:55 GMT):
perhaps? `Test Harness Expansion to cover AIP 1.0 Protocol 0037-present-proof` https://github.com/bcgov/aries-agent-test-harness/issues/11
ianco (Tue, 05 May 2020 13:24:42 GMT):
@sheldon.regular is currently working on the credential exchange, so present proof is probably a good one for you to work on
sheldon.regular (Tue, 05 May 2020 13:24:42 GMT):
Has joined the channel.
sheldon.regular (Tue, 05 May 2020 13:34:13 GMT):
Hi @adamjlemmon , yes it would be great to start on the Acceptance Tests for Present Proof. To start it would be great to focus on happy path tests. Maybe translate the RFC into a set of Gherkin Tests and get them reviewed before coding. Does that sound reasonable?
sheldon.regular (Tue, 05 May 2020 13:35:12 GMT):
I'll also be adding some Test Development Guidelines to the repo that will explain some of the things I have taken advantage of in the test harness, stuff like tags being used to manage test states and categorization, etc.
jljordan_bcgov (Tue, 05 May 2020 15:59:41 GMT):
Has joined the channel.
adamjlemmon (Tue, 05 May 2020 16:17:04 GMT):
Hi @sheldon.regular great to e-meet you, sure that sounds like a good path forward to me, I can get started there and reach out as ready for review
adamjlemmon (Tue, 05 May 2020 16:17:21 GMT):
would be great to have a look at the guidelines as well you would recommend when avialable
swcurran (Tue, 05 May 2020 22:28:39 GMT):
@ianco - looking at the CSV. A good exercise might be to go through the list and note everything for removal that is not part of the protocol, and assume that the backchannel will take care of the details, perhaps driven by parameters. For example, for issue credential, remove the commands to do with DIDs, Schema and Cred Def, and perhaps add something like the type of credential (e.g. "indy-zkp") and the credential (e.g. "education"), and document for the backchannels what the "education" credential is (schema). The backchannel for an agent that supports Indy would either do the prep work for issuing the education credential on start up, or as part of the "offer-credential" process.
swcurran (Tue, 05 May 2020 22:31:35 GMT):
I think we also need to figure out a way to flow data from one action through to another. For example, the DID of the issuer could flow to the verifier later in a test run, when running "present proof" tests. In theory, we could save and restore state, but that's not easy in Indy - ledger and wallet must match.
ianco (Wed, 06 May 2020 17:55:48 GMT):
@swcurran yes that all makes sense. It would be good to get the behave test scripts written before we start to hack the backchannel api (i.e. write the tests that make sense, the way we want to run the tests, and then make necessary changes to the backchannel).
ianco (Wed, 06 May 2020 17:56:22 GMT):
Behave has a context that can be used to persist data between actions, that's what we've been using so far
ianco (Wed, 06 May 2020 17:56:56 GMT):
e.g. setup a connection between agents as a pre-condition to issuing credentials -> save the connection info in behave's context
swcurran (Wed, 06 May 2020 17:59:27 GMT):
Re waiting. Agree except some of the issue credential tests are out there, so they can be looked at/corrected now.
ianco (Wed, 06 May 2020 18:48:26 GMT):
FYI I've merged @sheldon.regular 's PR with the testing guidelines = https://github.com/bcgov/aries-agent-test-harness/blob/master/TEST_DEV_GUIDE.md
sheldon.regular (Thu, 07 May 2020 14:10:33 GMT):
[ ](https://chat.hyperledger.org/channel/aries-agent-test-harness?msg=y7rT6n2oNjf26jrnW) Totally agree with this. The inclusion of commands not part of the protocol muddies the water a little. It will be a good exercise to get the backchannels to take care of stuff like this.
sheldon.regular (Thu, 07 May 2020 14:17:19 GMT):
[ ](https://chat.hyperledger.org/channel/aries-agent-test-harness?msg=xxcwzEvdmZLXtLaP2) Not sure I agree with this approach. Unless there is no other way to flow data across steps, we should leave the control of this to the test harness itself. As Ian stated, Behave has a Feature and Scenario context where things can get stored for later retrieval in another step or even another scenario. I don't think you meant this, but it may be worth mentioning that scenarios shouldn't be dependent on the Agents state from a previous scenario. It is best practice to have test scenarios independent, and to have a scenario setup or create whatever state it needs so if executed independently it will be successful.
swcurran (Thu, 07 May 2020 18:07:38 GMT):
@ianco - is the pico agent ready to be added to the ./manage script?
swcurran (Thu, 07 May 2020 18:43:07 GMT):
I'm going to work on the README and some items to make the repo friendlier to new devs. That will involve some changes to ./manage to make it easier to add backchannels without hacking into ./manage. First thing is to get rid of automatically building VCX....holy crap that takes a long time. A VCX docker image is desperately needed...
swcurran (Thu, 07 May 2020 18:44:20 GMT):
Also - I'd like to change "Alice" to "ACME", where ACME is (generally) the issuer/verifier agent, and Bob is the holder/prover agent. Any concerns with that?
swcurran (Thu, 07 May 2020 18:44:59 GMT):
If you agree, we can do that with a repo search and replace.
sheldon.regular (Thu, 07 May 2020 18:46:29 GMT):
What does ACME stand for?
swcurran (Thu, 07 May 2020 18:46:33 GMT):
We will likely add the idea that agents are optional on runs --- e.g. "Carol" (another holder/prover) and "Faber" (another issuer/verifier).
swcurran (Thu, 07 May 2020 18:47:03 GMT):
https://en.wikipedia.org/wiki/Acme_Corporation
swcurran (Thu, 07 May 2020 18:48:16 GMT):
So I guess it should be "Acme"
sheldon.regular (Thu, 07 May 2020 18:50:07 GMT):
Doesn't really matter to me, but to be honest I prefer Alice. Unless you are just talking about Issue Credential Protocol only?
swcurran (Thu, 07 May 2020 18:51:56 GMT):
No it should be across the board. It's meant to convey that "Acme" is an enterprise agent, and so that in general, Acme will also play an enterprise role. Likewise, Bob a human-type being.
swcurran (Thu, 07 May 2020 18:52:44 GMT):
IMO makes it easier to write tests, and easier to run the tests that matter for an agent.
swcurran (Thu, 07 May 2020 18:53:26 GMT):
A dev knows that if they have a (for example) mobile agent, they always want to run as Bob.
swcurran (Thu, 07 May 2020 18:54:54 GMT):
When they write a backchannel, they only need to write the "Bob" role.
sheldon.regular (Thu, 07 May 2020 18:55:30 GMT):
Just thinking through the role reversal tests. Wondering if it makes sense with Acme.
swcurran (Thu, 07 May 2020 18:56:32 GMT):
That becomes a runtime decision. Does what I'm testing operate as an issuer and prover? If so, I need to run the tests in reverse.
sheldon.regular (Thu, 07 May 2020 18:56:45 GMT):
With Connection Bob can play the inviter or the invitee.
sheldon.regular (Thu, 07 May 2020 18:57:53 GMT):
And with the issue Cred, the implementer is suppose to implement all the commands not just the ones for one side.
swcurran (Thu, 07 May 2020 18:59:06 GMT):
If their agent can't issue credentials, then there is no need. Or vice versa. But with the roles "understand" based on the names, it makes it much easier to decide what tests to run.
swcurran (Thu, 07 May 2020 18:59:23 GMT):
And what tests/roles to implement
swcurran (Thu, 07 May 2020 19:00:37 GMT):
With Connection that makes sense, but right now, the existing mobile agents can't be inviters, only invitees.
swcurran (Thu, 07 May 2020 19:01:07 GMT):
So we need to as flexible as possible.
sheldon.regular (Thu, 07 May 2020 19:02:54 GMT):
So I asked this before, but maybe I asked the wrong way. Are people going to implement a protocol based on one role in that protocol. I believe the answer was no, they had to fully implement the protocol.
swcurran (Thu, 07 May 2020 19:03:22 GMT):
No, they may do either.
sheldon.regular (Thu, 07 May 2020 19:03:39 GMT):
ok
swcurran (Thu, 07 May 2020 19:05:23 GMT):
This is why the concept of "AUT" is impossible. Any particular test run will have a different answer for that.
swcurran (Thu, 07 May 2020 19:07:39 GMT):
33 minutes in to my session on Play with VON and VCX is finally built. Ridiculous...
sheldon.regular (Thu, 07 May 2020 19:09:32 GMT):
So lets get rid of the names altogether. and just call them by their roles.
sheldon.regular (Thu, 07 May 2020 19:10:00 GMT):
ie Issuer and Holder
sheldon.regular (Thu, 07 May 2020 19:12:06 GMT):
To me it seems to be a case for knowing the AUT. In each run you want to know which role the AUT is playing at that time.
ianco (Thu, 07 May 2020 19:55:45 GMT):
No, it needs to be updated to the latest pico (basically pico has been rewritten since december) and dockerized
ianco (Thu, 07 May 2020 19:56:38 GMT):
Buy a faster machine ... with a fan!
swcurran (Thu, 07 May 2020 20:05:31 GMT):
That was on Play with Docker. I think they have machines with fans. Maybe not though.
swcurran (Thu, 07 May 2020 20:05:35 GMT):
Got it to run on Play with VON --- w00t! Easy to get a demo going. I'm seeing some features that we'll want to make this easier to use.
swcurran (Thu, 07 May 2020 20:08:58 GMT):
The problem with Issuer and Holder is that its a fuzzy line, particularly as the roles are actually at a protocol level. By using this mechanism we imply that "Acme will do things that enterprise agents do", but we've left it fuzzy.
We could go with "enterprise" and "personal" or something like that, but I think "Acme" and "Bob" are better, and not so restrictive.
swcurran (Thu, 07 May 2020 20:09:18 GMT):
The AUT could be added as a run time argument, but I don't think that's crucial.
ianco (Thu, 07 May 2020 20:09:37 GMT):
PWD is pretty slow ...
ianco (Thu, 07 May 2020 20:10:01 GMT):
The VCX build IS very slow but if you're running on your local you should only need to build it once
swcurran (Thu, 07 May 2020 20:10:07 GMT):
The goal is many many people use this for many different reasons -- ultimately testing interop, and in such a case, there isn't a specific AUT, we're making sure that all the tests work,./
ianco (Thu, 07 May 2020 20:10:22 GMT):
The backchannel gets added to a cached image when you update the backchannel
ianco (Thu, 07 May 2020 20:10:50 GMT):
... so updates are pretty quick, if you're the VCX backchannel developer guy
ianco (Thu, 07 May 2020 20:11:34 GMT):
The extra VCX stuff could be added to a published base image for sure
swcurran (Thu, 07 May 2020 20:12:03 GMT):
Yes - the joy od docker! I'm making it so you can build some or all, so that for the quick demo run, we skip the vcx build.
swcurran (Thu, 07 May 2020 20:12:03 GMT):
Yes - the joy of docker! I'm making it so you can build some or all, so that for the quick demo run, we skip the vcx build.
ianco (Thu, 07 May 2020 20:12:46 GMT):
... the other issue is that when we publish the von image, we strip out a lot of the development tools, so those need ot be added back in to build VCX
swcurran (Thu, 07 May 2020 20:12:48 GMT):
What we can also do is a "vcxX.Y" dockerfile so that we can have a pre-built image.
swcurran (Thu, 07 May 2020 20:13:33 GMT):
Yes - we have can have a VCX image that everyone except the VCX Backchannel Maintainer uses.
sheldon.regular (Thu, 07 May 2020 20:48:34 GMT):
I see what your saying, but flexibility = complexity. We just need to be as flexible as makes it reasonable for 80% of users. When you say many different reasons, that worries me a little... the goal I've been working with is that this is used to verify that a new or updated Agent conforms to the Interop Profile. In that case, I still see the AUT making sense, especially if they are going to do multiple runs, switching their Agent to different roles. Looking back on the results of their runs, they are going to want to know which role it played in that specific execution.
Also if we may want to store and use the result data in some sort of long term trends and analytics across agents and executions, then understanding which role the new or updated agents played may be important. Though this long term amalgamated reporting is a requirement I haven't heard about and have only thought about.
swcurran (Thu, 07 May 2020 21:41:51 GMT):
The test harness is more than that. There are definitely more use cases then just AIP. Ad hoc testing to find out if an update works with other all of the other agents out there means running the tests for each other agent. If a single agent becomes the reference agent and conformance is defined as capability with that agent, then it's possible each independent agent could just test against that. I think that will take a long time and in the meantime, we want to run against all the agents we can find.
swcurran (Thu, 07 May 2020 21:42:33 GMT):
I don't think the code complexity goes up because of this. The ability to easily run the tests goes up.
swcurran (Thu, 07 May 2020 21:43:25 GMT):
For example, almost immediately, we need a "-f config_file" option that will have the list of options to use.
swcurran (Thu, 07 May 2020 21:44:19 GMT):
I'm guessing we will want more info in the output to be able to easily create such a file.
swcurran (Thu, 07 May 2020 21:44:48 GMT):
These are things we'll evolve as we use this and want to simplify things. But these are all just eye-candy around the core.
sheldon.regular (Fri, 08 May 2020 19:09:39 GMT):
@ianco @swcurran FYI, for now, the "test" that sets up the Schema and Cred Def, etc, is moved into a Background Section. This means it runs for every scenario setting that stuff up. It was the path of least resistance. If it makes sense, we can go back later and move it totally into the backchannel. This is what it looks like in the feature file.
Background: create a schema and credential definition in order to issue a credential
Given "Acme" has a public did
When "Acme" creates a new schema
And "Acme" creates a new credential definition
Then "Acme" has an existing schema
And "Acme" has an existing credential definition
swcurran (Fri, 08 May 2020 19:10:21 GMT):
k - no problem. Don't think it moves us forward.
TimoGlastra (Sat, 09 May 2020 22:42:16 GMT):
Has joined the channel.
TimoGlastra (Sun, 10 May 2020 08:56:42 GMT):
aries-framework-javascript is currently under development. If we want to add conformance testing to the framework is adding a backchannel to the agent-test-harness repo for framework javascript the recommended approach at the moment? Or should protocol-test-suite be used for now? Is this a direct replacement for protocol test-suite?
swcurran (Mon, 11 May 2020 13:43:32 GMT):
Hi Timo - interesting questions. We are building out AATH so that we can do interop testing between any libraries. It will lead to conformance testing as the community converges on a reference agent to test against. For now that is probably aca-py, but doesn't have to be. But you can definitely test against ACA-Py today and we're going to be adding more backchannels - notably one for aries-framework-dotnet.
As to the state of protocol test suite - we're not a proponent of the APTS approach, hence why we started this effort. We think the ability to mix and match agents in tests is more important than just going against one test suite. AATH is not a direct replacement for APTS. The initial creator of APTS has left the community, and AFAIK there is only one or two other contributors.
TimoGlastra (Tue, 12 May 2020 10:10:25 GMT):
Thank you for the detailed explanation, @swcurran. I just learned about the test harness and it seemed like a good approach to me so thats why I was curious. I will look into adding a backchannel for aries-framework-javascript. As the backchannel for the javascript framework will be written in javascript instead of python making an open-api-spec/swagger would ease creating a new backchannel. This way the server boilerplate could be generated using tools such as openapi-generator. don't know if it could be generated from the operations csv, but it would be useful to have nevertheless. Do you share this vision with me?
TimoGlastra (Tue, 12 May 2020 10:10:25 GMT):
Thank you for the detailed explanation, @swcurran . I just learned about the test harness and it seemed like a good approach to me so thats why I was curious. I will look into adding a backchannel for aries-framework-javascript. As the backchannel for the javascript framework will be written in javascript instead of python making an open-api-spec/swagger would ease creating a new backchannel. This way the server boilerplate could be generated using tools such as openapi-generator. don't know if it could be generated from the operations csv, but it would be useful to have nevertheless. Do you share this vision with me?
swcurran (Tue, 12 May 2020 13:45:14 GMT):
Yes - that's sounds right to me. @ianco and @sheldon.regular -- your thoughts?
sheldon.regular (Tue, 12 May 2020 14:46:35 GMT):
Yes, I like that idea.
swcurran (Thu, 14 May 2020 00:00:11 GMT):
@sheldon.regular @ianco -- updated ./manage to be able to pass in a behave.ini file to try to get around the problem of passing in complex tags. However, if with that, I can't get the "not @wip" syntax working with behave. Verified the behave.ini is working and I can pass different combination of config settings in, but that does not work.
I'm trying to say `tags = @AcceptanceTest and not @wip`, but whenever I use the "not", none of the tests run. Checked examples on the internet and that's supposed to work...
swcurran (Thu, 14 May 2020 00:01:01 GMT):
I'm thinking that I change the tag to "@Acceptancewip" so it doesn't pick those up on a run. Any other ideas?
swcurran (Thu, 14 May 2020 00:01:48 GMT):
I'm planning on reorging the backchannels folder next, to put each agent/agent-framwork in their own folder, with (possibly) multiple dockerfiles.
swcurran (Thu, 14 May 2020 00:02:41 GMT):
Also improved the shutdown to speed it up a bit.
sheldon.regular (Thu, 14 May 2020 14:24:55 GMT):
Did you try the ~ instead of not. This sequence seems to work for me. ```behave --tags=~@wip --tags=@AcceptanceTest -k```
sheldon.regular (Thu, 14 May 2020 14:24:55 GMT):
@swcurran Did you try the ~ instead of not. This sequence seems to work for me. ```behave --tags=~@wip --tags=@AcceptanceTest -k```
swcurran (Thu, 14 May 2020 14:44:26 GMT):
I'll try it! Didn't find that in any docs...
sheldon.regular (Thu, 14 May 2020 16:01:07 GMT):
I approved the PR, but you may want to get that not @wip stuff in first before you merge.
swcurran (Thu, 14 May 2020 16:06:17 GMT):
Yup!
redongjun (Sun, 24 May 2020 06:22:49 GMT):
Has joined the channel.
AmolDeshpande (Wed, 03 Jun 2020 10:35:44 GMT):
Has joined the channel.
Jintolus (Wed, 03 Jun 2020 13:49:16 GMT):
Has joined the channel.
TimoGlastra (Mon, 29 Jun 2020 18:28:09 GMT):
User User_1 added by TimoGlastra.
TimoGlastra (Mon, 29 Jun 2020 18:28:09 GMT):
User User_2 added by TimoGlastra.
TimoGlastra (Mon, 29 Jun 2020 18:28:09 GMT):
User User_3 added by TimoGlastra.
TimoGlastra (Mon, 29 Jun 2020 18:49:29 GMT):
Hi AATH implementors, in the next two months we at ANIMO will join you in building out the test harness. We'll work on the 'code with us' challenge from BCGov and create a backchannel for Aries Framework .NET. I'll be doing this with my colleagues @AnaGoessens and @karimStekelenburg1 .
TimoGlastra (Mon, 29 Jun 2020 18:49:45 GMT):
At the moment we're working on Aries Framework JavaScript and are just getting familiar with the test harness and its codebase. We're excited to work with you and will start implementing in the coming week.
TimoGlastra (Tue, 30 Jun 2020 19:28:45 GMT):
Looking at the endpoints in the "Backchannel API" tab in the spreadsheet (https://docs.google.com/spreadsheets/d/1r40t6TRAoMrmDO7vM_o6eOmk6jvxUr189wZVNBcdgVs/edit#gid=1282646420) and the README from the aries-backchannels (https://github.com/bcgov/aries-agent-test-harness/tree/master/aries-backchannels#standard-backchannel-api) there is nothing documented about the `/agent/response` endpoint. However looking at the code this endpoint is definitely used. Is the documentation about this endpoint outdated? Also looking at the operations csv/spreadsheet there are `/agent/response` requests marked as POST requests, however the code only listens for GET requests for `/agent/response` (https://github.com/bcgov/aries-agent-test-harness/blob/master/aries-backchannels/python/agent_backchannel.py#L160-L164). Is the code leading in this case? And if so, would you like me to update the documentation/spreadsheet?
ianco (Wed, 01 Jul 2020 16:35:14 GMT):
The `/agent/response` endpoint isn't used and can be removed from the code. (I thought it was previously removed but I guess I' mistaken!)
swcurran (Wed, 01 Jul 2020 17:30:34 GMT):
I did remove the endpoints that are not used in an earlier PR - about a month ago.
TimoGlastra (Wed, 01 Jul 2020 18:15:09 GMT):
Looking at the commit history it was added back in a month ago. But if the endpoint is not used and needed I won't implement it
TimoGlastra (Wed, 01 Jul 2020 18:15:26 GMT):
https://github.com/bcgov/aries-agent-test-harness/commit/ca011c76da90134c8c0d176bd5f9ff6b25d31595
swcurran (Wed, 01 Jul 2020 18:50:12 GMT):
Dang...
sheldon.regular (Thu, 02 Jul 2020 16:24:03 GMT):
Hi Guys, Welcome @TimoGlastra. Just wanted to mention that I added the /agent/response GETs back in because they are being used in the tests to retrieve the webhook info.
TimoGlastra (Tue, 07 Jul 2020 11:49:54 GMT):
Hi Guys, small hiccup with implementing the connection operations. The test harness separates the receiving and accepting of an invitation. Framework .NET can’t receive a connection without accepting it. Approach I started out with is storing the invitation in memory until accept-invitation operation is received and then passing it to the framework. However the connection id is generated on the accept-invitation step, which means I can’t return the connection id on the receive-invitation step.
I see multiple ways to resolve this, each requiring a change in a different place:
1. change the internals of .NET framework to allow to pass a connection id when accepting - would need to discuss with Tomislav
2. Create the connection and connection request message, but keep the connection-request message in memory without sending until the accept-invitation operation is received (technically this makes the .NET framework state invalid).
3. Same as step 2, but already send it (and do nothing when accept-invitation is received). (Same as VCX I think)
4. Change the test harness client to remove receive-invitation.
I would appreciate hearing your thoughts and opinions on this
TimoGlastra (Tue, 07 Jul 2020 11:50:04 GMT):
F``ine with all approaches, but If you’d ask me I think I’ll lean towards removing the receive-invitation operation. It would make the .NET implementation simpler (no in memory storage of messages and invitations needed to keep track of actual state vs expected state) and also because the receive-invitation is imo more an aca-py specific operation than part of the connection protocol.
TimoGlastra (Tue, 07 Jul 2020 11:50:04 GMT):
Fine with all approaches, but If you’d ask me I think I’ll lean towards removing the receive-invitation operation. It would make the .NET implementation simpler (no in memory storage of messages and invitations needed to keep track of actual state vs expected state) and also because the receive-invitation is imo more an aca-py specific operation than part of the connection protocol.
sheldon.regular (Tue, 07 Jul 2020 12:43:54 GMT):
@TimoGlastra Just so I'm clear we are talking about the same things, which two Gherkin lines are in question here? I'm assuming it's lines 3 and 4?
```
When "Acme" generates a connection invitation (create-invitation)(RFC: send invitation)
And "Bob" receives the connection invitation (receive-invitation)(RFC: receive invitation)
And "Bob" sends a connection request to "Acme" (accept-invitation)(RFC: send connection-request)
And "Acme" receives the connection request (nothing done here in tests except check connection status of inviter)(RFC: receive connection-request)
And "Acme" sends a connection response to "Bob" (accept-request)(RFC: send connection-response)
And "Bob" receives the connection response (nothing done here in tests except check connection status of invitee)(RFC: receive connection-response)
And "Bob" sends
TimoGlastra (Tue, 07 Jul 2020 13:42:32 GMT):
I'm talking about lines 2 and 3 here. So receive-invitation and accept-invitation
swcurran (Tue, 07 Jul 2020 13:46:34 GMT):
My guess is that we do step 4 as indicated. That is an ACA-Py-ism, I think and the ACA-Py backchannel can address it.
swcurran (Tue, 07 Jul 2020 13:47:08 GMT):
Or to put it another way --- what does the RFC say? Is there a need for that step per the RFC.
sheldon.regular (Tue, 07 Jul 2020 13:58:15 GMT):
This may put some strain on the RFC verbiage. The way the Gherkin is written is what that RFC says. There are 3 distinct parts to the protocol, the invitation, the connection request, and the connection response. If I'm reading @TimoGlastra right, there is a blurring of the lines between invitation and connection request in the .Net Agent. @TimoGlastra, what happens in the .Net Agent for lines 3 and 4?
TimoGlastra (Tue, 07 Jul 2020 15:20:11 GMT):
I see what you mean. For line 3 a connection request is send to the other agent. For line 4 nothing happens (this is already done A2A via didcomm)
sheldon.regular (Tue, 07 Jul 2020 15:40:43 GMT):
hmmm, so it sounds like you are fine. In the 2nd line of gherkin, could you not just do both receive-invitation and accept-invitation in the .Net backchannel? Just because line 3 calls the accept-invitation from the aca-py admin API doesn't mean you have to on your side. You would just catch the name of the operation and call whatever accomplishes the goal of line 3. This was the first test written and it was more closely matched to what the aca-py admin api expects in terms of operations. I could of (and probably will later) change the operation to send-connection-request, then catch that in the aca-py backchannel and change the operation to accept-invitation.
nc-crtr_linx (Tue, 07 Jul 2020 15:57:42 GMT):
Has joined the channel.
TimoGlastra (Tue, 07 Jul 2020 16:30:02 GMT):
Yeah that would work. Just wanted to be sure before doing this as it makes the actual process different than the described process
swcurran (Tue, 07 Jul 2020 20:49:00 GMT):
Good conversation here as things brings out good issues. There are 4 (or more) things that could be wrong:
- The RFC may not be clear or may even be incorrect - correct it.
- The Test case may not follow the RFC correctly - correct it
- One of the Backchannels may not be implemented correctly. - correct one, the other or both.
We need to evaluate where a discrepancy is -- as you did above.
I'm sure I'm preaching to the choir on this, but this might be good to add to the documentation (if not there already), to foster the right discussion as we add test cases and backchannels.
TimoGlastra (Thu, 09 Jul 2020 21:24:18 GMT):
After rereading the connection protocol RFC my conclusion is that both the RFC and the Gherkin test are correct (I withdraw my previous statement) and the discrepancy lies in the fact that the test harness expects a connection id as a response to the receive-invitation operation, which the .NET framework does not support.
TimoGlastra (Thu, 09 Jul 2020 21:24:25 GMT):
So we should either send the request in the receive-invitation (diverge from the narrative of the test) OR change the internals of .NET OR don’t pass the connection id, but pass the invitation id as the id for the accept-invitation operation. For the narrative this makes sense: Receive this invitation with this id, then accept the invitation with this invitation id. However it makes the story more complex as the ID changes from invitation to connection id in the middle of the story.
TimoGlastra (Thu, 09 Jul 2020 21:24:31 GMT):
For now I’ll create, but not send the connection request message in the receive-invitation operation. This will make it work with both the .NET framework and the test harness. But I’m open to change this for an alternative solution.
swcurran (Fri, 10 Jul 2020 00:03:14 GMT):
My $0.02CDN -- I think the transition from invitation ID to connection ID mid-test is reasonable. In an agent, both are "first class citizens" that agent developers will recognize. An invitation ID is a single-use (or single-purpose) concept during the connection establishment. Thereafter, each party records and tracks the connection ID, and that is tracked as part of subsequent protocols. We also might name the ID for the participants "Acme has a connection with Bob" implies ACME has (or creates) a connectionID called "Bob", and it is for the backchannel to track that. [Note - it probably is already doing that...].
The other major concept/ID that I think should be first class in tests is a "protocolID" or "threadID" (could have a different, protocol specific names -- "cred-issue-id", "pres-proof-id", etc.). This is what is tracked over the life of the execution of a protocol, and then is gone (unlike a connection). It is associated with a connectionID (who the other party is). The "cred_ex_Id" in ACA-Py is really a threadID. The ID name could be unique for each protocol, and could be named for the protocol being executed.
swcurran (Fri, 10 Jul 2020 00:03:35 GMT):
Awesome to see these conversations. This will really help get us to something generally useful.
JelleFm (Fri, 10 Jul 2020 11:43:20 GMT):
Has joined the channel.
Moshe7 (Fri, 31 Jul 2020 20:54:36 GMT):
Has joined the channel.
Mahadevan 3 (Wed, 05 Aug 2020 20:37:10 GMT):
Has joined the channel.
lauravuo-techlab (Tue, 11 Aug 2020 06:01:47 GMT):
Has joined the channel.
blaz (Tue, 11 Aug 2020 13:57:06 GMT):
Has joined the channel.
lalchandran (Tue, 18 Aug 2020 16:35:25 GMT):
Has joined the channel.
lalchandran (Tue, 18 Aug 2020 16:35:25 GMT):
I have some specific questions around running aries-mobileagent-xamarin. Which is the right channel to ask?
TimoGlastra (Tue, 18 Aug 2020 16:39:02 GMT):
I’d go with #aries-framework-dotnet , aries-mobileagent-xamarin is built on top of that
lalchandran (Tue, 18 Aug 2020 16:39:20 GMT):
Super. Thanks @TimoGlastra
swcurran (Wed, 19 Aug 2020 16:48:00 GMT):
FYI @TimoGlastra -- @WadeBarnes is going to be addressing some DCO issues within the AATH repo. Beware that there will be a bit of history rewriting that may require you to stash/apply your current work.
WadeBarnes (Wed, 19 Aug 2020 16:48:00 GMT):
Has joined the channel.
swcurran (Wed, 19 Aug 2020 16:48:08 GMT):
We've merged all the pending PRs.
WadeBarnes (Wed, 19 Aug 2020 17:39:54 GMT):
Sign-offs fixed, history rewritten. Starting transfer to Hyperledger.
WadeBarnes (Wed, 19 Aug 2020 17:56:03 GMT):
Transfer complete; https://github.com/hyperledger/aries-agent-test-harness
swcurran (Wed, 19 Aug 2020 20:42:27 GMT):
w00t!!!
swcurran (Wed, 19 Aug 2020 20:42:29 GMT):
Nice
swcurran (Wed, 19 Aug 2020 20:42:36 GMT):
Thanks for that!
dipghosh (Fri, 21 Aug 2020 08:22:18 GMT):
Has joined the channel.
dipghosh (Fri, 21 Aug 2020 08:22:19 GMT):
Hi all, I have set up the vc-authn-oidc on the web and its working fine and we can do log in on the web, Is there any sample app which does the same as with vc-authn-oidc.
sebastian (Tue, 01 Sep 2020 16:00:30 GMT):
Has joined the channel.
kukgini (Thu, 03 Sep 2020 06:15:15 GMT):
Has joined the channel.
hcsatish (Sun, 20 Sep 2020 16:04:31 GMT):
Has joined the channel.
sheldon.regular (Mon, 21 Sep 2020 19:20:01 GMT):
Hi Everyone, I wanted to make you aware of a new set of test scenarios that are under development for Revocation. The Gherkin has been defined and the feature file submitted to the repo. I’m looking for others to review the scenarios, looking for inaccuracies, cases that may be missed, and even better ways to express any steps. Any comments and opinions would be greatly appreciated. These scenarios may change a little naturally as coding continues, some may even merge together if it is deemed efficient to combine. The feature file is located here, https://github.com/hyperledger/aries-agent-test-harness/blob/master/aries-test-harness/features/0011-0183-revocation.feature
chakshujain (Fri, 02 Oct 2020 14:50:43 GMT):
Has joined the channel.
SamB (Mon, 05 Oct 2020 05:27:19 GMT):
Has joined the channel.
lmtriet (Sat, 24 Oct 2020 14:41:53 GMT):
Has joined the channel.
ianco (Sat, 07 Nov 2020 13:49:38 GMT):
FYI github actions have been added to the AATH repository: https://github.com/hyperledger/aries-agent-test-harness/actions
ianco (Sat, 07 Nov 2020 13:50:16 GMT):
The test harness runs automatically every day running 3 scenarios: acapy/acapy, dotnet/dotnet and acapy/dotnet
ianco (Sat, 07 Nov 2020 13:50:39 GMT):
The agents are built from their respective github repo's, master branch
WadeBarnes (Sat, 07 Nov 2020 16:25:42 GMT):
:tada:
marc0olo (Mon, 30 Nov 2020 04:50:02 GMT):
Has joined the channel.
cmendoza (Tue, 01 Dec 2020 21:25:40 GMT):
Has joined the channel.
EtricKombat (Mon, 28 Dec 2020 11:08:22 GMT):
Has joined the channel.
ianco (Mon, 11 Jan 2021 19:38:22 GMT):
User User_4 added by ianco.
swcurran (Fri, 15 Jan 2021 17:04:08 GMT):
@ianco -- got an error in running the test harness in the compare script:
```
------------------COMPARE-RESULTS------------------
(Note that KGR filenames are relative to
ianco (Fri, 15 Jan 2021 17:06:41 GMT):
@swcurran can you attach the KGR file?
ianco (Fri, 15 Jan 2021 17:06:41 GMT):
~@swcurran can you attach the KGR file?~
ianco (Fri, 15 Jan 2021 17:08:18 GMT):
... actually scratch that, it looks like an issue with one of the `.json` files in the `allure-results` directory
ianco (Fri, 15 Jan 2021 17:08:57 GMT):
can you delete `./aries-test-harness/allure/allure-results/*.json` and then try again?
ianco (Fri, 15 Jan 2021 17:09:55 GMT):
I'll update the script to ignore non-test-result-json files
swcurran (Fri, 15 Jan 2021 17:13:29 GMT):
Running...
swcurran (Fri, 15 Jan 2021 17:32:57 GMT):
OK -- that worked without error the first time. Then I copied the KGR file to the expected and reran and got this error (presumably the same as before):
```
------------------COMPARE-RESULTS------------------
(Note that KGR filenames are relative to
ianco (Fri, 15 Jan 2021 17:34:07 GMT):
ok I'm testing now on my local
ianco (Fri, 15 Jan 2021 17:57:41 GMT):
possibly an issue with the test results recorded for the new did exchange test ...
kukgini (Mon, 25 Jan 2021 10:53:54 GMT):
Has left the channel.
Helen_Garneau (Thu, 04 Feb 2021 15:09:42 GMT):
Has joined the channel.
janl (Thu, 04 Feb 2021 15:18:23 GMT):
Has joined the channel.
JackyYuan (Tue, 23 Feb 2021 20:53:43 GMT):
Has joined the channel.
dgt1nsty (Sat, 27 Feb 2021 07:24:42 GMT):
Has joined the channel.
lohan.spies (Mon, 01 Mar 2021 15:21:46 GMT):
Has joined the channel.
MoShishi (Mon, 01 Mar 2021 16:30:06 GMT):
Has joined the channel.
rpobulic (Sun, 07 Mar 2021 05:14:26 GMT):
Has joined the channel.
swcurran (Thu, 11 Mar 2021 23:46:30 GMT):
User User_5 added by swcurran.
iamgollum (Sun, 04 Apr 2021 20:35:11 GMT):
Has joined the channel.
swcurran (Wed, 07 Apr 2021 23:33:14 GMT):
@sheldon.regular @TimoGlastra -- can we add tags on `Examples` in tests? For example:
```
Examples:
| credential_data | updated_credential_data | format |
| Data_DL_MaxValues | Data_DL_NormalizedValues | indy |
```
Could we add a tag (or something) that indicates
swcurran (Wed, 07 Apr 2021 23:58:02 GMT):
@sheldon.regular @TimoGlastra -- can we add tags on `Examples` in tests? For example:
```
Examples:
| credential_data | updated_credential_data | format |
| Data_DL_MaxValues | Data_DL_NormalizedValues | indy |
| Data_DL_MaxValues | Data_DL_NormalizedValues | json-ld |
```
Could we add a tag (or something) that indicates the test requires indy for the first example, and json-ld for the second? If we could do that, we could tag things at the Feature, Scenario and Example (is that the right name?) levels. If we can do that, we can do a lot more with examples.
Further, once each agent is started, we ask each "You are playing role X, what tags do you support/not-support?" and the backchannel responds with a list. We combine those to construct the input to behave to define the set of tests to be run. Not quite sure how we combine them together.
TimoGlastra (Thu, 08 Apr 2021 08:36:12 GMT):
We can do the following. So not exactly what you mean, but it reaches the same goal:
```
@CredFormat_Indy
Examples:
| credential_data | updated_credential_data
| Data_DL_MaxValues | Data_DL_NormalizedValues
@CredFormat_JSON-LD
Examples:
| credential_data | updated_credential_data
| Data_DL_MaxValues | Data_DL_NormalizedValues
@CredFormat_Indy @CredFormat_JSON-LD
Examples:
| credential_data | updated_credential_data
| Data_DL_MaxValues | Data_DL_NormalizedValues
```
swcurran (Thu, 08 Apr 2021 14:46:59 GMT):
To be clear -- if we did that and specified the tag `@CredFormat_Indy`, only the first and third examples would run, correct? That would be more concise than what we have today.
So that can be attached to a scenario, in that format -- e.g. the whole snippet as you have it above.
sheldon.regular (Thu, 08 Apr 2021 15:15:30 GMT):
Ok, that feature is not documented very well. I had no idea Example tags existed. Not in any documentation and only one closed issue from 2016. Oh well. That does change things, and would make a much cleaner solution. I just tried those tags out. They just stuff the Example tag in the Scenario tags at runtime. So the behaviour is the same, the code is even the same (since it already checks for that CredFormat tag in the scenario, but the feature file will be much simpler. The cred format doesn't need to be mentioned in the steps either like `When "Bob" proposes a "indy" credential to "Acme" with
TimoGlastra (Fri, 09 Apr 2021 10:02:56 GMT):
@sheldon.regular https://behave.readthedocs.io/en/latest/new_and_noteworthy_v1.2.6.html?highlight=examples#index-0 . It's only mentioned in the release notes
sheldon.regular (Fri, 09 Apr 2021 15:32:05 GMT):
Love it. I'm using it already.
lohan.spies (Mon, 12 Apr 2021 06:58:10 GMT):
Good morning
lohan.spies (Mon, 12 Apr 2021 06:58:43 GMT):
I want to use the test harness for our controller... a bit lost on the setup and how we can do achieve this.
lohan.spies (Mon, 12 Apr 2021 06:58:43 GMT):
I want to use the test harness for our controller... a bit lost on the setup and how we can achieve this.
lohan.spies (Mon, 12 Apr 2021 06:59:03 GMT):
Any pointers on where to start with the test harness from some experts in the group?
TimoGlastra (Mon, 12 Apr 2021 08:07:47 GMT):
Good morning @lohan.spies , could you clarify a bit on what you mean on using the test harness for your controller? Do you want to create a backchannel that talks to your agent controller?
lohan.spies (Mon, 12 Apr 2021 10:36:10 GMT):
Hi @TimoGlastra yes, would need to create a backchannel to test our controller - https://github.com/didx-xyz/aries-cloudcontroller-python/
lohan.spies (Mon, 12 Apr 2021 10:36:28 GMT):
With an AcaPy agent
TimoGlastra (Mon, 12 Apr 2021 11:00:16 GMT):
I think the aries-backchannels README is a good place to start: https://github.com/hyperledger/aries-agent-test-harness/tree/master/aries-backchannels/README.md To get started I think extending from the generic agent_backchannel.py (https://github.com/hyperledger/aries-agent-test-harness/blob/master/aries-backchannels/python/agent_backchannel.py) can help with some of the setup. The ACA-Py, AFGO and mobile backchannels all use this I believe. As you are still using an ACA-Py as agent and calling it through your own custom library it may even be worthwhile to start from the ACA-Py backchannel. The open api can give guidance on the API endpoints a backchannel needs to support: https://aries-interop.info/api
TimoGlastra (Mon, 12 Apr 2021 11:03:06 GMT):
I do want to note however that I'm not sure if AATH is the correct solution to test your controller. It's the exact same agent (ACA-Py) being tested, so it's not testing for interoperability, more if the controller you wrote is working with ACA-Py -- However I think @swcurran has a better opinion on that.
swcurran (Tue, 13 Apr 2021 00:18:27 GMT):
I think there are a couple of reasons for doing or not doing this. The intention I've always had is that the "CUT" (Component Under Test) can be anything -- framework or full agent, -- so it's reasonable to have such a backchannel. The two reasons I think for doing it are (a) because there is enough happening in the controller that it is worth testing the full agent in addition to the framework, and (b) to have a (hopefully) easy way to access a maintained set of tests to execute as part of the CI process.
lohan.spies (Tue, 13 Apr 2021 18:23:47 GMT):
Hi @swcurran that is exactly my thinking and what I would like to achieve.
swcurran (Tue, 13 Apr 2021 18:28:47 GMT):
Cool. So the guidance that Timo gave up is good for getting started. Basically, you need to create a docker container that contains your entire test "thingy" (e.g. your controller and an aca-py agent), plus a "backchannel" -- an API service that responds to requests from the test harness, (somehow) kicks your controller to do stuff, and provides responses back to the test harness about the status. There are a couple of examples already of what a backchannel looks like that you can start from.
swcurran (Tue, 13 Apr 2021 18:29:43 GMT):
Since this is the first full agent to get a backchannel, you may come across things that we should change in the test harness to make it easier. Don't hesitate to ask questions and propose changes to make things easier to do.
lohan.spies (Tue, 13 Apr 2021 18:30:34 GMT):
Thank you. Will have a look and come back with questions
swcurran (Tue, 13 Apr 2021 18:31:39 GMT):
Also, if it would help, @sheldon.regular and/or @ianco would (I'm sure :) ) be happy to jump on a call to go over concepts, or field questions.
lohan.spies (Tue, 13 Apr 2021 18:32:41 GMT):
That would really be appreciated and speed up the process to get going.
sheldon.regular (Tue, 13 Apr 2021 18:52:10 GMT):
Yes, I'd love to get together to answer any questions. Hit me up anytime @lohan.spies, we can get together as much as you need to move your effort along. If you haven't already, you may want to just run through the execution of the acapy tests to get a feel for how they work. I have a feeling your backchannel will be very similar to the [acapy_backchannel](https://github.com/hyperledger/aries-agent-test-harness/blob/master/aries-backchannels/acapy/acapy_backchannel.py) Timo mentioned.
smithbk (Fri, 16 Apr 2021 16:13:47 GMT):
I just tried to run AATH for the 1st time using instructions at https://github.com/hyperledger/aries-agent-test-harness#aries-agent-test-harness-smashing-complexity-in-interoperability-testing and when running `./manage run -d acapy -b dotnet -t @AcceptanceTest -t ~@wip` it does not find the `dotnet-agent-backchannel:latest` image. It looks like it built but tagged it incorrectly perhaps? Any ideas?
Also, it would be nice if there is a failure like this that it would terminate immediately so that I can easily see the first failure. Is there a way to run it this way? Here is my output.
./manage run -d acapy -b dotnet -t @AcceptanceTest -t ~@wip
Agents to be used:
Acme - acapy
Bob - dotnet
Faber - acapy
Mallory - acapy
Tags: --tags=@AcceptanceTest --tags=~@wip
waiting for ledger to start
waiting for tails server to start
Starting Acme Agent ...
Starting Bob Agent ...
Unable to find image 'dotnet-agent-backchannel:latest' locally
docker: Error response from daemon: pull access denied for dotnet-agent-backchannel, repository does not exist or may require 'docker login': denied: requested access to the resource is denied.
See 'docker run --help'.
Starting Faber Agent ...
Starting Mallory Agent ...
ianco (Fri, 16 Apr 2021 16:18:34 GMT):
did you build the images with `./manage build -a acapy -a dotnet`?
ianco (Fri, 16 Apr 2021 16:19:13 GMT):
... or what command did you use to build the images?
smithbk (Fri, 16 Apr 2021 22:53:36 GMT):
yes ... I followed the directions posted
ianco (Fri, 16 Apr 2021 23:09:53 GMT):
I'm guessing there was an error building the dotnet docker image (these are easy to miss because the `./manage build` job doesn't stop, it just continues on to the next image)
smithbk (Sat, 17 Apr 2021 22:45:25 GMT):
Yes, here are the errors ...
Step 8/12 : RUN dotnet publish "DotNet.Backchannel.csproj" -c Release -o /app/publish
---> Running in 7c19f7f1df0e
Microsoft (R) Build Engine version 16.7.1+52cd83677 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
Handlers/PresentationAckHandler.cs(43,41): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. [/src/DotNet.Backchannel.csproj]
Controllers/IssueCredentialController.cs(133,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/PresentProofController.cs(85,42): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. [/src/DotNet.Backchannel.csproj]
Controllers/ConnectionController.cs(129,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/ConnectionController.cs(148,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/ConnectionController.cs(173,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/IssueCredentialController.cs(225,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/IssueCredentialController.cs(245,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/PresentProofController.cs(131,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/IssueCredentialController.cs(262,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/PresentProofController.cs(157,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
Controllers/PresentProofController.cs(188,35): error CS7036: There is no argument given that corresponds to the required formal parameter 'endpointUri' of 'IMessageService.SendAsync(Wallet, AgentMessage, string, string, string[], string)' [/src/DotNet.Backchannel.csproj]
The command '/bin/sh -c dotnet publish "DotNet.Backchannel.csproj" -c Release -o /app/publish' returned a non-zero code: 1
sheldon.regular (Sat, 17 Apr 2021 22:50:06 GMT):
Not sure what is going on with the `latest`. Can you try with dotnet-master?
`./manage build -a acapy-main -a dotnet-master`
sheldon.regular (Sat, 17 Apr 2021 22:51:56 GMT):
Also a cleaner run command for acapy with dotnet is `./manage run -d acapy-main -b dotnet-master -t @AcceptanceTest -t ~@wip -t ~@ProofProposal -t ~@RFC0023 -t ~@DIDExchangeConnection` This will exclude things not supported yet.
smithbk (Sun, 18 Apr 2021 11:39:33 GMT):
The build works but then the following ...
$ ./manage run -d acapy-main -b dotnet-master -t @AcceptanceTest -t ~@wip -t ~@ProofProposal -t ~@RFC0023 -t ~@DIDExchangeConnection
All agents Acme, Bob, Faber and Mallory must be set to one of: acapy acapy-master afgo-master dotnet dotnet-master javascript vcx .
Use "./manage help" to get more information.
$ ./manage run -d acapy -b dotnet -t @AcceptanceTest -t ~@wip
Agents to be used:
Acme - acapy
Bob - dotnet
Faber - acapy
Mallory - acapy
Tags: --tags=@AcceptanceTest --tags=~@wip
waiting for ledger to start
waiting for tails server to start
Acme Agent already running, skipping...
Starting Bob Agent ...
Unable to find image 'dotnet-agent-backchannel:latest' locally
TimoGlastra (Sun, 18 Apr 2021 14:50:34 GMT):
I think the dotnet container (without master) is not working anymore. The code in this repo is updated to work with the master version, breaking the latest released script. I've run the build and run commands exactly as posted by sheldon. Could you try to remove all your images and try again? Most of the times that something is not working, deleting all images and rebuilding does the trick
TimoGlastra (Sun, 18 Apr 2021 14:50:34 GMT):
I think the dotnet container (without master) is not working anymore. The code in this repo is updated to work with the master version, breaking the latest released script. I've run the build and run commands exactly as posted by Sheldon and they work for me. Could you try to remove all your images and try again? Most of the times that something is not working, deleting all images and rebuilding does the trick
TimoGlastra (Sun, 18 Apr 2021 14:50:34 GMT):
I think the dotnet container (without master) is not working anymore. The code in this repo is updated to work with the master version, breaking the latest released script. I've run the build and run commands exactly as posted by Sheldon and they work for me. Could you try to remove all your images and try again? Most of the times that something is not working, deleting all images and rebuilding does the trick for me
smithbk (Mon, 19 Apr 2021 19:22:59 GMT):
I'll have to try this again later when I have time to rebuild my world since I have so many other images ... or will try 1st to delete just images with dotnet in the name 1st
swcurran (Mon, 19 Apr 2021 19:31:17 GMT):
It looks like you might have a not up to date version. the error on the first command shows that "acapy-master" is used instead of "acapy-main". That was changed a long time ago.
I don't think you need to do anything as extreme as deleting all your images, but you do have to make sure that none of the relevant ones are running -- such as the case with "Acme Agent already running..."
Not sure of that last message about the missing image. That's an odd one.
You do have to make sure that you build and run the same agents. Looks like you did, but I can't see the build command you ran.
swcurran (Mon, 19 Apr 2021 19:31:17 GMT):
It looks like you might have a not up to date version of the repo. The error on the first "run" command shows that "acapy-master" is a valid test agent name, used instead of "acapy-main". That change from master to main was made long ago in the repo.
I don't think you need to do anything as extreme as deleting all your images, but you do have to make sure that none of the relevant ones are running -- such as the case with "Acme Agent already running..."
Not sure of that last message about the missing image. That's an odd one.
You do have to make sure that you build and run the same agents. Looks like you did, but I can't see the build command you ran.
swcurran (Mon, 19 Apr 2021 22:36:44 GMT):
@smithbk -- I just ran everything and it worked fine. I think the issues you might be having are:
- making sure you have the latest updates and
- being consistent in using `acapy-main` (not master or just acapy) and `dotnet-master` (not just dotnet) in both the build and run commands.
My guess because of your error is that in the build, you had used `dotnet-master` (per Sheldon's note), but in the run just `dotnet`.
I don't think there is a need to delete any docker images.
swcurran (Mon, 19 Apr 2021 23:01:14 GMT):
Here are the tests that I ran:
```
./manage build -a acapy-main -a dotnet-master
./manage run -d acapy-main -b dotnet-master -t @AcceptanceTest -t ~@wip -t ~@ProofProposal -t ~@RFC0023 -t ~@DIDExchangeConnection
Results:
3 features passed, 1 failed, 2 skipped
34 scenarios passed, 1 failed, 60 skipped
320 steps passed, 1 failed, 550 skipped, 0 undefined
Took 12m58.364s
```
smithbk (Tue, 20 Apr 2021 03:18:37 GMT):
@swcurran Thanks Stephen, that works
MoShishi (Thu, 22 Apr 2021 15:00:14 GMT):
Hey everyone 👋, new here and working with @lohan.spies on the YOMA project
lohan.spies (Thu, 22 Apr 2021 15:01:39 GMT):
@sheldon.regular want to introduce you to @MoShishi. He is looking into using the test harness for the controller we developed.
lohan.spies (Thu, 22 Apr 2021 15:01:39 GMT):
@sheldon.regular want to introduce you to @MoShishi . He is looking into using the test harness for the controller we developed.
lohan.spies (Thu, 22 Apr 2021 15:02:24 GMT):
Maybe we should setup a call as suggested
TimoGlastra (Thu, 22 Apr 2021 15:02:56 GMT):
Hi @MoShishi!
MoShishi (Thu, 22 Apr 2021 15:04:25 GMT):
cool to be here
sheldon.regular (Thu, 22 Apr 2021 15:05:16 GMT):
Hi @MoShishi Sure we can setup a call. What works best for you guys? I'm in Eastern Time.
MoShishi (Thu, 22 Apr 2021 15:12:37 GMT):
I'll have a scroll through the history so I won;t ask too many dublicate questions but will be implementing a testharness for the YOMA aries-agentcontroller these days (python). I've looked at the repo and am a bit lost still atm 😬 To be quite frank it's not really clear to me how to achieve running the test-harness against/with the controller we're building. From the readme it looks like we have to write our own backchannels implementation, but yeah some parts make sense to me, overall kinda lost where to start and how to do this really. Maybe you know of a repo that does what we're doing and could serrve as an example? ... any help much appreciated!
MoShishi (Thu, 22 Apr 2021 15:23:43 GMT):
hey @sheldon.regular awesome! Thanks in advance. sorry just saw that thread. I'm in european time. Anytime that's not early morning for me works (But I guess that's not gonna happen with you in eastern time anyway. Generally pretty flexible schedule-wise. I can do tomorrow/Monday/Tuesday - you name it...
sheldon.regular (Thu, 22 Apr 2021 15:49:11 GMT):
How about Monday at 9am my time? You are 6 hours ahead of me correct?
sheldon.regular (Thu, 22 Apr 2021 16:00:33 GMT):
@MoShishi have you tried to execute the tests that are there with an agent backchannel that is already there? Like acapy for instance? The pattern you will be following will be similar to the acapy backchannel or afgo backchannel. Once you have the tests running with acapy, look in the aries_backchannels folder for implementations of backchannels. You can find instructions on running the test harness here, https://github.com/hyperledger/aries-agent-test-harness.
You will be able to get the Test Harness running with these few commands.
```
git clone https://github.com/bcgov/von-network
cd von-network
./manage build
./manage start
cd ..
git clone https://github.com/bcgov/indy-tails-server
cd indy-tails-server/docker
./manage start
cd..
git clone https://github.com/hyperledger/aries-agent-test-harness
cd aries-agent-test-harness
./manage build -a acapy-main
./manage run -d acapy-main -t @AcceptanceTest -t ~@wip
```
Instructions on implementing backchannels can be found here, https://github.com/hyperledger/aries-agent-test-harness#aries-agent-backchannels
I'm sure it will be much clearer after we meet.
MoShishi (Fri, 23 Apr 2021 07:28:10 GMT):
Thanks so much already. Yes, I've tried running the tests that are already there. Just was a bit puzzled by what goes where and comes from where and how YOMAs agent controller can "plugged" in/how to write own backchannels. Felt like I'm missing a few things. But this is already helpful s thanks a bunch. Looking forward to the call
MoShishi (Fri, 23 Apr 2021 07:29:28 GMT):
sounds great! lets do that. yes, 6 hours ahead is correct. looking forward to it and thanks in advance
smithbk (Fri, 23 Apr 2021 13:00:10 GMT):
Could I join this call also since we're trying to write a backchannel as well?
swcurran (Fri, 23 Apr 2021 14:37:04 GMT):
Please include @alexgmetcalf if possible as well, to help with making the docs easier to navigate.
alexgmetcalf (Fri, 23 Apr 2021 14:37:04 GMT):
Has joined the channel.
sheldon.regular (Fri, 23 Apr 2021 16:30:26 GMT):
@MoShishi Something else that might help you and others is an AATH overview presentation done last year. https://drive.google.com/file/d/1jEfbV1_TWYYK73eFkUXYEAThAwdUOAdH/view?usp=sharing
justinmason (Mon, 26 Apr 2021 13:07:51 GMT):
Has joined the channel.
sheldon.regular (Wed, 28 Apr 2021 15:50:08 GMT):
Just a little info worth sharing. Since Docker upgraded automatically on my Mac to 3.3.1 I've been having issues with AATH containers being able to communicate with other containers. For example, the Acapy agent can't connect to the ledger. This is an issue with the latest docker. I've had to downgrade to docker desktop version 3.2.1 https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-321 to make things work. 3.2.2 may work but it has an auto update feature turned on that you can't turn off, so you go back to 3.3.1 really fast. I'm not sure if this is an issue on the mac platform only.
filip.burlacu (Thu, 13 May 2021 22:47:53 GMT):
Has joined the channel.
filip.burlacu (Fri, 14 May 2021 17:55:07 GMT):
quick question - how do you set environment variables for an agent (for the backchannel) for a particular set of features? Do we have a way to do that?
sheldon.regular (Fri, 14 May 2021 18:33:11 GMT):
Hi @filip.burlacu We have a few we set in the manage script when we run docker with the -e option, anything beyond that is done in the backchannel itself.
filip.burlacu (Fri, 14 May 2021 18:37:03 GMT):
thanks!
but do we have a way to determine the environment variables or command-line options based on the particular test being run? I suspect this isn't possible because it would make it possible for certain tests to be incompatible with others, unable to run in the same invocation
filip.burlacu (Fri, 14 May 2021 18:38:59 GMT):
specifically I'm wondering about how to ensure aca-py runs with AIP2.0-comatible options when testing against afgo
ianco (Fri, 14 May 2021 18:54:43 GMT):
There is a `-v` option to specify the AIP version
ianco (Fri, 14 May 2021 18:55:12 GMT):
... so for example this sets all the API 2.0 flags: `./manage run -d afgo-master -b acapy-main -v 20 -t @TimoGlastra
ianco (Fri, 14 May 2021 18:55:12 GMT):
... so for example this sets all the API 2.0 flags: `./manage run -d afgo-master -b acapy-main -v 20 -t @T002-RFC0023`
ianco (Fri, 14 May 2021 18:56:52 GMT):
... and this sets an environment variable called `AIP_CONFIG `
ianco (Fri, 14 May 2021 18:57:05 GMT):
... which is passed to all the backchannels
filip.burlacu (Wed, 26 May 2021 18:32:08 GMT):
just raised a PR: https://github.com/hyperledger/aries-agent-test-harness/pull/244
this started out merely adding a uniresolver and sov driver, but when integrating those into the manage script, I found a way to address another common annoyance, namely, forgetting to start von network and the indy tails server, so when I created a `service` command to start/stop the uniresolver, I added a 'service' for von-network and indy-tails as well
and then when testing, I needed to have the entire harness configuration running, so I split out the `start` and `stop` commands.
MatthewSpence (Tue, 08 Jun 2021 16:21:34 GMT):
Has joined the channel.
MatthewSpence (Tue, 08 Jun 2021 16:53:29 GMT):
Howdy everyone, I'm working on a backchannel for Evernym's Verity Agent Service and I'm confused as to how to use a sovrin ledger for testing. Would somebody be willing to explain this to me?
ianco (Tue, 08 Jun 2021 16:55:20 GMT):
AATH currently assumes you are using some instance of a von-network (https://github.com/bcgov/von-network), this is basically an Indy network, but it comes bundled with a web browser that can serve the pool ledger transactions (for the agents to connect) as well as an endpoint to register DID's
ianco (Tue, 08 Jun 2021 16:56:02 GMT):
Theoretically the test suite can connect to and run against *any* Indy network (including the SOVRIN networks) but would require some updates to the scripts
ianco (Tue, 08 Jun 2021 16:56:36 GMT):
I don't know the specific tasks offhand, I'd need to do a quick code review, if this is something you may be interested in helping out with
ianco (Tue, 08 Jun 2021 16:57:18 GMT):
Otherwise you should be able to run the tests against a local instance of von-network (this is the default) or provide `LEDGER_URL` parameter to connect to (for example) one of the BCOVRIN ledgers
ianco (Tue, 08 Jun 2021 17:05:32 GMT):
`LEDGER_URL_CONFIG=http://localhost:9000 TAILS_SERVER_URL_CONFIG=http://localhost:6543 ./manage run -d acapy-main -v 20 -t @RFC0023 -t ~@wip`
ianco (Tue, 08 Jun 2021 17:05:43 GMT):
(for example)
MatthewSpence (Tue, 08 Jun 2021 17:07:16 GMT):
Thank you for the information. Let me ask my team and see where they want me to go with this
MatthewSpence (Tue, 08 Jun 2021 17:19:58 GMT):
I've been informed that it shouldn't be too difficult for us to run tests against the von network since it's also an indy ledger (I'm still new to the Indy/Aries stack so these kinds of things aren't clear to me yet). We may need to make some minor changes on our side, but I think I can move forward with what we have. Thanks explaining things to me!
ianco (Tue, 08 Jun 2021 17:20:32 GMT):
:+1:
ianco (Tue, 08 Jun 2021 17:21:08 GMT):
If you have any suggestions for improving things we'd love to hear them!
MatthewSpence (Tue, 08 Jun 2021 17:27:22 GMT):
I do have one, should I send it here or in the main channel?
ianco (Tue, 08 Jun 2021 17:27:40 GMT):
main channel
ianco (Tue, 08 Jun 2021 17:27:43 GMT):
thanks
MatthewSpence (Tue, 08 Jun 2021 17:38:12 GMT):
Suggestion for making AATH backchannels easier to develop: Right now it's not clear what the test harness expects back from commands it sends to backchannels. The Google Sheet that lists all the protocol steps and such is nice, but it could be more detailed. For example, during the connection protocol when the inviter generates a connection invitation, the agent backchannel POST request expects a response that includes an `invitation` field, which as far as I can tell is not actually explained anywhere. I had to go examine the feature step to figure out what to send back, and while that's not super difficult, it would be better if it were just listed somewhere. It's possible it is and I just missed it, but if I couldn't find it then other people probably won't either
MatthewSpence (Tue, 08 Jun 2021 18:48:56 GMT):
For some reason when I run the `./manage start` script in von-network I get the docker compose help page, as if I'd ran `docker-compose -h`. Any idea why this might be?
ianco (Tue, 08 Jun 2021 18:49:45 GMT):
Did you run `./manage build` to build the containers?
MatthewSpence (Tue, 08 Jun 2021 18:49:51 GMT):
yes
ianco (Tue, 08 Jun 2021 18:50:10 GMT):
if you run `docker ps` does it show any running containers?
MatthewSpence (Tue, 08 Jun 2021 18:50:25 GMT):
No
MatthewSpence (Tue, 08 Jun 2021 18:50:57 GMT):
I can run the AATH commands fine, it just ends up waiting on the ledger
ianco (Tue, 08 Jun 2021 18:50:58 GMT):
try `./manage start --logs`
MatthewSpence (Tue, 08 Jun 2021 18:51:13 GMT):
same things happened
ianco (Tue, 08 Jun 2021 18:51:18 GMT):
hmmmm
MatthewSpence (Tue, 08 Jun 2021 18:52:04 GMT):
yeah this has me stumped
ianco (Tue, 08 Jun 2021 18:52:05 GMT):
for AATH try to run `./manage run -d acapy-main -v 20 -t @RFC0023 -t ~@wip` i.e. without specifying the params for the ledder and tails file
ianco (Tue, 08 Jun 2021 18:52:26 GMT):
it should automatically start these services (this was a PR that was contributed recently)
MatthewSpence (Tue, 08 Jun 2021 18:52:51 GMT):
it's just waiting for the ledger to start
MatthewSpence (Tue, 08 Jun 2021 18:53:40 GMT):
To reiterate, this is when I try to start the VON-Network that I get this issue
ianco (Tue, 08 Jun 2021 18:54:00 GMT):
yep
ianco (Tue, 08 Jun 2021 18:55:41 GMT):
to run AATH, you can either (a) start up von network and the tails server, and then pass the parameters to AATH (LEDGER_URL_CONFIG and TAILS_SERVER_URL_CONFIG)
ianco (Tue, 08 Jun 2021 18:56:01 GMT):
OR just run AATH *without* starting von network and the tails server ahead of time
ianco (Tue, 08 Jun 2021 18:56:01 GMT):
OR (b) just run AATH *without* starting von network and the tails server ahead of time
ianco (Tue, 08 Jun 2021 18:56:44 GMT):
Can you try (b)? Make sure you don't have any dockers running and then just run `./manage run -d acapy-main -v 20 -t @RFC0023 -t ~@wip` to run the AATH script
ianco (Tue, 08 Jun 2021 18:57:08 GMT):
I'm not sure why your von network isn't starting that's weird
ianco (Tue, 08 Jun 2021 18:58:03 GMT):
Another alternate (c) is to run against an external ledger `LEDGER_URL_CONFIG=http://dev.bcovrin.vonx.io ./manage run -d acapy-main -v 20 -t @RFC0023 -t ~@wip`
MatthewSpence (Tue, 08 Jun 2021 18:58:17 GMT):
Yeah I got the same thing, the output of `docker-compose -h` and then `waiting for ledger to start...`
MatthewSpence (Tue, 08 Jun 2021 18:58:46 GMT):
that's working
MatthewSpence (Tue, 08 Jun 2021 18:58:58 GMT):
so weird that the local von network won't start
MatthewSpence (Tue, 08 Jun 2021 18:59:31 GMT):
feels like something in my dev env, I'll figure it out eventually
ianco (Tue, 08 Jun 2021 18:59:45 GMT):
what platform are you running on?
MatthewSpence (Tue, 08 Jun 2021 18:59:54 GMT):
Ubuntu 18.04
ianco (Tue, 08 Jun 2021 19:00:49 GMT):
"it should work"
ianco (Tue, 08 Jun 2021 19:00:56 GMT):
:-D
MatthewSpence (Tue, 08 Jun 2021 19:01:50 GMT):
lol that's just how it is sometimes, but it looks like the external ledger is working fine so I can proceed for now
MatthewSpence (Tue, 08 Jun 2021 19:01:58 GMT):
thank you again!
sheldon.regular (Tue, 08 Jun 2021 19:59:50 GMT):
Hi Matthew. Yes you are correct, that is poorly explained. I'll update the spreadsheet to include invitation {
}
It's going to be difficult to tell users what to include in there. The invitation is just used for the next step in the protocol, `receive-invitation` it takes the invitation as it is retrieved from `create-invitation` in the previous step. So whatever your agent expects for a receive invitation is what your create invitation should return.
swcurran (Tue, 08 Jun 2021 20:26:37 GMT):
Glad to have you here @MatthewSpence -- let us know if you find anything else to improve.
MatthewSpence (Tue, 08 Jun 2021 20:32:03 GMT):
Maybe I am confused then, I thought that `Inviter` creates the invitation, which is stored by the test harness, and then sent to `Invitee`, which could be some other agent?
sheldon.regular (Tue, 08 Jun 2021 20:47:15 GMT):
Yes, you are exactly right. My mistake. I'm thinking of the scenario where the two agents are from the same framework.
filip.burlacu (Tue, 08 Jun 2021 20:47:40 GMT):
@MatthewSpence what shell provides `sh` on your machine? there might be a compatibility issue since the manage script uses some non-POSIX bash stuff
`readlink $(which sh)`
filip.burlacu (Tue, 08 Jun 2021 20:49:46 GMT):
I was on 18.04 and had some issues at one point, so I relinked sh to bash. Later I reverted that relink though, since I didn't want to break anything dash-dependent on my machine. But later I upgraded to 20.04, and I just noticed that my sh is bash now
filip.burlacu (Tue, 08 Jun 2021 20:50:41 GMT):
(I was probably overly cautious though, using bash to provide sh should be fine)
MatthewSpence (Wed, 09 Jun 2021 14:55:30 GMT):
My shell is provided by dash currently, let me try relinking
MatthewSpence (Wed, 09 Jun 2021 15:10:59 GMT):
After relinking I get the same result
MatthewSpence (Wed, 09 Jun 2021 19:22:05 GMT):
How do TAA's work on the VON-Network? With Sovrin Staging net there's a self serve site with a TAA built in, but I'm assuming VON has some other process?
WadeBarnes (Wed, 09 Jun 2021 19:25:07 GMT):
`von-network` does not have TAA's enabled by default. So you can just register through the associated Network Browser.
MatthewSpence (Wed, 09 Jun 2021 19:25:26 GMT):
Good to know, thank you
WadeBarnes (Wed, 09 Jun 2021 19:28:02 GMT):
To enable TAA in `von-network`:
The TAA and associated AML can be defined here; https://github.com/bcgov/von-network/tree/master/config
Make copies of the samples and name them `aml.json` and `taa.json`, rebuild and start von-network.
Those files will then get registered by; https://github.com/bcgov/von-network/blob/master/server/anchor.py#L225
By default they are ignored by GIT; https://github.com/bcgov/von-network/blob/master/.gitignore#L145-L147
TimoGlastra (Thu, 10 Jun 2021 12:34:32 GMT):
@MatthewSpence https://aries-interop.info/api.html has a pretty good overview of endpoints with expected request and response values. It's not completely up-to-date, but covers AIP1.0
TimoGlastra (Thu, 10 Jun 2021 12:36:38 GMT):
E.g. https://aries-interop.info/api.html#operation/ConnectionCreateInvitation specifies what he create invitation endpoint should return
TimoGlastra (Thu, 10 Jun 2021 12:42:40 GMT):
I've been trying to get the other AATH contributors to use and update the OpenAPI file, but haven't succeeded yet :-)
TimoGlastra (Thu, 10 Jun 2021 12:42:52 GMT):
There's also a postman collection available: https://github.com/hyperledger/aries-agent-test-harness/blob/master/aath.postman_collection.json
MatthewSpence (Fri, 11 Jun 2021 17:09:52 GMT):
I'm running into a conflict between Evernym internal security policy and the architecture of the Test Harness. Building a TA for Verity requires pulling files from Evernym's internal repo, which is, you know, internal. That means it probably can't just be built with a dockerfile by the management script, at least not in the same way as the other agents. Best way I can see to deal with this is to build the docker image locally and push it to dockerhub, then edit the management script to pull the image whenever somebody tries to build the Verity TA. Is there any reason why this would not be an OK solution? Only other way I can see to resolve the issue is to commit the necessary .deb files to the repo, but the largest of them is like 100MB so that doesn't seem like a good option
swcurran (Fri, 11 Jun 2021 17:23:34 GMT):
I had been wondering if that would be an issue. I think it is a good solution and perfectly reasonable -- hopefully it works for you. There is no need to build the Test Agent from source -- the requirement just be that there is a container image that can be used.
MatthewSpence (Fri, 11 Jun 2021 17:24:10 GMT):
Awesome. I thought that would be the case but wanted to check first
ianco (Fri, 11 Jun 2021 17:29:24 GMT):
The manage script expects a Dockerfile to build an image, but you can just point your Dockerfile at a published image (the base image can contain the agent and then the AATH build can add the backchannel)
MatthewSpence (Fri, 11 Jun 2021 17:51:27 GMT):
Will that kind of docker-in-docker setup work? I've ever tried anything like that before
MatthewSpence (Fri, 11 Jun 2021 17:56:30 GMT):
That's a good idea, I forgot you can do that
MatthewSpence (Mon, 14 Jun 2021 16:53:49 GMT):
Is there documentation somewhere on registering a DID with the VON network via API instead of in browser?
ianco (Mon, 14 Jun 2021 16:57:30 GMT):
I don't know if there is any documentation specifically, here is an example of a `curl` command embedded in a docker compose script:
ianco (Mon, 14 Jun 2021 16:57:31 GMT):
https://github.com/bcgov/aries-vcr/blob/master/docker/docker-compose.yml#L148
ianco (Mon, 14 Jun 2021 16:57:53 GMT):
The same `HTTP POST` can be executed from your app, for example:
ianco (Mon, 14 Jun 2021 16:59:00 GMT):
https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/runners/support/agent.py#L350
WadeBarnes (Mon, 14 Jun 2021 17:01:12 GMT):
@ianco, correct, there is no documentation explicitly call out that `von-network` api. It's something we've always inferred from the code (the call the ledger browser makes to register the DID)
WadeBarnes (Mon, 14 Jun 2021 17:01:12 GMT):
@ianco, correct, there is no documentation explicitly calling out that `von-network` api. It's something we've always inferred from the code (the call the ledger browser makes to register the DID)
WadeBarnes (Mon, 14 Jun 2021 17:01:12 GMT):
@ianco, correct, there is no documentation explicitly calling out that `von-network` api. It's something we've always inferred from the code (the call the ledger browser makes to register the DID).
MatthewSpence (Mon, 14 Jun 2021 17:02:40 GMT):
:thumbsup: I'll check the request the browser makes
lohan.spies (Tue, 15 Jun 2021 07:44:51 GMT):
MichaelWiles
lohan.spies (Tue, 15 Jun 2021 07:44:51 GMT):
@MichaelWiles
swcurran (Tue, 15 Jun 2021 21:40:00 GMT):
Mesage from @mirgee work on the AATH backchannel for Aries-VCX:
Hi Stephen, while working on a aries-vcx backchannel for aries interop test harness I noticed that the proof presentation tests use presentation request attachments in the following format:
```
"presentation_proposal": {
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation",
"comment": "This is a comment for the request for presentation.",
"request_presentations~attach": {
"@id": "libindy-request-presentation-0",
"mime-type": "application/json",
"data": data
}
}
```
where
```
data = {
"requested_attributes": {
"attr_1": {
"name": "attr_1",
"restrictions": [
{
"schema_name": "test_schema." + context.issuer_name,
"schema_version": "1.0.0"
}
]
}
}
}
```
The tests are passing e.g. on acapy.
Now, looking into the accepted aries RFC on attachments [here](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0017-attachments), if I am understanding correctly, then
1. request_presentations~attach should be an array, and
2. the data field should contain some of json / base64 / links / jws / sha256 fields.
Is that correct? If so, does that mean that acapy is using incorrect format? If not, what are the expectations on the attachment content according to aries then?
Thanks
mirgee (Tue, 15 Jun 2021 21:40:01 GMT):
Has joined the channel.
swcurran (Tue, 15 Jun 2021 21:40:45 GMT):
@mirgee -- where did you copy and paste the JSON above from? Were those inflight messages from ACA-Py or from somewhere else?
swcurran (Tue, 15 Jun 2021 21:42:14 GMT):
I'm thinking that is AATH data that is passed via API to ACA-Py that then gets formatted into messages. ACA-Py handles the formatting for the message.
swcurran (Tue, 15 Jun 2021 21:43:08 GMT):
That might not be the friendliest for other backchannels, and so we can talk about fixing that, but I suspect it is not a problem in the V1 Present Proof implementation in ACA-Py.
swcurran (Tue, 15 Jun 2021 21:43:08 GMT):
That might not be the friendliest for other backchannels, and so we can talk about ~fixing ~ changing that, but I suspect it is not a problem in the V1 Present Proof implementation in ACA-Py.
swcurran (Tue, 15 Jun 2021 21:43:08 GMT):
That might not be the friendliest for other backchannels, and so we can talk about ~fixing ~ changing :-) that, but I suspect it is not a problem in the V1 Present Proof implementation in ACA-Py.
TimoGlastra (Tue, 15 Jun 2021 21:44:47 GMT):
This is a bit weird, but this is what the backchannel expects, not what ACA-Py expects. It is transformed in the ACA-Py backchannel (and other backchannels). In the OpenAPI it is documented in the same way: https://aries-interop.info/api#operation/PresentProofSendRequest
TimoGlastra (Tue, 15 Jun 2021 21:45:10 GMT):
V2 doesn't have this syntax anymore
mirgee (Wed, 16 Jun 2021 19:01:09 GMT):
@swcurran Apologies, I should have clarified - when I wrote tests, I meant AATH tests. You are correct, this is not data sent by ACA-Py, this is data sent by AATH. I was asking mainly to find out what the standard actually is.
mirgee (Wed, 16 Jun 2021 19:05:01 GMT):
I think it would be friendlier to actually send the presentation proposal in the aries format, working around it is not a problem except for additional / unnecessary complexity at the backchannel level.
mirgee (Wed, 16 Jun 2021 19:05:01 GMT):
I think it would be friendlier to actually send the presentation proposal in the aries format, but working around it is not a problem except for additional / unnecessary complexity at the backchannel level.
sheldon.regular (Wed, 16 Jun 2021 19:08:43 GMT):
It is weird. Back when the test was written, I was only looking at the RFC not knowing what the controllers would use communicating to the Agent frameworks. I just didn't go back and simplify it, and I know I missed the array anyway. I'll put it on the list to simplify/change the format, and adjust some of the backchannels.
sheldon.regular (Wed, 16 Jun 2021 19:21:50 GMT):
This is the work item: https://github.com/hyperledger/aries-agent-test-harness/issues/259
ianco (Wed, 16 Jun 2021 20:29:00 GMT):
The data that the agent requires in order to do something isn't necessarily the same as the data sent from one agent to another (which is what the RFC defines) ... so there may be some extra parameters that we need to send to the agent, and/or the agent may fill in some details (that we don't need to provide)
ianco (Wed, 16 Jun 2021 20:30:38 GMT):
... but getting the backchannel message standards more in-line with what is defined in the RFC isn't an issue, other than having to make sure all the backchannels are synced up ...
mirgee (Wed, 16 Jun 2021 20:43:13 GMT):
I agree that if the change doesn't simplify the code of the backchannels, that it's probably not worth it, given that it requires changing all of them. If it does, then it is a nice to have. Even better if it makes the harness code clearer.
MatthewSpence (Mon, 21 Jun 2021 19:26:21 GMT):
Question on connection tests (RFC 160): If I pass back an invitation url during the create-invitation step, will other agents like acapy be able to handle it? My initial testing seems to indicate no, but it's possible the problem is in my implementation
MatthewSpence (Mon, 21 Jun 2021 19:27:01 GMT):
It certainly seems like what they're expecting is a raw unencoded invitation
sheldon.regular (Mon, 21 Jun 2021 19:49:02 GMT):
Hi Matthew.
What acapy sends back on the `create-invitation` is this.
```
{
"connection_id":"5bc3aaad-c419-4916-8521-330d6f24e68b",
"invitation":{
"@type":"https://didcomm.org/connections/1.0/invitation",
"@id":"ed106d1f-3d2f-473d-b4c8-9167a0ca54a3",
"serviceEndpoint":"http://192.168.65.3:8021",
"recipientKeys":[
"3HBeQNCtg71mDqCSq1QeKX6LueCSwfawh9ojT2QpCbXD"
],
"label":"aca-py.Acme"
},
"invitation_url":"http://192.168.65.3:8021?c_i=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL2Nvbm5lY3Rpb25zLzEuMC9pbnZpdGF0aW9uIiwgIkBpZCI6ICJlZDEwNmQxZi0zZDJmLTQ3M2QtYjRjOC05MTY3YTBjYTU0YTMiLCAic2VydmljZUVuZHBvaW50IjogImh0dHA6Ly8xOTIuMTY4LjY1LjM6ODAyMSIsICJyZWNpcGllbnRLZXlzIjogWyIzSEJlUU5DdGc3MW1EcUNTcTFRZUtYNkx1ZUNTd2Zhd2g5b2pUMlFwQ2JYRCJdLCAibGFiZWwiOiAiYWNhLXB5LkFjbWUifQ=="
}
```
The test harness just sends that `invitation` portion to the invitee `receive-invitation` operation. What acapy uses in in this payload I don't know, someone else may have to answer that, but maybe it just uses the `invitation_url`. If so, your case should work if it is nested in `"invitation":{}`. If these formats are not understood between in different frameworks, then there might be some backchannel work to do to amend/change the payload so that the other participant in the protocol can interpret the invitation properly.
MatthewSpence (Mon, 21 Jun 2021 20:08:08 GMT):
Thank you, that answers my question. I think I'll probably just have to decode the invitation from the url in the backchannel and send that back to the test harness
MatthewSpence (Mon, 21 Jun 2021 20:31:59 GMT):
Also I think the Method on row 11 of the mappings google sheet is wrong. Looking at the gherkin steps it seems like its a GET request that's made, not a POST
MatthewSpence (Mon, 21 Jun 2021 20:31:59 GMT):
Also I think the Method on row 11 of the mappings google sheet might be wrong. Looking at the gherkin steps it seems like its a GET request that's made, not a POST
MatthewSpence (Mon, 21 Jun 2021 20:33:10 GMT):
And the result on row 8 doesn't reflect that the connection_id and invitation parameters are separate. Connection_id needs to be outside the invitation, unless I'm mistaken
sheldon.regular (Mon, 21 Jun 2021 20:35:32 GMT):
If you haven't yet, look at the OpenAPI Spec at https://aries-interop.info/api#operation/ConnectionCreateInvitation
sheldon.regular (Mon, 21 Jun 2021 20:36:49 GMT):
The OpenAPI needs some work but that with the spreadsheet may be helpful.
sheldon.regular (Mon, 21 Jun 2021 20:44:24 GMT):
Yes, you are correct about row 11. It can probably be removed. That was written before the tests were, thinking the controller api would have an explicit call to receive request. It has been the case so far that all agent frameworks automatically receive the request when the connection request is sent in a previous step. What is happening in the receive request test step is a GET to check the agent state to make sure it is in the requested state.
v.shalini (Tue, 22 Jun 2021 12:49:00 GMT):
Has joined the channel.
smithbk (Tue, 22 Jun 2021 12:51:07 GMT):
@sheldon.regular Hi Sheldon, it appears that in the did exchange test case in step 4, you are assuming that the inviter's connection ID will be equal to the invitation ID. This is not true in our case and seems like an invalid assumption. If you agree, could you also change this test case?
sheldon.regular (Tue, 22 Jun 2021 13:42:59 GMT):
that step is actually calling the backchannel to get the connection id by giving the invitation id. This was put in place to support AFGO. However, as per our conversation yesterday, if you don't have a 1-1 relationship between Invitation_id and connection_id then your agent can't do this. I'm assuming this is the same case as 0160 Connection where both participants have the same connection_id?
sheldon.regular (Tue, 22 Jun 2021 13:45:58 GMT):
What we can do in this instance if my assumptions above are correct, is you guys can throw back an error code and "Agent doesn't support connection_id retrieval by invitation_id", then the test can check for that error and make an assumption that the agent is going to use the same connection_id.
sheldon.regular (Tue, 22 Jun 2021 15:03:42 GMT):
@smithbk @v.shalini Could you check this PR and make sure that the changes will work for you before we merge? Thanks. https://github.com/hyperledger/aries-agent-test-harness/pull/264
smithbk (Tue, 22 Jun 2021 15:08:52 GMT):
Sheldon, on 2nd thought, even though we generally have a 1-N relationship between invitation and connection, a newly created invitation that has only been accepted once should have only 1 connection which we can look up. So Shalini is goiing to try to do a search and should find only 1 entry.
sheldon.regular (Tue, 22 Jun 2021 15:10:10 GMT):
ok, does that go for both Connection and DID Exchange?
sheldon.regular (Tue, 22 Jun 2021 15:10:41 GMT):
I'll have to modify my PR i just submitted if that is the case.
sheldon.regular (Tue, 22 Jun 2021 15:11:36 GMT):
Getting by invitation id a much better/consistent solution from the test harness perspective. No assumptions have to be made in the tests.
smithbk (Tue, 22 Jun 2021 15:19:17 GMT):
Yes
smithbk (Tue, 22 Jun 2021 15:20:17 GMT):
Yes, for both connection ID and DID exchange, but Shalini is going to make sure and will let you know
v.shalini (Tue, 22 Jun 2021 15:20:42 GMT):
hi Sheldon. the changes look good to me. I will do some further tests and let you know if there are any issues.
sheldon.regular (Tue, 22 Jun 2021 15:21:24 GMT):
ok, I'm going to adjust the PR for 160 Connection to do a GET given the invitation id the same as DID Exchange does now.
smithbk (Tue, 22 Jun 2021 15:23:54 GMT):
Please wait until you hear from Shalini, to make sure it can work this way. And hopefully any future backchannels will be able to do something similar, assuming this works.
sheldon.regular (Tue, 22 Jun 2021 15:24:11 GMT):
ok. Holding.
swcurran (Tue, 22 Jun 2021 15:43:35 GMT):
dang...sorry. I merged it already. Hope that wasn't too soon.
sheldon.regular (Tue, 22 Jun 2021 15:44:28 GMT):
That's ok. I'll adjust if needed.
v.shalini (Wed, 23 Jun 2021 06:21:41 GMT):
This fix is working.. thanks Sheldon for your quick response
Artemkaaas (Wed, 23 Jun 2021 11:25:41 GMT):
Has joined the channel.
Artemkaaas (Wed, 23 Jun 2021 11:34:19 GMT):
Hello, Are there any design documents/ examples / PoC's regarding automation testing of mobile applications with `aries-agent-test-harness` ?
We run `Appium` mobile automated end-to-end tests which use Evarnym Verity Rest API for opposite communication side. I think we can easily use Aca-py the same way as we use Verity.
But it will be best to integrate with `aries-agent-test-harness` directly.
Artemkaaas (Wed, 23 Jun 2021 11:34:19 GMT):
Hello. Are there any design documents/ examples / PoC's regarding automation testing of mobile applications with `aries-agent-test-harness` ?
We run `Appium` mobile automated end-to-end tests which use Evarnym Verity Rest API for opposite communication side. I think we can easily use Aca-py the same way as we use Verity.
But it will be best to integrate with `aries-agent-test-harness` directly.
v.shalini (Wed, 23 Jun 2021 11:52:40 GMT):
Sheldon, I forgot to mention context.connection_id_dict[context.inviter_name][invitee] = resp_json["connection_id"] in @when('"{invitee}" receives the connection invitation') gives an error. Changed it to context.connection_id_dict[context.inviter_name] = {invitee : resp_json["connection_id"]} for my testing
smithbk (Wed, 23 Jun 2021 12:14:26 GMT):
@sheldon.regular Also, it appears that AATH requires an agent to actually implement an "invitation-received" state for DID exchange even though I took that as being a logical state according to the RFC. Our agent currently assumes that if you receive the invitation to your agent and we create a connection object on the invitee side, then we also automatically send the DID exchange request. So there is currently no way to literally put a connection in the "invitation-received". We could of course add this new state to make the test case pass, but seems a bit odd to me.
The same is true for the connection protocol (but different state name). Thoughts?
sheldon.regular (Wed, 23 Jun 2021 12:16:12 GMT):
Hi @Artemkaaas There is a mobile PoC in the AATH repo. You can read about it here. https://github.com/hyperledger/aries-agent-test-harness/blob/27aa3fb90d67bc29aa2966c112cebb6337f28ae7/MOBILE_AGENT_TESTING.md
sheldon.regular (Wed, 23 Jun 2021 12:17:06 GMT):
This is the backchannel created that the tests use to drive the mobile agent. https://github.com/hyperledger/aries-agent-test-harness/tree/master/aries-backchannels/mobile
sheldon.regular (Wed, 23 Jun 2021 12:19:29 GMT):
Though this PoC is manually driven on the mobile app side, I see no reason this couldn't be done with a mobile automation platform or framework.
Artemkaaas (Wed, 23 Jun 2021 12:41:46 GMT):
Artemkaaas - Wed Jun 23 2021 15:40:08 GMT+0300 (Moscow Standard Time).txt
Artemkaaas (Wed, 23 Jun 2021 12:42:49 GMT):
I've seen this document and tried to run it but didn't get any meaningful output. Tests just failed for me even not started
Artemkaaas (Wed, 23 Jun 2021 12:43:42 GMT):
Artemkaaas - Wed Jun 23 2021 15:42:02 GMT+0300 (Moscow Standard Time).txt
Artemkaaas (Wed, 23 Jun 2021 12:44:03 GMT):
```
Starting mobile backchannel ...
Listening to backchannel on port 9030
Press Ctrl-C to exit ...
Matched operation: {'rfc': '0000 General Backchannel Commands', 'command': 'X', 'response': '', 'topic': 'status', 'method': 'GET', 'operation': '', 'id': '', 'data': '', 'description': 'Return agent status, 200 if active or 418 otherwise', 'id_details': '', 'data_details': '', 'result_details': 'status'}
make_agent_GET_request: {'rfc': '0000 General Backchannel Commands', 'command': 'X', 'response': '', 'topic': 'status', 'method': 'GET', 'operation': '', 'id': '', 'data': '', 'description': 'Return agent status, 200 if active or 418 otherwise', 'id_details': '', 'data_details': '', 'result_details': 'status'}
Matched operation: {'rfc': '0000 General Backchannel Commands', 'command': 'X', 'response': '', 'topic': 'version', 'method': 'GET', 'operation': '', 'id': '', 'data': '', 'description': 'Return agent version, 200 if exists or 404 otherwise', 'id_details': '', 'data_details': '', 'result_details': 'version'}
make_agent_GET_request: {'rfc': '0000 General Backchannel Commands', 'command': 'X', 'response': '', 'topic': 'version', 'method': 'GET', 'operation': '', 'id': '', 'data': '', 'description': 'Return agent version, 200 if exists or 404 otherwise', 'id_details': '', 'data_details': '', 'result_details': 'version'}
```
The output I have for bob
Artemkaaas (Wed, 23 Jun 2021 12:44:38 GMT):
Do you have any ideas about what I'm doing wrong? I'm using the current master
sheldon.regular (Wed, 23 Jun 2021 12:47:34 GMT):
The tests really only have two things to assert to keep things going, that is the response code 200 and the proper state. Right or wrong, it is assumed that the states listed in the RFCs are able to be determined in the agent/controller and given to the tests.
If you don't want to add this received state officially, can the state be determined from something in a webhook that the invitation was received?
Aries Framework Go also does what you are saying, but I can determine that if I receive a webhook message with a certain `type` in it it means the request was received. I have type to state translation dictionaries in the afgo backchannel that look like this.
```
# Issue Cred didcom type : AATH Expected State
self.IssueCredentialTypeToStateTranslationDict = {
"https://didcomm.org/issue-credential/2.0/offer-credential": "offer-received",
"https://didcomm.org/issue-credential/2.0/request-credential": "request-received",
"https://didcomm.org/issue-credential/2.0/issue-credential": "credential-received"
}
# Proof didcom type : AATH Expected State
self.ProofTypeToStateTranslationDict = {
"https://didcomm.org/present-proof/2.0/request-presentation": "request-received",
"https://didcomm.org/present-proof/2.0/presentation": "presentation-received"
}
```
Does that help?
sheldon.regular (Wed, 23 Jun 2021 12:51:20 GMT):
@v.shalini Yes, I'm sure that fix worked for you. However, that is not the preferred fix. I would like to change that to a GET that passes the invitation_id and your backchannel send back a connection_id for that agent. This is what DID Exchange does and I would like to make the Connection tests the same.
sheldon.regular (Wed, 23 Jun 2021 12:56:15 GMT):
I'll take a look and try to run it. I have never tried this before and the guy who did the PoC is away this week.
swcurran (Wed, 23 Jun 2021 14:26:39 GMT):
Hmm...it's worked for me previously, but I've not run it recently. When run, you should have QR codes coming up on the terminal that you can scan with the mobile agent.
swcurran (Wed, 23 Jun 2021 14:28:04 GMT):
We'd love to see a mobile agent wrapped in a container for a backchannel. We've theorized about it, but no one has dug into what would be needed for that. Any guidance would be very much appreciated.
v.shalini (Wed, 23 Jun 2021 15:09:50 GMT):
I have updated the backchannel code to retrieved the connection from invitation id
v.shalini (Wed, 23 Jun 2021 15:10:40 GMT):
when executing @T001-RFC0160, i am getting the following error context.connection_id_dict[context.inviter_name][invitee] = resp_json["connection_id"]
KeyError: 'Acme'
sheldon.regular (Wed, 23 Jun 2021 15:12:00 GMT):
ok, I'll update the tests to do a GET with the invitation id.
v.shalini (Wed, 23 Jun 2021 15:13:39 GMT):
its how the invitee and inviter are referenced in connection_id_dict.. Acme key is not present
sheldon.regular (Wed, 23 Jun 2021 15:14:06 GMT):
What line is that?
v.shalini (Wed, 23 Jun 2021 15:14:29 GMT):
@when('"{invitee}" receives the connection invitation')
v.shalini (Wed, 23 Jun 2021 15:15:22 GMT):
line 138
smithbk (Wed, 23 Jun 2021 15:47:11 GMT):
@sheldon.regular Sheldon, I'm not sure what is meant by "something in a webhook that the invitation was received". We take an invitation from the inviter and then POST the URL to the invitee. We can provide a webhook on the inviter to know that an invitation has been created or on the invitee to know when the invitation URL has been posted to the invitee, but I'm not sure how that helps to know when the invitee first receives the invitation since I thought AATH has a step for that anyway. When we POST the invitation URL to the invitee, the invitee's connection internal state name is "outbound_offer". Would it be possible for our backchannel to return "received" if it is in this state the 1st time it is asked and then "request_sent" (or whatever those 2 state names are) the 2nd time it is called? I know that is kludgy, but really don't think maintaining those separate states are needed.
sheldon.regular (Wed, 23 Jun 2021 15:49:33 GMT):
I'm having different issues when running that I'm trying to resolve, but @Artemkaaas did you build the agents first?
`./manage build -a mobile`
`./manage build -a acapy-main`
or if you are using dotnet
`./manage build -a dotnet-master`
sheldon.regular (Wed, 23 Jun 2021 15:54:39 GMT):
Yes, I would say that if the backchannel can determine that the agent is likely in the proper state, then return the state the test expects.
smithbk (Wed, 23 Jun 2021 15:55:32 GMT):
But I assume that the expected state is not passed to the backchannel, or is it?
sheldon.regular (Wed, 23 Jun 2021 15:56:34 GMT):
No it is not passed. The expected state is what is in the RFC, which is what is checked in the test steps after the operation is called.
swcurran (Wed, 23 Jun 2021 16:35:04 GMT):
If you use `acapy` instead of `acapy-main` it will work. We seem to have a broken main branch today.... :-(
sheldon.regular (Wed, 23 Jun 2021 17:34:48 GMT):
@swcurran is right. It should work with acapy not acapy-main. There is a problem with the way we are starting up acapy-main in this context.
swcurran (Wed, 23 Jun 2021 17:51:47 GMT):
Not sure it will work if ACA-Py doesn't use ngrok. :-(.
I was able to get the tests to run, but the connect in scanning the QR code doesn't work.
swcurran (Wed, 23 Jun 2021 17:51:50 GMT):
Dang...
swcurran (Wed, 23 Jun 2021 17:52:16 GMT):
We need to figure this out. Or have @ianco help us :-)
sheldon.regular (Wed, 23 Jun 2021 19:49:00 GMT):
PR submitted that should fix the inviter key error, and get connection id by invitation id.
https://github.com/hyperledger/aries-agent-test-harness/pull/266
sheldon.regular (Thu, 24 Jun 2021 16:05:19 GMT):
Are you guys ok with the changes in PR 266?
MatthewSpence (Thu, 24 Jun 2021 16:05:22 GMT):
Getting an interesting error when trying to run the connection protocol between Aca-py and Verity. When Verity is Acme and Aca-py is Bob, on this step `And "Bob" sends a connection request to "Acme"` Aca-py responds with status `responded` instead of `requested`. That would seem to indicate that Verity and Aca-py are moving through the protocol faster than the test harness expects, if that's the case I'm not sure what to do
sheldon.regular (Thu, 24 Jun 2021 16:23:18 GMT):
@MatthewSpence That could happen if Verity does an auto respond on the request. Does Verity have the option to turn off auto responding, to allow the tests/backchannels to completely control when the response happens?
MatthewSpence (Thu, 24 Jun 2021 16:25:48 GMT):
I thought that might be the issue. Unfortunately no, once Verity receives a connection request it proceeds through the protocol automatically
TimoGlastra (Thu, 24 Jun 2021 16:27:02 GMT):
I think the old VCX implementation had the same issue. @sheldon.regular do you know how that was handled?
sheldon.regular (Thu, 24 Jun 2021 16:32:15 GMT):
No I don't know what VCX did in this case. There is no hint in the current implementation.
sheldon.regular (Thu, 24 Jun 2021 16:39:01 GMT):
There are 2 options.
1/ Create a new Connection Test Scenario that considers auto responding. It would be a shorter scenario. Somehow the Issue Cred and Proof tests would need to know we are doing auto responding so that it uses that auto respond test step code to do the connection for those tests as well.
2/ Verity and Aca-py fakes the test out by changing the responded state to requested because we are already past that point in the process, and wait for the test to catch up to where the agents are. Nevermind... That is a horrible solution. I think the first option is our only one if Verity can't turn off auto responding.
MatthewSpence (Thu, 24 Jun 2021 16:58:48 GMT):
Option 1 sounds reasonable
swcurran (Thu, 24 Jun 2021 17:17:39 GMT):
Is it possible for the backchannel to compensate for the "auto" processing. E.g. the backchannel tells Verity (or ACA-Py when in auto mode) and then responds back without waiting to hear from it's agent? E.g. it goes through the steps the Harness wants assuming all is well?
swcurran (Thu, 24 Jun 2021 17:17:39 GMT):
Is it possible for the backchannel to compensate for the "auto" processing. E.g. the backchannel tells Verity (or ACA-Py when in auto mode) to act and then responds back without waiting to hear from it's agent? E.g. it goes through the steps the Harness wants assuming all is well?
sheldon.regular (Thu, 24 Jun 2021 17:54:49 GMT):
@swcurran Not sure I completely follow. When the backchannel tells Verity to do something, then what is it responding back to the tests with, the fake state? If the bakchannel is not waiting for a response, we are not going to know of a failure, at least not at the point of failure, which may get confusing when things are failing and we need to figure out what is going wrong.
I think creating a new test is probably the cleanest solution. However, letting the other tests (Issue Cred, Proof) know to use the auto respond connection steps in these other tests might be tricky.
swcurran (Thu, 24 Jun 2021 17:57:18 GMT):
For this case, yes -- respond with a fake state -- or at least one that is assumed. My concern with handling this with a different test is that you need an entire new suite of tests, since connection is foundational.
MatthewSpence (Thu, 24 Jun 2021 17:57:19 GMT):
The problem is that the test is failing on the acapy response
swcurran (Thu, 24 Jun 2021 17:57:55 GMT):
Ah...that's a different thing. But once we resolve it, we should be OK. So the question is why ACA-Py and Verity aren't connecting.
MatthewSpence (Thu, 24 Jun 2021 17:58:13 GMT):
I think they are connecting
MatthewSpence (Thu, 24 Jun 2021 17:58:36 GMT):
can't tell for sure just yet but verity logs indicate that the connecting protocol completes without a problem
swcurran (Thu, 24 Jun 2021 17:58:41 GMT):
We could have one test that is explictly assuming auto, but all the ones used elsewhere can't have two versions.
sheldon.regular (Thu, 24 Jun 2021 17:59:08 GMT):
Acapy isn't failing, the test is asserting the wrong state, acapy has already moved on to responded.
MatthewSpence (Thu, 24 Jun 2021 17:59:15 GMT):
^^^
swcurran (Thu, 24 Jun 2021 18:00:45 GMT):
OK, so all is working, but the test reporting is the issue. I'm back to the Verity backchannel reporting "all good" if it can't know for sure.
sheldon.regular (Thu, 24 Jun 2021 18:01:07 GMT):
If we had some sort of feature discovery for each agent framework, we could tailor the tests to use the auto respond connections across the existing suites. ;-)
MatthewSpence (Thu, 24 Jun 2021 18:01:53 GMT):
The verity backchannel doesn't get a chance to respond, the tests fail on acapy's response
swcurran (Thu, 24 Jun 2021 18:03:06 GMT):
I don't think that would help in this case. Verity still would not be able to report anything useful until the connection was done or failed.
sheldon.regular (Thu, 24 Jun 2021 18:03:16 GMT):
Well, I think I would say that a little differently, Verity has already responded based on acapy's request.
swcurran (Thu, 24 Jun 2021 18:03:26 GMT):
Oooppss..replied to the wrong message. Sorry.
MatthewSpence (Thu, 24 Jun 2021 18:03:57 GMT):
Test output looks like this
``` Scenario Outline: establish a connection between two agents -- @1.1 # features/0160-connection.feature:21
Given we have "2" agents # features/steps/0160-connection.py:15 0.000s
| name | role |
| Acme | inviter |
| Bob | invitee |
When "Acme" generates a connection invitation # features/steps/0160-connection.py:78 5.959s
And "Bob" receives the connection invitation # features/steps/0160-connection.py:105 0.585s
And "Bob" sends a connection request to "Acme" # features/steps/0160-connection.py:165 3.726s
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python3.7/site-packages/behave/matchers.py", line 98, in run
self.func(context, *args, **kwargs)
File "features/steps/0160-connection.py", line 181, in step_impl
assert expected_agent_state(invitee_url, "connection", invitee_connection_id, "requested")
AssertionError
Captured stdout:
From http://0.0.0.0:9030 Expected state ['requested', 'N/A'] but received responded , with a response status of 200```
MatthewSpence (Thu, 24 Jun 2021 18:04:15 GMT):
Just in case that helps illustrate the issue
MatthewSpence (Thu, 24 Jun 2021 18:04:47 GMT):
Yes I mean respond to the test harness
MatthewSpence (Thu, 24 Jun 2021 18:04:47 GMT):
Yes I mean respond to the test harness. Verity receives and responds to aca-py's connection request just fine
sheldon.regular (Thu, 24 Jun 2021 18:08:09 GMT):
I guess, the acapy backchannel could keep track of the webhook callbacks and make sure the states transitioned properly to responded, still hand back the expected state to the tests, until the test steps caught up. The Verity backchannel would probably have to do something similar for the next 2 steps in the test. Seems kludgy though.
MatthewSpence (Thu, 24 Jun 2021 18:08:39 GMT):
Yeah that seems like it's not solving the underlying problem
sheldon.regular (Thu, 24 Jun 2021 18:09:27 GMT):
I agree.
MatthewSpence (Thu, 24 Jun 2021 18:10:51 GMT):
It seems reasonable to me to write a new test that only checks states when the invitation message is sent, and when the request response is received
sheldon.regular (Thu, 24 Jun 2021 18:11:54 GMT):
A possible quick and dirty fix for this right now is to have the tests accept `responded` as an acceptable state at this point in the tests.
swcurran (Thu, 24 Jun 2021 18:13:21 GMT):
The other way to go is to ignore the intermediate states entirely, and just wait for completion. Would that adversely affect what we know? That way we don't have to have specialized tests.
swcurran (Thu, 24 Jun 2021 18:13:45 GMT):
I really think specialized tests in this case is a problem.
sheldon.regular (Thu, 24 Jun 2021 18:19:05 GMT):
We could... but instead of loosing all control and verification points, allowing responded should have the same effect. If state is anything other than requested or responded, then fail.
or...
We could create one new connection test that does not check those intermediate states, and change the other suites to use that new one. The point of the other suites is to test other things so not checking intermediate states in a precondition connection setup routine is not the end of the world.
smithbk (Thu, 24 Jun 2021 18:22:40 GMT):
My vote would be to either ignore intermediate states or allow a channel to send back a list of states through which it has traversed and have AATH validate those, but not require agents to be able to manually step through each step
smithbk (Thu, 24 Jun 2021 18:22:40 GMT):
My vote would be to either ignore intermediate states or allow a channel to send back a list of states through which it has traversed and have AATH validate those, but not require agents to be able to manually step through each state
MatthewSpence (Thu, 24 Jun 2021 18:23:03 GMT):
^^^ I was just about to suggest the list of states idea
sheldon.regular (Thu, 24 Jun 2021 18:23:16 GMT):
ohhh I like the list idea.
MatthewSpence (Thu, 24 Jun 2021 18:24:08 GMT):
It would possibly require more work but would be a more general solution, in case other future agents have auto responses that leave them at a different point
MatthewSpence (Thu, 24 Jun 2021 18:25:00 GMT):
Because there's no guarantee that all agents will auto respond at the same point, or for the same number of steps
smithbk (Thu, 24 Jun 2021 18:30:39 GMT):
hmm ... I don't see a PR 266 at https://github.com/hyperledger/aries-agent-test-harness/pulls
smithbk (Thu, 24 Jun 2021 18:30:39 GMT):
https://github.com/hyperledger/aries-agent-test-harness/pull/266/files
I assume it should be "connection" instead of "conection" on line 136
swcurran (Thu, 24 Jun 2021 18:36:57 GMT):
Regarding losing the control and verification points. I think we need to think about the purpose of AATH. It is to allow continuous interop testing -- e.g. over time. I think that when a Test Agent (e.g. Backchannel+Agent or Framework), it is incumbent on the creator of the backchannel to "get it working" and so they will be "hands on" in debugging. If AATH gives only protocol level pass/fails, that should be enough to trigger the Test Agent maintainer(s) to dig in. The step by step info is (obviously) helpful, at the cost of dealing with issues like this, and the backchannel could provide that info in the form of a log for investigating post-mortem. But the P/F of the protocol is probably sufficient for the higher level purpose of AATH.
MatthewSpence (Thu, 24 Jun 2021 18:43:06 GMT):
I think the point of allowing a list would be to make the step by step process optional, for cases like Verity where it might be very difficult to "get it working". It would definitely still be best practice to go through as many steps as possible
sheldon.regular (Thu, 24 Jun 2021 18:51:10 GMT):
Behave doesn't allow you to skip steps once you are inside of the scenario. So the test step process isn't optional, they will still be executed, they will just be less constrictive. The Backchannel to Agent operations are optional, which is what you are referring to.
MatthewSpence (Thu, 24 Jun 2021 18:53:27 GMT):
Yes that's what I meant. Thank you for clarifying
sheldon.regular (Thu, 24 Jun 2021 18:58:30 GMT):
yes, good catch.
MatthewSpence (Thu, 24 Jun 2021 19:05:43 GMT):
Is this the path we want to go down then? I can start working on it if so
sheldon.regular (Thu, 24 Jun 2021 19:05:49 GMT):
@swcurran yes, of course it is to allow interop testing, but it was to allow this based on the RFC. Losing the validation points could be considered a loss of resolution on what the RFC describes. Not to mention that auto responding is not talked about in the RFC(s). I'm not really arguing for or against. Just wearing my QA hat. ;-) I'm good with removing the validation if we agree that is the best approach.
I'm still partial to the list solution. Backchannels could return something like this and take appropriate actions.
```
{
"state":"responded",
"transistioned_states": [
"invited",
"requested"
]
}
```
sheldon.regular (Thu, 24 Jun 2021 19:08:56 GMT):
We could do both and see which one we like in the real world?
1/ Make a connection test that does not check for intermediate states. This could eventually be the default one if it wins out.
2/ also update existing tests to check for a transitioned_states list if the current state is not expected.
MatthewSpence (Thu, 24 Jun 2021 19:09:35 GMT):
The transitioned states idea is a lot more general, could easily be applied to other protocols if need be
swcurran (Thu, 24 Jun 2021 19:15:39 GMT):
If the states will work -- I'm good with that. I would just prefer not to go down the path of separate tests.
sheldon.regular (Thu, 24 Jun 2021 19:16:32 GMT):
Well the state list won't require separate tests.
sheldon.regular (Thu, 24 Jun 2021 19:24:27 GMT):
fixed and merged.
smithbk (Thu, 24 Jun 2021 19:34:25 GMT):
I'm also good with this, but the more I think about this, the more I think that in most cases it is not going to add any real test value because most backchannel implementations will likely just hard-code the list that they return and not truly verify that the agent actually went thru those states. It seems to me that you could:
1) continue with the list approach and ask/warn backchannels to truly verify these transitional states and not return a hardcoded list;
2) require the backchannel to implement a webhook to return each transitional state as it comes in; or
3) not verify transitional states ... well, perhaps unless you know that the state truly requires manual intervention and so all agents would have to be able to have an admin control over that state.
I really question though whether AATH really should verify all transitional states.
My $.02 (or less) worth :-)
swcurran (Thu, 24 Jun 2021 19:44:01 GMT):
`I really question though whether AATH really should verify all transitional states.` That's the key as well. The more states tracked, the more (I would assume) complex the backchannel, and hence the more effort to maintain them. It's super helpful while creating a test or implementing a backchannel to know the states, but if it reduces the number of Test Agents or the breadth of the test coverage, it's a questionable trade-off.
I'm very interested in what those building new backchannels think of AATH overall, the effort to build the backchannel and the resulting value. Obviously, we think the overall suite is a huge win, so the easier it is for everyone to participate, the better.
swcurran (Thu, 24 Jun 2021 19:44:01 GMT):
`I really question though whether AATH really should verify all transitional states.` I think that's the key as well. The more states tracked, the more (I would assume) complex the backchannel, and hence the more effort to maintain them. It's super helpful while creating a test or implementing a backchannel to know the states, but if it reduces the number of Test Agents or the breadth of the test coverage, it's a questionable trade-off.
I'm very interested in what those building new backchannels think of AATH overall, the effort to build the backchannel and the resulting value. Obviously, we think the overall suite is a huge win, so the easier it is for everyone to participate, the better.
swcurran (Thu, 24 Jun 2021 19:44:01 GMT):
`I really question though whether AATH really should verify all transitional states.` I think that's the key as well. The more states tracked, the more (I would assume) complex the backchannels, and hence the more effort to maintain them. It's super helpful while creating a test or implementing a backchannel to know the states, but if it reduces the number of Test Agents or the breadth of the test coverage, it's a questionable trade-off.
I'm very interested in what those building new backchannels think of AATH overall, the effort to build the backchannel and the resulting value. Obviously, we think the overall suite is a huge win, so the easier it is for everyone to participate, the better.
smithbk (Thu, 24 Jun 2021 19:48:38 GMT):
I agree that checking transitional states is good for debugging agents but not for being able to verify if a test passes or fails. If that is true, then perhaps AATH should allow a backchannel to optionally implement a webhook to return transitional states, simply to make debugging easier, but not mandate it.
sheldon.regular (Thu, 24 Jun 2021 20:08:44 GMT):
I agree that if backchannels just start hardcoding the transitioned states it will be of no value to anyone. So where are we landing here? I feel like I'm back to doing both and see which one we favor in the real world. I'm creating an issue in the AATH repo with the options and our path forward.
sheldon.regular (Thu, 24 Jun 2021 20:09:47 GMT):
This is a great conversation btw, it really helps create a more solid test harness to have you guys involved like this.
MatthewSpence (Thu, 24 Jun 2021 20:25:11 GMT):
I can offer my $0.02 on this. I like the architecture of the test harness overall, it's easy to wrap your head around and there's very clear steps to follow. My main gripe is that the documentation on what needs to be returned to the test harness could be improved, and I do think it relies too much on testing states. Testing states is nice but not practical in a lot of cases like with Verity, where a lot of protocols will enter/exit multiple states before anything gets sent back to the controller. Ultimately what we care about is the end result of successful interop, and if state transitions aren't perfect then so be it
MatthewSpence (Thu, 24 Jun 2021 20:25:11 GMT):
I can offer my $0.02 on this. I like the architecture of the test harness overall, it's easy to wrap your head around and there's very clear steps to follow. My main issue is that the documentation on what needs to be returned to the test harness could be improved, and I do think it relies too much on testing states. Testing states is nice but not practical in a lot of cases like with Verity, where a lot of protocols will enter/exit multiple states before anything gets sent back to the controller. Ultimately what we care about is the end result of successful interop, and if state transitions aren't perfect then so be it
MatthewSpence (Thu, 24 Jun 2021 20:29:30 GMT):
I can honestly say that I was planning on hard coding the state transitions, if that's any indication.
MatthewSpence (Thu, 24 Jun 2021 20:42:18 GMT):
As far as the effort to develop the backchannel, my personal experience may not be representative. I'm a new college grad (literally started work on late May this year) so I'm doing a lot of on the job learning. Writing the backchannel was pretty easy, most of my time initially was spent figuring out how to get Verity running against the VON-network and running properly in the test harness. Having Verity running against VON was valuable in and of itself though because it validated that we're not completely tied to Sovrin. I don't see a way to make integrating new agents much easier, and I think a more experienced developer would have been able to do it faster.
sheldon.regular (Thu, 24 Jun 2021 20:44:33 GMT):
Issue created, did I miss anything. https://github.com/hyperledger/aries-agent-test-harness/issues/268
sheldon.regular (Thu, 24 Jun 2021 20:44:33 GMT):
Issue created, did I miss anything? https://github.com/hyperledger/aries-agent-test-harness/issues/268
sheldon.regular (Thu, 24 Jun 2021 20:45:20 GMT):
I can start if we agree on the chosen solution - AATH not checking intermediate states.
MatthewSpence (Thu, 24 Jun 2021 20:58:50 GMT):
I think there may be value in making testing intermediate steps optional, a la option 2 in the issue, but for Verity specifically that won't be of much help
MatthewSpence (Thu, 24 Jun 2021 20:58:50 GMT):
This option works for me. I think there may be value in making testing intermediate steps optional, a la option 2 in the issue, but for Verity specifically that won't be of much help
sheldon.regular (Fri, 25 Jun 2021 15:08:49 GMT):
I've added another consideration to the #268 ticket.
sheldon.regular (Fri, 25 Jun 2021 15:08:49 GMT):
I've added another consideration to the 268 ticket.
MatthewSpence (Fri, 25 Jun 2021 20:07:10 GMT):
Is there a particular status I should return if Verity does not support one role in a given interaction? For example, Verity agents aren't intended to be holders
sheldon.regular (Fri, 25 Jun 2021 20:08:33 GMT):
I don't think so. Just don't run tests with Verity in that role. Am I understanding you correctly?
sheldon.regular (Fri, 25 Jun 2021 20:11:21 GMT):
In general Acme is an issue and Bob is a holder, but I do understand that there is a role reversal test that breaks the pattern. I think I will remove the test. If we want to swap roles we can do another run and assign the roles to agents at the command line. That is unless, it is of value to you to make sure Verity isn't or can't do holder things? I doubt that is the case.
MatthewSpence (Fri, 25 Jun 2021 20:44:38 GMT):
No there's no value to that
MatthewSpence (Fri, 25 Jun 2021 20:45:09 GMT):
It'd be great if Verity magically had holder functionality lol but I'm not going to hold my breath
sheldon.regular (Fri, 25 Jun 2021 20:45:31 GMT):
:thumbsup:
swcurran (Tue, 29 Jun 2021 17:00:15 GMT):
Hey folks -- the Mobile Backchannel had been not working for a bit, but it is back and working again. If you have a mobile wallet that you want to test against other Test Agent (such as ACA-Py), give it a go....instructions here: https://github.com/hyperledger/aries-agent-test-harness/blob/master/MOBILE_AGENT_TESTING.md
MatthewSpence (Thu, 01 Jul 2021 20:43:21 GMT):
Howdy folks, I'm looking to integrate the test harness into one of our Gitlab CI pipelines and I'm running into a couple of issues. First up: our gitlab jobs run in docker containers. I'm not an expert but my understanding is that running docker in docker is not recommended. If we were to spin up the Test Agent images separately, would there be a way for us to pass their endpoints in to the test harness?
MatthewSpence (Thu, 01 Jul 2021 20:43:21 GMT):
Howdy folks, I'm looking to integrate the test harness into one of our Gitlab CI pipelines and I'm running into a couple of issues. First up: our gitlab jobs run in docker containers. I'm not an expert so correct me if I'm wrong about this, but my understanding is that running docker in docker is not recommended. If we were to spin up the Test Agent images separately, would there be a way for us to pass their endpoints in to the test harness?
MatthewSpence (Thu, 01 Jul 2021 20:43:21 GMT):
Howdy folks, I'm looking to integrate the test harness into one of our Gitlab CI pipelines and I have some questions. First up: our gitlab jobs run in docker containers. I'm not an expert so correct me if I'm wrong about this, but my understanding is that running docker in docker is not recommended. If we were to spin up the Test Agent images separately, would there be a way for us to pass their endpoints in to the test harness?
MatthewSpence (Thu, 01 Jul 2021 21:05:09 GMT):
Second up is kind of a combination issue/suggestion: it might make it easier to test agents if there were prebuilt docker images of Test Agents hosted somewhere. We want to run tests against static versions of other Test Agents, so that we can avoid a situation in which an external change breaks out tests. As things stand the way we would do that (to the best of my knowledge) is to store the docker images of each Test Agent between runs, but that requires us to store images of other people's agents, potentially a lot of them. If there were a dockerhub or something that we could pull the images from we might avoid this issue for us and other testers. This might also make it easier for other companies whose agents can't be built externally to contribute
TimoGlastra (Fri, 02 Jul 2021 08:26:42 GMT):
I like this idea. Wouldn't be too hard to publish agent images to GHR/Dockerhub as part of the pipeline. Only question is how often you update them? Most run on master, does that mean we create a new image for every commit to the master/main branch of a repo?
MatthewSpence (Fri, 02 Jul 2021 13:30:23 GMT):
That's a good question. I think that would be up to the maintainers of the individual agents how often they would want to contribute new images of their agents. For evernym that would probably be every time we release a new Verity version, so once a week or so
swcurran (Fri, 02 Jul 2021 18:05:59 GMT):
That fits the model we've been using. "acapy" is the currently released version (but from PyPi), which "acapy-main" is the dev branch. Others can follow that model or just use the first. Note that as long as you use the dockerfile naming convention, the ./manage script automagically finds them and uses them if asked.
swcurran (Fri, 02 Jul 2021 18:05:59 GMT):
That fits the model we've been using. "acapy" is the currently released version (but from PyPi), which "acapy-main" is the dev branch. Others can follow that model of both or just use the first. Note that as long as you use the dockerfile naming convention, the ./manage script automagically finds them and uses them if asked.
MatthewSpence (Fri, 02 Jul 2021 19:03:59 GMT):
Yeah I was impressed when I saw that, it's a clever bit of scripting. What do you think about making a dockerhub and publishing the images to it?
swcurran (Fri, 02 Jul 2021 21:10:40 GMT):
Note sure what is needed for that. BC Gov has a Dockerhub account and we publish to it -- bcgovimages. I suspect Hyperledger has one -- is that what you are thinking?
TimoGlastra (Fri, 02 Jul 2021 21:50:08 GMT):
We could also use github container registry. It allows for public images and is already integrated I believe with github actions
MatthewSpence (Mon, 05 Jul 2021 17:52:39 GMT):
That seems like a good idea
filip.burlacu (Mon, 05 Jul 2021 19:11:17 GMT):
would anyone like to give this a review?
https://github.com/hyperledger/aries-agent-test-harness/pull/271
orb's configuration files are in `services/orb/`, which shouldn't interfere with anything else
in `./manage` I resorted to adding a conditional for adding agents to `aath_network`, so afgo agents are added but others aren't, since acapy has an unexplained but reproducible issue if it's added to `aath_network`
swcurran (Tue, 06 Jul 2021 06:37:01 GMT):
We need to think about how to get this into a test -- including (for example) what ACA-Py would have do to resolve a did:orb - how to add to the ACA-Py local resolvers or universal resolver.
filip.burlacu (Tue, 06 Jul 2021 13:56:46 GMT):
it's resolvable through uniresolver already :)
MatthewSpence (Tue, 06 Jul 2021 21:04:39 GMT):
Can somebody explain to me what's going on in this command from the management script?
`${terminalEmu} docker run ${INTERACTIVE} --rm --network="host" -v ${BEHAVE_INI_TMP}:/aries-test-harness/behave.ini aries-test-harness -k ${runArgs} -D Acme=http://0.0.0.0:9020 -D Bob=http://0.0.0.0:9030 -D Faber=http://0.0.0.0:9040 -D Mallory=http://0.0.0.0:9050` Specifically the -k and -D flags.
sheldon.regular (Tue, 06 Jul 2021 21:29:11 GMT):
These are behave options.
-k stops behave from printing out skipped steps.
-D loads the behave context dictionary with name=value. The contents of the context dictionary is available to every scenario/step at runtime.
MatthewSpence (Tue, 06 Jul 2021 21:30:51 GMT):
Oh ok, thank you!
sheldon.regular (Tue, 06 Jul 2021 21:31:03 GMT):
:thumbsup:
filip.burlacu (Thu, 08 Jul 2021 15:37:37 GMT):
I've configured ACA-Py in AATH to use the sicpa-dlab universal resolver plugin: https://github.com/hyperledger/aries-agent-test-harness/pull/281
It's successfully resolving orb DIDs now, and sending a request to afgo for the implicit invitation flow (ie, `"Acme" sends the request to "Bob" with the public DID` in `T005/6-RFC0023`)
But something unusual is going on - ACA-Py is sending a routing/forward message, that afgo is unable to handle since the agents don't have a connection yet.
ACA-Py doesn't seem to be doing this for any of the other didexchange flows, so I'm not sure what's going on here.
swcurran (Thu, 08 Jul 2021 15:51:51 GMT):
@ianco -- perhaps you could look at this PR? Looks like it might be a bit deeper into ACA-Py.
swcurran (Thu, 08 Jul 2021 15:52:22 GMT):
Would love to know what the DIDDoc for the resolved DID looks like.
filip.burlacu (Thu, 08 Jul 2021 16:03:06 GMT):
@swcurran I think the routing message was due to the orb did doc, it had a routing key when it shouldn't
ianco (Thu, 08 Jul 2021 16:08:47 GMT):
I'll take a look today ...
filip.burlacu (Thu, 08 Jul 2021 19:00:35 GMT):
@swcurran @ianco nvm, I got it working
I'll be cleaning up the code and raising PRs later today
ianco (Thu, 08 Jul 2021 19:26:48 GMT):
:+1:
filip.burlacu (Fri, 09 Jul 2021 21:07:17 GMT):
All afgo-acapy non-wip didexchange tests pass now
ianco (Fri, 09 Jul 2021 21:07:50 GMT):
Nice!
sheldon.regular (Fri, 09 Jul 2021 21:08:22 GMT):
:ok_hand:
filip.burlacu (Fri, 09 Jul 2021 21:15:10 GMT):
@sheldon.regular I also managed to avoid having to add acapy to `aath_network`, so it should avoid the strange errors people have seen with that
sheldon.regular (Fri, 09 Jul 2021 21:15:47 GMT):
ok awesome.
filip.burlacu (Fri, 09 Jul 2021 21:15:50 GMT):
https://github.com/hyperledger/aries-agent-test-harness/pull/281 is ready for review
sheldon.regular (Fri, 09 Jul 2021 21:16:12 GMT):
Is PR 281 ready? I'll give it a try if so.
filip.burlacu (Fri, 09 Jul 2021 21:16:30 GMT):
yes
filip.burlacu (Mon, 12 Jul 2021 16:26:00 GMT):
@swcurran https://github.com/hyperledger/aries-agent-test-harness/pull/288 is ready - sheldon can confirm that there are no test regressions in afgo from integrating orb, and on the orb side firas & troy confirm that everything looks good
swcurran (Tue, 13 Jul 2021 08:19:36 GMT):
Merged -- w00t!
swcurran (Tue, 13 Jul 2021 08:24:09 GMT):
Should we be merging https://github.com/hyperledger/aries-agent-test-harness/pull/281 as well? I ran it and got same result as current main.
filip.burlacu (Tue, 13 Jul 2021 14:20:03 GMT):
@swcurran it's ready
MatthewSpence (Wed, 14 Jul 2021 20:23:17 GMT):
I'm getting a new error when trying to run tests with Acapy in gitlab `No such file or directory: '/data-mount/plugin-config.yml` this started after I merged with the latest main, can somebody explain what's going on here?
sheldon.regular (Wed, 14 Jul 2021 20:25:51 GMT):
you may need the latest from main.
sheldon.regular (Wed, 14 Jul 2021 20:26:16 GMT):
This is just acapy throwing this?
MatthewSpence (Wed, 14 Jul 2021 20:27:20 GMT):
Acapy is the only agent I've tested other than Verity, which is still internal
MatthewSpence (Wed, 14 Jul 2021 20:27:30 GMT):
But yeah
MatthewSpence (Wed, 14 Jul 2021 20:28:22 GMT):
Also this should be the latest from Main
sheldon.regular (Wed, 14 Jul 2021 20:44:53 GMT):
you shouldn't be seeing that with the lastest. What is your run command?
MatthewSpence (Wed, 14 Jul 2021 20:48:47 GMT):
This is what I'm using to test locally: `docker run -it --expose 9020-9029 -p 9020-9029:9020-9029 -e AGENT_NAME=Acme -e LEDGER_URL=http://dev.bcovrin.vonx.io -e DOCKERHOST=172.17.0.1 --entrypoint bash acapy_test` getting this to run in gitlab is a bit different but getting the same issue
MatthewSpence (Wed, 14 Jul 2021 20:49:09 GMT):
the built image is tagged `acapy_test`, I built it manually
MatthewSpence (Wed, 14 Jul 2021 20:49:09 GMT):
the built image is tagged `acapy_test`, I built it outside the management script
filip.burlacu (Wed, 14 Jul 2021 21:09:20 GMT):
@MatthewSpence the manage script had to get a little smarter recently - it generates a plugin config YAML file for the plugin aca-py loads by default (`universal_resolver`) instead of that plugin config file being static, since it needs to amend the host IP of a config value to point to the docker host
run once with the manage script and it'll generate the file
MatthewSpence (Wed, 14 Jul 2021 21:10:32 GMT):
Can you point me to where in the management script that's done?
filip.burlacu (Wed, 14 Jul 2021 21:10:33 GMT):
(run anything, I know `acapy_test` would be rejected by the manage script)
filip.burlacu (Wed, 14 Jul 2021 21:11:06 GMT):
https://github.com/hyperledger/aries-agent-test-harness/blob/main/manage#L317
filip.burlacu (Wed, 14 Jul 2021 21:13:46 GMT):
one one machine the dockerhost shouldn't change, so you can just get the dockerhost value, open the template file, set the IP, and save it in whatever folder you like, then in your `docker run` command, mount that folder into `/data-mount`
filip.burlacu (Wed, 14 Jul 2021 21:15:58 GMT):
all agents now have the option to load files at runtime instead of just at build time
afgo and acapy use that so far, and the manage script sets the convention that the source directory is `
filip.burlacu (Wed, 14 Jul 2021 21:16:24 GMT):
I should add some documentation for this..
filip.burlacu (Wed, 14 Jul 2021 21:16:41 GMT):
(everything's automatic through the manage script though)
MatthewSpence (Wed, 14 Jul 2021 21:20:32 GMT):
My goal is to get this working in Gitlab, so it'll probably be a bit more complicated than that but I see what you're saying and I think I know what I need to do
filip.burlacu (Wed, 14 Jul 2021 21:23:55 GMT):
alternatively, add your acapy instance to the `aath_network` and use `uni-resolver-web.local` for the endpoint hostname in the plugin config file
and then the file can be static, and you can even add it in the Dockerfile
I didn't take this approach because people have reported issues with aca-py when it's added to `aath_network`, though, so ymmv
filip.burlacu (Wed, 14 Jul 2021 21:23:55 GMT):
alternatively, add your acapy instance to the `aath_network` network and use `uni-resolver-web.local` for the endpoint hostname in the plugin config file
and then the file can be static, and you can even add it in the Dockerfile
I didn't take this approach because people have reported issues with aca-py when it's added to `aath_network`, though, so ymmv
MatthewSpence (Wed, 14 Jul 2021 21:25:22 GMT):
Thanks for the advice, I'll see what I can do!
filip.burlacu (Thu, 15 Jul 2021 15:38:15 GMT):
@dbluhm why does `acapy-resolver-universal` require exactly `aries-cloudagent = "0.7.0rc1"` as a dependency?
How can we use the plugin in the test harness, where acapy-main needs to be unpinned to allow continuous integration testing?
dbluhm (Thu, 15 Jul 2021 15:38:15 GMT):
Has joined the channel.
filip.burlacu (Thu, 15 Jul 2021 15:47:17 GMT):
run `./manage rebuild -a acapy-main` in AATH to see the issue
filip.burlacu (Thu, 15 Jul 2021 15:51:35 GMT):
Maybe you can have two build targets / packages:
One for the plugin only, which a user needs to install with acapy
And one for the plugin+acapy for use in the plugin's integration tests
filip.burlacu (Thu, 15 Jul 2021 15:51:35 GMT):
Maybe you can have two build targets / packages?
One for the plugin only, which a user needs to install with acapy
And one for the plugin+acapy for use in the plugin's integration tests
dbluhm (Thu, 15 Jul 2021 15:59:23 GMT):
Hm. Good question. Sorry for the headache lol. Didn't realize this was already being used in AATH but happy to see it being used! Would `>= 0.7.0` solve our problem?
filip.burlacu (Thu, 15 Jul 2021 16:00:13 GMT):
I think so :)
dbluhm (Thu, 15 Jul 2021 16:08:03 GMT):
https://github.com/sicpa-dlab/acapy-resolver-universal/pull/12
Should have this merged soon. Now that 0.7.0 is out, hoping to have a tagged and published release soon as well.
dbluhm (Fri, 16 Jul 2021 16:01:55 GMT):
We started working with AATH more directly recently and we've run into some issues that I've attempted to correct with this PR: https://github.com/hyperledger/aries-agent-test-harness/pull/293
The nature of the issues has me a little perplexed though since it seems like nothing should be working but obviously the pipeline is still pushing out results (as far as I know at least lol) -- which leads me to feel that I might be missing something. Feedback is appreciated :slight_smile:
Laichonious (Fri, 16 Jul 2021 16:27:04 GMT):
Has joined the channel.
Laichonious (Fri, 16 Jul 2021 16:27:05 GMT):
Hey there! I'm a software tester with a basic, general knowledge of linux and software testing (read: total noob). I'm looking for some direction on general usage of AATH for someone who's just starting out. For example, is there an option or argument that I can include in the run command that will wait for my input at critical interaction points? Specifically, I need to scan a QR code to accept invitations/credentials in the mobile deployment of the app, but the script scrolls through those steps and zooms on by before I have a chance to react.
sheldon.regular (Fri, 16 Jul 2021 16:31:44 GMT):
Hi @Laichonious I believe the mobile tests should do exactly as you are describing. Have you tried that yet? https://github.com/hyperledger/aries-agent-test-harness/blob/main/MOBILE_AGENT_TESTING.md
swcurran (Fri, 16 Jul 2021 16:32:56 GMT):
You might have to scroll back to see the QR code, but soon after the text does stop everytime, so it's not that bad. Or get a very long terminal so it doesn't scroll off....
Laichonious (Fri, 16 Jul 2021 16:33:21 GMT):
Yes, those are the intructions that I've been following, though if that is what it is supposed to do, then I suspect there is something I might be doing incorrectly or there is a problem with how it has been set up
Laichonious (Fri, 16 Jul 2021 16:44:24 GMT):
@swcurran I can scroll back to the QR codes, but unfortunately I can't do anything with them. By the time I get one scanned, the rest have already printed and the test has concluded, so it starts shutting down all of the agents before I can establish a connection from the first invite
filip.burlacu (Fri, 16 Jul 2021 20:18:46 GMT):
PR to fix intermittent issues with uniresolver not always being ready when needed: https://github.com/hyperledger/aries-agent-test-harness/pull/296
swcurran (Sat, 17 Jul 2021 06:36:36 GMT):
That's very weird. When I've run it, it stops at the point where the other agent is issuing or verifying so I have lots of time to scan before moving to the next test. What agent are you using as issuers and verifiers?
swcurran (Sat, 17 Jul 2021 06:36:43 GMT):
@ianco ^^
dbluhm (Mon, 19 Jul 2021 18:35:05 GMT):
Okay, whose buttons do I need to push? lol our testing has only been unblocked by using the branch this PR is based on but would love to know if we're missing something
dbluhm (Mon, 19 Jul 2021 18:43:09 GMT):
I witnessed this same behavior on (and unblocked @Laichonious with) my fixed branch on the PR linked in my other message. Perhaps the odd behavior is another symptom of another problem?
dbluhm (Mon, 19 Jul 2021 18:48:26 GMT):
The issuers and verifiers were ACA-Py@main
ianco (Mon, 19 Jul 2021 19:30:10 GMT):
Hi @dbluhm I just did a clean build/run from the latest `main` branch and everything worked ok.
ianco (Mon, 19 Jul 2021 19:30:12 GMT):
`./manage run -d acapy-main -t @AcceptanceTest -t ~@wip`
ianco (Mon, 19 Jul 2021 19:30:52 GMT):
The Dockerfile was changed recently to use `FROM python:3.7-slim` (instad of what we used to use)
ianco (Mon, 19 Jul 2021 19:31:19 GMT):
What command are you running? I think ngrok is only started when the mobile backchannel is used ...
ianco (Mon, 19 Jul 2021 19:32:17 GMT):
I'll give this a try, I notice (from another @dbluhm question) that a recent Dockerfile change may be causing this issue...
dbluhm (Mon, 19 Jul 2021 19:33:18 GMT):
Ah -- yes, we were using the following command: `LEDGER_URL_CONFIG=http://test.bcovrin.vonx.io TAILS_SERVER_URL_CONFIG=https://tails.vonx.io ./manage run -d acapy-main -b mobile -n -t @MobileTest`
dbluhm (Mon, 19 Jul 2021 19:33:44 GMT):
Taken from the docs on mobile testing
ianco (Mon, 19 Jul 2021 19:34:13 GMT):
OK I'll test out your PR, thanks for this fix!
dbluhm (Mon, 19 Jul 2021 19:35:13 GMT):
Thanks for checking it out! I worry it's an incomplete fix given the strange behavior @Laichonious mentioned but hopefully it's a step in the right direction
ianco (Mon, 19 Jul 2021 20:24:17 GMT):
FYI without your PR I get the "curl" error (I suspect related to the docker change) and *with* your PR I get the same behaviour as @Laichonious reported on the other thread. I'm looking into it ...
ianco (Mon, 19 Jul 2021 20:25:26 GMT):
I've pulled @dbluhm 's PR (fixes another issue) and am able to duplicate this issue. There's an error establishing the initial connection to the mobile, that's why the tests just continue to zip along ...
ianco (Mon, 19 Jul 2021 20:25:32 GMT):
I'm looking into it further ...
ianco (Mon, 19 Jul 2021 20:38:47 GMT):
Aha I think this commit broke it: https://github.com/hyperledger/aries-agent-test-harness/commit/31d2ce5c4e8b7807a93008cb0a52c1962d7575d5#diff-4f9f4e26fd1603606f340759f023d1dcff4e270b8d8813c8c63e5bbd86e468d6
ianco (Mon, 19 Jul 2021 20:39:18 GMT):
It removes some "wait" steps
ianco (Tue, 20 Jul 2021 18:41:29 GMT):
This (draft) PR fixes the issue with mobile connections: https://github.com/hyperledger/aries-agent-test-harness/pull/299
ianco (Tue, 20 Jul 2021 18:42:07 GMT):
"Draft" because I'm still having issues with esatus and the connections - the connection is established but esatus doesn't seem to recognize that (even though the downstream connections and proofs work ...)
ianco (Tue, 20 Jul 2021 18:42:13 GMT):
Still testing ...
ianco (Tue, 20 Jul 2021 20:19:54 GMT):
Done with this PR, would be interested in what results others get. For me Trinsic works with no issues, esatus works but there is some confusing establishing the connection (try it, you'll see)
Laichonious (Tue, 20 Jul 2021 21:50:21 GMT):
Haha! Yes, the test harness is now behaving as intended, though I have not gotten it to work with either Trinsic or the app I'm testing, so I suspect there is a network configuration mismatch somewhere.
ianco (Tue, 20 Jul 2021 22:25:34 GMT):
FYI @sheldon.regular tested the PR and merged it into `main`
swcurran (Wed, 21 Jul 2021 13:42:12 GMT):
FYI -- AFJ and AF.NET daily tests passing dropped from last night's run. E.g. AF-J to AF.NET drop from 27/36 passing to 6/36 passing. Hoping someone can dig take a look. You can drill down from here: https://allure.vonx.io/api/allure-docker-service/projects/javascript-b-dotnet/reports/latest/index.html?redirect=false#behaviors
TimoGlastra (Wed, 21 Jul 2021 13:53:39 GMT):
I'll try to take a look. Seems like something is broken as almost all tests are failing
swcurran (Wed, 21 Jul 2021 14:44:40 GMT):
Let me know if the report that I linked above was helpful. Hoping we can get in the habit of using that resource to easily find issues.
swcurran (Wed, 21 Jul 2021 14:44:55 GMT):
Fixing them might be different... :-)
TimoGlastra (Wed, 21 Jul 2021 14:47:10 GMT):
Definitely useful. However I think we can improve on the usefulness by logging a bit more info. Most errors just show `AssertionError` or something. Not sure if that would be easy to do...
TimoGlastra (Wed, 21 Jul 2021 14:47:36 GMT):
Also maybe uploading the logs from `.logs` directory so you can see the agent logs themselves
TimoGlastra (Wed, 21 Jul 2021 14:47:41 GMT):
AFJ spits out a lot
swcurran (Wed, 21 Jul 2021 14:47:46 GMT):
k
TimoGlastra (Wed, 21 Jul 2021 14:50:26 GMT):
I can take a look at uploading the logs. Have done something similar for AFJ: https://github.com/hyperledger/aries-framework-javascript/blob/fb28935a0658ef29ee6dc3bcf7cd064f15ac471b/.github/workflows/continuous-integration.yml#L113-L127
filip.burlacu (Wed, 21 Jul 2021 15:50:31 GMT):
add this after the run-test-harness(-wo-reports) action:
```
- name: archive logs
uses: actions/upload-artifact@v2
with:
name: logs
path: test-harness/**/*.log
```
this is exactly what I used a few days ago to test my PRs
filip.burlacu (Wed, 21 Jul 2021 15:50:31 GMT):
add this after the run-test-harness(-wo-reports) action in a workflow you want to log:
```
- name: archive logs
uses: actions/upload-artifact@v2
with:
name: logs
path: test-harness/**/*.log
```
this is exactly what I used a few days ago to test my PRs
TimoGlastra (Wed, 21 Jul 2021 19:17:42 GMT):
Thanks @filip.burlacu
TimoGlastra (Wed, 21 Jul 2021 19:18:57 GMT):
AF.NET crashes when it receives a did document with any service that is different from `IndyAgent`. We send both `IndyAgent` and `did-communication`. I can remove it in AFJ, but seems more like an AF.NET issue
```
{
"id": "XQzpmfw5BV6wF2vpkXsZvB#did-communication",
"serviceEndpoint": "http://192.168.65.6:9021",
"type": "did-communication",
"priority": 1,
"recipientKeys": ["HaSRSaEFVHsv1jqxCxxQEDvgJwXAkMDgkKhPEBe3SbNj"],
"routingKeys": []
}
```
swcurran (Wed, 21 Jul 2021 21:15:46 GMT):
@tomislav @mboyd -- this would seem to be important.
TimoGlastra (Wed, 21 Jul 2021 21:48:42 GMT):
Made a fix in AFJ and updated the .NET backchannel: https://github.com/hyperledger/aries-agent-test-harness/pull/300
swcurran (Sat, 24 Jul 2021 20:30:01 GMT):
FYI -- looks like support has been broken for running AATH on Play With Docker. Not the end of the world, but it was a nice option for getting started quickly with just a browser -- no other dependencies.
Perhaps we should restore, or perhaps we should look at GitPod. The folks creating Business Partner Agent did that, and it's a pretty sweet setup. Perhaps a "help wanted" effort?
For now, I'll likely just remove the references to Play with Docker.
MatthewSpence (Mon, 26 Jul 2021 16:19:17 GMT):
Can I get a quick explanation of the uniresolver and did-sov driver services that the test harness spins up? Are those absolutely necessary for the test harness to run the connections protocol correctly?
swcurran (Mon, 26 Jul 2021 16:50:55 GMT):
Some Aries frameworks now have general DID resolver capabilities so that regardless of the DID they receive, they can resolve it. The uniresolver is based on the Universal Resolver and so covers a number of DID methods, the did-sov one is specifically for DID sov.
Depending on the framework you want to interact with, you may need those. For example, ACA-Py had not heard of "did:orb" until it added the capability to use an external resolver (like uniresolver) and then resolved the DID using that.
All that to say, if you don't use a universal resolver, you don't need it. If you are running tests with a Test Agent that uses it and you are using DIDs that they will need the resolvers to resolve, you will need it.
Right now, ACA-Py can use it, but only needs it for tests not using did:sov, did:peer and did:key.
AF-Go uses the did-sov resolver to resolve did:sov DIDs. AF-Go use did:orb, so to connect to an AF-Go instance, you will likely need a DID resolver.
Hope that makes sense...
MatthewSpence (Mon, 26 Jul 2021 16:51:58 GMT):
yes that makes sense. Thank you
filip.burlacu (Tue, 27 Jul 2021 13:37:18 GMT):
Tangentially related to the above ^, I'd like to come up with a way to determine which services to start based on which tests are being run
why run tails if we don't need it, why run uniresolver, etc
some tests shouldn't even need VON running
filip.burlacu (Tue, 27 Jul 2021 13:37:18 GMT):
Tangentially related to the above ^, I'd like to come up with a way to determine which services to start based on which tests are being run, and with which agents
why run tails if we don't need it, why run uniresolver, etc
some tests shouldn't even need VON running
swcurran (Tue, 27 Jul 2021 13:48:46 GMT):
Agreed. We'd have to move the services and agents starting to being part of the test harness vs. in parallel, I think.
filip.burlacu (Wed, 28 Jul 2021 06:42:31 GMT):
https://github.com/hyperledger/aries-agent-test-harness/pull/308 is ready for review
I ran the afgo-afgo (https://github.com/Moopli/aries-agent-test-harness/actions/runs/1073840810) and acapy-aip20 (https://github.com/Moopli/aries-agent-test-harness/actions/runs/1073843961) workflows on this branch on my fork, to verify that my changes to the test data (to make said data more conformant with its schemas) wouldn't break a more permissive agent
filip.burlacu (Wed, 28 Jul 2021 13:35:30 GMT):
^ actually, just gonna add one more change, I should be able to get the last few tests working too
swcurran (Wed, 28 Jul 2021 14:29:06 GMT):
Awesome news -- that's great!
swcurran (Wed, 28 Jul 2021 21:53:36 GMT):
@filip.burlacu is there any interest in doing a session at the DIF Interop group about the progress being made on the Interop testing being done here? I think the recent work about interop between AF-Go and ACA-Py is worth talking about in the community.
We could also cover the recent additions to ACA-Py, and the overall feature set in AF-Go.
filip.burlacu (Wed, 28 Jul 2021 22:00:44 GMT):
Yeah, that's worth talking about - I think once we can demonstrate AIP2 issue-credential and present-proof interop, that'll be a good milestone :)
swcurran (Wed, 28 Jul 2021 22:09:51 GMT):
Plus the DID Orb work and uniresolver component.
jljordan_bcgov (Wed, 28 Jul 2021 22:13:40 GMT):
👍🏼
MatthewSpence (Fri, 30 Jul 2021 19:35:12 GMT):
Can somebody explain how to configure aca-py to use an ngrok endpoint in the test harness? I'm seeing logic that indicates this is possible and I think I'll need it to get things working in Gitlab
swcurran (Fri, 30 Jul 2021 19:51:41 GMT):
IN the ./manage arguments, use the "-n" option.
swcurran (Fri, 30 Jul 2021 19:51:50 GMT):
Is that what you need?
MatthewSpence (Fri, 30 Jul 2021 19:55:02 GMT):
I think so, thank you
MatthewSpence (Fri, 30 Jul 2021 19:55:43 GMT):
Gitlab is NOT friendly to this kind of setup when you have no runners that support docker-in-docker
MatthewSpence (Fri, 30 Jul 2021 19:55:51 GMT):
To be clear though that's Gitlab's fault
MatthewSpence (Fri, 30 Jul 2021 19:55:51 GMT):
To be clear though that's Gitlab's fault, not the test harness
MatthewSpence (Tue, 03 Aug 2021 21:37:50 GMT):
Initial PR for the Verity Backchannel is in: https://github.com/hyperledger/aries-agent-test-harness/pull/313
MatthewSpence (Tue, 03 Aug 2021 21:40:32 GMT):
Some notes: This only supports the Connection Protocol, and only the Inviter role. The main purpose of this is to get the plumbing in place so we can add more protocols in the future, since Verity is kind of a weird fit for this setup. Any and all feedback is appreciated
MatthewSpence (Tue, 03 Aug 2021 21:40:32 GMT):
Some notes: This only supports the Connection Protocol, and only the Inviter role. The main purpose of this is to get the plumbing in place so we can add more protocols in the future. Any and all feedback is appreciated
filip.burlacu (Thu, 05 Aug 2021 05:00:24 GMT):
https://github.com/hyperledger/aries-agent-test-harness/pull/315
a fix to maintain afgo-afgo coverage for rfc 0453/0454
bruno.hivert (Fri, 10 Sep 2021 19:44:14 GMT):
Has joined the channel.
bruno.hivert (Fri, 10 Sep 2021 19:44:15 GMT):
@regiseloi
regiseloi (Fri, 10 Sep 2021 19:44:15 GMT):
Has joined the channel.
regiseloi (Fri, 10 Sep 2021 19:45:03 GMT):
Cross posted from #aries
I'm running into some unexpected and inconsistent issues with the Aries test harness (AATH).
I'm testing using several mobile wallets on iOS (Lissi among others), but I keep having problems accepting the connection request from Faber when executing @T001.5-RFC0037. I have no problem with T001-RFC0160, so I'm not sure what is different about this connection request (I can also execute @T003-RFC0036 without a problem).
The mobile agent gets the connection request, but it's unable to accept it.
FYI, here's the command I use (this is using ACA-Py 0.7.1RC0):
LEDGER_URL_CONFIG=http://test.bcovrin.vonx.io TAILS_SERVER_URL_CONFIG=https://tails.vonx.io ./manage run -d acapy-main -b mobile -n -r allure -t @T001.5-RFC0037
And more details on what is happening at the time:
`/steps/0160-connection.py:272 62.928sonnection_id, state'}
Assertion Failed: FAILED SUB-STEP: And "Faber" sends a connection response to "Bob"
Substep info: Assertion Failed: resp_status 500 is not 200; Expected state request but note recevied
Traceback (of failed substep):
File "/usr/local/lib/python3.7/site-packages/behave/model.py", line 1329, in run
match.run(runner.context)
File "/usr/local/lib/python3.7/site-packages/behave/matchers.py", line 98, in run
self.func(context, args, kwargs)
File "features/steps/0160-connection.py", line 161, in step_impl
assert resp_status == 200, f'resp_status {resp_status} is not 200; {resp_text}'`
I'd welcome any suggestions to troubleshoot this further!
sheldon.regular (Fri, 10 Sep 2021 19:51:17 GMT):
What other mobile wallets are you using? I've been using Trinsic and esatus the last couple of days with no problems on that test.
sheldon.regular (Fri, 10 Sep 2021 19:53:41 GMT):
I have tried Lissi this morning and I get that same issue. However, I could not set the ledger as the instructions says here https://vonx.io/getwallet#lissi-wallet. So I abandoned my effort with lissi
regiseloi (Fri, 10 Sep 2021 19:55:10 GMT):
I get the same error with Trinsic and esatus.
sheldon.regular (Fri, 10 Sep 2021 19:55:59 GMT):
Also, just an FYI, you can remove that `-r allure` from your command. It's for generating formal allure reports. No need of it here unless you want allure results for some reason?
sheldon.regular (Fri, 10 Sep 2021 19:56:40 GMT):
Have you followed the setup instructions on this page for Trinsic and esatus? https://vonx.io/getwallet#lissi-wallet
regiseloi (Fri, 10 Sep 2021 19:58:00 GMT):
Yes, all my wallets are configured for BCovrin test. And as I mentioned, I'm able to run RFC0036 and accept a credential offer.
sheldon.regular (Fri, 10 Sep 2021 20:03:29 GMT):
Not sure if this will solve the problem but you don't seem to have the latest from the repo. That message `Expected state request but note recevied` is old and there have been some rework there in the last few weeks. Could you try it with the latest?
sheldon.regular (Fri, 10 Sep 2021 20:03:29 GMT):
Not sure if this will solve the problem but you don't seem to have the latest from the repo. That message `Expected state request but note recevied` is old and there has been some rework there in the last few weeks. Could you try it with the latest?
regiseloi (Fri, 10 Sep 2021 20:04:27 GMT):
Interesting, thanks for pointing that out. That's odd, we just installed it a few days ago, but we should check on this.
sheldon.regular (Fri, 10 Sep 2021 22:04:18 GMT):
Just want to mention I was just able to run that `T001.5-RFC0037` test successfully with lissi.
JamesEbert (Sat, 11 Sep 2021 06:09:42 GMT):
Has joined the channel.
DenverNaicker (Sun, 12 Sep 2021 17:00:02 GMT):
Has joined the channel.
jcourt (Sun, 12 Sep 2021 23:25:06 GMT):
Has joined the channel.
Anasalamin (Mon, 13 Sep 2021 13:03:56 GMT):
Has joined the channel.
regiseloi (Mon, 13 Sep 2021 17:11:27 GMT):
Thanks Sheldon. We think we're having some kind of connection issues with ngrok when running the test harness on a VM rather than a local installation.
regiseloi (Wed, 15 Sep 2021 21:37:34 GMT):
In case anyone was curious: we uncovered some weird issues with ngrok and centos7. We switched to Debian 10 for that specific VM and all is well in the world again.
sheldon.regular (Wed, 15 Sep 2021 21:39:09 GMT):
Excellent. Thanks for the info. Good to know.
lauravuo-techlab (Fri, 17 Sep 2021 09:41:53 GMT):
PR for findy-agent backchannel: https://github.com/hyperledger/aries-agent-test-harness/pull/341 All feedback is welcome :pray:
swcurran (Fri, 17 Sep 2021 14:24:35 GMT):
Awesome @lauravuo-techlab -- really looking forward to trying this and looking at the Findy Agent! Loved the Travelogue blog post.
regiseloi (Fri, 17 Sep 2021 22:18:25 GMT):
I'm testing several mobile wallets, and I've run into an interesting situation with how existing connections are being handled: all tests start with RFC0160 to connect the agents. One particular wallet app gives me a "you are already connected to this org" message, which causes the tests to fail, because as far as I can tell it's not sending a response back at all.to accept or
(I tried manually deleting the existing connection records from the app, but it's too clever and doesn't let me do that if it has received or accepted a credential offer from that issuer before)
I'm trying to understand how this should be working, and what response the mobile agent should be sending back. It looks like it may not be sending a response at all.
regiseloi (Fri, 17 Sep 2021 22:18:25 GMT):
I'm testing several mobile wallets, and I've run into an interesting situation with how existing connections are being handled: all tests start with RFC0160 to connect the agents. One particular wallet app gives me a "you are already connected to this org" message, which causes the tests to fail, because as far as I can tell it's not sending a response back at all.
(I tried manually deleting the existing connection records from the app, but it's too clever and doesn't let me do that if it has received or accepted a credential offer from that issuer before)
I'm trying to understand how this should be working, and what response the mobile agent should be sending back. It looks like it may not be sending a response at all.
Here's the traceback, I'd be happy to provide more details if needed. But mostly I'm interested to know if anyone has come across this before.
`Traceback (most recent call last):
File "/aries-backchannels/python/agent_backchannel.py", line 319, in _post_command_backchannel
operation, rec_id=rec_id, data=data
File "acapy/acapy_backchannel.py", line 532, in make_agent_POST_request
raise Exception(f"Expected state request but not received")
Exception: Expected state request but not received`
sheldon.regular (Mon, 20 Sep 2021 16:12:22 GMT):
Is the wallet app that manifests the problem available for me to use and reproduce?
regiseloi (Mon, 20 Sep 2021 19:32:59 GMT):
You can try Adeya SSI wallet, that one is available in the app store.
sheldon.regular (Mon, 20 Sep 2021 20:03:22 GMT):
Thanks I'll give it a go.
sheldon.regular (Tue, 21 Sep 2021 14:02:37 GMT):
@regiseloi The Adeya wallet appears to be trying to uniquely identify a individual agent using the `label` attribute in the invitation. If the label is the same it reports `you are already connected to this org`. If I make the label unique for every invitation then Adeya accepts the invitation and you can create the connection. This seems odd to me as there is no guarantee that the label in the calling agent is using the label to uniquely identify itself, or expecting others to identify itself by this attribute. The label doesn't seem to be a great way to identify the agent. So you have any insight on this?
sheldon.regular (Tue, 21 Sep 2021 14:02:37 GMT):
@regiseloi The Adeya wallet appears to be trying to uniquely identify a individual agent using the `label` attribute in the invitation. If the label is the same it reports `you are already connected to this org`. If I make the label unique for every invitation then Adeya accepts the invitation and you can create the connection. This seems odd to me as there is no guarantee that the label in the calling agent is using the label to uniquely identify itself, or expecting others to identify itself by this attribute. The label doesn't seem to be a great way to identify the agent. Do you have any insight on this?
regiseloi (Tue, 21 Sep 2021 19:01:45 GMT):
That's really helpful. I'm curious how you figured that out, but that makes a lot of sense.
I can see what someone was trying to do from a UX perspective, but using the label attribute this way is probably not the best way to go about it.
I'll provide the feedback to the team behind this if/when I get a chance.
Am I right in thinking that there's no way today to overwrite the default labels with the Aries test harness?
sheldon.regular (Tue, 21 Sep 2021 21:07:18 GMT):
It was a hunch since I seen the label used in messages in the wallet. I just made the test add a unique id to the label after each invitation was created to test it.
I can make the tests do this unique label all the time, but I am reluctant to do so given there is no rule that this label is to be unique, and there is no way to make it unique just for that wallet. It would have to be for all agents using the test harness.
If it helps you move forward, I can possibly do it temporarily and remove it when there is another approach in that wallet?
regiseloi (Tue, 21 Sep 2021 21:12:15 GMT):
Let me think about this, but I'd also be reluctant to make a change to the test harness that might suggest that the label should be unique, when it's clearly not meant to be used this way. Thanks for sharing your insights
sheldon.regular (Tue, 21 Sep 2021 21:49:12 GMT):
np, keep me posted. :thumbsup:
sheldon.regular (Fri, 24 Sep 2021 16:12:23 GMT):
@lauravuo-techlab I'm attempting to run findy with the the javascript and dotnet agents. However, I can't get the findy agent to run locally. Both with the AATH manage script and outside running the findy agent with docker, I get the following messages. I'm hoping you may be able to help me get it going properly.
```
Starting backchannel to port 9020 and agent to port 9021
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3092 100 3092 0 0 1006k 0 --:--:-- --:--:-- --:--:-- 1006k
nohup: redirecting stderr to stdout
Pool created successfully by name: interop
I0924 16:05:40.847210 32 findy.go:25] {"backtrace":"","message":"Error: Pool timeout\n Caused by: No consensus possible\n"}
Error: Error: Pool timeout
Caused by: No consensus possible
nohup: redirecting stderr to stdout
2021/09/24 16:05:41 Starting server at port 9020
2021/09/24 16:05:41 Auth url http://localhost:8888, origin localhost:8888, user findy-agent-backchannel-1632499541863774800
panic: execute authenticator: register user: status code: 500 Internal Server Error
goroutine 1 [running]:
github.com/lainio/err2.Check(...)
/go/pkg/mod/github.com/lainio/err2@v0.6.1/err2.go:34
github.com/findy-network/findy-agent-backchannel/agent.Init(0xab6395)
/go/findy-agent-backchannel/agent/agent.go:70 +0x46b
main.main()
/go/findy-agent-backchannel/main.go:31 +0xea
```
lauravuo-techlab (Mon, 27 Sep 2021 04:03:36 GMT):
The easiest option is probably run with the AATH manage script. Which commands are you now using to run the tests?
sheldon.regular (Mon, 27 Sep 2021 15:56:19 GMT):
I'm running the same command that is used for the workflow test runset as documented in the yml file. However I run the tails server and von network outside of the manage script. Usually the agents just see these existing and use them. However with findy it only works if I let the manage script handle von network and the tails server. So I'm good for now, I'm running everything from the manage script, but I wouldn't mind knowing why it doesn't work outside of manage. It makes it a little more difficult for debugging.
swcurran (Mon, 27 Sep 2021 19:07:02 GMT):
I'm suddenly getting errors in local environment running AATH. Error relates to a missing network on starting the services -- tails and universal resolvers. Has anyone else seen that? Any ideas? This is on a basic test run that I've done 1000 times before.
```
Creating von_webserver_1 ... done
Creating von_node4_1 ... done
Creating von_node2_1 ... done
Creating von_node3_1 ... done
Creating von_node1_1 ... done
Want to see the scrolling container logs? Run "./manage logs"
waiting for ledger to start.........
starting local uniresolver...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 3076 100 3076 0 0 500k 0 --:--:-- --:--:-- --:--:-- 500k
Starting driver-did-sov.local ...
Starting uni-resolver-web.local ... error
Starting driver-did-sov.local ... error9c not found
ERROR: for driver-did-sov.local Cannot start service driver-did-sov.local: network ec486eddeffca04bf1ccc130d3d2adc76ee0d38fc2515281e5eca6ac53a0429c not found
ERROR: for uni-resolver-web.local Cannot start service uni-resolver-web.local: network ec486eddeffca04bf1ccc130d3d2adc76ee0d38fc2515281e5eca6ac53a0429c not found
ERROR: for driver-did-sov.local Cannot start service driver-did-sov.local: network ec486eddeffca04bf1ccc130d3d2adc76ee0d38fc2515281e5eca6ac53a0429c not found
ERROR: Encountered errors while bringing up the project.
starting local indy-tails-server...
Starting docker_tails-server_1 ... error
Starting docker_ngrok-tails-server_1 ...
ERROR: for docker_tails-server_1 Cannot start service tails-server: network 17e9c2ef9f12c5d743e3dc7597ea91c17461372a04ad7c2edf181309bec7d38a not founStarting docker_ngrok-tails-server_1 ... error
ERROR: for docker_ngrok-tails-server_1 Cannot start service ngrok-tails-server: network 17e9c2ef9f12c5d743e3dc7597ea91c17461372a04ad7c2edf181309bec7d38a not found
ERROR: for tails-server Cannot start service tails-server: network 17e9c2ef9f12c5d743e3dc7597ea91c17461372a04ad7c2edf181309bec7d38a not found
ERROR: for ngrok-tails-server Cannot start service ngrok-tails-server: network 17e9c2ef9f12c5d743e3dc7597ea91c17461372a04ad7c2edf181309bec7d38a not found
ERROR: Encountered errors while bringing up the project.
waiting for tails server to start..................
```
swcurran (Mon, 27 Sep 2021 19:14:47 GMT):
I've deleted docker images, rebooted. A clue is that the network being looked remains the same after all the changes, so there is some persistence somewhere. No volumes so it's not that. Sigh...
swcurran (Mon, 27 Sep 2021 19:22:57 GMT):
Fixed -- should have known... `docker system prune` resolved it. Likely the cache, as I had done prune on everything else. Sigh, again...
swcurran (Mon, 27 Sep 2021 19:42:54 GMT):
BTW - Sheldon, since the Waits don't seem to make any difference, should we reset them back to where they were?
sheldon.regular (Mon, 27 Sep 2021 19:43:56 GMT):
They do work, sort of, a couple more tests fail when they are not there.
sheldon.regular (Mon, 27 Sep 2021 19:44:27 GMT):
I'd say if someone can figure out a better solution, then remove the waits?
sheldon.regular (Mon, 27 Sep 2021 19:44:51 GMT):
are you running that javascript-b-acapy runset locally?
swcurran (Mon, 27 Sep 2021 19:45:51 GMT):
Not right now, but running something else that uses javascript that is going very slowly.
sheldon.regular (Mon, 27 Sep 2021 19:46:03 GMT):
ic
TimoGlastra (Mon, 27 Sep 2021 21:04:46 GMT):
@sheldon.regular could you give some context on the issue? I may be able to take a look. Why were the state checks removed? Are the intermediate endpoints still called? One option would be to enable auto acceptance of credentials/proofs. Another option would be to use an event based approach so we’re never waiting longer than needed
sheldon.regular (Mon, 27 Sep 2021 21:25:31 GMT):
Hi Timo. Thanks for the offer to help. The state checks were removed to accommodate agents that do not expose the states to their controllers or do not even track the states of the agent's protocol process at all. It was also done to help agents that are in an auto respond mode (some only have an auto respond mode), to just pass a 200 back on the call that was already automatically done.
Before this change, as you know, the tests would check for the proper state in all participating agents, then proceed. Removing this has had side effects that has required some `waits` to be put into some backchannels waiting for other agents to finish processing requests etc. I have put 3 of these in the javascript backchannel, that look like this, `await new Promise(f => setTimeout(f, 20000));`. This has cleared up 2-3 test failures in the runset, but we still get some failing in the daily run. These tests all work most of the time when running on my local machine, and always work when debugging, so that has been pain in trying to narrow down the problem. This only happens with the javascript-b-acapy runset.
lauravuo-techlab (Tue, 28 Sep 2021 06:52:26 GMT):
Ok! The findy backchannel image expects genesis file to be found in url `http://${DOCKERHOST}:9000/genesis` so unfortunately it is currently hardcoded. I take an action point for fixing this :thumbsup:
sheldon.regular (Tue, 28 Sep 2021 16:44:14 GMT):
I'm wondering if you can help investigate this issue. On the connection inside of all tests, the findy agent successfully connects when running with `acapy-main`. However running with `javascript` and `dotnet-master` agents the findy agent fails to send the trust ping at the end of the test.
```
@T001-RFC0160 @critical @AcceptanceTest @MobileTest
Scenario Outline: establish a connection between two agents -- @1.1 # features/0160-connection.feature:21
Given we have "2" agents # features/steps/0160-connection.py:16 0.001s
| name | role |
| Acme | inviter |
| Bob | invitee |
When "Acme" generates a connection invitation # features/steps/0160-connection.py:79 0.015s
And "Bob" receives the connection invitation # features/steps/0160-connection.py:110 0.811s
And "Bob" sends a connection request to "Acme" # features/steps/0160-connection.py:172 0.097s
And "Acme" receives the connection request # features/steps/0160-connection.py:187 0.000s
And "Acme" sends a connection response to "Bob" # features/steps/0160-connection.py:150 0.007s
And "Bob" receives the connection response # features/steps/0160-connection.py:163 0.000s
And "Acme" sends trustping to "Bob" # features/steps/0160-connection.py:367 65.395s
Assertion Failed: resp_status 404 is not 200; "connection by the id da0db625-888a-439f-bae3-8d46a44811c0 not found"
```
Any ideas what might be going on here?
lauravuo-techlab (Wed, 29 Sep 2021 04:19:51 GMT):
Yes, I'll take a look.
lauravuo-techlab (Wed, 29 Sep 2021 09:19:08 GMT):
There seems to be a mismatch in the HTTP request header Content-Type. I try to fix it to findy-agent. However, even with the fix the connection is not established between dotnet (acme) - findy (bob) -> there seems to happen some exceptions with states: `An unhandled exception was thrown by the application.
Hyperledger.Aries.AriesFrameworkException: Connection state was invalid. Expected 'Negotiating', found 'Invited'`
lauravuo-techlab (Wed, 29 Sep 2021 09:19:08 GMT):
There seems to be a mismatch in the HTTP request header Content-Type. I try to fix it to findy-agent. However, even with the fix the connection is not established between dotnet (acme) - findy (bob) -> there seems to happen some exceptions with states:`An unhandled exception was thrown by the application.
Hyperledger.Aries.AriesFrameworkException: Connection state was invalid. Expected 'Negotiating', found 'Invited'`
lauravuo-techlab (Wed, 29 Sep 2021 09:19:08 GMT):
There seems to be a mismatch in the HTTP request header Content-Type. I try to fix it to findy-agent. However, even with the fix the connection is not established between dotnet (acme) - findy (bob) -> there seems to happen some exceptions with states:
`An unhandled exception was thrown by the application.
Hyperledger.Aries.AriesFrameworkException: Connection state was invalid. Expected 'Negotiating', found 'Invited'`
lauravuo-techlab (Wed, 29 Sep 2021 09:19:08 GMT):
There seems to be a mismatch in the HTTP request header Content-Type. I try to fix it to findy-agent. However, even with the fix the connection is not established between dotnet (acme) - findy (bob) -> there seems to happen some exceptions with states:
`An unhandled exception was thrown by the application. Hyperledger.Aries.AriesFrameworkException: Connection state was invalid. Expected 'Negotiating', found 'Invited'`
lauravuo-techlab (Wed, 29 Sep 2021 09:19:08 GMT):
There seems to be a mismatch in the HTTP request header Content-Type. I try to fix it to findy-agent. However, even with the fix the connection is not established between dotnet (acme) - findy (bob) -> there seems to happen some exceptions with dotnet states:
`An unhandled exception was thrown by the application. Hyperledger.Aries.AriesFrameworkException: Connection state was invalid. Expected 'Negotiating', found 'Invited'`
sheldon.regular (Wed, 29 Sep 2021 13:59:07 GMT):
Is that message coming from acapy? I don't know of the state `Negotiating` in acapy.
Have you tried the same test with the Javascript agent?
Is the fix submitted to findy-agent so I can rebuild and try it?
lauravuo-techlab (Wed, 29 Sep 2021 15:54:32 GMT):
I will submit the fix tomorrow and let you know once the new build is available.
sheldon.regular (Wed, 29 Sep 2021 15:55:25 GMT):
ok thanks.
filip.burlacu (Wed, 29 Sep 2021 23:06:43 GMT):
I have an idea that builds on top of a feature I added in my latest PR (speaking of which, we have acapy-afgo present proof interop now)
I made some changes to the afgo dockerfiles and manage script, to allow the afgo agents to be built using `./manage build` without that common issue where docker uses cache instead of fetching the latest afgo source from github. This means faster builds locally, since every step can cache, with the git checkout and build steps skipping cache when the remote is on a new HEAD commit.
We can apply the same changes to other agents, for anyone doing a lot of dev work on the agent while testing in AATH (like I've been doing) it can really speed your workflow up.
Additionally, with a bit more work, we could set up the CI to use a caching server, cache its agent builds, and use this same mechanism, so the CI only needs to rebuild an agent binary when the agent itself has been updated (since otherwise, it can still get it from cache).
filip.burlacu (Wed, 29 Sep 2021 23:07:28 GMT):
I discussed this in DMs with sheldon, what do you think @swcurran @andrew.whitehead ?
andrew.whitehead (Wed, 29 Sep 2021 23:07:28 GMT):
Has joined the channel.
andrew.whitehead (Thu, 30 Sep 2021 02:41:38 GMT):
Sounds reasonable to me
lauravuo-techlab (Thu, 30 Sep 2021 12:02:00 GMT):
The Content-Type-fix is now available in latest findy-backchannel-bundle. You need to pull the latest image:
`docker pull ghcr.io/findy-network/findy-agent-backchannel:findy-bc-bundle-latest`
I didn't have yet a chance to try the fix with JS/dotnet agents.
lauravuo-techlab (Thu, 30 Sep 2021 12:02:00 GMT):
The Content-Type-fix is now available in latest findy-backchannel-bundle. You need to pull the latest image:
`docker pull ghcr.io/findy-network/findy-agent-backchannel:findy-bc-bundle-latest`
I didn't have yet a chance to try the fix fully with JS/dotnet agents.
sheldon.regular (Thu, 30 Sep 2021 14:49:58 GMT):
Will I get the update if I just do `./manage rebuild findy`?
swcurran (Thu, 30 Sep 2021 15:51:01 GMT):
> (speaking of which, we have acapy-afgo present proof interop now)
swcurran (Thu, 30 Sep 2021 15:51:01 GMT):
Great work!
> (speaking of which, we have acapy-afgo present proof interop now)
swcurran (Thu, 30 Sep 2021 15:51:49 GMT):
Sounds good -- let's take a look and see how it can apply.
sheldon.regular (Thu, 30 Sep 2021 23:29:09 GMT):
We have some good headway the with the findy and dotnet agents. 6 of 13 scenarios pass, and the issue above is not present in that configuration. I am still getting the exact same issue above when running with the javascript agent however.
lauravuo-techlab (Fri, 01 Oct 2021 05:04:30 GMT):
Ok, thanks for the info! I will continue investigations.
filip.burlacu (Tue, 05 Oct 2021 21:57:58 GMT):
is the google sheet downloaded by genBCData.py out-of-date?
I run genBCData and then didexchange afgo-afgo fails
(and yes, it passes when my local is clean on main)
sheldon.regular (Tue, 05 Oct 2021 22:03:43 GMT):
It shouldn't be, but it is possible.
filip.burlacu (Tue, 05 Oct 2021 22:35:45 GMT):
... when I run `genBCData.py` on the `Mapping Aries Protocols for Testing - Aries Agent Test Scripts.csv` file in the repo, on main, the `backchannel_operations.csv` generated file doesn't work
didexchange passes before genBCData, fails after
where do we have a source csv that actually produces the correct `backchannel_operations.csv` operations data?
sheldon.regular (Tue, 05 Oct 2021 22:36:48 GMT):
Are you adding operations?
sheldon.regular (Tue, 05 Oct 2021 22:37:50 GMT):
maybe add them directly to the csv manually. That should get you going, and we can focus on the spreadsheet and that script after.
filip.burlacu (Tue, 05 Oct 2021 22:57:12 GMT):
yeah, I can sidestep the issue that way
sheldon.regular (Wed, 06 Oct 2021 17:43:27 GMT):
Any feedback from the investigations?
lauravuo-techlab (Thu, 07 Oct 2021 07:31:10 GMT):
Unfortunately not much progress here. I try to squeeze some time for this today. At least with JS, the failure is evident, we have a mismatch with the aries message type prefix: JS-agent messages are starting with `https://didcomm.org`and we don't support that (yet).
sheldon.regular (Thu, 07 Oct 2021 20:14:13 GMT):
Thanks for the update.
filip.burlacu (Fri, 08 Oct 2021 19:13:18 GMT):
https://github.com/hyperledger/aries-agent-test-harness/pull/359 is ready for review
@sheldon.regular I think you haven't had an opportunity to review yet?
sheldon.regular (Fri, 08 Oct 2021 23:24:32 GMT):
I haven't sorry. I'm away until Tuesday.
filip.burlacu (Wed, 13 Oct 2021 17:56:45 GMT):
the vcx PR broke all afgo tests
filip.burlacu (Wed, 13 Oct 2021 17:56:58 GMT):
because it introduces some docker containers that have port conflicts
filip.burlacu (Wed, 13 Oct 2021 17:56:58 GMT):
because it introduces some docker containers that have port conflicts with orb
filip.burlacu (Wed, 13 Oct 2021 17:57:34 GMT):
why do we run the vcx agency in all tests, instead of only starting the service for vcx tests?
filip.burlacu (Wed, 13 Oct 2021 17:57:41 GMT):
the same way we only start orb for afgo tests
sheldon.regular (Wed, 13 Oct 2021 17:58:03 GMT):
I have a fix in that doesn't run the cloud agency unless one of the agents is vcx
sheldon.regular (Wed, 13 Oct 2021 17:58:15 GMT):
Merged an hour ago.
filip.burlacu (Wed, 13 Oct 2021 17:58:24 GMT):
oh I pulled before that
filip.burlacu (Wed, 13 Oct 2021 17:58:26 GMT):
thank you!
sheldon.regular (Wed, 13 Oct 2021 17:58:28 GMT):
Tails server is failing to build now, so I'm investigating that.
filip.burlacu (Wed, 13 Oct 2021 17:59:25 GMT):
tails isn't always necessary either, is it?
filip.burlacu (Wed, 13 Oct 2021 17:59:39 GMT):
though that depends on which tests are running, rather than which agents
sheldon.regular (Wed, 13 Oct 2021 18:00:04 GMT):
No it isn't, only with revocation. But haven't added a check for that in the manage script yet.
swcurran (Wed, 13 Oct 2021 20:07:05 GMT):
Can you add a ticket about that? Sorry about that. We'll need to address that ASAP.
swcurran (Wed, 13 Oct 2021 20:07:32 GMT):
Better fix would be to not have conflicting ports :-)
bruno.hivert (Thu, 14 Oct 2021 13:53:41 GMT):
Hello, I'm part of the devops staff of https://idlab.org, and for various reasons, we are testing a range of Mobile Wallet with AATH
Lastly, we had trouble getting even the simplest test case (@T003-RFC0036) to work, strangely only on some of android-based wallets.
After some rather longish troubleshooting session, I decided to track the problem on the android phone itself using `adb` and friends.
And then I got the answer: it's part of the fallout of this https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Right now, I only had time to debug the Lissi wallet, but due to timing hints, there is some high probability that the problem is similar with Esatus and Trinsic running on Android.
Basically, it's due to the fact the the ngrok infrastructure was build with a wildcard `*.ngrok.io` certificate issued by let's encrypt.
The .net sdk used by the Lissi wallet most certainly still refers to the expired let's encrypt root certificate, and thus refuses to establish an TLS session with the Bob agent.
I wanted to let you know, so nobody waste more time tracking this nasty one in the @Mobile tests.
On another front, this let's encrypt issue also prevents an agent from compiling, and I submitted this bug report https://github.com/hyperledger/aries-agent-test-harness/issues/360
The solution is fairly simple, I was not sure whether I should publish a pull request so I went the issue way
bruno.hivert (Thu, 14 Oct 2021 13:53:41 GMT):
Hello, I'm part of the devops staff of https://idlab.org, and for various reasons, we are testing a range of Mobile Wallet with AATH
Lastly, we had trouble getting even the simplest test case (@T003-RFC0036) to work, strangely only on some of the android-based wallets.
After some rather longish troubleshooting session, I decided to track the problem on the android phone itself using `adb` and friends.
And then I got the answer: it's part of the fallout of this https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
Right now, I only had time to debug the Lissi wallet, but due to timing hints, there is some high probability that the problem is similar with Esatus and Trinsic running on Android.
Basically, it's due to the fact the ngrok infrastructure was build with a wildcard `*.ngrok.io` certificate issued by let's encrypt.
The .net sdk used by the Lissi wallet most certainly still refers to the expired let's encrypt root certificate, and thus refuses to establish an TLS session with the Bob agent.
I wanted to let you know, so nobody waste more time tracking this nasty one in the @Mobile tests.
On another front, this let's encrypt issue also prevents an agent from compiling, and I submitted this bug report https://github.com/hyperledger/aries-agent-test-harness/issues/360
The solution is fairly simple, I was not sure whether I should publish a pull request so I went the issue way
bruno.hivert (Thu, 14 Oct 2021 13:55:34 GMT):
bruno.hivert - Thu Oct 14 2021 09:55:11 GMT-0400 (GMT-04:00).txt
bruno.hivert (Thu, 14 Oct 2021 13:55:34 GMT):
bruno.hivert - Thu Oct 14 2021 09:55:11 GMT-0400 (GMT-04:00).txt
sheldon.regular (Thu, 14 Oct 2021 14:21:12 GMT):
Thanks @bruno.hivert for tracking that issue so deeply. Is there a solution for the android based wallets?
We should find a place to document this issue. Maybe in the Mobile .md.
Please go ahead and issue a PR for 360.
TimoGlastra (Thu, 14 Oct 2021 14:23:44 GMT):
We've been pulling our hairs why Aries Framework JavaScript wasn't working with any Android wallet built on Aries Framework .NET
TimoGlastra (Thu, 14 Oct 2021 14:24:03 GMT):
Thank you for this :)
TimoGlastra (Thu, 14 Oct 2021 14:25:29 GMT):
We've already verified that it doesn't work with Trinsic or Esatus
TimoGlastra (Thu, 14 Oct 2021 14:26:11 GMT):
Have you informed the wallet vendors of the issue? I think they'll appreciate your investigation
bruno.hivert (Thu, 14 Oct 2021 14:38:46 GMT):
You are all very welcome, I'm really happy to contribute.
As for a solution on Android, I have practically no experience developing on Android, but I have some mileage with TLS, so here's my take: I'm not sure how root CA are managed on android, but it should not be so different from other OS: either an application is using the OS CA store, or its own.
On my pixel phone, I can tell you that neither chrome nor Firefox have issues with the let's encrypt certificates, so I suspect that the Android .NET framework is using its own certificate store.
In other words, the wallets should be bundled with a more up-to-date CA store.
I'm planning to contact the Lissi/Esatus/Trinsic dev through their official feedback e-mail addresses listed on Google play, unless someone has a better idea.
TimoGlastra (Thu, 14 Oct 2021 15:21:03 GMT):
I think this is more a problem with Xamarin than Android. I've managed to track down the issue to BoringSSL over here: https://bugs.chromium.org/p/boringssl/issues/detail?id=439. This describes
> Xamarin by default uses the managed Mono classes for SSL connections on Android, and Mono uses BoringSSL for that purpose.
bruno.hivert (Thu, 14 Oct 2021 15:30:03 GMT):
Definitely makes sense
bruno.hivert (Thu, 14 Oct 2021 17:09:47 GMT):
Just FYI, I notified the Lissi wallet team of the problem through `mailto:info@lissi.id`
esune (Thu, 14 Oct 2021 17:12:38 GMT):
Has joined the channel.
lauravuo-techlab (Fri, 15 Oct 2021 05:33:26 GMT):
We merged lately some pull requests regarding the dotnet/JS-agent problems, and it seems now that the test succeed with both when findy is acting as the default agent and dotnet/JS as Bob. Other way around there are still some issues.
sebastian (Fri, 15 Oct 2021 08:20:27 GMT):
@bruno.hivert Thanks! There are two fixes/workarounds at the moment. 1. Update the server certificate to not include the expired root certificate (when using certbot by adding `--preferred-chain "ISRG Root X1"`). 2. Disable the expired root certificate in the trust store of the device (_Settings->Biometrics & security->Other security settings->View security_ certificates and disable *"DST root ca x3"*)
TimoGlastra (Fri, 15 Oct 2021 09:49:37 GMT):
@sebastian I've asked a colleague of me with an Android to try that that, but that setting option doesn't exist. Tested on a OnePlus 5(t?)
Here's her response:
> Hmm that path doesn't match the options on my device. And when I view my systems 'Trusted Credentials' the credential you mentioned isn't there either.
TimoGlastra (Fri, 15 Oct 2021 09:49:57 GMT):
On which device did you try option 2?
sheldon.regular (Fri, 15 Oct 2021 13:59:34 GMT):
Thanks for the update, I will give it a go.
filip.burlacu (Fri, 15 Oct 2021 14:24:14 GMT):
issue made: https://github.com/hyperledger/aries-agent-test-harness/issues/365
bruno.hivert (Fri, 15 Oct 2021 14:55:54 GMT):
Hello Team !
@sebastian thanks:
- For server-side certificates we manage @https://idlab.org, we definitely went the `ISG Root X1` way
- For the client/device side, the Lissi engineering team proposed the same solution, which I tested OK on my pixel 4 running android 11
The setting Was (sorry french-speaking phone, so YMMV):
Sécurité => Avancé => Chiffrement et Authentifiant => Certificats de confiance
Which should roughly translate to:
Security => Advanced => Cyphers and Credentials => Trusted Certificates
Hope it helps
bruno.hivert (Fri, 15 Oct 2021 15:01:01 GMT):
Come to think of it, when you are on android, and assuming that your Setting application has a search bar, you just have to search for `Certifica` and select the relevant trusted certificate entry to find it.
After that, it's a longuish scroll to find the `DST root ca X3`, but at least they are sorted in dictionary order...
bruno.hivert (Fri, 15 Oct 2021 15:01:01 GMT):
Come to think of it, when you are on android, and assuming that your Setting application has a search bar, you just have to search for `Certifica` and select the relevant trusted certificate entry to find it.
After that, it's a longuish scroll to find the `DST root ca X3`, but at least they are sorted in dictionary order.
And If you cannot find this expired certificate, all the best, you should not experience interoperability problems with ngrok.io
pawel.kowalik (Fri, 15 Oct 2021 15:17:01 GMT):
Has joined the channel.
pawel.kowalik (Fri, 15 Oct 2021 15:17:02 GMT):
@sebastian thanks for the hint. Both options indeed work fine.
bruno.hivert (Fri, 15 Oct 2021 15:17:53 GMT):
And since this is a system-wide modifications, this should unblock other wallets and applications as well.
sheldon.regular (Fri, 15 Oct 2021 15:54:53 GMT):
Can I ask what tests you are running for findy and dotnet? I am doing the following,
`./manage run -d findy -b dotnet-master -t @AcceptanceTest -t @AIP10 -t ~@wip -t ~@revocation`
Are you doing a smaller subset of tests than that?
These are my results:
```
Failing scenarios:
features/0037-present-proof.feature:19 Present Proof where the prover does not propose a presentation of the proof and is acknowledged -- @1.1
features/0037-present-proof.feature:20 Present Proof where the prover does not propose a presentation of the proof and is acknowledged -- @1.2
features/0037-present-proof.feature:55 Present Proof of specific types and proof is acknowledged with a Drivers License credential type -- @1.1
features/0037-present-proof.feature:56 Present Proof of specific types and proof is acknowledged with a Drivers License credential type -- @1.2
features/0037-present-proof.feature:74 Present Proof of specific types and proof is acknowledged with a Biological Indicators credential type -- @1.1
features/0037-present-proof.feature:91 Present Proof of specific types and proof is acknowledged with multiple credential types -- @1.1
features/0037-present-proof.feature:109 Present Proof where the prover does not propose a presentation of the proof and is acknowledged -- @1.1
features/0037-present-proof.feature:110 Present Proof where the prover does not propose a presentation of the proof and is acknowledged -- @1.2
features/0037-present-proof.feature:149 Present Proof where the prover has proposed the presentation of proof in response to a presentation request and is acknowledged -- @1.1
features/0037-present-proof.feature:150 Present Proof where the prover has proposed the presentation of proof in response to a presentation request and is acknowledged -- @1.2
features/0037-present-proof.feature:170 Present Proof where the prover has proposed the presentation of proof from a different credential in response to a presentation request and is acknowledged -- @1.1
features/0037-present-proof.feature:171 Present Proof where the prover has proposed the presentation of proof from a different credential in response to a presentation request and is acknowledged -- @1.2
features/0037-present-proof.feature:227 Present Proof where the prover starts with a proposal the presentation of proof and is acknowledged -- @1.1
2 features passed, 1 failed, 5 skipped
6 scenarios passed, 13 failed, 82 skipped
99 steps passed, 13 failed, 808 skipped, 0 undefined
Took 5m6.311s
```
sheldon.regular (Fri, 15 Oct 2021 16:02:42 GMT):
6 scenarios passed so that is indeed a step forward. 👍
swcurran (Fri, 15 Oct 2021 17:00:10 GMT):
@ianco ^^^ more on the issue discussed this morning.
ianco (Fri, 15 Oct 2021 17:06:32 GMT):
@swcurran it sounds like the solution is `Disable the expired root certificate in the trust store of the device`, so I assume we just need to document this somewhere?
ianco (Fri, 15 Oct 2021 17:07:12 GMT):
Also it's an ngrok issue so we should only run into this in development-like environments
TimoGlastra (Fri, 15 Oct 2021 17:18:45 GMT):
As I understand it now, this not just an Ngrok issue, but an issue with Let’s Encrypt
TimoGlastra (Fri, 15 Oct 2021 17:19:08 GMT):
And as ngrok uses LE it’s also a problem with ngrok
TimoGlastra (Fri, 15 Oct 2021 17:19:23 GMT):
We’re also having issues with non-ngrok services
bruno.hivert (Fri, 15 Oct 2021 17:22:00 GMT):
Yes, I concur, this is an issue between any client with the expired certificate `DST root ca X3` in store, attempting to establish a TLS connection with a server providing a Let's Encrypt-issued certificate.
ianco (Fri, 15 Oct 2021 17:23:58 GMT):
But the solution is `Disable the expired root certificate in the trust store of the device` or no? The problem arose because of the ngrok dependency, so do we need to investigate a replacement for ngrok or do we patch the configuration on affected android devices?
bruno.hivert (Fri, 15 Oct 2021 17:27:13 GMT):
I would recommend patching the device.
This is kind of a temporary solution, until an android update removes the expired certificate (it should have been removed from the trust store since sept 30 2021, but android update being what they are...)
TimoGlastra (Fri, 15 Oct 2021 17:32:39 GMT):
It’s weird because wallets built on React Native (bifold, Connect.Me, our wallet) all still work
TimoGlastra (Fri, 15 Oct 2021 17:33:02 GMT):
so they aren’t using the device trust store I guess?
bruno.hivert (Fri, 15 Oct 2021 17:33:26 GMT):
That would be my guess
esune (Fri, 15 Oct 2021 18:03:27 GMT):
Question: did something change in Aries .NET recently? `ngrok` used to work just fine in the past, so unless they changed their certificate issuing/management policies it must be something that changed on the agent framework side (maybe a dependency?) that is causing these issuew now.
esune (Fri, 15 Oct 2021 18:03:27 GMT):
Question: did something change in Aries .NET recently? `ngrok` used to work just fine in the past, so unless they changed their certificate issuing/management policies it must be something that changed on the agent framework side (maybe a dependency?) that is causing these issues now.
TimoGlastra (Fri, 15 Oct 2021 18:05:38 GMT):
It’s because of this certificate expiration: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/
swcurran (Fri, 15 Oct 2021 18:53:50 GMT):
Huge thanks, Bruno, for finding this.
FWIW -- on my phone (Pixel 4), the path is as @bruno.hivert said Settings==>Security => Advanced => Encryption and Credentials => Trusted Certificates
The name of the CA is "Digital Signature Trust Co." and in small text below that `DST Root CA X3`. If you click on it to see the details, it says that it expired Sept. 30, 2021.
Agree that on the docs we add that -- volunteers?
Is it worth adding into the `./manage` script itself and print statement when someone uses the mobile backchannel?
sheldon.regular (Fri, 15 Oct 2021 19:05:07 GMT):
Ok, looking better from a findy to dotnet. I still get some failures. This is the test set I am running with `./manage run -d findy -b dotnet-master -t @AcceptanceTest -t @AIP10 -t ~@wip -t ~@revocation`
Are you running with a different set of tests?
These are the test results?
```
Failing scenarios:
features/0037-present-proof.feature:149 Present Proof where the prover has proposed the presentation of proof in response to a presentation request and is acknowledged -- @1.1
features/0037-present-proof.feature:150 Present Proof where the prover has proposed the presentation of proof in response to a presentation request and is acknowledged -- @1.2
features/0037-present-proof.feature:170 Present Proof where the prover has proposed the presentation of proof from a different credential in response to a presentation request and is acknowledged -- @1.1
features/0037-present-proof.feature:171 Present Proof where the prover has proposed the presentation of proof from a different credential in response to a presentation request and is acknowledged -- @1.2
features/0037-present-proof.feature:227 Present Proof where the prover starts with a proposal the presentation of proof and is acknowledged -- @1.1
2 features passed, 1 failed, 5 skipped
14 scenarios passed, 5 failed, 82 skipped
135 steps passed, 5 failed, 780 skipped, 0 undefined
```
sheldon.regular (Fri, 15 Oct 2021 19:13:16 GMT):
The same set of tests completely pass for findy to javascript. 👍
bruno.hivert (Fri, 15 Oct 2021 20:42:07 GMT):
I'm not sure it's OK,. but here is a suggestion:
https://github.com/hyperledger/aries-agent-test-harness/pull/367
Have a good week-end
sheldon.regular (Fri, 15 Oct 2021 21:04:18 GMT):
Does Findy support Proof Proposals?
sheldon.regular (Fri, 15 Oct 2021 21:39:52 GMT):
Forget the failures above. I removed the tests that do Proof Proposal and now all findy to dotnet are passing. dotnet does not support proof proposals.
pawel.kowalik (Sat, 16 Oct 2021 09:42:19 GMT):
I guess it might be also something on the .net stack that gets confused by the cross-signing trick Let's Encrypt did to maintain compatibility with older Android devices. More on this here https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
pawel.kowalik (Sat, 16 Oct 2021 09:46:15 GMT):
As per this page Android 7.1.1 and above should not have any trouble with the new default chain, but I experience the issue on Android 11 device.
pawel.kowalik (Sat, 16 Oct 2021 09:46:15 GMT):
As per this page https://letsencrypt.org/docs/certificate-compatibility/ Android 7.1.1 and above should not have any trouble with the new default chain, but I experience the issue on Android 11 device.
sebastian (Sat, 16 Oct 2021 16:48:07 GMT):
[ ](https://chat.hyperledger.org/channel/aries-agent-test-harness?msg=N47gZkRBi4kx64kor) It might differ among Android devices, for my Pixel 3 it was under Security -> Encryption&credntials -> Trusted credentials
TimoGlastra (Sun, 17 Oct 2021 15:07:07 GMT):
We eventually found the option by searching for certificates and disabling the `DST Root CA X3` seemed to do the trick :)
lauravuo-techlab (Mon, 18 Oct 2021 09:06:42 GMT):
Ok, thanks for the report!
sheldon.regular (Mon, 18 Oct 2021 21:00:51 GMT):
@filip.burlacu and others if you have a view on this.
I was looking at the format of the Media Type tests. I am wondering what your thoughts are if we move those tests to the DID Exchange feature file and just tagged them with the @RFC0044 tag?
Also, what do you think of this reformat of the tests, it creates one test with a bunch of variations. We use tags in the Examples to make some decisions on how to start the agent with whatever parameters. We do a similar construct in the proof tests to compress the test defs. Some of the words in the test below have been changed just to align more with the RFC text and to remove JSON particulars from the test definition.
```
@T001-RFC0044 @RFC0044 @AIP20 @UsesCustomParameters @AcceptanceTest
Scenario Outline: Perform DID Exchange between two agents that have variants of envelope media profile
Given we have "2" agents
| name | role | DIDComm Profile |
| Acme | requester |
filip.burlacu (Mon, 18 Oct 2021 22:03:24 GMT):
These changes look like good ideas!
I'll add that we'll need two Scenario Outlines still, one for success cases and one for failures
sheldon.regular (Mon, 18 Oct 2021 22:37:13 GMT):
Yes, I have done the Scenario outlines for the exception test as well. Something like this.
```
@T002-RFC0044 @ExceptionTest @RFC0044 @AIP20 @UsesCustomParameters
Scenario Outline: Fail DID Exchange between two agents with mismatching media profiles
Given we have "2" agents
| name | role | DIDComm Profile |
| Acme | requester |
nbAmit (Wed, 20 Oct 2021 04:54:25 GMT):
Has joined the channel.
Kazuya.N (Sat, 30 Oct 2021 07:59:58 GMT):
Has joined the channel.
kukgini (Wed, 03 Nov 2021 08:30:01 GMT):
Has joined the channel.
mirgee (Wed, 03 Nov 2021 11:09:34 GMT):
Hi, there is a PR on AATH which has been waiting for review for several weeks with no response, can somebody please take a look at it? https://github.com/hyperledger/aries-agent-test-harness/pull/364
kukgini (Thu, 04 Nov 2021 08:24:35 GMT):
Hi Here. Should I consider vcx in aries-backchannels directory as deprecated and replaced by aries-vcx?
ianco (Thu, 04 Nov 2021 13:59:08 GMT):
Yes that's correct
kukgini (Fri, 05 Nov 2021 07:58:35 GMT):
I made a PR about it. I hope it would be a tiny help. please take a look at it? https://github.com/hyperledger/aries-agent-test-harness/pull/381
ianco (Sat, 06 Nov 2021 12:20:54 GMT):
Thanks for the PR!
pawel.kowalik (Thu, 11 Nov 2021 16:33:25 GMT):
Has left the channel.
SuneetBendre (Tue, 23 Nov 2021 11:16:02 GMT):
Has joined the channel.
SuneetBendre (Tue, 23 Nov 2021 11:41:50 GMT):
Below test case is failing for my wallet. Can someone help me to understand the expected behavior.
aries-test-harness\features\0183-revocation.feature
_@T001-HIPE0011 @normal @AcceptanceTest @Schema_DriversLicense_Revoc @Indy
Scenario Outline: Credential revoked by Issuer and Holder attempts to prove with a prover that doesn't care if it was revoked_
*Failing Step from above testcase: "Then "Bob" has the proof verified"*
Assertion failing: aries-test-harness\features\steps\0037-present-proof.py [Line 295]
if 'credential_verification_dict' in context:
assert context.credential_verification_dict[context.presentation_thread_id] == "true"
Verification result from Faber agent:
{
"created_at":"2021-11-23T10:18:01.471283Z",
"connection_id":"5d47330f-f086-45b7-bc67-d759cfda464a",
"presentation_request":{},
"presentation":{},
*"verified":"false",*
"trace":false,
"auto_present":false,
"thread_id":"1f074328-934f-478a-adf3-d137fe431090",
*"state":"done",*
"initiator":"self",
"role":"verifier",
"updated_at":"2021-11-23T10:18:27.575974Z",
"presentation_exchange_id":"dfe6fdde-037e-447f-a051-62352c46ee58",
"presentation_request_dict":{}
}
My understanding is, if Credential is revoked then proof verification should fail, Resulting in aries agent should create verification result as:
status: done
verified: false
_
Should Assertion be _'assert context.credential_verification_dict[context.presentation_thread_id] == "false" '?
@sheldon.regular Can you please have a look
GoreTushar (Tue, 23 Nov 2021 11:43:36 GMT):
Has joined the channel.
sairanjit (Tue, 23 Nov 2021 12:35:15 GMT):
Has joined the channel.
sheldon.regular (Tue, 23 Nov 2021 15:04:31 GMT):
That test is correct as I see it. 0441 Revocation best practices states, "The absence of any non-revocation interval applicable to a requested item signifies that the verifier has no interest in its credential's non-revocation status."
So the test isn't sending a non-revocation interval with the proof request, therefore the verifier doesn't care about the revocation status, thus the proof should verify with the revoked cred.
https://github.com/sklump/aries-rfcs/tree/master/concepts/0441-present-proof-best-practices
SuneetBendre (Tue, 23 Nov 2021 17:24:31 GMT):
Thanks @sheldon.regular
Will look into it.
regiseloi (Tue, 23 Nov 2021 17:25:36 GMT):
So the next question is: what caused the verification to return "false" here. Was there a proof of non-revocation included in the presentation sent by the holder (despited Faber not including a non-revocation interval in the presentation request)?
sheldon.regular (Wed, 24 Nov 2021 14:58:45 GMT):
Yes, @regiseloi that is a good question. One that still has to be investigated. What happens for Acapy to not verify the proof? It may very well be that the holder/wallet is sending a proof of non-revocation and Acapy doesn't like that. It shouldn't care at this point if non-revocation is included in the proof IMO. I'll log an issue in AATH for further investigation. If it is an Acapy issue, then we will move the issue to that repo. In the mean time, @SuneetBendre can you check it you proof presentation includes a proof of non-revocation? If it does, can you remove it and see if the test passes?
sheldon.regular (Wed, 24 Nov 2021 15:11:22 GMT):
Issue Logged. https://github.com/hyperledger/aries-agent-test-harness/issues/392
sheldon.regular (Wed, 24 Nov 2021 17:04:12 GMT):
@SuneetBendre what wallet are you testing?
SuneetBendre (Thu, 25 Nov 2021 08:14:25 GMT):
@sheldon.regular / @regiseloi
In Presentation Proof, we are always checking revocation status and attaching 'non_revoked' object in the response.
SuneetBendre (Thu, 25 Nov 2021 08:14:25 GMT):
@sheldon.regular / @regiseloi
In Presentation Proof, we are always checking revocation status of the credential and attaching 'non_revoked' object in the response.
SuneetBendre (Thu, 25 Nov 2021 08:14:25 GMT):
@sheldon.regular / @regiseloi
In Presentation Proof, we are always checking revocation status of the credential and attaching 'non_revoked' object if the credential is revoked.
SuneetBendre (Thu, 25 Nov 2021 08:14:25 GMT):
@sheldon.regular / @regiseloi
In Presentation Proof, we are always checking revocation status of the credential and attaching 'non_revoked' object if the credential is revocable.
SuneetBendre (Thu, 25 Nov 2021 08:18:47 GMT):
@sheldon.regular We are working on DIT wallet (Decentralized Identity trust foundation)
SuneetBendre (Thu, 25 Nov 2021 08:18:47 GMT):
@sheldon.regular We are working on DIT wallet (Digital Identity trust foundation)
SuneetBendre (Thu, 25 Nov 2021 08:19:23 GMT):
https://apps.apple.com/za/app/dit-wallet/id1593180308
SuneetBendre (Thu, 25 Nov 2021 09:23:32 GMT):
Internally its AYANWORKS ARNIMA SDK
https://github.com/ayanworks/ARNIMA-reactnative-sdk
regiseloi (Thu, 25 Nov 2021 14:16:39 GMT):
Thanks for confirming Suneet. That's consistent with what we've seen with a different wallet. I would suggest that you set yourself up as a watcher on the issue that Sheldon is referring to above, and see where that goes before making changes to how your wallet is handling this.
SuneetBendre (Thu, 25 Nov 2021 15:16:15 GMT):
sure @regiseloi
timbl (Tue, 30 Nov 2021 20:38:58 GMT):
Has joined the channel.
darrell.odonnell (Thu, 09 Dec 2021 11:09:16 GMT):
Has joined the channel.
darrell.odonnell (Thu, 09 Dec 2021 11:09:20 GMT):
Folks - I chair the Technology Stack Working Group at the Trust Over IO Foundation. Where can I attend a meeting about Aries Interop and perhaps bring some DIF folks to see what's going on?
swcurran (Thu, 09 Dec 2021 16:19:58 GMT):
Per note on the Aries channel -- glad to set up a specific meeting about this.
darrell.odonnell (Wed, 15 Dec 2021 13:49:25 GMT):
Thanks Stephen - I am catching up on other efforts and hoping to attend the DIF Interop session this evening to see where their can be some sharing (HL, ToIP, and DIF).
swcurran (Sun, 23 Jan 2022 21:12:11 GMT):
Looking at the cancelled daily GitHub jobs that we had again yesterday:
The cancellations were on the JavaScript - Findy and .NET- Findy jobs. The core issue appears to be in the interaction between the JS/.NET issuers and Findy as a holder. The "Issue Credential" tests are all failing where Bob (Findy) is supposed to be acknowledging the credential, getting `AssertionError: resp_status 404 is not 200; "Credential a9dfd83a-69c2-4ea1-a77b-33121c0af4f6 not received"` -- after an 11 minute wait.
When the test run domes complete, all the tests Fail (but at least they complete). When the test run is cancelled the "Issue Credential" tests fail (same) and the cancellation happens during the first "Present Proof" test. I'm guessing the cancelation is at the "Holder has credential" step, when (I suspect) the "Issue" operation fails.
TimoGlastra (Mon, 24 Jan 2022 12:34:48 GMT):
Interesting. Is this something we need to fix in the .NET/AFJ backchannel or in the Findy backchannel? Not sure who is at fault here
TimoGlastra (Mon, 24 Jan 2022 12:34:53 GMT):
Tagging @lauravuo-techlab
sheldon.regular (Mon, 24 Jan 2022 16:43:14 GMT):
Just a side note in case it can help, for JS-Findy these tests started failing on 12/21, but the cancelling of that job didn't start until 14 days ago 1/10.
lauravuo-techlab (Tue, 25 Jan 2022 12:00:40 GMT):
ok, thanks for the info! I will take a look
lauravuo-techlab (Tue, 25 Jan 2022 12:45:25 GMT):
it seems that recent changes in our signature timestamp verification has broken this functionality. I will try to fix it.
lauravuo-techlab (Wed, 26 Jan 2022 09:50:12 GMT):
yup, it did the trick with the js agent - apparently js is not filling the signature timestamp for the connection response and our validation changes did not allow connections with an invalid timestamp (without sending a nack to the other end). I removed the validation altogether and it seems that the js test is now working as before. there are still some issue with the dotnet agent - will continue investigations.
TimoGlastra (Wed, 26 Jan 2022 10:24:32 GMT):
Thanks for looking into this! :)
But it seems like we should fix this in AFJ if the timestamp is invalid.
We do set the signature timestamp for the connection response by prefixing the typestamp to the data that we sign:
```
const dataBuffer = Buffer.concat([timestamp(), JsonEncoder.toBuffer(data)])
```
But maybe there's something wrong with our implementation. Could you point to the code in the findy agent where the timestamp is created and the attachment is signed?
lauravuo-techlab (Wed, 26 Jan 2022 11:40:54 GMT):
I think the relevant timestamp handling code is here: https://github.com/findy-network/findy-agent/blob/51310fd48ec9b1fe50f0d03aa1f144beba91228d/agent/sec/pipe.go#L70
lauravuo-techlab (Wed, 26 Jan 2022 11:52:56 GMT):
what comes to dotnet-case, the issue is related to dotnet returning err 500 to findy-agent, I have already created an GH issue for it: https://github.com/hyperledger/aries-framework-dotnet/issues/207 It seems I have to add logic for this case so that the test is not left pending.
lauravuo-techlab (Wed, 26 Jan 2022 11:52:56 GMT):
what comes to dotnet-case, the issue is related to dotnet returning err 500 to findy-agent, I have already created an GH issue for it: https://github.com/hyperledger/aries-framework-dotnet/issues/212 It seems I have to add logic for this case so that the test is not left pending.
lauravuo-techlab (Wed, 02 Feb 2022 12:11:40 GMT):
apparently the fix for the dotnet problem was not picked to findy-backchannel-release until now. so now the tests should fail "normally" and not leave anything pending.
lauravuo-techlab (Wed, 02 Feb 2022 12:11:57 GMT):
sorry for the trouble
kalyankonda (Thu, 10 Feb 2022 07:14:55 GMT):
Has joined the channel.
rjones (Tue, 22 Mar 2022 19:53:46 GMT):
rjones (Tue, 22 Mar 2022 19:53:46 GMT):
rjones (Tue, 22 Mar 2022 19:53:46 GMT):