rjones (Wed, 17 Jul 2019 14:43:12 GMT):
smithbk

rjones (Wed, 17 Jul 2019 14:43:24 GMT):
Has left the channel.

smithbk (Wed, 17 Jul 2019 15:05:32 GMT):
@andrew.whitehead Andrew, you said `The best way to debug pairwise connections would be to run the agent locally with --debug-connections which enables detailed logging of connection events.`. How do I run your agent locally? Or were you referring to the python reference agent?

andrew.whitehead (Wed, 17 Jul 2019 15:05:32 GMT):
Has joined the channel.

brycecurtis (Wed, 17 Jul 2019 15:17:35 GMT):
Has joined the channel.

vinomaster (Wed, 17 Jul 2019 15:24:51 GMT):
Has joined the channel.

jljordan_bcgov (Wed, 17 Jul 2019 15:38:43 GMT):
Has joined the channel.

swcurran (Wed, 17 Jul 2019 15:55:31 GMT):
Has joined the channel.

andrew.whitehead (Wed, 17 Jul 2019 16:42:35 GMT):
The basic instructions for running it are here: https://github.com/hyperledger/aries-cloudagent-python/blob/master/DevReadMe.md For testing the Indy side (credentials) we find it easier to run in Docker

vinomaster (Wed, 17 Jul 2019 18:36:54 GMT):
@andrew.whitehead For the Access to Audio (A2A) Project what are the minimum messages and tests that need to be interoperable for us to proceed?

andrew.whitehead (Wed, 17 Jul 2019 18:46:28 GMT):
I think the relevant protocols are connections, credentials, and presentation requests. For connections we're basically on HIPE 31. The current credential and presentation request protocols are covered in https://hackmd.io/oWSw18DLTYCmHi_ty_gYvg with support for the new Aries credential exchange RFC underway

vinomaster (Thu, 18 Jul 2019 12:09:45 GMT):
So can we can a bit for clarity here? When we are all ready to test A2A flows we need to be in agreemnet on what the baseline messages are and RFC or HIPE levels. My preference would be that we are using ONLY Aries RFCs. Who is making this project level call for A2A?

vinomaster (Thu, 18 Jul 2019 12:09:45 GMT):
So can we can a bit for clarity here? When we are all ready to test A2A flows we need to be in agreement on what the baseline messages are and RFC or HIPE levels. My preference would be that we are using ONLY Aries RFCs. Who is making this project level call for A2A?

jljordan_bcgov (Thu, 18 Jul 2019 15:55:51 GMT):
@swcurran can you provide the info on the relevant RFC please

swcurran (Thu, 18 Jul 2019 17:52:30 GMT):
@vinomaster - we shouldn't be developing in a vaccuum such that we wait until the end to know where other teams are going. Let us know what you are building to - perhaps post a document, of where you are, keep it updated and let us know as it changes. We'll do the same - I was planning on doing the same in the aries-cloudagent-python repo - I will push that up on my to do list. The first cut of this was published a couple of weeks ago on this slide - https://docs.google.com/presentation/d/1SeGmyt7BIZRw-XDHR2NcmxJSZ2g7-tZPoBaBZ7-Jt8I/edit#slide=id.g5c49965bc4_2_0 Yes, the intention is to support the RFCs for all protocols. They are moving fairly quickly (witness the change the "did-exchange" from "connections"), but at the same time the code changes as they evolve tend not to be that significant. The hardest part is (of course) deciding how to handle deprecation in each particular case. That said, today we support 0.1 versions of the credential exchange protocol. We'll soon have support for 1.0 issueance, and I can add 1.0 presentation as soon as we know someone is going to want to test with it. I would recommend that you select the protocols you are going to support and setup some interop testing that you will do. It would be great if there was a trusted, neutral 3rd party test suite to use, but there isn't really one of those yet (aries-test-suite repo was created yesterday). You can use for now the ACA-Py for that, and if you can publish your stuff, we might use yours in the same way. Andrew's list is correct, though I would add some of the fundamentals - trust ping, basic message. Those haven't changed since the connectathon. Action Menu, which is not an Aries RFC at all, is one that I/we need to get pushing on in the Aries community. I think it may be very useful (necessary?) for user experience.

vinomaster (Fri, 19 Jul 2019 12:57:48 GMT):
@swcurran Our team is marching down a Aries RFC Agent approach. We are not looking at Indy HIPEs. At the same time we are tying to prioritize message support and have (due to promises to your team) attempted to put A2A interop msg testing at the top of the list. Our inquires here are derived from this approach. We are seeking to focus on what is necessary for A2A first such as connections, credentials, and presentation.

vinomaster (Fri, 19 Jul 2019 12:58:20 GMT):
Since there is no place for capturing where everyone is at this juncture, here is what we are doing:

vinomaster (Fri, 19 Jul 2019 13:01:08 GMT):
1. Updating our agency code to work on a baseline set of message/protocol priorities. 2. Standup ACP Test Suite on a Local Docker Env to prep for interop testing. 3. Then we can ask to run against something live such as a A2A interop test plan.

vinomaster (Fri, 19 Jul 2019 13:03:34 GMT):
We are open to discuss the A2A test plan at everyones convenience. If that plan suggests interative testing (as messages become available) we are open to such collaboration.

vinomaster (Fri, 19 Jul 2019 13:04:54 GMT):
As you stated, there is so much change and thing are moving fast, so we need balance our work here with other activities.

vinomaster (Fri, 19 Jul 2019 13:04:54 GMT):
As you stated, there is so much change and things are moving fast, so we need balance our work here with other activities.

swcurran (Fri, 19 Jul 2019 19:21:00 GMT):
Sounds good. Here is our list (my repo now, but it's a PR for the hyperledger repo) - https://github.com/swcurran/aries-cloudagent-python/blob/master/SupportedRFCs.md

swcurran (Fri, 19 Jul 2019 19:22:00 GMT):
Re the reference to the HIPE in our document. That's the Basic Message and I recommend that every agent support it. I'll get it moved into Aries - no one has bothered, but everyone (so far) supports it.

swcurran (Fri, 19 Jul 2019 19:22:00 GMT):
Re the reference to the HIPE in our document. That's the Basic Message protocol and I recommend that every agent support it. I'll get it moved into Aries - no one has bothered, but everyone (so far) supports it.

swcurran (Fri, 19 Jul 2019 20:13:56 GMT):
FYI - turns out Basic Message is an Aries RFC - 95. I've updated our document accordingly.

swcurran (Fri, 19 Jul 2019 20:18:43 GMT):
BTW - in order to support the main ones we need for the A2A scenario (DID Exchange 0023, Issue 0036, Prove 0037), the mobile agent will have to support all of the concept RFCs, and several of the core feature RFCs - 0019, 0035/0092, 0067. The others that ACA-Py supports - 0048 and 0095 are trivial and highly recommended.

swcurran (Fri, 19 Jul 2019 20:18:43 GMT):
BTW - in order to support the main ones we need for the A2A scenario (DID Exchange 0023, Issue 0036, Prove 0037), the mobile agent will have to support all of the concept RFCs, and several of the core feature RFCs - 0019, 0035/0092, 0067. A couple of others that ACA-Py supports - 0048 and 0095 are trivial and highly recommended.

samaganamkarthik (Sat, 20 Jul 2019 09:26:00 GMT):
Has joined the channel.

mero (Tue, 23 Jul 2019 08:08:23 GMT):
Has joined the channel.

codenamedmitri (Thu, 25 Jul 2019 15:33:25 GMT):
Has joined the channel.

rolsonquadras (Thu, 25 Jul 2019 19:41:44 GMT):
Has joined the channel.

carl.diclementi (Wed, 31 Jul 2019 19:11:59 GMT):
Has joined the channel.

esplinr (Thu, 01 Aug 2019 16:23:10 GMT):
Has joined the channel.

guolidong (Fri, 02 Aug 2019 07:58:08 GMT):
Has joined the channel.

joshgraber (Fri, 02 Aug 2019 15:19:49 GMT):
Has joined the channel.

george.aristy (Thu, 08 Aug 2019 13:26:41 GMT):
Has joined the channel.

smithbk (Mon, 12 Aug 2019 13:50:45 GMT):
@swcurran The presentation preview at https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof#presentation-preview appears to only support restricting an attribute by cred_def_id, but not by the other 5 types (schema_id, schema_issuer_did, schema_name, schema_version, and issuer_did) as defined at https://github.com/hyperledger/indy-sdk/blob/57dcdae74164d1c7aa06f2cccecaae121cefac25/libindy/src/api/anoncreds.rs#L885. Do you know if this is intentional? I guess it could make sense that since this is coming from the holder as part of the `Propose Presentation` message and the holder knows the exact credentials and associated cred_def_ids that it has in its wallet, then only cred_def_id is allowed. Is that the reasoning or is this an oversight?

swcurran (Mon, 12 Aug 2019 15:00:01 GMT):
I think that is correct. Interesting point as it is very indy-specific, which seems at odds with what we are trying to do with the messages vs. the payloads.

smithbk (Wed, 14 Aug 2019 11:14:35 GMT):
hmm ... I made changes to the revocation-notification RFC per your comments shortly after you made them but just noticed that Kyle merged w/o these changes, so I submitted again under a new PR https://github.com/hyperledger/aries-rfcs/pull/186

smithbk (Wed, 14 Aug 2019 11:14:35 GMT):
@swcurran hmm ... I made changes to the revocation-notification RFC per your comments shortly after you made them but just noticed that Kyle merged w/o these changes, so I submitted again under a new PR https://github.com/hyperledger/aries-rfcs/pull/186

swcurran (Wed, 14 Aug 2019 14:10:36 GMT):
Thanks - merged the PR.

jonathanreynolds (Tue, 20 Aug 2019 20:51:54 GMT):
Has joined the channel.

kengeo (Fri, 23 Aug 2019 03:55:57 GMT):
Has joined the channel.

circlespainter (Tue, 03 Sep 2019 19:30:09 GMT):
Has joined the channel.

swcurran (Fri, 06 Sep 2019 23:33:38 GMT):
@smithbk - I checked with Andrew on the use of AgentBook for testing. He pointed out that you will have the issue with "did-exchange" vs. "connection" name and that on credential exchange, agentbook is still using the 0.1 versions of the protocols, so for now that is not a good choice. Best for now is to do what you are doing with docker. We'll let you know when we update that and you can use it.

aaronr (Mon, 09 Sep 2019 19:03:13 GMT):
Has joined the channel.

aaronr (Mon, 09 Sep 2019 19:03:14 GMT):
@andrew.whitehead: @smithbk wanted me to ask you...is there a way to point the reference agent to a ledger? Providing a genesis file? So that our agent and the reference agent are looking at the same ledger?

swcurran (Mon, 09 Sep 2019 19:18:47 GMT):
There are three ways, all through startup parameters. To see all the startup parameters on a system with docker you can run `scripts/run_docker start --help` from the repo root. Here are the relevant parameters: ``` --genesis-transactions Specifies the genesis transactions to use to connect to an Hyperledger Indy ledger. The transactions are provided as string of JSON e.g. '{"reqSignature":{},"txn":{"data":{"d... ' --genesis-file Specifies a local file from which to read the genesis transactions. --genesis-url Specifies the url from which to download the genesis transactions. For example, if you are using 'von- network', the URL might be 'http://localhost:9000/genesis'. Genesis transactions URLs are available for the Sovrin test/main networks. ```

aaronr (Wed, 11 Sep 2019 17:02:31 GMT):
@swcurran Do you have any kind of test suite that runs against the aries cloud agent container? What I've found so far looks like pytest unit tests

aaronr (Wed, 11 Sep 2019 18:45:36 GMT):
I also tried to start the agent pointing at a genesis file for a ledger we are running locally in a docker container and it seems to be failing. It reads the file without throwing an error, but it is then logging: `INFO Ledger instance not provided`

yutopyan (Wed, 11 Sep 2019 18:52:27 GMT):
Has joined the channel.

aaronr (Wed, 11 Sep 2019 19:26:59 GMT):
apart from the node_ip and node_port, seems identical to your demo/local-genesis.txt

aaronr (Wed, 11 Sep 2019 20:20:54 GMT):
I found https://github.com/hyperledger/aries-protocol-test-suite. Looks like that is the test suite?

swcurran (Wed, 11 Sep 2019 21:00:54 GMT):
That test suite is minimal, but is the way to go. We don't have it running against ACA-Py, but will be looking at it.

swcurran (Wed, 11 Sep 2019 21:02:23 GMT):
@andrew.whitehead - can comment on the testing we use (primarily against ACA-Py itself? Using demo?).

swcurran (Wed, 11 Sep 2019 21:02:43 GMT):
And on the startup issue - what other info is needed?

aaronr (Thu, 12 Sep 2019 14:05:40 GMT):
@swcurran I'm sorry, is that a question about the startup issue for me or for andrew? :-) Do you need more info from me? Should I open an issue?

swcurran (Thu, 12 Sep 2019 14:47:43 GMT):
It was for Andrew. If you are providing the genesis file at start up and that is not sufficient, what else would be needed?

andrew.whitehead (Thu, 12 Sep 2019 17:29:02 GMT):
I think this can happen if the wallet type is not Indy - the ledger connection requires an Indy wallet, specified with `--wallet-type indy`

andrew.whitehead (Thu, 12 Sep 2019 17:33:31 GMT):
The unit tests can be run with scripts/run_tests or scripts/run_tests_indy (the second is more complete and must pass for a PR to be accepted). We also generally run the alice/faber demo and performance demo before submitting a PR, those are documented here: https://github.com/hyperledger/aries-cloudagent-python/blob/master/demo/README.md

aaronr (Thu, 12 Sep 2019 17:37:10 GMT):
we were looking for tests that run against our agent (or any interoperable agent) and test the messages so that we could determine if our agent is compliant. From what Sam said, those are in https://github.com/hyperledger/aries-protocol-test-suite?

aaronr (Thu, 12 Sep 2019 17:37:41 GMT):
your unit tests just seem to test your internal libraries

andrew.whitehead (Thu, 12 Sep 2019 17:40:58 GMT):
Yes, that's the goal of the test suite

aaronr (Thu, 12 Sep 2019 18:04:02 GMT):
so I added --wallet-type indy to the startup parameters and it looks like it opened the ledger and then closes it after a timeout

aaronr (Thu, 12 Sep 2019 18:04:17 GMT):
so definitely further than we were

aaronr (Thu, 12 Sep 2019 18:05:59 GMT):
this is what we are running: ``` start --inbound-transport http 0.0.0.0 10000 --outbound-transport http --log-level DEBUG --admin 0.0.0.0 10001 --admin-insecure-mode --endpoint http://ref-agent:10000 --auto-accept-invites --auto-accept-requests --auto-respond-messages --auto-respond-credential-proposal --auto-respond-credential-offer --auto-respond-credential-request --auto-respond-presentation-proposal --auto-respond-presentation-request --auto-store-credential --auto-verify-presentation --wallet-type indy --genesis-url http://ledger:8000/sandbox/pool_transactions_genesis ```

andrew.whitehead (Thu, 12 Sep 2019 18:15:31 GMT):
It will reopen the ledger connection as needed

aaronr (Thu, 12 Sep 2019 18:17:17 GMT):
ah, ok, so that is normal. Excellent

smithbk (Mon, 16 Sep 2019 17:10:10 GMT):
@andrew.whitehead With the `--wallet-type indy` option above, it fails in unpack. That was working before, so I removed that option. I changed our agent to use the old "connections" rather than "did-exchange" so I got further, but it is now failing with the following. According to the RFC, the format of the message I'm sending seems correct to me. ```2019-09-16 17:02:59,241 aries_cloudagent.transport.outbound.queue.basic DEBUG Dequeuing message: ('connections_activity', {'connection_id': '49b4cfb9-1778-49b3-a762-196995a91e30', 'activity': [{'id': '4de4c4b7d4fe4707a1a74635fe5a5620', 'meta': None, 'time': '2019-09-16 17:02:59.239113Z', 'type': 'invitation', 'direction': 'sent', 'connection_id': '49b4cfb9-1778-49b3-a762-196995a91e30'}]}) 2019-09-16 17:02:59,259 aries_cloudagent.messaging.serializer DEBUG Expanded message: {'@type': 'did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/request', '@id': '1f6a9e53-9dca-48bf-9c2a-166b1f21bbfa', 'label': 'ibm', 'connection': {'did': 'Mna4eYfJCpnECWaypcZmKL', 'did_doc': {'@context': 'https://w3id.org/did/v1', 'id': 'Mna4eYfJCpnECWaypcZmKL', 'publicKey': [{'id': 'Mna4eYfJCpnECWaypcZmKL#keys-1', 'type': 'Ed25519VerificationKey2018', 'controller': 'Mna4eYfJCpnECWaypcZmKL', 'publicKeyBase58': 'CL5Ss4mgSxvy2CzrW4ayynXf1UAQDnGYqiDk5g2DiE8s'}], 'service': [{'id': 'Mna4eYfJCpnECWaypcZmKL;indy', 'type': 'IndyAgent', 'recipientKeys': ['CL5Ss4mgSxvy2CzrW4ayynXf1UAQDnGYqiDk5g2DiE8s'], 'serviceEndpoint': 'http://localhost:8080/a2a/v1/messages/ibm'}]}}} 2019-09-16 17:02:59,260 aries_cloudagent.messaging.connections.manager WARNING No corresponding DID found for sender verkey: CL5Ss4mgSxvy2CzrW4ayynXf1UAQDnGYqiDk5g2DiE8s 2019-09-16 17:02:59,260 aries_cloudagent.messaging.connections.manager WARNING No corresponding DID found for recipient verkey: 84BKi5vdsitNbRfk8Two2s7s9pLhESnK7sQjuTkHBvbp 2019-09-16 17:02:59,260 aries_cloudagent.messaging.models.base ERROR Message validation error: Traceback (most recent call last): File "/home/indy/aries_cloudagent/messaging/models/base.py", line 127, in deserialize return schema.loads(obj) if isinstance(obj, str) else schema.load(obj) File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/marshmallow/schema.py", line 690, in load data, many=many, partial=partial, unknown=unknown, postprocess=True File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/marshmallow/schema.py", line 852, in _do_load raise exc marshmallow.exceptions.ValidationError: {'connection': {'did': ['Unknown field.'], 'did_doc': ['Unknown field.']}} ```

smithbk (Mon, 16 Sep 2019 17:10:33 GMT):
Any ideas?

troyronda (Mon, 16 Sep 2019 19:52:02 GMT):
Has joined the channel.

smithbk (Mon, 16 Sep 2019 20:43:12 GMT):
@swcurran Hi Stephen, any ideas on the problem above?

swcurran (Mon, 16 Sep 2019 20:43:40 GMT):
@andrew.whitehead is the one we need to answer. I've pinged him.

smithbk (Mon, 16 Sep 2019 20:43:50 GMT):
thanks

andrew.whitehead (Mon, 16 Sep 2019 21:27:23 GMT):
We still follow a slightly earlier version of the RFC that uses "DID" and "DIDDoc" as the keys in the connection object (as does the .NET framework I believe)

smithbk (Tue, 17 Sep 2019 01:03:14 GMT):
@swcurran @andrew.whitehead Do you have a plan/timeline for when you will support the latest version of the RFC?

swcurran (Tue, 17 Sep 2019 02:35:18 GMT):
That is a bit of a sore spot. I'm trying to get rid of that change. @andrew.whitehead and will go over it tomorrow. It's a bit of a pain for us to move - especially for no purpose.

daisuke1983 (Tue, 17 Sep 2019 03:47:28 GMT):
Has joined the channel.

smithbk (Tue, 17 Sep 2019 12:29:51 GMT):
hmm ... our interoperability testing is blocked then until either the RFC is changed or the reference agent is changed to support the RFC

troyronda (Tue, 17 Sep 2019 12:35:27 GMT):
@swcurran @andrew.whitehead from Andrew’s response above, is the issue deeper than just the protocol name?

smithbk (Tue, 17 Sep 2019 12:44:10 GMT):
@troyronda yes, there are two field name differences. Instead of 'did', it is expecting 'DID'; and instead of 'did_doc', it is expecting 'DIDDoc'

swcurran (Tue, 17 Sep 2019 16:17:23 GMT):
Such fun. We're going to have enough real issues without this silly one - a change for with no benefit.

swcurran (Tue, 17 Sep 2019 16:17:31 GMT):
User User_1 added by swcurran.

swcurran (Tue, 17 Sep 2019 16:19:45 GMT):
@tomislav when and how do you plan to update from `connections` to `did-exchange`, or do you want to keep me pushing to not make the change at all? We need `agent-framework-dotnet` updated, along with all instances of it, more or less in sync with the ACA-Py change.

swcurran (Tue, 17 Sep 2019 16:20:02 GMT):
@dbluhm what about static agent?

dbluhm (Tue, 17 Sep 2019 16:20:02 GMT):
Has joined the channel.

swcurran (Tue, 17 Sep 2019 16:20:31 GMT):
@tplooker - what about an MattrGlobal instances?

tplooker (Tue, 17 Sep 2019 16:20:31 GMT):
Has joined the channel.

swcurran (Tue, 17 Sep 2019 16:21:09 GMT):
@sukalpomitra - your work will also be disrupted with this.

sukalpomitra (Tue, 17 Sep 2019 16:21:09 GMT):
Has joined the channel.

burdettadam (Tue, 17 Sep 2019 16:21:42 GMT):
Has joined the channel.

tomislav (Tue, 17 Sep 2019 16:32:33 GMT):
@swcurran Most likely after IIW. We'll probably have a one week period where existing things may be in state of flux until all deployments finish

dbluhm (Tue, 17 Sep 2019 17:30:19 GMT):
The static agent library does not implement protocols and just gives the base for implementing them. On top of that, static agents typically don't engage in a connection (did exchange) protocol as their connection to their full agent is configured statically.

swcurran (Tue, 17 Sep 2019 19:10:34 GMT):
We think we'll give up on this issue. I'll close the issue and we'll convert ACA-Py the week after IIW as well.

swcurran (Tue, 17 Sep 2019 19:11:21 GMT):
Please keep this message in mind when proposing breaking changes in protocols and make sure there is a significant benefit to overcome the change cost.

troyronda (Tue, 17 Sep 2019 19:14:53 GMT):
I'd also like to raise the importance level on the JWE compliance / interop topic.

troyronda (Tue, 17 Sep 2019 19:14:53 GMT):
I'd also like to raise the importance level on the JWE compliance / interop topic(s).

troyronda (Tue, 17 Sep 2019 19:18:23 GMT):
The topic for envelope is here: https://github.com/hyperledger/aries-rfcs/issues/133

swcurran (Tue, 17 Sep 2019 19:25:31 GMT):
That topic is for a select few. How about we announce the need for the discussion on Wednesday, determine who needs to be participate and then that group can meet on the topic, and continue the discussion on the issue? The folks on that issue are AFAIK the key players on the discussion.

troyronda (Tue, 17 Sep 2019 19:27:42 GMT):
@swcurran Sounds good.

swcurran (Tue, 17 Sep 2019 20:24:15 GMT):
BTW - I would suggest that for now, @smithbk, you should switch to `connections` until after IIW so you can continue to test. Your call, of course, but it would seem to be easy enough to do.

swcurran (Tue, 17 Sep 2019 20:24:40 GMT):
@troyronda - not sure if that matters as much for you.

smithbk (Tue, 17 Sep 2019 20:25:48 GMT):
@swcurran I already switched to connections to get to that next failure. I really don't want to switch too much that I'll have to switch back later

swcurran (Tue, 17 Sep 2019 20:26:52 GMT):
It's two element names AFAIK, but that's fine. Up to you.

smithbk (Tue, 17 Sep 2019 20:28:37 GMT):
yeh, i can't be compatible with both the old names and the new ones as the golang framework is using the new ones

faisal00813 (Wed, 18 Sep 2019 12:41:03 GMT):
Has joined the channel.

jadhavajay (Thu, 19 Sep 2019 18:43:31 GMT):
Has joined the channel.

Alexi (Thu, 19 Sep 2019 21:59:52 GMT):
Has joined the channel.

jmandel (Tue, 24 Sep 2019 21:24:36 GMT):
Has joined the channel.

brentzundel (Wed, 25 Sep 2019 18:16:03 GMT):
Has joined the channel.

danielhardman (Wed, 25 Sep 2019 18:59:45 GMT):
Has joined the channel.

danielhardman (Wed, 25 Sep 2019 20:05:05 GMT):
cross-post from #aries-maintainers: All (and especially dbluhm and TelegramSam): I really liked our brief discussion about the test suite just now. It made me feel like we need an RFC to explain community expectations about the test suite. I just started a hackmd doc that I filled with questions (but not a lot of answers). When you see the questions, I think you'll see why I don't think it's the same thing as test suite docs. Maybe we could use this to collaborate on the topic? https://hackmd.io/@dhh1128/SyQ0Y4tvS

danielhardman (Wed, 25 Sep 2019 20:05:05 GMT):
cross-post from #aries-maintainers: All (and especially @dbluhm and @TelegramSam): I really liked our brief discussion about the test suite just now. It made me feel like we need an RFC to explain community expectations about the test suite. I just started a hackmd doc that I filled with questions (but not a lot of answers). When you see the questions, I think you'll see why I don't think it's the same thing as test suite docs. Maybe we could use this to collaborate on the topic? https://hackmd.io/@dhh1128/SyQ0Y4tvS

nage (Wed, 25 Sep 2019 22:58:35 GMT):
Has joined the channel.

jljordan_bcgov (Thu, 26 Sep 2019 01:33:55 GMT):
@swcurran ^^

swcurran (Thu, 26 Sep 2019 04:13:08 GMT):
As I've mentioned to @danielhardman and @dbluhm - BC Gov is looking at implementing a community test suite built around ACA-Py. The test suite would essentially be an ACA-Py controller that controls a stock instance of the ACA-Py agent. The Agent-Under-Test would at minimum provide a config file of information about itself (where it is, how to contact it, what tests to run). It could also use an API to send requests to the Test Suite Controller. The test suite will run locally and we're thinking of running a hosted instance (a la https://agentbook.vonx.io) that developers can use interactively. We have a developer that recently joined the project that is using node-js to build the controller and provide it with a UI for operation and reporting. We think that using node-js for this will make it more accessible for developers wanting to extend the test suite. This is still very early days, but we'll see what the tech spike produces and how to proceed next.

swcurran (Thu, 26 Sep 2019 04:13:08 GMT):
As I've mentioned to @danielhardman and @dbluhm - BC Gov is looking at implementing a community test suite built around ACA-Py. The test suite would essentially be an ACA-Py controller that controls a stock instance of the ACA-Py agent. The Agent-Under-Test would at minimum provide a config file of information about itself (where it is, how to contact it, what tests to run). It could also use an API to send requests to the Test Suite Controller. The test suite will run locally and we're thinking of running a hosted instance (a la https://agentbook.vonx.io) that developers can use interactively. We have a developer that recently joined the project doing a tech spike using node-js to build the controller and provide it with a UI for operation and reporting. We think that using node-js for this will make it more accessible for developers wanting to extend the test suite. This is still very early days, but we'll see what the tech spike produces and how to proceed next.

TelegramSam (Thu, 26 Sep 2019 12:52:56 GMT):
Has joined the channel.

TelegramSam (Thu, 26 Sep 2019 12:55:01 GMT):
@swcurran I know I've been out for a few weeks and may have missed some conversation, but why? We have an active test suite project already. Why is creating a totally separate one a good idea?

george.aristy (Thu, 26 Sep 2019 13:38:11 GMT):
A community test suite cannot be built around a specific implementation that is not steered by the community.

swcurran (Thu, 26 Sep 2019 15:24:12 GMT):
@TelegramSam - it may not be a good idea. It's a tech spike to see if perhaps there is a better way. It may lead to nothing. @george.aristy - I think the implementation we are trying to build on is being steered by the community. It is not being done by a vendor or anyone with an interest other than trying to get Aries technology in use - and more importantly, the ability to easily use verifiable credentials.

RodrigoMedeiros (Tue, 01 Oct 2019 16:23:16 GMT):
Has joined the channel.

mxs1491 (Wed, 02 Oct 2019 19:46:09 GMT):
Has joined the channel.

ajayjadhav (Fri, 04 Oct 2019 12:39:53 GMT):
Has joined the channel.

mwherman2000 (Thu, 10 Oct 2019 18:56:24 GMT):
Has joined the channel.

davidlj_btca (Wed, 16 Oct 2019 11:12:27 GMT):
Has joined the channel.

Audrius (Thu, 24 Oct 2019 10:47:12 GMT):
Has joined the channel.

brian.richter (Thu, 24 Oct 2019 15:44:02 GMT):
Has joined the channel.

josephboyle (Fri, 25 Oct 2019 20:50:36 GMT):
Has joined the channel.

sergey.minaev (Mon, 28 Oct 2019 15:55:28 GMT):
Has joined the channel.

sergey.minaev (Mon, 28 Oct 2019 16:34:57 GMT):
@danielhardman @TelegramSam @tomislav I've raised few PRs against ACA-Py to fix some places in the code where implementation is different from the standards (RFCs) @swcurran and @sklump already aware of the problems as a maintainers of the repo (btw thanks for immediate review!) but I think it's not just a ACA-Py problem and all interested participants of community should be on the same page here

sklump (Mon, 28 Oct 2019 16:34:57 GMT):
Has joined the channel.

sergey.minaev (Mon, 28 Oct 2019 16:38:14 GMT):
Here is an example https://github.com/hyperledger/aries-cloudagent-python/pull/239 in RFCs fields are defined as `did` and `did_doc`, in current master they are `DID` and `DIDDoc`, the PR propose to fix implementation. And there are 2 more minor places with the same problem. Sounds like now is a time to define a rule, how Aries repositories should handle backward-compatibility for such cases

sergey.minaev (Mon, 28 Oct 2019 16:38:14 GMT):
Here is an example https://github.com/hyperledger/aries-cloudagent-python/pull/239 in RFCs fields are defined as `did` and `did_doc`, in current master they are `DID` and `DIDDoc`, the PR propose to fix implementation. And there are 2 more minor places with the similar problem. Sounds like now is a time to define a rule, how Aries repositories should handle backward-compatibility for such cases

danielhardman (Mon, 28 Oct 2019 16:40:39 GMT):
@sergey.minaev : the fields are named `did` and `did_doc` in RFC 0023, but `DID` and `DIDDoc` in the Connection protocol RFC. Which one are you trying to conform with.

sergey.minaev (Mon, 28 Oct 2019 16:41:37 GMT):
@danielhardman https://github.com/hyperledger/aries-rfcs/tree/master/features/0160-connection-protocol#attributes

danielhardman (Mon, 28 Oct 2019 16:42:17 GMT):
That is an error

danielhardman (Mon, 28 Oct 2019 16:42:40 GMT):
RFC 0160 is intended to capture the Connection protocol as implemented in the Connectathon last Feb.

danielhardman (Mon, 28 Oct 2019 16:42:56 GMT):
The decision to change to `did` and `did_doc` wasn't made until several months after February.

danielhardman (Mon, 28 Oct 2019 16:43:05 GMT):
So someone updated this RFC but should not have.

sergey.minaev (Mon, 28 Oct 2019 16:43:53 GMT):
btw indy-hipe uses new names as well... https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol#attributes-1 let me check the history...

danielhardman (Mon, 28 Oct 2019 16:44:48 GMT):
There is already a rule for handling backward compatibility: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/semver.md

danielhardman (Mon, 28 Oct 2019 16:46:06 GMT):
I probably changed it

danielhardman (Mon, 28 Oct 2019 16:46:18 GMT):
Here's what happened.

sergey.minaev (Mon, 28 Oct 2019 16:46:32 GMT):
well, I'm talking not about the rules for semver, but about the situation when we found the implementation is different from the RFC.

sergey.minaev (Mon, 28 Oct 2019 16:47:05 GMT):
so it not changes for the protocol it's fixing a bug in implementation

sergey.minaev (Mon, 28 Oct 2019 16:47:05 GMT):
so it not changes for the protocol, it's fixing a bug in implementation

swcurran (Mon, 28 Oct 2019 16:54:12 GMT):
@andrew.whitehead - this is the discussion I wanted you to start.

danielhardman (Mon, 28 Oct 2019 16:55:03 GMT):
Here's what happened: 1. The HIPE in Feb timeframe used `DID` and `DIDDoc`. That's what everybody impelemented. At the time, there was an explicit agreement that we were going to implement the HIPE in its raw form, even though it had NOT been accepted more formally by the community. 2. After the Connectathon (summer-ish), I pointed out that the use of `DID` and `DIDDoc` was out of harmony with the snake_case convention we'd chosen as a community, and asked for approval to update the HIPE. This approval was given by a number of community voices, with no dissent, so I updated the HIPE. When the update was made, there was still no expectation that this HIPE was frozen. 3. During the migration to Aries, we decided that the existing, unaccepted HIPE was deficient in several ways. We transferred the HIPE by loose equivalence rather than direct copying, and it became the DID Exchange protocol (RFC 0023). 4. Meanwhile, folks at BC Gov had invested a lot of time in demos that showed interop using the old protocol, and began to advocate for making the old HIPE an RFC in its own right. Eventually this effort culminated in us copying HIPE 0031 over as RFC 0160. However, when we copied it over, even though our intent was to represent what BC Gov had implemented, what we ended up copying was the evolved version of the HIPE with the field name change. I think RFC 0160 should revert the field name change so it faithfully represents the state from February's connectathon.

danielhardman (Mon, 28 Oct 2019 16:55:03 GMT):
Here's what happened: 1. The HIPE in Feb timeframe used `DID` and `DIDDoc`. That's what everybody implemented. At the time, there was an explicit agreement that we were going to implement the HIPE in its raw form, even though it had NOT been accepted more formally by the community. 2. After the Connectathon (summer-ish), I pointed out that the use of `DID` and `DIDDoc` was out of harmony with the snake_case convention we'd chosen as a community, and asked for approval to update the HIPE. This approval was given by a number of community voices, with no dissent, so I updated the HIPE. When the update was made, there was still no expectation that this HIPE was frozen. 3. During the migration to Aries, we decided that the existing, unaccepted HIPE was deficient in several ways. We transferred the HIPE by loose equivalence rather than direct copying, and it became the DID Exchange protocol (RFC 0023). 4. Meanwhile, folks at BC Gov had invested a lot of time in demos that showed interop using the old protocol, and began to advocate for making the old HIPE an RFC in its own right. Eventually this effort culminated in us copying HIPE 0031 over as RFC 0160. However, when we copied it over, even though our intent was to represent what BC Gov had implemented, what we ended up copying was the evolved version of the HIPE with the field name change. I think RFC 0160 should revert the field name change so it faithfully represents the state from February's connectathon.

swcurran (Mon, 28 Oct 2019 16:55:08 GMT):
Our recommendation for the connection-protocol and the ~sig decorator is to change the RFC to match the implementations, not the other way around. The third one on the `forward` message is still in the air.

swcurran (Mon, 28 Oct 2019 16:55:37 GMT):
But again, to prevent breakage in the implementations, we probably don't want to change it.

sergey.minaev (Mon, 28 Oct 2019 16:56:26 GMT):
sounds like for connection-protocol it's a problem of RFC, as described by Daniel above, so we should fix it

sergey.minaev (Mon, 28 Oct 2019 16:56:26 GMT):
sounds like for connection-protocol it's a problem of RFC, as described by Daniel above, so we should fix RFC

danielhardman (Mon, 28 Oct 2019 16:58:20 GMT):
@swcurran : I thought ~sig was not being used. What role does it play in your current implementation?

andrew.whitehead (Mon, 28 Oct 2019 16:58:47 GMT):
~sig is a part of the connection protocol

danielhardman (Mon, 28 Oct 2019 16:59:03 GMT):
Yes, I know. But it's an optional part.

danielhardman (Mon, 28 Oct 2019 16:59:26 GMT):
Is anybody actually checking it, or are you including it but it's being ignored.

andrew.whitehead (Mon, 28 Oct 2019 16:59:52 GMT):
We always send it and check it

dbluhm (Mon, 28 Oct 2019 17:00:06 GMT):
Test suite also sends and checks it

sergey.minaev (Mon, 28 Oct 2019 17:00:13 GMT):
and it's fair to expect the check from 3rd party implementation, if it presents

sergey.minaev (Mon, 28 Oct 2019 17:00:13 GMT):
and it's fair to expect the check from 3rd party implementation, if it included

sergey.minaev (Mon, 28 Oct 2019 17:00:13 GMT):
and it's fair to expect the check from 3rd party implementation, if it's included

andrew.whitehead (Mon, 28 Oct 2019 17:01:14 GMT):
For 1.0 hopefully that would just be an attach decorator with a signature

andrew.whitehead (Mon, 28 Oct 2019 17:01:14 GMT):
For 1.0 hopefully that would just be an attach decorator with a signature (meaning for the did-exchange protocol)

sergey.minaev (Mon, 28 Oct 2019 17:02:25 GMT):
For other 2 cases we have defined message family and the divergence in implementation. So in fact this implementation is not compatible with the standard I recognize that we have at least 2 implementation with the same problem. But there is no 1.0.0 stable releases. Why we can't just fix the bug and don't broke the standard...

sergey.minaev (Mon, 28 Oct 2019 17:02:25 GMT):
For other 2 cases we have defined message family and the divergence in implementation. So in fact this implementation are not compatible with the standard I recognize that we have at least 2 implementation with the same problem. But there is no 1.0.0 stable releases. Why we can't just fix the bug and don't broke the standard...

danielhardman (Mon, 28 Oct 2019 17:03:38 GMT):
~sig is a dead end. Can't we just leave it alone as used in the Connection protocol, and then deprecate it if/when the Connection protocol goes away?

danielhardman (Mon, 28 Oct 2019 17:03:47 GMT):
How is it out of harmony with impls?

sergey.minaev (Mon, 28 Oct 2019 17:04:55 GMT):
@dbluhm what format is expected by test suite?

danielhardman (Mon, 28 Oct 2019 17:06:23 GMT):
Sergey, can you give me links to your other PRs so I can go read them to understand what you're proposing?

andrew.whitehead (Mon, 28 Oct 2019 17:07:05 GMT):
The only difference in the signature format is the property name `signer` vs `signers`

sergey.minaev (Mon, 28 Oct 2019 17:07:10 GMT):
https://github.com/hyperledger/aries-cloudagent-python/pull/239 https://github.com/hyperledger/aries-cloudagent-python/pull/240 https://github.com/hyperledger/aries-cloudagent-python/pull/241 I'm proposing nothing, just follow the RFCs...

danielhardman (Mon, 28 Oct 2019 17:08:27 GMT):
We already decided that 239 shouldn't happen; the RFC should be fixed instead. Right?

danielhardman (Mon, 28 Oct 2019 17:10:08 GMT):
240 may or may not be what we want. There was a discussion about this. A long one. Kyle was deeply involved. There was some ambiguity about the RFC's language and Kyle realized it (the RFC) needed to be clarified. I'm not sure about the relative timing of the clarification vs. the impl code, or whether Sergey's update makes the code more or less aligned with what got decided. We should confer with Kyle.

danielhardman (Mon, 28 Oct 2019 17:11:17 GMT):
241 seems fine to me.

danielhardman (Mon, 28 Oct 2019 17:13:02 GMT):
Although, if 241 is changing code to align with an RFC that 100% of impls do differently, AND it's an RFC we're going to abandon anyway, AND the difference between the two is just the letter 's', AND the status of the RFC isn't ACCEPTED, it seems like updating the RFC would be easier.

sergey.minaev (Mon, 28 Oct 2019 17:13:51 GMT):
240 I disagree from abstract situation, I mean the follow: There is Core:Routing:1.0:Forward message and it's already approved. It means that new framework should be able to implement this version of the protocol and doesn't care about the another implementation, only about the RFC and Test Suite

andrew.whitehead (Mon, 28 Oct 2019 17:14:31 GMT):
Aries #234 (signature decorator) only has a string for `signers`, as does the latest version of the HIPE - effectively only one signer is supported. The original version of the HIPE did have a list there

danielhardman (Mon, 28 Oct 2019 17:15:29 GMT):
@andrew.whitehead : do we know whether other impls have used `signer` with a string, as you did?

andrew.whitehead (Mon, 28 Oct 2019 17:15:49 GMT):
The .net framework does

sergey.minaev (Mon, 28 Oct 2019 17:16:08 GMT):
lets fix .net as well

sergey.minaev (Mon, 28 Oct 2019 17:16:21 GMT):
and merge the PRs at the same time

danielhardman (Mon, 28 Oct 2019 17:16:50 GMT):
@sergey.minaev : I don't even want to discuss 240 unless/until Kyle is involved. Like I said, there was a *long* discussion about the topic, and we will just create havoc if we try to argue the issue without referencing the other context.

sergey.minaev (Mon, 28 Oct 2019 17:18:07 GMT):
totally agree on 240 itself. But I'd like to have general rules defined.

andrew.whitehead (Mon, 28 Oct 2019 17:18:26 GMT):
@sergey.minaev FYI it's less about when the PR is merged and more about when versions are released/deployed :)

andrew.whitehead (Mon, 28 Oct 2019 17:19:06 GMT):
We expect our 0.4.0 version to have some breaking changes, so that would be the appropriate time

sergey.minaev (Mon, 28 Oct 2019 17:20:07 GMT):
this is exactly what I would like to have discussion started about: how the maintainer should handle such of PRs

sergey.minaev (Mon, 28 Oct 2019 17:20:35 GMT):
Include to the upcoming release? Merge to master ASAP?

sergey.minaev (Mon, 28 Oct 2019 17:20:35 GMT):
Include to the upcoming release? Merge to master ASAP? more options..

sergey.minaev (Mon, 28 Oct 2019 17:22:06 GMT):
what about the case when we have multiple implementations with the same problem? what should we do in the case when half of the language-specific follow the RFCs, anothers - diverges a bit? Should RFCs be updated if ALL implementations are diverged but 100% similar to each other

andrew.whitehead (Mon, 28 Oct 2019 17:22:13 GMT):
I think we might have a 0.3.5 release before then with some refactoring and performance improvements, but maintaining compatibility. It's too bad github doesn't let you merge PRs to a different branch

sergey.minaev (Mon, 28 Oct 2019 17:23:33 GMT):
doesn't get the point... I think it allows, could you describe the case in DM?

sergey.minaev (Mon, 28 Oct 2019 17:23:33 GMT):
doen't get the point... I think it allows, could you describe the case in DM?

sergey.minaev (Mon, 28 Oct 2019 17:23:33 GMT):
don't get the point... I think it allows, could you describe the case in DM?

andrew.whitehead (Mon, 28 Oct 2019 17:24:15 GMT):
Ah, looks like you can do that by editing the PR

sergey.minaev (Mon, 28 Oct 2019 17:24:27 GMT):
yep

danielhardman (Mon, 28 Oct 2019 17:32:16 GMT):
I think the general rule is that ACCEPTED status of an RFC is an inflection point in where changes should happen. When an RFC is not yet ACCEPTED, implementations are encouraged but with the understanding that lots could change. Changes probably flow mostly from impl into RFC. After an RFC is ACCEPTED, it becomes *roughly* normative for implementations. It is not *totally* normative. Our official description of the ACCEPTED status makes that clear: >An accepted RFC is incubating on a standards track; the community has decided to polish it and is exploring or pursuing implementation. So it is still possible for an impl to produce evidence that the RFC should be changed. But this is swimming upstream, and the default assumption should be that the impl conforms to the RFC, not the other way around. This is because multiple people are now implementing, and the RFC is supposed to clarify the target for convergence. Changing the RFC to accommodate an impl is usually not advised. When an RFC gets ADOPTED status (which none have, yet), then the RFC is totally normative. Now, note some hedge words ("usually", "default assumption", "still possible") I used. I was articulating a general rule, not a hard-and-fast rule. I think in this case there are reasonable grounds for an exception. If the only impls we have are aligned with one another but not the RFC, then we could update the RFC as a somewhat odd but reasonable choice in this case. I'm okay with that, as long as we acknowledge that it's an anomaly.

sergey.minaev (Mon, 28 Oct 2019 17:39:39 GMT):
And trying to map this idea to the cases we can do the follow: 239 - bug in RFC history, should be fixed there, PR to codebase should be closed after that 240 - wait expertise from @kdenhartog 241 - check all existing implementation and make an agreement where we should change the sig format - pause the PR and either fix the RFC if all other implementations are agree, otherwise fix the implementations and keep RFC

kdenhartog (Mon, 28 Oct 2019 17:39:39 GMT):
Has joined the channel.

sergey.minaev (Mon, 28 Oct 2019 17:44:44 GMT):
probably my personal opinion is for Accepted state we should ALWAYS align implementation to RFC until we discover the contradiction between RFCs itself / logical problems of RFCs So if smth wrong named in Accepted state - it should be fixed in impls, if there is a logical problem in the flow - RFC should be updated.

sergey.minaev (Mon, 28 Oct 2019 17:44:44 GMT):
probably my personal opinion is for Accepted state we should ALWAYS align implementation to RFC until we discover the contradiction between RFCs itself / logical problems of RFCs So if smth is wrong named in Accepted state - it should be fixed in impls, if there is a logical problem in the flow - RFC should be updated.

andrew.whitehead (Mon, 28 Oct 2019 17:54:24 GMT):
For the signature decorator the pragmatic option is just to update the RFC, since existing implementations do it differently and there's no change in the functionality

sergey.minaev (Mon, 28 Oct 2019 17:57:06 GMT):
changing the spec to the implementations is always looks easier) ... while you control all the impls and don't care about others)

andrew.whitehead (Mon, 28 Oct 2019 17:58:29 GMT):
There aren't any implementations that do it differently, that I know of (maybe libvcx now)

sergey.minaev (Mon, 28 Oct 2019 17:59:06 GMT):
libvcx is not a problem as it's in progress and under control in public

sergey.minaev (Mon, 28 Oct 2019 18:06:09 GMT):
btw the habit to change RFCs is not so good for growing up the community. For existing teams it's easy to debug and detect such type of problems. But for new members it would be very frustrated to waste hours for debugging and then recognize that documentation is not a rule

andrew.whitehead (Mon, 28 Oct 2019 18:08:49 GMT):
In general I agree, but these entered the accepted state without actually matching existing implementations

sergey.minaev (Mon, 28 Oct 2019 18:09:35 GMT):
in this particular case I think the main problem is missed tests in Test Suite

andrew.whitehead (Mon, 28 Oct 2019 18:09:59 GMT):
Also they predate the test suite

sergey.minaev (Mon, 28 Oct 2019 18:12:37 GMT):
probably it's time to make a rule to follow kind of TDD for major teams, not only inside repos, but against test suite as well

tomislav (Mon, 28 Oct 2019 21:59:25 GMT):
Sorry, I am just getting around to read this. I'd be happy to update aries framework .net codebase. Are the PR's submitted to the aca-py repo the source of truth for these changes?

andrew.whitehead (Mon, 28 Oct 2019 22:17:58 GMT):
239 is probably an RFC change instead; 241 could be an RFC change; 240 is undecided

andrew.whitehead (Mon, 28 Oct 2019 22:17:58 GMT):
239 is probably an RFC change instead; 241 could be an RFC change; 240 is undecided (waiting on Kyle I think)

tomislav (Mon, 28 Oct 2019 22:20:37 GMT):
Great, thanks. I'll keep following this channel/convo for decisions

kdenhartog (Tue, 29 Oct 2019 03:26:23 GMT):
Hey all just getting to read through this. With regards to the forward messaging, I think the most important aspect is consistency. Right now, there's two ways that the same goal can be achieved and neither is required. On one hand, you can base64url encode the returned JSON string from `pack()`. The other option is to provide the JSON object directly which is what pack returns right now. I'm leaning toward using the JSON object and making the change that @sergey.minaev made. It makes parsing the JSON object easier. I think we should also be specifying in the forward message RFC that it MUST be done in this way. Additionally we should be testing this functionality in the test suite. To the point about how we should approach this going forward, I think the use of the test suite will be the guiding light on this. We definitely shouldn't be declaring something accepted until there's functionality in the test suite (as @danielhardman proposed). I'd suggest that in order for an RFC to be of demonstrated status it should also be in the test suite first (It's listed as a SHOULD right now, but may need to become a MUST). Then what ever we decide for what is correct we make sure it's implemented that way in the test suite. This way, when a second person comes around to implement something there's a binary test of whether an implementation is correct or not and keeps every implementation in sync. We've not been good about this in the past, but going forward I would strongly recommend this is what we should be checking for demonstrated and accepted status. It will make life much easier for all implementors.

swcurran (Tue, 29 Oct 2019 03:55:28 GMT):
@kdenhartog - we're not looking for long term answers (I think we all agree on that), we're looking for short term "what are we going to do today" answers. Specifically, what do we do with the three ACA-Py PRs submitted by Sergey, each of which will break functionality between ACA-Py and aries-framework-dotnet based implementations. I think we've agreed that for two of them we'll change the RFC (connection-protocol and ~sig decorator). The question for you is was what to do with the "forward" one?

kdenhartog (Tue, 29 Oct 2019 03:57:17 GMT):
I answered that with the first paragraph. see "I'm leaning toward using the JSON object and making the change that sergey.minaev made. It makes parsing the JSON object easier. I think we should also be specifying in the forward message RFC that it MUST be done in this way. Additionally we should be testing this functionality in the test suite."

sergey.minaev (Tue, 29 Oct 2019 08:52:10 GMT):
> I think we've agreed that for two of them we'll change the RFC I can see consensus only for 239, 241 is still opened

sergey.minaev (Tue, 29 Oct 2019 08:52:10 GMT):
> I think we've agreed that for two of them we'll change the RFC I can see consensus only for 239, 241 is still opened question

sergey.minaev (Tue, 29 Oct 2019 08:59:40 GMT):
> I think we should also be specifying in the forward message RFC that it MUST be done in this way. @kdenhartog we already have this behavior specified in RFCs... I mean that every description of the message family in the RFCs should be interpreted as MUST.. Or you just suggesting to in additional to the structure add one more text line to highlight this moment?

sergey.minaev (Tue, 29 Oct 2019 08:59:40 GMT):
> I think we should also be specifying in the forward message RFC that it MUST be done in this way. @kdenhartog we already have this behavior specified in RFCs... I mean that every description of the message family in the RFCs should be interpreted as MUST.. Or you just suggesting to (in additional to the structure) add one more text line to highlight this moment?

kdenhartog (Tue, 29 Oct 2019 11:13:45 GMT):
Ok I thought about this more based on the responses. I think the difficulty that we encounter with the use of a normative statement here is that it assumes that all messages that will be forwarded will be JSON objects. This isn't possible if I want to pass a message like "Hello World". In which case, I believe the implementation as it stands is correct and we should be modifying the RFC to account for this. In terms of what the RFC could be modified to, this is a first attempt: "The `msg` field contains the data to be forwarded to the identified recipient listed in the `to` field. The value of the `msg` field must contain a string. In the case where a wire message format message is embedded into this field, the message MUST be converted to a string representation of a JSON object." I'm not sure if this is accounting for all aspects of the use cases we want to support. For example, what impact might it have if the message needs to be sent over a URL? Should the string be base64url encoded? This is an example where our fast and loose language is coming back to haunt us.

kdenhartog (Tue, 29 Oct 2019 11:13:45 GMT):
Ok I thought about this more based on the responses. I think the difficulty that we encounter with the use of a normative statement here is that it assumes that all messages that will be forwarded will be JSON objects. This isn't possible if I want to pass a message like "Hello World". In which case, I believe the implementation as it stands is correct and we should be modifying the RFC to account for this. In terms of what the RFC could be modified to, this is a first attempt: "The `msg` field contains the data to be forwarded to the identified recipient listed in the `to` field. The value of the `msg` field must contain a string. In the case where a wire message format message is embedded into this field, the message MUST be converted to a string representation of a JSON object." I'm not sure if this is accounting for all aspects of the use cases we want to support. For example, what impact might it have if the message needs to be sent over a URL? Should the string be base64url encoded? I think it comes down to the question, how crisp do we want the RFC to be versus how much of this do we want to be interpretative and extensible at the tradeoff of potential interoperability concerns. The test suite can only test for normative statements, so we'll need a few to specify the semantics of this message. Also, side note. Should this be moved to features since it's describing the forward message format?

ashcherbakov (Tue, 29 Oct 2019 11:55:39 GMT):
Has joined the channel.

swcurran (Tue, 29 Oct 2019 15:03:48 GMT):
Sorry - my bad on interpreting your answer.

tomislav (Tue, 29 Oct 2019 17:32:30 GMT):
This is slightly different direction, but why not use attachment decorator for the message? "msg~attach". This way, we have the option to specify what the forward message format is: base64, text, link, etc.

tomislav (Tue, 29 Oct 2019 17:32:30 GMT):
This is slightly different direction, but why not use attachment decorator in the forward message? "msg~attach". This way, we have the option to specify what the forward message format is: base64, text, link, etc.

tomislav (Tue, 29 Oct 2019 17:33:24 GMT):
It's more descriptive and in line with how we attach arbitrary data to standard messages.

tomislav (Tue, 29 Oct 2019 17:34:24 GMT):
Code bases will already have attachment decorator implementations, so it'll be easy to reuse and parse

danielhardman (Tue, 29 Oct 2019 19:33:47 GMT):
Good point, @tomislav . This also solves another problem that I've just been waiting to manifest, which is how you can bundle the things you're trying to forward (forward multiple at the same time). I suggest that the right way to approach this idea is to write a new RFC about a routing protocol. This protocol is really no different from any other protocol; it has a message family and state. Maybe even ACKs. The current routing implementation can then be kept as-is, and we can ponder adopting a fancier routing protocol as a community, using the normal RFC process.

danielhardman (Tue, 29 Oct 2019 20:04:24 GMT):
@tomislav and @swcurran : the reason I suggested an RFC is not that I dislike the ideas in the current cross-domain messaging RFC (0094) that Stephen wrote. Rather, I'd like to describe forwarding as a formalized protocol, with Stephen's RFC still providing the conceptual background. Right now it feels to me like we treat fording as a special topic, when it really is just an ordinary protocol implemented by mediators. I have one other reason I'd like to contemplate an update to the forwarding: I'd like to add some additional, optional properties to a forward message that would make it compatible with use in a mix network.

danielhardman (Tue, 29 Oct 2019 20:04:24 GMT):
@tomislav and @swcurran : the reason I suggested an RFC is NOT that I dislike the ideas in the current cross-domain messaging RFC (0094) that Stephen wrote. Rather, I'd like to describe forwarding as a formalized protocol, with Stephen's RFC still providing the conceptual background. Right now it feels to me like we treat forwarding as a special topic, when it really is just an ordinary protocol implemented by mediators. I have one other reason I'd like to contemplate an update to the forwarding: I'd like to add some additional, optional properties to a forward message that would make it compatible with use in a mix network.

tomislav (Tue, 29 Oct 2019 20:05:49 GMT):
I'm OK with a new protocol. It scales well with adding message handler architectures that are common.

tomislav (Tue, 29 Oct 2019 20:10:10 GMT):
We can easily support both to provide transitioning period

kdenhartog (Wed, 30 Oct 2019 07:10:36 GMT):
All good, I knew there was no intended hostility to it. I checked the time and figured it was just sleepiness speaking.

kdenhartog (Wed, 30 Oct 2019 07:13:11 GMT):
I like the direction this is going. +1 to separating out the forward messaging and adding option mix netting features.

andrew.whitehead (Wed, 30 Oct 2019 17:58:31 GMT):
I've added a PR to rename the DID/DIDDoc properties in the connection protocol back to their original values

andrew.whitehead (Wed, 30 Oct 2019 17:58:31 GMT):
I've added a PR to rename the DID/DIDDoc properties in the connection protocol back to their original values @danielhardman

lovesh (Thu, 31 Oct 2019 14:16:16 GMT):
Has joined the channel.

Yano (Thu, 31 Oct 2019 17:27:20 GMT):
Has joined the channel.

cstoecker (Fri, 01 Nov 2019 15:06:20 GMT):
Has joined the channel.

ashlinSajan (Mon, 04 Nov 2019 09:45:25 GMT):
Has joined the channel.

ashlinSajan (Mon, 04 Nov 2019 09:47:07 GMT):
#sergey.minave

ashlinSajan (Mon, 04 Nov 2019 09:47:07 GMT):
@sergey.minaev I was trying to connect the aries code to a seperate node server i created in which i was able to request from node server to the aries admin server by calling functions create invitation via http post in node the invitation was got back but i cannot send anything back to the node from the controller code it is redirected to the aries admin server

ashlinSajan (Mon, 04 Nov 2019 09:47:07 GMT):
@sergey.minaev I was trying to connect the aries code to a seperate node server i created,in which i was able to request from node server to the aries admin server,by calling functions create invitation via http post in node. the invitation was got back but i cannot send anything back to the node from the controller code as it is redirected to the aries admin server.

jljordan_bcgov (Tue, 05 Nov 2019 13:52:30 GMT):
Which Aries implementation are you working with?

AnnaJ (Tue, 05 Nov 2019 15:59:28 GMT):
Has joined the channel.

RameshT (Wed, 06 Nov 2019 11:45:26 GMT):
Has joined the channel.

knagware9 (Tue, 12 Nov 2019 07:35:41 GMT):
Has joined the channel.

dbluhm (Mon, 18 Nov 2019 23:52:46 GMT):
Aries Protocol Test Suite

Identitywoman (Mon, 25 Nov 2019 05:55:19 GMT):
Has joined the channel.

IWontDiscloseMyIdentity (Tue, 26 Nov 2019 04:54:48 GMT):
Has joined the channel.

michaelblack117 (Thu, 05 Dec 2019 23:19:08 GMT):
Has joined the channel.

ianco (Mon, 09 Dec 2019 23:08:33 GMT):
Has joined the channel.

abdfaye (Tue, 10 Dec 2019 16:24:42 GMT):
Has joined the channel.

abdfaye (Tue, 10 Dec 2019 16:24:43 GMT):
Hi, I facing an issue trying to unpack a message I got from Aries-cloudagent-python, on my phone using aries-framework-dotnet. `Failed to un-pack message ---> Hyperledger.Indy.InvalidParameterException: The value passed to parameter 3 is not valid` I thought these 2 was supposed to be interoperable? Or am I using the wrong? Currently using version libindy 1.11.1 on both side

abdfaye (Tue, 10 Dec 2019 16:24:43 GMT):
Hi, I facing an issue trying to unpack a message I got from Aries-cloudagent-python, on my phone using aries-framework-dotnet. `Failed to un-pack message ---> Hyperledger.Indy.InvalidParameterException: The value passed to parameter 3 is not valid` I thought these 2 was supposed to be interoperable? Or am I using the wrong version? Currently using version libindy 1.11.1 on both side

swcurran (Tue, 10 Dec 2019 16:47:43 GMT):
Hi - can you share some more about the issue you are facing. What messages you are sending, the state of the connection, etc. We are trying to get things interoperable, and things are pretty good, but not yet perfect. @tomislav @andrew.whitehead @sklump

abdfaye (Tue, 10 Dec 2019 16:51:23 GMT):
So we are trying to establish a connection between a phone agent (using agent-framework-dotnet) and a cloud agent (using the aries-cloudagent-python)

abdfaye (Tue, 10 Dec 2019 16:52:38 GMT):
The invitation is created on the phone, pasted to the cloud agent that replies with a packed message I can't unpack

tomislav (Tue, 10 Dec 2019 17:00:48 GMT):
@abdfaye How are you creating the invitation on the phone? Does it contain routing/recipient keys?

tomislav (Tue, 10 Dec 2019 17:01:01 GMT):
As well as endpoint url?

tomislav (Tue, 10 Dec 2019 17:03:13 GMT):
Invitation itself isn't packed, where does this error occur?

abdfaye (Tue, 10 Dec 2019 17:05:47 GMT):
`{"label":"AriesWallet","imageUrl":null,"serviceEndpoint":"http://10.112.47.113:5000/","routingKeys":["AzW8ti9UC579qq5H6suegAsSEVQRfKikwrnRsEjskYQb"],"recipientKeys":["Gm7fDtcnftA55B9i5hnUEeeo9UaeYPjAnFmtVi5qQMvE"],"@id":"435b3181-d275-444e-8f4d-80128bed32a0","@type":"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation"}`

abdfaye (Tue, 10 Dec 2019 17:06:26 GMT):
This is an example of invitation created on the phone

abdfaye (Tue, 10 Dec 2019 17:07:27 GMT):
the error occur when I receive a response from the cloud to the phone

abdfaye (Tue, 10 Dec 2019 17:07:27 GMT):
the error occurs when I receive a response from the cloud to the phone

tomislav (Tue, 10 Dec 2019 17:07:38 GMT):
that looks OK. I'm assuming you run some kind of mediator agent on http://10.112.47.113:5000/. Does acapy process this invitation correctly?

tomislav (Tue, 10 Dec 2019 17:08:30 GMT):
So the error is when the connection request message gets processed?

abdfaye (Tue, 10 Dec 2019 17:09:22 GMT):
Yes precisely while unpacking the message

abdfaye (Tue, 10 Dec 2019 17:09:47 GMT):
the message has the wire-message format

tomislav (Tue, 10 Dec 2019 17:11:13 GMT):
Which service are you feeding the wire message to on your mobile side?

abdfaye (Tue, 10 Dec 2019 17:13:34 GMT):
`[Mono] DllImport searching in: 'indy' ('libindy.so'). [Mono] Searching for 'indy_unpack_message'. [Mono] Probing 'indy_unpack_message'. [Mono] Found as 'indy_unpack_message'. Hyperledger.Aries.AriesFrameworkException: Failed to un-pack message ---> Hyperledger.Indy.InvalidParameterException: The value passed to parameter 3 is not valid. at Hyperledger.Indy.Utils.CallbackHelper.CheckResult (System.Int32 result) [0x00009] in <54b0577d0edf42ce9fec83cff58e603c>:0 at Hyperledger.Indy.CryptoApi.Crypto.UnpackMessageAsync (Hyperledger.Indy.WalletApi.Wallet wallet, System.Byte[] message) [0x00035] in <54b0577d0edf42ce9fec83cff58e603c>:0 at Hyperledger.Aries.Utils.CryptoUtils.UnpackAsync (Hyperledger.Indy.WalletApi.Wallet wallet, System.Byte[] message) [0x0000a] in D:\a\1\s\src\Hyperledger.Aries\Utils\CryptoUtils.cs:65 at Hyperledger.Aries.Agents.AgentBase.UnpackAsync (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.PackedMessageContext message) [0x0003e] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:170 --- End of inner exception stack trace --- at Hyperledger.Aries.Agents.AgentBase.UnpackAsync (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.PackedMessageContext message) [0x000b6] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:175 at Hyperledger.Aries.Agents.AgentBase.ProcessMessage (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.MessageContext messageContext) [0x00070] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:124 at Hyperledger.Aries.Agents.AgentBase.ProcessAsync (Hyperledger.Aries.Agents.IAgentContext context, Hyperledger.Aries.Agents.MessageContext messageContext) [0x00071] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:112 `

abdfaye (Tue, 10 Dec 2019 17:13:34 GMT):
```[Mono] DllImport searching in: 'indy' ('libindy.so'). [Mono] Searching for 'indy_unpack_message'. [Mono] Probing 'indy_unpack_message'. [Mono] Found as 'indy_unpack_message'. Hyperledger.Aries.AriesFrameworkException: Failed to un-pack message ---> Hyperledger.Indy.InvalidParameterException: The value passed to parameter 3 is not valid. at Hyperledger.Indy.Utils.CallbackHelper.CheckResult (System.Int32 result) [0x00009] in <54b0577d0edf42ce9fec83cff58e603c>:0 at Hyperledger.Indy.CryptoApi.Crypto.UnpackMessageAsync (Hyperledger.Indy.WalletApi.Wallet wallet, System.Byte[] message) [0x00035] in <54b0577d0edf42ce9fec83cff58e603c>:0 at Hyperledger.Aries.Utils.CryptoUtils.UnpackAsync (Hyperledger.Indy.WalletApi.Wallet wallet, System.Byte[] message) [0x0000a] in D:\a\1\s\src\Hyperledger.Aries\Utils\CryptoUtils.cs:65 at Hyperledger.Aries.Agents.AgentBase.UnpackAsync (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.PackedMessageContext message) [0x0003e] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:170 --- End of inner exception stack trace --- at Hyperledger.Aries.Agents.AgentBase.UnpackAsync (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.PackedMessageContext message) [0x000b6] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:175 at Hyperledger.Aries.Agents.AgentBase.ProcessMessage (Hyperledger.Aries.Agents.IAgentContext agentContext, Hyperledger.Aries.Agents.MessageContext messageContext) [0x00070] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:124 at Hyperledger.Aries.Agents.AgentBase.ProcessAsync (Hyperledger.Aries.Agents.IAgentContext context, Hyperledger.Aries.Agents.MessageContext messageContext) [0x00071] in D:\a\1\s\src\Hyperledger.Aries\Agents\AgentBase.cs:112 ```

abdfaye (Tue, 10 Dec 2019 17:14:45 GMT):
This is the trace

tomislav (Tue, 10 Dec 2019 17:16:16 GMT):
parameter 3 in the unpack message is the jwe wire message

abdfaye (Tue, 10 Dec 2019 17:16:27 GMT):
right

abdfaye (Tue, 10 Dec 2019 17:17:17 GMT):
That's why I am wondering in the message is compatible

abdfaye (Tue, 10 Dec 2019 17:17:17 GMT):
That's why I am wondering if the message is compatible

tomislav (Tue, 10 Dec 2019 17:18:55 GMT):
Yeah, that's not even a question of frameworks compatibility, its just libindy

tomislav (Tue, 10 Dec 2019 17:19:54 GMT):
Are you invoking the agent by calling `ProcessAsync` with `new PackedMessageContext(wireMessage)`?

abdfaye (Tue, 10 Dec 2019 17:20:00 GMT):
I noticed that the aries-cloudagent-python is reimplementing the Crypto

abdfaye (Tue, 10 Dec 2019 17:20:42 GMT):
and not using it from libindy. am I right?

abdfaye (Tue, 10 Dec 2019 17:21:04 GMT):
Yes that's it

tomislav (Tue, 10 Dec 2019 17:21:14 GMT):
I don't know that

tomislav (Tue, 10 Dec 2019 17:21:49 GMT):
Both LISSI and Streetcred mobile apps use Aries framework dotnet and work well with acapy backends

tomislav (Tue, 10 Dec 2019 17:22:15 GMT):
So my assumption is that whatever acapy uses, should work

tomislav (Tue, 10 Dec 2019 17:22:24 GMT):
At least on low level processing like that

swcurran (Tue, 10 Dec 2019 17:24:03 GMT):
Sounds like @andrew.whitehead needs to weigh in when he gets in.

abdfaye (Tue, 10 Dec 2019 17:26:08 GMT):
it's clearly at the libindy level. Which version is used on LISSI and Streetcred?

abdfaye (Tue, 10 Dec 2019 17:27:18 GMT):
I am on android btw

andrew.whitehead (Tue, 10 Dec 2019 17:31:46 GMT):
I'd have to see the value of `wireMessage`. What version of aries-cloudagent is being used? It has a native implementation of pack/unpack but uses the Indy one when you have an indy wallet.

abdfaye (Tue, 10 Dec 2019 17:34:13 GMT):
```{"protected":"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJ4UHFmNXZONXI1RjRXWGVzNzVzZXBYYUxQRmM0c0Nzb1l5cHpIbU5DREQwQVFKaGJGWjFobV90Mzh6MkJpM3pwRzB1TjE2azczN1VWU2ZZRS1OODN4YTVLbjBMWmNLVUlpcnphWEhyX2I1OD0iLCJoZWFkZXIiOnsia2lkIjoiQXpXOHRpOVVDNTc5cXE1SDZzdWVnQXNTRVZRUmZLaWt3cm5Sc0Vqc2tZUWIifX1dfQ==","iv":"8gBoOooXfbCN0got","ciphertext":"GpPJjz_pzvlfIUizxYihttKO6tViR3ebZTPzIQP6ZzUUng-HQTiM3z2ikaMXx83FsH_KLl02DhxB5AyS7Tu_cwoNjgRQAzZ3eBaZK74zwKNJM7_DojZTg2UgDypy5SFM6tkX5S7Ici1mQPkfeAguEwQ5Rzi_0lkRv1Nrt8JCeEjs6yvjPSTGB50IxWL_9JaVEW9wf3C8C93iIGonJOk02bWhSlOCp3EiAvhqyXoLxJ0o2jP4LM7MH6q4-pw3lNpiMtmhQ_voTMsW3ie8MZRAZyyEHQgPxr-lVyyRlAHWg5_gmH3_jr77RLyE3weMRfwPie4Ocz7NL-3s2bhBU8taZPlVYo3ZLCblXAo2X0Y9IIj79-0MNU0fvevkThh01iTy9wr65HtpcdfnYCq8BCZojYMcKXVxGUPK5iIITWN7GVbul5qdz3cEoaujWZqnQTv895gJ3eoul-4-XeV4968y268LMFUpVxgB87ZV8PQIsty4sQTJ-KeNRzd5SRi9a4NsLS1subgdPHwU9AGNcjS1KtYhctMeSMpggCjVbMBRY8kk_WT5lBRym-GLKlDqpajw_NpJ6CdTA3ZJetbB5Rip3X2ZSLcHUKiLaOUyA-KFYceOejAr1_QNs1NQqeWf6UxbsqlgFjlCIHhw-TvNuuahILV0PBA-ra3hXoup7d_VE83d3USVbbSvBiTjGOiCoLMUXUutaT3i7IOgEosnxH-3Q7nrYLxAodkaln3rqbsbP9G9M1A-0DBo8fwFc8gJBOotJiV87UJdIupHzHoM509Wj-v11RsM6GoTkUZP258G_BtecrS468BNrzzQ6tWat03FC6A0tmB4td3qDLak1iAubsd8rVFRcMkH_edOzqtQIdt09STqs3llmYTr7YNyiRtZDpoz4QlYeojhOhsxR9gqi8BJSdE4_nwkPsGP4GHUeWgL9gOmBwDwJ8SH5qFG9KaI94VecQ36_d-BrJd0X1i4anqhZdTQb35hn57WQzz94NOGA5spW3Whk5vLMcJScVXtb_STcU4czArY2GSWLiBaLx4zJ91dHA7Y-sqGobWt0p2OIC9W9X1G_UI-im8EXjHsoGtQU1wXWt8PkG2aNIZxFC2wrSVc2UNAA2g5-3hlhDMS8K5GWIoVr22OGmgfvvUuWQVGi4UqrXSgcgQAtI6k6XGcB_QgQFwx6xRyUNeWCCpQ4Yk8FY3NACAObmRzAUkKSxUa8aZZgmbZHN-9GeXU32AjnXpNLJGwdxXbyTDc_i5eSM1nF97oePeClGve_2nn2DXtZAZdAvRicFEgtFDlbpACU0r0m9QJISNlmKW2jfUSlFxDcXC7WQ8b585Y4ukcS-QkhJC7W_vH0xH3vfT5mtnVZXFRRXKwTIIGVLLlaKRBF6pNGBXuCHpZSwB90gKVlXQxMDEQPnLYfeBCdOAh-y7stwsnQuB4wcidA6VoNAoTZrgyI9Y_C5q6X19_1xdlW5OffAh8xGPaP1DGeCyU1oM3dwkLSryM_XgorS_ctl1TwPVO-9_XJHxG6TbF1jlsvmtmQ3STKgf5PnkiOGIXP53E1BZhgZH23052hJhUBcEzJhTo106w8a1gf_ONH37_H7nlLSy18RkykpmrQyjZF5CCrESeKgEAWA-fXEikvmK02HqJjxLC5VgiTyspUm2ZmpAkYcvv-1vw6lYXj3cCRx0KOskb1w7Ac-F06N5gt0gsQbhJLTQaJO-ohclqHbyBSuTT2JLwUjuUjMKRZsod9WTra3YJhOab8TaScxRfEgJ-QqcaXSDS4ssqywwGdVjpKmKlvCAFoNFvMx4BXdZB72hHursOwVRSrQZUT12fROneOrwh_vKs-fjTyO5IvamA7dKWh_6WurWr1_naynEN75_L-WyTnr9n56oufhH0CdMRgvq7mwG5CTfZ3rvr33e3fc-v-WCt6XW8jtjL0SvqgZ7JbYo4B2n0MsTDQd58egsBP5Ns5_0jRodikGb63yN9UHOyG30G3X4Jsk7vBQ2v4sSGYgGgO45lnYLwmWgSPG4h3RY66Cq475mVszcYeT4mgeY2wTFn3mJKmm3UPNafqR7jth44FR13sAddro7rR2LYfhbeQIDLYq4_yvyPh9BTEUWLEZXYceXZPg3u2AvTwMzhmxWamw4cZ6QKzp7kgBFHvm5X66mbGoEYtXAJGxagqPZQ2vAR-FiocTG9HEpVXxXu3WIaD3wBMSeuZ2mU-KT_P3OmzHsc1Qqe48fSo4YQyyGgo9qLXls1VPUMV4oizGFaw8d_2KKGgwtwB-bV3uwWTW6SiyqiL-IFHH9hpZT8IdkuANK0V8kzO_c0X_DoAcodbhojBrW4MPrZOYqbRfBElqgJVDkY1b_UoCZalXo9CA7wy1VY7PFqjTUc04t_nMLTkBCfP5LjGMEwaCXn9x3XNKEwEwOoERUW5sWXg1nEQyJ5_y55HiyyHNJJtKSZHBHvXJhrKiVuoYvrajV35ZHXfSFAm5IcCiqzvtp_ZucUYekF_P8TUvDXSt7sNSmPeib5V1O04ac-wpC7sLdnRSWUdi4L4NMu2ovntGGumS71at19Hwz2KC55","tag":"dw7Nr5Gx9gnCifJ9bd0pvg=="}```

abdfaye (Tue, 10 Dec 2019 17:34:40 GMT):
This is the wireMessage

abdfaye (Tue, 10 Dec 2019 17:36:11 GMT):
Using the version 0.3.5 of acapy

andrew.whitehead (Tue, 10 Dec 2019 17:40:39 GMT):
I can try parsing it in a bit but it looks fine at first. It's not in some weird string encoding?

abdfaye (Tue, 10 Dec 2019 17:45:48 GMT):
I am getting the message through a IPEndpoint in the phone (not sure it's the best practice) so I get the whole HTTP request with the header I remove to get to the wireMessage. But the string is on utf8

abdfaye (Tue, 10 Dec 2019 17:48:45 GMT):
I also tried to use the byte[] directly but same result

dbluhm (Tue, 10 Dec 2019 17:55:07 GMT):
I recently ran into inconsistencies between the ACA-Py native crypto implementation and the indy packing methods that resulted in a similar issue; might be related? The Indy pack method chokes on unicode encoded strings as it is expecting ascii whereas the in memory wallet handled unicode just fine.

andrew.whitehead (Tue, 10 Dec 2019 17:55:12 GMT):
It might object to leading whitespace too

abdfaye (Tue, 10 Dec 2019 18:30:47 GMT):
yes I guess I was missing a character so I deserialized and a

abdfaye (Tue, 10 Dec 2019 18:30:47 GMT):
yes I guess I was missing a character so I deserialized and reserialized and it unpacks now

abdfaye (Tue, 10 Dec 2019 18:33:04 GMT):
But now getting : ``Faber | 2019-12-10 18:27:20,455 aries_cloudagent.messaging.models.base ERROR Message validation error: Faber | Traceback (most recent call last): Faber | File "/home/administrator/.local/lib/python3.6/site-packages/aries_cloudagent/messaging/models/base.py", line 127, in deserialize Faber | return schema.loads(obj) if isinstance(obj, str) else schema.load(obj) Faber | File "/home/administrator/.local/lib/python3.6/site-packages/marshmallow/schema.py", line 684, in load Faber | data, many=many, partial=partial, unknown=unknown, postprocess=True Faber | File "/home/administrator/.local/lib/python3.6/site-packages/marshmallow/schema.py", line 842, in _do_load Faber | raise exc Faber | marshmallow.exceptions.ValidationError: {'signature': ['Value {input} is not a valid base64url encoding'], 'sig_data': ['Value {input} is not a valid base64url encoding']} Faber | 2019-12-10 18:27:20,457 aries_cloudagent.dispatcher ERROR Message parsing failed: Error deserializing message: Schema validation failed, sending problem report``` ```

abdfaye (Tue, 10 Dec 2019 18:33:04 GMT):
But now getting : ```Faber | 2019-12-10 18:27:20,455 aries_cloudagent.messaging.models.base ERROR Message validation error: Faber | Traceback (most recent call last): Faber | File "/home/administrator/.local/lib/python3.6/site-packages/aries_cloudagent/messaging/models/base.py", line 127, in deserialize Faber | return schema.loads(obj) if isinstance(obj, str) else schema.load(obj) Faber | File "/home/administrator/.local/lib/python3.6/site-packages/marshmallow/schema.py", line 684, in load Faber | data, many=many, partial=partial, unknown=unknown, postprocess=True Faber | File "/home/administrator/.local/lib/python3.6/site-packages/marshmallow/schema.py", line 842, in _do_load Faber | raise exc Faber | marshmallow.exceptions.ValidationError: {'signature': ['Value {input} is not a valid base64url encoding'], 'sig_data': ['Value {input} is not a valid base64url encoding']} Faber | 2019-12-10 18:27:20,457 aries_cloudagent.dispatcher ERROR Message parsing failed: Error deserializing message: Schema validation failed, sending problem report``` ```

tomislav (Wed, 11 Dec 2019 13:03:25 GMT):
Libindy expects ASCII encoded JWE and not UTF8? I thought UTF8 was the standard for binary string representations?

tomislav (Wed, 11 Dec 2019 13:03:25 GMT):
Libindy expects ASCII encoded JWE and not UTF8? I thought UTF8 was the standard for binary string representations in Indy?

sklump (Wed, 11 Dec 2019 13:17:23 GMT):
By the time it gets there I believe it is base64-encoded, so it comes out the same? Vague recollection only.

tomislav (Wed, 11 Dec 2019 13:39:03 GMT):
Yeah, the JWE envelope is most likely not going to have unicode charset, but in case it does, at least Aries framework .net will break, is it treats the binary data as UTF8 encoded, not ascii - which works fine all characters are ascii

sklump (Wed, 11 Dec 2019 13:43:00 GMT):
If there is interest I will hunt down all the ascii encodings and turn them into utf-8 in a PR.

sklump (Wed, 11 Dec 2019 13:43:00 GMT):
If there is interest I will hunt down all the ascii encodings and turn them into utf-8 in a PR. Is this a good thing to do?

tomislav (Wed, 11 Dec 2019 13:44:40 GMT):
Well, I'm looking at the JWE spec now, and it seems that they are ASCII encoded, which means we need to change the implementations, although we're pretty safe since ASCII is subset

tomislav (Wed, 11 Dec 2019 13:45:33 GMT):
The sequence of encoding content according to the spec is `ASCII(BASE64URL(UTF8(JWE Protected Header)))`

dbluhm (Wed, 11 Dec 2019 13:50:29 GMT):
Just to give some more context to my discovery, I was working with the toolbox and ACA-Py with the Indy wallet in use, testing the addition of websocket support in the toolbox. The nodejs websocket.send method encodes strings as UTF8 by default before sending, which resulted in the CommonInvalidParam3 error. Inspecting the library call, the jwe_data byte array had 3 null bytes trailing each ascii character and serde failed to interpret the nulls. Sending an explicitly ASCII encoded buffer fixed that.

dbluhm (Wed, 11 Dec 2019 13:52:11 GMT):
So in my case, at least, the packed message encoding was the issue, not the encoding of the header

sklump (Wed, 11 Dec 2019 13:57:44 GMT):
Yes, that's right: I knew there was a reason

sklump (Wed, 11 Dec 2019 13:57:44 GMT):
Yes, that's right (re: JWE spec, ASCII): I knew there was a reason

tomislav (Wed, 11 Dec 2019 13:59:31 GMT):
Interesting. We are treating all wire messages as UF8 encoded and haven't seen this issue. https://github.com/hyperledger/aries-framework-dotnet/blob/5d30511eb829fe96b5ab331437158e3705ef7cb6/src/Hyperledger.Aries.AspNetCore/AgentMiddleware.cs#L50

tomislav (Wed, 11 Dec 2019 13:59:58 GMT):
And judging by the above comments, it should break just the same

tomislav (Wed, 11 Dec 2019 14:02:48 GMT):
Although ascii encode and utf8 decode should be compatible `utf_decode(ascii_encode("ssi")) = ascii_decode(ascii_encode("ssi")) = "ssi"`

dbluhm (Wed, 11 Dec 2019 14:04:35 GMT):
What I was experiencing may be unique to how messages are handled over websocket in ACA-Py

sklump (Wed, 11 Dec 2019 14:05:48 GMT):
Bits on the wire, as long as we're in the ASCII subdomain, it ought to come out the same: no?

dbluhm (Wed, 11 Dec 2019 14:17:40 GMT):
I'm not terribly familiar with the details of encodings but having just googled it, characters in ASCII should be the same values and the same number of bytes (1) in both ASCII encoding and UTF8 (right?). So the extra null characters might be a result of something I different going on in websocket.send than I thought

dbluhm (Wed, 11 Dec 2019 14:17:40 GMT):
I'm not terribly familiar with the details of encodings but having just googled it, characters in ASCII should be the same values and the same number of bytes (1) in both ASCII encoding and UTF8 (right?). So the extra null characters might be a result of something different going on in websocket.send than I thought

dbluhm (Wed, 11 Dec 2019 14:19:41 GMT):
And perhaps casting to a buffer was what fixed my issue rather than encoding it in ASCII

tomislav (Wed, 11 Dec 2019 16:02:43 GMT):
Yep, characters in ascii are the same size/order in utf-8

abdfaye (Wed, 11 Dec 2019 18:16:56 GMT):
Finally I was able to progress on the the connection process but when I receive the connectionResponseMessage, it seems like the ProcessResponseAsync is not executed correctly

abdfaye (Wed, 11 Dec 2019 18:17:29 GMT):
```{"Alias":{"Name":"Faber Agent","ImageUrl":null},"Endpoint":{"did":null,"verkey":null,"uri":"http://10.112.50.236:8020"},"State":"Connected","Id":"45bc4622-5b1f-46df-8c34-9a87d7db33c7"}```

abdfaye (Wed, 11 Dec 2019 18:19:34 GMT):
This is the connectionRecord at the end of the process. The state is Connected but no response to the Cloud agent

abdfaye (Wed, 11 Dec 2019 18:26:58 GMT):
am I missing something?

peter_somogyvari (Sat, 14 Dec 2019 23:41:12 GMT):
Has joined the channel.

redongjun (Wed, 18 Dec 2019 13:30:18 GMT):
Has joined the channel.

harrywright (Wed, 18 Dec 2019 17:48:23 GMT):
Has joined the channel.

kdenhartog (Thu, 19 Dec 2019 02:16:33 GMT):
This is interesting to see this happening. I've found encoding is the biggest problem. From what I recall too, the ASCII wrapping around the base64URL was only done that way because that's how it was described in JWE. There wasn't much thinking that went into it other than that.

rajeshkalaria (Fri, 10 Jan 2020 04:44:50 GMT):
Has joined the channel.

rileyphughes (Thu, 16 Jan 2020 22:22:42 GMT):
Has joined the channel.

abdfaye (Fri, 17 Jan 2020 10:38:48 GMT):
Hello, working on an A2A scenario between a mobile agent using the aries-framework-dotnet and a cloud agent using aca-py, I figured out that there are some interoperability issues mostly on the proposal message. It seems like the credential preview is required on aca-py while in the aries-rfcs, it should be optional? Are we expecting a change on the rfcs?

sklump (Fri, 17 Jan 2020 11:31:06 GMT):
You're right; it's a bug in aca-py. I will get to it next week.

sklump (Fri, 17 Jan 2020 11:31:06 GMT):
You're right; it's a deficiency in aca-py. I will get to it next week.

EdEykholt (Mon, 20 Jan 2020 03:35:19 GMT):
Has joined the channel.

sklump (Tue, 21 Jan 2020 18:34:50 GMT):
Track https://github.com/hyperledger/aries-cloudagent-python/pull/336 for this fix. If and when it's merged, it's in.

sheldon.regular (Mon, 03 Feb 2020 18:05:55 GMT):
Has joined the channel.

Vritra (Tue, 11 Feb 2020 08:34:26 GMT):
Has joined the channel.

NikhilPrakash (Wed, 12 Feb 2020 00:46:06 GMT):
Has joined the channel.

jayapalreddy (Tue, 03 Mar 2020 02:07:08 GMT):
Has joined the channel.

gokulalex (Fri, 20 Mar 2020 12:06:34 GMT):
Has joined the channel.

mohammadhossein73 (Sun, 29 Mar 2020 05:51:51 GMT):
Has joined the channel.

TimoGlastra (Sat, 18 Apr 2020 12:57:33 GMT):
Has joined the channel.

swcurran (Thu, 23 Apr 2020 18:25:03 GMT):
@jljordan_bcgov @tomislav @mboyd @CHempel @s.weidenbach @esplinr @sergey.minaev @vinomaster @smithbk @tplooker @TelegramSam @george.aristy @troyronda @ajayjadhav @darrell.odonnell A reminder to all those Aries Agent and Agent Framework builders and those with Agent Deployments about this channel. We'd like to encourage the use of this channel to discuss and resolve Aries-wide interop issues, and promote interop testing. Please invite key members of your team to monitor this channel and raise issues about getting interoperable solutions deployed.

s.weidenbach (Thu, 23 Apr 2020 18:25:03 GMT):
Has joined the channel.

darrell.odonnell (Thu, 23 Apr 2020 18:25:03 GMT):
Has joined the channel.

CHempel (Thu, 23 Apr 2020 18:25:03 GMT):
Has joined the channel.

mboyd (Thu, 23 Apr 2020 18:25:03 GMT):
Has joined the channel.

mboyd (Thu, 23 Apr 2020 18:56:21 GMT):
Thanks for the ping, Stephen. Three cheers for interoperability!

KhageshSharma (Fri, 24 Apr 2020 07:27:33 GMT):
Has joined the channel.

swcurran (Fri, 24 Apr 2020 18:43:54 GMT):
Hey folks, we've hit an issue with the handling of URL Shortening implementation in the `vc-authn-oidc` -- comments that it is not a typical approach to that issue. We don't think we will change the approach now in vc-authn-oidc, but we want to be sure that it is clear how to do it on Out of Band. I've raised the issue in the Aries RFC repo and would like to get precise feedback on what should be in the RFC so that we can all get along and don't have this confusion after we get to Out of Band. Please help - https://github.com/hyperledger/aries-rfcs/issues/470

SviatoslavButskyi (Sun, 26 Apr 2020 11:43:36 GMT):
Has joined the channel.

adamjlemmon (Mon, 27 Apr 2020 10:47:33 GMT):
Has joined the channel.

lauravuo-techlab (Tue, 28 Apr 2020 05:24:53 GMT):
Has joined the channel.

wip-abramson (Tue, 28 Apr 2020 07:40:08 GMT):
Has joined the channel.

tplooker (Thu, 07 May 2020 21:33:39 GMT):
Hi r.e the issue raised in email about how the url shortening works within vc-authn-oidc currently, this was originally devised that way for alignment purposes with the DIDComm message url format at that time. We have since evolved from there and I would suggest the new logic should be URL with some form of recognizable scheme such as didcomm where the url format would be as follows `didcomm://?request_uri=https://example.com/request/12345` where processing a URL and finding a request_uri query parameter would signal to the receiving wallet that it needs to perform an HTTP GET on the request_uri, that would need the payload in the body of the HTTP response

swcurran (Thu, 07 May 2020 21:50:28 GMT):
@tplooker questions: 1. What does that do to the proposed URL and URL shortening handling in OutOfBand? https://github.com/hyperledger/aries-rfcs/tree/master/features/0434-outofband#url-shortening . It looks to me like you want to change OOB a fair bit around URL handling. 2. If we go with the `didcomm://...`, should we remove the bits in the OOB RFC about a browser handling the URL to direct a user to a page with information about getting an wallet app? My $0.02CDN is that the latter (redirect user to a page...) is not needed as inviter presenting the wallet would use separate mechanisms to coach the user on getting a wallet. But I know others want that capability.

tplooker (Thu, 07 May 2020 22:04:25 GMT):
@swcurran sorry I have not kept up with the oob protocol, the desire to have a custom URI scheme is so that wallets can register their intent to handle the scheme otherwise how do you deep link from a web page into a wallet?

tplooker (Thu, 07 May 2020 22:04:59 GMT):
The use of `request_uri` is essentially a request by reference as opposed to by value, to overcome the size limitations of QR codes

swcurran (Thu, 07 May 2020 22:16:53 GMT):
Yes - I get the intent. However, the Connections and the DID-Exchange protocols both had text about deliberately using http: so that the browser could resolve the page, display instructions. As I said, I agree with the use of didcomm://, but that means a change to OOB. Just wanted to be sure people were aligned with that. Can you take a scan of OOB and indicate how that would change as a result of that new approach? As well, please look at the URL shortening to see if it is correct as you imagine it.

swcurran (Thu, 07 May 2020 22:18:40 GMT):
Note that we plan on updating the processing in vc-authn-oidc so that we can have a multi-use QR code, where the final proof request URL is not finalized until after the shortened URL is hit and, at minimum, the nonce in the full request is updated.

swcurran (Thu, 07 May 2020 22:18:40 GMT):
Note that we plan on updating the processing in vc-authn-oidc so that we can have a multi-use, shortened-URL QR code, where the final proof request URL is not finalized until after the shortened URL is hit and, at minimum, the nonce in the full request is updated.

tplooker (Thu, 07 May 2020 22:31:08 GMT):
Yeap will review but essentially my suggested approach is a did comm message should be encodable into a url safe form where the underlying message is either included by reference or by value, with a scheme that is recognized by wallets, when the expectation is that this message will be encoded into a QR code, the option of a didcomm:// url using the by reference method e.g `didcomm://?request_uri=https://example.com/request/12345` should be used, where the url should be short to meet size restrictions of QR codes

tplooker (Thu, 07 May 2020 22:31:08 GMT):
Yeap will review but essentially my suggested approach is a did comm message should be encodable into a url safe form where the underlying message is either included by reference or by value, with a scheme that is recognized by wallets. When the expectation is that this message will be encoded into a QR code, the option of a didcomm:// url using the by reference method e.g `didcomm://?request_uri=https://example.com/request/12345` should be used, where the url should be short to meet size restrictions of QR codes

tplooker (Thu, 07 May 2020 22:31:08 GMT):
Yeap will review but essentially my suggested approach is a did comm message should be encodable into a url safe form where the underlying message is either included by reference or by value, with a scheme that is recognized by wallets. When the expectation is that this message will be encoded into a QR code, the option of using the by reference method e.g `didcomm://?request_uri=https://example.com/request/12345` should be used, where the url should be short to meet size restrictions of QR codes

troyronda (Fri, 08 May 2020 13:16:46 GMT):
Out of curiosity, have the above strategies been tested in the stock iOS camera? It would be nice to be able to trigger the agent app externally.

troyronda (Fri, 08 May 2020 13:17:23 GMT):
I haven't been so involved with the discussions, but I can say that failing protocol handlers can be confusing for users. Having a help page can be helpful.

troyronda (Fri, 08 May 2020 13:17:54 GMT):
@swcurran it would be good to have a discussion on how we make a roadmap towards interop between aries-framework-go and aca-py

troyronda (Fri, 08 May 2020 13:19:47 GMT):
we are working on the out-of-band protocol, DID Exchange modifications, JWE envelopes, and are now starting efforts on integrating issue-credential and present-presentation into the sidetree-fabric implementation that we run.

troyronda (Fri, 08 May 2020 13:19:47 GMT):
we are working on the out-of-band protocol, DID Exchange modifications, JWE envelopes, and are now starting efforts on integrating issue-credential and present-presentation with our VCs/VPs and our sidetree-fabric implementation that we run.

troyronda (Fri, 08 May 2020 13:25:16 GMT):
we generically support DID resolution via HTTP bindings (but the framework can also be instantiated with additional Go native/wrapped implementations).

troyronda (Fri, 08 May 2020 13:28:57 GMT):
We support the Verifiable Credential Data Model 1.0 and several JSON-LD signature suites. The new BBS+ signature suite is a TODO.

troyronda (Fri, 08 May 2020 13:34:50 GMT):
Re: DID Registration question on the prior WG call. We started out by having an abstract Create DID interface where we would plug in generic implementations (similar to resolution). However, at the moment, we have been using our framework KMS interface to generate keypairs and then externally (to the framework) perform DID registration.

george.aristy (Fri, 08 May 2020 15:25:25 GMT):
Not sure if Tobias had web-based wallets in mind, but for sure the UX with current technologies around the handling of schemes in the browser is poor.

rileyphughes (Sat, 09 May 2020 02:19:56 GMT):
@tomislav might have thoughts on the URL shortening conversation above ^^

swcurran (Mon, 11 May 2020 21:01:59 GMT):
Hey folks, we're adding a tails server to our stable of products, and have a new version of the "Alice Gets a Phone Demo", where we eliminate the manual bits of doing the demo with the mobile agents. It even generates a QR code on the terminal screen so you don't have to do that manually. In running through the demo, I note that both of the mobile agents tested (Streetcred and esatus) happily send over a proof using a revoked credential, and happily receive and store a new, identical credential. Don't know what your plans are for those features, but I would suggest: 1. Detecting a revoked credential and giving the user the option of not sending back the proof if the credential is revoked. Ideally, flagging the revoked credential in the wallet for display in the UI. 2. On receipt of a new credential of the same type, offering the user the opportunity to delete the existing one, including indicating that the existing one is revoked (if that is known). That latter feature might be a bit tricky, as the use case may call for both to be kept, but I think the user should be made of the scenario, and given the opportunity on the spot to clear it up.

swcurran (Mon, 11 May 2020 21:04:56 GMT):
Note that the issue above is not really an interop issue --- agents are free to do what they want, so that is treading a bit close to proprietary behavior. I definitely should have left out anything about the current behaviour of agents. My apologizes for that.

george.aristy (Fri, 15 May 2020 18:51:36 GMT):
Hey folks - our implementation of the new encryption envelope format (RFC 0334) is coming along nicely, and we are now wondering whether we need to coordinate a migration to the new format, and if so how? Do we need some mechanical tweaks to existing connection protocols (eg. add some stuff to the invitations)?

george.aristy (Fri, 15 May 2020 18:52:26 GMT):
@swcurran @TelegramSam @danielhardman ^^

swcurran (Fri, 15 May 2020 18:53:48 GMT):
How does that relate to the JWM stuff happening in DIF?

george.aristy (Fri, 15 May 2020 18:56:27 GMT):
@swcurran the JWM is at the message-level, right? RFC 0334 is about the encryption envelope, specifically the `ECDH-1PU` alg, which I see is also referenced over at DID/didcomm-messaging.

swcurran (Fri, 15 May 2020 18:58:33 GMT):
@andrew.whitehead ^^^

andrew.whitehead (Fri, 15 May 2020 18:59:59 GMT):
JWM includes the encryption and/or signing envelope, although with no special support for forwarded messages as this one has

george.aristy (Fri, 15 May 2020 19:02:50 GMT):
@andrew.whitehead forwarding is currently defined at the message-level. ie the router unpacks a message to find a `To` field and an inner message that is packed for someone else. Perhaps adding `to` to the JWM would resolve this.

andrew.whitehead (Fri, 15 May 2020 19:03:45 GMT):
I mean this proposal avoids re-encrypting the payload for forwarded messages, while JWM only has simple nesting. It does have standard 'to' and 'from' attributes at the inner envelope level

george.aristy (Fri, 15 May 2020 19:04:07 GMT):
Right.

andrew.whitehead (Fri, 15 May 2020 19:09:05 GMT):
This one also seems to expose the number of 'hops' if the message is intercepted, which might be undesirable

Baha-sk (Fri, 15 May 2020 19:34:36 GMT):
Has joined the channel.

Baha-sk (Fri, 15 May 2020 19:34:36 GMT):
not necessarily @andrew.whitehead as the envelope is intended and encrypted for the next mediator hop in line, only it can decrypt its envelope (unless the encryption key is compro

Baha-sk (Fri, 15 May 2020 19:36:53 GMT):
also the RFC distinguishes encryption keys from verification keys, I believe there is a need to separate them for better security.. at the envelope level, verification keys should not be exchanged, the underlying payload can then extract its verification key

andrew.whitehead (Fri, 15 May 2020 19:43:06 GMT):
You can't tell who the next recipients are but just counting the dots tells you how many mediators there are. I'm not sure what you're referring to with the verification keys, at the moment the recipient kid is their verification key

Baha-sk (Fri, 15 May 2020 19:47:15 GMT):
correct, the envelope should contain only encryption key, not verification key

Baha-sk (Fri, 15 May 2020 19:48:34 GMT):
the contained payload can have the verification key as needed

andrew.whitehead (Fri, 15 May 2020 19:51:03 GMT):
A reference to the encryption key in a DID document, presumably a peer DID document in most cases

Baha-sk (Fri, 15 May 2020 19:53:29 GMT):
yes, we were thinking of using a DID document derived from did:key as in https://w3c-ccg.github.io/did-method-key/#create.. this works well for ed35519/X25519 keys.. not sure how to translate the KeyAgreement into P-256 key though

Baha-sk (Fri, 15 May 2020 19:53:29 GMT):
yes, we were thinking of using a DID document derived from did:key as in https://w3c-ccg.github.io/did-method-key/#create.. this works well for ed25519/X25519 keys.. not sure how to translate the KeyAgreement into P-256 key though

Baha-sk (Fri, 15 May 2020 19:54:37 GMT):
I believe `KeyAgreement` is used for key conversion (specifically for Ed25519 to X25519)

Rishal_ep (Wed, 20 May 2020 07:10:31 GMT):
Has joined the channel.

profae (Wed, 20 May 2020 18:16:06 GMT):
Has joined the channel.

profae (Wed, 20 May 2020 18:16:07 GMT):
Hi I have done some tests between LibVcx, ACA-py and StreetCred I used the Alice.py code in indy-sdk/vcx/wrappers/python3/demo/ as holder connected to an instance of dummy-cloud-agent I haven't changed the Alice.py code much I provided the invitation created by ACA-py and then issued a credential, all correctly then I tried with an invitation from StreetCred and the connection worked but the credential issue failed. In getOffer LibVcx gave a malformed Json error Did I do something wrong or are there other configurations to do? thanks

sergey.minaev (Wed, 20 May 2020 18:18:34 GMT):
@tomislav ^ I can help with gathering logs from libvcx side if needed. Could you suggest the way to obtain more debug info from StreetCred side? Or should we start from libvcx one?

sergey.minaev (Wed, 20 May 2020 18:20:21 GMT):
I can remember some dialog between Artem and Tomislav several months ago. Tomislav, are all changes required on StreetCred side available in public?

tomislav (Wed, 20 May 2020 23:08:49 GMT):
Yes, everything is in the aries dotnet framework repo.

tomislav (Wed, 20 May 2020 23:09:44 GMT):
Is the dummy-cloud-agent configured against Sovrin Staging by default?

profae (Thu, 21 May 2020 04:06:29 GMT):
Yes,

profae (Thu, 21 May 2020 04:06:29 GMT):
Yes, this is error File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/vcx/api/credential.py", line 220, in get_offers Credential.get_offers.cb) vcx.error.VcxError: (, {'backtrace': '', 'cause': 'Cannot deserialize A2A message: invalid type: null, expected a string', 'error': 'Invalid JSON string', 'message': 'Error: Invalid JSON string\n Caused by: Cannot deserialize A2A message: invalid type: null, expected a string\n'})

SuperSeiyan (Wed, 27 May 2020 09:35:40 GMT):
Has joined the channel.

ker13530018 (Wed, 27 May 2020 09:57:36 GMT):
Has joined the channel.

george.aristy (Wed, 27 May 2020 12:49:05 GMT):
@swcurran is someone working on a present-proof v2 ?

antonio.jack (Wed, 27 May 2020 14:03:32 GMT):
Has joined the channel.

swcurran (Wed, 27 May 2020 15:32:32 GMT):
It's on my list. I can take a pass it in the next day or so. The changes are pretty small -- just alignment with how Issue Credential V2 works.

sklump (Wed, 27 May 2020 16:16:34 GMT):
Oh yes, one more thing, what is left to do before we can merge https://github.com/hyperledger/aries-cloudagent-python/pull/514 ?

sklump (Wed, 27 May 2020 16:16:34 GMT):
Oh yes, one more thing, what is left to do before we can merge https://github.com/hyperledger/aries-cloudagent-python/pull/514 (symbolic links for major and minor versions per protocol)?

antonio.jack (Thu, 28 May 2020 03:05:28 GMT):
Is there any update on this? My team's also experiencing the same problem but with libvcx implemented on mobile as a holder.

swcurran (Thu, 28 May 2020 04:08:11 GMT):
First pass of PR done. I'll submit it tomorrow (Thursday).

antonio.jack (Thu, 28 May 2020 09:26:58 GMT):
We just found a root cause of our problem: the `comment` field in credential request payload from cloud controller was missing so mobile (holder) threw the error "Invalid JSON string" Hope this helps, @profae.

profae (Mon, 01 Jun 2020 15:12:50 GMT):
thanks for reply Is mandatory comment field ?

StevenTCramer (Tue, 02 Jun 2020 14:58:21 GMT):
Has joined the channel.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential / Present Proof v2 (hopefully next week). * Attachment format for VC protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection Protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential v2 / Present Proof v2 (hopefully next week). * Attachment format for VC protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection Protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential v2 / Present Proof v2 (hopefully next week). * Attachment format for VC protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential v2 / Present Proof v2 (hopefully next week). * Attachment format for VC protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC 334 and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential v2 / Present Proof v2 (hopefully next week). * Attachment format for VC in v2 credential protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC 334 and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential.

troyronda (Tue, 02 Jun 2020 17:51:12 GMT):
Quick update on aries-framework-go protocol implementation planning: * Wrapping up Out-Of-Band (hopefully end of week). * We will be using OOB invitations rather than DID Exchange invitations. * Issue Credential v2 / Present Proof v2 (hopefully next week). * Attachment format for Verifiable Credentials in the v2 credential protocols (hopefully starting in the next couple weeks). * JWE envelope format (see Aries RFC 334 and DIDComm WG) is our primarily supported envelope format. * Investigating ZKP via BBS+ JSON-LD Signatures. We already support VC data model with non-ZKP JSON-LD signatures. * Wrapping up updates to Introduce (switching to OOB invitations and adding controller API). What we don't have: * Connection protocol. We only implemented DID Exchange. * Indy attachment formats and related ZKP algorithms. Note: our protocol implementation is generic via insertion of middleware for attachment formats. * The original envelope algorithms (e.g., libsodium) are not in the new KMS implementation. * v1.0 of Present Proof and Issue Credential protocols.

kdimak (Tue, 02 Jun 2020 20:00:30 GMT):
Has joined the channel.

esplinr (Fri, 05 Jun 2020 16:45:24 GMT):
User User_2 added by esplinr.

DucaDellaForcoletta (Fri, 12 Jun 2020 22:22:02 GMT):
Has joined the channel.

Vlad (Mon, 29 Jun 2020 14:51:20 GMT):
Has joined the channel.

Vlad (Mon, 29 Jun 2020 14:51:20 GMT):
Hey team. Wanted to see if there is an unwritten consensus to communicate Organization's logo (logo URL) as part of the Connection Invite in the AIP 1.0? Right now in some of the implementations from BCGov, the "label" parameter has been used to communicate the Inviter name or Organization name, but there's nothing specified for the logo. Since the Connect.Me UI implementation normally displays logo from the Inviter, we are trying to figure out what would be the best way to communicate logo of the Inviter. Couple of things that came to our mind: 1. Since the c_i parameter in the only required one by the RFC, one suggestion is to add loge here as the optional one: https:///?logo=https%3A%2F%2Frobohash.org%2F234&c_i= 2. Or label parameter in the invite itself is also JSON and name and logo are parsed from there Any suggestions on this? Has Trinsic been implementing using logo of the Inviter?

george.aristy (Mon, 29 Jun 2020 15:12:50 GMT):
@Vlad I support the addition of a `label~attach` property

george.aristy (Mon, 29 Jun 2020 15:12:50 GMT):
@Vlad I support the addition of an optional `label~attach` property to the `invitation`.

Vlad (Tue, 30 Jun 2020 12:01:20 GMT):
@george.aristy - thanks for the info. Do you have an example of the invite i can see?

george.aristy (Tue, 30 Jun 2020 12:58:42 GMT):
@Vlad be aware that the Connections protocol is considered at its end of life. It will soon be replaced by a combination of the Out-of-Band and did-exchange protocols.

george.aristy (Tue, 30 Jun 2020 12:59:04 GMT):
If I were to add this I'd add it to the oob message.

tomislav (Tue, 30 Jun 2020 13:02:13 GMT):
We use a non-standard property in the invitation `profileUrl` to show this, but there's a better way of doing it. Using invitation property `profile~attach` might be a good way for this.

tomislav (Tue, 30 Jun 2020 13:02:52 GMT):
happy to coordinate an efforts with other implementers to standardize this.

tomislav (Tue, 30 Jun 2020 13:02:52 GMT):
happy to coordinate efforts with other implementers to standardize this.

Vlad (Tue, 30 Jun 2020 13:10:55 GMT):
@george.aristy - Yes, I'm aware of that and we are implementing OOB as we speak. My reasoning is that before OOB and did-exchange becomes more widely implemented, there'll be some time to support the current AIP 1.0 in parallel with OOB so we better have this working the best way we can.

Vlad (Tue, 30 Jun 2020 13:12:51 GMT):
@tomislav - that's great to hear. Yes let's coordinate that for OOB for sure.

swcurran (Tue, 30 Jun 2020 13:15:47 GMT):
I like the idea of `profile~attach`.

TelegramSam (Tue, 30 Jun 2020 14:32:04 GMT):
I'm cautious about `profile~attach`, for two reasons that can be mitigated: 1. It's an obvious correlation issue. Language should be included that indicates so, and cautions against use unless already highly correlated. 2. It edges into work better done with protocols. I'd encourage a useful limit around what is passed.

swcurran (Tue, 30 Jun 2020 14:51:05 GMT):
What would you suggest for 2? A "get logo" protocol that can be called after the connection is established?

TelegramSam (Tue, 30 Jun 2020 14:52:45 GMT):
No, logo and name is fine I think. But contact info etc I think are better elsewhere.

TelegramSam (Tue, 30 Jun 2020 14:53:04 GMT):
Only info used on accept screen.

TelegramSam (Tue, 30 Jun 2020 14:53:31 GMT):
Also should mention potential for fishing.

devin-fisher (Tue, 30 Jun 2020 15:13:47 GMT):
Has joined the channel.

swcurran (Tue, 30 Jun 2020 15:18:46 GMT):
Ah...sorry - yes. Agree contact info -- should not be there.

swcurran (Tue, 30 Jun 2020 15:19:12 GMT):
I was thinking just label and logo/link to logo.

Vlad (Tue, 30 Jun 2020 15:42:14 GMT):
@swcurran - we are not against this proposal (to share logo/link and label) using `profile~attach` for the OOB. It would be good to agree/standardize how those particular attachments are defined so that wallet apps know what to do with them and how to display them. We are currently doing the development for the OOB, so would be interested to see your thinking on this? Also is this channel good way to coordinate this work or you are preferring to do this on the Aries WG call? Also, besides using label and logo/link, have you been thinking to use some parameter for the Username, for example to have something like: "Hi Marco, Acme wants you to share..." As for our immediate need, to have a way to display logo/link using Connections 1.0 on Connect.Me, we have decided to do what @tomislav implemented (use the `profileUrl` in the invitation) so we'll achieve internal interop (Verity - Connect.Me) and Verity - Trinsic

TelegramSam (Wed, 01 Jul 2020 18:41:16 GMT):
Topic will be brought up on the Aries call today.

marvinber (Thu, 02 Jul 2020 08:30:06 GMT):
Has joined the channel.

AnneGoellnitz (Thu, 02 Jul 2020 08:33:07 GMT):
Has joined the channel.

SuperSeiyan (Thu, 02 Jul 2020 15:10:22 GMT):
Hi, I try to test the connection between ACA-py and LibVCX by assigning ACA-py as Faber and LibVCX client as Alice. I did 1. Make connection [pass] 2. Issue credential [pass] 3. Proof presentation [failed] As check the log. I found that a timestamp field is missing and cannot validate by ACA-py Identifier attribute on presentation ``` ... "identifiers": [ { "schema_id": "AzLgamfBZrjD3vXr4gzrQr:2:degree schema:31.20.49", "cred_def_id": "AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default", "rev_reg_id": "AzLgamfBZrjD3vXr4gzrQr:4:AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default:CL_ACCUM:3a662305-c30b-4ffe-af97-3d9796b9697d", "timestamp": null } ] ``` ACA-py step ``` #28 Check if proof is valid Faber | Presentation: state = verified , presentation_exchange_id = 718ac0d5-a5f8-4b4d-aea1-5c94cabb3ae4 Faber | Proof = false Faber | 2020-07-02 14:48:35,342 aries_cloudagent.verifier.indy ERROR Presentation on nonce=1099147109456219140090990 cannot be validated: missing essential components [Missing timestamp in presentation identifier #0 for cred def id AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default] ```

SuperSeiyan (Thu, 02 Jul 2020 15:12:08 GMT):
Hi, I try to test a connection between ACA-py and LibVCX by assigning ACA-py as Faber and LibVCX client as Alice. I did 1. Make connection [pass] 2. Issue credential [pass] 3. Proof presentation [failed] As check the log. I found that a timestamp field is missing and cannot validate by ACA-py Identifier attribute on presentation ``` ... "identifiers": [ { "schema_id": "AzLgamfBZrjD3vXr4gzrQr:2:degree schema:31.20.49", "cred_def_id": "AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default", "rev_reg_id": "AzLgamfBZrjD3vXr4gzrQr:4:AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default:CL_ACCUM:3a662305-c30b-4ffe-af97-3d9796b9697d", "timestamp": null } ] ``` On ACA-py step ``` #28 Check if proof is valid Faber | Presentation: state = verified , presentation_exchange_id = 718ac0d5-a5f8-4b4d-aea1-5c94cabb3ae4 Faber | Proof = false Faber | 2020-07-02 14:48:35,342 aries_cloudagent.verifier.indy ERROR Presentation on nonce=1099147109456219140090990 cannot be validated: missing essential components [Missing timestamp in presentation identifier #0 for cred def id AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default] ``` Thanks for your help.

SuperSeiyan (Thu, 02 Jul 2020 15:12:08 GMT):
Hi, I try to test interoperation between ACA-py and LibVCX by assigning ACA-py as Faber and LibVCX client as Alice. I did 1. Make connection [pass] 2. Issue credential [pass] 3. Proof presentation [failed] As check the log. I found that a timestamp field is missing and cannot validate by ACA-py Identifier attribute on presentation ``` ... "identifiers": [ { "schema_id": "AzLgamfBZrjD3vXr4gzrQr:2:degree schema:31.20.49", "cred_def_id": "AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default", "rev_reg_id": "AzLgamfBZrjD3vXr4gzrQr:4:AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default:CL_ACCUM:3a662305-c30b-4ffe-af97-3d9796b9697d", "timestamp": null } ] ``` On ACA-py step ``` #28 Check if proof is valid Faber | Presentation: state = verified , presentation_exchange_id = 718ac0d5-a5f8-4b4d-aea1-5c94cabb3ae4 Faber | Proof = false Faber | 2020-07-02 14:48:35,342 aries_cloudagent.verifier.indy ERROR Presentation on nonce=1099147109456219140090990 cannot be validated: missing essential components [Missing timestamp in presentation identifier #0 for cred def id AzLgamfBZrjD3vXr4gzrQr:3:CL:117:default] ``` Thanks for your help.

KitHat (Thu, 02 Jul 2020 15:17:35 GMT):
Let me check the RFCs. I do not think that some of your actions are incorrect, but I find your report a bit alarming from the point of interop

KitHat (Thu, 02 Jul 2020 15:32:01 GMT):
I have consulted the Libindy API and Aries RFC. From the Libindy API point of view it is not required, it is optional. Aries do not describe this field, it is on lower level. @swcurran could you please have a look on this issue?

KitHat (Thu, 02 Jul 2020 15:35:37 GMT):
@SuperSeiyan could you please give more info about the credential you are trying to verify with? Does it use revocation registry or not?

KitHat (Thu, 02 Jul 2020 15:35:53 GMT):
If it does not, then this field should be null.

KitHat (Thu, 02 Jul 2020 15:37:04 GMT):
And proof request that was sent would alkso be helpful

KitHat (Thu, 02 Jul 2020 15:37:04 GMT):
And proof request that was sent would also be helpful

andrew.whitehead (Thu, 02 Jul 2020 15:42:12 GMT):
The timestamp is required because the credential definition supports revocation

KitHat (Thu, 02 Jul 2020 15:50:15 GMT):
Oh, I see. rev reg is presented there.

KitHat (Thu, 02 Jul 2020 16:33:27 GMT):
I have examined the LibVCX code, you need to check your Revocation Registry For some reason it is returned without a timestamp

s.weidenbach (Thu, 02 Jul 2020 19:04:37 GMT):
User User_3 added by s.weidenbach.

SuperSeiyan (Fri, 03 Jul 2020 03:39:54 GMT):
@KitHat Here is issued credential. The timestamp is one of credential's attribute ``` EVENT: Controller POST /issue-credential/send-offer request to Agent with data: { "connection_id": "ebbff983-1f82-4d40-a0aa-5ea2cd6efa84", "cred_def_id": "3BdbNx99WLncYbfWiXbst7:3:CL:159:default", "comment": "Offer on cred def id 3BdbNx99WLncYbfWiXbst7:3:CL:159:default", "auto_remove": false, "credential_preview": { "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/issue-credential/1.0/credential-preview", "attributes": [ { "name": "name", "value": "Alice Smith" }, { "name": "date", "value": "2018-05-28" }, { "name": "degree", "value": "Maths" }, { "name": "age", "value": "24" }, { "name": "timestamp", "value": "1593746784" } ] }, "trace": false } # After issues credential Faber | Credential: state = credential_issued, credential_exchange_id = 007a904d-f81f-4f9f-afe0-7c37e134c3fe Faber | Revocation registry ID: 3BdbNx99WLncYbfWiXbst7:4:3BdbNx99WLncYbfWiXbst7:3:CL:159:default:CL_ACCUM:4509e168-669c-4c19-83eb-9fef489c7e05 Faber | Credential revocation ID: 1 ``` The root cause might be currently VCX does not support the revocation feature? Found more that there is PR that did not merge yet https://github.com/hyperledger/indy-sdk/pull/2148. I think if merge the PR the revocation might works PR link: https://github.com/hyperledger/indy-sdk/pull/2148 Sorry to late reply due to my timezone

SuperSeiyan (Fri, 03 Jul 2020 03:39:54 GMT):
@KitHat Here is issued credential. The timestamp is one of credential's attribute ``` EVENT: Controller POST /issue-credential/send-offer request to Agent with data: { "connection_id": "ebbff983-1f82-4d40-a0aa-5ea2cd6efa84", "cred_def_id": "3BdbNx99WLncYbfWiXbst7:3:CL:159:default", "comment": "Offer on cred def id 3BdbNx99WLncYbfWiXbst7:3:CL:159:default", "auto_remove": false, "credential_preview": { "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/issue-credential/1.0/credential-preview", "attributes": [ { "name": "name", "value": "Alice Smith" }, { "name": "date", "value": "2018-05-28" }, { "name": "degree", "value": "Maths" }, { "name": "age", "value": "24" }, { "name": "timestamp", "value": "1593746784" } ] }, "trace": false } # After issues credential Faber | Credential: state = credential_issued, credential_exchange_id = 007a904d-f81f-4f9f-afe0-7c37e134c3fe Faber | Revocation registry ID: 3BdbNx99WLncYbfWiXbst7:4:3BdbNx99WLncYbfWiXbst7:3:CL:159:default:CL_ACCUM:4509e168-669c-4c19-83eb-9fef489c7e05 Faber | Credential revocation ID: 1 ``` The root cause might be currently VCX does not support the revocation feature? Found more that there is PR that did not merge yet. I think if merge the PR the revocation might works PR link: https://github.com/hyperledger/indy-sdk/pull/2148 Sorry to late reply due to my timezone

DucaDellaForcoletta (Mon, 06 Jul 2020 09:16:50 GMT):
Hi all, I'm executing some integration test with aca-py and vcx, Upon basic message sent from vcx to aca-py an error is showed in aca-py log, relatd to the validation of the sent_time. Vcx send 2020-07-06T08:42:59.051353767Z while aca-py expect from 1 to 6 digit related to the milliseconds section.

sklump (Mon, 06 Jul 2020 11:20:37 GMT):
https://github.com/hyperledger/aries-cloudagent-python/pull/586 addresses

tangelo1 (Thu, 09 Jul 2020 23:59:47 GMT):
Has joined the channel.

JelleFm (Fri, 10 Jul 2020 11:42:52 GMT):
Has joined the channel.

swcurran (Fri, 17 Jul 2020 20:35:21 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (July 21, 8AM Pacific), we're going to be talking again about the DID Method underlying Indy -- currently "did:sov" and at the interoperability of the DID Method and Aries across multiple ledgers. What changes are needed to the DID Method, Indy, Indy SDK, Aries and/or Aries Storage layers to enable a prover to seamlessly create a proof that involves credentials rooted in different Indy networks, and for a verifier to verify such a proof? My goal is for this to be a first discussion in a near-term, focused effort on getting code written and deployed to accomplish that use case. My thought is that we (I??) need to organize a "Connectathon" like multi-day virtual conference to explore the possible solutions, decide on a sufficient goal endpoint, agree on what code needs to be implemented and define a plan to get the resources to do the coding. Please join us on Tuesday for this discussion -- https://wiki.hyperledger.org/display/indy/2020-07-21+Indy+Contributors+Call

swcurran (Fri, 17 Jul 2020 20:35:21 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (July 21, 8AM Pacific), we're going to be talking again about the DID Method underlying Indy -- currently "did:sov" -- and at the interoperability of the DID Method and Aries across multiple ledgers. What changes are needed to the DID Method, Indy, Indy SDK, Aries and/or Aries Storage layers to enable a prover to seamlessly create a proof that involves credentials rooted in different Indy networks, and for a verifier to verify such a proof? My goal is for this to be a first discussion in a near-term, focused effort on getting code written and deployed to accomplish that use case. My thought is that we (I??) need to organize a "Connectathon" like multi-day virtual conference to explore the possible solutions, decide on a sufficient goal endpoint, agree on what code needs to be implemented and define a plan to get the resources to do the coding. Please join us on Tuesday for this discussion -- https://wiki.hyperledger.org/display/indy/2020-07-21+Indy+Contributors+Call

SuperSeiyan (Sat, 25 Jul 2020 07:29:54 GMT):
After update with a merged PR #2148, the problem does not fixed by the PR yet. Are there can suggest any solutions on how to add `timestamp` manually on VCX as a holder to send a presentation to ACA-py as a verifier?

SuperSeiyan (Sat, 25 Jul 2020 07:29:54 GMT):
After update with a merged PR #2148, the problem does not fixed by the PR yet. Is there anyone who can suggest any solutions on how to add `timestamp` manually on VCX as a holder to send a presentation to ACA-py as a verifier? Note: I've finish revocation flow on VCX to VCX already Another thing that I found is there is not aries-RFC that describe about revocation implementation because ACA-py and VCX develop in different way.

zickau (Mon, 27 Jul 2020 14:33:06 GMT):
Has joined the channel.

esune (Tue, 04 Aug 2020 17:19:49 GMT):
Has joined the channel.

esune (Tue, 04 Aug 2020 18:37:56 GMT):
Hello everyone, I've been testing generating proof-requests using [vc-authn-oidc](https://github.com/bcgov/vc-authn-oidc) with several mobile wallet apps and I have been encountering the following issue with all of them so far: when responding to a proof-request that contains a `non-revoked` interval (the use-case here is someone trying to authenticate to a service using a VC that has to be valid right now), the mobile wallets only propose as candidates to satisfy the proof credentials for which the `cred_def` supports revocation, while also credentials that do NOT support revocation, but satisfy all the attribute/predicate restrictions should be selectable/presentable. Please see [here](https://hackmd.io/lv6ccW87QmqWnY1otQOAmg?view) for further details. I wanted to bring this up since this will be a very common use-case for many flows using VCs for the purpose of authentication.

esune (Tue, 04 Aug 2020 18:43:58 GMT):
As long as testing goes, aca-py seems to be pulling all the credentials from the wallet correctly - revocable and non-revocable

esune (Tue, 04 Aug 2020 20:00:33 GMT):
Is [this RFC](https://github.com/hyperledger/aries-rfcs/tree/8033be264c2cfa7e7a2a79758a5c49268a92e72f/features/0160-connection-protocol#invitation-processing) for invitations/deeplinking still actual? I noticed that deeplinks in the form `didcomm://launch?d_m=ey...` have stopped working (no mobile wallets pick up the syntax), while `didcomm://invite?c_i=ey...` still works. They both used to work until not very long ago, an I remember we changed the former to use `d_m` rather than `c_i`. Not sure whether this has to do wit the query parameter or the `invite/launch` part, as I said both used to work just fine so this appears to be a relatively recent change.

esune (Tue, 04 Aug 2020 20:00:53 GMT):
Tested behaviour on Android and iOS in both eSatus/Lissi/Trinsic

ianco (Thu, 06 Aug 2020 14:26:16 GMT):
User User_4 added by ianco.

ianco (Thu, 06 Aug 2020 14:26:16 GMT):
User User_5 added by ianco.

sebastian (Mon, 07 Sep 2020 07:36:26 GMT):
Has joined the channel.

simnic (Wed, 23 Sep 2020 11:48:06 GMT):
Has joined the channel.

aaronr (Wed, 14 Oct 2020 02:16:11 GMT):
Is there a way to pass implementation-specific information in a Aries message and be reasonably certain it won't break any implementation that doesn't know about it? For example, to supplement information in a `"https://didcomm.org/present-proof/1.0/request-presentation"`, I might want to pass in a properties object that contains, perhaps, visual information that wouldn't make sense outside of our environment but also isn't required for the processing of the presentation request.

swcurran (Wed, 14 Oct 2020 04:08:21 GMT):
Take a look at the Aries RFC 0003 on protocols - https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0003-protocols As I recall, it explains that extra info (fields) can be passed and a recipient should just ignore the info. Read through it to check.

swcurran (Wed, 14 Oct 2020 04:08:46 GMT):
I would add that if you think you need the info, maybe it's something that others might need as well.

swcurran (Wed, 14 Oct 2020 04:08:46 GMT):
I would add that if you think you need the info, maybe it's something that others might need as well and so you might want to suggest adding it to the RFC.

aaronr (Wed, 14 Oct 2020 20:14:42 GMT):
@swcurran I can think of a couple of things that we use them for so far * icon that represents the party (verifier, issuer) or image that represents the artifact (e.g. credential card) * meta information, e.g. a nonce an issuer can use to associate a credential offer and credential response with the user account it was offered to Not sure how interesting those are to others, they are legacy strategies. As we progress toward full Aries compliance, we'll see how much it changes our approaches and will be sure to put forward things we find useful.

swcurran (Thu, 15 Oct 2020 18:27:15 GMT):
The icon issue is a good use case that has some interesting tension to it -- we want it to improve the user experience, but we want to be careful to make sure a "self-asserted" image (no verification of the sender) can't be used to fool a user into thinking a connection is with one party when it isn't. The meta information for the use case you are talking about is inherent in Aries connections. The concepts of a "connection" (a peer-to-peer relationship between two agents that may or may not have a level trust associated with it), a 'thread" (an instance of a protocol execution), and a credential identifier (information needed to revoke a credential) are all data elements in Aries that can be used in a controller (business logic) to associate things in Aries to things in a business application.

aaronr (Fri, 23 Oct 2020 22:52:00 GMT):
Is there a way in Aries or Indy to determine if a credential is supported? For example, proactively determining if a credential conforms to W3C Verifiable Credentials v1.0 spec.

swcurran (Fri, 23 Oct 2020 23:26:21 GMT):
In the Issue Credential and Present Proof 2.0 RFCs (453, 454 as I recall, but could be wrong), there is a place for a registry for that type of information and how to detect that. It currently has two mechanisms listed in some of the place --- Indy (anoncreds ZKPs) and DIF protocols. That's at the RFC level. There would also need to be a "discover feature" capability at the implementation level that would provide runtime information.

swcurran (Fri, 23 Oct 2020 23:28:09 GMT):
At the implementation level, there are a couple of methods. One is discover feature, which could provide that. The other is that with the two protocols above, an Issuer/Holder and Prover/Verifier can negotiate which type of credential they offer (e.g. JWT, LD Proof, anoncreds, etc.) and based on those offered, which one to use.

smithbk (Tue, 27 Oct 2020 16:31:19 GMT):
Hi anyone, I have assumed that any Aries message which is NOT the first message of a thread MUST have non-equal `@id` and `~thread.id` fields; however, in my interop testing I see an agent which does not adhere to this. Is my assumption correct, or if not, how can I differentiate between the 1st message of a thread and a response to that message? Thanks

pfeairheller (Thu, 19 Nov 2020 18:56:29 GMT):
Has joined the channel.

marc0olo (Mon, 30 Nov 2020 04:51:57 GMT):
Has joined the channel.

cmendoza (Tue, 01 Dec 2020 21:31:11 GMT):
Has joined the channel.

tschulshuh (Wed, 02 Dec 2020 15:40:21 GMT):
Has joined the channel.

gagepoulson (Wed, 06 Jan 2021 15:30:29 GMT):
Has joined the channel.

da3v21 (Sun, 10 Jan 2021 12:26:24 GMT):
Has joined the channel.

paul.bastian (Mon, 01 Feb 2021 21:51:33 GMT):
Has joined the channel.

janl (Thu, 04 Feb 2021 15:21:12 GMT):
Has joined the channel.

CHempel (Mon, 15 Feb 2021 08:49:58 GMT):
Wallet Sync

CHempel (Mon, 15 Feb 2021 08:55:03 GMT):
Wallet Sync

JackyYuan (Tue, 23 Feb 2021 20:53:26 GMT):
Has joined the channel.

jcourt (Tue, 23 Feb 2021 22:56:30 GMT):
Has joined the channel.

dgt1nsty (Sat, 27 Feb 2021 07:25:03 GMT):
Has joined the channel.

rpobulic (Sun, 07 Mar 2021 05:16:44 GMT):
Has joined the channel.

lmtriet (Mon, 08 Mar 2021 20:50:14 GMT):
Has joined the channel.

sklump (Tue, 09 Mar 2021 15:20:05 GMT):
I'm about to start destroying aca-py functionality without further comment on https://github.com/hyperledger/aries-rfcs/issues/601. Does anyone need MIME types? Going, going...

swcurran (Tue, 09 Mar 2021 17:56:50 GMT):
...gone.

sklump (Wed, 10 Mar 2021 15:29:47 GMT):
Is nobody going to address Timo's https://github.com/hyperledger/aries-rfcs/issues/599 ? I need to know the goal I'm coding to, today ideally. Fiscal year end is approaching quick in Canada (21 days, some of them forced vacation) and after that there is no such thing as certainty _(hell, we haven't had a budget in two years)_

sklump (Wed, 10 Mar 2021 15:29:47 GMT):
Is nobody going to address Timo's https://github.com/hyperledger/aries-rfcs/issues/599 ? I need to know the goal I'm coding to, today ideally. Fiscal year end is approaching quick in Canada (21 days, some of them forced vacation) and after that there is always non-zero project risk from the Federal side.

sklump (Wed, 10 Mar 2021 15:29:47 GMT):
Is nobody going to address Timo's https://github.com/hyperledger/aries-rfcs/issues/599 ? I need to know the goal I'm coding to, today ideally. Fiscal year end is approaching quick in Canada (21 days, some of them forced vacation for me) and after that there is always non-zero project risk from the Federal side.

TimoGlastra (Wed, 10 Mar 2021 16:36:14 GMT):
I think it'll come up during the WG call later today

sklump (Wed, 10 Mar 2021 16:37:04 GMT):
Great, thanks

esune (Wed, 10 Mar 2021 19:25:10 GMT):
Revocation support in Aries .NET based mobile wallets

HighBrow (Tue, 16 Mar 2021 06:18:13 GMT):
Has joined the channel.

troyronda (Sat, 20 Mar 2021 13:23:39 GMT):
@swcurran @andrew.whitehead please see https://github.com/hyperledger/aries-framework-go/pull/2655

JamesEbert (Wed, 24 Mar 2021 19:03:09 GMT):
Has joined the channel.

Baha-sk (Thu, 25 Mar 2021 16:56:58 GMT):
@swcurran @kdenhartog @danielhardman @troyronda https://github.com/hyperledger/aries-rfcs/pull/625 I've added answers to the unanswered questions of RFC 334 so that we can move forward with our implementations

swcurran (Thu, 25 Mar 2021 23:22:43 GMT):
@troyronda -- a report from @ianco on the status of Aries Framework Go and Aries Cloud Agent Python interop. https://docs.google.com/document/d/1s4RoOy1nUgYRay_CR6MrkZWKPZ7H61nwmRtZoSPyRUw/edit?usp=sharing Let's get together on this (tomorrow?) and get the right people on both sides to push on these issues and get the tests we have working, and then looking at adding more. Now that more people in the world now about it, we need to improve the tests passing numbers on: https://aries-interop.info

Baha-sk (Tue, 06 Apr 2021 14:28:20 GMT):
hi @swcurran @george.aristy @danielhardman @TelegramSam @kdenhartog , I noticed this PR was closed https://github.com/hyperledger/aries-rfcs/pull/577 which I was hoping to fix https://github.com/hyperledger/aries-rfcs/issues/520, especially for DIDcomm, we are currently blocked for DIDComm V2 in AFG since we have no way of differentiating the keys' purpose/use in RecipientKeys (in V1 they're Ed25519 only). I do see an action item in the comment of this PR: * @TelegramSam will draft a new DID method spec similar to did:key that will allow a sender to encode several keys plus additional metadata that would indicate the key's purpose and algorithms any idea if this was materialized?

Baha-sk (Tue, 06 Apr 2021 14:28:20 GMT):
hi @swcurran @george.aristy @danielhardman @TelegramSam @kdenhartog , I noticed this PR was closed https://github.com/hyperledger/aries-rfcs/pull/577 which I was hoping to fix https://github.com/hyperledger/aries-rfcs/issues/520, especially for DIDcomm, we are currently blocked for DIDComm V2 in AFG since we have no way of differentiating the keys' purpose/use in RecipientKeys (in V1 they're Ed25519 only). I do see an action item in a comment of this PR: * @TelegramSam will draft a new DID method spec similar to did:key that will allow a sender to encode several keys plus additional metadata that would indicate the key's purpose and algorithms any idea if this was materialized?

Baha-sk (Tue, 06 Apr 2021 14:28:20 GMT):
hi @swcurran @george.aristy @danielhardman @TelegramSam @kdenhartog , I noticed this PR was closed https://github.com/hyperledger/aries-rfcs/pull/577 which I was hoping to fix https://github.com/hyperledger/aries-rfcs/issues/520, especially for DIDcomm, we are currently blocked for DIDComm V2 in AFG since we have no way of differentiating the keys' purpose/use in RecipientKeys (in V1 they're Ed25519 only). I do see an action item in a comment of this PR: > @TelegramSam will draft a new DID method spec similar to did:key that will allow a sender to encode several keys plus additional metadata that would indicate the key's purpose and algorithms any idea if this was materialized?

Baha-sk (Tue, 06 Apr 2021 14:35:36 GMT):
another option would be add a second list of keys: `RecipientsAuthenticationKeys` for signing and use `RecipientsKeys` for envelope encryption

Baha-sk (Tue, 06 Apr 2021 14:35:36 GMT):
another option would be add a second list of keys: `RecipientAuthenticationKeys` for signing and use `RecipientKeys` for envelope encryption

andrew.whitehead (Tue, 06 Apr 2021 19:14:54 GMT):
I've been going over the process of forming a connection if we use the DIDComm v2 envelope, which raises a lot of questions for me. It'd be nice to know what afgo does for some of this, and it would be nice if this could be simplified. @TelegramSam @george.aristy @Baha-sk @troyronda @swcurran https://hackmd.io/FUDOdm1gR666vW_z8r-pvQ

andrew.whitehead (Tue, 06 Apr 2021 19:16:56 GMT):
In general I'm bothered by the recurring requirement to encode a whole peer DID document into one string. For me a peer DID is one that only the other peer (or peers) knows, and it just needs to be a unique value that they have a DID document for. It doesn't have to be self-authenticating when you have the opportunity to sign it

Baha-sk (Tue, 06 Apr 2021 20:23:34 GMT):
the work to update AFGO to DIDComm V2 is wip @andrew.whitehead but the aim is to keep as much as possible of what V1 offers, the only change is the envelope format that's closer to a JWE compliant one using ECDH-1PU KW for authcrypt packer and the standard ECDH-ES KW for the anoncrypt packer, but the interaction between 2 agents doesn't change. We have identified an issue in DID Exchange with regards to the signing key used for signed attachment used in a connection response: both ACApy and AFGO currently use the DIDComm's service bloc's RecipientKeys[0] to sign the attachment. RFC 23 clearly mentions RecipientKeys are used to encrypt the envelope but are unfortunately used for signing in this specific case. This breaks the key's purpose used in RecipientKeys. We will need to update RFC 23 to mention that the key used for singing the attachment should be retrieve from the DIDDoc's authentication verification method.

Baha-sk (Tue, 06 Apr 2021 20:23:34 GMT):
the work to update AFGO to DIDComm V2 is wip @andrew.whitehead but the aim is to keep as much as possible of what V1 offers, the only change is the envelope format that's closer to a JWE compliant one using ECDH-1PU KW for authcrypt packer and the standard ECDH-ES KW for the anoncrypt packer, but the interaction between 2 agents doesn't change. We have identified an issue in DID Exchange with regards to the signing key used for signed attachment used in a connection response: both ACApy and AFGO currently use the DIDComm's service bloc's RecipientKeys[0] to sign the attachment. RFC 23 clearly mentions RecipientKeys are used to encrypt the envelope but are unfortunately used for signing in this specific case. This breaks the key's purpose used in RecipientKeys. We will need to update RFC 23 to mention that the key used for singing the attachment should be retrieved from the DIDDoc's authentication verification method.

andrew.whitehead (Tue, 06 Apr 2021 20:25:09 GMT):
Okay. I do think ECDH-ES is good for this purpose, and I saw @kdenhartog mention it once as an alternative, but it's not part of the spec right now

andrew.whitehead (Tue, 06 Apr 2021 20:26:20 GMT):
Is that something your KMS can do? I thought it had some restriction that was part of the reason you wanted to change envelope formats

Baha-sk (Tue, 06 Apr 2021 20:27:24 GMT):
yeah. not part of DIDComm specifically, but it's in an RFC as a general purpose JWE format, here are examples: https://github.com/hyperledger/aries-rfcs/blob/master/features/0334-jwe-envelope/anoncrypt-examples.md

Baha-sk (Tue, 06 Apr 2021 20:29:21 GMT):
AFGO has both JWE packers with underlying keys stored in our KMS supported these 2 packers: - Authcrypt (using ECDH-1PU kw) where a sender key is required -Anoncrypt (using standard ECDH-ES kw) where no sender info is used

Baha-sk (Tue, 06 Apr 2021 20:29:21 GMT):
AFGO has both JWE packers with underlying keys stored in our KMS supported. These 2 packers are: - Authcrypt (using ECDH-1PU kw) where a sender key is required -Anoncrypt (using standard ECDH-ES kw) where no sender info is used

Baha-sk (Tue, 06 Apr 2021 20:29:59 GMT):
DIDComm with did keys used to build these envelopes are one layer above these packers

Baha-sk (Tue, 06 Apr 2021 20:33:03 GMT):
we transform the did keys into raw keys then build the kms kid as JWK thumbprints

andrew.whitehead (Tue, 06 Apr 2021 20:34:46 GMT):
Okay. I don't understand setting apu and apv to the key values, that seems like redundant information

Baha-sk (Tue, 06 Apr 2021 20:38:40 GMT):
so in https://github.com/hyperledger/aries-rfcs/tree/master/features/0334-jwe-envelope, an anoncrypt recipient's apu the sender's epk key base64URL encoded, pseudo-code: `base64url(epk.x)` where epk.x is pointing to an `X25519` key while an authcrypt recipient's apu would be the sender's kid base64URL encoded.

Baha-sk (Tue, 06 Apr 2021 20:38:40 GMT):
so in https://github.com/hyperledger/aries-rfcs/tree/master/features/0334-jwe-envelope, an anoncrypt recipient's apu is the sender's epk key base64URL encoded, pseudo-code: `base64url(epk.x)` where epk.x is pointing to an `X25519` key while an authcrypt recipient's apu would be the sender's kid base64URL encoded.

Baha-sk (Tue, 06 Apr 2021 20:39:36 GMT):
yes, they're redundant information, but needed to preserve kw integrity of the wrapped cek, as suggested by @kdenhartog

andrew.whitehead (Tue, 06 Apr 2021 20:43:30 GMT):
It's base64-encoding a base64-encoded kid..

Baha-sk (Tue, 06 Apr 2021 20:43:41 GMT):
and the same thing with computing the AAD, it's Sha256 digest of the sorted recipient's KIDs, joined by a `.`

andrew.whitehead (Tue, 06 Apr 2021 20:44:04 GMT):
Also protecting an ephemeral cek, wrapped by a KDF with an ephemeral key ¯\_(ツ)_/¯

Baha-sk (Tue, 06 Apr 2021 20:45:33 GMT):
>It's base64-encoding a base64-encoded kid.. yes this is correct, since our kms kids are JWK thumbprints which are base64URL values, the apu is base64URL encoding the kid.. this is why it looks like we're base64URL encoding twice

andrew.whitehead (Tue, 06 Apr 2021 20:46:30 GMT):
Right, I suppose the kid could be anything

Baha-sk (Tue, 06 Apr 2021 20:47:14 GMT):
>Also protecting an ephemeral cek, wrapped by a KDF with an ephemeral key ¯\_(ツ)_/¯ this is to be consistent with authcrypt APUs, I didn't want to have different behaviour between ECDH-ES and ECDH-1PU

Baha-sk (Tue, 06 Apr 2021 20:48:28 GMT):
yes, the kid could be anything at the JWE level, the upper level can set DID keys, as long as the packer is able to resolve/fetch the underlying raw keys behind them from the kms

Baha-sk (Tue, 06 Apr 2021 20:48:28 GMT):
>Right, I suppose the kid could be anything yes, the kid could be anything at the JWE level, the upper level can set DID keys, as long as the packer is able to resolve/fetch the underlying raw keys behind them from the kms

andrew.whitehead (Tue, 06 Apr 2021 20:48:32 GMT):
Okay, I don't suppose it doesn't hurt to have it there since it's not leaking any information

andrew.whitehead (Tue, 06 Apr 2021 20:48:32 GMT):
Okay, I don't suppose it hurts to have it there since it's not leaking any information

Baha-sk (Tue, 06 Apr 2021 20:49:44 GMT):
yeah, correct the point is no information leaking should happen when building the envelope

andrew.whitehead (Tue, 06 Apr 2021 20:50:20 GMT):
It would be worse if for instance the apv was the recipient's public key

Baha-sk (Tue, 06 Apr 2021 20:51:15 GMT):
yeah.. the point is to use a kid, not the raw key in APU/APV.. except for EPKs since their ephemeral and are already in the envelope

andrew.whitehead (Tue, 06 Apr 2021 20:52:46 GMT):
It doesn't need to be validated anyway, I think the sender can use whatever values they like. The aad probably should be validated

Baha-sk (Tue, 06 Apr 2021 20:54:00 GMT):
no they don't, apu/apv are in the envelope and are directly used to kdf a kek then wrap/unwrap the cek

andrew.whitehead (Tue, 06 Apr 2021 20:54:16 GMT):
* whatever values they like as long as apu and apv don't match if they are non-empty. The spec says they must be distinct

andrew.whitehead (Tue, 06 Apr 2021 20:54:16 GMT):
* whatever values they like as long as apu and apv don't match if they are non-empty. The ECDH-1PU spec says they must be distinct

Baha-sk (Tue, 06 Apr 2021 20:54:51 GMT):
the aad is based on the recipients' KIDs.. if the recipient is not able to properly build it, they cannot decrypt the envelope

andrew.whitehead (Tue, 06 Apr 2021 20:55:28 GMT):
Is it not sent with the envelope?

Baha-sk (Tue, 06 Apr 2021 20:55:56 GMT):
APU/APV are in the recipient's headers, they are sent with the envelope

Baha-sk (Tue, 06 Apr 2021 20:57:01 GMT):
>The ECDH-1PU spec says they must be distinct I guess we can add a check to ensure APU and APV are not equal when unpacking..

Baha-sk (Tue, 06 Apr 2021 20:57:01 GMT):
>The ECDH-1PU spec says they must be distinct I guess we can add a check to ensure APU and APV are not equal if not empty when unpacking..

Baha-sk (Tue, 06 Apr 2021 20:57:01 GMT):
>The ECDH-1PU spec says they must be distinct I guess we can add a check to ensure APU and APV are not equal if not empty when packing and unpacking..

Baha-sk (Tue, 06 Apr 2021 21:09:53 GMT):
or if you meant the aad, if it's not sent with the envelope? yes it is, it has a sepecific `aad` header at the top level of the JWE, it's appended to the JWE's protected headers with a `.` to build a final AAD value used for AEAD encryption of the payload

Baha-sk (Tue, 06 Apr 2021 21:09:53 GMT):
or if you meant the aad, if it's not sent with the envelope? yes it is, it has a sepecific `aad` header at the top level of the JWE, it's appended to the JWE's marshalled protected headers with a `.` to build a final AAD value used for AEAD encryption of the payload

Baha-sk (Tue, 06 Apr 2021 21:13:21 GMT):
the only caveat is single recipient envelopes serialized in JWE Compact form, it doesn't support aad. You must use the JSON JWE flattened format for single recipients want want to use AAD (in this case the AAD would be the single recipient's KID)

Baha-sk (Tue, 06 Apr 2021 21:13:21 GMT):
the only caveat is single recipient envelopes serialized in JWE Compact form, it doesn't support aad. You must use the JSON JWE flattened format for single recipients and want to use AAD (in this case the AAD would be the single recipient's KID)

andrew.whitehead (Tue, 06 Apr 2021 21:27:43 GMT):
Okay well I'll work on the ECDH-ES approach for now, I'm adding methods to askar to do that.

Baha-sk (Tue, 06 Apr 2021 22:07:37 GMT):
sounds good.. don't hesitate to reach out if you have questions/issues

Baha-sk (Tue, 06 Apr 2021 22:53:28 GMT):
[ ](https://chat.hyperledger.org/channel/aries-interop?msg=XHFdC42qtcSc7umep) I've updated RFC 23 to effectively separate the signing key from the encryption keys in DID exchange: https://github.com/hyperledger/aries-rfcs/pull/626 this means Aries agents should update their code accordingly..

sklump (Wed, 07 Apr 2021 15:32:18 GMT):
... if it's accepted and merged

sklump (Wed, 07 Apr 2021 15:32:53 GMT):
... if it's accepted and merged

kdenhartog (Thu, 08 Apr 2021 08:00:18 GMT):
I'm not sure why that was closed. I'll leave that up to @swcurran and @george.aristy who appearred most active on it.

troyronda (Wed, 21 Apr 2021 21:45:08 GMT):
https://github.com/hyperledger/aries-cloudagent-python/issues/1108

troyronda (Wed, 21 Apr 2021 22:08:53 GMT):
( @swcurran @andrew.whitehead )

smithbk (Wed, 28 Apr 2021 18:05:10 GMT):
Anyone, is it possible for connection reuse (via https://github.com/hyperledger/aries-rfcs/tree/master/features/0434-outofband#reuse-messages) to work with peer DIDs. or must the DID be written to a ledger?

swcurran (Wed, 28 Apr 2021 19:02:35 GMT):
Per the RFC, the DID in the Out Of Band must be a published DID -- cannot be a peer DID.

swcurran (Thu, 06 May 2021 21:13:56 GMT):
An Indy Networks of Networks question has come up recently (mostly from me/Stephen Curran) about an Aries Agent, not knowing the ledger an object is to be found, checking a set of the networks in parallel to find the object. Several Aries Wallets do this today and we'd like to see if others would do this. The user experience improvement is significant. I'd like to get some feedback, particularly from Wallet makers, about this approach. In my first round of questions to Wallet makers on this a security issue was raised (see attached document) and I responded (in the same document). Bottom line for me is that I think the security issue can be mitigated, and that we’d like to see Wallet makers (and perhaps verifiers) use this approach. Please add your comments to this document -- https://docs.google.com/document/d/109C_eMsuZnTnYe2OAd02jAts1vC4axwEKIq7_4dnNVA/edit?usp=sharing Thanks

swcurran (Thu, 06 May 2021 21:13:56 GMT):
An Indy Networks of Networks question has come up recently (mostly from me) about an Aries Agent, not knowing the ledger an object is to be found, checking a set of the networks in parallel to find the object. Several Aries Wallets do this today and we'd like to see if others would do this. The user experience improvement is significant. I'd like to get some feedback, particularly from Wallet makers, about this approach. In my first round of questions to Wallet makers on this a security issue was raised (see attached document) and I responded (in the same document). Bottom line for me is that I think the security issue can be mitigated, and that we’d like to see Wallet makers (and perhaps verifiers) use this approach. Please add your comments to this document -- https://docs.google.com/document/d/109C_eMsuZnTnYe2OAd02jAts1vC4axwEKIq7_4dnNVA/edit?usp=sharing Thanks

swcurran (Thu, 06 May 2021 21:15:02 GMT):
The concern: ``` There are some serious security concerns that I'd like to point out, and these have been the main reason why we haven't added it to our mobile app. Due to the way ledgers and governance work on Indy networks, it is possible to have data that is present and different across ledgers. This is especially noticeable with DID and SCHEMA records, but also ATTR records. A DID can exist on one network with one key, but have completely different key on another network because of key rotation. A SCHEMA can have the same identifier, but completely different set of attributes across ledgers. A malicious person can very easily register a trusted DID on the Sovrin Staging ledger to duplicate one on the main network, and rotate their key, tricking the relying party into trusting the exchange. This isn't even that difficult to do and is completely valid within the governance framework, too. For an enterprise platform, this kind of security flaw can be completely unacceptable. There's also the developer headache of dealing with situations of why a proof doesn't pass as valid in some cases, because the app resolved the ledger data from a different ledger. Of course the new "did:indy" method will address all of this. Until then, I prefer to stay away from supporting obvious flawed mechanics, for the sake of UX improvement. ```

swcurran (Thu, 06 May 2021 21:29:32 GMT):
@tomislav @TimoGlastra @CHempel @sebastian @JamesEbert @andrew.whitehead @TelegramSam @esplinr @justinmason

justinmason (Thu, 06 May 2021 21:29:32 GMT):
Has joined the channel.

filip.burlacu (Fri, 14 May 2021 14:55:41 GMT):
Has joined the channel.

filip.burlacu (Fri, 14 May 2021 15:05:59 GMT):
Hey all, right now we're looking at configuring afgo in aath to connect to the test harness sov ledger - we're looking to use uniresolver, so I've got a few questions for setup does von-network have a pool config file we can give to the uniresolver sov driver? for https://github.com/decentralized-identity/uni-resolver-driver-did-sov#uniresolver_driver_did_sov_poolconfigs

filip.burlacu (Fri, 14 May 2021 15:14:26 GMT):
is von-network providing a local sovrin network at all? I may be misunderstanding how it works

swcurran (Fri, 14 May 2021 15:20:59 GMT):
Yes -- von-network is providing a local network. The pool config file can be retrieved from an environment variable GENESIS_URL.

swcurran (Fri, 14 May 2021 15:22:01 GMT):
Are you using an external uniresolver or a local one?

ianco (Fri, 14 May 2021 15:51:33 GMT):
when you run von-network, it runs a ledger browser by default on port 9000, you can retrieve the pool transactions at `http://localhost:9000/genesis`

ianco (Fri, 14 May 2021 15:53:01 GMT):
Indy ledger nodes are pinned to a specific IP address, when you run von-network the default IP it uses is the internal IP address of the Docker network (you can see the IP address in the pool transactions)

ianco (Fri, 14 May 2021 15:53:54 GMT):
... you can run von-network using your local IP address (or any IP actually) by specifying the IP when you start von-network, e.g. `./manage start 192.168.0.11`

filip.burlacu (Fri, 14 May 2021 17:02:31 GMT):
I'd like to set up a local uniresolver, that can be started by the AATH manage script

jaqo (Thu, 20 May 2021 02:53:22 GMT):
Has joined the channel.

swcurran (Fri, 21 May 2021 19:27:07 GMT):
Folks working on wallets that support Indy and that have or will be supporting automatic querying of multiple Indy ledgers to resolve identifiers: A question came up about handling a situation where a holder has credentials from multiple networks that could satisfy a Proof Request. How are you choosing the default credential to use for the response? Would it be worth sharing a document (perhaps perhaps the Google Doc linked below to start) that provides the rules on what to do when an object is found on multiple networks? https://docs.google.com/document/d/109C_eMsuZnTnYe2OAd02jAts1vC4axwEKIq7_4dnNVA/edit?usp=sharing @sebastian at LISSI -- since you have had the feature the longest, could you share what rules you are following? @justinmason -- perhaps you could also kick in? FYI -- we are starting work on adding the feature to ACA-Py, so it can be part of all of the verifiers we deploy. FYI 2 -- I believe we should all be encouraging issuers to NOT use the same identifier (DID/Nym) on multiple networks. This might be done when an app is promoted from Dev -> Staging -> Prod. Agreed?

esune (Fri, 21 May 2021 20:01:05 GMT):
Are issuers supposed to only be connected to one network at a time? Could they be connected to more than one network and therefore need to have the same DID across them?

esune (Fri, 21 May 2021 20:02:33 GMT):
Also as I think I mentioned in the past, I wonder if "same did" for an issuer could potentially be seen in the future the same way as "same domain name" for Organizations that have a multi-national presence.

esune (Fri, 21 May 2021 20:02:52 GMT):
Just throwing it out there as a possibly very wrong brainstorming idea

justinmason (Sat, 22 May 2021 05:03:10 GMT):
I'll provide more thoughts over the weekend, but we've had several discussions internally about this sort of cross-network credential selection criteria. What @esune mentions, which is that having the same issuer DID on multiple networks may be a good thing, has also come up.

sebastian (Tue, 25 May 2021 08:03:29 GMT):
Normally, if the user has multiple credentials that could satisfy a proof request we select the latest issued credential first and allow him to choose a different one. If the credential happens to be on the wrong network, the verification would fail. Currently, this makes it necessary for a verifier to construct the presentation request in such a way that is specific enough about network. When we implemented that feature, our assumption was that at least in the beginning the majority of holders will stick to one network and that most verifiers they interact with are on the same network.

swcurran (Tue, 25 May 2021 14:12:09 GMT):
@esune -- an issuer will likely only issue from one network, and we should encourage them NOT use the the same DID on multiple networks. That is what creates the problem. If no one does that -- there is never a problem. @sebastian -- I agree that's the best approach. And it's the same as what would be used when they have multiple credentials that meet the criteria from the same network.

swcurran (Tue, 25 May 2021 14:14:04 GMT):
I think that Proof of being the same entity should be in the holding of the same VCs vs. having the same DID.

esune (Tue, 25 May 2021 16:41:43 GMT):
I am still convinced that expecting issuers not to use the same DID on different networks is not great way of preventing issues, I understand the problem, but since this is just a recommendation rather than something that can be enforced we should expect it to happen sooner or later - regardless of whether it makes sense, it is on purpose or not.

swcurran (Tue, 25 May 2021 16:49:31 GMT):
Agreed -- he still have to deal with it. But we can tell issuers they will get into less problems if they don't do that. We're doing a hack here, so just trying to do the best we can.

filip.burlacu (Wed, 26 May 2021 18:17:39 GMT):
@swcurran hey Stephen, it looks like the did docs acapy publishes through indy also need to be updated to satisfy RFC 0067-didcomm-diddoc-conventions here's what they look like right now, and afgo fails to process it since there isn't a service of `did-communication` type: ``` { "@context": "https://www.w3.org/2019/did/v1", "id": "did:sov:17hRTxZFuRqqwFPxXnnuLj", "service": [ { "type": "endpoint", "serviceEndpoint": "http://172.17.0.1:9031" } ], "authentication": [ { "type": "Ed25519SignatureAuthentication2018", "publicKey": [ "did:sov:17hRTxZFuRqqwFPxXnnuLj#key-1" ] } ], "publicKey": [ { "id": "did:sov:17hRTxZFuRqqwFPxXnnuLj#key-1", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "14ehnBh9oevUhQUADCRk5dmMCk3cmLukZcKNCTxLGiic" } ] } ```

filip.burlacu (Wed, 26 May 2021 18:17:39 GMT):
@swcurran hey Stephen, it looks like the did docs acapy publishes through indy (for the OOB invitation) also need to be updated to satisfy RFC 0067-didcomm-diddoc-conventions here's what they look like right now, and afgo fails to process it since there isn't a service of `did-communication` type: ``` { "@context": "https://www.w3.org/2019/did/v1", "id": "did:sov:17hRTxZFuRqqwFPxXnnuLj", "service": [ { "type": "endpoint", "serviceEndpoint": "http://172.17.0.1:9031" } ], "authentication": [ { "type": "Ed25519SignatureAuthentication2018", "publicKey": [ "did:sov:17hRTxZFuRqqwFPxXnnuLj#key-1" ] } ], "publicKey": [ { "id": "did:sov:17hRTxZFuRqqwFPxXnnuLj#key-1", "type": "Ed25519VerificationKey2018", "publicKeyBase58": "14ehnBh9oevUhQUADCRk5dmMCk3cmLukZcKNCTxLGiic" } ] } ```

swcurran (Wed, 26 May 2021 20:51:52 GMT):
This is a function of the resolver, unfortunately. Indy does not have full DIDDoc support, and then assembly of the DIDDoc from the returned objects is constructed by the resolver. I'm guessing you are using the Universal Resolver?

swcurran (Wed, 26 May 2021 20:52:08 GMT):
Full DIDDoc support is in "did:indy", but it's not implemented.

justinmason (Fri, 04 Jun 2021 06:30:25 GMT):
I think that using the same DID will be expected, so we'll have to deal with that eventuality. Having the same schema on multiple networks is extremely convenient, but obviously open to subterfuge, since I can have different attributes on each ledger. It'll be simpler for the end user ultimately if any given entity can have the same DID on various networks with schema written to various networks. I have no need to know if my cell phone is connected to Sprint or T-Mobile to call a phone on Verizon in today's cellphone mess. The key is that we have to have a way to talk about networks/ledgers and tag objects whether via the diddoc itself or something else in the protocol. I would say that we first need a language to talk about ledgers in a globally unique way--to me, a DID for each ledger lends itself to the technology we're espousing. Then, whether it's a distributed ledger of ledgers or peer DIDs for describing ledgers, you could describe all objects absolutely. The UniversalResolver mechanisms just have to take one extra step to go deeper than a `did:` to resolve a network, but none do that yet. Right now, networks have a moniker proprietary to each app for each network which is in no way interoperable.

justinmason (Fri, 04 Jun 2021 06:38:56 GMT):
In the meantime, there is a lot to consider: - How many attributes or Names groups of attributes can you satisfy from one network? That's our main priority generally, unless a proprietary decorator on a message indicates otherwise. - How many attributes or Names groups of attributes can be satisfied by the same cred? Given that Indy won't list creds that couldn't satisfy this given attribute? - Always show the context -- a network moniker, and visually indicate attributes linked by Names, via a grouping or coloring or something

swcurran (Fri, 04 Jun 2021 18:30:38 GMT):
To solve the issue that @filip.burlacu raised above, I've proposed this change to the Indy `did:sov` DID Method and notably the result of reading an Indy DID and rendering the DID Document -- see this PR: https://github.com/sovrin-foundation/sovrin/pull/296. If that is OK, we'll update the universal resolver and request @dbluhm (or someone else?) to update the internal ACA-Py did:sov resolver accordingly -- so both match. Make sense?

troyronda (Mon, 12 Jul 2021 17:34:53 GMT):
@swcurran adds orb to AATH: https://github.com/hyperledger/aries-agent-test-harness/pull/288

troyronda (Mon, 12 Jul 2021 20:33:30 GMT):
Hurray - AATH now has another DID method service (orb).

shaanjot.gill (Thu, 12 Aug 2021 18:49:03 GMT):
Has joined the channel.

filip.burlacu (Fri, 17 Sep 2021 16:07:49 GMT):
So I fixed the recent afgo didexchange issues locally, and I can pass all didexchange tests, afgo-afgo and afgo-acapy both ways, _if_ I run one test at a time But, because afgo is reusing the connection, running multiple didexchange tests at once will fail all but the first, since they expect to be going through correct didexchange states, rather than being completed already If I configure the CI to run each test separately (so, with fresh agents), would that break the allure dashboard reporting?

filip.burlacu (Fri, 17 Sep 2021 16:07:59 GMT):
@swcurran ?

sheldon.regular (Fri, 17 Sep 2021 16:16:07 GMT):
Hi Filip, Do you have the latest from main? There has been some work removing the interim state checks. Unless I'm misunderstanding the issue? The afgo to afgo run we have in CI is running and passing two DIDEx tests.

filip.burlacu (Fri, 17 Sep 2021 18:02:43 GMT):
ohh, that could be it

filip.burlacu (Fri, 17 Sep 2021 18:03:50 GMT):
I rebased on the latest before testing today, but it could be a change I introduced that's causing a problem, then

regiseloi (Fri, 17 Sep 2021 19:11:09 GMT):
Has joined the channel.

filip.burlacu (Wed, 22 Sep 2021 15:38:10 GMT):
@sheldon.regular @swcurran https://github.com/hyperledger/aries-agent-test-harness/pull/344 is ready for review You can mainly look at the middle commit, `feat: support afgo-acapy RFC0453/0454 interop, and fix 0023 interop issues`, the others are self-contained some commits in this PR are optional - if we want to keep the allure-generated environment.properties in git, I can remove the `chore: remove environment.properties from index` commit and `feat: service command can now start/stop all services in one go` is convenient for my local testing, and we could switch CI over to using the service command if we want, but if it doesn't seem useful, I can remove this commit too.

darrell.odonnell (Wed, 22 Sep 2021 16:30:07 GMT):
The approach appears sound to me, though it has some obvious pitfalls. As the number of Indy networks becomes large you are chewing your own resources to solve the problem that `did:indy` is intended to solve. Further, there will be a disconnect in time - where one wallet supports an Indy network list that differs from others.

nbAmit (Wed, 20 Oct 2021 04:55:26 GMT):
Has joined the channel.

kalyankonda (Thu, 10 Feb 2022 07:16:02 GMT):
Has joined the channel.

rjones (Tue, 22 Mar 2022 19:54:32 GMT):

rjones (Tue, 22 Mar 2022 19:54:33 GMT):