rjones (Thu, 13 Apr 2017 18:27:36 GMT):
are people able to join this channel freely?
drummondreed (Thu, 13 Apr 2017 18:29:03 GMT):
Has joined the channel.
drummondreed (Thu, 13 Apr 2017 18:29:53 GMT):
I just got the notice on the #indy channel and was able to join this channel directly. No problems. (But then, I was a member of the what is now #indy-agent-old too, if that makes any difference).
rjones (Thu, 13 Apr 2017 18:30:13 GMT):
that's fine.
rjones (Thu, 13 Apr 2017 18:35:04 GMT):
nage
peacekeeper (Thu, 13 Apr 2017 19:19:01 GMT):
Has joined the channel.
peacekeeper (Thu, 13 Apr 2017 19:19:25 GMT):
also managed to join without problems
anttikettunen (Thu, 13 Apr 2017 19:50:25 GMT):
Has joined the channel.
stevetolman (Thu, 13 Apr 2017 20:00:26 GMT):
Has joined the channel.
windley (Thu, 13 Apr 2017 20:18:11 GMT):
Has joined the channel.
devin-fisher (Thu, 13 Apr 2017 20:25:05 GMT):
Has joined the channel.
farooq_m_khan (Fri, 14 Apr 2017 05:37:25 GMT):
Has joined the channel.
fabienpe (Fri, 14 Apr 2017 10:00:30 GMT):
Has joined the channel.
TelegramSam (Fri, 14 Apr 2017 18:19:54 GMT):
Has joined the channel.
peacekeeper (Sun, 16 Apr 2017 19:47:35 GMT):
FYI my RWoT#4 topic paper about verifiable claims and link contracts using XDI and Sovrin DIDs: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/topics-and-advance-readings/xdi-verifiable-claims-link-contracts.md
drummondreed (Mon, 17 Apr 2017 15:46:16 GMT):
Good job, Markus. I just uploaded the first of three that I'll be posting, this one on DID Names: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/topics-and-advance-readings/did-names.md
VipinB (Tue, 18 Apr 2017 14:35:06 GMT):
Has joined the channel.
nage (Wed, 19 Apr 2017 19:59:36 GMT):
It is time again to put together an agenda for our Agent Working Group Meeting. Please speak up here if you have topics you'd like to cover.
nage (Thu, 20 Apr 2017 14:54:45 GMT):
It looks like the agenda for today will be very light. We might have some updates on libsovrin, and there will be some community news (what is going on at RWoT, Hyperledger and IIW 24)
TelegramSam (Thu, 20 Apr 2017 15:10:40 GMT):
- Meeting Notes -
devin-fisher (Thu, 20 Apr 2017 15:11:11 GMT):
Discussing rebooting the web of trust. Papers will be discussed. In particular of interest are about DID. Nathan will post links to paper in this chat.
We are continuing to moving to hyperledger. We have a Jira space in hyperledger. All tickets for work being done to Indy will be done over there.
We have a new mailing list for hyperledger indy
nage (Thu, 20 Apr 2017 15:11:48 GMT):
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2017/blob/master/topics-and-advance-readings/did-family-of-specifications.md
nage (Thu, 20 Apr 2017 15:12:12 GMT):
https://lists.hyperledger.org/mailman/listinfo/hyperledger-indy
nage (Thu, 20 Apr 2017 15:12:45 GMT):
https://jira.hyperledger.org/projects/INDY/issues
nage (Thu, 20 Apr 2017 15:14:36 GMT):
upcoming events http://www.internetidentityworkshop.com/ and https://www.hyperledger.org/events
nage (Thu, 20 Apr 2017 15:14:36 GMT):
upcoming events http://www.internetidentityworkshop.com/ and https://www.hyperledger.org/event/washington-d-c-hyperledger-hackfest
nage (Thu, 20 Apr 2017 15:26:37 GMT):
danielhardman: We would like some discussion around wallets and vaults in this meeting and collaborate on use cases for these
danielhardman (Thu, 20 Apr 2017 15:28:35 GMT):
Has joined the channel.
danielhardman (Thu, 20 Apr 2017 15:29:52 GMT):
Here's the link to my doc discussing guidlines for libsovrin wrappers: https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit
nage (Thu, 20 Apr 2017 15:30:47 GMT):
You can manage your account settings here http://identity.linuxfoundation.org/
danielhardman (Thu, 20 Apr 2017 15:30:51 GMT):
And here's the link to libsovrin's API: https://github.com/evernym/sovrin-client-rust/tree/master/src/api
RiahiKarim (Thu, 20 Apr 2017 15:32:15 GMT):
Has joined the channel.
nage (Thu, 20 Apr 2017 15:43:22 GMT):
Discussion about SNI Hints and the prototype of SovrinTLS that we've been experimenting with on top of aiohttp
nage (Thu, 20 Apr 2017 15:43:58 GMT):
TelegramSam: is hoping to build a prototype to allow people to see how it might work, if we can get it to where it is demonstrable we'll share it out
nage (Thu, 20 Apr 2017 15:44:33 GMT):
...: the long term goal would to see if we could get something like that incorporated into something like openssl, but we need a viable path forward until then
nage (Thu, 20 Apr 2017 15:46:08 GMT):
cbruguera: asked about migration plan from RAET->an HTTP-like mechanism
danielhardman (Thu, 20 Apr 2017 15:46:15 GMT):
Here is a link to my doc stub about wallet use cases: https://docs.google.com/document/d/13s0M7XGd2t3M7Kybb18O5d6t9MfqA3hQ_HlOlriJb98/edit?usp=sharing
nage (Thu, 20 Apr 2017 15:46:35 GMT):
TelegramSam: talked about options for allowing both to work in parallel and the options to develop a more full interface over time
nage (Thu, 20 Apr 2017 16:07:04 GMT):
https://docs.google.com/a/evernym.com/presentation/d/1Q6p1Tqp5UFSqq0gNOq3fIo04uxWrXbVD87DZHCfTl10/edit?usp=sharing
nage (Thu, 20 Apr 2017 16:07:17 GMT):
(the Agenda from today's meeting)
cbruguera (Thu, 20 Apr 2017 21:43:29 GMT):
Has joined the channel.
denofernandes (Sat, 22 Apr 2017 13:39:26 GMT):
Has joined the channel.
tkuhrt (Tue, 25 Apr 2017 15:23:50 GMT):
Has joined the channel.
benjaminbollen (Thu, 27 Apr 2017 16:40:51 GMT):
Has joined the channel.
benjaminbollen (Thu, 27 Apr 2017 16:46:55 GMT):
Hi everyone ! Im Ben (working Hyperledger Burrow) but very interested to keep the conversation we had at the Hackfest about a unified user story from Indy, Composer and Burrow permissions going. @nage suggested to do it here initially cc @sstone1
sstone1 (Thu, 27 Apr 2017 16:46:55 GMT):
Has joined the channel.
nage (Thu, 27 Apr 2017 17:17:45 GMT):
@TelegramSam there are a bunch of common issues with Indy Agents, especially around the mechanisms for authorizations we have discussed (I think the binary formats being used by Burrow and Composer may be farther along here), and the idea of Swagger+EventedAPI specifications (where I think you're work may be helpful to inform where we are all trying to get to)
drummondreed (Sat, 29 Apr 2017 19:00:46 GMT):
@benjaminbollen I just got back to Seattle from a long two weeks on the road, but +1 to working together here to develop a unified user identity story across all the projects. (Note that in Sovrin land we call it an *identity owner* since a person is only a "user" from the perspective of a particular system.)
cbruguera (Sun, 30 Apr 2017 00:29:05 GMT):
Sometimes when running an agent, a message such as the following is displayed in the logs:
> Signing and Encryption keys were not found for Hswa2Vg88xTxtBy5TGxYGTwwraCbBw8zQfoi6DJeU3tB. Creating them now.
Where are these keys being stored?
avkrishnan (Sun, 30 Apr 2017 10:48:40 GMT):
Has joined the channel.
cbruguera (Mon, 01 May 2017 00:07:47 GMT):
Another question: How can I tell the `sendPing` method works properly? The function doesn't actually return anything, or more precisely it returns a supposed `req_id` but this is always None since `sendMessage` method doesn't return anything.
darrell.odonnell (Mon, 01 May 2017 12:26:16 GMT):
Has joined the channel.
rjones (Mon, 01 May 2017 18:32:39 GMT):
Has left the channel.
Sean_Bohan (Tue, 02 May 2017 05:43:39 GMT):
Has joined the channel.
prashiyn (Tue, 02 May 2017 06:47:47 GMT):
Has joined the channel.
nage (Wed, 03 May 2017 13:41:39 GMT):
Please propose agenda items or proposed topics and questions for the Indy Agent WG call tomorrow here in chat.
nage (Wed, 03 May 2017 13:42:35 GMT):
So far we have: setting up a test network (see questions above) - @here Any volunteers to cover this?
nage (Wed, 03 May 2017 13:43:05 GMT):
Archiving sovrin slack channels to move the conversation here
nage (Wed, 03 May 2017 13:43:51 GMT):
Common approaches between Composer and Indy Agents and how we can leverage the similarities
nage (Wed, 03 May 2017 13:44:36 GMT):
ACL formats in Composer and Burrow and potential overlap with Indy Agent AuthZ mechanisms
danielhardman (Thu, 04 May 2017 15:10:53 GMT):
I'd like to talk about libsovrin a bit.
danielhardman (Thu, 04 May 2017 15:13:11 GMT):
Notes from WG call: uport + Indy/Sovrin interested in collaborating on DID spec (which makes DIDs interoperable across ledgers), plus SovrinTLS (aka DIDTLS), plus DID-Auth (using DID+key to authenticate someone).
danielhardman (Thu, 04 May 2017 15:21:07 GMT):
Motion to cut over, chat-wise: archive #agent on sovrin's slack, start using the Rocket.Chat channel here.
danielhardman (Thu, 04 May 2017 15:21:24 GMT):
agent-to-agent comm with CurveZMQ
danielhardman (Thu, 04 May 2017 15:59:32 GMT):
Sebastian, you can email me at daniel dot hardman at evernym dot com
cbruguera (Thu, 04 May 2017 16:00:40 GMT):
Did the zoom link change for the agent meetings?
cbruguera (Thu, 04 May 2017 16:03:59 GMT):
@danielhardman
cbruguera (Thu, 04 May 2017 16:04:28 GMT):
@nage I'm trying the habitual zoom link, but no one's there.
cbruguera (Thu, 04 May 2017 16:05:33 GMT):
Or did it end already? :-/
nage (Thu, 04 May 2017 16:07:09 GMT):
Apologies for the technical difficulties, the call dropped briefly and then we were able to resume it
nage (Thu, 04 May 2017 16:08:10 GMT):
The call ended about 5 minutes early
cbruguera (Thu, 04 May 2017 16:09:44 GMT):
But what time did it start?
danielhardman (Thu, 04 May 2017 16:09:50 GMT):
An hour ago.
cbruguera (Thu, 04 May 2017 16:10:16 GMT):
shouldn't it be at 9:00 MST? What time is it there? :-/
cbruguera (Thu, 04 May 2017 16:16:25 GMT):
I just read in a comment that would be held at 8:00... I was guiding myself through this, though: http://forum.sovrin.org/t/agent-working-group-call/157/7
cbruguera (Thu, 04 May 2017 16:17:05 GMT):
which is the only publicly available information there is on these events, as far as I know.
nage (Thu, 04 May 2017 16:27:01 GMT):
Time zones, we need to get better about always using time zones!
snowy13 (Thu, 04 May 2017 16:34:50 GMT):
Has joined the channel.
cbruguera (Thu, 04 May 2017 16:48:42 GMT):
@nage the calendar link you sent me is still not working. Maybe that'd be a help... I don't like missing these calls, they're important to me.
nage (Thu, 04 May 2017 16:49:44 GMT):
I'll be back into the office Friday, and I'll sort out what is going wrong
nage (Thu, 04 May 2017 16:50:09 GMT):
We need a good central calendar to track everything that is happening
cbruguera (Thu, 04 May 2017 16:50:45 GMT):
OK but meanwhile we can just clear it up via this chatroom. Are meetings scheduled to be held at 8:00am or 9:00am MST?
cbruguera (Thu, 04 May 2017 16:54:25 GMT):
Oh I see, I'm just being confused about MST and MDT
cbruguera (Thu, 04 May 2017 16:54:39 GMT):
Could this be a matter of daylight saving?
cbruguera (Thu, 04 May 2017 16:57:19 GMT):
I guess it is.
nage (Thu, 04 May 2017 19:25:45 GMT):
It is 9 mountain time. The daylight savings time switch affects translation to other time zones (both because of when mountain time changes and when your local time may change)
cbruguera (Thu, 04 May 2017 22:44:13 GMT):
I've been having a discussion with @devin-fisher about how to check ATTRIB transactions. We're bringing it here so other community members can contribute as well..
cbruguera (Thu, 04 May 2017 22:45:07 GMT):
Basically, I have this agent method defined:
cbruguera (Thu, 04 May 2017 22:45:39 GMT):
```
def make_attrib_request(self, attrib):
self.wallet.addAttribute(attrib)
reqs = self.wallet.preparePending()
return self.client.submitReqs(*reqs)
```
cbruguera (Thu, 04 May 2017 22:45:39 GMT):
```
def make_attrib_request(self, attrib):
self.wallet.addAttribute(attrib)
reqs = self.wallet.preparePending()
return self.client.submitReqs(*reqs)
```
cbruguera (Thu, 04 May 2017 22:47:23 GMT):
(it's a method defined in my agent class)
The question, basically, is how to know this is actually working or not.
I've been checking a file named `test_nym_attrib.py` on sovrin_client/test, to guide myself..
In some places it looks like the way to check would be to invoke the agent's wallet `getAttribute` method, and then check if `attr.seqNo is not None`...
However, I just can't see where in the whole workflow is this `seqNo` being updated.
Of course the agent attribute is visible if I look into `agent.wallet._attributes` but seqNo is None, and I just don't know how to verify the attribute has been effectively recorded on the ledger or not.
I'm using `sovrin-client-dev=0.3.76` by the way, which is what I got from installing directly from sovrin-client master branch.
cbruguera (Thu, 04 May 2017 22:49:05 GMT):
I'm now checking a function in sovrin_common/util.py called `ensureReqCompleted`... If there are any other suggestions regarding this matter, or pointers on how is this utility function to be used, I'd highly appreciate it.
cbruguera (Thu, 04 May 2017 22:50:24 GMT):
By the way, this is an agent I'm just instantiating on the run in a test function. Does this agent need to have a "nym" registered on the ledger or something like that in order to be able to perform these transactions?
devin-fisher (Thu, 04 May 2017 22:50:35 GMT):
I don't know much about the client but this might help.
in sovrin_client/agent/walleted.py there is a function _sendToSovrinAndDo
which calls a utility function in sovrin_common/util.py called ensureReqCompleted
which I believe will check for a completed request. Also, allows for a callback when it is complete.
But this is an example of mixing coding style between async and callbacks that I think makes the code confusing. I'm hopeful that we will improve this.
I don't know what permissions are needed to issue an attrib transaction.
also, this type of conversion would be better on rocket chat but I don't get notifications nearly as well on rocket chat for hyperledger.
devin-fisher (Fri, 05 May 2017 03:22:58 GMT):
We discussed on the working group meeting about setting up test environments. Couple of developers at Evernym have been working to make launching an Indy (Sovrin) network easier through docker. We also have files for vagrant and AWS. Anyway, they are contained in this github repo: https://github.com/evernym/sovrin-environments#sovrin-environments
I have not personally tried it but any feed back you can give (maybe through github issues) would help to make this work smoothly on as many environments as possible.
danielhardman (Fri, 05 May 2017 15:58:29 GMT):
Here is another resource for running a test node locally: https://github.com/sovrin-foundation/sovrin/pull/24
paulmersky (Sat, 06 May 2017 07:26:23 GMT):
Has joined the channel.
peacekeeper (Mon, 08 May 2017 06:50:57 GMT):
Hello, should libsovrin be able to connect to these test environments ?
nage (Mon, 08 May 2017 17:12:20 GMT):
The intent is that they are compatible. If it doesn't work, I'd expect it to be a bug worth logging.
tyler (Mon, 08 May 2017 18:56:25 GMT):
Has joined the channel.
TelegramSam (Tue, 09 May 2017 04:20:57 GMT):
@drummondreed I've begun to make the spec changes discussed at IIW. I've made a few (but not all necessary) changes to the DID spec in the Google Doc, and I've begun writing an example Agent DID Service Spec. Please holler if you have feedback more general than fits in a doc comment thread.
harrihoo (Tue, 09 May 2017 06:22:19 GMT):
Has joined the channel.
turmewr3ck (Tue, 09 May 2017 08:20:36 GMT):
Has joined the channel.
drummondreed (Tue, 09 May 2017 21:12:53 GMT):
@TelegramSam Very good. I've seen a few Google doc change notices but haven't had time to process them yet. I likely won't have time until EIC is over on Friday, but then I'll be on it. In the meantime, please make edits/comments as needed, and send me a link to your Agent DID Service Spec when you're ready.
hydrat (Thu, 11 May 2017 07:28:46 GMT):
Has joined the channel.
dhuseby (Thu, 11 May 2017 14:15:46 GMT):
Has joined the channel.
Skorpion7777 (Thu, 11 May 2017 20:25:27 GMT):
Has joined the channel.
amigus (Wed, 17 May 2017 23:40:02 GMT):
Has joined the channel.
nage (Thu, 18 May 2017 14:51:19 GMT):
The regular agent WG call is scheduled to start in 10 minutes https://zoom.us/j/232861185
nage (Thu, 18 May 2017 14:54:06 GMT):
Items to cover:
* Update on Hyperledger Indy migration
* Any updates on libsovrin?
* ????
nage (Thu, 18 May 2017 15:06:32 GMT):
We are working at migrating tickets over to Hyperledger's Jira https://jira.hyperledger.org/browse/INDY-7
nage (Thu, 18 May 2017 15:06:57 GMT):
I'll announce more information here when the bulk of the tickets start to appear
nage (Thu, 18 May 2017 15:09:54 GMT):
We discussed what tickets aren't logged anywhere regarding libsovrin and libsovrin language wrappers
nage (Thu, 18 May 2017 15:10:17 GMT):
Daniel and Markus were open to logging them in Hyperledger Jira and making room for them in the github repos there as well
nage (Thu, 18 May 2017 15:15:10 GMT):
We are hoping that Tyler Ruff will give an introduction to how we've organized Jira and what to do to manage issues as soon as the first few tickets are moved over from the Evernym Jira server
nage (Thu, 18 May 2017 15:16:27 GMT):
https://jira.hyperledger.org/browse/INDY-2
nage (Thu, 18 May 2017 15:18:03 GMT):
Sorry about that, Daniel must have dropped not realizing he was still set as the host
nage (Thu, 18 May 2017 15:18:10 GMT):
please join back into the same meeting
cbruguera (Thu, 18 May 2017 15:18:11 GMT):
Aww...
cbruguera (Thu, 18 May 2017 15:18:16 GMT):
Alright
nage (Thu, 18 May 2017 15:18:19 GMT):
https://zoom.us/j/232861185
nage (Thu, 18 May 2017 15:21:03 GMT):
Carlos asked what is the current status of the stand alone agent repo
nage (Thu, 18 May 2017 15:23:15 GMT):
https://docs.google.com/presentation/d/1hlWqNZ3yLeOPL_zYnONQGqI9Ho5dOso5huTJgw3yZvc/present
nage (Thu, 18 May 2017 15:23:34 GMT):
goes through the functionality of libsovrin (to be renamed libindy)
nage (Thu, 18 May 2017 15:24:03 GMT):
the reference agent should be relatively thin and not having much logic relative to this client library
nage (Thu, 18 May 2017 15:24:29 GMT):
and until this library stabilizes I expect that the stand alone agent repo will be somewhat neglected (volunteers welcome)
nage (Thu, 18 May 2017 15:36:16 GMT):
There were some more good questions about the maturity and production readiness of libsovrin
nage (Thu, 18 May 2017 15:36:24 GMT):
@danielhardman will post the links to the video demos here
nage (Thu, 18 May 2017 15:36:44 GMT):
See #indy-sdk channel for updates and interacting with the developers of the library
danielhardman (Thu, 18 May 2017 15:51:23 GMT):
I have posted links to libsovrin demos in #indy-sdk
TelegramSam (Thu, 18 May 2017 17:27:56 GMT):
Overview of the DID TLS approaches. Please contribute or comment, particularly with technical details of problems or (preferably) solutions. :)
TelegramSam (Thu, 18 May 2017 17:28:30 GMT):
https://docs.google.com/document/d/10Lga3UBeDnbE0EO4ippElC0N0J0RxfLDuTSvPso7SnE/edit?ts=5919c808#
TelegramSam (Thu, 18 May 2017 17:29:25 GMT):
@farooq_m_khan ^
TelegramSam (Thu, 18 May 2017 17:29:49 GMT):
@nage ^
peacekeeper (Thu, 18 May 2017 18:57:21 GMT):
@TelegramSam can you change permissions on the doc so everyone can comment/suggest
nage (Thu, 18 May 2017 19:34:46 GMT):
Everyone should now be able to comment
cbruguera (Thu, 18 May 2017 23:11:40 GMT):
*Question:*
I know there's an ongoing development on http-based agent communication, as well as agent "extensions" over http (I more or less understand this is also related to Sovrin TLS somehow)... However, does it make any sense (or is it feasible) to work on ZMQ-based agent extensions?
I'm completely ignorant about how does ZMQ work, but I was just asking myself if that'd be too complicated since agent-to-node and node-to-node communication is already supported by this protocol.
TelegramSam (Fri, 19 May 2017 03:00:00 GMT):
@cbruguera There can be, but the advantages of using HTTP with DID TLS are pretty huge. If we can't pass by some of the technical hurdles, we'll have to focus on extension support within a messaging protocol like ZMQ.
TelegramSam (Fri, 19 May 2017 03:00:22 GMT):
Extensions will be supported in some way, as they are key to future platform development.
nage (Fri, 19 May 2017 14:14:44 GMT):
Yes, @farooq_m_khan is investigating ZMQ based extensions now, but we are still hoping that DID TLS is close enough that we can leapfrog straight to the more universal approach
alex.nagelberg (Tue, 23 May 2017 15:40:29 GMT):
Has joined the channel.
krw910 (Wed, 24 May 2017 13:58:50 GMT):
Has joined the channel.
KhageshSharma (Thu, 25 May 2017 13:06:31 GMT):
Has joined the channel.
jlaw (Thu, 25 May 2017 14:26:02 GMT):
Has joined the channel.
anttikettunen (Fri, 26 May 2017 11:17:15 GMT):
Hey @nage, @TelegramSam et, al. Sorry, I've been out of sync for almost couple months. Though that hasn't put down my Sovrin-enthusiasm! A question for you guys: so far we've been talking individual <-> organisation pairwise connections. Is there any reason why Sovrin couldn't be used for direct organisation<->organisation pairwise connections? IIRC Agents are agnostic to their "owner". Verifiable information and trusted communication interfaces are needed between B2B as well.
nage (Fri, 26 May 2017 12:19:08 GMT):
You are correct. There is a lot of goodness to be had with all kinds of interactions between all combinations of people, organizations and things.
apoikola (Sat, 27 May 2017 15:29:53 GMT):
Has joined the channel.
turmewr3ck (Mon, 29 May 2017 10:46:04 GMT):
In this context, I guess that some agents will be more autonomous than others, right? For instance, a user/organization might be able to configure policies on what an agent could do without involving the user. Is things like this anticipated?
turmewr3ck (Mon, 29 May 2017 10:46:04 GMT):
In this context, I guess that some agents will be more autonomous than others, right? For instance, a user/organization might be able to configure policies on what an agent could do without involving the user. Are things like this anticipated?
srottem (Mon, 29 May 2017 20:59:38 GMT):
Has joined the channel.
TelegramSam (Tue, 30 May 2017 12:49:53 GMT):
We expect exactly what you describe. Some agents will be very autonomous, and some will be mostly under direct control by their human(s). Our focus in designing agent communication is to allow any level of automation so that we don't inhibit future innovation and unnecessarily restrict what they are capable of.
drummondreed (Tue, 30 May 2017 19:28:35 GMT):
Right on, Sam.
devin-fisher (Tue, 30 May 2017 20:51:56 GMT):
We have a agent working group meeting at 3:00 pm (GMT). @nage who normal runs the meeting is going to be on vacation. So, he has ask me to take his place.
So, I'm looking for who in the community is looking to share
devin-fisher (Tue, 30 May 2017 20:51:56 GMT):
We have a agent working group meeting on Thursday at 3:00 pm (GMT). @nage who normal runs the meeting is going to be on vacation. So, he has ask me to take his place.
So, I'm looking for who in the community is looking to share:
devin-fisher (Tue, 30 May 2017 20:55:26 GMT):
@TelegramSam: do you have updates to DID TLS or other agent work you are doing?
@gudkov or @danielhardman: do you have updates to share about indy-sdk?
gudkov (Tue, 30 May 2017 20:55:26 GMT):
Has joined the channel.
TelegramSam (Tue, 30 May 2017 20:56:01 GMT):
Slightly related is getting the compute/storage group going at the DIF.
devin-fisher (Tue, 30 May 2017 20:56:08 GMT):
@drummondreed: Do you have any updates about community events or conferences.
TelegramSam (Tue, 30 May 2017 20:56:27 GMT):
I can hilight our approach for testing DID TLS. Results not quite in yet.
drummondreed (Tue, 30 May 2017 20:57:40 GMT):
@devin-fisher When is the agent WG meeting? Thursday, correct? Yes, I can give an update that day. But I have a conflict if the meeting is today.
devin-fisher (Tue, 30 May 2017 20:59:26 GMT):
no, its on Thursday. Trying to see if advanced notice helps get wider participation.
devin-fisher (Tue, 30 May 2017 21:01:40 GMT):
@TelegramSam Anything you want to report would be helpful.
turmewr3ck (Wed, 31 May 2017 07:28:28 GMT):
Thanks @TelegramSam. The Sovrin whitepapers chiefly describes agents as something that you should not trust, but an agent built and deployed within an organization could perfectly well be trusted, right? And so such trusted agent could have access to the master key and hence the keyrings and encrypted containers? If so, is there any documents that describes the minimal set of required features / characteristics of such a trusted agent?
turmewr3ck (Wed, 31 May 2017 07:28:28 GMT):
Thanks @TelegramSam ; The Sovrin whitepapers chiefly describes agents as something that you should not trust, but an agent built and deployed within an organization could perfectly well be trusted, right? And so such trusted agent could have access to the master key and hence the keyrings and encrypted containers? If so, is there any documents that describes the minimal set of required features / characteristics of such a trusted agent?
danielhardman (Wed, 31 May 2017 15:00:55 GMT):
Agents can be trusted if their owners choose to do so--but we don't want the design to require such trust. Instead of having agents with master keys, we want agents that have delegated keys and limited authority. Have you seen this conceptual overview of agents? https://github.com/sovrin-foundation/sovrin/wiki/Perspectives-on-Agent-Design
mhailstone (Wed, 31 May 2017 22:55:37 GMT):
Has joined the channel.
turmewr3ck (Thu, 01 Jun 2017 07:14:06 GMT):
Read the document a while back, but the aspect of delegated keys I certainly missed that. Thanks.
devin-fisher (Thu, 01 Jun 2017 14:06:46 GMT):
@here ^^^
devin-fisher (Thu, 01 Jun 2017 14:42:16 GMT):
@gudkov You willing to give an update for indy-sdk at the agent working group meeting in a few minutes?
gudkov (Thu, 01 Jun 2017 14:43:51 GMT):
Actually no, agent work in progress and we expect first visible results next week.
gudkov (Thu, 01 Jun 2017 14:43:51 GMT):
Actually no, agent work is in progress and we expect first visible results next week.
devin-fisher (Thu, 01 Jun 2017 14:57:21 GMT):
Agenda for Working group meeting:
devin-fisher (Thu, 01 Jun 2017 14:57:21 GMT):
https://docs.google.com/presentation/d/1C35YQcX4z99Bz145nLkGLcBvG12viH7jgminkLTMeJo/edit#slide=id.g209ecb4b09_0_0
danielhardman (Thu, 01 Jun 2017 15:27:11 GMT):
Here is the link to the proposed agent-oriented APIs in libsovrin: https://github.com/hyperledger/indy-sdk/blob/master/src/api/agent.rs
mhailstone (Thu, 01 Jun 2017 15:50:30 GMT):
Just seeing there was an agent WG call. Is there a link to the meeting?
mhailstone (Thu, 01 Jun 2017 15:59:53 GMT):
I'm working on getting a running agent service.
I've tried running a docker-compose on the https://github.com/hyperledger/indy-sdk repository:
`docker-compose run sovrin-client-rust-test` but the `ledger_demo_works` test is failing.
gudkov (Thu, 01 Jun 2017 16:34:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=BxQaHH7W7Mh6JkjM8) Can you move this question to indy-sdk chat? Execution through docker-compose doesn't support tests that work with ledger now. You need to execute dedicated pool. It can be done with docker too.
gudkov (Thu, 01 Jun 2017 16:37:21 GMT):
You can use testUbuntu method in Jenkins to get instruction how to execute all tests
mhailstone (Thu, 01 Jun 2017 16:38:19 GMT):
Will do. Thanks @gudkov
TelegramSam (Thu, 01 Jun 2017 21:35:27 GMT):
@drummondreed and I just made some great progress on the definition of Agents in the DID Spec. I hope to have more to share there soon.
peacekeeper (Fri, 02 Jun 2017 04:00:41 GMT):
URL of that current version of DID Spec?
devin-fisher (Fri, 02 Jun 2017 14:37:20 GMT):
I believe the working document they are talking is here.
https://docs.google.com/document/d/1Z-9jX4PEWtyRFD5fEyyzEnWK_0ir0no1JJLuRu8O9Gs/edit#
drummondreed (Fri, 02 Jun 2017 23:43:25 GMT):
Yup, that's it. It's a living document, so please comment as needed.
turmewr3ck (Mon, 05 Jun 2017 18:51:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=WJvLdjjMJ83jvEA8t) @danielhardman By the way, does the framework support delegated keys directly, or are those something that needs to be developed case by case?
danielhardman (Mon, 05 Jun 2017 21:13:12 GMT):
The framework *allows* delegated keys. There is an academic paper about how delegated keys might work; it builds on BIP32 (used in BitCoin). See https://drive.google.com/file/d/0ByMtMw2hul0EMFJuNnZORDR2NDA/view and https://www.ietf.org/mail-archive/web/cfrg/current/msg09130.html
danielhardman (Mon, 05 Jun 2017 21:13:36 GMT):
However, there is not pre-built support for this featureset in the framework, only space for it.
peacekeeper (Mon, 05 Jun 2017 21:16:49 GMT):
My first RWoT paper in 2015 explored delegated BIP32 keys for use in XDI link contracts: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/topics-and-advance-readings/cool-hack-xdi-blockstore-bip32.md
nage (Thu, 15 Jun 2017 04:58:18 GMT):
Just a reminder of the Indy Agent WG tomorrow at 9 am mountain time here https://zoom.us/j/232861185. The information on the Hyperledger Calendar is incorrect (the zoom link there is for the Indy Node WG meeting). Please post any agenda items here. So far I expect to have updates about the hardening sprints (see Jira) and efforts to stand up the Alpha network. I would love for some updates about Indy-sdk (libsovrin), and a discussion about repositories for language-specific wrappers.
nage (Thu, 15 Jun 2017 14:59:53 GMT):
The Agent WG meeting starts in just a few minutes
nage (Thu, 15 Jun 2017 15:00:05 GMT):
@here
nage (Thu, 15 Jun 2017 15:27:59 GMT):
https://jira.hyperledger.org/secure/RapidBoard.jspa?projectKey=INDY&rapidView=133&view=planning
nage (Thu, 15 Jun 2017 15:32:58 GMT):
From @sergey.minaev: more information on indy-sdk https://chat.hyperledger.org/channel/indy-sdk
https://github.com/hyperledger/indy-sdk/tree/master/src/api
sergey.minaev (Thu, 15 Jun 2017 15:32:59 GMT):
Has joined the channel.
jimscarver (Thu, 15 Jun 2017 15:46:27 GMT):
Has joined the channel.
nage (Thu, 15 Jun 2017 15:58:29 GMT):
note for the meeting in two weeks: there is interest in talking about DID Auth and how integration with OAuth and Open ID platforms might work (or how to replicate that functionality using Sovrin-based BYOIDs)
peacekeeper (Thu, 15 Jun 2017 16:01:10 GMT):
Did I drop from the Zoom call? The DIF Agent WG group decided today to move their call one hour earlier, in order to not overlap with this one.
nage (Thu, 15 Jun 2017 17:20:55 GMT):
Yes, but thanks for the update, I think we were able to get the core of it.
himansri (Thu, 22 Jun 2017 17:56:16 GMT):
Has joined the channel.
mvsjober (Mon, 26 Jun 2017 11:27:24 GMT):
Has joined the channel.
Tiitus (Mon, 26 Jun 2017 12:47:02 GMT):
Has joined the channel.
nage (Wed, 28 Jun 2017 15:46:17 GMT):
Just a reminder that we have an Agent Working Group call scheduled in 23 hours and 15 minutes (Thursday 9:00 Mountain Time)
nage (Wed, 28 Jun 2017 15:48:42 GMT):
Topics so far:
* indy-sdk updates (Java wrapper, iOS, status of agent to agent communications with Pairwise Curve ZMQ)
* Update on Agent Communications DID TLS (status of ed25519 in openssl)
* Updates on work going on at DIF Identity Hubs
* General discussion about DID Auth (what do we want this to look like?)
*
nage (Wed, 28 Jun 2017 15:48:51 GMT):
If you'd like to propose other topics, please speak up here
nage (Wed, 28 Jun 2017 15:50:00 GMT):
@ashcherbakov or @sergey.minaev can one of you take the lead on the indy-sdk topics?
ashcherbakov (Wed, 28 Jun 2017 15:50:00 GMT):
Has joined the channel.
nage (Wed, 28 Jun 2017 15:50:15 GMT):
@TelegramSam would you be able to talk to us about DID TLS and DIF Identity Hubs?
gudkov (Wed, 28 Jun 2017 15:54:18 GMT):
@nage I can lead indy-sdk. Can you send invite to me?
nage (Wed, 28 Jun 2017 15:56:53 GMT):
Calendar appointments should be available on the Sovrin Development Calendar, or the Hyperledger Community Calendar
gudkov (Wed, 28 Jun 2017 15:57:33 GMT):
I am not sure i have access to this calendars.
nage (Wed, 28 Jun 2017 15:57:42 GMT):
these are both public calendars
nage (Wed, 28 Jun 2017 15:57:54 GMT):
the links should appear in #indy
nage (Wed, 28 Jun 2017 15:58:27 GMT):
but I'm not sure if they are entirely up to date and correct (please report issues)
nage (Thu, 29 Jun 2017 14:28:15 GMT):
The Agent WG call will start in 32 minutes here
https://zoom.us/j/232861185
nage (Thu, 29 Jun 2017 14:28:27 GMT):
@here ^^^
wightman (Thu, 29 Jun 2017 15:01:53 GMT):
Has joined the channel.
TelegramSam (Thu, 29 Jun 2017 15:04:55 GMT):
@nage I can give an update on DIF activity and DID TLS both.
nage (Thu, 29 Jun 2017 15:05:08 GMT):
Excellent
amigus (Thu, 29 Jun 2017 16:01:46 GMT):
Hi, this is Adam from the WG call. Can I keep asking questions related to agent security here, between meetings?
amigus (Thu, 29 Jun 2017 16:11:41 GMT):
PS. if my perspective would be helpful to others at any point, please ping me. I'm happy to make statements as well as ask questions. :-)
amigus (Thu, 29 Jun 2017 16:50:43 GMT):
I wrote up the questions I asked and what I understood to be the answers. Let me know if it would be helpful to post that here...
nage (Thu, 29 Jun 2017 19:21:41 GMT):
Yes please
amigus (Thu, 29 Jun 2017 19:30:18 GMT):
Message Attachments
amigus (Thu, 29 Jun 2017 19:31:15 GMT):
Weird. I was trying to do an inline copy/paste and it made me upload it as a file. Anyway, here are my notes. Hopefully I got it right and please correct me if not or add more -- I'm happy to get more information and carry the conversation forward...
peacekeeper (Thu, 29 Jun 2017 21:20:23 GMT):
Regarding @TelegramSam's report on using RSA keys in DID TLS for now, I wonder if there's some voodoo crypto that can seed an RSA keypair from an Ed25519 keypair, so that you wouldn't have to store a separate RSA key in your DDO and instead compute one in a deterministic way. Well nevermind, probably a really stupid idea.
TelegramSam (Thu, 29 Jun 2017 22:09:10 GMT):
@peacekeeper That is a great idea, if we can get it to work. Better yet, just put the seed method into the DDO resolver for the method, so that the chain storage stays low.
TelegramSam (Thu, 29 Jun 2017 22:11:36 GMT):
However it gets into the DDO, I want DID TLS to work with any key in the DDO, given library support for key type.
TelegramSam (Thu, 29 Jun 2017 22:11:48 GMT):
This allows future key types as well as older ones.
srottem (Fri, 30 Jun 2017 14:48:35 GMT):
Is there anyone out there who can help me get a Windows build environment set up for indy-sdk?
srottem (Fri, 30 Jun 2017 14:49:19 GMT):
Apologies - this shouldn't be here. Please ignore and I'll post in the right channel.
agslc (Fri, 30 Jun 2017 16:39:12 GMT):
Has joined the channel.
nage (Mon, 03 Jul 2017 14:12:04 GMT):
@gudkov any tips for Windows? ^^^
nage (Mon, 03 Jul 2017 14:12:42 GMT):
Looks like this conversation already found its way to #indy-sdk
jleders (Thu, 06 Jul 2017 22:15:32 GMT):
Has joined the channel.
nage (Wed, 12 Jul 2017 15:09:09 GMT):
@here it is time to set the agenda for another Agent WG meeting tomorrow. Does anyone have topics they would like to discuss?
nage (Wed, 12 Jul 2017 15:09:52 GMT):
@TelegramSam, would you be willing to give us an update on what is happening with the DIF working groups, and perhaps demo your progress on DID TLS?
nage (Wed, 12 Jul 2017 15:10:26 GMT):
@gudkov or @sergey.minaev: any updates about indy-sdk that you'd like to demo or share?
tharmon (Wed, 12 Jul 2017 15:43:31 GMT):
Has joined the channel.
gudkov (Wed, 12 Jul 2017 16:31:42 GMT):
We have implemented Agent API in indy-sdk. It is more less stable and available for wrappers developers.
nage (Wed, 12 Jul 2017 16:51:43 GMT):
Would you be willing to show folks these APIs and talk about how to make use of them (and provide feedback)?
TelegramSam (Wed, 12 Jul 2017 21:12:08 GMT):
@nage I will do both updates.
nage (Wed, 12 Jul 2017 21:12:23 GMT):
Thank you
Rouven (Thu, 13 Jul 2017 12:26:28 GMT):
Has joined the channel.
peacekeeper (Thu, 13 Jul 2017 14:53:01 GMT):
regrets i won't be able to join today's Agent WG call.. but am interested in progress on DID TLS
nage (Thu, 13 Jul 2017 15:03:42 GMT):
@here just a reminder that the Agent WG meeting is starting now https://zoom.us/j/232861185
danielhardman (Thu, 13 Jul 2017 15:05:38 GMT):
--- notes from agent WG call
danielhardman (Thu, 13 Jul 2017 15:05:58 GMT):
housekeeping items: anybody interested in making a logo? Talk about it here.
danielhardman (Thu, 13 Jul 2017 15:06:14 GMT):
working on getting people to sign CLA (contributor license agreement)
danielhardman (Thu, 13 Jul 2017 15:06:54 GMT):
package renaming happening in the code
danielhardman (Thu, 13 Jul 2017 15:07:27 GMT):
logo guidelines attached
danielhardman (Thu, 13 Jul 2017 15:07:27 GMT):
I'm trying to figure out how to attach logo guidelines
danielhardman (Thu, 13 Jul 2017 15:07:27 GMT):
Here are logo guidelines.
danielhardman (Thu, 13 Jul 2017 15:10:37 GMT):
Message Attachments
danielhardman (Thu, 13 Jul 2017 15:11:33 GMT):
Message Attachments
danielhardman (Thu, 13 Jul 2017 15:11:52 GMT):
Message Attachments
danielhardman (Thu, 13 Jul 2017 15:13:46 GMT):
About package renames, here's the note from @andrey.goncharov : python3-plenum -> indy-plenum
python3-anoncreds -> indy-anoncreds
sovrin-node -> indy-node
andrey.goncharov (Thu, 13 Jul 2017 15:13:46 GMT):
Has joined the channel.
danielhardman (Thu, 13 Jul 2017 15:16:08 GMT):
A new package 'sovrin' was introduced. It depends on indy-node and just provides genesis transactions for an indy-node.
nage (Thu, 13 Jul 2017 15:18:17 GMT):
@danielhardman presented a propsal about how contributions could work inside of the Indy community
nage (Thu, 13 Jul 2017 15:18:30 GMT):
... anyone can propose a completely different vision if you'd like
nage (Thu, 13 Jul 2017 15:19:01 GMT):
_ponders how these definitions jive with the ones in the Hyperledger charter and what the TSC uses_
nage (Thu, 13 Jul 2017 15:19:14 GMT):
(there is value in keeping these the same across Hyperledger)
nage (Thu, 13 Jul 2017 15:23:06 GMT):
MAINTAINERS.md seems like a better idea (some parts of Hyperledger projects are using .rst files, so using markdown seems good to me)
nage (Thu, 13 Jul 2017 15:24:06 GMT):
we should probably change "management" to something more open-source friendly like "primary maintainer" or "this list of folks: nage, danielhardman, ..."
nage (Thu, 13 Jul 2017 15:27:45 GMT):
danielhardman's presentation went through permissions, communication responsiveness for maintainers (#indy-pr-review channel), responsiveness to broken builds, and general rules for code (style, dependencies, copyright/patent concerns, etc)
danielhardman (Thu, 13 Jul 2017 15:30:09 GMT):
Indy Contributor Guidelines: http://bit.ly/2ugd0bq
nage (Thu, 13 Jul 2017 15:30:33 GMT):
TelegramSam: first off, the Distributed Identity Foundation has a WG called the "storage and compute WG" that is working on something they call "hubs" which means the same things as an Indy Agent
nage (Thu, 13 Jul 2017 15:30:52 GMT):
the group there has a github repository and would be happy to have more contributors
nage (Thu, 13 Jul 2017 15:30:57 GMT):
their initial work is all HTTP based
nage (Thu, 13 Jul 2017 15:31:15 GMT):
they have chosen TypeScript on Node to build a reference hub
nage (Thu, 13 Jul 2017 15:31:34 GMT):
any questions about what is going on at DIF? If so, please reach out to @TelegramSam
nage (Thu, 13 Jul 2017 15:32:11 GMT):
TelegramSam: Second there has been some progress on DID TLS, which is using the TLS protocol to replace CA verification with distributed ledger verification.
nage (Thu, 13 Jul 2017 15:32:52 GMT):
... what I have working is the ability for ....
nage (Thu, 13 Jul 2017 15:33:01 GMT):
@TelegramSam your audio is not good anymore
nage (Thu, 13 Jul 2017 15:34:21 GMT):
@mhailstone: We had a meeting with @nage and @TelegramSam last week to go over what the conceptual diagram at BYU looks like
nage (Thu, 13 Jul 2017 15:34:58 GMT):
... for us, we have organizations that are sister institutions of BYU that are owned and operated by the LDS church that we refer to as "CES" or "Church Educational System"
nage (Thu, 13 Jul 2017 15:35:31 GMT):
... there is an organization called BYU Pathways Worldwide that acts as a broker of educational information
nage (Thu, 13 Jul 2017 15:36:20 GMT):
... which leads to a concept of a student agent where a student can manage all of their educational content, credentials, and information about the student. Then they can use this information about their educational experiences to interact with institutions and organizations outside of the scope of CES.
nage (Thu, 13 Jul 2017 15:36:45 GMT):
... this is a diagram about the scope of what we believe a student agent could be. I have updated it relative to my conversations with folks here last week
nage (Thu, 13 Jul 2017 15:37:16 GMT):
... you can see how we're thinking of storing various types of profile data, learning resources and claims so that we can manage access to the APIs and the data.
nage (Thu, 13 Jul 2017 15:37:45 GMT):
... we are hoping to incorporate these agent services into Sovrin and the hub with the indy-sdk, so we need to get more information on how the Agent-to-Agent communications and things work technically
TelegramSam (Thu, 13 Jul 2017 15:41:24 GMT):
DIF Update: The Storage and Compute working group of the DIF is working on their spec for Hubs, which aligns with what we call Agents. They are working on permissions and profiles. We are involved and working towards common standards. Please ask if you have questions or want additional information.
TelegramSam (Thu, 13 Jul 2017 15:41:24 GMT):
DID TLS Update: (DID TLS is a project to use the existing TLS standards, but replacing CA verified certificates with certificates anchored to a chain. I have the server's (think agent's) chain cert being presented and verified correctly, and I'm working on having the client's (think calling agent) certificate verified against the chain as well.
nage (Thu, 13 Jul 2017 15:41:32 GMT):
... He showed us some information about schemas and swagger and how those might relate to what we're doing with agents
nage (Thu, 13 Jul 2017 15:41:45 GMT):
@mhailstone would you post a link to those github repositories and swagger files?
mhailstone (Thu, 13 Jul 2017 15:43:18 GMT):
https://github.com/byu-oit/node-byuapi-framework
mhailstone (Thu, 13 Jul 2017 15:43:58 GMT):
https://github.com/byu-oit/applicants-ces-api
nage (Thu, 13 Jul 2017 15:44:18 GMT):
@rajesh.kalaria showed a story that he is working on about agent versioning for API REST versioning
rajesh.kalaria (Thu, 13 Jul 2017 15:44:18 GMT):
Has joined the channel.
nage (Thu, 13 Jul 2017 15:48:16 GMT):
@TelegramSam updated us on the DID TLS status
nage (Thu, 13 Jul 2017 15:48:47 GMT):
@mhailstone mentioned a technology that they use for API versioning. He mentioned that he's not sure how the first one affects his resources, but likes it up higher in the path
nage (Thu, 13 Jul 2017 15:48:55 GMT):
... so that it doesn't affect your API resource design
nage (Thu, 13 Jul 2017 15:49:28 GMT):
@TelegramSam would normally agree, but in the case of Agents if it goes higher than the DID in the path it forces version upgrades to revision the ledger's service pointer.
nage (Thu, 13 Jul 2017 15:49:56 GMT):
... which means it needs to go after the id, so that you don't require a DID update, and allows an agent to support multiple versions simultaneously
nage (Thu, 13 Jul 2017 15:50:16 GMT):
... so perhaps agency.evernym.com/agent/id/12345/v2/auth
nage (Thu, 13 Jul 2017 15:50:43 GMT):
@mhailstone so where would the DID point to in this case?
nage (Thu, 13 Jul 2017 15:51:17 GMT):
@TelegramSam so it would point to the base uri of the specific agent, but it depends on what you're versioning the entire agent or a particular extensible API
nage (Thu, 13 Jul 2017 15:51:41 GMT):
... my inclination is that it would be better to version them seperately, so you could rev the Auth API without having to revision the unrelated APIs
nage (Thu, 13 Jul 2017 15:52:11 GMT):
@mhailstone so in my mind auth would be a context or a base path of a service, and you'd be able to version them independently, rather than having to do them at the agent root.
nage (Thu, 13 Jul 2017 15:52:50 GMT):
@TelegramSam yes, it is useful to think of the agent as a collection of services rather than one complete system. Which means you can have auth v1 and auth v2 running at the same time, while consuming clients are moving from one to the other
nage (Thu, 13 Jul 2017 15:53:19 GMT):
@danielhardman I was an advocate for the first of the three versions of these for a lot of the same reasons Sam articulated, but I've realized something that makes me question that:
nage (Thu, 13 Jul 2017 15:53:31 GMT):
... which is you might actually need a solution for versioning that is broader than just HTTP
nage (Thu, 13 Jul 2017 15:53:57 GMT):
... so if you want to talk to the same agent over HTTP and it also exposed some services over websockets or QUIC or another protocol, you're going to have the same issue showing up in other protocols
nage (Thu, 13 Jul 2017 15:54:13 GMT):
... so I'm wondering if it is smarter to say that the version is expressed in the messages that get sent and not in the URL?
mark.hadley (Thu, 13 Jul 2017 15:54:23 GMT):
Has joined the channel.
nage (Thu, 13 Jul 2017 15:54:35 GMT):
... There are some problems with that, because exposing versioning for the routing infrastructure is useful
nage (Thu, 13 Jul 2017 15:55:31 GMT):
@TelegramSam any encapsulation where we provide a bridge with HTTP and message will have to account for the "PATH" or "URI" portion of the system, so having the versioning in the path should translate using whatever mechanism you use to translate that to the non-path based protocol
nage (Thu, 13 Jul 2017 15:56:02 GMT):
@danielhardman so your saying there is always some construct that maps to the path, and the version can always be expressed using that mechanism
nage (Thu, 13 Jul 2017 15:56:17 GMT):
there was general agreement on the call for this approach
nage (Thu, 13 Jul 2017 15:56:23 GMT):
(please speak up if you disagree)
nage (Thu, 13 Jul 2017 15:56:42 GMT):
(or just have general feedback or comments you'd like to add)
nage (Thu, 13 Jul 2017 15:59:12 GMT):
@TelegramSam inclusion of additional data shouldn't constitute breaking things, and it is good to be as lazy as possible in updating these versions (only change it if it actually breaks the message processing)
nage (Thu, 13 Jul 2017 15:59:57 GMT):
... adding some additional information in the header or response about minor versions might be helpful, but if you're parsing things regular expressions or other bad processing techniques it might hurt you, but we wouldn't expect to have to protect you from yourself in those cases
nage (Thu, 13 Jul 2017 16:00:28 GMT):
@rajesh.kalaria If we increment any version, that means it just affects that one resource, or do we increment the API generally?
nage (Thu, 13 Jul 2017 16:00:49 GMT):
... based on this discussion it seems like we can do the version of the affected resource and not the others...that is what I'm understanding
nage (Thu, 13 Jul 2017 16:01:24 GMT):
@TelegramSam I'm a fan of revving the extension as a whole, rather than the individual resource
nage (Thu, 13 Jul 2017 16:01:52 GMT):
... that being said we want each extension to be as small and modular as possible, so if they are dealing with multiple resources we could consider whether they are one extension or multiple ones
nage (Thu, 13 Jul 2017 16:02:07 GMT):
@danielhardman Every extension certainly needs to be versioned independently
nage (Thu, 13 Jul 2017 16:02:30 GMT):
... because we cannot guarantee that extensions will comply with version statements you make about them
nage (Thu, 13 Jul 2017 16:03:05 GMT):
@TelegramSam I think versioning independently is the right answer and if sub-resources change it would trigger version changes at the extension level
nage (Thu, 13 Jul 2017 16:10:52 GMT):
@TelegramSam and @rajesh.kalaria could you summarize the conclusions that come out of the bonus period of the meeting?
TelegramSam (Thu, 13 Jul 2017 17:02:50 GMT):
Sure
TelegramSam (Thu, 13 Jul 2017 17:03:30 GMT):
An agent extension must be versioned if it includes any breaking changes to either it's arguments (expected input) or output.
TelegramSam (Thu, 13 Jul 2017 17:04:50 GMT):
A minor version can be used to record support for non-breaking changes, like optional attributes or extra information in either the input or output. This minor version should be present in the agent capability discovery to allow clients to understand availability for use.
TelegramSam (Thu, 13 Jul 2017 17:06:09 GMT):
@rajesh.kalaria did I miss anything?
danielhardman (Thu, 13 Jul 2017 19:55:20 GMT):
Message Attachments
faisal00813 (Thu, 20 Jul 2017 06:41:04 GMT):
Has joined the channel.
ryanmarsh (Thu, 20 Jul 2017 15:09:20 GMT):
Has joined the channel.
Sean_Bohan (Tue, 25 Jul 2017 15:07:02 GMT):
Indy Agent Folks:
This Thurs 7/27 we are doing the Agent WG call. Details here:
http://forum.sovrin.org/t/agent-working-group-call-7-27-agenda/353
Agenda:
We would love to have a focused discussion on the following topics:
Our Agenda:
1. Product roadmap for Hyperledger Indy
2. We want to share the current needs for Agents
3. We want your input and thoughts on what is there, what you think is needed
4. “Trailhead” for Hyperledger Indy Agents
5. Agent Extensible API
6. Growing the Agent community (invite a friend to take a look at our GitHub or join a WG call!)
THANKS!
jamesmonaghan (Wed, 26 Jul 2017 11:22:48 GMT):
Has joined the channel.
sanbachs (Thu, 27 Jul 2017 14:44:40 GMT):
Has joined the channel.
nage (Thu, 27 Jul 2017 14:46:32 GMT):
The Agent WG call starts in 14 minutes here https://zoom.us/j/232861185
nage (Thu, 27 Jul 2017 15:01:51 GMT):
The call has started :)
jamesmonaghan (Thu, 27 Jul 2017 15:02:56 GMT):
_waves_
JohnCallahan (Thu, 27 Jul 2017 15:03:15 GMT):
Has joined the channel.
TelegramSam (Thu, 27 Jul 2017 15:03:30 GMT):
= Meeting Start =
TelegramSam (Thu, 27 Jul 2017 15:04:10 GMT):
Introduction: John Callahan. CTO of Veridium.
nage (Thu, 27 Jul 2017 15:04:54 GMT):
Something going on at Hyperledger related to biometrics (though they haven't accounted for verifiable claims and Indy's architecture yet) https://docs.google.com/document/d/1YaQo5Yd2ooDurKhL_iGWkHO5KuNFA9L50GkXCs3LqeA/edit#heading=h.yh0l87vux0on
TelegramSam (Thu, 27 Jul 2017 15:05:02 GMT):
Introduction: Andrew Johnston of Telus
JohnCallahan (Thu, 27 Jul 2017 15:05:32 GMT):
thanks!
nage (Thu, 27 Jul 2017 15:06:33 GMT):
telegramsam: it has been a good week and a half for DID TLS
nage (Thu, 27 Jul 2017 15:06:43 GMT):
... we're trying to figure out what to do to make this work right away and into the future
nage (Thu, 27 Jul 2017 15:07:04 GMT):
... I have some demos on how to make end-to-end DID TLS work, but there are some more decisions that have to be made
nage (Thu, 27 Jul 2017 15:07:27 GMT):
... the server side of the DID TLS connection is fairly easy, by using the SNI hint for the DID you are connecting to
nage (Thu, 27 Jul 2017 15:07:52 GMT):
... the slightly harder piece is for the client to respond to a certificate request and return a chain-anchored certificate, as the pattern is a little farther away from normal
nage (Thu, 27 Jul 2017 15:08:14 GMT):
... in openssl's case if you request a client certificate there isn't a "self-signed" option (it hangs up if it isn't signed)
nage (Thu, 27 Jul 2017 15:08:28 GMT):
... the goal is to make this work now so there are a handful of options for the workaround
nage (Thu, 27 Jul 2017 15:08:47 GMT):
... the simplest is to just sign them with a CA, which is undesirable in the long term, but might be the quickest way to get started
nage (Thu, 27 Jul 2017 15:09:13 GMT):
... other options include various forms of signing certificates that could be presented, but there isn't an asynchronous way to do that
nage (Thu, 27 Jul 2017 15:09:24 GMT):
... so there may be a connection dance that is possible there
nage (Thu, 27 Jul 2017 15:09:49 GMT):
... we're working through that to see how we can make it work in the short term with an outline of what fixes/changes would be needed in the long-term
nage (Thu, 27 Jul 2017 15:10:06 GMT):
... this will allow us to have a mutually authenticated connection at the transport layer
nage (Thu, 27 Jul 2017 15:10:25 GMT):
... which should allow all sorts of peer-to-peer authenticated communication based on a blockchain
nage (Thu, 27 Jul 2017 15:12:02 GMT):
nage: if you wish to get involved, please reply to these status update or reach out to @nage or @TelegramSam
atjohnston (Thu, 27 Jul 2017 15:12:59 GMT):
Has joined the channel.
nage (Thu, 27 Jul 2017 15:13:28 GMT):
@srottem: I can't speak to much to the c-callable side, other than the functionality for the registration for custom wallet types has been added to it
nage (Thu, 27 Jul 2017 15:13:48 GMT):
... @peacekeeper has done some work to get the Java wrapper to support those features, and I've added some .net support for it
nage (Thu, 27 Jul 2017 15:14:08 GMT):
... the .NET wrapper hasn't been pulled in yet, but we expect that will be reviewed and pulled in sometime next week
nage (Thu, 27 Jul 2017 15:14:21 GMT):
... it should have roughly the same level of testing support (work in progress)
TelegramSam (Thu, 27 Jul 2017 15:16:30 GMT):
network golive is still moving forward. packages have been revisioned to 1.0 in prep for go live.
TelegramSam (Thu, 27 Jul 2017 15:17:25 GMT):
Not yet at incubation status at HyperLedger, but wanted to indicate that people are depending on the userspace.
TelegramSam (Thu, 27 Jul 2017 15:18:26 GMT):
Lots of testing and hardening.
TelegramSam (Thu, 27 Jul 2017 15:24:31 GMT):
Andrew Johnston asked about the connected nature of Agents.
TelegramSam (Thu, 27 Jul 2017 15:26:10 GMT):
Are they 'all' the agent?
TelegramSam (Thu, 27 Jul 2017 15:26:40 GMT):
Sometimes, but we often call the user facing portions of your agent clients.
TelegramSam (Thu, 27 Jul 2017 15:31:30 GMT):
State of Agents: lots of work by different parties, but not yet a community reference agent.
TelegramSam (Thu, 27 Jul 2017 15:31:49 GMT):
The IndySDK is the right building block for agenty things.
JohnCallahan (Thu, 27 Jul 2017 15:32:17 GMT):
can you spell the names
JohnCallahan (Thu, 27 Jul 2017 15:32:20 GMT):
?
TelegramSam (Thu, 27 Jul 2017 15:34:02 GMT):
@JohnCallahan names of projects? names of people?
TelegramSam (Thu, 27 Jul 2017 15:34:18 GMT):
oh.... usernames.
nage (Thu, 27 Jul 2017 15:34:21 GMT):
@gudkov and @MRJCrunch are the handles I was referring to (as experts on indy-sdk)
MRJCrunch (Thu, 27 Jul 2017 15:34:21 GMT):
Has joined the channel.
JohnCallahan (Thu, 27 Jul 2017 15:34:31 GMT):
perfect. thx!
TelegramSam (Thu, 27 Jul 2017 15:37:26 GMT):
James talking about Evernym goals and roadmap.
TelegramSam (Thu, 27 Jul 2017 15:40:21 GMT):
Sean talking about Indy Roadmap
TelegramSam (Thu, 27 Jul 2017 15:42:29 GMT):
We want to know desires of community as it relates to the roadmap. What do you want?
TelegramSam (Thu, 27 Jul 2017 15:49:07 GMT):
CII Badge Process: Core Infrastructure Inititative
TelegramSam (Thu, 27 Jul 2017 15:49:32 GMT):
Key pieces of Internet infrastructure. auditing and best practices for core infrastructure.
TelegramSam (Thu, 27 Jul 2017 15:49:53 GMT):
Hyperledger asks that all core projects participate.
nage (Thu, 27 Jul 2017 15:50:20 GMT):
https://www.coreinfrastructure.org/
nage (Thu, 27 Jul 2017 15:58:23 GMT):
@Sean_Bohan is taking notes in a google doc on his screen share
nage (Thu, 27 Jul 2017 15:58:43 GMT):
@Sean_Bohan will you share that doc when the call is finished?
Sean_Bohan (Thu, 27 Jul 2017 16:33:51 GMT):
YES!
Terminalman90 (Thu, 27 Jul 2017 17:17:55 GMT):
Has joined the channel.
edge (Thu, 27 Jul 2017 18:31:37 GMT):
Has joined the channel.
edge (Thu, 27 Jul 2017 18:32:28 GMT):
Hi all. nice to meet folks on this call today
edge (Thu, 27 Jul 2017 18:32:36 GMT):
(tom here)
nage (Thu, 27 Jul 2017 20:07:22 GMT):
Welcome @edge !
edge (Thu, 27 Jul 2017 22:13:40 GMT):
it's not quite ski season :D
edge (Thu, 27 Jul 2017 23:38:13 GMT):
.
srottem (Sun, 30 Jul 2017 20:11:18 GMT):
I have a few questions about the Getting Started scenario with Alice and Faber College. Am I correct in assuming that the identifier from the invitation Alice downloads has been pre-assigned to represent Alice's "account" at Faber on Sovrin? How does Faber know that Alice is who she says she is - would she have already authenticated with Faber through some non-Sovrin mechanism? The guide mentions Alice's Sovrin app - would I be correct in assuming that this would be a Faber College specific application that supports Sovrin and that Alice would authenticate through that in order to obtain an invitation that is effectively tied to her Faber account?
jamesmonaghan (Mon, 31 Jul 2017 08:48:44 GMT):
the assumption is that Alice has authenticated out-of-band with Faber
jamesmonaghan (Mon, 31 Jul 2017 08:49:10 GMT):
maybe she has clicked a link in the Internet Banking application, and the invitation has been dynamically generated for her, for example
jamesmonaghan (Mon, 31 Jul 2017 08:51:57 GMT):
her "sovrin app" would likely be separate to the Faber app, and she could use it to manage all her sovrin connections
jamesmonaghan (Mon, 31 Jul 2017 08:52:34 GMT):
so she'd log in to her banking app like normal, see an option to connect using sovrin, and on clicking that link the invitation file is opened by her sovrin app
srottem (Mon, 31 Jul 2017 09:09:08 GMT):
Gotcha. Thanks for the clarification. So the identifier in the link request is the Sovrin identifier that Faber would link to their internal systems, yes?
jamesmonaghan (Mon, 31 Jul 2017 10:00:15 GMT):
alice responds to a specific invitation saying "here's the identifier i'd like you to use for me", and faber stores that against the account the invitation was generated for
jamesmonaghan (Mon, 31 Jul 2017 10:00:46 GMT):
in the GST these examples are pretty hard-coded, but in a real-world scenario it would all be dynamically generated
Captain63Dragon (Wed, 02 Aug 2017 03:42:04 GMT):
Has joined the channel.
callahan (Wed, 02 Aug 2017 10:12:25 GMT):
Has joined the channel.
mgbailey (Fri, 04 Aug 2017 17:24:05 GMT):
Has joined the channel.
Suedonym (Tue, 08 Aug 2017 17:13:10 GMT):
Has joined the channel.
Suedonym (Wed, 09 Aug 2017 23:05:28 GMT):
Remember the Agent Working Group meeting tomorrow (8/10) at 9:00 AM US Mountain Time.
We will be discussing ways to engage, and @nage will be speaking to the road map.
If you have items you would like to see added to the agenda, please message them to me.
Suedonym (Wed, 09 Aug 2017 23:09:21 GMT):
https://zoom.us/j/232861185
nage (Thu, 10 Aug 2017 14:48:20 GMT):
indy-agent wg call in T-12 minutes
nage (Thu, 10 Aug 2017 15:01:00 GMT):
Agent WG call starting here https://zoom.us/j/232861185
nage (Thu, 10 Aug 2017 15:07:29 GMT):
Slava aka @gudkov works on the Indy SDK and will talk to us about what has been going on there
nage (Thu, 10 Aug 2017 15:07:54 GMT):
gudkov: the python wrapper has matured and is now ready to start using. Look at the wrappers folder for python and you can get started with it
nage (Thu, 10 Aug 2017 15:08:01 GMT):
... we have plans to use it more in the python code base
nage (Thu, 10 Aug 2017 15:08:25 GMT):
... we are also working on build pipelines to build libindy on Windows and the associated wrappers (for example the .NET wrapper, python and java)
nage (Thu, 10 Aug 2017 15:09:05 GMT):
... in the previous weeks we've created pipelines to produce builds for the various wrappers. We're going to continue adding Windows and Mac OSX and iOS platform support to the build system
nage (Thu, 10 Aug 2017 15:09:24 GMT):
... we are also working on the creation of some installers to help do quick installs of libindy and wrappers on supported platforms
nage (Thu, 10 Aug 2017 15:10:04 GMT):
... binary builds are published in the deb and rpm files in evernym's repo (@gudkov, please give a link)
nage (Thu, 10 Aug 2017 15:11:02 GMT):
... for now we are doing this on the master branch, which can have some stability issues. We will be making a stable release branch in the future where we will avoid anything that causes stability issues
nage (Thu, 10 Aug 2017 15:11:30 GMT):
... it looks like we need pointers to these repos on our github documentation, I'll be adding those
nage (Thu, 10 Aug 2017 15:11:40 GMT):
gudkov: also we started work on integration of DID TLS to our Agent API
nage (Thu, 10 Aug 2017 15:12:01 GMT):
... we are also targeting getting that in over the next couple of weeks
nage (Thu, 10 Aug 2017 15:12:21 GMT):
... so we should have automation of releases and a release branch and some release of libindy
nage (Thu, 10 Aug 2017 15:12:59 GMT):
... there are few new features we want to provide: DID TLS, some changes in the way the node API works (serialization approach) and other fixes to keep things integrated with the changes happening on the indy-node side
nage (Thu, 10 Aug 2017 15:14:00 GMT):
markus: there are improvements going on with the Java and .NET wrappers and they are in good shape
nage (Thu, 10 Aug 2017 15:14:20 GMT):
... looking forward to getting everything to a release and keeping it all in sync with libindy
nage (Thu, 10 Aug 2017 15:15:14 GMT):
doug: over the last week or so Sam has been building out a DID TLS specification doc
wightman (Thu, 10 Aug 2017 15:15:19 GMT):
https://docs.google.com/document/d/1-aPY1eeHdR_TnF7_WpEs58RZ_jNdDeptVrNEu3groFc/edit?usp=sharing
nage (Thu, 10 Aug 2017 15:15:33 GMT):
... it gives a good background on the spec itself and the effort to use DIDs for TLS authentication and encryption
nage (Thu, 10 Aug 2017 15:15:58 GMT):
... the idea here is that in libindy we will be able to use TLS in addition to the CurveZMQ pairwise authentication
nage (Thu, 10 Aug 2017 15:16:39 GMT):
... this work would happen in the Agent-to-Agent communication so that they can use certificates that are found on the ledger (basically self-signed certs) that can be traced back to the ledger for validation instead of root CA authorities
nage (Thu, 10 Aug 2017 15:17:40 GMT):
... the doc goes into detail about using SNI hints and how we use that to transfer the DID information during the initial handshake
nage (Thu, 10 Aug 2017 15:18:04 GMT):
... grab certificate information and resolve getting the needed information from the ledger DDO
nage (Thu, 10 Aug 2017 15:18:44 GMT):
... going forward this enables simple REST interfaces and so many other systems that use TLS to plug into agents more easily
nage (Thu, 10 Aug 2017 15:19:28 GMT):
... we have also been investigating the next steps for supporting this in the Agent API of indy-sdk
nage (Thu, 10 Aug 2017 15:19:47 GMT):
... and there will be some changes to that API to support both protocols (DID TLS and Pairwise Curve ZMQ)
wightman (Thu, 10 Aug 2017 15:20:34 GMT):
https://github.com/TelegramSam/DID-TLS
nage (Thu, 10 Aug 2017 15:20:39 GMT):
... right now there are two experimental/reference implementations of how to do this on Sam's github
nage (Thu, 10 Aug 2017 15:20:58 GMT):
... if you look there you'll see a python and a C example with a client reaching out to a server and specifying a DID in the SNI hint
nage (Thu, 10 Aug 2017 15:21:28 GMT):
... the server resolves that cert if it has it cached, or looks it up and adds it to its local chain off the ledger if it does not have it
nage (Thu, 10 Aug 2017 15:21:51 GMT):
... on the second try it should have loaded the cert into its cache and will correctly resolve the cert for the server and client side
nage (Thu, 10 Aug 2017 15:23:06 GMT):
... some further work that needs to be done is to get the system to look for the certs from the ledger instead of just stubbing in the files
nage (Thu, 10 Aug 2017 15:23:31 GMT):
gudkov: if I have an existing service where I want to just add an ssl layer over did tls, how could I integrate this into an existing service?
lohan.spies (Thu, 10 Aug 2017 15:24:12 GMT):
Has joined the channel.
nage (Thu, 10 Aug 2017 15:24:39 GMT):
doug: short term the answer is probably no. Short term we're looking at how to use sni hints to facilitate this. The servers accepting the connections right now (if they are just using openssl) aren't going to be able to find the cert when they look it up (they have to chain it back to a root CA). Long term we hope the library level could do that resolution (in something like openssl)
nage (Thu, 10 Aug 2017 15:29:43 GMT):
nage: we would like DID TLS to be interoperable at the DID level so it can be used with others at DIF
nage (Thu, 10 Aug 2017 15:30:17 GMT):
... also we expect that systems trying to integrate will need some agent smarts to handle the authentication and profile information associated with that connection
nage (Thu, 10 Aug 2017 15:30:34 GMT):
mhailstone: why does it do the double-connect?
nage (Thu, 10 Aug 2017 15:30:50 GMT):
doug: when the system first gets a certificate from the client it doesn't know about that certificate
nage (Thu, 10 Aug 2017 15:31:13 GMT):
... and the current libraries don't provide an opportunity to retrieve those certs during the handshake, but when it hangs up it can go look up the cert
nage (Thu, 10 Aug 2017 15:31:27 GMT):
... so when you ask a second time it can know about the certificate
nage (Thu, 10 Aug 2017 15:33:27 GMT):
nage: we aren't sure if it is a protocol layer issue or a library implementation issue, but doing this work around lets us support it immediately and then we hope to ask for the needed enhancements as it gets more adoption
nage (Thu, 10 Aug 2017 15:33:56 GMT):
markus: would this work also for SSH?
nage (Thu, 10 Aug 2017 15:34:19 GMT):
... I have mentioned MonkeySphere, a project with a similar approach before.
nage (Thu, 10 Aug 2017 15:35:47 GMT):
nage: I think that would make a great project, and because SSH already does ed25519, it could make a really interesting enhancement.
nage (Thu, 10 Aug 2017 15:39:05 GMT):
... the common ssh client even has some type of integration layer that might work for this
nage (Thu, 10 Aug 2017 15:39:05 GMT):
markus: the common ssh client even has some type of integration layer that might work for this
nage (Thu, 10 Aug 2017 15:41:33 GMT):
mikebailey: if I attach to a pool with the CLI and the pool object, does it actually download the stats from the ledger I can data mine about (like verkeys and stuff) from that ledger object?
nage (Thu, 10 Aug 2017 15:42:12 GMT):
nage: this question might need to be directed to the indy-node working group as the developers of that part of the system hang out there
nage (Thu, 10 Aug 2017 15:49:22 GMT):
nage: how do we help facilitate developers getting started
nage (Thu, 10 Aug 2017 15:49:41 GMT):
_talked and folks asked very good questions and had good comments, which nage did not effectively capture for the notes_
nage (Thu, 10 Aug 2017 15:51:57 GMT):
mhailstone: right now there aren't many markers pointing to jira, I need to go look there. I look for good example tests and getting started info, so having that should help, and I'll look at jira to try to have more of an opinion on what we might need there
nage (Thu, 10 Aug 2017 15:55:36 GMT):
lohan: which indy-sdk wrapper(s) are most mature or the best examples?
nage (Thu, 10 Aug 2017 15:55:51 GMT):
gudkov: most of them are equally mature, and there is good test coverage for all of them
nage (Thu, 10 Aug 2017 15:56:09 GMT):
... the C-callable library is actually the target of the sdk itself, so rust isn't a good target
nage (Thu, 10 Aug 2017 15:56:19 GMT):
... but the various sdk wrappers should all be pretty good
nage (Thu, 10 Aug 2017 15:56:30 GMT):
... for quickstart python is a good place to start as it is easy to setup and manage
nage (Thu, 10 Aug 2017 15:57:03 GMT):
lohan: is there any current implementation under development for node.js?
nage (Thu, 10 Aug 2017 15:57:35 GMT):
gudkov: right now there is not. We have a jira ticket for this if you're interested in taking it on (@gudkov, could you get us a link to that ticket)
nage (Thu, 10 Aug 2017 15:57:49 GMT):
lohan: most of the code we have so far uses node.js quite extensively
nage (Thu, 10 Aug 2017 15:58:13 GMT):
markus: there are some folks that have said they would commit resources to such a wrapper a couple of months ago, we should follow up with them
nage (Thu, 10 Aug 2017 15:58:23 GMT):
lohan: could you put us in contact with them to follow up on that?
nage (Thu, 10 Aug 2017 15:58:30 GMT):
markus: yes, I can try to get that started
gudkov (Thu, 10 Aug 2017 15:58:37 GMT):
https://jira.hyperledger.org/browse/IS-272
nage (Thu, 10 Aug 2017 15:58:56 GMT):
mhailstone: we're doing a lot of node.js work as well, perhaps we should do a separate call for that
nage (Thu, 10 Aug 2017 16:00:33 GMT):
nage: lets organize this here on rocket.chat so that people who want to participate can get involved. Feel free to self-organize, but if you need zoom support, etc, I'm happy to help with calendar coordination and those types of things too
lohan.spies (Thu, 10 Aug 2017 16:01:18 GMT):
@mhailstone would be great to organise a call regarding the nodejs wrapper and also to potentially get someone from Sovrin on the call as well. @peacekeeper please put us in contact with KYC Chain work they did on nodejs as well
mhailstone (Thu, 10 Aug 2017 16:01:29 GMT):
Here is my email for any Node.js call coordination: matthew_hailstone@byu.edu.
lohan.spies (Thu, 10 Aug 2017 16:01:46 GMT):
Great! will send an email now
mhailstone (Thu, 10 Aug 2017 16:01:59 GMT):
Thanks @lohan.spies!
nage (Thu, 10 Aug 2017 16:02:47 GMT):
Thanks to everyone for participating in the call. I look forward to seeing the continued discussion here in chat.
peacekeeper (Thu, 10 Aug 2017 17:52:29 GMT):
@lohan.spies @mhailstone I sent Eric Welton of KYCChain an email as well as a message on the Sovrin Slack. Let's see if there any news; if not then this group can just self-organize and get something started.
jljordan_bcgov (Thu, 10 Aug 2017 23:10:07 GMT):
Has joined the channel.
ewelton (Fri, 11 Aug 2017 04:08:50 GMT):
Has joined the channel.
ewelton (Fri, 11 Aug 2017 04:16:44 GMT):
@peacekeeper thanks for the head's up - i had to step away from digital identity for a short while as of Aug 1st am returning to DI - I am very much interested in a typescript/javascript effort. I do not have a useful code base to offer but I do have availability - I would be happy to pitch in some significant hours to get this going ASAP.
ewelton (Fri, 11 Aug 2017 04:23:18 GMT):
i'm just scanning the mailing list and I see some overlap with something I have been working on - ethereum TLS integration using caddy + coredns + geth - the need is for a GraphQL and websocket wrapper bound to a contract.
ewelton (Fri, 11 Aug 2017 04:23:18 GMT):
i'm just scanning the conversation and I see some overlap with something I have been working on - ethereum TLS integration using caddy + coredns + geth - the need is for a GraphQL and websocket wrapper bound to a contract.
lohan.spies (Fri, 11 Aug 2017 10:37:42 GMT):
@ewelton can you please provide me with your email address so that i can include you in the indy-sdk nodejs wrapper discussion
ewelton (Fri, 11 Aug 2017 10:47:26 GMT):
@lohan.spies hi - plz use eric@korsimoro.com - is there any interest in a go wrapper as well? That might be fun to plug into the caddy project - and a step towards broader adoption of DID TLS.
DibbsZA (Sun, 13 Aug 2017 06:28:25 GMT):
Has joined the channel.
marek.dapps (Mon, 14 Aug 2017 12:34:27 GMT):
Has joined the channel.
mhailstone (Thu, 17 Aug 2017 13:39:44 GMT):
@peacekeeper I appreciate @lohan.spies @albertod and @ewelton discussing in our email thread about getting started and some initial discussion. I will be out of the office Friday and Monday, but look forward to having a call sometime next week.
albertod (Thu, 17 Aug 2017 13:39:44 GMT):
Has joined the channel.
spivachuk (Thu, 17 Aug 2017 15:53:49 GMT):
Has joined the channel.
dsurnin (Thu, 17 Aug 2017 15:53:54 GMT):
Has joined the channel.
RBowron (Fri, 18 Aug 2017 00:20:40 GMT):
Has joined the channel.
swcurran (Mon, 21 Aug 2017 19:49:23 GMT):
Has joined the channel.
maheshkr81 (Tue, 22 Aug 2017 09:48:01 GMT):
Has joined the channel.
nage (Thu, 24 Aug 2017 14:50:46 GMT):
If you'd like to use a chunk of the agent WG call today to coordinate, I think that would be welcome
nage (Thu, 24 Aug 2017 15:03:16 GMT):
@here The Indy Agent WG starts now at https://zoom.us/j/232861185
drummondreed (Thu, 24 Aug 2017 15:04:02 GMT):
@nage I'd love to join but I have to be on a call with a prospective Founding Steward.
nage (Thu, 24 Aug 2017 15:07:01 GMT):
gudkov: we are working on the first official release of the sdk with bugfixes and stability fixes
nage (Thu, 24 Aug 2017 15:07:16 GMT):
... also we are working together on our vision of a communication framework for agents
nage (Thu, 24 Aug 2017 15:07:40 GMT):
... we are looking at the DID TLS solution as well as issues with the pairwise curve zmq
nage (Thu, 24 Aug 2017 15:07:53 GMT):
... we're not sure how we want to integrate all this yet, but hope to be able to share more soon
nage (Thu, 24 Aug 2017 15:08:23 GMT):
... We implemented most of anoncreds for revocation and is ready for integration as soon as the corresponding ledger transactions are ready
nage (Thu, 24 Aug 2017 15:08:53 GMT):
... For our first release we plan on making the release next week, releasing packages for Ubuntu, Windows and also Python and Java wrappers
nage (Thu, 24 Aug 2017 15:09:09 GMT):
... additional parts for iOS and .NET will be released in the next releases
nage (Thu, 24 Aug 2017 15:11:34 GMT):
nage: we are working on State Proofs for the ledger, which will cause us to expand the crypto support of the system. To do this we'd like to use a shared C crypto library, and hope to share it across other Hyperledger projects
nage (Thu, 24 Aug 2017 15:11:47 GMT):
... watch for news on this after the hackfests in Chicago and Europe
nage (Thu, 24 Aug 2017 15:12:07 GMT):
symon: work on the .NET wrapper is proceeding and should come soon, as Slava mentioned
nage (Thu, 24 Aug 2017 15:12:26 GMT):
mhailstone: we are working on a node.js wrapper
mhailstone (Thu, 24 Aug 2017 15:12:46 GMT):
https://plus.google.com/hangouts/_/trustlab.tech/sovrin-nodejs
nage (Thu, 24 Aug 2017 15:13:01 GMT):
daniel.hardman: question on the node.js wrapper, is that formally planned, and is anyone working towards a schedule?
nage (Thu, 24 Aug 2017 15:13:16 GMT):
mhailstone: organizations that are interested are starting conversations but nothing formal yet
nage (Thu, 24 Aug 2017 15:13:57 GMT):
daniel.hardman: we would like to start on this, and I didn't know there was any work underway yet there. Can we get a subgroup moving forward on this, as there are many that want it?
nage (Thu, 24 Aug 2017 15:15:14 GMT):
mhailstone: the status right now is simply that we've started
nage (Thu, 24 Aug 2017 15:15:23 GMT):
daniel.hardman: we have a document on how to write wrappers available
nage (Thu, 24 Aug 2017 15:16:07 GMT):
mhailstone: there will be a conversation tomorrow morning around this topic
nage (Thu, 24 Aug 2017 15:16:37 GMT):
mhailstone: the discussion will start tomorrow at 7:30 am Mountain Daylight time (relative to the 9:00 start of this meeting)
nage (Thu, 24 Aug 2017 15:16:58 GMT):
... there are some discussions around what javascript platforms we need to target and how to start
nage (Thu, 24 Aug 2017 15:18:37 GMT):
nage: please feel free to leverage the email lists and rocket.chat channels, and if you need other resources, please let me know
Suedonym (Thu, 24 Aug 2017 15:19:04 GMT):
email list - hyperledger-indy@lists.hyperledger.org
danielhardman (Thu, 24 Aug 2017 15:20:45 GMT):
Here's the doc about wrapper design, alluded to in @nage's comment above: https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit
nage (Thu, 24 Aug 2017 15:22:34 GMT):
Topic: agent to agent communications
nage (Thu, 24 Aug 2017 15:22:45 GMT):
farooq: we have some correlation troubles with service endpoints and keys
nage (Thu, 24 Aug 2017 15:23:06 GMT):
... we would like to have a way for establishing a connection with a unique pair of server and client keys
nage (Thu, 24 Aug 2017 15:24:02 GMT):
... in curve cp or curve zmq there are short term and long term keys (this is totally different than TLS)
nage (Thu, 24 Aug 2017 15:24:20 GMT):
... we ask the server to maintain an array of long term public/private keys, where each one is for a particular client
nage (Thu, 24 Aug 2017 15:24:31 GMT):
... when a new client arrives they tell the server which key they intend to use
nage (Thu, 24 Aug 2017 15:24:45 GMT):
... then the server can set the context and continue using the correct key to negotiate the channel
nage (Thu, 24 Aug 2017 15:25:01 GMT):
... there is an issue that allows someone snooping on the connection to detect who is trying to talk to the server
nage (Thu, 24 Aug 2017 15:25:12 GMT):
... it is filed as a defect on the curve zmq github issues list now
nage (Thu, 24 Aug 2017 15:26:15 GMT):
... https://github.com/zeromq/libzmq/issues/2529#issuecomment-324433160
nage (Thu, 24 Aug 2017 15:26:32 GMT):
... this link talks about the problem and possible solutions
TelegramSam (Thu, 24 Aug 2017 15:26:46 GMT):
DID TLS Spec: https://docs.google.com/document/d/1-aPY1eeHdR_TnF7_WpEs58RZ_jNdDeptVrNEu3groFc/edit#
nage (Thu, 24 Aug 2017 15:26:46 GMT):
... still working on this to see if we can get to a resolution, but we don't have one yet.
nage (Thu, 24 Aug 2017 15:28:02 GMT):
TelegramSam: the idea with DID TLS is to have a TLS based connection that provides encryption as well as mutual authentication
nage (Thu, 24 Aug 2017 15:28:21 GMT):
... the difficulties we have run into is that the implementations of the TLS spec make some things easy, but other things are quite difficult
nage (Thu, 24 Aug 2017 15:29:08 GMT):
... for example in server connections it is common to allow connections to self-signed server certificates, but no flags to do the same for client certificates (you cannot request one and not validate it in most deployed implementations)
nage (Thu, 24 Aug 2017 15:33:45 GMT):
nage: please take a look at this spec and the Pairwise Curve ZMQ designs
nage (Thu, 24 Aug 2017 15:34:04 GMT):
... we would like more eyes on this
nage (Thu, 24 Aug 2017 15:34:35 GMT):
TelegramSam: we are hoping to hide most of the cognitive load of these specs behind library code and methods that support developers integrating things into their own languages
nage (Thu, 24 Aug 2017 15:34:55 GMT):
... DID TLS hopes to be functional for agent-to-agent communication but also allow other TLS wrapped specifications to work
nage (Thu, 24 Aug 2017 15:35:28 GMT):
... right now the most successful peer-to-peer secure protocols are actually centralized, and the hope is that DID TLS would help us decentralize these types of systems
nage (Thu, 24 Aug 2017 15:35:55 GMT):
... it is a bit grand an ambitious in this sense, over time we hope we can make it much simplier
nage (Thu, 24 Aug 2017 15:36:04 GMT):
... I would love feedback about what is reasonable and not reasonable
nage (Thu, 24 Aug 2017 15:36:15 GMT):
... we need experts on particular platforms and its ability to deal with the compromises
nage (Thu, 24 Aug 2017 15:36:30 GMT):
... also if you are familiar with TLS or the spec, we could use feedback about items we may have missed
nage (Thu, 24 Aug 2017 15:36:30 GMT):
... also if you are familiar with the TLS spec, we could use feedback about items we may have missed
nage (Thu, 24 Aug 2017 15:36:57 GMT):
... and provide feedback about the cost compared to the benefits it provides
nage (Thu, 24 Aug 2017 15:37:44 GMT):
farooq: I am currently researching how we might have one private key with several corresponding public keys
nage (Thu, 24 Aug 2017 15:38:16 GMT):
nage: there are some HDKey formats that support these types of schemes
nage (Thu, 24 Aug 2017 15:38:25 GMT):
farooq: yes, I have started discussions with Dmitry on this
nage (Thu, 24 Aug 2017 15:39:48 GMT):
topic: general discussion and questions
nage (Thu, 24 Aug 2017 15:40:46 GMT):
daniel.hardman: are there any demos from recent sprints that we'd want to share here?
nage (Thu, 24 Aug 2017 15:41:00 GMT):
gudkov: there are some demos that we could share from the previous sprint
nage (Thu, 24 Aug 2017 15:41:20 GMT):
daniel.hardman: I would like to be able to show what has been accomplished lately, perhaps we can do this on the next one?
nage (Thu, 24 Aug 2017 15:41:45 GMT):
gudkov: the current plan is to create the demos at the end of the sprint and have them in a document, with links that we can share in this meeting
nage (Thu, 24 Aug 2017 15:45:28 GMT):
Looks like I wasn't marked as the meeting's host
nage (Thu, 24 Aug 2017 15:45:33 GMT):
and someone else leaving ended the call
nage (Thu, 24 Aug 2017 15:45:42 GMT):
Please feel free to continue discussion here
OlufAndrews (Thu, 24 Aug 2017 19:33:16 GMT):
Has joined the channel.
ewelton (Fri, 25 Aug 2017 02:04:49 GMT):
Oh goodness - I missed this agent WG call. I've been working on a node.js typescript wrapper and am working on writing tests now - following the lead from the other wrappers. I understand we're still have a call this evening (my time) to discuss the formal status.
ewelton (Fri, 25 Aug 2017 02:08:05 GMT):
in addition, some of us here in Chiangmai are working on implementing something very similar to DID-TLS in the caddy stack with some pluggable CAs. not exactly the DID-TLS spec (the rest of the team is uPort oriented), but similar. I hope to bring that into the DID-TLS fold once we have a functional node.js wrapper
ewelton (Fri, 25 Aug 2017 02:08:58 GMT):
looking forward to tonights's call re: the node.js wrapper and hope to start joining the working group calls soon...
DibbsZA (Fri, 25 Aug 2017 06:06:45 GMT):
@ewelton Great news.Looking forward to trying that out. Thaks for your efforts.
nage (Fri, 25 Aug 2017 17:22:04 GMT):
@TelegramSam please notice ewelton's comment about DID-TLS like functionality with some pluggable CAs
TelegramSam (Fri, 25 Aug 2017 17:26:12 GMT):
@ewelton do you have some time for a conversation about what you are doing? It has a good chance of moving our work along...
ewelton (Fri, 25 Aug 2017 17:58:09 GMT):
would love to - my first priority is a node.js libindy, but a deliverable moment later is a caddy/custom-CA module. It does seem like this should all grow-together.
jljordan_bcgov (Mon, 28 Aug 2017 17:00:29 GMT):
General Question:
https://github.com/decentralized-identity/hubs/blob/master/explainer.md
would the API Routes proposed in the above draft be something that Indy-Agents would implement to be "DIF Standards" compliant?
Am I correct in putting Agents and Identity Hubs at the same level of abstraction?
Syscom (Wed, 30 Aug 2017 05:34:15 GMT):
Has joined the channel.
drummondreed (Wed, 30 Aug 2017 09:00:25 GMT):
@jljordan_bcgov Yes, you are exactly right. In fact there's been a lot of discussion between the Sovrin and DIF communities about the two terms. "Identity Hubs" is more data-centric and static than "Agents", which does more to emphasis dynamic relationships and context. But yes, both terms basically describe the same thing: the endpoint that the DDO for a specific DID points to so you can interact with that identity owner.
guidol (Wed, 30 Aug 2017 13:29:35 GMT):
Has joined the channel.
Sean_Bohan (Tue, 05 Sep 2017 13:53:20 GMT):
indy-agent folks: We are working on the agenda for this week's call and would love to know what YOU want to discuss: topics, questions, explainers, deep dives, etc. Please let us know HERE in the chat and we will share with all in advance of the call
srottem (Tue, 05 Sep 2017 14:06:10 GMT):
I've become passingly familiar with the Anoncreds part of the SDK but I'm still completely unclear on how credential attributes are constructed (e.g. 'sex': ['male', '5944657099558967239210949258394887428692050081607692519917050011144233115103']). I'm told that the construction of the hex part of this value falls out of scope of the API but would like to get a handle on how construction of these values this would normally be approached since I assume I would need to know this in order to create an agent. Is this an appropriate subject for discussion?
gudkov (Tue, 05 Sep 2017 15:39:28 GMT):
For example In python:
```
'male'.to_hex()
```
gudkov (Tue, 05 Sep 2017 15:41:05 GMT):
For java something like:
```
import org.apache.commons.codec.binary.Hex;
String hexString = Hex.encodeHexString(myString.getBytes('utf-8'));
```
gudkov (Tue, 05 Sep 2017 15:41:55 GMT):
The only restriction is that all parties must be agreed on this hex encoding.
srottem (Tue, 05 Sep 2017 16:26:17 GMT):
Thanks Slava - I was assuming that there was more to it than that.
swcurran (Tue, 05 Sep 2017 17:42:05 GMT):
chr
SLafranca2017 (Tue, 05 Sep 2017 22:34:45 GMT):
Has joined the channel.
sklump (Wed, 06 Sep 2017 10:49:02 GMT):
Has joined the channel.
Sean_Bohan (Wed, 06 Sep 2017 17:02:29 GMT):
Hyperledger Indy Agents WG Call tomorrow 9/8
8amPT, 9amMT, 11amET, 4pm BST.
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
swcurran (Wed, 06 Sep 2017 23:34:33 GMT):
@Sean_Bohan - re: your request for Indy Agent topics. Would this work?
We've been working on the "Verified Organization" concept, and the delegation of authority around identity from an organization to the people that act on it's behalf. We're trying to wrap our heads around it with varying levels of success :-). Attached is a link to a use case that we've fleshed out that we would love to talk about.
https://docs.google.com/a/cloudcompass.ca/document/d/1my0_imeT-XMRi9hakRPKTauQt1Qfooce3IP4h5YYnvI/edit?usp=sharing
anttikettunen (Thu, 07 Sep 2017 08:15:31 GMT):
Hi all, has there been discussions yet on how Composer could be used with Indy?
anttikettunen (Thu, 07 Sep 2017 08:54:39 GMT):
And also, how agent to agent communication could relate to Fabric's channel concept. Could indy's pairwise connection provide basis of creation of "dynamic fabric channel". (just random thoughts)
sklump (Thu, 07 Sep 2017 14:52:37 GMT):
I am trying to get the `test/agent/test_general_use_case.py` test to run on the client node (container), to set a base working use case with a known agent, then I'm aiming to build my own agent based on it.
*`sovrin@85b6dc0db5b0:~$ pytest /usr/local/lib/python3.5/dist-packages/sovrin_client/test/agent/test_general_use_case.py`*
Any clue what I might be missing? Or is my approach entirely unworkable here? I would like to know what allowed this test ever to run, anywhere? Output follows:
```
method
sklump (Thu, 07 Sep 2017 14:52:37 GMT):
I am trying to get the `test/agent/test_general_use_case.py` test to run on the client node (container), to set a base working use case with a known agent, then I'm aiming to build my own agent based on it.
From account `sovrin`'s home directory, I issue:
`sovrin@85b6dc0db5b0:~$ pytest /usr/local/lib/python3.5/dist-packages/sovrin_client/test/agent/test_general_use_case.py`
Any clue what I might be missing? Or is my approach entirely unworkable here? I would like to know what allowed this test ever to run, anywhere? Output follows:
```
method
sklump (Thu, 07 Sep 2017 14:55:22 GMT):
(obviously, this can wait until after the call today)
nage (Thu, 07 Sep 2017 15:01:46 GMT):
@anttikettunen: I'm not aware of any new discussions on how Composer and Indy will be working together. But if they are at the next Hackfest, I will try to take it up with them again there.
nage (Thu, 07 Sep 2017 15:02:21 GMT):
If others are interested, we can talk about agents vs channels vs side-chain approaches (like Corda) today on the call
TelegramSam (Thu, 07 Sep 2017 15:03:31 GMT):
---start of meeting notes---
TelegramSam (Thu, 07 Sep 2017 15:03:43 GMT):
Antitrust Policy Notice
TelegramSam (Thu, 07 Sep 2017 15:03:57 GMT):
Meetings are now recorded.
TelegramSam (Thu, 07 Sep 2017 15:05:09 GMT):
Stephen Klump: Verified Organizations.
TelegramSam (Thu, 07 Sep 2017 15:05:56 GMT):
Indy SDK updates from Slava
TelegramSam (Thu, 07 Sep 2017 15:06:42 GMT):
Current work is focused on state proofs.
TelegramSam (Thu, 07 Sep 2017 15:07:06 GMT):
Also stability fixes.
nage (Thu, 07 Sep 2017 15:07:10 GMT):
Indy packages are now available! :woo:
nage (Thu, 07 Sep 2017 15:07:10 GMT):
Indy-sdk packages are now available! :woo:
TelegramSam (Thu, 07 Sep 2017 15:08:09 GMT):
new indy-crypto project provides c callable library
TelegramSam (Thu, 07 Sep 2017 15:11:02 GMT):
Working towards continuous integration on public infrastructure.
gudkov (Thu, 07 Sep 2017 15:12:43 GMT):
The first official release of indy-sdk.
Artifacts:
Libindy
* deb files for Ubuntu-based distributives (https://repo.evernym.com/libindy/ubuntu/stable/1.0.0/)
* zip-archive for windows (https://repo.evernym.com/libindy/windows/stable/1.0.0/)
Python wrapper
pip package python3-indy==1.0.0 (https://pypi.python.org/pypi/python3-indy/1.0.0)
Java wrapper
maven artifcat `indy` on Evernym repo:
```
TelegramSam (Thu, 07 Sep 2017 15:12:44 GMT):
More of the build pipeline will be open soon, for easier integration.
TelegramSam (Thu, 07 Sep 2017 15:12:58 GMT):
@gudkov thanks for the links!
TelegramSam (Thu, 07 Sep 2017 15:13:42 GMT):
@sklump now addressing verified organizations.
jljordan_bcgov (Thu, 07 Sep 2017 15:14:47 GMT):
actually its @swcurran ... we have two Stephens on the team :)
TelegramSam (Thu, 07 Sep 2017 15:15:19 GMT):
Apologies!
gudkov (Thu, 07 Sep 2017 15:17:27 GMT):
The link to Indy Crypto library https://github.com/hyperledger/indy-crypto
TelegramSam (Thu, 07 Sep 2017 15:17:29 GMT):
delegation of organization authority by employees or other related parties.
nage (Thu, 07 Sep 2017 15:35:02 GMT):
representing group membership with claim possession (claim saying I can sign on behalf of TacoTruck) makes a lot of sense
sklump (Thu, 07 Sep 2017 15:39:38 GMT):
Oh! Never mind:
`$ docker exec -u 0 -it sovrinclient bash`
`root@85b6dc0db5b0"# pip3.5 install pytest-xdist`
sklump (Thu, 07 Sep 2017 15:39:38 GMT):
Oh! I pytest-xdist extension advances the state to a satisfactory conclusion:
`$ docker exec -u 0 -it sovrinclient bash`
`root@85b6dc0db5b0:# pip3.5 install pytest-xdist`
sklump (Thu, 07 Sep 2017 15:46:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tpQaFXwarRTsdSvFh) @TelegramSam
sklump (Thu, 07 Sep 2017 15:46:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tpQaFXwarRTsdSvFh) @TelegramSam
It's Stephen Curran and John Jordan re: Verified Organizations, not directly myself
nage (Thu, 07 Sep 2017 15:46:22 GMT):
important insight: sometimes claims represent roles, sometimes permission slips and other information
sklump (Thu, 07 Sep 2017 15:46:45 GMT):
Its' Stephen Curran and John Jordan re: Verified Organizations, not directly myself
sklump (Thu, 07 Sep 2017 15:47:52 GMT):
@nage, a claim is any assertion. Any declarative statement can be cast as a claim if I understand correctly.
nage (Thu, 07 Sep 2017 15:48:14 GMT):
@sklump that is how I understand it
nage (Thu, 07 Sep 2017 15:48:35 GMT):
(just trying to capture some highlights as notes (while @TelegramSam is talking)
sklump (Thu, 07 Sep 2017 15:48:44 GMT):
(but the ontology of the terms can get fuzzy - hence schema and claim definitions -- but I am a little unclear where one stops and the other starts)
nage (Thu, 07 Sep 2017 15:49:07 GMT):
schemas declare "here are the fields and what I mean by each of them"
nage (Thu, 07 Sep 2017 15:49:30 GMT):
claims definitions declare "this identity is going to issue these using the following rules for issuance and revocation"
nage (Thu, 07 Sep 2017 15:49:30 GMT):
claims definitions declare "this identity is going to issue claims using this schema according to the following rules for issuance and revocation"
nage (Thu, 07 Sep 2017 15:49:30 GMT):
claims definitions declare "this identifier is going to issue claims using this schema according to the following rules for issuance and revocation"
sklump (Thu, 07 Sep 2017 15:51:16 GMT):
(e.g., a claim that this dragon is magical may not be operable)
nage (Thu, 07 Sep 2017 15:51:38 GMT):
we try to keep this relationship flexible so that identities can still say what they want (they preserve agency), and it is up to interacting parties to trust or not trust whether they accept that dragons are magical
nage (Thu, 07 Sep 2017 15:51:38 GMT):
we try to keep this relationship flexible so that identities can still say what they want (they preserve agency), and it is up to interacting parties to trust or not trust (whether they accept that this entity has the authority to say that dragons are magical)
mhailstone (Thu, 07 Sep 2017 16:02:04 GMT):
@TelegramSam I'd like to address the role discovery scenario you were speaking to. Instead of introducing role definitions, could we discover/read Agent services in terms of Swagger paths for what is possible to perform on the agent service and then the managing agent (the food truck) could verify that the individual has authorization to perform certain services on the Health Authority? Basically, use REST service definitions instead of roles.
mhailstone (Thu, 07 Sep 2017 16:05:46 GMT):
A Proof request on the Taco Agent could determine whether Bob is authorized to perform some action.
TelegramSam (Thu, 07 Sep 2017 16:08:14 GMT):
@mhailstone even more generically, each agent extension could designate it's own paths/permissions, and the permission slip claim can specify those specifially.
TelegramSam (Thu, 07 Sep 2017 16:24:02 GMT):
Taco Truck doc: https://docs.google.com/document/d/1my0_imeT-XMRi9hakRPKTauQt1Qfooce3IP4h5YYnvI/edit
jljordan_bcgov (Thu, 07 Sep 2017 16:24:22 GMT):
Here is the doc we discussion (and apologies for dominating the time) https://docs.google.com/document/d/1d5ywpeNATuDCQAUSIkI18o_JUAGLpCIDyD2RNtpmqSQ/edit?usp=sharing
jljordan_bcgov (Thu, 07 Sep 2017 16:24:36 GMT):
oops .. already posted
jljordan_bcgov (Thu, 07 Sep 2017 16:26:30 GMT):
Thanks everyone ... really appreciate the discussion and interaction. Have a great day!
TelegramSam (Thu, 07 Sep 2017 16:27:02 GMT):
Thanks!
nage (Thu, 07 Sep 2017 17:12:02 GMT):
The Agent WG meeting recording is available here https://drive.google.com/open?id=0B0ChWSmqhJemNXkzSFdvTTg5N0k
sklump (Fri, 08 Sep 2017 15:33:19 GMT):
Quick question, yes-or-no, before I pull the trigger. I have a sovrin client node running (with some modifications I want to keep for testing), and a node pool where at least one node did not come up. If I shut down and restart the (docker containers of the) node pool, am I going to lose the client container as well (as far as connectivity to the node pool is concerned)? Or are will the client node reset connections to the nodes on the pool?
sklump (Fri, 08 Sep 2017 15:33:19 GMT):
Quick question, yes-or-no, before I pull the trigger. I have a sovrin client node running (with some modifications I want to keep for testing), and a node pool where at least one node did not come up. If I shut down and restart the (docker containers of the) node pool, am I going to lose the client container as well (as far as connectivity to the node pool is concerned)? Or will the client node reset connections to the nodes on the pool?
sklump (Fri, 08 Sep 2017 15:33:19 GMT):
Quick question, yes-or-no, before I pull the trigger. I have a sovrin client node running (with some modifications I want to keep for testing), and a node pool where at least one node did not come up. If I shut down and restart the (docker containers of the) node pool, am I going to lose the client container as well (as far as connectivity to the node pool is concerned)? Or will the client node reset connections to the nodes in the pool?
sklump (Fri, 08 Sep 2017 16:53:16 GMT):
Hello,
I notice that in the Alice Garcia story, agents (faber, acme, thrift) have public (encryption) keys ('5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z', 'C5eqjU7NMVMGGfGfx2ubvX5H9X346bQt5qeziVAo3naQ', 'AGBjYvyM3SFnoiDGAEzkSLHvqyzVkXeMZfKDvdpEsC2x'). If I create a new agent, from a design point of view, are these public (encryption) keys attributes of the wallet or the agent itself? How do I query my new agent's public key?
Or are the public (encryption) key and the verification key actually the same key?
sklump (Fri, 08 Sep 2017 16:53:16 GMT):
Hello,
I notice that in the Alice Garcia story, agents (faber, acme, thrift) have public (encryption) keys ('5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z', 'C5eqjU7NMVMGGfGfx2ubvX5H9X346bQt5qeziVAo3naQ', 'AGBjYvyM3SFnoiDGAEzkSLHvqyzVkXeMZfKDvdpEsC2x'). If I create a new agent, from a design point of view, are these public (encryption) keys attributes of the wallet or the agent itself? How do I query my new agent's public key?
I created SIGNER = plenum.common.signer_did.DidSigner on the seed, then used sovrin_client.agent.helper.rawVerkeyToPubkey(SIGNER.verkey), and took the response from plenum.common.util.rawToFriendly() on the raw value to get 9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP,
but
```
sovrin@test> send ATTRIB dest=LTS6iRWf27cHXBDYoxiT3C raw={"endpoint": {"ha": "10
.0.0.6:5678", "pubkey": "9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP"}}
```
produces
```
Error: client request invalid: UnauthorizedClientRequest('Only identity owner/guardian can add attribute for that identity',)
```
suggesting that this is not the key I am looking for. In short, what is?
sklump (Fri, 08 Sep 2017 16:53:16 GMT):
Hello,
I notice that in the Alice Garcia story, agents (faber, acme, thrift) have public (encryption) keys ('5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z', 'C5eqjU7NMVMGGfGfx2ubvX5H9X346bQt5qeziVAo3naQ', 'AGBjYvyM3SFnoiDGAEzkSLHvqyzVkXeMZfKDvdpEsC2x'). If I create a new agent, from a design point of view, are these public (encryption) keys attributes of the wallet or the agent itself? How do I query my new agent's public key?
I created SIGNER = plenum.common.signer_did.DidSigner on the seed, then used sovrin_client.agent.helper.rawVerkeyToPubkey(SIGNER.verkey), and took the response from plenum.common.util.rawToFriendly() on the result to get 9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP,
but
```
sovrin@test> send ATTRIB dest=LTS6iRWf27cHXBDYoxiT3C raw={"endpoint": {"ha": "10
.0.0.6:5678", "pubkey": "9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP"}}
```
produces
```
Error: client request invalid: UnauthorizedClientRequest('Only identity owner/guardian can add attribute for that identity',)
```
suggesting that this is not the key I am looking for. In short, what is?
swcurran (Fri, 08 Sep 2017 17:33:16 GMT):
Question: To initiate an interaction between two identities (e.g. Alice and Faber), a user might click a link on the web site of the other (or scan a QR code). What are the expected attributes of the that link? I'm assuming it is a URL of a type that will invoke the (Alice's) Client. For establishing a connection, I assume it’s the DID of the identity (e.g. Faber), but is there any documentation about other ways it might be used - e.g. to trigger a proof request/response interaction? Is that documented anywhere?
swcurran (Fri, 08 Sep 2017 17:33:16 GMT):
Question: To initiate an interaction between two identities (e.g. Alice and Faber), a user might click a link on the web site of the other (or scan a QR code). What are the expected attributes of the that link? I'm assuming it is a URL of a type that will invoke the (Alice's) Client. For establishing a connection, I assume it’s the DID of the identity (e.g. Faber), but is there any documentation about other ways it might be used - e.g. to trigger a proof request/response interaction?
swcurran (Fri, 08 Sep 2017 17:33:16 GMT):
Question: To initiate an interaction between two identities (e.g. Alice and Faber), a user might click a link on the web site of the other (or scan a QR code). What are the expected attributes of the that link? I'm assuming it is a URL of a type that will invoke the (Alice's) Client. For establishing a connection, I assume it’s the DID of the identity (e.g. Faber), but is there any documentation/details about other ways it might be used - e.g. to trigger a proof request/response interaction?
sklump (Fri, 08 Sep 2017 18:02:03 GMT):
`sovrin@test> send ATTRIB dest=LTS6iRWf27cHXBDYoxiT3C raw={"endpoint": {"ha": "10
.0.0.6:5678", "pubkey": "9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP"}}`
returns
`Error: client request invalid: UnauthorizedClientRequest('Only identity owner/guardian can add attribute for that identity',)`, suggesting that this is not the key I am looking for. What is?
sklump (Fri, 08 Sep 2017 18:04:10 GMT):
```
sovrin@test> send ATTRIB dest=LTS6iRWf27cHXBDYoxiT3C raw={"endpoint": {"ha": "10
.0.0.6:5678", "pubkey": "9YwBeAjULnQknKZRaoXMGsE4gHNtm6LQcgcM98BesCP"}}
```
produces
```
Error: client request invalid: UnauthorizedClientRequest('Only identity owner/guardian can add attribute for that identity',)
```
suggesting that this is not the key I am looking for. In short, what is?
mgbailey (Fri, 08 Sep 2017 23:16:01 GMT):
@sklump , to send the ATTRIB you must be the trust anchor associated with the agent. So, in the CLI, you should first establish your identity: "use DID xxxxx", where xxxxx is the DID of the trust anchor. Then you can send ATTRIB
mgbailey (Fri, 08 Sep 2017 23:25:01 GMT):
@swcurran , typically an invitation to connect will contain at least an identifier of an agent and a nonce. Using the identifier, the client will be able to get the public key, the IP address, and the port that the agent communicates on, so it will be able to connect to the agent and establish secure communications. It can then pass the nonce that was provided in the invitation to the agent. The agent could use this nonce for context, and begin communications with the client, providing a claim, requesting a proof, etc.
sklump (Sat, 09 Sep 2017 13:51:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=4u6WFYG4Gqy9Jcxwc) @mgbailey I'm not on that environment again until Monday, but I'm pretty sure I already have done this part. I will ping you Monday, thanks for the reply.
swcurran (Mon, 11 Sep 2017 15:17:01 GMT):
@mgbailey - thanks, that helps. I saw reference to that in the Alice story and figured that was one way to handle it.
sklump (Tue, 12 Sep 2017 14:56:15 GMT):
Hello - I'm trying to build an agent to work into the Alice story. Is anyone familiar enough with the agent code to know how to query an agent for its public (encryption) key -- the one that gets written to {name}/public_keys/{name}.key, z85-encoded?
srottem (Tue, 12 Sep 2017 15:45:32 GMT):
I think the idea is that when calling the indy_agent_connect method the 'receiver_did' parameter will be used to look up the values from the open wallet specified by the 'wallet_handle' parameter. If the keys aren't there then they will automatically be looked up from the ledger in the open node pool specified by the 'pool_handle' parameter and the obtained information will be stored in the wallet.
sklump (Tue, 12 Sep 2017 15:47:47 GMT):
Sure, great, but the endpoint has to end up on the distributed ledger in the first place, with address (known) and public key (magic value). Without the public key, I don't see how it is possible to bootstrap the agent in the first place.
sklump (Tue, 12 Sep 2017 15:48:14 GMT):
e.g., send ATTRIB dest=LTS6iRWf27cHXBDYoxiT3C raw={"endpoint": {"ha": "10.0.0.6:5678", "pubkey": "9xtJXKsGpJQRDDTM3K7SCjuQtWGEBDruzcWvDPSZtKxH"}}
srottem (Tue, 12 Sep 2017 15:48:50 GMT):
Oh, OK. Are you using the Rust C-Callable API or one of the wrappers?
sklump (Tue, 12 Sep 2017 15:50:02 GMT):
At present I'm in the guts of the code that deploys to the docker sovrin environment. Ultimately I suppose I will be using the python wrapper.
sklump (Tue, 12 Sep 2017 15:50:41 GMT):
I haven't got that to pass its anoncreds unit tests since v1.0.0 dropped, and am punting on that for the moment
sklump (Tue, 12 Sep 2017 15:50:52 GMT):
(it's probably something I did)
srottem (Tue, 12 Sep 2017 15:56:03 GMT):
I've got no expertise on the python side, but in the Java and .NET wrappers there are some demo tests that do a pretty good job of explaining the steps - see AgentDemoTest in the test project of the Java project. In the meantime I can probably outline it; indy_create_and_store_my_did can be used to create a new DID into a wallet. The DID then needs to be recorded to the ledger using a NYM request - the request can be constructed using the indy_build_nym_request function and then submitted to the ledger using the indy_sign_and_submit_request. After that the DDO needs to be recorded tot he ledger which can be done using an ATTRIB request which can be built using the indy_build_attrib_request and then is also submitted to the ledger indy_sign_and_submit_request.
srottem (Tue, 12 Sep 2017 15:56:30 GMT):
Hopefully I've got this right - I'm a contributor, not one of the core team so I could be off base. :)
sklump (Tue, 12 Sep 2017 16:17:04 GMT):
Thanks a million, I will look into this first thing this afternoon. Step 1, get the indy-sdk back up and running.
sklump (Tue, 12 Sep 2017 18:30:29 GMT):
PS - I've found my immediate error -- I had been using the `verkey` instead of the `full_verkey` attribute of `DidSigner`. A five-liner to get the public key from the seed follows:
```
from sovrin_client.agent.helper import friendlyVerkeyToPubkey
seed = b'seed0000000000000000000000000000'
signer = DidSigner(seed=seed)
full_verkey = signer.full_verkey
print("Derived public base58-encoded key is [{}]".format(friendlyVerkeyToPubkey(full_verkey)))
```
Audrius (Wed, 13 Sep 2017 19:33:53 GMT):
Has joined the channel.
Suedonym (Wed, 20 Sep 2017 21:25:14 GMT):
Hyperledger Indy Agents WG Call tomorrow 9/21
8amPT, 9amMT, 11amET, 4pm BST.
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Suedonym (Wed, 20 Sep 2017 21:27:59 GMT):
We are working on the agenda and would love to know what YOU want to discuss: topics, questions, explainers, deep dives, etc. Please let us know here in the chat. All are welcome!
TelegramSam (Thu, 21 Sep 2017 15:01:36 GMT):
Start Meeting Notes
TelegramSam (Thu, 21 Sep 2017 15:01:54 GMT):
Nathan George is at the hackfest, so Sean is running the meeting.
Suedonym (Thu, 21 Sep 2017 15:02:57 GMT):
http://events.linuxfoundation.org/events/blockchain-for-good-hackathon
TelegramSam (Thu, 21 Sep 2017 15:05:49 GMT):
Review by Alex and Slava
TelegramSam (Thu, 21 Sep 2017 15:06:13 GMT):
Sprint focus on signatures and state proofs.
TelegramSam (Thu, 21 Sep 2017 15:06:31 GMT):
(if I miss something, anybody jump and and fill the gap...)
TelegramSam (Thu, 21 Sep 2017 15:11:10 GMT):
Renaming to Indy (from Sovrin) Involves folder changes in the repos.
Sean_Bohan (Thu, 21 Sep 2017 15:12:33 GMT):
I will add notes from the recording
Sean_Bohan (Thu, 21 Sep 2017 15:12:35 GMT):
too
TelegramSam (Thu, 21 Sep 2017 15:13:59 GMT):
Organization and updates also allow for more flexibility in the future.
TelegramSam (Thu, 21 Sep 2017 15:16:28 GMT):
Stephen Curran/John Jordan on agent work:
TelegramSam (Thu, 21 Sep 2017 15:16:42 GMT):
- bootstrapping an identity system in BC
TelegramSam (Thu, 21 Sep 2017 15:17:35 GMT):
- Orgbook contains claims that are publically available for those without agents.
jljordan_bcgov (Thu, 21 Sep 2017 15:17:43 GMT):
We are initially focused on legal entities .. ie businesses and other organizations
Here is our working doc with the terms, architecture and scenario
https://docs.google.com/document/d/1wNnXdQKUtWnx--xw3VQ9Fr2TDa0kUNIBSMmFGR4uoMg/edit
jljordan_bcgov (Thu, 21 Sep 2017 15:17:43 GMT):
We are initially focuses on legal entites .. ie businesses and other organizations
Here is our working doc with the terms, architecture and scenario
https://docs.google.com/document/d/1wNnXdQKUtWnx--xw3VQ9Fr2TDa0kUNIBSMmFGR4uoMg/edit
TelegramSam (Thu, 21 Sep 2017 15:18:00 GMT):
Thanks @jljordan_bcgov
jljordan_bcgov (Thu, 21 Sep 2017 15:23:21 GMT):
Message Attachments
TelegramSam (Thu, 21 Sep 2017 15:23:21 GMT):
- Allows use and demonstration of the value of verifiable claims without having to get everybody on board.
TelegramSam (Thu, 21 Sep 2017 15:26:28 GMT):
Quebec is also collaborating on the bootstrapped claimed store.
jljordan_bcgov (Thu, 21 Sep 2017 15:27:00 GMT):
It's actually the Government of Canada that @sklump and team are working within
jljordan_bcgov (Thu, 21 Sep 2017 15:27:10 GMT):
We are collaboration as per the diagram above
TelegramSam (Thu, 21 Sep 2017 15:30:36 GMT):
Sean wants everybody to feel welcome in sharing their work in the community.
TelegramSam (Thu, 21 Sep 2017 15:33:35 GMT):
Open call for opinions on DID-Auth
darrell.odonnell (Thu, 21 Sep 2017 15:34:51 GMT):
community agreement at RWoT that DID-Auth is a great idea (my note: let's upgrade that to awesome)
darrell.odonnell (Thu, 21 Sep 2017 15:36:04 GMT):
DIF: DID-Auth agreement. DIF Agent working group - terminology (Agent called Hub) - solely focuses on http though.
darrell.odonnell (Thu, 21 Sep 2017 15:36:04 GMT):
DIF: DID-Auth agreement that the idea is great. DIF Agent working group - terminology (Agent called Hub) - solely focuses on http though.
TelegramSam (Thu, 21 Sep 2017 15:39:52 GMT):
End Live Meeting Notes
TelegramSam (Thu, 21 Sep 2017 15:40:17 GMT):
Thanks @Sean_Bohan !
Suedonym (Thu, 21 Sep 2017 16:58:22 GMT):
Unfortunately, the recording of today's meeting is too large to post here. You can find the link in the Sovrin Slack #sovrin-architecture channel.
TelegramSam (Thu, 21 Sep 2017 17:31:33 GMT):
@Suedonym Next time we'll use smaller words. ;)
Captain63Dragon (Thu, 21 Sep 2017 18:26:37 GMT):
Thanks for posting the recording. Gave it a listen and now know more about these calls. Thanks also for the notes @TelegramSam
stanliberman (Thu, 21 Sep 2017 20:02:40 GMT):
Has joined the channel.
darkcrux (Fri, 22 Sep 2017 19:53:03 GMT):
Has joined the channel.
tkuhrt (Thu, 28 Sep 2017 10:57:35 GMT):
@Suedonym : We can place the recording on the Google Drive that I have set up to hold Hyperledger Indy working group calls. DM me, and I will get you access.
farskipper (Fri, 29 Sep 2017 17:17:29 GMT):
Has joined the channel.
Artemkaaas (Sat, 30 Sep 2017 09:05:16 GMT):
Has joined the channel.
andkononykhin (Sat, 30 Sep 2017 11:54:31 GMT):
Has joined the channel.
mzk-vct (Sun, 01 Oct 2017 12:16:07 GMT):
Has joined the channel.
bryanhuang (Wed, 04 Oct 2017 02:40:16 GMT):
Has joined the channel.
cre8bidio (Wed, 04 Oct 2017 14:18:19 GMT):
Has joined the channel.
Sean_Bohan (Thu, 05 Oct 2017 14:48:34 GMT):
Hyperledger Indy Agents WG Call TODAY
8amPT, 9amMT, 11amET, 4pm BST.
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Sean_Bohan (Thu, 05 Oct 2017 15:01:52 GMT):
Nathan: AntiTrust policy noticed shared
Sean_Bohan (Thu, 05 Oct 2017 15:02:26 GMT):
Welcome to the 10/05/17 Hyperledger Indy AGENTS Call
Sean_Bohan (Thu, 05 Oct 2017 15:03:26 GMT):
Nathan:
Sean_Bohan (Thu, 05 Oct 2017 15:03:45 GMT):
Internal document to deal with priorities for pushing community forward
See what we are thinking and going
Sean_Bohan (Thu, 05 Oct 2017 15:03:53 GMT):
Indy Team Priorities Doc
Sean_Bohan (Thu, 05 Oct 2017 15:04:45 GMT):
Prerequisites - graduating from Incubation
bootstrapping secondary agent protocols
Ledger monitoring work (NodeWG)
Verifiable claims DID support and revocation
Item - showing up - token work
Sean_Bohan (Thu, 05 Oct 2017 15:04:55 GMT):
will discuss Token work at end of call
Sean_Bohan (Thu, 05 Oct 2017 15:05:06 GMT):
Agent to Agent communications
Sean_Bohan (Thu, 05 Oct 2017 15:05:25 GMT):
Questions? Pls post in rocketchat channel #indy-agent
Sean_Bohan (Thu, 05 Oct 2017 15:06:23 GMT):
Alex:
Last 2 weeks, next two weeks
finished implement of state proofs and bls sig support
Sean_Bohan (Thu, 05 Oct 2017 15:06:30 GMT):
code in Master and Indy SDK and Py CLI
Sean_Bohan (Thu, 05 Oct 2017 15:07:23 GMT):
work in testing (QA)
also 1 more thing related to this - going to introduce a concept of prootocol version for Indy Node and for client to Node communication
required for backwards compatibility
expect changes / evolution in how we send data requests, structure - need to have a way to support quite old clients with new nodes
Sean_Bohan (Thu, 05 Oct 2017 15:07:57 GMT):
some kind of backwards compatibility
if client is old, and sends outdated format, latest pool should understand and reply with JSON
protocol version
work in progress, supported in INDY SDK
Sean_Bohan (Thu, 05 Oct 2017 15:09:40 GMT):
Why? new state proof feature
to be back-compatible with old clients that dont support state proof, so old clients can get replies from pool and new clients can use power of state proofs and mutli-sig
as for other things on node side - working on incubation task
finished rebranding, all code use correct INDY branding instead of SOvrin
CI and CD parts of pipelines are split, what is left, is to integrate CI into Hyperledger infrastructure
so any PR someone sends are public for all
another task - related to incubation
file folder refactoring
Sean_Bohan (Thu, 05 Oct 2017 15:10:05 GMT):
write data (ledger, state) not in Home but in LibIndy (better for services running on ubuntu)
Sean_Bohan (Thu, 05 Oct 2017 15:11:01 GMT):
related tasks, factoring of config files, as of now config can be messy, would like to make correspondent changes
in this sprint will be able to finish bug fixing related tasks, main goal, release candidate have a portion of incubation tasks and state proofs for next stable release
Sean_Bohan (Thu, 05 Oct 2017 15:11:06 GMT):
Nathan - any questions for Alex?
Sean_Bohan (Thu, 05 Oct 2017 15:11:38 GMT):
differences in how the nodes work, if you dont und the context, please ask
Sean_Bohan (Thu, 05 Oct 2017 15:13:07 GMT):
Darrell - verbal with no visual issue
Nathan
when we have demos, we do somethign with a visual or slide with how the new change works
status updates - haven't gone that far
Darrel - amazing memories, without looking at notes
Nathan - Jira.hyperledger.org, Active Sprint, tickets in there, more context
Sean_Bohan (Thu, 05 Oct 2017 15:14:33 GMT):
SteveT - maybe during status updates, if issues are in a sprint, share a screen and highlight tickets?
Nathan - seems like a good idea
Alex - demos for ledger workig group at end of sprint - chance to show some demos
Sean_Bohan (Thu, 05 Oct 2017 15:16:05 GMT):
Slava:
Goals - state proofs in Indy SDK
done and merged to Master
versions of node protocol in a couple of days, finish until the end of the sprint
implemented bug fixes in anon creds
for now - better crypto and performance also bette
Sean_Bohan (Thu, 05 Oct 2017 15:16:45 GMT):
easier to perform key rotation
improved pipeline
implemented few helpers in Indy SDK with workflow
storing wallet info for Pairwise connections
set meta data to pairwise connections
Sean_Bohan (Thu, 05 Oct 2017 15:18:03 GMT):
daemon related to funct. at end of Sprint
New approach to Agent-to-Agent comms
can't shaare details right now as active dev and design, final vision in discussion
approach in SKD, most probably in the next sprint
also working on incubation tasks, plan to move outside pipelines to HL infrastructure and hope to finish end of sprint
Sean_Bohan (Thu, 05 Oct 2017 15:18:32 GMT):
Questions?
Sean_Bohan (Thu, 05 Oct 2017 15:19:37 GMT):
Nathan:
All items discusse dwere in active sprint for LibIndy
Alex talked about things in active sprint that are in the core of Indy
please take a look, a lot of tickets could use your help
Commit some code to INDY!
Sean_Bohan (Thu, 05 Oct 2017 15:20:34 GMT):
More interesting developments in the standards space and future work
Slava mentioned Agent-Agent communication design work
Answe questions about that - chance for Slava or Devin to discuss motivation or goals
what or why adding API for agent-to-agent comms
Sean_Bohan (Thu, 05 Oct 2017 15:22:04 GMT):
Devin:
For us at Evernym looking to standing up actual agents, Agent WG implementing them, looking and wanting to make sure control remains with the identity owner and keys need to stay on devices they control and agents act on the users behalf
looking at how we could have keys remain out on the edge and not an agents-side, the design and discussion to modify design so agent worked on behalf of ID owner without holding the keys
Sean_Bohan (Thu, 05 Oct 2017 15:23:56 GMT):
want to make sure the self sovereignty of an ID on Sovrin remains, but provide funct. on surface they get value from it
Alice needs to own and control the keys, Bob has a similar need, have keys to know agents are authorized by their owners, auth continues to be up to date and valid (Alice revokes access by agent use case) - needs to be some auth of that agent
Accomplished thorugh intermediate or signed key (TLS world) also working on a channel where agent can act on behalf of owner without sacrificing exclusive control over keys
Sean_Bohan (Thu, 05 Oct 2017 15:25:39 GMT):
CURVEZMQ not providing additional features or credential handshaek
moving forward - ideas around how it might be better with some advanced use of TLS and stuff, building it into the actual message
CurveZMQ becomes transport
HTTP is a more common transport
Not sure we have a good diagram for showing that message wrap-protocol
Nathan - we dont, in 2 weeks with next Agent WG call, Slava can be on the call and describe the over the wire protocol and describe how it works
Matthew H
Sean_Bohan (Thu, 05 Oct 2017 15:26:51 GMT):
looking at diagram was helpful
wallet or client, interaction of agent services, inside client is wallet
agent then, must use some other service and interaction to say "yup, valid agent of ID owner, interaction of protocol" - client has own interaction with the ledger, agent also has the ledger client - thats the other the interaction th agent has with ledger as well
Sean_Bohan (Thu, 05 Oct 2017 15:28:50 GMT):
Nathan - both client and agent can interact with ledger to prove claims and proofs of the parties hasnt been revoked (owned by Alice, her Agent, associated by those keys)
Agent doesnt have to gain access to keys in all cases, if Alice has signed a proof that says "trust my agent" then bobs agent should rely on that proof that came from Alice
DanielH - similar to UMA2.0 in a diff way - auth check in the form of a claim rather than a token, claim still valid, etc. Dont have to have direct interaction with ID owners client in all cases if claim is still valid and claim is checked on the ledger
Sean_Bohan (Thu, 05 Oct 2017 15:28:50 GMT):
Nathan - both client and agent can interact with ledger to prove claims and proofs of the parties hasnt been revoked (owned by Alice, her Agent, associated by those keys)
Agent doesnt have to gain access to keys in all cases, if Alice has signed a proof that says "trust my agent" then bobs agent should rely on that proof that came from Alice
Nathan - similar to UMA2.0 in a diff way - auth check in the form of a claim rather than a token, claim still valid, etc. Dont have to have direct interaction with ID owners client in all cases if claim is still valid and claim is checked on the ledger
Sean_Bohan (Thu, 05 Oct 2017 15:28:56 GMT):
Nathan - correct
Sean_Bohan (Thu, 05 Oct 2017 15:31:16 GMT):
SamC - understand presenting proof across the wire
What mechanism are in play to prevent replays of those creds? what types of binding or other things in play? fall back to same handshake a la nonce-signing?
Nathan - way anoncreds is built, create nonces for protocol, use them for blinding of secrets involved, prevent replay attack
in particular, need ot be careful - not a strong binding to comms channel, protocol could be across multiple, some things you might consider (cookie hijacking, packacge injection)
if anyone wants to help with investigating shape of that protocol please let us know
Sean_Bohan (Thu, 05 Oct 2017 15:32:47 GMT):
not using transport player to bind credentials
Nathan - indy anoncreds doc folder, 3-4 papers describe it, details are in there but not easy to parse or understand, Nathan can connect anyone with questions with someone who can get up to speed
no API-level description of documentation
SamC - running into similar issues making DID Auth a thing
not just Agent-Agent - but generic auth
ashcherbakov (Thu, 05 Oct 2017 15:33:18 GMT):
Anoncreds sequence diagram:
http://www.plantuml.com/plantuml/svg/jLPjRzis4FwkNt58Fgm5qZWlwxOQiORKSJi13YguhVnXA0HAecqYakYGj1q3-V4xlaYMOjbRMoo01OMyU-xkkUT8oGTMBeaW1OH4A9Qo9IbLIBACbNEukl1alV-UFpNMFSLKJc7C4bPcMo0bBrD1C-d9bE3wnVaxp_CI_WGdWPGhAaxWTCpc2_K-Nr5lkGi59rEIvrJH32f38Y6OUYHLNBWri-JHCaD0XneAlaPZPsR_qsRX0N1dRqocDPJrZgXWCsRz8wyDCARPtFcDiQAIAmecLZ0zWp6SRXPCKG_mBoDoWO6847mZ-q1WJR1Mc0bUW4M1WcmXeP2IL5k-OYLiJ7v_lZO8DucVy3m3HP_KJI_n-pjQ8NT4tuO1-kUvTPXnp37bEHS3jFBnrx_fwKKVMAceA4cEsqMnAbbA5ECOaAc5Yuefq1BRkDt3cWjAIzyyQpovIWgcUdEgGF6UgKhIT2MeGzi3IR1wNp-EGLXYZ6-Ia_IX_oBTXAeDPk5qqBDTx5KDytGZTKkmCuF108Q24kpFC2UiW3iwOoKpA8E15y0R7tlMroHVdeFcCcO6D4wDLqpAB9Oe1ngdsZ_EwCmBfl3cxrD3n3VhRYpWWMwbsSH5XAmTpg1-ZLShblcU5o20Pk6RFqPlp1U6uzlWFhuRVG3rL7hZUhz6WgnENVuYqUanBhc6QjHmvMgmvCVI_BHTFECYDjBho7wrp3H1TP8EkyNUXAwvOtz2vqmgiTK4jg9V_mk3GcFWSzwHWsv_pLyNkSOPAcVBS0ru1lNhOOOde-ZJC9wCFdOmNBiVOlRNds4MqPS6lOlPUo9n9lNO2EH0SnhgkA6D-_RSX5qQYLUK5iObjYvUs0eRremLJM0RyhDHcb7JfzaCDrqBDHKuPzhTaMKbnxLHAn_upH7XCchEXhC-a4u3KRfi5dpJp4OYCdmDzZZulSK1AgKPJtO4r69gXGkDPC9wAEsoxw9WXZeJheFRp2RqSKMbmfFMNK0sJQbJ2w5I3lfMsleu-XBl9bZGHs_SD0ixXjXl5_b7LwDVdZuQkBlSThEFzg16QJA2QpQXdHI2bXI4fQGz5Uyw9zuuVD-Cwwsk2TyDaDtoprp2VgrRFSAmD-Fnr_3kzil8ZFfXWRTRS7bnVa3QHpLMCNEKz9UAbrPkJb2x52xRurMB_QZCzmH-HDgXe5Y_SdEdE5ndvYDl2wym9fzLvRpMKnXrCTSoyvwVdziLN7LFgpG7fV7j4g04t6v3TzPGBz6SfbNvnbSjgFMlKkgUqi_3lqRtjzqZAl4Bh23-pusula6FGEnkeKw8-YBozvczxZeYRCb7nD5WsjZwJNviPwDcPyrszBtqHGtweX-WBshJ5_q0VT4-VH6uTMIlki7NxZFHlcmTWUxON_E7vbdV-ZvyspxiX37-Nm-x_tp4_GC0
https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.puml
mhailstone (Thu, 05 Oct 2017 15:33:18 GMT):
Can we get a link to the documentation Nathan is talking about?
Sean_Bohan (Thu, 05 Oct 2017 15:33:20 GMT):
Nathan - may be additions with token binding, binding transport layer to token, b/c you have strong binding with identifier or DID itself, we need to know the shape of that
Sean_Bohan (Thu, 05 Oct 2017 15:34:27 GMT):
will put the link here Matthew
Sean_Bohan (Thu, 05 Oct 2017 15:34:30 GMT):
when i get it
mhailstone (Thu, 05 Oct 2017 15:34:50 GMT):
Thank you @Sean_Bohan
ashcherbakov (Thu, 05 Oct 2017 15:35:19 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.puml
Sean_Bohan (Thu, 05 Oct 2017 15:36:05 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:37:18 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:38:14 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:38:45 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:41:06 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:42:14 GMT): swcurran (Thu, 05 Oct 2017 15:42:24 GMT): swcurran (Thu, 05 Oct 2017 15:42:24 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:42:42 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:43:56 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:45:17 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:48:44 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:49:40 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:50:51 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:51:50 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:54:23 GMT): mhailstone (Thu, 05 Oct 2017 15:56:51 GMT): mhailstone (Thu, 05 Oct 2017 15:56:54 GMT): Sean_Bohan (Thu, 05 Oct 2017 15:56:58 GMT): Sean_Bohan (Thu, 05 Oct 2017 16:00:20 GMT): Sean_Bohan (Thu, 05 Oct 2017 16:04:48 GMT): Raffael 5 (Tue, 10 Oct 2017 15:07:04 GMT): FranciscoReyes (Wed, 11 Oct 2017 12:39:09 GMT): drummondreed (Thu, 12 Oct 2017 02:59:01 GMT): Paratus (Thu, 12 Oct 2017 05:44:31 GMT): brycecurtis (Fri, 13 Oct 2017 17:40:52 GMT): anttikettunen (Tue, 17 Oct 2017 08:56:05 GMT): srottem (Tue, 17 Oct 2017 09:24:19 GMT): srottem (Tue, 17 Oct 2017 09:26:09 GMT): anttikettunen (Tue, 17 Oct 2017 11:38:40 GMT): bhurley (Wed, 18 Oct 2017 12:39:48 GMT): alain2sf (Thu, 19 Oct 2017 06:17:33 GMT): nage (Thu, 19 Oct 2017 07:02:47 GMT): Sean_Bohan (Thu, 19 Oct 2017 14:18:02 GMT): ashcherbakov (Thu, 19 Oct 2017 15:05:01 GMT): codenamedmitri (Tue, 24 Oct 2017 18:02:06 GMT): ChristianSmith (Tue, 24 Oct 2017 18:08:56 GMT): nbrempel (Tue, 24 Oct 2017 20:46:27 GMT): apoikola (Sun, 29 Oct 2017 19:38:38 GMT): ashcherbakov (Mon, 30 Oct 2017 08:00:18 GMT): schristie (Mon, 30 Oct 2017 18:17:06 GMT): Sean_Bohan (Thu, 02 Nov 2017 14:07:48 GMT): TelegramSam (Thu, 02 Nov 2017 15:03:45 GMT): TelegramSam (Thu, 02 Nov 2017 15:03:54 GMT): TelegramSam (Thu, 02 Nov 2017 15:05:53 GMT): TelegramSam (Thu, 02 Nov 2017 15:06:04 GMT): TelegramSam (Thu, 02 Nov 2017 15:06:10 GMT): TelegramSam (Thu, 02 Nov 2017 15:07:21 GMT): Suedonym (Thu, 02 Nov 2017 15:07:35 GMT): TelegramSam (Thu, 02 Nov 2017 15:07:56 GMT): TelegramSam (Thu, 02 Nov 2017 15:08:59 GMT): TelegramSam (Thu, 02 Nov 2017 15:09:47 GMT): TelegramSam (Thu, 02 Nov 2017 15:11:02 GMT): TelegramSam (Thu, 02 Nov 2017 15:11:32 GMT): ashcherbakov (Thu, 02 Nov 2017 15:11:33 GMT): ashcherbakov (Thu, 02 Nov 2017 15:11:40 GMT): ashcherbakov (Thu, 02 Nov 2017 15:11:44 GMT): nage (Thu, 02 Nov 2017 15:12:35 GMT): TelegramSam (Thu, 02 Nov 2017 15:15:02 GMT): TelegramSam (Thu, 02 Nov 2017 15:15:16 GMT): nage (Thu, 02 Nov 2017 15:15:48 GMT): TelegramSam (Thu, 02 Nov 2017 15:17:19 GMT): TelegramSam (Thu, 02 Nov 2017 15:17:46 GMT): TelegramSam (Thu, 02 Nov 2017 15:17:55 GMT): TelegramSam (Thu, 02 Nov 2017 15:21:48 GMT): TelegramSam (Thu, 02 Nov 2017 15:24:04 GMT): ashcherbakov (Thu, 02 Nov 2017 15:24:29 GMT): nage (Thu, 02 Nov 2017 15:25:09 GMT): nage (Thu, 02 Nov 2017 15:25:31 GMT): Suedonym (Thu, 02 Nov 2017 15:25:49 GMT): nage (Thu, 02 Nov 2017 15:25:54 GMT): nage (Thu, 02 Nov 2017 15:26:21 GMT): nage (Thu, 02 Nov 2017 15:26:30 GMT): nage (Thu, 02 Nov 2017 15:26:56 GMT): nage (Thu, 02 Nov 2017 15:27:11 GMT): nage (Thu, 02 Nov 2017 15:28:11 GMT): nage (Thu, 02 Nov 2017 15:33:12 GMT): nage (Thu, 02 Nov 2017 15:34:27 GMT): nage (Thu, 02 Nov 2017 15:34:48 GMT): nage (Thu, 02 Nov 2017 15:34:57 GMT): nage (Thu, 02 Nov 2017 15:35:11 GMT): nage (Thu, 02 Nov 2017 15:35:23 GMT): nage (Thu, 02 Nov 2017 15:35:46 GMT): nage (Thu, 02 Nov 2017 15:36:13 GMT): nage (Thu, 02 Nov 2017 15:36:29 GMT): nage (Thu, 02 Nov 2017 15:36:42 GMT): nage (Thu, 02 Nov 2017 15:37:07 GMT): nage (Thu, 02 Nov 2017 15:37:31 GMT): nage (Thu, 02 Nov 2017 15:37:41 GMT): nage (Thu, 02 Nov 2017 15:37:57 GMT): nage (Thu, 02 Nov 2017 15:39:50 GMT): nage (Thu, 02 Nov 2017 15:40:07 GMT): nage (Thu, 02 Nov 2017 15:40:20 GMT): nage (Thu, 02 Nov 2017 15:40:39 GMT): nage (Thu, 02 Nov 2017 15:40:57 GMT): nage (Thu, 02 Nov 2017 15:41:33 GMT): nage (Thu, 02 Nov 2017 15:41:49 GMT): nage (Thu, 02 Nov 2017 15:42:01 GMT): nage (Thu, 02 Nov 2017 15:42:14 GMT): nage (Thu, 02 Nov 2017 15:42:22 GMT): nage (Thu, 02 Nov 2017 15:42:29 GMT): nage (Thu, 02 Nov 2017 15:43:13 GMT): nage (Thu, 02 Nov 2017 15:43:34 GMT): Sean_Bohan (Thu, 02 Nov 2017 16:02:25 GMT): srottem (Thu, 02 Nov 2017 16:03:45 GMT): Suedonym (Thu, 02 Nov 2017 16:16:05 GMT): swcurran (Thu, 02 Nov 2017 16:46:24 GMT): Sean_Bohan (Thu, 02 Nov 2017 17:01:31 GMT): Sean_Bohan (Thu, 02 Nov 2017 17:06:39 GMT): srottem (Thu, 02 Nov 2017 17:07:08 GMT): Sean_Bohan (Thu, 02 Nov 2017 17:14:47 GMT): peacekeeper (Thu, 02 Nov 2017 20:13:57 GMT): peacekeeper (Thu, 02 Nov 2017 20:14:38 GMT): CabMorris14 (Sun, 05 Nov 2017 21:13:18 GMT): nage (Tue, 07 Nov 2017 18:09:22 GMT): swlcanderson (Fri, 10 Nov 2017 21:21:07 GMT): sreekanthn (Sun, 12 Nov 2017 02:55:41 GMT): sreekanthn (Sun, 12 Nov 2017 02:57:44 GMT): sreekanthn (Sun, 12 Nov 2017 03:01:04 GMT): mgbailey (Mon, 13 Nov 2017 16:22:31 GMT): Sean_Bohan (Mon, 13 Nov 2017 18:54:03 GMT): sreekanthn (Mon, 13 Nov 2017 22:45:40 GMT): sreekanthn (Tue, 14 Nov 2017 00:28:04 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:01:22 GMT): ashcherbakov (Thu, 16 Nov 2017 16:08:16 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:19:49 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:20:23 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:21:13 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:22:57 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:23:18 GMT): nage (Thu, 16 Nov 2017 16:24:24 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:25:13 GMT): nage (Thu, 16 Nov 2017 16:25:27 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:25:44 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:26:12 GMT): nage (Thu, 16 Nov 2017 16:26:32 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:27:26 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:28:34 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:28:39 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:29:29 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:33:37 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:34:03 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:35:09 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:35:24 GMT): nage (Thu, 16 Nov 2017 16:36:56 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:37:12 GMT): nage (Thu, 16 Nov 2017 16:37:21 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:38:02 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:38:27 GMT): nage (Thu, 16 Nov 2017 16:38:33 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:38:48 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:40:56 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:43:05 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:43:40 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:44:04 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:44:06 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:44:48 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:45:25 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:45:56 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:47:59 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:48:36 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:49:03 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:49:58 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:50:30 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:50:54 GMT): VipinB (Thu, 16 Nov 2017 16:52:30 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:53:11 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:53:44 GMT): Sean_Bohan (Thu, 16 Nov 2017 16:54:29 GMT): dhuseby (Thu, 16 Nov 2017 16:54:51 GMT): panickervinod (Thu, 16 Nov 2017 17:04:41 GMT): Suedonym (Thu, 16 Nov 2017 19:22:29 GMT): pupeter (Mon, 27 Nov 2017 16:43:15 GMT): turmewr3ck (Tue, 28 Nov 2017 11:27:13 GMT): srottem (Tue, 28 Nov 2017 23:17:32 GMT): srottem (Tue, 28 Nov 2017 23:18:07 GMT): turmewr3ck (Wed, 29 Nov 2017 09:14:43 GMT): srottem (Wed, 29 Nov 2017 10:54:07 GMT): srottem (Wed, 29 Nov 2017 10:54:07 GMT): srottem (Wed, 29 Nov 2017 10:54:07 GMT): gudkov (Wed, 29 Nov 2017 15:14:11 GMT): Sean_Bohan (Wed, 29 Nov 2017 18:04:07 GMT): wittrock (Wed, 29 Nov 2017 18:55:29 GMT): srottem (Wed, 29 Nov 2017 20:57:51 GMT): arjanvaneersel (Thu, 30 Nov 2017 07:37:01 GMT): chriswinc (Thu, 30 Nov 2017 14:54:25 GMT): ashcherbakov (Thu, 30 Nov 2017 16:07:19 GMT): the_identity_guy (Thu, 30 Nov 2017 17:04:14 GMT): swcurran (Thu, 30 Nov 2017 17:06:16 GMT): swcurran (Thu, 30 Nov 2017 17:06:16 GMT): mhailstone (Thu, 30 Nov 2017 17:58:49 GMT): gudkov (Fri, 01 Dec 2017 12:02:24 GMT): chenxi 3 (Mon, 04 Dec 2017 06:25:29 GMT): chenxi 3 (Mon, 04 Dec 2017 06:53:30 GMT): alkopnin (Mon, 04 Dec 2017 07:45:08 GMT): mhailstone (Mon, 04 Dec 2017 18:55:20 GMT): the_identity_guy (Mon, 04 Dec 2017 21:24:45 GMT): Suedonym (Thu, 07 Dec 2017 16:41:52 GMT): slafranca (Fri, 08 Dec 2017 18:37:07 GMT): Sean_Bohan (Fri, 08 Dec 2017 19:52:13 GMT): Sean_Bohan (Fri, 08 Dec 2017 19:52:13 GMT): Sean_Bohan (Fri, 08 Dec 2017 19:52:13 GMT): alexeykoren (Mon, 11 Dec 2017 16:01:57 GMT): BrandonKlotz (Wed, 13 Dec 2017 16:39:05 GMT): nage (Wed, 13 Dec 2017 20:24:20 GMT): Sean_Bohan (Wed, 13 Dec 2017 20:25:16 GMT): Sean_Bohan (Wed, 13 Dec 2017 20:34:46 GMT): tkuhrt (Wed, 13 Dec 2017 22:54:16 GMT): Sean_Bohan (Wed, 13 Dec 2017 22:54:35 GMT): Sean_Bohan (Wed, 13 Dec 2017 22:59:35 GMT): nuxibyte_old (Thu, 14 Dec 2017 09:41:17 GMT): ashcherbakov (Thu, 14 Dec 2017 16:08:09 GMT): mhailstone (Thu, 14 Dec 2017 16:17:41 GMT): mhailstone (Thu, 14 Dec 2017 16:20:53 GMT): mhailstone (Thu, 14 Dec 2017 16:26:30 GMT): panickervinod (Thu, 14 Dec 2017 16:27:06 GMT): mhailstone (Thu, 14 Dec 2017 16:28:13 GMT): mhailstone (Thu, 14 Dec 2017 16:38:36 GMT): gvvishwanath (Fri, 15 Dec 2017 05:21:32 GMT): calvinx (Fri, 15 Dec 2017 06:29:29 GMT): PabloBascunana (Wed, 20 Dec 2017 08:50:53 GMT): wolili (Fri, 22 Dec 2017 11:27:48 GMT): Sean_Bohan (Thu, 28 Dec 2017 14:52:15 GMT): ronniemh (Wed, 03 Jan 2018 16:44:28 GMT): Sean_Bohan (Thu, 04 Jan 2018 14:36:36 GMT): mhailstone (Thu, 04 Jan 2018 22:24:30 GMT): mgbailey (Fri, 05 Jan 2018 14:54:39 GMT): mhailstone (Fri, 05 Jan 2018 16:47:39 GMT): mgbailey (Fri, 05 Jan 2018 16:49:46 GMT): WadeBarnes (Fri, 05 Jan 2018 16:49:46 GMT): mhailstone (Fri, 05 Jan 2018 16:53:27 GMT): Harmannz (Sun, 07 Jan 2018 21:48:31 GMT): JOYELIN (Mon, 08 Jan 2018 03:21:50 GMT): mhailstone (Mon, 08 Jan 2018 16:16:51 GMT): mhailstone (Mon, 08 Jan 2018 16:20:31 GMT): mhailstone (Mon, 08 Jan 2018 16:20:31 GMT): mgbailey (Mon, 08 Jan 2018 17:35:56 GMT): mgbailey (Mon, 08 Jan 2018 17:37:05 GMT): mgbailey (Mon, 08 Jan 2018 17:37:12 GMT): mhailstone (Mon, 08 Jan 2018 17:38:02 GMT): mhailstone (Mon, 08 Jan 2018 17:41:38 GMT): mgbailey (Mon, 08 Jan 2018 17:45:39 GMT): mgbailey (Mon, 08 Jan 2018 17:46:02 GMT): mgbailey (Mon, 08 Jan 2018 17:46:25 GMT): mgbailey (Mon, 08 Jan 2018 17:48:24 GMT): mhailstone (Mon, 08 Jan 2018 17:53:37 GMT): mgbailey (Mon, 08 Jan 2018 17:56:05 GMT): mgbailey (Mon, 08 Jan 2018 18:15:51 GMT): mhailstone (Mon, 08 Jan 2018 19:07:12 GMT): aaronr (Mon, 08 Jan 2018 19:34:44 GMT): aaronr (Mon, 08 Jan 2018 19:36:41 GMT): Sean_Bohan (Mon, 08 Jan 2018 19:37:21 GMT): Sean_Bohan (Mon, 08 Jan 2018 19:37:26 GMT): aaronr (Mon, 08 Jan 2018 19:37:31 GMT): nbrempel (Mon, 08 Jan 2018 23:32:55 GMT): Sean_Bohan (Tue, 09 Jan 2018 17:05:34 GMT): gbarcomu (Wed, 10 Jan 2018 15:12:23 GMT): Sean_Bohan (Wed, 10 Jan 2018 20:32:54 GMT): dwjohnston (Thu, 11 Jan 2018 03:08:42 GMT): dwjohnston (Thu, 11 Jan 2018 03:12:15 GMT): dwjohnston (Thu, 11 Jan 2018 03:12:16 GMT): dwjohnston (Thu, 11 Jan 2018 03:12:43 GMT): dwjohnston (Thu, 11 Jan 2018 03:15:29 GMT): dwjohnston (Thu, 11 Jan 2018 03:20:13 GMT): dwjohnston (Thu, 11 Jan 2018 04:11:52 GMT): dwjohnston (Thu, 11 Jan 2018 04:12:14 GMT): dwjohnston (Thu, 11 Jan 2018 04:15:06 GMT): mgbailey (Thu, 11 Jan 2018 15:01:53 GMT): wittrock (Thu, 11 Jan 2018 15:05:59 GMT): mgbailey (Thu, 11 Jan 2018 15:06:49 GMT): wittrock (Thu, 11 Jan 2018 15:07:35 GMT): wittrock (Thu, 11 Jan 2018 15:07:49 GMT): mgbailey (Thu, 11 Jan 2018 15:10:16 GMT): wittrock (Thu, 11 Jan 2018 15:10:29 GMT): ashcherbakov (Thu, 11 Jan 2018 15:31:29 GMT): wittrock (Thu, 11 Jan 2018 15:34:39 GMT): ashcherbakov (Thu, 11 Jan 2018 15:35:58 GMT): ashcherbakov (Thu, 11 Jan 2018 16:15:25 GMT): Rickzan (Tue, 16 Jan 2018 19:23:29 GMT): smithbk (Wed, 17 Jan 2018 15:30:41 GMT): hawkmauk (Wed, 17 Jan 2018 16:23:40 GMT): hawkmauk (Wed, 17 Jan 2018 16:26:49 GMT): sklump (Wed, 17 Jan 2018 17:48:43 GMT): sklump (Wed, 17 Jan 2018 17:48:43 GMT): Sean_Bohan (Wed, 17 Jan 2018 19:20:22 GMT): Sean_Bohan (Wed, 17 Jan 2018 19:20:42 GMT): akhihaki (Mon, 22 Jan 2018 18:17:56 GMT): nghia47 (Tue, 23 Jan 2018 04:43:43 GMT): JustinBoyer (Tue, 23 Jan 2018 22:58:59 GMT): nage (Thu, 25 Jan 2018 15:36:32 GMT): hawkmauk (Thu, 25 Jan 2018 15:38:49 GMT): Sean_Bohan (Thu, 25 Jan 2018 15:46:31 GMT): Sean_Bohan (Thu, 25 Jan 2018 15:46:31 GMT): notOccupanther (Fri, 26 Jan 2018 11:03:01 GMT): wolili (Fri, 26 Jan 2018 12:10:18 GMT): tkuhrt (Fri, 26 Jan 2018 12:44:52 GMT): ashcherbakov (Fri, 26 Jan 2018 12:51:33 GMT): ashcherbakov (Fri, 26 Jan 2018 12:51:49 GMT): NiallC (Mon, 29 Jan 2018 14:36:09 GMT): ajayatgit (Mon, 29 Jan 2018 19:49:27 GMT): nmellal (Tue, 30 Jan 2018 09:56:21 GMT): ianco (Thu, 01 Feb 2018 16:48:57 GMT): drew 41 (Thu, 01 Feb 2018 19:22:11 GMT): pimotte (Fri, 02 Feb 2018 07:30:32 GMT): Jasdog (Wed, 07 Feb 2018 06:22:22 GMT): Sean_Bohan (Thu, 08 Feb 2018 00:17:09 GMT): AtulKumthekar (Mon, 12 Feb 2018 11:02:30 GMT): NickThomas (Mon, 12 Feb 2018 23:09:23 GMT): daveryIBM (Thu, 15 Feb 2018 13:44:36 GMT): Sean_Bohan (Thu, 15 Feb 2018 17:10:54 GMT): Drew 42 (Fri, 16 Feb 2018 21:36:03 GMT): mohdhafeezaj (Fri, 16 Feb 2018 23:25:47 GMT): mawi (Tue, 20 Feb 2018 17:46:15 GMT): mawi (Tue, 20 Feb 2018 17:49:18 GMT): jljordan_bcgov (Tue, 20 Feb 2018 17:50:42 GMT): mawi (Tue, 20 Feb 2018 18:09:16 GMT): mawi (Tue, 20 Feb 2018 18:11:28 GMT): jljordan_bcgov (Tue, 20 Feb 2018 18:51:57 GMT): jljordan_bcgov (Tue, 20 Feb 2018 18:51:57 GMT): jljordan_bcgov (Tue, 20 Feb 2018 18:56:44 GMT): mawi (Tue, 20 Feb 2018 18:59:20 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:00:25 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:01:41 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:01:41 GMT): mawi (Tue, 20 Feb 2018 19:02:06 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:02:55 GMT): mawi (Tue, 20 Feb 2018 19:02:58 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:03:20 GMT): mawi (Tue, 20 Feb 2018 19:03:26 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:04:28 GMT): mawi (Tue, 20 Feb 2018 19:04:38 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:05:27 GMT): mawi (Tue, 20 Feb 2018 19:05:44 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:06:30 GMT): mawi (Tue, 20 Feb 2018 19:07:12 GMT): mawi (Tue, 20 Feb 2018 19:07:19 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:07:23 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:08:01 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:08:35 GMT): mawi (Tue, 20 Feb 2018 19:08:41 GMT): mawi (Tue, 20 Feb 2018 19:08:53 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:09:05 GMT): mawi (Tue, 20 Feb 2018 19:09:08 GMT): mawi (Tue, 20 Feb 2018 19:09:18 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:09:41 GMT): mawi (Tue, 20 Feb 2018 19:09:52 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:09:54 GMT): mawi (Tue, 20 Feb 2018 19:10:00 GMT): mawi (Tue, 20 Feb 2018 19:11:15 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:11:23 GMT): mawi (Tue, 20 Feb 2018 19:11:44 GMT): jljordan_bcgov (Tue, 20 Feb 2018 19:12:01 GMT): malvikam (Tue, 20 Feb 2018 21:07:26 GMT): Comuto (Wed, 21 Feb 2018 12:33:56 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): swcurran (Wed, 21 Feb 2018 17:41:47 GMT): nage (Wed, 21 Feb 2018 18:51:27 GMT): Sean_Bohan (Thu, 22 Feb 2018 00:56:58 GMT): mawi (Thu, 22 Feb 2018 08:29:19 GMT): dkulic (Thu, 22 Feb 2018 16:20:51 GMT): jankokrstic (Thu, 22 Feb 2018 16:57:11 GMT): jljordan_bcgov (Thu, 22 Feb 2018 17:30:59 GMT): swcurran (Thu, 22 Feb 2018 18:09:14 GMT): Sean_Bohan (Thu, 22 Feb 2018 21:47:25 GMT): mawi (Fri, 23 Feb 2018 07:54:26 GMT): Skorpion7777 (Fri, 23 Feb 2018 12:11:55 GMT): ianco (Fri, 23 Feb 2018 14:19:38 GMT): Skorpion7777 (Fri, 23 Feb 2018 14:26:30 GMT): ianco (Fri, 23 Feb 2018 14:29:24 GMT): ianco (Fri, 23 Feb 2018 14:29:58 GMT): ianco (Fri, 23 Feb 2018 14:30:20 GMT): swcurran (Fri, 23 Feb 2018 17:54:16 GMT): Skorpion7777 (Fri, 23 Feb 2018 21:30:45 GMT): jljordan_bcgov (Sun, 25 Feb 2018 02:07:47 GMT): vinomaster (Mon, 26 Feb 2018 14:38:30 GMT): vinomaster (Mon, 26 Feb 2018 14:54:21 GMT): swcurran (Tue, 27 Feb 2018 17:42:22 GMT): swcurran (Tue, 27 Feb 2018 17:44:56 GMT): swcurran (Tue, 27 Feb 2018 19:41:49 GMT): lcinacio (Thu, 01 Mar 2018 08:17:49 GMT): vinomaster (Thu, 01 Mar 2018 14:30:12 GMT): danielhardman (Thu, 01 Mar 2018 14:41:01 GMT): vinomaster (Thu, 01 Mar 2018 14:42:30 GMT): danielhardman (Thu, 01 Mar 2018 14:45:08 GMT): danielhardman (Thu, 01 Mar 2018 14:46:31 GMT): danielhardman (Thu, 01 Mar 2018 14:47:37 GMT): ianco (Thu, 01 Mar 2018 14:58:07 GMT): ianco (Thu, 01 Mar 2018 14:58:07 GMT): danielhardman (Thu, 01 Mar 2018 14:59:24 GMT): vinomaster (Thu, 01 Mar 2018 15:03:23 GMT): ianco (Thu, 01 Mar 2018 15:03:55 GMT): vinomaster (Thu, 01 Mar 2018 15:26:05 GMT): vinomaster (Thu, 01 Mar 2018 15:28:20 GMT): swcurran (Thu, 01 Mar 2018 22:03:16 GMT): swcurran (Thu, 01 Mar 2018 22:12:57 GMT): swcurran (Thu, 01 Mar 2018 22:12:57 GMT): swcurran (Thu, 01 Mar 2018 22:12:57 GMT): swcurran (Thu, 01 Mar 2018 22:12:57 GMT): vinomaster (Fri, 02 Mar 2018 12:07:19 GMT): vinomaster (Fri, 02 Mar 2018 12:07:19 GMT): swcurran (Fri, 02 Mar 2018 16:30:02 GMT): vinomaster (Fri, 02 Mar 2018 18:48:52 GMT): jljordan_bcgov (Fri, 02 Mar 2018 20:17:15 GMT): jljordan_bcgov (Fri, 02 Mar 2018 20:17:47 GMT): danielhardman (Fri, 02 Mar 2018 22:22:17 GMT): danielhardman (Fri, 02 Mar 2018 22:25:37 GMT): danielhardman (Fri, 02 Mar 2018 22:33:56 GMT): swcurran (Sat, 03 Mar 2018 06:10:24 GMT): vinomaster (Sat, 03 Mar 2018 18:51:28 GMT): vinomaster (Sat, 03 Mar 2018 18:56:10 GMT): vinomaster (Sat, 03 Mar 2018 19:15:51 GMT): swcurran (Sun, 04 Mar 2018 19:45:55 GMT): mspatel (Mon, 05 Mar 2018 16:03:02 GMT): the_identity_guy (Mon, 05 Mar 2018 18:52:03 GMT): the_identity_guy (Mon, 05 Mar 2018 18:52:03 GMT): pimotte (Wed, 07 Mar 2018 08:03:32 GMT): pimotte (Wed, 07 Mar 2018 08:03:32 GMT): creatornader (Wed, 07 Mar 2018 23:00:25 GMT): swcurran (Thu, 08 Mar 2018 00:32:02 GMT): ArthurManz (Thu, 08 Mar 2018 10:02:51 GMT): danielhardman (Thu, 08 Mar 2018 16:20:16 GMT): danielhardman (Thu, 08 Mar 2018 16:25:14 GMT): danielhardman (Thu, 08 Mar 2018 17:45:25 GMT): pimotte (Mon, 12 Mar 2018 07:39:04 GMT): luca.boldrin (Mon, 12 Mar 2018 10:45:21 GMT): p6g (Mon, 12 Mar 2018 12:29:34 GMT): ydennisy (Mon, 12 Mar 2018 14:05:45 GMT): ydennisy (Mon, 12 Mar 2018 17:03:41 GMT): jflack1970 (Tue, 13 Mar 2018 13:51:44 GMT): eramitg (Thu, 15 Mar 2018 16:04:06 GMT): swcurran (Fri, 16 Mar 2018 15:30:31 GMT): mhailstone (Fri, 16 Mar 2018 21:19:12 GMT): trthhrtz (Sun, 18 Mar 2018 06:38:57 GMT): ShikarSharma (Tue, 20 Mar 2018 22:48:15 GMT): bafonins (Wed, 21 Mar 2018 13:29:58 GMT): mhailstone (Thu, 22 Mar 2018 15:12:27 GMT): pimotte (Thu, 22 Mar 2018 15:24:31 GMT): mhailstone (Thu, 22 Mar 2018 15:36:44 GMT): pimotte (Thu, 22 Mar 2018 15:41:49 GMT): mhailstone (Thu, 22 Mar 2018 15:45:56 GMT): mhailstone (Thu, 22 Mar 2018 15:45:56 GMT): swcurran (Thu, 22 Mar 2018 16:03:54 GMT): swcurran (Thu, 22 Mar 2018 16:04:17 GMT): BryanSparks (Fri, 23 Mar 2018 13:57:30 GMT): thomasmm (Mon, 26 Mar 2018 12:49:41 GMT): nage (Mon, 26 Mar 2018 14:10:13 GMT): swcurran (Mon, 26 Mar 2018 15:06:32 GMT): nage (Mon, 26 Mar 2018 16:59:02 GMT): nage (Mon, 26 Mar 2018 16:59:35 GMT): nage (Mon, 26 Mar 2018 17:01:28 GMT): nage (Mon, 26 Mar 2018 17:02:04 GMT): the_identity_guy (Mon, 26 Mar 2018 18:55:11 GMT): nage (Mon, 26 Mar 2018 20:36:19 GMT): nage (Mon, 26 Mar 2018 20:38:01 GMT): nage (Mon, 26 Mar 2018 20:39:33 GMT): tomislav (Mon, 26 Mar 2018 23:42:21 GMT): mboyd (Tue, 27 Mar 2018 02:52:00 GMT): swcurran (Tue, 27 Mar 2018 15:55:12 GMT): nage (Wed, 28 Mar 2018 15:47:29 GMT): kdenhartog (Thu, 29 Mar 2018 01:39:33 GMT): tomislav (Thu, 29 Mar 2018 14:03:09 GMT): jljordan_bcgov (Thu, 29 Mar 2018 15:57:24 GMT): tomislav (Thu, 29 Mar 2018 15:59:30 GMT): ianco (Thu, 29 Mar 2018 16:00:51 GMT): ianco (Thu, 29 Mar 2018 16:00:51 GMT): ianco (Thu, 29 Mar 2018 16:01:30 GMT): tomislav (Thu, 29 Mar 2018 16:02:29 GMT): MikeCohen (Fri, 30 Mar 2018 18:52:22 GMT): mawi (Tue, 03 Apr 2018 13:54:02 GMT): drummondreed (Wed, 04 Apr 2018 06:31:36 GMT): mawi (Wed, 04 Apr 2018 07:04:04 GMT): hcsatish (Wed, 04 Apr 2018 17:18:24 GMT): Sean_Bohan (Thu, 05 Apr 2018 14:09:28 GMT): nuxibyte_old (Thu, 05 Apr 2018 22:54:37 GMT): swcurran (Mon, 09 Apr 2018 16:53:07 GMT): eramitg (Wed, 11 Apr 2018 15:39:23 GMT): MyMate (Thu, 12 Apr 2018 09:26:24 GMT): mawi (Thu, 12 Apr 2018 11:23:22 GMT): swcurran (Thu, 12 Apr 2018 20:10:57 GMT): drummondreed (Mon, 16 Apr 2018 00:38:11 GMT): mawi (Mon, 16 Apr 2018 13:38:03 GMT): ryanwest6 (Tue, 17 Apr 2018 01:39:48 GMT): twshelton (Wed, 18 Apr 2018 15:22:00 GMT): drummondreed (Wed, 18 Apr 2018 16:24:42 GMT): esplinr (Thu, 19 Apr 2018 16:00:46 GMT): Steve-Boyd (Thu, 19 Apr 2018 20:17:28 GMT): danielhardman (Fri, 20 Apr 2018 23:32:03 GMT): danielhardman (Fri, 20 Apr 2018 23:32:50 GMT): kyogesh91 (Sat, 21 Apr 2018 20:12:04 GMT): tomislav (Sun, 22 Apr 2018 02:23:05 GMT): mawi (Sun, 22 Apr 2018 10:04:59 GMT): danielhardman (Sun, 22 Apr 2018 17:19:13 GMT): jaredhanson (Mon, 23 Apr 2018 02:00:15 GMT): Kelattar (Mon, 23 Apr 2018 07:38:22 GMT): Kelattar (Mon, 23 Apr 2018 07:45:42 GMT): mawi (Mon, 23 Apr 2018 07:46:43 GMT): Kelattar (Mon, 23 Apr 2018 08:32:24 GMT): mawi (Mon, 23 Apr 2018 08:55:49 GMT): musquash (Mon, 23 Apr 2018 11:36:09 GMT): StevenCotes (Mon, 23 Apr 2018 20:26:34 GMT): salmanbaset (Tue, 24 Apr 2018 19:23:21 GMT): jackson18 (Wed, 25 Apr 2018 19:58:04 GMT): mawi (Mon, 30 Apr 2018 10:04:34 GMT): esplinr (Mon, 30 Apr 2018 23:55:58 GMT): esplinr (Mon, 30 Apr 2018 23:56:22 GMT): esplinr (Mon, 30 Apr 2018 23:56:57 GMT): drummondreed (Tue, 01 May 2018 06:57:45 GMT): mawi (Tue, 01 May 2018 07:07:15 GMT): nuxibyte (Tue, 01 May 2018 16:50:32 GMT): SteveGoob (Wed, 02 May 2018 19:43:04 GMT): swcurran (Wed, 02 May 2018 21:41:45 GMT): nage (Thu, 03 May 2018 12:45:01 GMT): TelegramSam (Thu, 03 May 2018 13:00:15 GMT): TelegramSam (Thu, 03 May 2018 13:03:09 GMT): swcurran (Thu, 03 May 2018 15:21:31 GMT): cadi 2 (Thu, 03 May 2018 17:53:18 GMT): samadsajanlal (Fri, 04 May 2018 19:33:53 GMT): samadsajanlal (Fri, 04 May 2018 19:36:02 GMT): samadsajanlal (Fri, 04 May 2018 19:46:50 GMT): samadsajanlal (Fri, 04 May 2018 19:46:50 GMT): samadsajanlal (Fri, 04 May 2018 19:46:50 GMT): samadsajanlal (Fri, 04 May 2018 19:46:50 GMT): samadsajanlal (Fri, 04 May 2018 19:51:10 GMT): kdenhartog (Sat, 05 May 2018 08:05:19 GMT): kdenhartog (Sat, 05 May 2018 08:09:51 GMT): the_identity_guy (Sun, 06 May 2018 22:07:52 GMT): kdenhartog (Sun, 06 May 2018 23:41:58 GMT): drummondreed (Mon, 07 May 2018 00:22:27 GMT): drummondreed (Mon, 07 May 2018 00:24:07 GMT): samadsajanlal (Mon, 07 May 2018 18:23:09 GMT): samadsajanlal (Mon, 07 May 2018 18:23:34 GMT): samadsajanlal (Mon, 07 May 2018 21:04:12 GMT): swcurran (Mon, 07 May 2018 22:09:30 GMT): drummondreed (Mon, 07 May 2018 23:38:11 GMT): drummondreed (Mon, 07 May 2018 23:38:19 GMT): vidor (Mon, 07 May 2018 23:56:10 GMT): the_identity_guy (Tue, 08 May 2018 15:18:22 GMT): kdenhartog (Tue, 08 May 2018 15:21:18 GMT): samadsajanlal (Tue, 08 May 2018 16:22:06 GMT): swcurran (Tue, 08 May 2018 16:57:09 GMT): swcurran (Tue, 08 May 2018 16:57:09 GMT): swcurran (Tue, 08 May 2018 17:02:34 GMT): samadsajanlal (Tue, 08 May 2018 18:40:47 GMT): kdenhartog (Tue, 08 May 2018 18:49:09 GMT): kdenhartog (Tue, 08 May 2018 18:51:51 GMT): samadsajanlal (Tue, 08 May 2018 18:57:40 GMT): samadsajanlal (Tue, 08 May 2018 18:58:30 GMT): mboyd (Tue, 08 May 2018 19:04:42 GMT): samadsajanlal (Tue, 08 May 2018 19:09:16 GMT): saholman (Tue, 08 May 2018 19:21:05 GMT): dbluhm (Tue, 08 May 2018 19:46:18 GMT): nage (Tue, 08 May 2018 19:48:33 GMT): nage (Tue, 08 May 2018 19:49:47 GMT): mboyd (Tue, 08 May 2018 19:52:18 GMT): dbluhm (Tue, 08 May 2018 19:53:22 GMT): guido.santos (Wed, 09 May 2018 14:17:34 GMT): mboyd (Wed, 09 May 2018 20:13:25 GMT): nhelmy (Thu, 10 May 2018 07:36:46 GMT): troyronda (Thu, 10 May 2018 15:34:04 GMT): jonathanreynolds (Thu, 10 May 2018 15:34:15 GMT): saholman (Thu, 10 May 2018 15:59:16 GMT): mboyd (Thu, 10 May 2018 16:00:34 GMT): kevin.chan (Thu, 10 May 2018 16:32:53 GMT): swcurran (Thu, 10 May 2018 21:55:44 GMT): swcurran (Thu, 10 May 2018 22:19:11 GMT): swcurran (Thu, 10 May 2018 22:20:30 GMT): mhailstone (Thu, 10 May 2018 22:20:48 GMT): mhailstone (Thu, 10 May 2018 22:20:48 GMT): mhailstone (Thu, 10 May 2018 22:22:05 GMT): dbluhm (Thu, 10 May 2018 23:18:44 GMT): kdenhartog (Fri, 11 May 2018 21:07:58 GMT): dbluhm (Fri, 11 May 2018 22:31:52 GMT): dbluhm (Fri, 11 May 2018 22:31:52 GMT): swcurran (Fri, 11 May 2018 22:36:05 GMT): dbluhm (Fri, 11 May 2018 22:38:44 GMT): swcurran (Fri, 11 May 2018 22:46:19 GMT): swcurran (Fri, 11 May 2018 22:48:42 GMT): swcurran (Fri, 11 May 2018 22:48:42 GMT): danielhardman (Fri, 11 May 2018 22:56:05 GMT): swcurran (Fri, 11 May 2018 22:58:28 GMT): dbluhm (Fri, 11 May 2018 23:22:31 GMT): dbluhm (Fri, 11 May 2018 23:25:25 GMT): danielhardman (Sat, 12 May 2018 01:05:13 GMT): DST 32 (Sat, 12 May 2018 15:21:27 GMT): Kelattar (Wed, 16 May 2018 13:08:16 GMT): dbluhm (Wed, 16 May 2018 18:45:20 GMT): Kelattar (Thu, 17 May 2018 07:45:53 GMT): aaronr (Thu, 17 May 2018 14:51:42 GMT): esplinr (Thu, 17 May 2018 15:03:44 GMT): mboyd (Thu, 17 May 2018 16:06:50 GMT): kevin.chan (Thu, 17 May 2018 16:15:53 GMT): kevin.chan (Thu, 17 May 2018 16:16:09 GMT): kevin.chan (Thu, 17 May 2018 16:16:29 GMT): danielhardman (Thu, 17 May 2018 16:19:30 GMT): danielhardman (Thu, 17 May 2018 16:33:33 GMT): mboyd (Thu, 17 May 2018 17:42:12 GMT): mboyd (Thu, 17 May 2018 17:42:12 GMT): mboyd (Thu, 17 May 2018 17:42:12 GMT): danielhardman (Thu, 17 May 2018 19:25:40 GMT): swcurran (Thu, 17 May 2018 19:27:45 GMT): swcurran (Thu, 17 May 2018 19:27:45 GMT): mboyd (Thu, 17 May 2018 19:28:55 GMT): danielhardman (Thu, 17 May 2018 19:30:05 GMT): mboyd (Thu, 17 May 2018 19:32:18 GMT): mboyd (Thu, 17 May 2018 19:32:18 GMT): swcurran (Thu, 17 May 2018 19:33:56 GMT): mboyd (Thu, 17 May 2018 19:36:46 GMT): danielhardman (Thu, 17 May 2018 19:37:58 GMT): danielhardman (Thu, 17 May 2018 19:38:14 GMT): danielhardman (Thu, 17 May 2018 19:38:56 GMT): swcurran (Thu, 17 May 2018 19:39:39 GMT): swcurran (Thu, 17 May 2018 19:40:08 GMT): danielhardman (Thu, 17 May 2018 19:41:06 GMT): danielhardman (Thu, 17 May 2018 19:42:45 GMT): swcurran (Thu, 17 May 2018 19:43:08 GMT): swcurran (Thu, 17 May 2018 19:43:08 GMT): danielhardman (Thu, 17 May 2018 19:43:35 GMT): swcurran (Thu, 17 May 2018 19:43:56 GMT): mboyd (Thu, 17 May 2018 19:44:19 GMT): danielhardman (Thu, 17 May 2018 19:44:36 GMT): swcurran (Thu, 17 May 2018 19:46:29 GMT): swcurran (Thu, 17 May 2018 19:48:54 GMT): swcurran (Thu, 17 May 2018 19:48:54 GMT): mboyd (Thu, 17 May 2018 19:49:22 GMT): mboyd (Thu, 17 May 2018 19:56:27 GMT): mboyd (Thu, 17 May 2018 19:56:27 GMT): swcurran (Thu, 17 May 2018 20:05:38 GMT): swcurran (Thu, 17 May 2018 20:10:01 GMT): swcurran (Thu, 17 May 2018 20:10:01 GMT): swcurran (Thu, 17 May 2018 20:10:01 GMT): swcurran (Thu, 17 May 2018 20:10:01 GMT): mboyd (Thu, 17 May 2018 20:11:55 GMT): kevin.chan (Thu, 17 May 2018 20:13:05 GMT): danielhardman (Thu, 17 May 2018 20:15:24 GMT): swcurran (Thu, 17 May 2018 20:29:33 GMT): swcurran (Thu, 17 May 2018 20:29:33 GMT): swcurran (Thu, 17 May 2018 20:31:02 GMT): mhailstone (Thu, 17 May 2018 23:19:00 GMT): mhailstone (Thu, 17 May 2018 23:19:00 GMT): mhailstone (Thu, 17 May 2018 23:19:35 GMT): mhailstone (Thu, 17 May 2018 23:19:55 GMT): mhailstone (Thu, 17 May 2018 23:42:07 GMT): mhailstone (Thu, 17 May 2018 23:42:07 GMT): mhailstone (Thu, 17 May 2018 23:49:40 GMT): danielhardman (Fri, 18 May 2018 03:39:46 GMT): danielhardman (Fri, 18 May 2018 03:39:49 GMT): mhailstone (Fri, 18 May 2018 14:04:38 GMT): mhailstone (Fri, 18 May 2018 14:09:36 GMT): mhailstone (Fri, 18 May 2018 14:11:14 GMT): swcurran (Fri, 18 May 2018 15:07:49 GMT): swcurran (Fri, 18 May 2018 15:17:23 GMT): mhailstone (Fri, 18 May 2018 16:03:36 GMT): swcurran (Fri, 18 May 2018 16:10:19 GMT): mboyd (Fri, 18 May 2018 17:13:17 GMT): mboyd (Fri, 18 May 2018 17:14:03 GMT): mhailstone (Fri, 18 May 2018 18:07:34 GMT): mhailstone (Fri, 18 May 2018 18:13:45 GMT): mhailstone (Fri, 18 May 2018 18:17:54 GMT): swcurran (Fri, 18 May 2018 18:30:55 GMT): mhailstone (Fri, 18 May 2018 18:46:08 GMT): swcurran (Fri, 18 May 2018 18:55:09 GMT): mhailstone (Fri, 18 May 2018 19:28:02 GMT): swcurran (Fri, 18 May 2018 22:33:40 GMT): mhailstone (Fri, 18 May 2018 23:30:53 GMT): APSSI (Mon, 21 May 2018 06:54:41 GMT): nagad814 (Mon, 21 May 2018 07:07:27 GMT): CabMorris2 (Mon, 21 May 2018 19:27:50 GMT): jayapalreddy (Tue, 22 May 2018 12:01:12 GMT): kosullivan_sita (Tue, 22 May 2018 15:50:20 GMT): username343 (Wed, 23 May 2018 11:51:14 GMT): tusharg (Wed, 23 May 2018 14:35:59 GMT): dbluhm (Thu, 24 May 2018 16:02:52 GMT): nage (Thu, 24 May 2018 16:05:14 GMT): mhailstone (Thu, 24 May 2018 22:42:00 GMT): mhailstone (Thu, 24 May 2018 22:42:00 GMT): mhailstone (Thu, 24 May 2018 22:54:18 GMT): swcurran (Thu, 24 May 2018 23:09:08 GMT): swcurran (Thu, 24 May 2018 23:11:28 GMT): swcurran (Thu, 24 May 2018 23:14:07 GMT): swcurran (Thu, 24 May 2018 23:19:26 GMT): swcurran (Thu, 24 May 2018 23:20:36 GMT): kdenhartog (Fri, 25 May 2018 03:25:49 GMT): jeremi 24 (Fri, 25 May 2018 07:04:54 GMT): mhailstone (Fri, 25 May 2018 16:26:01 GMT): mhailstone (Fri, 25 May 2018 16:26:01 GMT): mhailstone (Fri, 25 May 2018 17:02:58 GMT): mhailstone (Fri, 25 May 2018 17:02:58 GMT): mhailstone (Fri, 25 May 2018 17:47:25 GMT): nage (Sat, 26 May 2018 14:14:33 GMT): swcurran (Mon, 28 May 2018 15:25:13 GMT): shsedghi (Tue, 29 May 2018 14:53:17 GMT): burdettadam (Tue, 29 May 2018 19:14:25 GMT): vd30992 (Wed, 30 May 2018 04:44:27 GMT): vd30992 (Wed, 30 May 2018 04:45:14 GMT): mboyd (Wed, 30 May 2018 04:53:52 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 05:02:15 GMT): vd30992 (Wed, 30 May 2018 06:55:48 GMT): jwaup (Wed, 30 May 2018 13:57:46 GMT): adaml (Wed, 30 May 2018 16:39:22 GMT): swcurran (Wed, 30 May 2018 16:46:23 GMT): swcurran (Wed, 30 May 2018 16:46:23 GMT): Jiropole (Wed, 30 May 2018 18:27:12 GMT): dbluhm (Thu, 31 May 2018 00:57:44 GMT): vd30992 (Thu, 31 May 2018 03:16:21 GMT): vd30992 (Thu, 31 May 2018 03:17:16 GMT): swcurran (Thu, 31 May 2018 03:17:31 GMT): swcurran (Thu, 31 May 2018 03:17:45 GMT): swcurran (Thu, 31 May 2018 03:17:45 GMT): vd30992 (Thu, 31 May 2018 03:18:32 GMT): swcurran (Thu, 31 May 2018 03:19:25 GMT): swcurran (Thu, 31 May 2018 03:19:40 GMT): dbluhm (Thu, 31 May 2018 03:20:31 GMT): swcurran (Thu, 31 May 2018 03:24:19 GMT): dbluhm (Thu, 31 May 2018 03:26:30 GMT): mdapps (Thu, 31 May 2018 08:58:36 GMT): peter.danko (Thu, 31 May 2018 09:15:55 GMT): vd30992 (Fri, 01 Jun 2018 07:25:23 GMT): karthikpanicker (Sat, 02 Jun 2018 09:26:02 GMT): the_identity_guy (Sat, 02 Jun 2018 19:34:41 GMT): swcurran (Sat, 02 Jun 2018 20:06:02 GMT): sklump (Sat, 02 Jun 2018 20:06:02 GMT): swcurran (Sat, 02 Jun 2018 20:13:23 GMT): swcurran (Sat, 02 Jun 2018 20:13:23 GMT): swcurran (Sat, 02 Jun 2018 20:13:23 GMT): sklump (Mon, 04 Jun 2018 12:11:21 GMT): sklump (Mon, 04 Jun 2018 12:11:21 GMT): sklump (Mon, 04 Jun 2018 12:11:21 GMT): sklump (Mon, 04 Jun 2018 12:11:21 GMT): the_identity_guy (Mon, 04 Jun 2018 13:26:13 GMT): the_identity_guy (Mon, 04 Jun 2018 13:26:13 GMT): sklump (Mon, 04 Jun 2018 13:27:15 GMT): sklump (Mon, 04 Jun 2018 13:28:24 GMT): haggs (Mon, 04 Jun 2018 20:32:45 GMT): mhailstone (Wed, 06 Jun 2018 00:04:15 GMT): sklump (Wed, 06 Jun 2018 10:32:16 GMT): sklump (Wed, 06 Jun 2018 10:43:40 GMT): BreizhIndy (Wed, 06 Jun 2018 14:41:01 GMT): abraham (Fri, 08 Jun 2018 05:20:24 GMT): danielhardman (Fri, 08 Jun 2018 21:49:12 GMT): tomislav (Mon, 11 Jun 2018 12:48:03 GMT): PhillipGibb (Mon, 11 Jun 2018 14:00:18 GMT): slr (Mon, 11 Jun 2018 17:11:37 GMT): mhailstone (Mon, 11 Jun 2018 17:32:56 GMT): swcurran (Mon, 11 Jun 2018 20:06:18 GMT): tomislav (Tue, 12 Jun 2018 00:11:04 GMT): Sean_Bohan (Thu, 14 Jun 2018 14:34:37 GMT): jljordan_bcgov (Thu, 14 Jun 2018 16:01:06 GMT): mhailstone (Thu, 14 Jun 2018 16:05:22 GMT): mhailstone (Thu, 14 Jun 2018 16:06:32 GMT): Sean_Bohan (Thu, 14 Jun 2018 16:06:46 GMT): Sean_Bohan (Thu, 14 Jun 2018 16:11:24 GMT): Sean_Bohan (Thu, 14 Jun 2018 16:11:27 GMT): mhailstone (Thu, 14 Jun 2018 16:12:30 GMT): jonathanreynolds (Fri, 15 Jun 2018 14:41:33 GMT): jonathanreynolds (Fri, 15 Jun 2018 14:41:49 GMT): TelegramSam (Fri, 15 Jun 2018 18:02:07 GMT): mhailstone (Fri, 15 Jun 2018 22:03:35 GMT): BreizhIndy (Mon, 18 Jun 2018 13:34:52 GMT): BreizhIndy (Mon, 18 Jun 2018 13:34:52 GMT): BreizhIndy (Mon, 18 Jun 2018 13:37:52 GMT): BreizhIndy (Mon, 18 Jun 2018 13:38:16 GMT): dbluhm (Mon, 18 Jun 2018 16:14:38 GMT): mhailstone (Mon, 18 Jun 2018 17:12:40 GMT): swcurran (Mon, 18 Jun 2018 19:16:27 GMT): tomislav (Mon, 18 Jun 2018 20:34:01 GMT): nhelmy (Mon, 18 Jun 2018 21:37:02 GMT): nhelmy (Mon, 18 Jun 2018 21:37:16 GMT): nhelmy (Mon, 18 Jun 2018 21:37:20 GMT): nhelmy (Mon, 18 Jun 2018 21:42:13 GMT): nhelmy (Mon, 18 Jun 2018 21:42:13 GMT): swcurran (Mon, 18 Jun 2018 22:53:56 GMT): swcurran (Mon, 18 Jun 2018 22:54:58 GMT): BreizhIndy (Tue, 19 Jun 2018 15:19:43 GMT): json (Tue, 19 Jun 2018 19:12:16 GMT): saholman (Tue, 19 Jun 2018 20:10:05 GMT): saholman (Tue, 19 Jun 2018 20:10:05 GMT): saholman (Tue, 19 Jun 2018 20:15:47 GMT): saholman (Tue, 19 Jun 2018 20:15:47 GMT): AvikHazra (Wed, 20 Jun 2018 05:36:06 GMT): BreizhIndy (Wed, 20 Jun 2018 07:51:50 GMT): BreizhIndy (Wed, 20 Jun 2018 07:52:38 GMT): BreizhIndy (Wed, 20 Jun 2018 08:08:13 GMT): BreizhIndy (Wed, 20 Jun 2018 08:08:13 GMT): PhillipGibb (Wed, 20 Jun 2018 12:42:39 GMT): PhillipGibb (Wed, 20 Jun 2018 12:48:41 GMT): asardo (Wed, 20 Jun 2018 14:28:10 GMT): nage (Thu, 21 Jun 2018 01:58:10 GMT): nage (Thu, 21 Jun 2018 02:00:45 GMT): saholman (Thu, 21 Jun 2018 14:24:46 GMT): sklump (Thu, 21 Jun 2018 14:40:22 GMT): BreizhIndy (Thu, 21 Jun 2018 15:05:35 GMT): saholman (Thu, 21 Jun 2018 15:09:43 GMT): mjmckean (Thu, 21 Jun 2018 15:40:14 GMT): BreizhIndy (Mon, 25 Jun 2018 13:10:07 GMT): BreizhIndy (Mon, 25 Jun 2018 15:26:00 GMT): BreizhIndy (Mon, 25 Jun 2018 15:26:57 GMT): mhailstone (Mon, 25 Jun 2018 16:12:23 GMT): burdettadam (Mon, 25 Jun 2018 16:49:46 GMT): burdettadam (Mon, 25 Jun 2018 16:49:46 GMT): burdettadam (Mon, 25 Jun 2018 16:49:46 GMT): PhillipGibb (Mon, 25 Jun 2018 19:24:48 GMT): PhillipGibb (Mon, 25 Jun 2018 19:26:09 GMT): burdettadam (Mon, 25 Jun 2018 20:02:58 GMT): PhillipGibb (Mon, 25 Jun 2018 20:14:41 GMT): PhillipGibb (Mon, 25 Jun 2018 20:17:08 GMT): burdettadam (Mon, 25 Jun 2018 20:29:01 GMT): burdettadam (Mon, 25 Jun 2018 20:29:01 GMT): dbluhm (Tue, 26 Jun 2018 02:54:44 GMT): PhillipGibb (Tue, 26 Jun 2018 03:51:47 GMT): SherifMuhammed (Tue, 26 Jun 2018 06:24:05 GMT): alvaradojl (Tue, 26 Jun 2018 07:56:53 GMT): BreizhIndy (Tue, 26 Jun 2018 08:55:09 GMT): dbluhm (Tue, 26 Jun 2018 12:44:00 GMT): dbluhm (Tue, 26 Jun 2018 12:44:00 GMT): tomislav (Tue, 26 Jun 2018 14:27:27 GMT): swcurran (Tue, 26 Jun 2018 15:11:23 GMT): swcurran (Tue, 26 Jun 2018 15:11:23 GMT): mhailstone (Tue, 26 Jun 2018 15:52:31 GMT): swcurran (Tue, 26 Jun 2018 16:01:40 GMT): swcurran (Tue, 26 Jun 2018 16:24:45 GMT): burdettadam (Tue, 26 Jun 2018 17:22:32 GMT): dbluhm (Tue, 26 Jun 2018 18:14:59 GMT): dbluhm (Tue, 26 Jun 2018 18:15:23 GMT): PhillipGibb (Tue, 26 Jun 2018 18:51:14 GMT): PhillipGibb (Tue, 26 Jun 2018 18:52:48 GMT): swcurran (Tue, 26 Jun 2018 19:05:06 GMT): swcurran (Tue, 26 Jun 2018 19:05:06 GMT): dbluhm (Tue, 26 Jun 2018 19:08:28 GMT): mjmckean (Tue, 26 Jun 2018 19:16:25 GMT): PhillipGibb (Tue, 26 Jun 2018 19:18:28 GMT): dbluhm (Tue, 26 Jun 2018 19:18:55 GMT): mjmckean (Tue, 26 Jun 2018 19:19:12 GMT): swcurran (Tue, 26 Jun 2018 22:18:34 GMT): wangdong (Thu, 28 Jun 2018 01:45:20 GMT): saholman (Thu, 28 Jun 2018 21:39:15 GMT): saholman (Thu, 28 Jun 2018 21:42:49 GMT): RyanWest (Thu, 28 Jun 2018 22:48:35 GMT): arunwij (Fri, 29 Jun 2018 05:52:57 GMT): drummondreed (Fri, 29 Jun 2018 06:30:03 GMT): Sean_Bohan (Fri, 29 Jun 2018 08:39:08 GMT): drummondreed (Fri, 29 Jun 2018 08:42:23 GMT): Sean_Bohan (Fri, 29 Jun 2018 08:43:00 GMT): nage (Fri, 29 Jun 2018 14:00:00 GMT): saholman (Fri, 29 Jun 2018 14:02:32 GMT): saholman (Fri, 29 Jun 2018 14:06:09 GMT): hvandurme (Fri, 29 Jun 2018 14:23:49 GMT): nage (Fri, 29 Jun 2018 14:27:34 GMT): nage (Fri, 29 Jun 2018 14:27:38 GMT): nage (Fri, 29 Jun 2018 14:32:09 GMT): hvandurme (Fri, 29 Jun 2018 14:34:11 GMT): saholman (Fri, 29 Jun 2018 14:37:10 GMT): saholman (Fri, 29 Jun 2018 14:56:57 GMT): hvandurme (Fri, 29 Jun 2018 16:15:02 GMT): hvandurme (Fri, 29 Jun 2018 16:15:37 GMT): saholman (Fri, 29 Jun 2018 16:16:40 GMT): hvandurme (Fri, 29 Jun 2018 16:17:25 GMT): dbluhm (Fri, 29 Jun 2018 16:21:33 GMT): swcurran (Fri, 29 Jun 2018 16:26:09 GMT): dbluhm (Fri, 29 Jun 2018 16:27:47 GMT): swcurran (Fri, 29 Jun 2018 16:28:05 GMT): dbluhm (Fri, 29 Jun 2018 16:32:52 GMT): kdenhartog (Fri, 29 Jun 2018 16:34:56 GMT): dbluhm (Fri, 29 Jun 2018 16:40:42 GMT): kdenhartog (Fri, 29 Jun 2018 16:42:41 GMT): kdenhartog (Fri, 29 Jun 2018 16:44:59 GMT): dbluhm (Fri, 29 Jun 2018 16:47:32 GMT): kdenhartog (Fri, 29 Jun 2018 16:48:18 GMT): swcurran (Fri, 29 Jun 2018 16:58:45 GMT): swcurran (Fri, 29 Jun 2018 16:58:45 GMT): swcurran (Fri, 29 Jun 2018 16:58:45 GMT): swcurran (Fri, 29 Jun 2018 16:59:40 GMT): dbluhm (Fri, 29 Jun 2018 17:07:50 GMT): dbluhm (Fri, 29 Jun 2018 17:08:44 GMT): swcurran (Fri, 29 Jun 2018 17:14:45 GMT): dbluhm (Fri, 29 Jun 2018 17:20:53 GMT): swcurran (Fri, 29 Jun 2018 17:36:43 GMT): kdenhartog (Fri, 29 Jun 2018 17:38:35 GMT): dbluhm (Fri, 29 Jun 2018 17:52:21 GMT): mhailstone (Fri, 29 Jun 2018 23:27:43 GMT): mhailstone (Fri, 29 Jun 2018 23:29:10 GMT): mhailstone (Fri, 29 Jun 2018 23:34:06 GMT): kdenhartog (Fri, 29 Jun 2018 23:34:24 GMT): mhailstone (Fri, 29 Jun 2018 23:37:36 GMT): kdenhartog (Fri, 29 Jun 2018 23:38:26 GMT): kdenhartog (Fri, 29 Jun 2018 23:40:57 GMT): kdenhartog (Fri, 29 Jun 2018 23:59:45 GMT): kdenhartog (Sat, 30 Jun 2018 00:03:04 GMT): swcurran (Sat, 30 Jun 2018 03:19:11 GMT): swcurran (Sat, 30 Jun 2018 03:35:14 GMT): kdenhartog (Sat, 30 Jun 2018 03:38:39 GMT): nage (Sat, 30 Jun 2018 04:18:10 GMT): mhailstone (Sat, 30 Jun 2018 19:34:34 GMT): mhailstone (Sat, 30 Jun 2018 20:18:53 GMT): mhailstone (Sat, 30 Jun 2018 20:20:18 GMT): nage (Sun, 01 Jul 2018 17:28:03 GMT): hvandurme (Mon, 02 Jul 2018 07:05:50 GMT): ArthurManz (Mon, 02 Jul 2018 08:16:17 GMT): mhailstone (Mon, 02 Jul 2018 15:18:08 GMT): VitalijReicherdt (Tue, 03 Jul 2018 09:44:29 GMT): ThomasKrech (Tue, 03 Jul 2018 09:44:33 GMT): VitalijReicherdt (Tue, 03 Jul 2018 12:33:26 GMT): hvandurme (Tue, 03 Jul 2018 12:37:00 GMT): VitalijReicherdt (Tue, 03 Jul 2018 12:43:59 GMT): hvandurme (Tue, 03 Jul 2018 12:45:52 GMT): VitalijReicherdt (Tue, 03 Jul 2018 12:47:03 GMT): VitalijReicherdt (Tue, 03 Jul 2018 12:49:15 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:17:25 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:18:21 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:18:28 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:18:28 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:20:20 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:21:44 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:21:47 GMT): VitalijReicherdt (Tue, 03 Jul 2018 17:24:35 GMT): mjmckean (Tue, 03 Jul 2018 18:23:04 GMT): VitalijReicherdt (Tue, 03 Jul 2018 21:33:03 GMT): VitalijReicherdt (Tue, 03 Jul 2018 21:33:03 GMT): PhillipGibb (Wed, 04 Jul 2018 04:14:18 GMT): VitalijReicherdt (Wed, 04 Jul 2018 06:19:07 GMT): Marcus1 (Wed, 04 Jul 2018 06:47:13 GMT): VitalijReicherdt (Wed, 04 Jul 2018 08:16:42 GMT): PhillipGibb (Wed, 04 Jul 2018 08:27:21 GMT): VitalijReicherdt (Wed, 04 Jul 2018 08:40:30 GMT): VitalijReicherdt (Wed, 04 Jul 2018 08:42:11 GMT): VitalijReicherdt (Wed, 04 Jul 2018 08:58:19 GMT): PhillipGibb (Wed, 04 Jul 2018 09:00:27 GMT): PhillipGibb (Wed, 04 Jul 2018 09:06:11 GMT): VitalijReicherdt (Wed, 04 Jul 2018 09:08:06 GMT): PhillipGibb (Wed, 04 Jul 2018 09:12:17 GMT): PhillipGibb (Wed, 04 Jul 2018 09:12:35 GMT): PhillipGibb (Wed, 04 Jul 2018 09:13:11 GMT): BreizhIndy (Wed, 04 Jul 2018 12:22:28 GMT): BreizhIndy (Wed, 04 Jul 2018 12:41:22 GMT): VitalijReicherdt (Wed, 04 Jul 2018 13:17:39 GMT): VitalijReicherdt (Wed, 04 Jul 2018 13:17:39 GMT): VitalijReicherdt (Wed, 04 Jul 2018 13:17:39 GMT): VitalijReicherdt (Wed, 04 Jul 2018 14:52:00 GMT): BreizhIndy (Wed, 04 Jul 2018 15:17:31 GMT): PhillipGibb (Wed, 04 Jul 2018 20:12:50 GMT): nage (Thu, 05 Jul 2018 14:34:50 GMT): nage (Thu, 05 Jul 2018 14:46:29 GMT): herveblanc (Thu, 05 Jul 2018 15:54:15 GMT): jljordan_bcgov (Thu, 05 Jul 2018 15:55:39 GMT): kdenhartog (Thu, 05 Jul 2018 16:02:14 GMT): saholman (Thu, 05 Jul 2018 21:49:26 GMT): saholman (Thu, 05 Jul 2018 21:49:26 GMT): saholman (Thu, 05 Jul 2018 21:54:49 GMT): swcurran (Thu, 05 Jul 2018 23:18:52 GMT): swcurran (Thu, 05 Jul 2018 23:19:34 GMT): mhailstone (Fri, 06 Jul 2018 00:24:38 GMT): drummondreed (Fri, 06 Jul 2018 04:57:28 GMT): MALodder (Fri, 06 Jul 2018 04:57:28 GMT): BreizhIndy (Fri, 06 Jul 2018 13:45:16 GMT): saholman (Fri, 06 Jul 2018 13:59:28 GMT): nhelmy (Fri, 06 Jul 2018 16:36:18 GMT): burdettadam (Fri, 06 Jul 2018 16:40:23 GMT): dbluhm (Fri, 06 Jul 2018 16:40:32 GMT): burdettadam (Fri, 06 Jul 2018 16:41:13 GMT): mhailstone (Fri, 06 Jul 2018 16:55:33 GMT): dbluhm (Fri, 06 Jul 2018 17:56:53 GMT): dbluhm (Fri, 06 Jul 2018 17:56:58 GMT): swcurran (Fri, 06 Jul 2018 19:10:59 GMT): swcurran (Fri, 06 Jul 2018 20:34:09 GMT): swcurran (Fri, 06 Jul 2018 20:34:09 GMT): ryanwest6 (Fri, 06 Jul 2018 21:05:54 GMT): ryanwest6 (Fri, 06 Jul 2018 21:05:54 GMT): ryanwest6 (Fri, 06 Jul 2018 21:05:54 GMT): swcurran (Fri, 06 Jul 2018 22:01:15 GMT): swcurran (Fri, 06 Jul 2018 22:01:15 GMT): dbluhm (Fri, 06 Jul 2018 22:19:11 GMT): ryanwest6 (Fri, 06 Jul 2018 22:19:29 GMT): swcurran (Sat, 07 Jul 2018 19:41:47 GMT): swcurran (Sat, 07 Jul 2018 19:45:30 GMT): tomislav (Sun, 08 Jul 2018 18:29:31 GMT): danielhardman (Mon, 09 Jul 2018 01:44:26 GMT): danielhardman (Mon, 09 Jul 2018 01:44:26 GMT): danielhardman (Mon, 09 Jul 2018 01:44:26 GMT): danielhardman (Mon, 09 Jul 2018 01:44:26 GMT): danielhardman (Mon, 09 Jul 2018 01:46:24 GMT): danielhardman (Mon, 09 Jul 2018 01:48:02 GMT): danielhardman (Mon, 09 Jul 2018 01:52:30 GMT): danielhardman (Mon, 09 Jul 2018 01:52:30 GMT): gudkov (Mon, 09 Jul 2018 14:41:29 GMT): saholman (Mon, 09 Jul 2018 14:48:26 GMT): ghouston10 (Mon, 09 Jul 2018 15:05:48 GMT): ghouston10 (Mon, 09 Jul 2018 16:09:00 GMT): danielhardman (Mon, 09 Jul 2018 16:15:28 GMT): danielhardman (Mon, 09 Jul 2018 16:15:28 GMT): danielhardman (Mon, 09 Jul 2018 16:15:28 GMT): dbluhm (Mon, 09 Jul 2018 16:19:03 GMT): swcurran (Mon, 09 Jul 2018 16:45:12 GMT): swcurran (Mon, 09 Jul 2018 16:47:03 GMT): saholman (Mon, 09 Jul 2018 16:47:26 GMT): mhailstone (Mon, 09 Jul 2018 19:32:05 GMT): mhailstone (Mon, 09 Jul 2018 19:41:53 GMT): mhailstone (Mon, 09 Jul 2018 19:41:53 GMT): swcurran (Mon, 09 Jul 2018 19:47:39 GMT): gudkov (Tue, 10 Jul 2018 08:09:48 GMT): ghouston10 (Tue, 10 Jul 2018 08:30:33 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): ThomasKrech (Tue, 10 Jul 2018 09:16:41 GMT): sklump (Tue, 10 Jul 2018 12:28:46 GMT): sklump (Tue, 10 Jul 2018 12:29:18 GMT): gudkov (Tue, 10 Jul 2018 13:23:04 GMT): ThomasKrech (Tue, 10 Jul 2018 13:35:31 GMT): sklump (Tue, 10 Jul 2018 13:38:42 GMT): TelegramSam (Tue, 10 Jul 2018 13:46:50 GMT): MALodder (Tue, 10 Jul 2018 14:10:10 GMT): AvikHazra (Tue, 10 Jul 2018 14:19:28 GMT): AvikHazra (Tue, 10 Jul 2018 14:19:28 GMT): swcurran (Tue, 10 Jul 2018 14:46:21 GMT): mhailstone (Tue, 10 Jul 2018 14:47:31 GMT): tomislav (Tue, 10 Jul 2018 19:01:33 GMT): tomislav (Tue, 10 Jul 2018 19:02:15 GMT): n3m4nja (Wed, 11 Jul 2018 06:54:18 GMT): n3m (Wed, 11 Jul 2018 07:32:11 GMT): ghouston10 (Wed, 11 Jul 2018 10:01:11 GMT): n3m (Wed, 11 Jul 2018 10:26:46 GMT): n3m (Wed, 11 Jul 2018 10:26:46 GMT): n3m (Wed, 11 Jul 2018 10:27:22 GMT): ghouston10 (Wed, 11 Jul 2018 10:57:12 GMT): ghouston10 (Wed, 11 Jul 2018 10:57:41 GMT): n3m (Wed, 11 Jul 2018 11:11:27 GMT): n3m (Wed, 11 Jul 2018 11:12:22 GMT): n3m (Wed, 11 Jul 2018 11:12:37 GMT): saholman (Wed, 11 Jul 2018 14:03:08 GMT): saholman (Wed, 11 Jul 2018 14:12:09 GMT): saholman (Wed, 11 Jul 2018 14:12:09 GMT): ghouston10 (Wed, 11 Jul 2018 14:42:30 GMT): ghouston10 (Wed, 11 Jul 2018 15:04:30 GMT): ghouston10 (Wed, 11 Jul 2018 15:20:09 GMT): mhailstone (Wed, 11 Jul 2018 19:16:56 GMT): kdenhartog (Wed, 11 Jul 2018 21:17:43 GMT): kdenhartog (Wed, 11 Jul 2018 21:18:52 GMT): swcurran (Wed, 11 Jul 2018 22:02:24 GMT): kdenhartog (Thu, 12 Jul 2018 01:41:05 GMT): AxelNennker (Thu, 12 Jul 2018 04:37:22 GMT): AvikHazra (Thu, 12 Jul 2018 05:19:51 GMT): AvikHazra (Thu, 12 Jul 2018 05:19:51 GMT): nikhil.kumar (Thu, 12 Jul 2018 05:37:09 GMT): danielhardman (Thu, 12 Jul 2018 09:22:27 GMT): danielhardman (Thu, 12 Jul 2018 09:22:27 GMT): danielhardman (Thu, 12 Jul 2018 09:39:41 GMT): danielhardman (Thu, 12 Jul 2018 10:23:48 GMT): TelegramSam (Thu, 12 Jul 2018 13:39:28 GMT): swcurran (Thu, 12 Jul 2018 14:50:11 GMT): ksista (Thu, 12 Jul 2018 16:33:23 GMT): Sean_Bohan (Thu, 12 Jul 2018 16:40:10 GMT): ryanwest6 (Thu, 12 Jul 2018 17:55:45 GMT): n3m (Thu, 12 Jul 2018 19:32:18 GMT): mhailstone (Thu, 12 Jul 2018 23:59:13 GMT): mhailstone (Thu, 12 Jul 2018 23:59:13 GMT): danielhardman (Fri, 13 Jul 2018 02:09:17 GMT): danielhardman (Fri, 13 Jul 2018 02:09:17 GMT): sammitchell (Fri, 13 Jul 2018 07:43:23 GMT): VitalijReicherdt (Fri, 13 Jul 2018 08:34:47 GMT): VitalijReicherdt (Fri, 13 Jul 2018 08:35:17 GMT): ghouston10 (Fri, 13 Jul 2018 10:48:25 GMT): VitalijReicherdt (Fri, 13 Jul 2018 11:10:23 GMT): VitalijReicherdt (Fri, 13 Jul 2018 11:16:16 GMT): VitalijReicherdt (Fri, 13 Jul 2018 11:16:16 GMT): ghouston10 (Fri, 13 Jul 2018 11:51:17 GMT): danielhardman (Fri, 13 Jul 2018 11:59:07 GMT): danielhardman (Fri, 13 Jul 2018 11:59:07 GMT): danielhardman (Fri, 13 Jul 2018 11:59:07 GMT): swcurran (Fri, 13 Jul 2018 12:25:06 GMT): swcurran (Fri, 13 Jul 2018 12:29:05 GMT): danielhardman (Fri, 13 Jul 2018 12:51:08 GMT): mhailstone (Fri, 13 Jul 2018 13:52:52 GMT): swcurran (Fri, 13 Jul 2018 16:06:46 GMT): swcurran (Fri, 13 Jul 2018 16:06:46 GMT): kendra.bittner (Fri, 13 Jul 2018 16:40:03 GMT): mhailstone (Fri, 13 Jul 2018 16:59:34 GMT): mhailstone (Fri, 13 Jul 2018 17:41:44 GMT): mhailstone (Fri, 13 Jul 2018 17:41:44 GMT): mhailstone (Fri, 13 Jul 2018 17:41:44 GMT): mhailstone (Fri, 13 Jul 2018 17:48:33 GMT): kdenhartog (Fri, 13 Jul 2018 19:03:47 GMT): kdenhartog (Fri, 13 Jul 2018 19:03:47 GMT): swcurran (Fri, 13 Jul 2018 19:04:26 GMT): kdenhartog (Fri, 13 Jul 2018 19:04:47 GMT): swcurran (Fri, 13 Jul 2018 19:07:56 GMT): danielhardman (Sat, 14 Jul 2018 18:36:25 GMT): darrell.odonnell (Sat, 14 Jul 2018 19:05:54 GMT): DoctorX (Sun, 15 Jul 2018 12:37:48 GMT): kdenhartog (Mon, 16 Jul 2018 19:23:59 GMT): kdenhartog (Mon, 16 Jul 2018 19:23:59 GMT): kdenhartog (Mon, 16 Jul 2018 19:23:59 GMT): kdenhartog (Mon, 16 Jul 2018 20:10:19 GMT): swcurran (Mon, 16 Jul 2018 21:21:17 GMT): swcurran (Mon, 16 Jul 2018 21:21:17 GMT): sativ (Tue, 17 Jul 2018 08:46:51 GMT): alanz (Wed, 18 Jul 2018 06:46:53 GMT): ghouston10 (Wed, 18 Jul 2018 13:41:42 GMT):
Stephen - small company wants to delegate roles, permissions, claims around employees of the company
got to be perceived by the person they are talking to as an organization
org needs to control how to do things
5 accounts, 5 govt orgs, roles and permissions - "we fired dave" - Agent should remove Dave from having access claims company agent has and you are done
Nathan - whatever the root ID of the org can revoke any creds it has access to
can give Dave access in any context where they trust that cred, go back and say " revoking now" and strong assurance
any checking endpoint to endpoint can validate that has been removed from the ledger
THANKS ALEX
Any other Questions?
Stephan Curran - grappling with Wallets, have a claims store in their use case, entitit that will hold claims about many subjects
not like a person having their own wallet
is the wallet part of the SDK and abstracted away or can they access claoims to persist in their own way and use SDK to exchange claims as necessary, where does the wallet come into play
Nathan - SDK provides wallet API - inteface - any implementation of an agent can provide its own implementation of a wallet in place
different enterprises, want to keep data where it is already being managed and correctly as opposed to making a diff wallet it is more secure to use what you currently have and business processes have been thought through
Symon - some wrapper implmentations have incorporated wallets
Nathan - default is simple (Sql Lite) moving to Sql Cypher
https://www.zetetic.net/sqlcipher/
SQL Cipher https://www.zetetic.net/sqlcipher/
thanks swcurran!
Nathan
Token work, merge requests, make new implmentations possible in agent space
Lot of relevant standards work on DIDs, etc.
Token work - to prevent spam in the system, helpful if there is cost to posting transactions to the ledger
investigating idea of spam protection, tokens can be solution to lots of interesting things
Need to make sure the token doenst undermine privacy
one time use of token - same types of tech that backs anoncreds does 1-time transfer of secrets, you can mint value on a ledger, declare it exists and what it represents, can have token owned without revealing owner
credit card network with access to info and data flows, selectively disclose info if somone is willing to pay for it, may charge $.001 if a transaction is risky, willing to sign info
simple as university transcript, Uni charges money for , value transfer occurs on the ledger in privacy preserving way
value transfer between parties, issue can give data to a holder an dpresent proof to relying party and relying party can exchange tokens to get access to the data, gives issue incentives to issue to share in order to get paid (by users sharing creds)
in the process of vetting out the crypto required to do that and add right hooks into system to ask for tokens to pay for validator nodes, prevent spam, allow hooks to make claims and proofs exchange can require token exchange for premium claims or proofs
other piece - new project proposing to be included in HL called INTERLEDGER - atomic value exchange between ledgers
reviewing code from Lovesh or Dmitry, see new code reorgs to make these constructs possible, work coming in the next few months
Questions?
Matthew - discounts for Stewards for tokens?
Nathan - not privy to how we are minting tokens, or distributing - right people to get in touch would be timothy, or trustees on Sovrin foundation
MatthewH - sugggesting is to protect against spam, stewards are resp players on ledger, not create bad claims and dirty up, they are reliable, give them a discount, proven to be responsibel
Nathan - we want stewards who run validator nodes to be rewarded for doing work as part of their effort
Darrel - overall incentives for all players - goal is to be fair and make sense (refugees who can't pay, to groups who are paying )
themes discussed - if you look at bitcoin or ethereum, cost of transactions so high, want to have incentives so it doesn't happen
https://w3c-ccg.github.io/did-spec/
?
Nathan - DID Support
Changes to DID spec
housed in W3C community group, github repo for that spec, different ledgers using that spec
folks locked in a room, hashing out difference for how each can use and leverage to make things work well
held off on implementing DIDs in JSON format
DID Spec as written, using DID support to help move anoncreds move to something compliant with the W3C WG initiatives
suggesting changes so our anoncreds can meet that spec
plug into either effort (W3C Credentials Community Group) or following W3C Ver Claims WG mailing list
Darrel - how radical will changes be at SDK level?
Nathan - mostly on the wire serialization
some blocks of JSON we pass to those calls, we may change a little bit, will ask for feedback from this group to see how much they are depending on old formats and see if we can drop old and move to new
push all to more standards compliant versions without dealing with the old stuff
other format - speak up -
Darrel - on our side - planning on churn in data format
more consistent more easy
THANKS EVERYON
Indy Agent Working Group call is now closed
Has joined the channel.
Has joined the channel.
Folks, I just read the notes above (sorry I couldn't make it - have been helping put on the DHS Blockchain Workshop in DC) and the good news is that, while the DID spec will be changing a little, most of it will be to make the underlying RDF graph model consistent and extensible everywhere in the same way. The net effect will be relatively small - as Nathan says, it will be mostly in the JSON-LD serialization.
Has joined the channel.
Has joined the channel.
There was some discussion earlier regarding javascript and/or node.js client. Has there been any progress? IIRC at least @peacekeeper was in that discussion.
@ewelton was working on something for node.js here: https://github.com/korsimoro/indy-sdk - there was some discussion about it in the indy-sdk channel a while ago.
There's a readme for it here: https://github.com/korsimoro/indy-sdk/tree/init-node-wrapper/wrappers/node
Thanks @srottem
Has joined the channel.
Has joined the channel.
At IIW more folks have expressed interest in this wrapper. @ewelton any update on your progress or what interested folks can do to help?
Folks:
Hyperledger Indy Agents WG Call TODAY
8amPT, 9amMT, 11amET, 4pm BST.
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
This will be a shorter call than usual as most of our normal attendees are at Internet Identity Workshop.
https://docs.google.com/spreadsheets/d/1vGJ1VwOQSgwzEnq0Gej3eu7InbUn1CYOOKt0hm80nTM/edit#gid=0
Has joined the channel.
Has joined the channel.
Has joined the channel.
@ashcherbakov I requested access to the memo of the agent calls. I am working in the TrustNet project [1] in Finland and would be interested to follow a bit how the agent development is going.
[1] https://sovrin.org/sovrin-foundation-finlands-trustnet-join-forces-build-trust-network-distributed-personal-data-management
The doc mentioned above is a bit outdated. Please find the latest doc from the last Thursday meeting:
https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit#gid=0
Has joined the channel.
Folks:
Hyperledger Indy Agents WG Call TODAY
8amPT, 9amMT, 11amET, 4pm BST.
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Today's Agenda:
Housekeeping (Sean)
Development Status (Alex)
Universal Resolver discussion with Markus (@peacekeeper)
Indy Roadmap discussion (Nathan, Sean)
= Begin meeting notes=
Linux Foundation Anti-trust policy
Upcomming events
TPAC
Hyperledger Hackfest
Zoom_2017-11-02_05-06-53.png
https://www.edx.org/course/blockchain-business-introduction-linuxfoundationx-lfs171x
IIW Workshop Updates
Book of IIW Proceedings will be posted here when available.
Photos from Conference from the amazing Doc Searls https://www.flickr.com/photos/docsearls/albums/72157665717723489
Folder Locations are changing. Work has been done to migrate to the new locations, but please be aware.
Master branch contains the changes before they are merged into Stable.
https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit#gid=0
https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=133&projectKey=INDY&selectedIssue=INDY-754
https://jira.hyperledger.org/secure/RapidBoard.jspa?projectKey=IS&rapidView=149
@Sean_Bohan would you give me or @stevetolman a few minutes to talk about cardwall changes in JIRA?
Alex giving updates
Testing Pipeline improvements.
@ashcherbakov could you put a link to the hyperledger jenkins here?
agent to agent comms
preparation of message, and sending of message are two different steps.
should be transport agnostic, including insecure transport.
totally not complete notes here... check meeting recording for full details.
[I need to drop off the call earlier than expected...]
The PRs to move to hyperledger Jenkins are still in review, so we will fully move to Hyperledger's Jira once they are merged.
I will let folks know when it happens.
Markus has been doing awesome work with the Decentralized Identity Foundation on the Universal Resolver, and will present to us about what is happening there.
Sovrin and Hyperledger are both members of DIF, and the group has made a lot of progress on this Universal Resolver
https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c
Markus created a blog post with a preview of the universal resolver. The idea is to have a tool that resolves DID
DIDs are a fundamental building block for self-sovereign identity used to refer to individuals, organizations and things
and they can be resolved to a particular thing
they contain cryptographic information, service endpoints, or basically the data you need to talk to the entity that owns this identifier
each method that supports DIDs has different advantages and disadvantages
this means you can have verifiable claims or agents that communicate between identifiers that are on different chains
peacekeeper: the universal resolver will do all the hard work to resolve the did according to the method specification
... in some ways it is very easy to do if the ledger supports the format natively. In others, like btcr, when the document isn't on the ledger or anywhere else really, the did document exists in a way that has to be deterministically constructed from the information on the ledger and elsewhere. In this case btcr puts the essential key information on ledger, and the driver follows standard references to retrieve the rest of the information, verify integrity and then return the constructed document.
... in some cases the driver might run a full ledger node to get all the information, in other setups the driver may just call another remote web service
... there are different options with different trust implications
... this is an "early preview" if we can call it that
... there are drivers for six different did methods
... I can't do a demo without my screenshare, but it isn't working from the linux box right now
... we have a docker compose file that builds the java implementation of the universal resolver and assembles and orchestrates the individual drivers and launches everything locally
... using the curl commands you see here you can resolve different DIDs
... whatever did you pass in, you get the corresponding did document
... there are a lot of changes going on in the did specification right now, and they all implement different formats of did documents right now, and we're working on resolving those differences now
... we are working to figure out what kind of process and versioning we'll need here to ensure the returned values meet the right format
Thank you for the overview Markus!
Sean: any questions about what this is, or where it is going in the future?
peacekeeper: the idea is to build a counterpart to the resolver called a registrar that would add an identifier to a ledger
... there are more parameters and possibly manual steps by the identity owner to prepare these types of calls
... for example agreeing to an identity owner agreement and finding a trust anchor on sovrin
... or registering on bitcoin's chain costs bitcoin that needs to come from a wallet
... there is some text and design materials starting to come together here, but it will take more time
johnjordan42: we are going to try to use this resolver, and we now have a working early agent and successfully done agent to agent communication and verified and issued claims
... we had to write our own did resolver, which we are now talking to DIF about
... we want to use this resolver for the proof of concept we're working on
Sean: any updates in Rocket.Chat are very welcome
... any more comments or questions for Markus?
... The next item is the roadmap for Indy
@here please add what you want to work on to this roadmap and jump into the sprint process if you're working on any core functionality for Indy or Sovrin
Sean: I will share this graphic (the 2017 roadmap slide) on rocket chat
Development Status:
https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit#gid=0
@Peacekeeper’s “A Universal Resolver for self-sovereign identifiers“ Post:
https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c
Hey all, I'm going to be relocating to Australia this weekend for around 6 months so I'm most likely to be absent from the majority of calls going forward - at least until I'm back in France next year. I'll still be on Rocketchat but will be less likely to be responding in real-time.
Recording of today's meeting here: https://drive.google.com/open?id=0B0boW7wc5MQ9RHM3N0puWE1ETkE
@Sean_Bohan - will you be posting the roadmap slides that were on the call? I think you said you would - wanted to confirm. Thx
YES - getting permissions set on the doc now
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=spniyZPgGxccziRS7) @srottem Safe travels! We post the videos of the calls if you want to listen in
I'll definitely be reviewing them and will post questions here if I have any. Cheers!
ALL INDY AGENT FOLKS:
Here is a PDF of the draft roadmap. Nothing is final, all comments welcome (here). We will also be sharing this next week on the call
https://drive.google.com/open?id=0ByaxIFopqmUVRkhyRWZ1X0RpQ1U
@Sean_Bohan Thanks this is very useful.
The third slide says "Indy Universal Resolver".. Is this the DIF Universal Resolver we talked about today, or something else?
Has joined the channel.
I think the answer there is we're not entirely certain. It is likely the DIF resolver for now, but should we consider adding some sort of universal resolver functionality into indy-sdk? It might be worth considering, though we'd likely want to do it in a more native c-callable way.
Has joined the channel.
Has joined the channel.
All: Facing a problem while trying to setup the 4 Node sample cluster : I am at the step "Starting the agent process" fro the page : https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md
Error Seen is : ```vagrant@agent01:~$ python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 5555
python3: can't open file '/usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py': [Errno 2] No such file or directory
vagrant@agent01:/usr/local/lib/python3.5/dist-packages$ cd in
indy_anoncreds-1.0.10.egg-info/ indy_plenum-1.1.27.egg-info/ intervaltree-2.1.0.egg-info/
indy_node-1.1.43.egg-info/ intervaltree/
vagrant@agent01:/usr/local/lib/python3.5/dist-packages$ ``` - Request any help to see why the indy_client folder is missing
@sreekanthn I will take a look at this. Meanwhile, take a look at https://github.com/brycecurtis/indy-tutorial-sandbox for a nice docker setup for this that has been contributed by some community members.
THIS week we have the Indy Agent WG Call on Thursday November 16, 2017
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Report from W3C TPAC (Nathan and Drummond)
D. Report from Hyperledger Community Summit (Phil Windley, Sovrin Foundation)
E. Dave Huesby from Hyperledger on American Fuzzy Lop and Fuzzing in Hyperledger
F. Wrap Up
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
November 16, 2017
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Please note: This meeting will be recored
Bring a friend. It will be fun.
- Hyperledger Indy Community
Hyperledger Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Thanks @mgbailey ! I will check the docker option today, thanks for the alternative.
The docker based setup worked fine for me on Macbook Pro; this one was really smooth to get up and running. @mgbailey Thanks a lot for the help !
Indy Agent call for 11/16/2017
NOTES:
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=0
TPAC Update
Member confidentiality but here is what we can say
F2F meetings on VerClaims very productive
JSON linked Data model doesnt work for selective disclosure
in person meetings able to describe how pieces work, get buy-in from community supporting data model for selective disclosure
open invite to make PRs to W3C community to make changes
Lot of interest and broad support for privacy preservation in DIDs in respect to community group
more momentum there to take pieces and put into standards track items
lot of interesting things going on, support for things so far
aware of community group for HTTPS- Local
participants from electronics manufactrers
similar needs to what we need for DID TLS
IETF task group working on STAR PRotocol - will
lot of support for fixing dns
layer or mech to own layer via DID would be valuable
not a real strong pref if that piece of the ecosystem needs to be TCP
might move into IETF area, how standardization might proceed
DIDs and identity based interactions at W3C is very web centric
name might resolve to DID and then IP address
Standards more web-like, or webby is being thought about
https://www.w3.org/community/httpslocal/
Member summit Singapore
good group, fun to put faces to names
overall a lot of interest in Indy - people referencing it
known in hyperledger community
talking about
https://w3c-ccg.github.io/
opportunity to spend time with ChrisF and original contribs of FABRIC (HL's first?)
talked about how he was doing experiments with indy on top of fabric, provide identity solutions inside fabric
avoid having every ledger in HL build their own ID - why they approached Indy
first day - use cases
second day - tech issues
https://github.com/httpslocal
uses - Fintech still dominates a lot of the discussions
Interesting panels on asset security, using it for regtech, logisitics
using in china for small and medium enterprise loans to connect processors in fin sector and regulators
panel on privacy
Dave Huseby was moderator
SSI implies control, cant have control without privacy
key part of what makes indy special
breakout on SSI later in the afternoon, 15 people from various devs and contributors
grt questions, grt opportunity to discuss indy priv features in more detail, good questions on how it works, how DIDs work, why Indy does things the way it does
Privacy and control connection
Technology AND regulation issues
problem of priv is not when voluntarily consented, but when tech doesnt give you proper tools to manage what you do and dont reveal
ROUVEN: priv can be solved on social and legal level, even tech side, needs to be built into the ledger, others think not
can do parts off-chain completely
can put things into one layer and solve in a different one
can solve priv by sharing and selectively disclose in other ways
NATHAN - agree, data not on the ledger
@Rouven we would love to talk about these techniques. Bring all good ideas and approaches!
easy for parties to collude to triangulate data
pairwise ID limit context that you bound the attributes to, from crypto protocol perspective, you can limit
PHIL - agree - lot of layers and approaches to each
ROUVEN - there are good solutions in Indy, but there might be diff solutions addressing same problem
one of the reqs
can solve with pairwise
good reasons why usefule
some reasons TO correlate things
and yes, there are legal trust framework tools that are critical
flip side - everything with pairwise, need to maintain good accounting system of who has seen what, revealed what - complexity
if someone needs to manage complexity it could be a user or third party - who is managing
not one answer, why do we try to force this is the solution
always a trade-off, no absolutes
@Rouven++ these discussions are a major purpose for these calls, thanks for the discussion
PHIL - Indy is a grand experiment to seeing how well that complexity can be managed
JohnBC - arent we able to be issuers of our own consent, if someone has my data illegal or otherwise w/o consetn, without my consent receipt for the use of that data - they are wrong
Rouven - especially in the EU
JohnBC - may have it, sold it
Rouven - like certain data gained via illegal means
also downsides for this approach
what is your attack vector? what optimizing for?
Every one has potential to correlate
move problem somewhere else
NATHAN - complexity trade-off - agree
DAVE HUSEBY
Fuzzing and American Fuzzy Lop
Proposal - Fuzzing in detail for Lisbon
findings and code for fuzzing the Indy Crypto library
Lib written in Rust
https://fuzzing-project.org/tutorial3.html
trying to trigger unexpected state changes in the software, giving data it wasnt expecting
American Fuzzy Lop homepage -
uses learning algo and code coverage to compromise
sends "buncha junk", measures how code responded, mutates junk to measure how the code reacts
coming up with instrumentation and code to run fuzzing against
Big enough to matter but small enough to complete
teach at hackfest, aall of the code in HL and building corpusces to test that software
hardest part of fuzzing, get an initial set of garbage data and write the code that wraps the lib you are fuzzing
havent gotten to point to run fuzzer against the lib
fuzzing meant to fill gap
NATHAN - build pipeline or code repos?
DaveH - popular, give it a random set of data, let it go runnign diff combinations, will find bugs, it optimizes corpus down to an executable set of code, make into unit tests
output is not a bunch of bugs, but repeatable tests
when it does find a bug and fix
using AFL - capability to test C, C++, Py, Javascript
2018 - year to fuzz all our code and translate into repeatable tests
AFL is a thing DaveH has come to as the last thing to do before you say "we are confident in the software)
Great to sit ringside and watch meeting whizzing by
AFL deployed against REST APIs
Get calls with garbage data and hung process - didnt crash but would be a DDoS vector, get server process to hang, resources exhausted, found wihtin a day
handled in confidential security handling system
Presented at Lisbon hackfest
not a zero-day, but deemed to be a mediaum to low risk
I'm here
Has joined the channel.
The recording of today's Indy Agent WG can be found here:https://drive.google.com/file/d/1_uMFQWfvyeNTVDb761seOZWzfvfBT7Jz/view?usp=sharing
Has joined the channel.
Is the forthcoming new agent2agent API (including listeners, connections, etc) currently best documented in wrappers/dotnet/indy-sdk-dotnet/AgentApi (branch feature/agent2agent_api_v2), or are there other (public) documents worth considering at this point?
That documentation is also available in web-consumable form here for the moment: https://srottem.github.io/indy-sdk/wrappers/dotnet/docs/api/Hyperledger.Indy.AgentApi.html
We're working on getting it hosted on the official hyperledger github at the moment.
Interesting thanks. That documentation does not reflect what is on the "feature/agent2agent_api_v2" branch. Does the AgentApi on that branch in the official indy-sdk repository reflect the forthcoming Agent API, or will it be something else?
Interesting. The Java wrapper on the feature/agent2agent_api_v2 branch is up to date but for some reason the the .NET wrapper changes haven't been pulled it. The documentation link I gave you accurately represents what's on master at the moment, which includes the new agent2agent API. @gudkov - should I re-open the PR for the .NET changes to get them pulled into that branch?
Interesting. The Java wrapper on the feature/agent2agent_api_v2 branch is up to date but for some reason the the .NET wrapper changes haven't been pulled it. The documentation link I gave you accurately represents what's on master at the moment, which includes the new agent2agent API. @gudkov - should I re-open the PR and it's associated branch for the .NET changes to get them pulled into feature/agent2agent_api_v2?
Interesting. The Java wrapper on the feature/agent2agent_api_v2 branch is up to date but for some reason the the .NET wrapper changes haven't been pulled in. The documentation link I gave you accurately represents what's on master at the moment, which includes the new agent2agent API. @gudkov - should I re-open the PR and it's associated branch for the .NET changes to get them pulled into feature/agent2agent_api_v2?
@srottem just open PR to master.
Indy Agent Folks:
TOMORROW is the Indy Agent WG Call - Thursday November 30, 2017
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C.DEMO and discussion with the team from British Columbia: @jljordan_bcgov and @swcurran
D. Wrap Up
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
November 30, 2017
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Please note: This meeting will be recored
Bring a friend. It will be fun.
- Hyperledger Indy Community
Hyperledger Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=am27m2yRiLNabweDL) @gudkov I don't seem to be able to as all the changes in the my branches have already been pulled into master. The branches in question are srottem:feature/dotnet_agent2agent_api_v2 and srottem:feature/dotnet_agent_tests_and_samples.
Has joined the channel.
Has joined the channel.
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=526493707
Has joined the channel.
Link to Google Docs folder with the presentations and videos from BC Government presentation on today's call - https://drive.google.com/open?id=0B4DUXk_qFFhvOHNUVUUwY0NYbkk
github links are in the "British Columbia..." Google Slides presentation.
Link to Google Docs folder with the presentations and videos from BC Government presentation on today's call -
https://drive.google.com/open?id=0B4DUXk_qFFhvOHNUVUUwY0NYbkk
github links are in the "British Columbia..." Google Slides presentation.
@gudkov Sorry about the question about node wrapper in the call. I am realizing that I was on the initial project in the https://github.com/korsimoro/indy-sdk.git repository. I have now switched to the https://github.com/hyperledger/indy-sdk.git repository.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=iuFQDQ89Lcic83XmJ) Do you have any plans to create PR?
Has joined the channel.
Is there have indy-base container image available at docker hub to pull?
Has joined the channel.
@gudkov We have not contributed to that project, so that's a good question.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ipGw2b7BxivnZyjTR) @Sean_Bohan Is it possible to get the recording and slides of the last Indy meeting on November 30?
@the_identity_guy the recording can be found here. https://drive.google.com/file/d/1w5v0Mtjnn-GsglXDSVhs3m9DSxlRR0DH/view?usp=sharing
Has joined the channel.
NEXT WEEK we have the Indy Agent WG Call - Thursday December 14, 2017
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Dave Huesby (@dhuesby ) and Nathan George (@nage ) will share their experiences at the Hyperledger Hackfest
D. Community Input discussion (Nathan)
D. Wrap Up
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
December 14, 2017
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Please note: This meeting will be recored
Bring a friend. It will be fun.
- Hyperledger Indy Community
Hyperledger Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy WG Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Next week is the Indy Agent WG Call
TOMORROW is the Indy Agent WG Call - Thursday December 14, 2017
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Dave Huesby (@dhuesby ) and Nathan George (@nage ) will share their experiences at the Hyperledger Hackfest
D. Community Input discussion (Nathan)
D. Wrap Up
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
November 30, 2017
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Please note: This meeting will be recored
Bring a friend. It will be fun.
- Hyperledger Indy Community
Hyperledger Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy WG Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Next week is the Indy Agent WG Call
TOMORROW is the Indy Agent WG Call - Thursday December 14, 2017
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Dave Huesby (@dhuesby ) and Nathan George (@nage ) will share their experiences at the Hyperledger Hackfest
D. Community Input discussion (Nathan)
D. Wrap Up
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
December 14, 2017
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Please note: This meeting will be recored
Bring a friend. It will be fun.
- Hyperledger Indy Community
Hyperledger Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy WG Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Has joined the channel.
Has joined the channel.
@Sean_Bohan agenda item for tomorrow: propose skipping calls Dec 21st, Dec 28th, and possibly Jan 4 due to end of year holidays (Christmas, New Years, Russia New Year Holiday)
3 weeks off? what will I do with all the free time?
#indy what do you think? no calls for 3 weeks?
@Sean_Bohan : Let me know what you decide so that I can remove them from the community calendar
Will know in a bit - need to let everyone know tomorrow
if we do
Has joined the channel.
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=970515928
https://github.com/evernym/sovrin-environments/tree/master/docker
On Mac OS, you need to modify the `client_for_pool_start.sh` script to use the `-E` option instead of the `-r` option on the `sed` command:
```if [ -z "$IP" ]; then
IP_REGEXP="([0-9]+\\.[0-9]+\\.[0-9]+\\.)([0-9]+)"
BASE_IP=$(echo "$LAST_NODE_IP" | sed -E "s/${IP_REGEXP}/\1/")
LAST_GROUP=$(echo "$LAST_NODE_IP" | sed -E "s/${IP_REGEXP}/\2/")
((LAST_GROUP++))
IP="${BASE_IP}${LAST_GROUP}"
fi
```
NodeJS wrapper initial project: https://github.com/korsimoro/indy-sdk.git
@mhailstone thanks for the NodeJS initial project link
This may be different then what @ewelton may have finished, but that was the project that was created from initial NodeJS wrapper calls.
The following procedure helped me complete the Getting Started guide on Mac OS:
* https://github.com/evernym/sovrin-environments/tree/master/docker
* https://github.com/evernym/sovrin-environments/blob/master/docker/StartIndyAgents.md
* https://github.com/hyperledger/indy-node/blob/stable/getting-started.md
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
No Indy WG Call Today!
Has joined the channel.
please note there is no Indy call today! We will reconvene next Thursday 1/11/18
I would like to run a local standalone indy-node in order to test a client/agent using the indy-sdk. Is that a good approach, or should I be testing against another running test ledger instance? If it's recommended to run a locally running ledger instance (probably with four nodes that are running locally), how would I set this up? Thanks in advance!
HI @mhailstone . A local pool is a good way to do test & development. If you have the RAM to support it, there are instructions and scripts to set up a 4 node pool locally using vagrant and virtualbox. This is what I use. Others use docker scripts that have been contributed by the community. https://github.com/evernym/sovrin-environments/blob/stable/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md
@mgbailey Thank you for the response. Could you point me to the docker scripts as well?
@mhailstone , @WadeBarnes just posted this in another channel:
You may also want to have a look at the work we've done here; https://github.com/bcgov/von-network
It's a 4 node pool and it adds a basic ledger explorer and a few other features.
Runs on Docker/Docker Compose
You can find a running instance here; http://138.197.170.136
Has joined the channel.
Perfect. Thanks @mgbailey!
Has joined the channel.
Has joined the channel.
I'm attempting to run the java samples in the `./hyperledger/indy-sdk/samples/java/src/main/java/Main.java` file. The `Agent.demo` works, but I'm failing in the `Anoncreds.demo` call with the error:
```ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with name "default_pool" already exists
Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name.
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at utils.PoolUtils.createPoolLedgerConfig(PoolUtils.java:47)
at Anoncreds.demo(Anoncreds.java:21)
at Main.main(Main.java:5)
Caused by: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name.
at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:109)
at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90)
at org.hyperledger.indy.sdk.pool.Pool.access$100(Pool.java:19)
at org.hyperledger.indy.sdk.pool.Pool$1.callback(Pool.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520)
at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)```
How can I delete the `default_pool`?
BTW, I am running the BC von-network nodes mentioned by @WadeBarnes and @mgbailey.
BTW, I am running the BC von-network nodes mentioned by @WadeBarnes and @mgbailey .
@mhailstone It is in ~/indy_sdk/sandbox/pools, or something similar. I don't have a vm running right now to make sure this path is exactly right.
Another approach would be to just do a try {} catch{} around that call. Do nothing if this error occurs, and execution will proceed normally.
This is what I do
@mgbailey I don't see a sandbox/pools directory, but I will implement the try/catch.
I implemented the try/catch, but now when the `Pool.openPoolLedger` call is invoked I get the following error:
```ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool work terminated
Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.pool.PoolLedgerTerminatedException: The pool ledger was terminated.
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895)
at Anoncreds.demo(Anoncreds.java:22)
at Main.main(Main.java:5)
Caused by: org.hyperledger.indy.sdk.pool.PoolLedgerTerminatedException: The pool ledger was terminated.
at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:101)
at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90)
at org.hyperledger.indy.sdk.pool.Pool.access$300(Pool.java:19)
at org.hyperledger.indy.sdk.pool.Pool$2.callback(Pool.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520)
at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)
```
I am working in python rather than java, but things should track pretty closely. I assume your error is in the "create_wallet" call?
excuese me, no
In the create_pool_ledger_config call?
If so, this is how I handle it:
'''
try:
await pool.create_pool_ledger_config(pool_name, pool_config)
except IndyError as err:
if (err.error_code == 306):
logger.warning("Pool %s already exists. Skipping create.", pool_name)
else:
raise
'''
I put a try/catch around the `Pool.createPoolLedgerConfig(DEFAULT_POOL_NAME, createPoolLedgerConfigJSONParameter.toJson()).get();` in PoolUtils.java:48, but now the exception happens in Anoncreds.java:22 `Pool pool = Pool.openPoolLedger(poolName, "{}").get();`
Strange. If the pool already exists, it should just be able to use the existing pool... I'll spin up a VM and find that path for you.
@mhailstone try deleting the directory ~/.indy_client/pool/default_pool
I stopped the von-network, deleted both the `pool` and `wallet` directories in the `~/.indy_client` directory restarted the von-network (./manage start) and I still get the above error when running the samples.
Has joined the channel.
@Sean_Bohan: are the call details (time and numbers) for the 1/11 meeting the same as you posted for Dec 14th?
Hey Aaron - I am posting that in a few mintuesw
same details though
ok, thanks
@mhailstone how is your java app connecting to the von-network? Do you have an example of your environment that I can look at?
THIS WEEK we have the Indy Agent WG Call - Thursday January 11, 2018
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Evolving the Getting Started Guide (Nathan and Slava)
D. Demo/Discussion with IBM
D. Wrap Up
Please note: This meeting will be recored
Bring a friend. It will be fun.
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
January 11, 2018
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Has joined the channel.
Indy folks. The Indy Glossary (still work in progress) can be found here:
https://wiki.hyperledger.org/projects/indy_glossary
Has joined the channel.
Hey I'm looking for details about how the faber.py agent is initialised. Basically I'm trying to create my own one - but my understanding is that I need to tell it where to look for the network?
My initialisation log looks like this:
2018-01-11 02:11:03,862 | INFO | client.py ( 179) | __init__ | Client 8f6934 found an empty node registry:
2018-01-11 02:11:03,863 | DEBUG | plugin_helper.py ( 23) | loadPlugins | Plugin loading started to load plugins from plugins_dir: /root/.indy-cli/networks/sandbox
2018-01-11 02:11:03,863 | DEBUG | plugin_helper.py ( 63) | loadPlugins | Total plugins loaded from plugins_dir /root/.indy-cli/networks/sandbox are : 0
2018-01-11 02:11:03,871 | DEBUG | selector_events.py ( 53) | __init__ | Using selector: EpollSelector
2018-01-11 02:11:03,874 | INFO | zstack.py ( 273) | setupOwnKeysIfNeeded | Signing and Encryption keys were not found for DavidCollege. Creating them now
2018-01-11 02:11:03,882 | DEBUG | authenticator.py ( 31) | start | Starting ZAP at inproc://zeromq.zap.1
2018-01-11 02:11:03,882 | DEBUG | base.py ( 72) | allow | Allowing 0.0.0.0
2018-01-11 02:11:03,882 | DEBUG | base.py ( 112) | configure_curve | Configure curve: *[*]
2018-01-11 02:11:03,883 | INFO | stacks.py ( 84) | start | CONNECTION: 6SfCKDQBosS7p7xQekDuEPBi28HBzZur4wSo5oqnS4sZ listening for other nodes at 0.0.0.0:6001
2018-01-11 02:11:03,883 | DEBUG | authenticator.py ( 31) | start | Starting ZAP at inproc://zeromq.zap.2
2018-01-11 02:11:03,883 | DEBUG | base.py ( 72) | allow | Allowing 0.0.0.0
2018-01-11 02:11:03,884 | DEBUG | base.py ( 112) | configure_curve | Configure curve: *[*]
2018-01-11 02:11:03,884 | INFO | run_agent.py ( 79) | do_run | Running David College now (port: 8888)
2018-01-11 02:14:03,978 | ERROR | eventually.py ( 182) | eventually | is_connected failed; not trying any more because 120 seconds have passed; args were (
You see that line - 'llistening for other nodes at 0.0.0.0:6001' I believe this is the line that I want to point else where?
Ok, I see it's in agent.py - an agent creates a client?
Arrh, what is a client.
Ok, I might have worked this out.
I think the pool_transactions_genesis tells you the IP addresses of the nodes
I can post something when I've got this worked out. I can possibly submit a PR for the docker demo?
@dwjohnston You are on the right track with the genesis file. Note that doing this is a good academic exercise, but is of limited long-term practical use since the agent made will be incompatible with the newer indy-sdk. Here is a document that will also help. https://docs.google.com/document/d/1kQcdICAYmSqbk4d5lUtFhk2L55dKJMfyM0JbZPeG55s/edit?usp=sharing
@mgbailey how is the agent going to be made incompatible? is the protocol changing or just how we integrate it into larger applications?
The inter-agent communications protocol will be different.
aha. is there a summary of the change somewhere?
or even what the current protocol is?
Unfortunately, it is still evolving. I don't have good information on it at this time. I'll see if I can get one of the architects to chime in.
that would be great, thank you!
@dwjohnston @wittrock All agents (faber, acme, etc.) from indy-node repos will be deprecated soon. Existing Getting Started is also going to be replaced by a new one.
Please follow https://github.com/hyperledger/indy-sdk for up-to-date approaches regarding any client and agent communication.
Old agents (faber, acme from indy-node) assumed to use ZMQ.
new agent-to-agent communicaiton is transport-agnostic. It can be done via pure http. Indy-sdk provides necessary crypto calls to make it secure (such as `authcrypt`, `anoncrypt`)
@ashcherbakov thanks for answering! Do you have a timeline for their deprecation and timeline to non-functionality? I'm putting together a demo of agents but there isn't a good resource yet for creating an agent with the SDK. I'm thinking of using the indy-client agents to get a simple initial version working, which might be fine if they'll still work for three months, but won't be fine if they will only work for two weeks
I suspect we may deprecate them sooner than 3 months, but not sure. Probably @Sean_Bohan has better answer.
FYI: Environment (docker, vagrant, etc.) scripts were moved from sovrin-environment to https://github.com/hyperledger/indy-node/tree/master/environment
Has joined the channel.
Has joined the channel.
Has joined the channel.
I was looking at the slides for the last WG call and saw that the next one was scheduled for 18 Jan (tomorrow)- is that correct and would it be possible to join?
Has left the channel.
Has left the channel.
Open Source Organization = Open call
anyone can attend and everyone is welcome
I am behind in getting the agenda posted (had a last min cancellation)
Has joined the channel.
Has joined the channel.
Has joined the channel.
@hawkmauk the next call starts in 24 minutes here https://zoom.us/j/232861185 (everyone is welcome to join)
thanks, I'm in a training session at the moment so can't make it this week
THIS WEEK we have the Indy Agent WG Call - Thursday January 25, 2018
Agenda:
Housekeeping (Sean)
Community Appreciation (Sean)
Development Status (Alex and Slava)
Roadmap Update/Discussion (Sean)
Entity Relationship Diagram Discussion (Alex, Slava, Nathan)
Wrap Up (Sean)
Please note: This meeting will be recored
Bring a friend. It will be fun.
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
January 25, 2018
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
THIS WEEK we have the Indy Agent WG Call - Thursday January 25, 2018
Agenda:
Housekeeping (Sean)
Community Appreciation (Sean)
Development Status (Alex and Slava)
Roadmap Update/Discussion (Sean)
Entity Relationship Diagram Discussion (Alex, Slava, Nathan)
Wrap Up (Sean)
Please note: This meeting will be recored
Bring a friend. It will be fun.
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
January 11, 2018
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat:
https://chat.hyperledger.org/channel/indy
https://chat.hyperledger.org/channel/indy-agent
https://chat.hyperledger.org/channel/indy-node
Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Indy WG Agendas:
https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos:
https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Has joined the channel.
Hi, I allways thought that claims are stored in the wallets. But when I run the Docker setup and inspect the wallet, there are no claims in there (when doing the "getting started" "Faber" example). So where are claims stored?
SeanBohan_Sovrin
@wolili you may use old client implementation (in the current getting started). I belive it may have multiple wallets (one for claims, one for keys) located at ~/.indy-cli/wallets
BTW real clients (and hence wallets and claims implementation) should be based on indy-sdk.
A new getting started will come soon which is based on indy-sdk
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hey everyone
THIS THURSDAY (TOMORROW!) we have the Indy Agent WG Call for Thursday February 8, 2018
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Discussing Enhancements to Hyperledger Indy SDK (wallet) with IanC
D. Discussing Initial Reference Implementation of Decentralized Authentication (DID-Auth) with MarkusS
D. Wrap Up
Please note: This meeting will be recorded
Bring a friend. It will be fun.
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
Feb 8, 2018
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat: https://chat.hyperledger.org/channel/indy https://chat.hyperledger.org/channel/indy-agenthttps://chat.hyperledger.org/channel/indy-node
Indy Wiki: https://wiki.hyperledger.org/projects/indy
Indy WG Agendas: https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos: https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Has joined the channel.
Has joined the channel.
Has joined the channel.
folks - join the mailing list, find out about Wallets, PRs and how Indy community is opening up the Sprint process
https://lists.hyperledger.org/mailman/listinfo/hyperledger-indy
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello everyone. Quick question: should a consent receipt be stored and handled as a verifiable claim, or an attribute to both NYMs?
I would vote for Verifiable claim which is off ledger
My thought as well. Should a data subject (who provided consent) then manually inform a data controller (who acquired consent) when he revokes consent? In this example, the data subject can't manipulate the revocation registry, right?
Maybe he could then inform the organization which created the claim_def on which consent was given that he wants to revoke consent. Then when the creator of the claim_def adds a revocation to the associated revoc_reg it could be seen as a confirmation of the revocation? I hope my question/thought process is clear...
would be easier for me to understand this in terms of Verifiable Claims language rather than (i think) GDPR ...
So your question perhaps is:
A holder of a verifiable claim (issued to them by an issuer) is offering a claim as a proof to a verifier. Once this proof is proven by the verifier, the verifier and perhaps the holder, would store a consent receipt of that proof. Presumably some PII data of some sort has been given to the verifier in the course of this interaction. At some later point in time the holder wishes to remove their consent for the verifier to have their PII data.
would be easier for me to understand this in terms of Verifiable Claims language rather than (i think) GDPR ...
So your question perhaps is:
A holder of a verifiable claim (issued to them by an issuer) is offering a claim as a proof to a verifier. Once this proof is proven by the verifier, the verifier and perhaps the holder, would store a consent receipt of that proof. Presumably some PII data of some sort has been given to the verifier in the course of this interaction.
I think you are also suggesting there is a claim definition on the ledger based on a consent receipt schema. As far as I know only issuers create claim definitions for claims they wish to issue. This is when the revocation register is created and is controlled by this issuer. So now the question is who is the issuer of the consent receipt.
Yes, my bad. The scenario as you sketch it is what I meant as well. The last question is indeed the interesting part
I want to say that the holder of the PII could become an issuer of consent receipts to a verifier that request PII data however I feel like that could end up leaking information about the holder
If the holder was also the issuer of the concent reciept then perhaps they could then revoke consent and the verifier would no longer be able to prove they have consent to use the PII they are storing on behalf of the holder
If the holder was also the issuer of the consent receipt (now a verifiable claim to the verifier) then perhaps they could then revoke consent and the verifier would no longer be able to prove they have consent to use the PII they are storing on behalf of the holder
Exactly
I like that conceptually .. I just don't know right now what this would mean in terms of public data on ledger connected to a person
So for that to work the holder should maintain a claim definition and revocation registry, right?
Yes that is my understanding of the current model
Yes, I would have to research that
so the holder would have a DID, DID Doc, Claim Def based on a consent reciept schema (perhaps published by the verifier, or maybe there emerges a standard schema), and a revocation registry
maybe if the claim definition for consent receipts would only contain the DID of the holder and the verifier + a hash of the (encrypted) consent receipt. That wouldn't reveal anything public i dont think
the consent receipt issued by the holder in this scenario would still be off ledger
Exactly
claim def is just the schema + magic crypto materials so that is "safe" except that everyone knows DID XYZ may have issued some consent receipts to unknown other DID(s)
Yes, so the only thing public is that certain DIDs have shared some data with other DIDs
To my understanding at least
if the schema is very widely used .. that seems not so terrible
I don't think that there would be any public record of data having been shared nor between which DIDs
In fact, if the relationship is pairwise .. those DIDs are not going to be on ledger
Oh no wait of course
I had it mixed up with the claim definition
they will only be stored in the pairwise relationships respective wallets
The actual receipt is off-ledger ofc.
Yeah
So .. could be quite safe and very cool
:)
but we need the guru's to weigh in I think
Yeah I agree
Thanks for your feedback though
NP .. fun problem
Much appreciated, I'm sometimes still struggling a bit with schema's/claim_defs
me too
Has joined the channel.
Has joined the channel.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR) VC, the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a CR, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data. We both retain a copy.
* I prove the claim.
* Later, I decide to revoke the CR. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. As I say, VCs might be the answer, but to me they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter) that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR), the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a claim, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data and we both hold that.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. VCs might be the answer, but they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR), the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a claim, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data and we both hold that.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. VCs might be the answer, but they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR) VC, the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a claim, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data and we both hold that.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. VCs might be the answer, but they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR) VC, the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a claim, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data. We both retain a copy.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. VCs might be the answer, but they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR) VC, the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a claim, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data. We both retain a copy.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. As I say, VCs might be the answer, but to me they seem too heavy.
@mawi, @jljordan_bcgov - listening in on your convo. I'm not convinced that VCs are the way to go here (although they could work) - and they are the only thing we have, right now. Perhaps something different is needed.
My concerns are the heavyweight feel of the use of VCs for this (we need something lighter), and that a revocation is a unilateral act that means nothing until there is a verification of the VC. So if I revoke my Consent Receipt (CR) VC, the Holder (e.g. BigCorp) doesn't know it until I tell it. Since I have to do that anyway, why not just use signed messages to implement the entire CR process? For example:
* Before/After proving a CR, I send a message that says "I, DID 1234, agree to share PII with DID 9876 at time 9:00:00GMT" and I sign it with my private key. BigCorp (DID 9876) adds "I, DID 9876, agree" and signs it with their private key. I might also put a limit on how long I'm willing to share the data. We both retain a copy.
* I prove the claim.
* Later, I decide to revoke the claim. I send the message back to DID 9876 with a new addition - "I, DID 1234 revoke my consent" and again sign the message. BigCorp acknowledges and sends a signed note back.
* Potential problem here - I have no proof that I actually sent the message to BigCorp, so they have some deniability. However, since the outcome of a failed CR process is likely legal and offline, it might be sufficient to have a way to show I tried to send the message at a certain time. #morethoughtneeded
For this to work at scale, I think we need a pairwise protocol for CRs with structured data for the data elements - the DIDs, timestamps, consent/revocation and signatures. As I say, VCs might be the answer, but to me they seem too heavy.
_reminds @jljordan_bcgov he is welcome to claim guru status_
THIS THURSDAY (TOMORROW!) we have the Indy Agent WG Call for Thursday February 22, 2018
Agenda:
A. Housekeeping (Nathan and Sean)
B. Development Achievements (Alex and Slava)
C. Hyperledger Indy SDK - Wallet Discussion Part 2 with Ian & Daniel
D. Wrap Up
Please note: This meeting will be recorded
Bring a friend. It will be fun.
Call details:
Hyperledger Indy Agent (SDK) WG Call
When:
Feb 22, 2018
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat: https://chat.hyperledger.org/channel/indy https://chat.hyperledger.org/channel/indy-agenthttps://chat.hyperledger.org/channel/indy-node
Indy Wiki: https://wiki.hyperledger.org/projects/indy
Indy WG Agendas: https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos: https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
@swcurran My initial feeling was the same, it seems a little weird to 'claim' consent. But as you've stated, at the moment there is no other way to record it on the ledger. My issue is that I think that not in every scenario where consent is provided, a claim must be proved. For example, if I agree that a fitness tracker may track my location, I don't share a VC about this event, right?
I feel a lightweight way of doing this might be to create a minimal Consent Receipt schema, which might look something like this:
consent_receipt_schema = {
'name': 'Consent Receipt',
'version': '0.1',
'attr_names': ['consent_receiver', 'data', 'consent_duration']
}
Here, the issuer of consent specifies who receives consent (would just be a DID), the data (a hash of the consent receipt file), and maybe the duration of consent (e.g. 1 month).
Now, everyone who gives consent can reference this standard schema, whereby the actual consent details are in the consent receipt data. If I'm not mistaken, revocation should be rather simple now, by using the revocation registry. Can a holder 'listen' to the ledger, so that they may be alerted when a claim they hold has been revoked?
I'm not sure if my line of thinking here is according to Indy's vision. I'm very curious about your feedback.
Has joined the channel.
Has joined the channel.
so @mawi and @swcurran
in @mawi example above .. would still be a issue consent receipt as a claim as this is the only way to have a revocation registry that is on the ledger
I think this is not just a tech solution .. but a convention that over time verifiers will request consent receipts from holders, if they use data post revocation of the consent receipt well in EU they are breaking the law .. elsewhere perhaps they are liable
@mawi - there is no "listener" capability right now, so only polling or a notification from the revoking party. So what is available today is still insufficient. Hence my suggesting the approach be covered by other than a Verifiable Credential.
Not sure of Indy's vision on this. They have examples in documents of CRs, but there is no code to specifically support it.
@jljordan_bcgov - agree this is a convention that will evolve over time. However, that convention could be facilitated by some tech to make it easier to achieve the convention - e.g. make CRs a first class entity like a verifiable credential. Which comes first - convention or standard? :-)
Folks:
Below, please find links to the docs shared in the Hyperledger Indy WG call today (2/22/2018)
Video recording of the meeting:
https://drive.google.com/open?id=1QCHycndmn597KAa2WS4DJLZuhpCaoQSa
Agenda of the call:
https://docs.google.com/presentation/d/1SQfjirAYC58w1diLbFX5cVnYhJFtaAkcXm0_ojkIRi8/edit#slide=id.g32810f0578_0_13
Daniel's notes about Wallets:
https://docs.google.com/document/d/1uvoZkMdZz-TZKrTYbyLXSa-kDueIex69BBy2SGPgQ2s/edit
Ian's doc about Wallets
https://github.com/ianco/indy-sdk/blob/master/doc/wallet/enterprise-wallet-design.md
Slava's deck on Anoncreds API changes:
https://docs.google.com/presentation/d/1whbMoVhw8oxK_CasOBfs0e5Yyyp3KKPKgMnzhRv1UCo/edit#slide=id.g306237b895_0_0
The Org Book from BC.gov team:
https://www.bcdevexchange.org/projects/prj-verifiable-organizations-network---theorgbook
https://bcgov.github.io/TheOrgBook/
Hyperledger Hackfest: Amsterdam (June 27-29)
https://www.hyperledger.org/event/hyperledger-hackfest-june-2018
Hyperledger IDENTITY Working Group (Feb 21, 2018:
https://wiki.hyperledger.org/groups/identity/identity-wg
Check out the Hyperledger Indy Wiki:
https://wiki.hyperledger.org/projects/indy
Join the Mailing List:
https://lists.hyperledger.org/mailman/listinfo/hyperledger-indy
Internet Identity Workshop April 2-5, Mountainview, CA - Hyperledger Discount Code:
https://iiw26.eventbrite.com?discount=HL_XXVI_20
@swcurran @jljordan_bcgov I agree. I do feel a standard could be developed before a convention though. As you also stated, CR functionality is clearly mentioned in multiple Sovrin documents, but there is no code for it. @Team Sovrin, is CR functionality on the roadmap/agenda?
@danielhardman Hey Daniel, I just watched the recording of the meeting yesterday. You refer to a post/analysis Steven made on the scaling characteristics and how expensive a lookup currently is.
Do you (or someone else) has this post on hand and can share it with me? Thanks!
Hi @Skorpion7777 @danielhardman there isn't a post, but I can share some data. I ran a test with a modified version of the Alice/Faber getting started script, to add a loop and grant Alice multiple transcripts. I found that the time required for the get_claims_for_proof_req() call increased linearly with the number of transcripts (as did the resulting message size). With 200 transcripts the response time was ~200 msec (non-encrypted database). With our solution we're storing millions of claims so obviously linear performance is a concern.
@ianco If you can share that data that would be great! Thanks!
I need to think a bit more about Daniels proposal excluding claims from the ledger. Seems very ruff, but maybe with a good alternative storing solution it is better
@Skorpion7777 there are 2 csv files here: https://github.com/ianco/indy-sdk/tree/master/samples/python. default.csv is a run with 100 transcripts with the response time for each get_claims_for_proof_req() call. enterprise.csv is a run with a poc virtual wallet.
each run adds a transcript so it shows the performance characteristic as the number of claims grows
It's a small number of claims and not a realistic scenario but it shows the trends
@Skorpion7777 - credentials (claims) are not stored on the ledger as they (may) contain private information which is generally a bad thing to put on a public ledger. Credentials are held in the wallets of the identities that hold them (to whom they have been issued). @danielhardman was talking about redefining the term "wallet" to separate it into two parts from an API perspective - a part to hold the crypto elements (private keys, link secret, etc.) and the credentials.
@swcurran Ahh, thanks for clarifying Stephen. Some time has passed since I've read the what goes on the ledger paper. probably will give it a re-read this weekend.
@Skorpion7777 you may want to look at a small project https://kumu.io/maher-bouidani/bc-govern#bc-govern/worksafe-bc we did which visualizes our "BCovrin" development ledger .. we also did a simple dashboard ... http://138.197.170.136
We had many many discussions about "What's on the ledger" and this really helped us make it straightforward ...
Now these are simple efforts and not meant for anything other than basic helpers right now
Has joined the channel.
@danielhardman @swcurran Gents just trying to catch upon the Wallet design discussions. If storage of SSI metadata and claims will be separate where will the correlation between DID and Claims (per connection) be maintained?
@vinomaster @danielhardman Thinking the same thing from another angle. We noticed in the code that the "store_claim_in_wallet" call does not return a handle to the claim. In order to (at least) revoke a claim, would an Agent not need to store the claim in the Enterprise "CRM" (or whatever) associated with the claim subject?
That would also help us for our problem of filtering on claims. If we could include in the proof request a list of credential IDs, then we would have a mechanism for the filtering needed for our TOB use case.
@danielhardman - thinking if the wallet credential IDs are known to the issuer, we could extend the proof request section of JSON that current allows list-of-schema, list-of-issuer to also support a list-of-credentialIDs. It's out of band for how the Verifier gets the list of credentialIDs and up to the Holder to provide that - if they want/it is appropriate.
Changes needed: Return credentialID when stored in wallet; extend Proof Request structure.
Would that work?
Has joined the channel.
@danielhardman @nage We are trying gather an understanding of the protocol wire-formatted structure for a proof-response. We are tediously walking code (i.e.: agent.prover()) and modifying source to dump message structures being built in the indy-anoncreds source (primary_proof_builder.py). Is there someone we can talk to who can describe the data structure (sub-structures) for a proof-response? In particular, we are interested in the difference between what is being sent back between a self-attested attribute and a verifiable-attribute. I would imagine that for testcases to be written - someone had to write down these structures -- shamelessly hoping this source is not the only documentation of the wire-formats.
@vinomaster The best source of documentation is probably going to be @devin-fisher or @wightman or @KhageshSharma , since they have been actively involved in building a product that exchanges proof requests in the past 3 months. I don't know exactly what they have written, but they will know what's available. I do know that @jlaw 1 is busy writing docs on this very subject as well.
@danielhardman Thank you sir -- any idea which rocketchat channel is best for these folks on this topic?
@swcurran @ianco I have been thinking really, really hard about how to fully address your TOB use case such that credentials become richly searchable but the wallet's simplicity, high bar for security, and pluggability are retained. What I've begun to like is a tagging mechanism where you could insert credentials with as much metadata as you like (issuer, schema, subject, etc--but also values of as many internal attributes as you care to make searchabe), and the wallet would allow efficient queries. See this slide deck: https://docs.google.com/presentation/d/1X6F9QVG8M4PqQQLLL_5I6aQ5z7CCpYyYHBNKYMlsqXc/edit?ts=5a9476ba
I believe this would allow you to write a wallet impl for TOB that's backed by a searchable doc store like mongo, or by an industrial RDBMS, and it would still have exactly the same interface as the tiny one implemented with sqllite (sqlcypher) in indy-sdk.
@vinomaster This channel ought to work. I'll go ping them on some other channels and see if I can get them to come here.
@danielhardman thanks will give your doc a read. FYI imho if we are going to make the wallet "searchable" then the best implementation choice is a document-oriented DB like MondoDB or CouchDB (whereas if the wallet is just a simple key/value store then a SQL database is probably best). For TOB the current thought is to keep the wallet key/value storage and "searchable" content separate. But in either case one of the important questions is how to tie this into a proof request. (The main driver is the fact that anoncreds will fetch all claims from the wallet in get_claims_for_proof_req()" and we want to be able to filter this.
@danielhardman thanks will give your doc a read. FYI imho if we are going to make the wallet "searchable" then the best implementation choice is a document-oriented DB like MondoDB or CouchDB (whereas if the wallet is just a simple key/value store then a SQL database is probably best). For TOB the current thought is to keep the wallet key/value storage and "searchable" content separate. But in either case one of the important questions is how to tie this into a proof request. (The main driver is the fact that anoncreds will fetch all claims from the wallet in get_claims_for_proof_req()" and we want to be able to filter this.)
I guess I am assuming that anoncreds will stop fetching all credentials from the wallet, if we make the wallet searchable. Rather, it will fetch just those credentials that satisfy a few criteria.
@danielhardman thansk for teh doc -- vernacular is helpful. Wrestling still with sovereign domain and vault. I was viewing in teh context of Indy that your "enterprise entity vault" or "personal identity vault" was the virtual corpus of all your wallets across your multiple devices and your cloud agent.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=MRuL2azzbBGdCPwQY) @danielhardman got it :+1:
@danielhardman What needs to go onto the Public Ledger to enable a beacon based recovery for re-establishing broken microledger connection ?
@danielhardman Do queries like the one on slide 27 span across a specific device wallet or the entire sovereign domain?
@danielhardman Fun stuff! I like what you have in the presentation. I have some comments on different slides that I'd be interested in your response - perhaps turn on commenting on the presentation in Google?
Our immediate concern is how the information necessary to use the tags flows within libindy from anoncreds to a wallet implementation. I'm assuming by your comment above that (b) is a given - filter data *must* be able to be passed from the wallet caller into the wallet. It would be great to get agreement on a design for how that interface will change. The current implementation will not work at scale.
Regarding tags. I like that it means that the item itself can remain opaque, and it's up to the wallet owner (agent) to add tags necessary to retrieve items as needed for their implementation. However, for credentials arbitrary tags independent of the schema eliminates the use of a common language between the verifier and prover to negotiate the desired credential to be used for a Proof. If we did use the a claim name/value pair, both parties would understand the filtering.
I think (a) is going to be a common use case - a prover could be holding several of a specific type of credential and the verifier wants to influence the one returned in an A2A scenario. Do you think that will be done via out-of-band negotiation, or should that go into the Proof Request - the only current in-band place currently available.
@danielhardman Fun stuff! I like what you have in the presentation. I have some comments on different slides that I'd be interested in your response - perhaps turn on commenting on the presentation in Googale?
Our immediate concern is how the information necessary to use the tags flows within libindy from anoncreds to a wallet implementation. I'm assuming by your comment above that (b) is a given - filter data *must* be able to be passed from the wallet caller into the wallet. It would be great to get agreement on a design for how that interface will change. The current implementation will not work at scale and we're moving fast to need it to scale.
Regarding tags. I like that it means that the item itself can remain opaque, and it's up to the wallet owner (agent) to add tags necessary to enable retrieval as needed for their implementation. I think tags may be required for objects that don't have any other attributes to use for selection. However, for credentials, arbitrary tags independent of the schema (e.g. without claim value-based filtering) eliminates the ability for the verifier and prover to use a common language for negotiating the desired credential to be used for a Proof. The verifier does not (I assume) know what tags an arbitrary prover is using, so has no way to express filtering concepts using tags. I think the need for the verifier to be able to say what credentials they want will be a common use case. A prover could be holding several of a specific type of credential and the verifier wants to influence the one returned in an A2A scenario. QUESTION: Do you that happening via an out-of-band negotiation, or should that go into the Proof Request - the only current in-band place currently available.
Progress - very interested in keeping this discussion going.
@danielhardman Fun stuff! I like what you have in the presentation. I have some comments on different slides that I'd be interested in your response - perhaps turn on commenting on the presentation in Google?
Our immediate concern is how the information necessary to use the tags flows within libindy from anoncreds to a wallet implementation. I'm assuming by your comment above that (b) is a given - filter data *must* be able to be passed from the wallet caller into the wallet. It would be great to get agreement on a design for how that interface will change. The current implementation will not work at scale and we're moving fast to need it to scale.
Regarding tags. I like that it means that the item itself can remain opaque, and it's up to the wallet owner (agent) to add tags necessary to enable retrieval as needed for their implementation. I think tags may be required for objects that don't have any other attributes to use for selection. However, for credentials, arbitrary tags independent of the schema (e.g. without claim value-based filtering) eliminates the ability for the verifier and prover to use a common language for negotiating the desired credential to be used for a Proof. The verifier does not (I assume) know what tags an arbitrary prover is using, so has no way to express filtering concepts using tags. I think the need for the verifier to be able to say what credentials they want will be a common use case. A prover could be holding several of a specific type of credential and the verifier wants to influence the one returned in an A2A scenario. QUESTION: Do you that happening via an out-of-band negotiation, or should that go into the Proof Request - the only current in-band place currently available.
Progress - very interested in keeping this discussion going.
@danielhardman Fun stuff! I like what you have in the presentation. I have some comments on different slides that I'd be interested in your response - perhaps turn on commenting on the presentation in Google?
Our immediate concern is how the information necessary to use the tags (or other filtering info) flows within libindy from anoncreds to a wallet implementation. I'm assuming by your comment above that (b) is a given - filter data *must* be able to be passed from the wallet caller into the wallet. It would be great to get agreement on a design for how that interface will change. The current implementation will not work at scale and we're moving fast to need it to scale.
Regarding tags. I like that it means that the item itself can remain opaque, and it's up to the wallet owner (agent) to add tags necessary to enable retrieval as needed for their implementation. I think tags may be required for objects that don't have any other attributes to use for selection. However, for credentials, arbitrary tags independent of the schema (e.g. without claim value-based filtering) eliminates the ability for the verifier and prover to use a common language for negotiating the desired credential to be used for a Proof. The verifier does not (I assume) know what tags an arbitrary prover is using, so has no way to express filtering concepts using tags. I think the need for the verifier to be able to say what credentials they want will be a common use case. A prover could be holding several of a specific type of credential and the verifier wants to influence the one returned in an A2A scenario. QUESTION: Do you that happening via an out-of-band negotiation, or should that go into the Proof Request - the only current in-band place currently available.
Progress - very interested in keeping this discussion going.
@danielhardman Fun stuff! I like what you have in the presentation. I have some comments on different slides that I'd be interested in your response - perhaps turn on commenting on the presentation in Google?
Our immediate concern is how the information necessary to use the tags (or other filtering info) flows within libindy from anoncreds to a wallet implementation. I'm assuming by your comment above that (b) is a given - filter data *must* be able to be passed from the wallet caller into the wallet. It would be great to get agreement on a design for how that interface will change. The current implementation will not work at scale and we're moving fast to need it to scale.
Regarding tags. I like that it means that the item itself can remain opaque, and it's up to the wallet owner (agent) to add tags necessary to enable retrieval as needed for their implementation. I think tags may be required for objects that don't have any other attributes to use for selection. However, for credentials, arbitrary tags independent of the schema (e.g. without claim value-based filtering) eliminates the ability for the verifier and prover to use a common language for negotiating the desired credential to be used for a Proof. The verifier does not (I assume) know what tags an arbitrary prover is using, so has no way to express filtering concepts using tags. I think the need for the verifier to be able to say what credentials they want will be a common use case. A prover could be holding several of a specific type of credential and the verifier wants to influence the one returned in an A2A scenario. QUESTION: Do you see that happening via an out-of-band negotiation, or should that go into the Proof Request - the only current in-band place currently available.
Progress - very interested in keeping this discussion going.
@swcurran: From our work on Mobile identity our experience is that to remain truly self-sovereign the Verifier has a right to describe what they require in a proof request and in some cases based on the role/relationship of the Verifier with an Issuer (i.e.: Cop with DMV; Clerk with Pharmacy) the Verifier may not has a choice and the Issuer defines proof request requirements for various roles. Furthermore, the Owner/Holder must be allowed to respond as they deem comfortable in a proof-response. This means they may respond without meeting the criteria. How such incomplete or unsatisfied exchanges are handles is a policy decision at the verifier and out of scope for the tech IMHO. We do not want to insert ourselves into the job of the Verifier, we only seek to help simplify the experience. The Verifier is ultimately accountable/liable.
@swcurran: From our work on Mobile identity our experience is that to remain truly self-sovereign the Verifier has a right to describe what they require in a proof request and in some cases based on the role/relationship of the Verifier with an Issuer (i.e.: Cop with DMV; Clerk with Pharmacy) the Verifier may not have a choice because the Issuer defines proof request requirements for various roles. Furthermore, the Owner/Holder must be allowed to respond as they deem comfortable in a proof-response. This means they may respond without meeting the criteria. How such incomplete or unsatisfied exchanges are handled is a policy decision at the verifier and out of scope for the tech IMHO. We do not want to insert ourselves into the job of the Verifier, we only seek to help simplify the experience. The Verifier is ultimately accountable/liable.
Agreed for the most part - particularly in the mobile context. The challenge I'm seeing is when the interaction is agent-to-agent (system-to-system) and their is no human in the middle to understand the request and respond appropriately to satisfy the intent of the request. As soon as there is ambiguity, there needs to be some negotiation/rules to resolve the ambiguity, and I think that has to involve both the Verifier and the Prover.
@swcurran: Ah Autonomous Verification -- interesting; Introduces more trust concerns.
remembering that our particular use case is public data about businesses
and this is to enable the verification of certain permissions or accreditations that businesses have been granted by issuers
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fqaM6tqFPvPACmCiM) @vinomaster Queries have a scope of one wallet only. Higher-level queries spanning a full domain are conceivable but would not be the job of the wallet interface.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=f7Qjeo2dcAKHoMKYc) @vinomaster This has only been whiteboarded at this point, but here's the thinking: two parties agree in advance that they will coordinate via a beacon on the public ledger, if they become disconnected. This beacon needs to have some identifier that both parties know but that is not correlating for either of them. When you write to a beacon, you basically submit a transaction to the ledger that says, "I want to activate a beacon with the following identifier. Here is a state proof that shows what I think about the state of the relationship." The other party eventually sees the beacon and compares its own knowledge of the relationship state to decide whether it will accept the remote party's view of where they should resume communications.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=LKwcw75725ESzms3P) @swcurran Verifiers express criteria in the proof request (in-band). The Prover must convert the criteria in the proof request into tags in their wallet. Imagine that the Prover says, "I need a proof from a credential that matches schema X or Y, where the issuer is Z, and the issue date is within the past month, and the subject of the credential is 'Acme Corp'". There are ways to say this in proof requests; if you haven't seen docs on that topic, let me know and I'll track them down and post them here for you.
So the prover gets this request and says, "Okay, I need to map these criteria into tags in my wallet." And comes up with something like this (here, I'm using SQL and imagining an RDBMS backing store for the wallet, but there could be an analog for MongoDB or similar tech as well):
SELECT i.item_id, i.value
FROM item i
INNER JOIN text_tags t1 ON i.item_id=t1.item_id
INNER JOIN int_tags t2 ON i.item_id = t2.item_id
INNER JOIN text_tags t3 on i.item_id = t3.item_id
WHERE i.item_name like ‘cred:*’
AND t1.tname=’subject’ AND t1.tval like ‘Acme%’
AND t2.tname=’issue_date’ AND t2.tval > date_to_int(last week)
AND t3.tname='schema_name' and t3.tval in (schema1, schema2)
@danielhardman - I haven't seen these expressed in Proof Requests - please send them. That's what I've been trying to get to. If that's doable - all good!
@danielhardman: Related to this topic of identifying claims applicable to a proof-request, I have been conversing with @devin-fisher and after walking code in anocreds and mapping the code to the zkp math (https://github.com/hyperledger/indy-anoncreds/blob/master/docs/dev/anoncred.pdf) the following seems to me to still be unclear -- When a proof request contains a series of verifiable attributes, it is assumed (maybe incorrectly) that the proof response will carry some extra crypto or metadata in the response payload for those tagged verifiable attributes so that the inspector can gain trust in the origin of the verifiable attributes. It is assumed that what is passed back to the Inspector for a self-attested attribute should be different for what is passed back for verifiable attributes. As such an understanding of the proof-response payload is of interest.
My concern here is that I believe the zkp math is applicable under some business situation but not all. Under the notion of a Web of Trust based trust chain I can see where the zkp math applies. However, when an Inspector (Verifiers) needs to address certain business policies for verification a zkp may not be adequate. I refer to the notion of a "Policy Driven Trust" whereby the Verifier is assumed to have no knowledge, relationship or chain of trust with Issuers associated with the verifiable attributes presented in a proof-response.
In the physical world what I refer to here is the concept of a vetting process. What ins intriguing for us in the SSI community is that we have an opportunity to address digital vetting processes. Assume the Inspector has to have verifiable evidence that he/she can verify for each verifiable attribute that the origin of that attribute value came from the issuer the prover claims he/she claims to have received it from. So if we can agree that there may exist cases where the Verifier lacks a trust chain for Issuers associated with each of the prover presented verifiable-attributes AND Verifier policy dictates that there must be recordable evidence in the Verifiable SOR that each verifiable attributes was issued a valid Issuer THEN we may need to have the option of processing proof-requests/responses in more than only one possible manner. Finally, on the requirement of correlation at the Inspector level -- there are well documented cases where a Verifier for policy reasons may require not just proof of certain attributes but proof from specific types of Issuers (i.e.: Government). So again, sometimes the assumptions for the zkp arcocreds may not always hold. I am sure I have overlooked something and will try to write this up to improve the quality of the conversation. My question is who should the conversation be with? Do I just submit it as a JITA story to be debated? BTW - just got power/water back after a long sleepless nite after Nor'Easter Riley so I am sure my articulation herein needs help. :-(
@vinomaster - I've written an article about the vetting process for a Verifier. This (I think) answers some of your questions about what HL-Indy provides in a Proof.
https://docs.google.com/document/d/1nYq0iakgtyC21oUGWa5hLuJUoKeJFpURtGz6HcLIltY/edit?usp=sharing
In general - your questions/concerns are covered in the HL-Indy implementation - the verifier knows the issuer, the verifier can (in the Proof Request) require the issuer be a specific entity (by requiring a specific Issuer DID), or use a specific schema - or both.
Has joined the channel.
Hi, Where can I find material on how to create a sample agent on Indy? Is there is any sample code within Indy repo that deals with Agents. I couldn't find anything on INDY-SDK on Agents. Thanks!
Hi, Where can I find material on how to create a sample agents on Indy? Is there is any sample code within Indy repo that deals with Agents. I couldn't find anything within INDY-SDK on Agents. Thanks!
@swcurran @vinomaster Do either of you happen to know a more high-level description of what's sketched in
@swcurran @vinomaster Do either of you happen to know a more high-level description of what's discussed in https://github.com/hyperledger/indy-anoncreds/blob/master/docs/dev/anoncred.pdf ? Or is the zkp strategy really so specific to indy that this is the only reference?
Has joined the channel.
@pimotte - let me check what our devs would recommend. We have reasonably easy code to follow that shows a chunk of the protocol - requestProof, Prove, requestClaim, issueClaim.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Jk3efokm9rJRpf2yX) @swcurran Sorry; I was away from RocketChat for a few days but am now back up to speed. Will try to track down info asap.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=WiBFT4ovovPZBSGL9) @vinomaster We been talking with folks at IBM Research in Zurich (the creators of idemix and ABC4Trust) about a concept called ZKLang. This deals with expressing proof requirements to a crypto engine in a formal mathematical way, and can safely be ignored by most consumers of Indy. But it intersects with your observation about the response payload, because we've identified the need for something between a proof request and the mathematical computation that satisfies it, and we're calling this intermediate thing a "Proof Resolution". You can think of it like a query execution plan in an RDBMS; it shows how the criteria in a proof request are being mapped into a set of credentials and attributes. One of the possible uses of a Proof Resolution is as part of the payload of a proof presentation, allowing a verifier to know more about how the proving is being approached. I think this may help with the vetting you're thinking about.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ySCJEZMy7KgNAonyZ) @the_identity_guy The python code behind Indy's Getting Started Guide contains some very simple sample agents. The need for something more detailed is painfully obvious to all of us and is being discussed in various places. Evernym, for example, is trying very hard to figure out a way to spend some time plugging this gap. Have you already seen the material about agent-to-agent communication (https://docs.google.com/presentation/d/1H7KKccqYB-2l8iknnSlGt7T_sBPLb9rfTkL-waSCux0/edit -- note link on first slide to recording, which you might want to refer to as you flip through slides)?
@swcurran Thanks! Any leads are highly appreciated:)
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello just a quick question from a new entrant to this project... I was just wondering when the next release 😄 of documentation for the project is due?
Has joined the channel.
Has joined the channel.
In the Proof handling process (Offer, Request, Proof), is there any mechanism within the protocol to convey multiple proofs in response to a proof request? Multiple proofs could be sent be the Prover, but since the process is async, the Verifier would not know when it had received all of the responses. Example might be references for a job application, family members on an insurance application, etc.
Suggestions on how that might be handled?
In the indy-skd/samples/python/src/getting_started.py file line 196, what is the data format of the authcrypted_transcript_claim_offer:
```authcrypted_transcript_claim_offer = await crypto.auth_crypt(faber_wallet, faber_alice_key, alice_faber_verkey,
transcript_claim_offer_json.encode('utf-8'))```
Has joined the channel.
Has joined the channel.
Has joined the channel.
My intended question here is actually: What is the preferred or decided mime-type to send these kind of encrypted payloads from agent to agent?
@mhailstone In the java case it's simply a byte array, I imagine it's the same/similar in python, so it would be just binary data going over the line
Thanks @pimotte! Should we decide on a particular method and/or mime-type so the community is in conformity in how to exchange the data between agents?
I think that's something that will be up to implementations of agents that need to interact. But if you're looking for a recommendation, application/octet-stream seems like a good fit
application/octet-stream sounds great to me as well. I am concerned about interoperability with any agent no matter what the implementation. We are defining an Open API 2.0 document that defines an Agent API that we hope to share soon. With an API definition, this would help interoperability from any Indy Agent to other Agents. We'll incorporate application/octet-stream for now unless others have other recommendations. Thanks for your input @pimotte.
application/octet-stream sounds great to me as well. I am concerned about interoperability with any agent no matter what the implementation. We are defining an Open API 2.0 document that defines an Agent API that we hope to share soon. With an API definition, this would help interoperability from any Indy Agent to other Agents. We'll incorporate application/octet-stream for now unless others have other recommendations. Thanks for your input @pimotte .
Per the mention today on the Indy Community Call, here is information about the VON-Agent.
Current primary repo for VON-Agent is in the Gov't of Canada github organization - the link is:
https://github.com/PSPC-SPAC-buyandsell/von_agent
It's being used in TheOrgBook and Permitify projects at BC Gov.
Has joined the channel.
Has joined the channel.
https://www.ietf.org/mail-archive/web/ietf-announce/current/msg17592.html. TLS 1.3 is now a proposed standard.
@nage - does that help with progress towards the practical use of DIDs (non-CA-driven) in TLS?
It should. As versions of the library roll out and compatible servers become more common, the hurdles for adoption and library availability should disappear.
There is still work to do (see @TelegramSam ‘s google doc outlining the new options required)
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/OpenTLS.md
And https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/TLS-Flex.md
Question about pairwise DIDs.. Does a new pairwise DID get generated for every interaction with two agents A and B? or is it the same DID for every pair A and B. Another question: Do all DIDs get registered on the ledger and are public before the secure comm. channel is established?
Pairwise IDs get reused whenever you want the unit of correlation to be reused
You can chose to register them before or after the interaction. For some cases an agent might refuse to interact with an unregistered is because it needs guarantees provided by registration, but that will probably be a rare case. Many of these ids could exist off-ledger provided the agents have a way to find each other again when agents move and keys are rotated (there are ways of doing that part on the ledger more cheaply and securely)
Registering identifiers well before an interaction or after an interaction also helps avoid timing correlation (look these two identifiers were created at almost the exact same time, I bet these two organizations connected!).
Has joined the channel.
Has joined the channel.
@the_identity_guy - to put another way, there is no requirements from HL-Indy on how these are handled - it's an app level concern. Protocols will evolve, but the restrictions are not in the underlying implementation of HL-Indy.
development discussion and support for the master branch work for reference implementations on top of Hyperledger Indy. There isn't a dedicated code base to the Agent currently, but work is underway in many places. Take a look at the code examples and ask questions on how you can get involved.
Has joined the channel.
There was a link to a repo on enterprise wallet and agent 2 agent proposal flow that I can't seem to locate now. Anyone familiar with it?
@tomislav if you are referring to the enterprise wallet stuff we are doing our repos are here https://github.com/topics/verifiable-organizations-network
I think it is the von-agent and indy-sdk that has the bulk of the effort .. @ianco can direct you to specifics
That's the one, thank you
@tomislav @jljordan_bcgov the enterprise wallet docs are here: https://github.com/bcgov/indy-sdk/tree/master/doc/wallet ... there will be a PR later today including some updates (or you can get a sneak peek here: https://github.com/ianco/indy-sdk/tree/master/doc/wallet)
@tomislav @jljordan_bcgov the enterprise wallet docs are here: https://github.com/bcgov/indy-sdk/tree/master/doc/wallet ... there will be a PR later today including some updates (or you can get a sneak peek here: https://github.com/ianco/indy-sdk/tree/master/doc/wallet
... also an exciting demo on next week's Indy call! :-D
Fantastic, can't wait. Thank you
Has joined the channel.
Does someone here have a clear view on the relationship between Sovrin's A2A protocols and the work by DIF on 'Hubs'? I'm not quite sure how the interaction between edge/cloud agents and hubs could/should look like.
@mawi Ironic you should ask that as that is one of the main topics of discussion here at Internet Identity Workshop #26 in Mountain View. Today was the first of three days and it was FILLED with discussion of your exact question. I've just returned to my AirBNB and have to crash to get enough sleep for tomorrow, but I'll summarize it this way: there are major discussions going on between the different groups working on the Sovrin A2A protocols, the uPort identity wallet protocols, and the DIF hub protocol discussions, and good progress is being made. Stayed tuned (one way is listening to the tweet stream on the #IIW tag).
@drummondreed Ah, good to know! I'll keep an eye on it. Please do keep us posted if any major outcomes are published :)
Has joined the channel.
Folks:
INDY Call today, April 5, 2018:
Agenda:
Housekeeping (Sean)
Development Status (Slava)
Wallet Update (IanC)
Benchmarking and Scaling Discussion (Slava and Vladimir)
8amPT, 9amMT, 11amET, 4pm BST
Where:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185
Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185#
Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 232 861 185
International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1
Hyperledger Indy Community
Indy Rocketchat: https://chat.hyperledger.org/channel/indyhttps://chat.hyperledger.org/channel/indy-agenthttps://chat.hyperledger.org/channel/indy-node
Indy Wiki: https://wiki.hyperledger.org/projects/indy
Indy WG Agendas: https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH
Indy Videos: https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt
Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ
Has left the channel.
FYI - a claims issuing performance report from @ianco about the work he has done on the BC Gov Enterprise Wallet - https://github.com/ianco/indy-sdk/tree/master/doc/wallet/performance.
Some interesting information on raw performance, threading and docker stability.
Hi Folks , I am an Phd Candidate in www.nitrr.ac.in my Linkedind Profile is https://www.linkedin.com/in/eramitg/ for sake of earning an Phd Degree i was proposed Blockchain Technology research work area to my guide so oom I request all of you gyus ,please guide me and assign me some research oriented task so that we mutullay benifited research related to Hyperledger Umbrella Project , All of you feel free to catch me on twitter or skype to https://twitter.com/eramitg1 or amitg.iitb skype id also in Zoom to in Zoom ID 3649222703 or whatsapp +917773011100 Regards
Has joined the channel.
Hi all, question regarding coordination across multiple edge agents. Say I make a did-connection with another entity on a web browser on my desktop. How would I interact with that connection on my mobile phone? How would I authenticate with that connection on any other device if we're not copying signing keys from the browser?
^^^ @danielhardman - Daniel, this looks like one for you. I've got a rough idea of what you are thinking but would likely be more wrong than right on the mechanics of it.
Although we still need @danielhardman to provide the definitive answer, you can find some good background on this in the DKMS Design and Architecture document Evernym published last week at IIW. https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/DKMS%20Design%20and%20Architecture%20V3.md
@drummondreed that's a very good read, clearing quite a number of things up. Thanks!
Has joined the channel.
Has joined the channel.
@mawi Thanks. It has been a great project for DHS and we're excited to move this forward within Hyperledger Indy.
Has joined the channel.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=FWBuMmebSNueWPedg) @mawi Sorry for the slow response; I've had this half written all week...
The short answer is that your edge agents and cloud agent should cooperate to share knowledge of the connection. Each agent has its own keys, but no matter which device (agent) initiates the connection, keys from all agents should be authorized to represent you to a greater (edge) or lesser (cloud) degree. The list of keys that can represent you is stored in your DID Doc and thus known to your connection.
You may find this doc helpful: https://docs.google.com/document/d/1hnQPEdfmAG-DnXGrDXowjc5J571pK7Ub4bWkUlzrH1Y/edit
Has joined the channel.
This is a great doc @danielhardman , thank you for sharing. Are we able to work with these transaction types yet to manage agent registries?
@danielhardman thanks a bunch, and that's a great document!
@tomislav There is work in feature branches of indy-node and indy-sdk that demonstrates almost everything described in the doc, but it has not yet been raised as a PR against master because the code needs some hardening. @devin-fisher can identify the branches and describe the status better than I can.
Has joined the channel.
Has joined the channel.
Hello guys ! I'm working on the development of a human-friendly solution for identity for all based on indy/sovrin. I have a major question, how can agents communicate ? for example in the demo, how can I make faber send a message to acme without going through the CLI ? Same for clients, I don't find in 'python' wrappers for example the possibility to send a claim to another if they are in different machines ... Thank's for helping me..
Hi @Kelattar , check out https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos/send-secure-msg/python
Thank's @mawi for your answer :) I had actually already studied to encryption functions in crypto.py, but I thought they have specific 'sending' functions to allow the 'private channel'. Seems like it's not the case
You use crypto.py to prepare a message to send to the endpoint of the message receiver
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hey everyone. Question regarding web-based agents.
If I want to create a web application which uses indy functionality, how would I go about executing the libindy code client-side? The browser would then have to initiate the creation of a wallet and key materials locally on the machine on which the browser is accessed. Would the browser then execute indy commands locally on the machine via API calls or? For example in Evernym's VCX demo (https://vimeo.com/262596133), I'm not sure how the web app could work 'under the hood'.
@mawi Current web applications store the wallets for the users server-side, but that isn't necessary best practice. There is a Node wrapper that can be leveraged. Delegating browser usage to the user is also a challenge, because browser site storage isn't always reliably backed up. Perhaps you would need a browser plugin?
This topic is discussed occasionally, but I haven't seen any clear answers yet.
For ease of implementation, I'm leaning toward storing the wallet server side and giving users a way to download and upload wallets. But there are good arguments against that practice.
@esplinr and @mawi The bottom line is that eventually you want the browser to act as an edge-agent, i.e., to have the wallet integrated. But realistically that's years away. So the only options are either browser plug-ins (awkward), web wallets (bad idea), or out-of-band communication to mobile wallets (current best practice).
@esplinr & @drummondreed I want to prevent having to use a server to store user's wallets, as that highly conflicts with the SSI vision. I've thought about extensions, but as you've said, that doesn't seem very user-friendly. I'll keep it as a constraint to use mobile devices. Thanks for your replies
Has joined the channel.
Has joined the channel.
@nage / @drummondreed or others - a question about a slightly different use case for key rotation/updating a DID Doc.
Suppose that I have a pairwise connection to a Gov't Service in my Personal Agent (PA), but I now want the connection to be with the company I own that has a brand spanking new "Enterprise Agent" (EA). Could the Enterprise Agent include a feature to allow it's connections (e.g. my Personal Agent) to request it create and send a new DID Doc by creating a keypair and populating new the DID Doc with the new Public Key and the EA's endpoint(s). Once I get that DID Doc, my PA could use key rotation functionality to replace the current DID Doc for the connection with the DID Doc from my Enterprise Agent, thereby transferring control of the connection from my PA to my Organization's EA?
We're seeing this as a possible way to bootstrap an EA for an organization, allowing it to receive and hold the Credentials for the Organization.
Is this a good pattern? Any pros and cons to it? Does the Service have a need to know anything about this? Any thoughts on this?
From a technical perspective this approach works, but you might want to use an introduction pattern instead so that the correlation between the PA DID and EA isn’t so obvious. @TelegramSam thoughts?
In this case the DID would stay the same, but the keys and service endpoints would change. There isn't really a way to hide that history.
@swcurran Providing a 'relinquish' service on an Agent to facilitate control transfer isn't a terrible idea. DID Docs themselves have (or had...) a guardian feature that made that relationship (from a key perspective) obvious. Not sure if this is needed in all cases.
Thanks. Once the connections are off ledger, the correlation risk is less of a concern - particular in the places we are thinking. What I like about it is that it is controlled by the Owner/Org independent of the Service. The Service doesn't care.
Do you have a link or a quick summary of the introduction pattern? I can sort of imagine it, but not certain.
Has joined the channel.
Has joined the channel.
hi, i'm stuck running the indysdk how-to's. i get this error.
```~/indy-sdk/wrappers/python/tests/demo$ pytest test_ledger.py
Traceback (most recent call last):
File "/usr/local/bin/pytest", line 11, in
hi folks, I'm stuck here. ```Note that before you can use python wrapper you must install c-callable SDK. See the section "How-to-install" in Indy SDK```
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/README.md
clicking the link leads back to the same page. looking to understand what the install steps for the c-callable SDK are. i am trying to run the tests but get an error... see below
```:~/indy-sdk/wrappers/python/tests/demo$ pytest test_ledger.py
Traceback (most recent call last):
File "/usr/local/bin/pytest", line 11, in
hi folks, I'm stuck here. ```Note that before you can use python wrapper you must install c-callable SDK. See the section "How-to-install" in Indy SDK```
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/README.md
clicking the link leads back to the same page. looking to understand what the install steps for the c-callable SDK are. i am trying to run the tests but get an error... see below
```~/indy-sdk/wrappers/python/tests/demo$ pytest test_ledger.py
Traceback (most recent call last):
File "/usr/local/bin/pytest", line 11, in
hi folks, I'm stuck here. Note that before you can use python wrapper you must install c-callable SDK. See the section "How-to-install" in Indy SDK```
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/README.md
clicking the link leads back to the same page. looking to understand what the install steps for the c-callable SDK are. i am trying to run the tests but get an error... see below
```~/indy-sdk/wrappers/python/tests/demo$ pytest test_ledger.py
Traceback (most recent call last):
File "/usr/local/bin/pytest", line 11, in
hi folks, I'm stuck here. Note that before you can use python wrapper you must install c-callable SDK. See the section "How-to-install" in Indy SDK
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/README.md
clicking the link leads back to the same page. looking to understand what the install steps for the c-callable SDK are. i am trying to run the tests but get an error... see below
```~/indy-sdk/wrappers/python/tests/demo$ pytest test_ledger.py
Traceback (most recent call last):
File "/usr/local/bin/pytest", line 11, in
ubuntu 16.04
Try running it with Python3 instead of Python
Alternatively it may be an issue with your PATH and how your Python is being found. Try setting up a Python virtual environment and installing all dependencies in there. Then activate it and try running it again. This way your Python interpreter won't go looking for packages in other places because they're all in the virtualenv
Hi, are the concepts of agents and agencies (edge or cloud) used anywhere outside of Indy ecosystem?
DIF is working on a hub concept that is very similar to cloud agents. We've been working closely with them to get communication protocols aligned
BTW, "DIF" is the Decentralized Identity Foundation, http://identity.foundation/
As @kdenhartog suggests, the DIF concept of identity hubs is similar to cloud agents, but more data-centric. DIF does not currently have the concept of edge agents. The generalized view of both cloud and edge agents and their roles in decentralized key management is covered in the DKMS Design and Architecture document: https://github.com/hyperledger/indy-sdk/blob/master/doc/dkms/DKMS%20Design%20and%20Architecture%20V3.md
@kdenhartog thanks - I was able to get that going.
i'm running this setup on openstack. currently, each node of my cluster is on its own VM and it appears the cluster is working fine.
now I'm trying to run through the indy-sdk how-tos. I found the file ~/indy-sdk/cli/docker_pool_transactions_genesis and saw that I need to modify some of this to connect to my pool, which it does now.
I think I need to modify it some more, but I'm not sure where to get various pieces of data.
new error output below
```2. Open pool ledger and get handle from libindy
INFO|indy::commands | src/commands/mod.rs:107 | PoolCommand command received
INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node3 po
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"9NAYH8vXAnEupfV7hYEA9m3j53pUK1GDoTehKJj1SjMN\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 po
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"9NAYH8vXAnEupfV7hYEA9m3j53pUK1GDoTehKJj1SjMN\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node2 po
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"9NAYH8vXAnEupfV7hYEA9m3j53pUK1GDoTehKJj1SjMN\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node1 po
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"9NAYH8vXAnEupfV7hYEA9m3j53pUK1GDoTehKJj1SjMN\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node3 {"txnSeqNo":4,"merkleRoot":"AAYFcKMtSju1DbTtXxurjDmgEfsHU5S9nDMfX8xW6uxn","ledgerId":0,"viewNo":null,"op":"LEDGER_STATUS","ppSeqNo":null}
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 {"merkleRoot":"AAYFcKMtSju1DbTtXxurjDmgEfsHU5S9nDMfX8xW6uxn","viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"ledgerId":0,"op":"LEDGER_STATUS"}
INFO|indy::commands | src/commands/mod.rs:107 | PoolCommand command received
INFO|indy::commands::pool | src/commands/pool.rs:66 | OpenAck handle 1, result Err(Terminate)
ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool work terminated
_indy_loop_callback: Function returned error 302
Error occurred: ErrorCode.PoolLedgerTerminated
ERROR|indy::services::pool | src/services/pool/mod.rs:778 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))
```
pretty sure my txn ids don't match, which is why I get this issue
strange... looks like my nodes can't reach each other. might be the reason :) diving deeper into this
@drummondreed - any more details on how the Dead Drop mechanism would work for DKMS? The link in the Design & Architecture document is a little short on SSI details :-)
@swcurran I'm not the full crypto expert but the basic idea is that the two identity owners, after they exchange their pairwise pseudonymous DIDs, do something similar to a Diffie-Helman key exchange to agree on a key to use for a *future* dead drop DID if they ever get disconnected. Then, if it ever happens, one of them registers the dead drop DID on the agreed upon ledger, and it contains the service endpoint at which they will "rendezvous" to do another real Diffie-Helman exchange to re-establish their private channel. Then they will share their updated pairwise pseudonymous DID documents and be back in sync.
That all make sense?
Has joined the channel.
thank you @kdenhartog @drummondreed
@samadsajanlal any luck with getting the nodes communicating with each other?
@kdenhartog negative, i'm still looking into it. doesn't help that i'm fairly new to the sovrin/indy codebase :)
@drummondreed - sort of. So at the start of the relationship, they both store locally a not-published DID and shared public/private key pair (via Diffie-Helman), and if they lose contact, one puts the agreed to DID on a ledger with an endpoint. That endpoint is presumably built to handle a Dead Drop and does something - not quite sure what - to help them re-establish communications.
I would recommend getting someone to write that up so the reference to that in the DKMS document was better.
@drummondreed - sort of. So at the start of the relationship, they both store locally a not-published DID and shared public/private key pair (via Diffie-Helman), and if they lose contact, one puts the agreed to DID on a ledger with an endpoint. That endpoint is presumably built to handle a Dead Drop and does something - not quite sure what - to help them re-establish communications.
I would recommend getting someone to write that up so the reference to that in the DKMS document was better. I don't get it well enough to do that :-)
Is an alternative to this that if one side has a public DID, they issue a verifiable credential to the other, and on loss of contact, they use the public DID and the credential to kickstart reestablishing their relationship?
@kdenhartog found the issue - i had started the nodes with incorrect nodenames (node 1 was node4, etc)
so far the cluster works. however I get stuck on the how-to's, step 2's output is this:
```2. Open pool ledger and get handle from libindy
INFO|indy::commands | src/commands/mod.rs:107 | PoolCommand command received
INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "pi"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 po
INFO|indy::services::pool | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"9NAYH8vXAnEupfV7hYEA9m3j53pUK1GDoTehKJj1SjMN\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}"
INFO|indy::services::pool | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 {"merkleRoot":"AAYFcKMtSju1DbTtXxurjDmgEfsHU5S9nDMfX8xW6uxn","viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"ledgerId":0,"op":"LEDGER_STATUS"}
```
doesn't progress past this point
Are you submitting the transaction from the wallet CLI? This looks like the transaction successfully completed and the sdk should be able to update the wallet accordingly.
I just checked with someone and it sounds like it is getting stuck. I'll have to take a look at this in more depth to see if I can get a better understanding of what's causing this problem. So it sounds like you made it to step 2 in the getting started guide in Indy-Node is that correct?
hey - I just got it to run through all of them. I reconfigured everything from scratch and it appeared to work fine... zipped through the entire how to for write & query verkey. to sum it up, the issue was in the configuration. I ran this command before:
```generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 4 --ips '191.177.76.26,22.185.194.102,247.81.153.79,93.125.199.45'
This node with name Node4 will use ports 9707 and 9708 for nodestack and clientstack respectively```
with my respective IPs... but I didn't take care to look at the order that I put them in. So... node 4 was actually node 1, node 2 was node 3, so on. once I redid this with the correct order, and edited the docker_pool_transactions_genesis file respectively.... it worked
thanks for the quick replies :) gonna keep proceeding w/ the how-tos and get an idea how I can start building upwards :)
@samadsajanlal Thank you for working your way through all these challenges! Would you mind documenting anything that could be improved in the indy-sdk to make it easier who follow in your footsteps?
sure - i'll make sure to submit a pull request for any updates to the documentation I find needed along the way :)
Has joined the channel.
Has joined the channel.
I'm expecting this channel will come back to life with discussions about reference agents and agencies, especially with the good work @mhailstone and @saholman are working on, and the work @mboyd and @dbluhm have started.
A reminder, if you're doing released code on the stable branch, #indy is the right place for those discussions, this channel is for development issues on the master branch of the indy-agent repo (newly created, not to be confused with the old sovrin-agent repo).
@dbluhm would you be able to post the link to the new indy-agent repository? @saholman has already made the first PR with a great start. I'll work with him to write a readme that describes our effort and what we want the Indy Reference Agent to become over time.
https://github.com/hyperledger/indy-agent
Has joined the channel.
@saholman Where can we find agreed upon definitions for the json message structure for connection and credential requests and responses?
Has joined the channel.
Has joined the channel.
Has joined the channel.
@mboyd That is a great question. There are no official message structures defined as far as I am aware but we are using the message structures in the getting started guide as a resource.https://github.com/saholman/indy-sdk/blob/master/samples/nodejs/gettingStarted.js
@swcurran Does the BCGov team have anything about standardized messages for credential exchange, and also how to tell different types of messages from one another?
Has joined the channel.
@mboyd - no. To this point, we've been communicating between Issuer/Verifier Agents and TheOrgBook - a specialized Holder, and not worrying much about more generalized messaging. As such, the Issuer/Verifier Agents have been hitting HTTPS endpoints of TheOrgBook. We've done some planning on messaging and even some consideration of Cloud Agents, but haven't worked on that yet.
FYI - here are the current endpoints - the 4 endpoints under BCovrin. https://django-devex-von-test.pathfinder.gov.bc.ca/api/v1/#/bcovrin
I think the plan is to make a single endpoint with a message payload, but the protocol hasn't been worked out yet.
Using indy-sdk, how would we set the endpoint of a DID and retrieve it from the ledger. libindy seems to lookup the endpoint in the wallet before looking on the ledger, so if you are only running locally and not looking up another DID on the ledger, it works fine.
Using indy-sdk, how would we set the endpoint of a DID and retrieve it from the ledger? libindy seems to lookup the endpoint in the wallet before looking on the ledger, so if you are only running locally and not looking up another DID on the ledger, it works fine.
We build an attribute request and sent it to the ledger, but we aren't able to get it back out from another running process looking it up on the ledger. We're not sure if it's actually being set on the ledger, though.
@mhailstone Someone else with more experience may be able to help you before I can but I'll check this out and let you know what I find
@mboyd the standardization of message formats is currently being worked out in DIF I believe, so we can make them interoperable as well. @TelegramSam would know the latest state of where that's currently at.
When an agent receives a message that as been anoncrypted/authcrypted, how does the agent know that it is anon or auth crpyted? Is the message annotated saying which one it is? @nage
When an agent receives a message that as been anoncrypted/authcrypted, how does the agent know that it is anon or auth crpyted? Is the message annotated saying which one it is? @nage / @TelegramSam
@dbluhm - AFAIK no one has progressed to that point, at least publicly. If there is something that has gone to that level, I'd love to see it :-).
@swcurran lol me, too, it seems... On just a theoretical level, though, there wouldn't be a way to know unless the encrypted message was wrapped with some kind of meta data, right?
Yes - the message is basically an envelope with some meta data and a (likely) encrypted payload, with enough information to decrypt it and see what happens next. There could be multiple layers of envelopes, encryption and routing in the message.
I've seen a good presentation that @danielhardman did on this as the message is passed from person 1 to person 2 via their respective edge agents and cloud agencies and agents. It turns out there are a lot of layers - many of which are just go-betweens that are not privy to the actual message being passed.
I've seen a good presentation that @danielhardman did on this as the message is passed from person 1 to person 2 via their respective edge agents and cloud agencies/agents. It turns out there are a lot of layers - many of which are just go-betweens that are not privy to the actual message being passed.
@dbluhm We are using libsodium. I think it packages the encrypted bytes in a way that allows us to tell which is which. However, I don't know the details. @gudkov would know.
Slides for the presentation that @swcurran refers to are at https://docs.google.com/presentation/d/1H7KKccqYB-2l8iknnSlGt7T_sBPLb9rfTkL-waSCux0/edit -- and on the title slide, there's a link to a recorded version of the presentation. The recording contains some detail that's missing from the slides.
Thanks @danielhardman - that's the one. It's great.
@danielhardman Oh, interesting. The current indy-sdk wrapper and getting started guide don't seem to reflect that, unfortunately (from what I could tell at least). Thanks for the reference; it was very informative -- especially the "mail clerk" idea which I hadn't grasped quite yet
Sorry, to be more specific, the getting started guide doesn't seem to make use of inferring the -cryption type
@dbluhm Perhaps I'm wrong. Like I said, Slava is the definitive source.
Has joined the channel.
hello ! I am working on the python wrappers, but I have some questions : when we create a ledger configuration, what does it exactly mean ? more like a copy of the ledger or a copy of all information about nodes .. ?, and when the prover receives a claim from the issuer and stores it with the functions anoncreds.prover_store_credential where is it stored ? I can't find any of the exchanges done through python wrappers stored somewhere ? can you please help me figure this out ?
@Kelattar Your question is definitely relevant to #indy-agent but you may have more success asking in #indy-sdk which is the channel and repository that house the python wrapper and discussion about it
@dbluhm you're right thanks
Not sure if this is strictly an agent question or not. Any guidance would be helpful. But has anyone given any thought to disconnected/offline user agents running on mobile devices that connect to each other over Bluetooth? No reason that a proof request and response couldn't be done this way. But the verification is going to be a gotcha since the signature of the issuer on any of the attributes submitted for the proof can't be verified. Has any thought been given to chaining like with certs? So that I can still have some level of trust in the document assuming I know about one of the certs in the chain?
That's a good suggestion for a use case. I haven't personally considered it, but I'll start considering it now.
@danielhardman On the Indy call, Sean mentioned that you are making a test suite for indy-agent? Would you be able to give us more information about that? We'd love to be building our reference agent with the tests in mind.
Screen Shot 2018-05-17 at 9.15.29 AM.png
@danielhardman is the agent policy registry work planned?
the ledger in that sequence diagram is the public ledger?
Yes, but I'm still probably a week away from having a fully coherent description. I'll be raising a PR into the indy-rfc repo about it... I'm breaking the tests into "core" and "extensions" (where extensions may not be relevant to all agents). I'm also distinguishing between "inbound" and "outbound" tests. Inbound tests are those where an agent has to listen and understand; outbound tests are those where an agent actively requests stuff from others. Some agents might be passive listeners, whereas others might be proactive talkers.
The first coherent thing you'll see is a list of test descriptions. Later, I'll write code that uses the python wrapper around libindy to talk to an agent and, in an implemented test suite, prove its behaviors.
Also, as @dbluhm and I build the ref agent, we are trying to understand how dids, verkeys, and endpoints are stored in an agent's wallet and also on the ledger.
Here is our process for sending and handling a connection request. I think we've accidentally mixed some of the ledgerless did theory into our design, and I'd love for someone to set us on the right path.
In our current design (which we've pulled mostly from @danielhardman's 'how dids, keys, and credentials work' doc), when a connection request is sent, the sender agent A
1. creates a new did and verkey for the transaction, and stores it in their wallet.
2. sends their did, verkey, and endpoint in an out-of-band channel (or us, it's an http post request) to agent B.
then agent B:
1. Accepts request
2. creates new did and verkey for the relationship ( did@B:A & vk@B:A), stores it in wallet as my_did.
3. stores agent A's did and verkey in wallet as ( did@A:B & vk@A:B)
4. creates a pairwise connection with did@A:B & vk@A:B and did@B:A & vk@B:A, and stores that in wallet
5. stores agent A's endpoint somewhere... (see below)
6. creates a connection response, anon_crypts the data with agent A's verkey that they sent over, then sends agent A --> did@B:A, vk@B:A, e[B] (endpoint of B) back to agent A.
agent A handles the response by:
1. anon_decrypting message
2. creating pairwise connection and storing it in wallet.
3
Here is our process for sending and handling a connection request.
I think we've accidentally mixed some of the ledgerless did theory into our design, and I'd love for someone to set us on the right path.
In our current design, when a connection request is sent:
*Connection Request*
the sender agent A:
1. creates a new did and verkey for the transaction, and stores it in their wallet.
2. sends their did, verkey, and endpoint in an out-of-band channel (or us, it's an http post request) to agent B.
*Connection Response*
agent B:
1. Accepts request
2. creates new did and verkey for the relationship ( did@B:A & vk@B:A), stores it in wallet as my_did.
3. stores agent A's did and verkey in wallet as ( did@A:B & vk@A:B)
4. creates a pairwise connection with did@A:B & vk@A:B and did@B:A & vk@B:A, and stores that in wallet
5. stores agent A's endpoint somewhere... (see below)
6. creates a connection response, anon_crypts the data with agent A's verkey that they sent over, then sends agent A --> did@B:A, vk@B:A, endpoint of B back to agent A.
agent A *handles the response* by:
1. anon_decrypting message
2. creating pairwise connection and storing it in wallet.
*2 Questions:*
1. what are we missing? @danielhardman @swcurran @mhailstone I would love your thoughts
2. what should we be writing to the ledger?
Also, as @dbluhm and I build the ref agent, we are trying to understand how dids, verkeys, and endpoints are stored in an agent's wallet and also on the ledger.
Here is our process for sending and handling a connection request. I think we've accidentally mixed some of the ledgerless did theory into our design, and I'd love for someone to set us on the right path.
In our current design (which we've pulled mostly from @danielhardman's 'how dids, keys, and credentials work' doc), when a connection request is sent, the sender agent A
1. creates a new did and verkey for the transaction, and stores it in their wallet.
2. sends their did, verkey, and endpoint in an out-of-band channel (or us, it's an http post request) to agent B.
then agent B:
1. Accepts request
2. creates new did and verkey for the relationship ( did@B:A & vk@B:A), stores it in wallet as my_did.
3. stores agent A's did and verkey in wallet as ( did@A:B & vk@A:B)
4. creates a pairwise connection with did@A:B & vk@A:B and did@B:A & vk@B:A, and stores that in wallet
5. stores agent A's endpoint somewhere... (see below)
6. creates a connection response, anon_crypts the data with agent A's verkey that they sent over, then sends agent A --> did@B:A, vk@B:A, endpoint of B back to agent A.
agent A handles the response by:
1. anon_decrypting message
2. creating pairwise connection and storing it in wallet.
*2 Questions:*
1. what are we missing? @danielhardman @swcurran @mhailstone I would love your thoughts
2. what should we be writing to the ledger?
This looks virtually identical to what Evernym has done, although I'm not sure about your use of anon(de)crypt versus auth(de)crypt in the flow.
Looks pretty good - nice to see written :-). A couple of notes:
* I would suggest that a DID Doc be used for sending/storing DIDs. So on 2 in Connection Request is "Send the DID and DID Document in an...". That also solves the question in 5.
* Hadn't thought of where the pairwise relationship data goes, but I had assumed it would be outside the wallet, but maybe inside the wallet makes more sense.
Looks pretty good - nice to see it written :-). A couple of notes:
* I would suggest that a DID Doc be used for sending/storing DIDs. So on 2 in Connection Request is "Send the DID and DID Document in an...". That also solves the question in 5.
* Hadn't thought of where the pairwise relationship data goes, but I had assumed it would be outside the wallet, but maybe inside the wallet makes more sense.
@danielhardman do you use any encryption for the bootstrapping a connection phase?
I don't think we encrypt on the backchannel. But once we have have DIDs and verkeys, I think we may.
@swcurran looks like the indy api has a `set_did_metadata` signature. Would the Did Doc be stored in the wallet as the did's metadata? Also, I found this [did doc spec in the sovrin protocol](https://github.com/sovrin-foundation/sovrin/blob/b3f2a6c0d29e9d581bffcc3e9dcf4a28e5df75ed/spec/did-method-spec-template.html#L182), but it's telling us to store it on the ledger wheres from what I understand, we're storing dids in the agent wallets
@swcurran looks like the indy api has a `set_did_metadata` signature. Would the Did Doc be stored in the wallet as the did's metadata? Also, I found this (did doc spec in the sovrin protocol)[https://github.com/sovrin-foundation/sovrin/blob/b3f2a6c0d29e9d581bffcc3e9dcf4a28e5df75ed/spec/did-method-spec-template.html#L182], but it's telling us to store it on the ledger wheres from what I understand, we're storing dids in the agent wallets.
I believe that would work. While the DID doc is used for the ledger, I would think we want to use the same format for the pairwise relationships.
honestly, I still don't understand at what points an agent should write a did/did doc to the ledger. Is there a reference to when that happens?
The Sovrin protocol repo is an embodiment of lots of thinking, and I hope we begin converging around it over time--but its coverage is uneven. I wouldn't attempt to implement anything there without talking about it more broadly to get a read on how complete and accepted the thinking is.
A public DID should update its DID doc on the ledger any time something in the DID Doc changes.
"metadata" in indy sdk doesn't refer to DID docs; it refers to application-specific data that some vendor/developer wants to associated with a DID in the wallet.
@mboyd - a DID is written to the ledger if they need a public endpoint - analogous to a public URL for website. When creating a pairwise relationship - no need to write it to the ledger.
@danielhardman - but that metadata could be in the format of a DID Doc, couldn't it?
Yes, the metadata could contain a DID doc. But that would be a quirky path to take. Would work; would just be odd.
It's probably the best solution we have for the time being, *if* you want DID Docs to go into wallets. In a month, when Darko Kulic's work on searchable wallets with non-secret data is offered to master, there will be a better way. And a couple months after that, when we finally get around to microledgers, we'll have a good and permanent solution. Microledgers are just ledgers for pairwise--so the DID Docs would go there.
vs. what? If I get a DID from another endpoint, I get a GUID (the DID), possibly one or more verkeys, possibly one or more endpoints. All those would be in the DID Doc. Wouldn't it best to just use the DID Spec to store the data?
vs. what? If I get a DID from another endpoint, I get a GUID (the DID), possibly one or more verkeys, possibly one or more endpoints. All those would be in the DID Doc. Wouldn't it best to just use the DID Spec format to store all the data in a consistent way?
what do you mean by "use the DID Spec"?
As in the format defined in the DID Spec. The JSON/JSON-LD Document.
So when an agent is created for the first time (let's say for someone like alice, not an org like faber), it should write a public did to the ledger with a did doc, so that its endpoint is publicly reference-able, and then create pairwise dids/verkeys for each connection it makes with other agents. When two agents want to connect, they reference each other's public did on the ledger, but sign and send messages using their pairwise dids and verkeys. Yes?
I'm not making any claim at all about doc format. Of course we'd use the format from the DID Spec. I'm only talking about *where* we store the data.
OK - I am making a claim about the format :-) As in what would be stored in the wallet. But, you're right, not crucial.
@mboyd - not necessarily. There may not be a reason for Alice to ever have a public DID. She could "find" Faber using it's Public DID and attempt to connect by creating a pairwise DID for the relationship. She wouldn't need a public DID in this case. She proves her identity later, using Verifiable Credentials. Initially, she is just creating a communication path with Faber.
@mboyd - not necessarily. There may not be a reason for Alice to ever have a public DID. She could "find" Faber using their Public DID and attempt to connect by creating a pairwise DID for the relationship. She wouldn't need a public DID in this case. She proves her identity later, using Verifiable Credentials. Initially, she is just creating a communication path with Faber.
great. That's what we're currently doing.
I guess I've been wary of storing correlatable data outside of a wallet. Daniel and I have been making a more generic peer 2 peer use case - like if alice and bob want to send messages to each other using Sovrin. If alice and bob want to connect using to each other over the sovrin ecosystem, neither of them will have public dids on the ledger, and won't really have a need to use the ledger until something needs to be verified - like a credential - for a more formal transaction.
In this case, if metadata for each DID in the wallet is application-specific data that some vendor wants associated with a DID, then alice can just store bob's endpoint in her wallet with his did and verkey in the metadata, or I guess could also store it in some sort of other persistent data store like a traditional web app
I guess I've been wary of storing correlatable data outside of a wallet. @dbluhm and I have been making a more generic peer 2 peer use case - like if alice and bob want to send messages to each other using Sovrin. If alice and bob want to connect using to each other over the sovrin ecosystem, neither of them will have public dids on the ledger, and won't really have a need to use the ledger until something needs to be verified - like a credential - for a more formal transaction.
In this case, if metadata for each DID in the wallet is application-specific data that some vendor wants associated with a DID, then alice can just store bob's endpoint in her wallet with his did and verkey in the metadata, or I guess could also store it in some sort of other persistent data store like a traditional web app
The use of the wallet makes sense.
One thing to consider is adding a Cloud Agent to the picture - as the DKMS document shows. If the Cloud Agent is purely for transport of messages and the endpoint is generic and uses the destination DID for internal routing (Agency to Cloud Agent) and for routing to the Edge Agent, that can eliminate some further correlatability.
That brings me to something else I've been thinking for a bit. @danielhardman - would love to get your thoughts on this.
What if a pairwise relationship always had two keypairs for side - one for the pairwise relationship between the two identities at the edge, and a second for encryption to the endpoint - e.g. for message transportation? If the Agent was acting on it's own (no Cloud Agent), it would create both keypairs itself, and expect to receive the message encrypted with the transport keypair.
However, this also works if the Identity has a Cloud Agent. In creating the DID, Alice's Edge Agent would request the Cloud Agent create, remember (associated with the DID) and return the verkey and endpoint to the Edge Agent who would put both into the DID Document to send to Bob. Then, regardless of the routing between the Endpoint to the Edge Agent, the other Identity (e.g. Bob) knows how to encrpyt the message to the Alice's Endpoint and how to encrypt/sign, etc. messages only for Alice.
That brings me to something else I've been thinking for a bit. @danielhardman - would love to get your thoughts on this.
What if a pairwise relationship always had two keypairs per side - one for the pairwise relationship between the two identities at the edge, and a second for encryption to the endpoint - e.g. for message transportation? If the Agent was acting on it's own (no Cloud Agent), it would create both keypairs itself, and expect to receive the message encrypted with the transport keypair.
However, this also works if the Identity has a Cloud Agent. In creating the DID, Alice's Edge Agent would request the Cloud Agent create, remember (associated with the DID) and return the verkey and endpoint to the Edge Agent who would put both into the DID Document to send to Bob. Then, regardless of the routing between the Endpoint to the Edge Agent, the other Identity (e.g. Bob) knows how to encrpyt the message to the Alice's Endpoint and how to encrypt/sign, etc. messages only for Alice.
That brings me to something else I've been thinking for a bit. @danielhardman - would love to get your thoughts on this.
What if a pairwise relationship always had two keypairs per side - one for the pairwise relationship between the two identities at the edge, and a second for encryption to the endpoint - e.g. for message transportation? If the Agent was acting on it's own (no Cloud Agent), it would create both keypairs itself, and expect to receive the message encrypted with the transport keypair.
However, this also works if the Identity has a Cloud Agent. In creating the DID, Alice's Edge Agent would request the Cloud Agent create, remember (associated with the DID) and return the verkey and endpoint to the Edge Agent who would put both into the DID Document to send to Bob. Then, regardless of the routing between Alice's Endpoint to the Edge Agent, the other Identity (e.g. Bob) knows how to encrpyt the message to the Alice's Endpoint and how to encrypt/sign, etc. messages only for Alice.
That brings me to something else I've been thinking for a bit. @danielhardman - would love to get your thoughts on this.
What if a pairwise relationship always had two keypairs per side - one for the pairwise relationship between the two identities at the edge, and a second for encryption to the endpoint - e.g. for message transportation? If the Agent was acting on it's own (no Cloud Agent), it would create both keypairs itself, and expect to receive the message encrypted with the transport keypair.
However, this also works if the Identity has a Cloud Agent. In creating the DID, Alice's Edge Agent would request the Cloud Agent create, remember (associated with the DID) and return the verkey and endpoint to the Edge Agent who would put both into the DID Document to send to Bob. Then, regardless of the routing between Alice's Endpoint to the Edge Agent, the other Identity (e.g. Bob) knows how to encrpyt the message to the Alice's Endpoint and how to encrypt/sign, etc. messages only for Alice.
@swcurran - on your first point, that's where we're headed - although for now we'd like first like to get 2 agents talking with each other as a basic, general use case
re: DKMS and Cloud Agents, I've been trying to ask if the agent policy registry exists yet. I assume it doesn't as I don't see any sdk operations around it. If anyone can clarify it would be great, thanks.
@swcurran, I want to be really picky for just a minute about semantics. Technically, the keypairs per side are actually *per agent*. Alice herself doesn't have any keys; she's a human being who can't speak bytes-on-a-wire. Only the agent on her phone has keys. So when we use the shorthand phrase "Alice's keypair for the Alice~Bob relationship", we are really implying that Alice has a keypair for one particular agent that she uses in that relationship. If Alice has 3 agents that she uses in the Alice~Bob relationship (whether those 2 agents are both edges, both clouds, or a mix), then she has 3 keypairs.
With that on the table, I think what you're suggesting is that Alice share a key for endpoint encryption across all her agents. Am I right?
Agreed on the semantics.
No on the question. The Cloud Agent has an endpoint and for Alice's A:B relationship, it creates a keypair, keeps the private key and sends the public key to Alice with the Agency endpoint. Alice puts the endpoint and that public key (for transport encryption) into the DID Doc. Her Edge Agent also generates a keypair that goes into the DID Doc for message encryption that her Cloud Agent doesn't know. Bob's Agent then has all it needs to communicate with Alice's Edge Agent and to encrypt the message to the endpoint.
Agreed on the semantics.
No on the question. The Cloud Agent has an endpoint and for Alice's A:B relationship, it creates a keypair, keeps the private key and sends the public key to Alice with the Agency endpoint. Alice puts the endpoint and that public key (for transport encryption) into the DID Doc. Her Edge Agent also generates a keypair and the public key for that goes into the DID Doc for message encryption that her Cloud Agent doesn't know. Bob's Agent then has all it needs to communicate with Alice's Edge Agent and to encrypt the message to the endpoint.
That first line might actually read - "The Cloud Agent's Agency has an endpoint..."
Sorry for being late to this discussion. I've been working on the sequence diagram and thought I'd share it:
Sorry for being late to this discussion. I've been working on the sequence diagram so here's what I have:
sovrin_connection_transaction.png
Here is the puml:
```@startuml
actor Alice as A
participant "Alice's\nAgent" as AAg
participant "Bob's\nAgent" as BAg
actor Bob as B
'Connection Offer
A -> AAg: Initiate connection transaction
AAg -> AAg: Create connection offer nonce
AAg -> AAg: Create connection offer message
AAg -->> BAg: Send connection offer message
BAg -> BAg: Store connection offer message\nand wait for user interaction
B -> BAg: Accept connection offer
'Connection Request
BAg -> BAg: Create DID for connection offer
BAg -> BAg: Create connection request nonce
BAg -> BAg: Create connection request message
BAg -->> AAg: Send connection request message
AAg -> AAg: Identify offer nonce\nand associate to connection offer
AAg -> AAg: Store connection request message\nand wait for user interaction
A -> AAg: Accept connection request
'Connection Response
AAg -> AAg: Create DID and associate with\nBob's DID sent in connection request
AAg -> AAg: Create connection response message
AAg -> AAg: Anoncrypt connection response\nmessage with Bob's DID VerKey
AAg -->> BAg: Send connection response message
BAg -> BAg: Identify which DID managed\nby this agent to use to process message
BAg -> BAg: Anondecrypt connection response message
BAg -> BAg: Verify connection request nonce\nhas not been previously consumed
BAg -> BAg: Associate Alice's DID to Bob's DID which was\nsent to Alice with the connection request nonce
'Connection Acknowledgement'
BAg -> BAg: Create connection acknowledgement message
BAg -> BAg: Authcrypt acknowledgement message
BAg -->> AAg: Send connection acknowledgement message
AAg -> AAg: Identify which DID managed\nby this agent to use to process message
AAg -> AAg: Authdecrypt connection acknowledgement message
@enduml```
Here are some examples of the message structure that we are also coming up with:
Connection Offer:
```{
aud:
Here are some examples of the message structure that we are also coming up with:
Connection Offer:
```{
aud:
We are assuming that Alice and Bob have a "public" DID that is associated with the endpoint, but that other DIDs can be private to encrypt other messages with underneath that public DID. Therefore, all messages sent to and endpoint are anon-crypted to the endpoint which wraps the message structure above. The outer message of the public DID would look like:
```{
message:
@mboyd Here is the first useful thing you can read about agent test suites: https://github.com/dhh1128/indy-rfc/blob/796c5411e0847e4b17743ce240cbdcaa11ee8ec4/text/agent-test-suite-interface/README.md
More to come...
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=snLHefLN8GykRDhaw) @swcurran I agree that if the DID is not on the ledger than you will need to provide a DID Document with the connection request. In our initial implementation so far we are assuming that all DIDs are on the ledger.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=g3yvjyLrdRRNMTPb6) @swcurran Steve, our take on this would be that an "agency" or agent that is managing the endpoint would need to be on the ledger, but that all messages for DIDs (specified in the decrypted message portion and identified in the "aud" or "to" attribute) inside the message wouldn't have to be on ledger.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Ew2YfE5K2rwr7As29) @swcurran Steve, this sounds exactly what we are doing. :)
@mhailstone - so the public DIDs for Alice and Bob are for transport, and the private DIDs for P2P communications? That's interesting. I was thinking the transport DID would be within the pairwise relationship to reduce correlation. The Cloud Agent would have a unique keypair per P2P relationship. That may be overkill, but this is where my lack of experience with correlation threats comes in. Listening to Nathan has got me thinking about it everywhere.
In thinking through your sequence diagram, I thinking that the model for "finding" others needs to be thought through to humanize it. As was stated at Rebooting Web of Trust - if a person in the public sees a DID, we've failed :-). What current world and real world mechanisms can we use in bootstrapping a connection? QR codes and anything that can embed a reasonably complex URL are obvious. Introductions from one person to another using Agents would seem possible. It seems there needs to be a way as easy as an email address to initiate the connection.
@swcurran For sure, how the UI renders the connection request and other messages definitely needs to be humanized. :) For the demo we did with Microsoft, the logged in user clicked a button on the website page that generated a custom protocol request `did-auth://?jwt=
I think with an Agency, the endpoint correlation is less likely - the same message type with an encrypted payload goes in for all Agents of the Agency and there is internal mapping for the DID to Edge Agent relationship. Important is to have enough users of an Agency.
@mhailstone - I like the format for your types: `type: "urn:sovrin:agent:message_type:sovrin.org/connection_offer"` is this syntax defined anywhere? (probably in the did spec, which I still need to read)
we have not yet implemented the concept of a `connection offer` or a `connection acknowledgement`, but I think these messages make sense, and allow greater extensibility of ways in which two agents can connect.
In regards to which DIDs are stored where, you are saying that when Alice and Bob create their agents for the first time (let's assume that they are not using any intermediary agents/agencies), They will both write a did to the ledger with a did doc that contains their endpoint, Their verkey, verkeyID, etc, and when Bob receives a connection offer from Alice, he will:
1. use her did to get her verkey and endpoint from the ledger
2. send a connection request with that information
If the connection is direct, the data on the ledger will be correlatable with their edge agents (the agent's direcly under their control), right? So are you assuming that their will always be cloud agent intermediaries when A and B want to communicate?
(if it's too tedious to answer here, let's voice chat next week)
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dqYWdv8zb7u8db8AY) @swcurran Exactly. If you have an Agency, then the endpoint is obfuscated away, but I think the Agency needs to have a "public" DID on the ledger that has a known endpoint. All messages for the Agency need to be anon-crypted for the public DID, then the Agency can decrypt the message and see who the message is really for. The internal message is encrypted (whether anon or auth) for the intended DID. The Agency would know all the DIDs that it is managing and would therefore be a point of correlation.
On the other hand, if you have an Agent for one owner, then the endpoint of that Agent would be the correlation point because every DID pair would have the same endpoint configured with it.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=E5rHAhvcmXegxZEkg) @mboyd @mboyd I tried to follow the URN convention, but if the community likes this format, I am definitely open to changes that makes sense. I just wanted a message type convention that would protect against collisions.
Concerning the data configured with the DID, I would recommend that if the DID is not on the ledger, or if the DID doesn't have the DID document on the ledger or an endpoint attribute configured on the ledger, then the use of the connection offer is important. The connection offer actually provides that information. You could insert that information in the connection request as well, but the connection offer is a way to provide that independently and not put too much correlating information in the connection request. The connection offer may be unnecessary, though, and we can discard it if we want to put everything in the connection request.
The convention for the URN was that other organizations could create their own message types:
`urn:sovrin:agent:message_type:byu.edu/ces_transcript`or something like that. If we want to reverse the order of the domain name, we could do that as well:
`urn:sovrin:agent:message_type:edu.byu/ces_transcript`
@mhailstone - re: urn - the DID Spec talks about service endpoints and I know that @drummondreed was pushing on including examples of how they are to be dereferenced. See: https://w3c-ccg.github.io/did-spec/#service-endpoints. That might be helpful in what you are doing.
@swcurran Here is the Universal Resolver project similarly re: that as well: https://github.com/decentralized-identity/universal-resolver
@danielhardman - regards my thought above about DID Docs and having the DID Doc include the Edge2Edge and Endpoint Keys.
I'm going through your Love Letters document, and the "Initial State" drawing - which is tricky to understand. However, if we use that "convention" for the contents of a DIDDoc (and related private keys) then we just have to say that each of the four Agents possesses DIDDoc:AB and DIDDoc:BA, and we know who can talk to whom.
In other words, DIDDoc:AB implies a bunch of details that need not be specified again:
* There is a unique DID related to the DIDDoc
* Alice's Edge Agent owns/controls the DID and DIDDoc (can update the DIDDoc - key rotation etc.)
* Alice's Edge Agent owns/controls the public key for Edge2Edge encryption, etc. - has it in it's wallet
* Alice has a specified service endpoint
* Alice's Endpoint Agent (her Edge or Optional Cloud Agent) owns the public key for Endpoint encryption - has it in it's wallet
* All of the keys, etc. relate to Alice's relationship with Bob
The DID/DIDDoc may be on the ledger (public and resolvable from just the DID) or only shared pairwise.
Here are some questions that have driven our thoughts and design:
- What does a relationship look like?
- What is the structure of message type?
- Is the exclusive functionality of an Agency to route messages to Cloud Agents?
-- Agency must put public DID on the ledger
-- Cloud Agents must register DIDs in the Agency so the Agency knows how to route messages for them
- Does an endpoint attribute on the ledger only hold host or IP address and port? (We can't put a whole URL as the endpoint currently.)
- How does the agent know who the connection request is from? Does it look it up on the ledger as well as any DID attributes configured with it on the ledger?
@mhailstone - good questions. On the ones of which I have an opinion:
* Technically, I think the relationship includes - the history of: DIDDocs for the pair, references to Verifiable Credentials exchanged, human-friendly references to the parties.
* Is the exclusive functionality of an Agency to route messages - mostly. Will do things like enable registration and updates, but in general - yes.
* Agency must put public DID on the ledger - Not really - perhaps for discovery, not for message routing. Agency maintains a DID to (internal) Agent routing table, and DID to Edge Agent routing table (may be a different DID - not sure)
* Cloud Agents must register DIDs... - yes - I called that a routing table
* Endpoints must meet DID Spec, so will be able to use URLs soon.
* How does the agent know who the connection is from? - Too much for a Friday afternoon before a long weekend. My gut is the Agent doesn't care and uses Verifiable Credentials to resolve who. Until a VC from an "acceptable" issuer is received, the Agent doesn't notify the human about the connection. This prevents unsolicited spamming.
@swcurran - thanks for the responses, here are my added thoughts to yours
- relationships -> paired DIDs, DIDDocs and any attributes associated with the DIDs, references to all exchanged message types including: VCs, proof reqs/proofs, connection reqs/responses/etc.
- agency -> I'm seeing this as the agent with a configured endpoint or eventually a DIDDoc with an endpoint (the chain of communication might look like Edge Agent -> Cloud Agent <-> Agency <-> Agency <-> Cloud Agent <- Edge Agent) The Agency has a routing table for the Cloud Agent, the Cloud Agent is queried by the Edge Agent to consume messages. The ratio would be Agency *:* Cloud Agent, Cloud Agent 1:1 Edge Agent. The Cloud Agent is a place holder for messages that the EdgeAgent retrieves and then decrypts for processing. The problem I see with this is that the chain of encryption would have to be understood by each end of the message construction/deconstruction process on each side. With this said, Agencies would have a well known DID with an endpoint that messages can be sent to.
- Who is the connection from? -> We are assuming that the user needs to accept all connection requests and interactions and will probably give them a name. Hopefully most of the time the user will know the entity that invoked the request, but definitely that doesn't have to be the case. I suppose either way a DDOS attack of connection requests could happen. Not sure how to prevent that because a new DID can be generated for every new connection request.
Too much for a Friday sentiment shared here and I'll probably have a different opinion on Monday. ;) Thanks for the dialog!
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@jonathanreynolds As a follow up to the indy WG call, @mboyd, @mhailstone, and I have all been working on creating the reference agent (https://github.com/hyperledger/indy-agent) that @nage mentioned. We're still working through the early stages but we'd love to talk about our progress and yours sometime. We try to keep up here on Rocketchat and it'd be great to talk in an Agent WG call as well.
As mentioned in the Indy WG call, we would like to start up a dedicated Agent WG where we can have discussions (there is a lot to talk about). What day/times will work, and does anyone want to volunteer to be considered for chair of that discussion group
Questions:
How does an agent identify who the connection offer/request/response is from?
If we use exclusive pairwise identifiers, is there meta information with the connection transaction that can be used? Does the pairwise identifier (their_did) refer to an alias DID on the ledger that is well-known?
Could we use a new message type that is for identification of the pairwise identifier (their_did)?
Even with a new message type, how are we sure the DID is who it says it is?
I suppose this goes into the Web of Trust concept. If we reference an alias DID, the issuer is probably a well-known DID that is a good pattern to follow in referencing. But, if I'm not an issuer (yet) what would I use as the requesting agent?
Questions:
How does an agent identify who the connection request/response is from?
If we use exclusive pairwise identifiers, is there meta information with the connection transaction that can be used?
Should the pairwise identifier (their_did) refer to an alias DID on the ledger that is well-known?
Could we use a new message type that is for identification of the pairwise identifier (their_did)?
Even with a new message type, how are we sure the DID is who it says it is?
I suppose this goes into the Web of Trust concept. If we reference an alias DID, the issuer is probably a well-known DID that is a good pattern to follow in referencing. But, if I’m not an issuer (yet) what would I use as the requesting agent to identify myself?
What is the distinction between private DID pairs and issuer DIDs if one of the parties in the connection is an issuer?
@mhailstone - an issuer is identified by the DID tied to the Cred Def - not the DID used to communicate with the Holder. Further, the Credential uses a keypair also tied to the Cred Def and not related to either the DID tied to the Cred Def or the DID used for transporting the Credential. As a result, it doesn't matter if the pairwise DIDs are on the ledger or not in relation to the issuance of a Credential.
In addition, a Holder/Prover of a set of Credential uses it's link secret to prove to a verifier that it is the party to whom each Credential was issued. Basically - it gives a piece of data encrypted with the link secret to the issuer to embed in the Credential, and then proves to the verifier that it has the link secret to decrypt that piece of data.
@mhailstone - regards your identity questions above. I think proving who you are is about the use of Verifiable Credentials. That is separate from establishing and using a connection - the DID layer. You create a connection with another party, and then you send proof requests as appropriate to establish identity.
More fun - with DIDs: It's really easy to transfer control of a DID to another party - for good or bad. So depending on the needs of your use case - you may need to have the user prove (via VerCreds) every time they access the service (or at least every time they update the DID verkey) if you have to know some attributes of the controlling Identity.
Use Case - I sign up for a Liquor Delivery service and proof my age. Then I change (rotate) the verkey associated with the DID. The Liquor Delivery service needs to verify the age again, as the verkey could have been transferred to someone else that may not be of age.
I do agree that there could and should be metadata associated with the DID for convenience, but that should not be considered "proof" of identity.
@nage I nominate @swcurran and @mhailstone for the chairs of that call. They are doing an excellent job working through this.
Has joined the channel.
@kdenhartog @nage @swcurran I sincerely appreciate the nomination from @kdenhartog to be a co-chair with @swcurran. We are all busy. I was hesitant to put my name in the ring to be the sole and only chair, but I would definitely enjoy working with @swcurran as a co-chair in facilitating and tracking the concepts and implementation concerning agents. @swcurran ? @nage ? What do you think about creating co-chairs?
@kdenhartog @nage @swcurran I sincerely appreciate the nomination from @kdenhartog to be a co-chair with @swcurran . We are all busy. I was hesitant to put my name in the ring to be the sole and only chair, but I would definitely enjoy working with @swcurran as a co-chair in facilitating and tracking the concepts and implementation concerning agents. @swcurran ? @nage ? What do you think about creating co-chairs?
Here is an expression of a scenario with DIDs and connections, credentials, and proofs:
Establish a connection between Alice (A) and Faber College (F) -> Pairwise_DID@A:F and Pairwise_DID@F:A
Faber College creates a DID and has it written to the ledger (either by itself as a Trust Anchor or by another Trust Anchor) and uses it to create a Credential Definition -> CredentialDefinition_DID@F
Alice's Wallet
- Pairwise_DID@A:F
- Pairwise_DID@F:A
Faber's Wallet:
- Pairwise_DID@F:A
- Pairwise_DID@A:F
- CredentialDefinition_DID@F
Ledger
- CredentialDefinition_DID@F
(This next point at least is what is in question in my mind.)
Faber uses the CredentialDefinition_DID@F to issue a credential to Pairwise_DID@A:F
In your ( @swcurran ) scenario, you also mentioned that Faber could issue a credential to a separate DID other than the Pairwise_DID@A:F, correct? I'm not sure where Faber would get that DID, nor how Alice's agent would decrypt the credential offer/credential as well.
Thoughts/clarifications?
Here is an expression of a scenario with DIDs and connections and credentials:
Establish a connection between Alice (A) and Faber College (F) -> Pairwise_DID@A:F and Pairwise_DID@F:A
Faber College creates a DID and has it written to the ledger (either by itself as a Trust Anchor or by another Trust Anchor) and uses it to create a Credential Definition -> CredentialDefinition_DID@F
Alice's Wallet
- Pairwise_DID@A:F
- Pairwise_DID@F:A
Faber's Wallet:
- Pairwise_DID@F:A
- Pairwise_DID@A:F
- CredentialDefinition_DID@F
Ledger
- CredentialDefinition_DID@F
(This next point at least is what is in question in my mind.)
Faber uses the CredentialDefinition_DID@F to issue a credential to Pairwise_DID@A:F
In your ( @swcurran ) scenario, you also mentioned that Faber could issue a credential to a separate DID other than the Pairwise_DID@A:F, correct? I'm not sure where Faber would get that DID, nor how Alice's agent would decrypt the credential offer/credential as well.
Thoughts/clarifications?
When Faber uses the CredentialDefinition_DID@F to issue a credential to Pairwise_DID@A:F, I'm assuming that the credential is anon-crypted in that scenario.
@mhailstone and @swcurran I think cochairs is a great idea, do we have any other nominations for candidates?
@mhailstone - I think you have it above. The paraphrasing of my wording is not what I meant but aligns with the layout you have above :-) - I was meaning that the DID associated with the Cred Def can be different from the pairwise one used to deliver a Cred to a Holder. That DID (generally) has to be public, so that a Verifier can dereference the DID to determine who is the Issuer.
What about getting these scenarios/understandings into something like a Google Doc to start (so that we can have heavy editing/commenting) and then once we get it close, into a github document?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello everyone, got issue while setting up Hyperledger Indy Agent. ``` -------------------------------------------------------------------------------------------------------ERROR-------------------------------------------------------------------------------------------------------
Agent startup failed: [cause : error occurred during operation: client request invalid: InvalidClientRequest('ULtgFQJe6bjiFbs7ke3NJD can have one and only one SCHEMA with name Transcript and version 1.2',)]
-------------------------------------------------------------------------------------------------------ERROR-------------------------------------------------------------------------------------------------------
```
Kindly provide me solution, Thank you.
@vd30992 Are you setting up the nodeJS or the python code?
@mboyd setting up python code. Following this
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error after this cmd : $ python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 9702 --network sandbox
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber Agent but giving above error.
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error.
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error.
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error after this cmd : $ python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 9702 --network sandbox
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error after this cmd :*$ python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 9702 --network sandbox* Any idea?
@mboyd setting up python code. Following this https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md . Trying to setup Faber College Agent but giving above error after this cmd :*$ python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 9702 --network sandbox Any idea?*
Hello everyone, wasted my much time on executing this (https://github.com/hyperledger/indy-node/blob/master/getting-started.md) example on deprecated cli version. Now working on new cli version (https://github.com/hyperledger/indy-sdk/tree/master/cli) but here Unable to run above example because commands are changed. Anyone please guide me that How to run ALICE example using new cli. Thanks for any help :-)
Has joined the channel.
Has joined the channel.
@vd30992 - I haven't looked at the Alice demo in (long, long) while, and am starting it up. Have you looked at the Running Getting Started MD file - https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md?
@vd30992 - I haven't looked at the Alice demo in (long, long) while, and am starting it up. Have you looked at the Running Getting Started MD file - https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md?
Has joined the channel.
@vd30992 One of our guys on the Sovrin team did some work a while back where he essentially translated that example from the old cli to the new cli. You may have a more "complete" experience by looking at the Getting Started guide in indy-sdk but if you'd still like to play with the cli, you might try giving @SteveGoob a message
@swcurran Okay, that means removed Vagrant dependencies & working with Docker only. Thank you for your your direction :-)
@dbluhm Okay, thanks I'll connect with Steave.
Actually - I gave it a try and didn't have a lot of success :-(. The Iron Python notebook didn't seem to work.
vd30992 ^^^
@vd30992 ^^^
@swcurran Ohhh, no issues, we will make it together.
I did try the ibm starter kit and it worked better, but I think it's using the deprecated cli. Not quite sure what the best advice is. I think @dbluhm might have a much better handle on this.
:-)
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=bMmphBGfwBzvTXQou) @swcurran I wasn't directly involved but from what I remember, @SteveGoob had a fair level of success -- might be interesting to compare notes
I'm running docker-compose on docker-for-windows so perhaps that's part of the grief. Not sure. If I get some time I'll take a look again. It's been a long time since I've done the getting started. Our project is nearing production, so we're a little further along :-)
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=d7AkTLSXQGFgYMTop) @swcurran Working with @mhailstone, @burdettadam, and@mboyd on the reference agent, I really need to take a closer look at what you guys have accomplished!
Has joined the channel.
Has joined the channel.
Hello everyone, anyone know how to create *pool_transactions_genesis* file from $
*pool create sandbox gen_txn_file=/var/lib/indy/sandbox/pool_transactions_genesis* this command? I tried to find location *"/var/lib/indy/sandbox/pool_transactions_genesis*" but only blank indy folder found. Thank you very much for any suggestions.
Has joined the channel.
Hi, Does VON_Agent lib require other components such as Von_base or Von_connector. I am trying to create a pair of issuer/verifier agents that exchange claims
^^^ @sklump
Has joined the channel.
We're in the midst of a little refactoring - so I'm not the right one to help you (not a developer), but I'll see about getting others to help.For integration with our TheOrgBook, the old way is permitify (https://github.com/bcgov/permitify) and the new way is von-x (https://github.com/PSPC-SPAC-buyandsell/von-x). Both implement python issuer/verifiers that are driven by configurations. The Wallet/Ledger/Verify and Issuer patterns are all built in.
If you aren't integrating with an instance of TheOrgBook, then they can give you much of the code for the issuer verifier based on von-agent.
We're in the midst of a little refactoring - so I'm not the right one to help you (not a developer), but I'll see about getting others to help.For integration with our TheOrgBook, the old way is permitify (https://github.com/bcgov/permitify) and the new way is von-x (https://github.com/PSPC-SPAC-buyandsell/von-x). Both implement python issuer/verifiers that are driven by configurations. The Wallet/Ledger/Verify and Issuer patterns are all built in.
If you aren't integrating with an instance of TheOrgBook, then they can give you much of the code for the issuer verifier based on von-agent.
We're in the midst of a little refactoring - so I'm not the right one to help you (not a developer), but I'll see about getting others to help.
For integration with our TheOrgBook, the old way is permitify (https://github.com/bcgov/permitify) and the new way is von-x (https://github.com/PSPC-SPAC-buyandsell/von-x). Both implement python issuer/verifiers that are driven by configurations. The Wallet/Ledger/Verify and Issuer patterns are all built in.
If you aren't integrating with an instance of TheOrgBook, then they can give you much of the code for the issuer verifier based on von-agent.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=2XGDDo8Ft9tZNkGAt) @the_identity_guy
Package von_base sets up prerequisites for von_agent. Package von_agent isolates only von_agent code, so a user can install it via pypi. Consult von_base/doc/agent-design.doc for everything to do with von_agent and von_base.
Packages von_connector, von_conx are obsolete, but used to implement a protocol to create claims, create and verify proofs, etc. The current generation of von_agent (1.x) acts as a back end to The Org Book etc, which take their own requests and delegate to von_agent back ends. Instances of von_agent 1.x do not communicate directly. Perhaps they will again one day, but the protocol is obsolete in any case as it builds on the indy data structures prior to revocation support, and the state of the art has moved on since then.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=2XGDDo8Ft9tZNkGAt) @the_identity_guy
Package von_base sets up prerequisites for von_agent. Package von_agent isolates only von_agent code, so a user can install it via pypi. Consult von_base/doc/agent-design.doc for everything to do with von_agent and von_base.
Packages von_connector, von_conx are obsolete, but used to implement a protocol to create claims, create and verify proofs, etc. The current generation of von_agent (1.x) acts as a back end to The Org Book etc, which take their own requests and delegate to von_agent back ends. Instances of von_agent 1.x do not communicate directly. Perhaps they will again one day, but the protocol is obsolete in any case as it builds on the indy data structures prior to revocation support, and the state of the art has moved on since then.
Avoid
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=2XGDDo8Ft9tZNkGAt) @the_identity_guy
Package von_base sets up prerequisites for von_agent. Package von_agent isolates only von_agent code, so a user can install it via pypi. Consult von_base/doc/agent-design.doc for everything to do with von_agent and von_base.
Packages von_connector, von_conx are obsolete, but used to implement a protocol to create claims, create and verify proofs, etc. The current generation of von_agent (1.x) acts as a back end to The Org Book etc, which take their own requests and delegate to von_agent back ends. Instances of von_agent 1.x do not communicate directly. Perhaps they will again one day, but the protocol is obsolete in any case as it builds on the indy data structures prior to revocation support, and the state of the art has moved on since then.
Avoid the temptation to identify a VON agent semantically with an indy-agent. The VON agent aligns semantically more or less with the idea of an indy-sdk trust anchor.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=2XGDDo8Ft9tZNkGAt) @the_identity_guy
Package von_base sets up prerequisites for von_agent. Package von_agent isolates only von_agent code, so a user can install it via pypi. Consult von_base/doc/agent-design.doc for everything to do with von_agent and von_base.
Packages von_connector, von_conx are obsolete, but used to implement a protocol to create claims, create and verify proofs, etc. The current generation of von_agent (1.x) acts as a back end to The Org Book etc, which take their own requests and delegate to von_agent back ends. Instances of von_agent 1.x do not communicate directly. Perhaps they will again one day, but the protocol is obsolete in any case as it builds on the indy data structures prior to revocation support, and the state of the art has moved on since then.
Avoid the temptation to identify a VON agent semantically with an indy-agent, which has evolved on its own track in the last year or so. The VON agent aligns semantically more or less with the idea of an indy-sdk trust anchor.
thank you @sklump, The reason I decided on using VON-Agent to create an agent was because I noticed IBM developed something similar here: https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial . They used VON-Agent within each entity of the Alice use case.
So based on your response, the latest IndySDK is incompatible with that demo as well, provided that the latest IndySDK code is used. Which VON component is up to date with the latest IndySDK? Would it be permitify?
thank you @sklump, The reason I decided on using VON-Agent to create an agent was because I noticed IBM developed something similar here: https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial . They used VON-Agent within each entity of the Alice use case.
So based on your response, the latest IndySDK is incompatible with that demo as well, provided that the latest IndySDK code is used. Which VON component is compatible with the latest IndySDK? Would it be permitify?
We're all working on our own pieces here to bring them back into compliance with indy-sdk. @swcurran can address what component is in what state.
The IBM demo was largely in collaboration with the BC Gov team.
Has joined the channel.
@sklump Could you help me understand the design of the calculations/algorithms of the encode and decode functions?
https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/f20c35443f14156f03183c5287726f5001a59afb/von_agent/codec.py
This is used when creating a credential, correct?
https://github.com/PSPC-SPAC-buyandsell/von_base/blob/master/doc/agent-design.doc, section 3.2.3.5.
If anything else needs explanation, ping me again thanks
Has joined the channel.
Has joined the channel.
I have been dithering and not making the progress I wanted on my agent test suite work. I finally decided it was better to raise a PR against indy-hipe, to promote discussion, than to wait any longer. So here you go: https://github.com/hyperledger/indy-hipe/pull/12.
Explanation: This PR actually proposes 2 different HIPEs. One (in the agent-test-suite-interface folder) is a HIPE for the *harness* used by an agent test suite--it specifies how an agent will be exercised, what assumptions it will make, how results will be communicated, and so forth. The other (in the agent-test-suite-v1 folder) is a HIPE for an initial set of tests. The first folder is mature enough to merit deep consideration. The second folder IS NOT mature enough for that, but it should be a good conversation starter.
If you have time to think about this topic at all, I recommend that you start by reading https://github.com/hyperledger/indy-hipe/blob/30713f72a1bbb2476ccafb5e2f297123d69b47fc/text/agent-test-suite-interface/README.md. The semi-finished material in the other folder will then make more sense.
I am hoping that these HIPEs, in an evolved form that the community buys off on, will be the basis for interoperability discussions in the Indy agent ecosystem, and that it will be used to define success criteria for reference agent contributions in indy-agent.
Great work @danielhardman . You inspired me to wrap up the work I've been playing with the past couple of months. It's an implementation of an agent framework for the dotnet platform.
It's built around the idea of message based communication and extensible message handlers. Each agent is configurable which messages/features it can support as well as the type of transport. In my example I used REST API, but the core implementation is transport agnostic as it's driven by the message protocol.
I was able to setup a docker compose to demo the entire flow, which runs an indy node, issuer agent service and a console client discovering and consuming the agent services.
I wrote a little bit of documentation explaining the technical approach for the framework. Happy to hear any feedback.
https://github.com/streetcrednyc/agent-framework
Has joined the channel.
Has joined the channel.
All,
Stephen Curran (@swcurran) and I have been coordinating on the Indy Agent effort in the Google document I mentioned in last Thursday’s call. https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit# We would like to have more detailed conversations in addition to the weekly Thursday call. We have setup a meeting for this Friday at 8:30 AM MDT for any who would like to join the discussion. The call will be governed under the Linux Foundation Anti-Trust Policy (https://www.linuxfoundation.org/antitrust-policy/).
Here are the zoom meeting details:
Topic: Indy Agent Design/Discussion
Time: Jun 15, 2018 8:30 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
@tomislav - very cool. Makes for a very nice inventory of the messages. For those interested in set of messages defined checkout the list here - https://github.com/streetcrednyc/agent-framework/tree/master/proto
This is using Google's protobuf - https://github.com/google/protobuf - with, as Tomislav points out, many code generators to handle lots of details - except the implementation of what the handler does. Cool stuff!
Thank you @swcurran . Next step would be to try and match the message format to the document you've been working on. Protobuf works nicely with JSON serialization - would be nice to work towards a standardized format. Looking forward to the Indy Agent call on Friday
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=k79Gu5RNRK6EYqZM6) @mhailstone would you mind posting this to the Indy mailing list?
@mhailstone and team :thumbsup:
Thanks @jljordan_bcgov ! Honestly, we have built on top of all the previous work, documentation, and discussion. We are really excited that the work in this project is culminating to this point. Looking forward to the exciting weeks/months ahead! :)
@Sean_Bohan I thought that I had sent it to the mailing list. Would you verify that you see it in your inbox or not?
lemme check
My bad - you posted it on the 11th and I missed it
awesome
No problem. Glad it was sent. Thanks for confirming that. :)
I'm having issues dialling in to the agent WG zoom
Authorized attendees only...
@tomislav Can I get the link to your agent code again, for the protobuf stuff?
@TelegramSam https://github.com/streetcrednyc/agent-framework/tree/master/proto
Hello i'm trying to do a nodejs implementation of the agent, everything is working without errors in the quickstart guide until I try to execute the "npm start" command where I get this error
{ IndyError: CommonInvalidState
at Object.callback (/home/indyana/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidState',
indyCode: 112,
indyName: 'CommonInvalidState' }
any idea to solve the problem ?
Hello, i'm trying to implement the nodejs version of the indy-agent. I followed each step without encountering errors until I try to execute "npm start" where I get the following error:
> indy-agent@0.0.0 start /home/indyana/indy-agent/nodejs
> node ./bin/www
{ IndyError: CommonInvalidState
at Object.callback (/home/indyana/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidState',
indyCode: 112,
indyName: 'CommonInvalidState' }
any idea of the cause of this error ?
@mhailstone ^^
@BreizhIndy Please set the environment variable `RUST_LOG=indy\=trace` for more information. The `CommonInvalidState` error is pretty generic.
Hey Folks - I've put out some feelers for suggestions on Message Protocol helpers (e.g. "Swagger for messaging" to enable code generation, documentation and test generation). Some smart folks responded and interestingly, both suggestions where based on Google's Protobuf. I'm thinking @tomislav is onto something :-).
Suggestions to look at - gRPC (https://grpc.io/)- see inventory of tools - https://github.com/grpc-ecosystem/awesome-grpc - gRPC is from google.
And NATS - https://nats.io/ - which is a CNCF project (Linux Foundation). It doesn't look to me like NATS is what we would want, but I mention it because it is based on Protobuf.
Just taking lessons from hyperledger's playbook. Sawtooth uses protobuf for the validator protocol. It made writing the dotnet sdk a breeze.
Does anyone know where the recording from Friday's Agent WG call is posted?
I tried checking the Indy Folder and couldn't find it
https://drive.google.com/drive/u/1/folders/1Vof1CQDh2ZzSnuAP_vtn0vu5SPvCdNV_
@swcurran ?
@swcurran @mhailstone ?
@nhelmy - the recording will be (but has not yet been) posted here: https://drive.google.com/drive/u/0/folders/1Vof1CQDh2ZzSnuAP_vtn0vu5SPvCdNV_
Sean Bohan set that up for us to post the recordings and agendas.
@mhailstone I didn't manage to print the trace however now I have a PoolLedgerTimeout.
When i inspect my docker containair containing indy-pool I have IpAddress=172.16.0.2, in my config.js file (/indy-agent/nodejs/config.js) the ip address is 127.0.0.1 should I change that ?
Also the port of the container are as followed : 9701/tcp -> 0.0.0.0:9701 / 9702/tcp -> 0.0.0.0:9702 .... 9708/tcp -> 0.0.0.0:9708
I'm just getting started with indy and I don't know which information is relevant for debug
Has joined the channel.
@BreizhIndy You can specify the ip address of your pool with the TEST_POOL_IP environment variable, and without understanding your setup perfectly I would thing `TEST_POOL_IP=127.0.0.1 npm start` would do it. How did you start the pool?
@BreizhIndy You can specify the ip address of your pool with the TEST_POOL_IP environment variable, and without understanding your setup perfectly I would thing `TEST_POOL_IP=172.16.0.2 npm start` would do it. How did you start the pool?
Depending on how you got the pool running in the first place, you may need to rebuild it with the right ip address. The default test pool in the indy-sdk repository must be built with the ip address it will be accessed at. For example, I run the following two commands inside the indy-sdk repository to get it running on a specific ip address. ```
docker build --no-cache --build-arg pool_ip=172.16.0.2 -f ci/indy-pool.dockerfile -t indy_pool .
docker run -itd --name indy_pool -p 9701-9708:9701-9708 indy_pool
```
Depending on how you got the pool running in the first place, you may need to rebuild it with the right ip address. The default test pool in the indy-sdk repository must be built with the ip address it will be accessed at. For example, I run the following two commands inside the indy-sdk repository to get it running for a specific ip address. ```
docker build --no-cache --build-arg pool_ip=172.16.0.2 -f ci/indy-pool.dockerfile -t indy_pool .
docker run -itd --name indy_pool -p 9701-9708:9701-9708 indy_pool
```
Has joined the channel.
I started the pool with the following commands
docker build -f ci/indy-pool.dockerfile -t indy_pool .
docker run -itd -p 9701-9708:9701-9708 indy_pool
specifying the ip to build the pool didn't solve my problem
Looks like I managed to reach the pool by specifying the ip, however I came back to my first error which is "IndyError 112 CommonInvalidState" which is: # Invalid library state was detected in runtime. It signals library bug
Looks like I managed to reach the pool by specifying the ip, however I came back to my first error which is "IndyError 112 CommonInvalidState" which is: #Invalid library state: Ledger merkle tree doesn't acceptable for current tree.
Hi, I am trying to make use of Evernym's VCX, has anyone had success provisioning an Agent?
i.e. provisioning keys for libvcx. My problem is that I don't have a demo agency url. None of the links work, not even the jenkins link that I thought I could use to download a deb file and run in a linux docker container
Has joined the channel.
We now have a JIRA project for the Indy-agent repo here https://jira.hyperledger.org/projects/IA/summary
@dbluhm @mhailstone @burdettadam and I will get it setup and issues moved over, so that we do the have to shuffle backlogs and epics between these major components.
@BreizhIndy Some changes have been made to libindy in the last few weeks that we haven't pulled into our project. I believe if you change the genesis txn data in indy/src/pool/index.js to match that found here: https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/util.js, that it might resolve the issue. If not, we will be pulling the latest version of libindy and resolving any issues soon.
Has left the channel.
@saholman thanks I think that was the problem, the error 112 is now solved bu let place to an error 114 "Pool worker thread finished with erro CommonError(IOError(Custom{kind:InvalidInput, error: Invalid argument})"
@BreizhIndy I haven't pulled the most recent version of libindy and gone through to fix the errors. I'll take a look at it next week and I'll let you know. If you can figure them out in the mean time that would be great! :smiley:
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jnSfD7Eh3y5oL2QhB) @saholman I try but I might not be able to solve the problem sorry
I managed to do it but I didn't do any change
just make sure the version of libindy-crypto in docker are the same than your machine
All,
We are having a Friday Agent Design/Discussion call again this week. Here are the details:
Topic: Indy Agent Design/Discussion
Time: Jun 29, 2018 9:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=aguME8otfLgQ6q8tg) @PhillipGibb Are you still working with libvcx? I was able to get it to build but have not done anything with it yet. I documented what I did in my Ubuntu environment to get it to build here https://github.com/burdettadam/sdk/blob/master/vcx/README.md .
@PhillipGibb Are you still working with libvcx? I was able to get it to build but have not done anything with it yet. I documented what I did in my Ubuntu environment to get it to build here https://github.com/burdettadam/sdk/blob/master/vcx/README.md .
@PhillipGibb what Linux distribution are you using? If your using Ubuntu 16.04, this reference may help https://github.com/hyperledger/indy-sdk/blob/master/libindy/ci/ubuntu.dockerfile#L38. The version of libsodium needed is not available for Ubuntu 16.04, so you have to build it from source.
@burdettadam Yes I have been through this install for OS X successfully but got stuck on the provisioning of keys
@burdettadam trying to build on linux but the part that installs libindy 1.4 requires libsodium18 which.does.not.exist
@PhillipGibb what Linux distribution are you using? If your using Ubuntu 16.04, this reference may help https://github.com/hyperledger/indy-sdk/blob/master/libindy/ci/ubuntu.dockerfile#L38. The version of libsodium needed is not available for Ubuntu 16.04, so you have to build it from source.
@burdettadam yes Ubuntu 16.04
@burdettadam I was using that docker file as a reference, but I can't find the source for libsodium18, only up to 16
I have not seen the libsodiums18 dependency issue. I have followed this (https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md) document, which worked.
@PhillipGibb I have not seen the libsodiums18 dependency issue. I have followed this (https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md) document, which worked.
@mhailstone I think it would be great to go into this call with a firmly set agenda. Do you have a link to a Google Doc containing our agenda?
@burdettadam I get a "undefined reference to `zmq_has" with that process
Has joined the channel.
Has joined the channel.
Hello, is the image indy-agentjs in docker-compose.yml correspond to the indy-pool we built just before ?
I submitted a HIPE for the core message structure that we defined as a community recently. Please add your thoughts to the PR even if you don't have much to say. https://github.com/dbluhm/indy-hipe/tree/core-message-structure/text/core-message-structure
I submitted a HIPE for the core message structure that we defined as a community recently. Please add your thoughts to the PR even if you don't have much to say. https://github.com/hyperledger/indy-hipe/pull/17
@dbluhm Thank you! I added some comments to spur discussion.
Here are my proposals for topics for Friday Agent Meeting:
* The use of a common message specification language - e.g. protobuf
* A two key/one endpoint approach for Identity to Identity (or Domain to Domain) communication
* I'll add this into the Collected Wisdom docs - we can nix this if not needed
* Where to evolve the Protocol Section - Google Doc or HIPE or Sovrin Protocol Repo
* Messages for establishing connections - pre-assumptions, first contact, pairwise DIDs
@mhailstone, @kdenhartog, @dbluhm, @tomislav and others, please review and propose changes.
Here are my proposals for topics for Friday Agent Meeting:
* The use of a common message specification language - e.g. protobuf
* A two key/one endpoint approach for Identity to Identity (or Domain to Domain) communication
( I'll add this into the Collected Wisdom docs - we can nix this if not needed )
* Where to evolve the Protocol Section - Google Doc or HIPE or Sovrin Protocol Repo
* Messages for establishing connections - pre-assumptions, first contact, pairwise DIDs
@mhailstone, @kdenhartog, @dbluhm, @tomislav and others, please review and propose changes.
@swcurran @kdenhartog @dbluhm @tomislav et. al, here are some other action items in addition to the list above that were captured from the last Friday agent call:
* Discuss URN structure
* Discuss discoverability
* Begin identifying message families
Good ones. I think "message families" and "establishing connections" are similar - a deeper dive into the one connections family. I like touching on the URN structure if people have good suggestions to improve what you have proposed - probably one of the first we should talk about.
On the other hand, I would say that while discoverability down the line will be really important - especially for schema - we can push that to the Indy Team and the Roadmap - what are their plans?
I've added and bookmarked a write up about my thoughts on Domain to Domain communications document: https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#bookmark=id.qcxsl1qpmq5h
Would love to get feedback - feel free to pooh-pooh the idea. It seems useful to me, but may be too limiting
As to whether we discuss it Friday - if it is on the mark then it might be important for the protocol conversation. If it's not right, then we can just skip any discussion.
Thanks!
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=8adx9vES28xkjiybc) @PhillipGibb Can you give a little more information with your error?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=2tPDqBJZmFWt4FjmC) @swcurran It's my understanding that basically all of these topics could/should be proposed as HIPEs. Google Docs are good for formulating a proposals but, for eventually coming to a consensus, HIPEs seem like the best place -- especially as I don't think we've descended into Sovrin specific protocol yet.
@nage feel free to correct me if I'm wrong (or others lol).
@burdettadam it is ok, I have given up trying to build an ubuntu container to run my app that uses indy-sdk, does not seem possible. So I have now started using the Sovrin Test network with way more success
@burdettadam everything builds fine in my local mac evironment but I am unable to connect to the docker indy pool (hence my attempt to run my app in another container that uses the docker network)
@dbluhm - agree that eventually things go into github, but not immediately and not necessarily as HIPEs. First, github discussions are IMHO not a very good way to get "into the ballpark". I'd prefer to have an idea discussed to see if there is merit to a topic before it becomes a HIPE-type document in github. Second, HIPEs are by definition Indy specific, and so some of these topics we are discussing will go into the cross protocol interoperability.
@dbluhm - agree that eventually things go into github, but not immediately and not necessarily as HIPEs. First, github discussions are IMHO not a very good way to get "into the ballpark". I'd prefer to have an idea discussed to see if there is merit to a topic before it becomes a HIPE-type document in github. Second, HIPEs are by definition Indy specific, and so some of these topics we are discussing will go into the cross network interoperability - e.g. the Sovrin Protocol repo.
I'm not sure exactly what you mean by "get in the ballpark" but if you mean community discussion and getting to the point to where a proposal can be made then that makes sense, for sure. If we want to have that kind of discussion using Google Docs, I think that's fine.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=LLkGva6wsZQyc9ho5) @PhillipGibb I ran into something similar on my mac. Have you edited the ip addresses in the dockerfile to 127.0.0.1? That enabled my connection
@mjmckean that is where I started, but I just got timeouts when I tried to open a connection to the pool
@swcurran For instance, we've already reached some level of agreement on the core message structure so moving discussion regarding that out of the Google Docs and started down the pipeline for formal acceptance is absolutely necessary.
@PhillipGibb dm me and let's troubleshoot
@dbluhm - agree that we are there for the core message structure we're getting there and that can go in a HIPE. Same with the URN - there was enough acceptance to move it. But something like what I put in today to the Google Doc - domain-2-domain messaging is definitely not ready for a HIPE.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fWKwPrDJKcdQmR4Qv) @BreizhIndy I'm glad you got it working!
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=foHHLuHRPHzLeF7Yi) @BreizhIndy No, it is an image that has indy-sdk built and the running node.js agent.
Has joined the channel.
Has joined the channel.
@swcurran When is the "Friday Agent Meeting"? And on what channel?
@drummondreed
Today's Indy Agents call:
Agenda:
- The use of a common message specification language - e.g. protobuf
- A two key/one endpoint approach for Identity to Identity (or Domain to Domain) communication
- Where to evolve the Protocol Section - Google Doc or HIPE or Sovrin Protocol Repo
- Messages for establishing connections - pre-assumptions, first contact, pairwise DIDs
- Discuss URN structure
- - Discuss discoverability
Begin identifying message families
Call Details
Topic: Indy Agent Design/Discussion
Time: Jun 29, 2018 9:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
@Sean_Bohan Ah, no wonder I've been missing it—it's a direct conflict with the Evernym management team call every Friday. Drat! I'd really like to start attending these. Anyway, I wish everyone godspeed. and I entrust @TelegramSam to carry the thoughts that @danielhardman and I had been discussing with him on the protocol layer this past week.
Pretty sure these are recorded.
@mhailstone or @saholman We are working at setting up the nodejs indy agent, and running into some initialization problems with the changes in indy-sdk, are you guys aware of what happened?
@nage We are aware of the changes to the Indy-sdk but I don’t believe the node.js wrapper has been updated to support all of the changes. I would be happy to do a zoom chat and take a look at it with you if you’d like!
The easiest way to run the agent really is the docker container. I believe it has Indy-sdk v1.3. If you make any changes to the code and then rebuild the container it will contain your changes. If you just want to run a single instance, then try ‘./manage build’ and ‘./manage start alice’.
Has joined the channel.
The docker container run fails the same way my non-docker one does
not sure what the issue is
@saholman would you ping us here when things are up and running -- was a room full of people here in Amsterdam who would like to play with your toys :innocent:
Yes, please let us know! Can't way to dig a little deeper
@nage Can I get a few more details on the error you are getting?
Also, what version of libindy are you using?
@nage @hvandurme When I build v1.3 (https://github.com/hyperledger/indy-sdk/releases/tag/v1.3.0) of libindy and then run `npm install` and `npm start` in the nodejs directory of the indy-agent repository, everything runs great. Indy-agent does not currently support v1.4 or v1.5 of libindy.
@saholman we all took the latest build I think, so probably v1.5
Most of us were getting this error when running npm start:
> indy-agent@0.0.0 start /Users/hadrienvandurme/Desktop/hhf/indy-agent/nodejs
> node ./bin/www
{ IndyError: CommonInvalidParam4
at Object.callback (/Users/hadrienvandurme/Desktop/hhf/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidParam4',
indyCode: 103,
indyName: 'CommonInvalidParam4' }
Ok, give v1.3 a try. It’s hard to keep up with the Indy-sdk guys 😉, and the wrapper for node.js hasn’t been updated for newer versions yet either. That’s probably what was causing the issues.
Will do and let you know if I run into any issues
@kdenhartog , @swcurran , @mhailstone , @saholman , @TelegramSam
For those who were a part of the call today, your comments on the Core Message Structure HIPE would be greatly appreciated. If we can get everyone on the same page to at least some level, I think it will help facilitate meetings in the future:
https://github.com/hyperledger/indy-hipe/pull/17
@dbluhm - agree. What I struggled with in preparing the desk was how to present what the message would look like vs. transport. I intermingled the two - and sort of had to because of the topic. But in future I'd like a definitive way to present a message in a deck.
For sure. Great work with that presentation today, btw. I think it ended up bringing up a lot of things that needed to be talked about. Looking forward to more discussion.
Separate from that concept -- I'd also like to know the assumptions built into to sending a message. What do I have to know and what is the sequence. That can then become a given when we talk about higher level concepts - the connection process and the attestation flow, etc.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=d1HZPOgzZsKFhhA7lH) @saholman Just noticed that this PR was merged recently: https://github.com/hyperledger/indy-sdk/pull/916
@dbluhm ill go in there and review it's proposal. Id also like to see this go into the Sovrin-foundation/ssi-protocol so that people outside the Indy community who we would like to interoperate, but are planning to build on non-indy ledgers can offer suggestions and feedback as well. Also, @swcurran great job on the presentation. I believe we're aligned on the necessity of this and I like the idea that it's time to start moving forward.
@kdenhartog I'm not familiar with that repo (looks new). Are we favoring using that repo for Sovrin protocol discussion over https://github.com/sovrin-foundation/protocol ? For instance, a defined core message structure seems like appropriate information for https://github.com/sovrin-foundation/protocol/tree/master/janus
That is the proposed idea right now to move move away from the Sovrin brand and bring more people in and be interoperable with us. However, it will incorporate nearly the same information (my first draft is going to be copy-paste) and we'll move forward from there.
The idea is we don't want to say this is the way Sovrin does agent comms, but rather this is how all SSI does agent comms and so I've proposed making it a protocol separate from Sovrin and haven't heard push back on it so far.
@kdenhartog Sounds good, thanks. Also, I'm interested in more details on the Micro-ledger work you mentioned. Is there anywhere I can look for information on that? I've been thinking about off-the-ledger pairwise DIDs for a while and would like to know what's been developing.
Sounds good, I'll go dig up what I can find on this and see what's available.
@dbluhm @saholman - do one of you want to fix my slide deck messaging so that it better matches how we want to present the messages? My intention was to show an Edge-to-Edge Message (Type: Proof Request) and several Agent-to-Agent Messages of Type: Forward.
* How do we show the message content vs. the wire content
@dbluhm @saholman - do one of you want to fix my slide deck messaging so that it better matches how we want to present the messages? My intention was to show an Edge-to-Edge Message (Type: Proof Request) and several Agent-to-Agent Messages of Type: Forward.
* How do we show the message content vs. the wire content
@dbluhm @saholman - do one of you want to fix my slide deck messaging so that it better matches how we want to present the messages? My intention was to show an Edge-to-Edge Message (Type: Proof Request) and several Agent-to-Agent Messages of Type: Forward.
* How do we show the message content vs. the wire content
https://drive.google.com/open?id=1PZuU2Jkkkgveqi432ufW4UVzq_2iO-CzWx7oasFrkLU
@swcurran When you say message content vs. wire content, are you referring to the message content as the content being forwarded and the wire content as the full message that gets transmitted?
I think I might be misunderstanding what you're referring to but once I figure out what you mean, I'd be glad to make those changes
In the call - Matthew was confused about how I laid out the messages - where I had put in the base64, anon-crypt and auth-crypt data. Some of that is implied by the wire protocol - basically the outer base64/anoncrypt (I think). What I'm looking for is to fix the presentation so that it is what "the group" (e.g. you and Spencer :-) wants to see when we communicate about what is in a message. E.g. accurately show the data, but don't show things that are assumed. But formalizing that, it's easier to have future discussions about (for example) exactly how to do a connection sequence of messages.
Does that make sense?
Yeah, thanks for the clarification!
@kdenhartog - I agreed to submit a HIPE, but what was in the presentation was not any requested change to Indy (os it doesn't "improve" Indy), but rather a proposed convention that would be followed by all Agent makers. That sounds like it belongs in the ssi-protocol repo. Agreed?
In my mind yes.
That's off from what I thought/was told. @nage, would you be able to give the official word on protocol discussion and proposals? I dont have any problems using ssi-protocol but just want to make sure im putting things in the right place
@swcurran @kdenhartog @dbluhm I will take a stab at changing the presentation and comment on the HIPE. Sorry I haven't been able to get back to this discussion until now.
@kdenhartog What were the different transport packaging options you were looking into?
Also, a basic credential example that we want to focus our efforts on now is issuing a completed course credential. This is a simple example of what a completed course schema might look like:
```{
course_name,
class_id,
instructors, (this is an array)
grade,
start_date,
completed, (boolean)
completed_date,
competencies, (this is an array)
}```
Multiple problems:
- values that are arrays
- I could return multiple completed courses when fulfilling a proof request
Picnic and Signal are the two right now. I think I want to hold off on changing things for now because AuthCrypt and AnonCrypt are working fine right now for us. I recognize that we'll need to at the very least tweak things (to work with other key types), but we can address that when problems actually come up rather than trying to be too foresighted and slowing us down. For now we'll focus on building around what we got and getting message format standardized.
@kdenhartog Do you have links to those solutions?
picnic: https://github.com/Microsoft/Picnic
signal: https://signal.org/docs/ but someone just pointed me to the noise framework (built from signal protocol and proposed by it's creator) which can be found here http://noiseprotocol.org/
@swcurran i think signal has solved the problem I was discussing earlier today. I need to investigate more, but here's a high level overview https://signal.org/blog/private-groups/
Think of the server as the message forward receiver in context of your proposal you made.
@mhailstone - I think that it's an app protocol issue whether multiple proofs are returned for a proof request - e.g. that it should be handled by the verifier agent.
The general problem of handling an array is a crypto issue as I understand it. I suppose in some cases (and it might work in the case you have), there could be an agreement that "instructors" and "competencies" is a comma separated list or something, but that would be case by case. And it definitely feels like a hack.
@kdenhartog - very cool! - when we were in Salt Lake City we were talking about that as a way to distribute messages - pairwise encrypted symmetrical key. That would definitely work for messaging.
For me - the really tricky part (to me) with multiple devices is with verifiable creds, where there is a different link secret per device. You basically need the cred to be different per device.
@mhailstone one option you could try is a proof request of address 1 the another with address 2 and they all have the same fields
With the Indy-agent repo now online it is appropriate to make a HIPE. I think the idea of the SSI-protocol repo was to work on what would need to go into a set of HIPE proposals. So your call on if it is ready yet or not
The Friday Agent call recording can be found at either of these two places:
https://byu.zoom.us/recording/share/smFh7y9AAwdrBwwsIJQCa1gUPXCIfoX4xCSZVKwtJm2wIumekTziMw
https://drive.google.com/drive/folders/1YqY2mN3BCa4mcvYf3VJd3-dMaqSVPcFe?usp=sharing
Forgive me, my zoom session crashed near the beginning, so the first portion was not saved. Most of the meeting was recorded, though.
@kdenhartog I looked at those links and I would really like to have you present the differences of the protocols and/or the suggestions you have to incorporate one of those protocols as our adopted protocol. From a brief overview reading, I'm leaning towards the Noise Protocol (http://noiseprotocol.org/noise.html).
I am not a cryptographer, though, so this is simply a "looks good" opinion.
A video demo thay some asked about in the Agent meeting at the Hackfest https://vimeo.com/262596133
Thanks @nage !
Good morning from Amsterdam! I was wondering why should we use NONCEs in the indy-agent repository. It requires session management, would it be not easier to use JSON Web tokens where we can send enough information in its payload to match the requests?
@ArthurManz The nonce isn't necessarily used for session data but state information in creating a connection and how to route the request. Very similar to session data, but I would suggest that it's more state logic about the connection that's being created that it isn't session data. I'm open to others' interpretations, though. Just thought I'd give me two cents. :)
Has joined the channel.
Has joined the channel.
which version of indy-sdk is with current indy-agent node.js compatible?
@VitalijReicherdt Give v1.3 a try
@hvandurme hmm, the nodejs wrapper exists only since version 1.5 in indy-sdk
@VitalijReicherdt Yes it hasn't been updated yet.
@hvandurme i can compile/build libindy in version 1.5, but not in version 1.3 or 1.4... i'm on mac
@hvandurme i think, i need only libindy.dylib in version 1.3 for the current indy-agent. On mac i must build this self
ok, after reinstall libsodium I compiled libindy in sdk 1.3 (Tag)
but, i can't build docker image in sdk 1.3
`Step 20/22 : RUN generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 2 3 4 --ips="$pool_ip,$pool_ip,$pool_ip,$pool_ip"
---> Running in e07227852788
Traceback (most recent call last):
File "/usr/local/bin/generate_indy_pool_transactions", line 19, in
``` Step 20/22 : RUN generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 2 3 4 --ips="$pool_ip,$pool_ip,$pool_ip,$pool_ip"
---> Running in e07227852788
Traceback (most recent call last):
File "/usr/local/bin/generate_indy_pool_transactions", line 19, in
also, I build docker image under 1.5 (master) and tried to combine libindy from 1.3 with docker image from 1.5 and indy-agent nodejs from master...
it doesn't work with other error:
`dyld: lazy symbol binding failed: Symbol not found: _indy_list_my_dids_with_meta`
i think, I wait for the next version of nodejs agent or I try to use phyton agent :smiley:
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=pdmhcNdpAu7QcQ8Wf) @VitalijReicherdt, @PhillipGibb has been working with the nodeJS wrapper on Mac and was able to connect his app to indy pool (correct me if I'm wrong Phillip)
I've just tested the nodejs indy-agent with indy-sdk 1.5.0-beta dependency and fresh compiled libindy from master...
```
TRACE|indy::api::wallet | src/api/wallet.rs:176 | indy_create_wallet: >>> pool_name: 0x102886810, name: 0x10284ba10, storage_type: 0x0, config: 0x0, credentials_json: 0x0
TRACE|indy::api::wallet | src/api/wallet.rs:243 | indy_open_wallet: >>> name: 0x102886810, runtime_config: 0x0, credentials_json: 0x0
LOG 2
{ IndyError: CommonInvalidParam4
at Object.callback (/Users/vitalijreicherdt/BlockChain/chainID/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidParam4',
indyCode: 103,
indyName: 'CommonInvalidParam4' }
```
The traces from indy_create_wallet and indy_open_wallet look bad, params are not readable. It looks like corrupted func args mapping or so.
Both indy_create_wallet and indy_open_wallet functions have been changed in in wallet.rs in sdk version 1.5.
But the signatures of these functions are differnt in wallet.rs and indy_wallet.h!
I've just tested the nodejs indy-agent with indy-sdk 1.5.0-beta dependency and fresh compiled libindy from master...
```
TRACE|indy::api::wallet | src/api/wallet.rs:176 | indy_create_wallet: >>> pool_name: 0x102886810, name: 0x10284ba10, storage_type: 0x0, config: 0x0, credentials_json: 0x0
TRACE|indy::api::wallet | src/api/wallet.rs:243 | indy_open_wallet: >>> name: 0x102886810, runtime_config: 0x0, credentials_json: 0x0
LOG 2
{ IndyError: CommonInvalidParam4
at Object.callback (/Users/vitalijreicherdt/BlockChain/chainID/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidParam4',
indyCode: 103,
indyName: 'CommonInvalidParam4' }
```
The traces from indy_create_wallet and indy_open_wallet look bad, params are not readable. It looks like corrupted func args mapping or so.
Both indy_create_wallet and indy_open_wallet functions have been changed in in wallet.rs in sdk version 1.5.
*But the signatures of these functions are differnt in wallet.rs and indy_wallet.h*!
Hi @VitalijReicherdt are you passing credentials to the create and the open wallet?
@PhillipGibb I only tried to start the agent with `npm start`, this error occurs during initialisation of angent
Has joined the channel.
@PhillipGibb you've right, the problem is the new check (since 1.5) of mandatory credentials
@VitalijReicherdt success?
the next/other bug in agent wallet/index.js:
```
exports.setup = async function () {
try {
await sdk.createWallet(config.poolName, config.walletName);
} catch (e) {
if (e.message !== "WalletAlreadyExistsError") {
throw e;
}
} finally {
wallet = await sdk.openWallet(config.walletName);
}
};
```
throw e; does not break and exit from setup function, because finally block catches this exception! And we don't see on console this exception from createWallet!
*my version*:
```
exports.setup = async function () {
try {
await sdk.createWallet(config.poolName, config.walletName);
} catch (e) {
if (e.message !== "WalletAlreadyExistsError") {
console.warn("create wallet failed with message: " + e.message);
throw e;
}
console.info("wallet already exist, try to open wallet");
wallet = await sdk.openWallet(config.walletName);
}
};
```
@PhillipGibb I'm not understand which credentials and where can i take it
ok, i need verification key as first and mandatory param...
@VitalijReicherdt finally will always be called regardless of exception or not.
@VitalijReicherdt
this is how I am creating a wallet, specifically for my steward:
`await indy.createWallet(pool_name, wallet_name, "default", null, credentials)`
with credentials:
`{"key": "whatever"}`
@PhillipGibb correct! and this makes `throw e;` useless
@VitalijReicherdt true
or maybe an if else
wish there was a call to check if the wallet already exists
jones!
Hey guiys, when I send a new connection request it' is automatically accepted and it sends a proof request of the name, is that normal ? ( also i can have relationship with the same DID multiple times)
@PhillipGibb OK, create and open wallet works (from nodejs agent)...
The problem was the change of wallet.json format from 1.x to 1.5.
I have deleted the file `$HOME/.indy_client/wallet/alice_wallet/wallet.json`, because *xtype* is not compatible with WalletDescriptor in 1.5
OLD:
`{"pool_name":"pool1","xtype":"default","name":"alice_wallet"}`
NEW (1.5):
`{"pool_name":"pool1","type":"default","name":"alice_wallet"}`
@PhillipGibb OK, create and open wallet works (from nodejs agent)...
The problem was the change of wallet.json format from 1.x to 1.5.
I have deleted the file `$HOME/.indy_client/wallet/alice_wallet/wallet.json`, because *xtype* is not compatible with WalletDescriptor in 1.5
OLD:
`{"pool_name":"pool1","xtype":"default","name":"alice_wallet"}`
NEW (1.5):
`{"pool_name":"pool1","type":"default","name":"alice_wallet"}`
WalletDescriptor was changed:
```
@PhillipGibb OK, create and open wallet works (from nodejs agent)...
The problem was the change of wallet.json format from 1.x to 1.5.
I have deleted the file `$HOME/.indy_client/wallet/alice_wallet/wallet.json`, because *xtype* is not compatible with WalletDescriptor in 1.5
OLD:
`{"pool_name":"pool1","xtype":"default","name":"alice_wallet"}`
NEW (1.5):
`{"pool_name":"pool1","type":"default","name":"alice_wallet"}`
WalletDescriptor was changed `#[serde(rename = "type")]`:
```
pub struct WalletDescriptor {
pool_name: String,
#[serde(rename = "type")]
xtype: String,
name: String
}
```
My agent runs :stuck_out_tongue_winking_eye:
:clap: :clap: :p
@VitalijReicherdt nice
A reminder that our Indy developer call today has important Agent topics today (it starts in 25 minutes).
The agenda is here https://docs.google.com/presentation/d/1cNaIZz-iBKH9PrKSn3yVgfHXIT881BeRQePgqi_O1VE
https://zoom.us/j/232861185
Has joined the channel.
Draft blog post on Connection and Relationships: putting DID and Verifiable Credential in to a context
https://docs.google.com/document/d/1j_ANJ6hRz9ehDtoeUTCpD4Km79-u5x1g2QDkzLfpdBo/edit?usp=sharing
Note, I don't believe I'll be on the call tomorrow because I'll be on a flight. I will listen to the recording and respond in here.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CRrdECfuBYR8NeLcE) @BreizhIndy Yes that is the expected behavior. In this little demo we've tried to find the balance between making the user do everything and abstracting some of the details away. What do you mean you can have a relationship with the same DID multiple times? The same endpoint did? The pairwise or relationship DIDs should be different for every relationship?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CRrdECfuBYR8NeLcE) @BreizhIndy Yes that is the expected behavior. In this little demo we've tried to find the balance between making the user do everything and abstracting some of the details away. What do you mean you can have a relationship with the same DID multiple times? The same endpoint did? The pairwise or relationship DIDs should be different for every relationship.
@nage @swcurran @danielhardman This is a proposed solution to some of the issues discussed in the call this morning with regards to multiple edge agents. Would you mind taking a look at it and commenting on any issues or concerns you have? https://gist.github.com/saholman/9ad923fd6cc6ddbe1563b168e2536d32.
I've had time to skim it and will read it more deeply shortly. A big assumption that stands out is the sharing of the link secret. I had thought that a link secret needs to be handled like a private key - e.g. not moved, so hadn't thought of that as possible.
What do others think of a link secret that is shared?
If that is permitted from a crypto/security basis, it does make things a LOT easier.
Topic: Indy Agent Design/Discussion
Time: Jul 6, 2018 9:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=4cF3MrPiNBes3Y4xC) @swcurran Stephen, it's a great question. From our work on DKMS, we were torn on whether a link secret needed to be shared or you could a Sovrin wallet work across multiple devices using a derived link secret. @MALodder or @kdenhartog can go deeper on that debate.
Has joined the channel.
at the moment where are stored the content of the wallet( credentials, shemas, proofs) ? Is it in the ledger or locally in our machine ? The credentials should be on the agent side but i'm not sure ...
There is a `sqlite.db` file at `~/.indy_client/wallet/
Did anyone get a chance to copy the chat in the Agent WG Zoom meeting? I was copying the links but then the meeting ended :confused:
https://github.com/sovrin-foundation/protocol search that repo for micro ledger for micro ledger stuff.
Call notes: https://docs.google.com/document/d/1hZVxch9GDffcULsxV4YpCIPDgSA1Ulqm-0aY0p51-OA/edit
https://docs.google.com/document/d/1dFmQ_5NlAIrCYx7AYvvEeYlyvzv-2u3cpQqWTadJbPA/edit another link from the call.
Here is the recording for today's call:
https://drive.google.com/drive/folders/1-IC_79fUaTqBs-uZ9uQK_LeOhudec36F
I've update the core message structure HIPE according to community feedback. Please review the changes and add your comments to the discussion. I hope that at the beginning of this coming week that this HIPE can enter FCP (Final Comment Period) and we can officially move as a community closer to established standards.
https://github.com/hyperledger/indy-hipe/pull/17
The discussion today about the potential for application level authority being assigned from an Identity (e.g. Alice) to Agents is an identical pattern to what we have been considering for Organizations (e.g. companies) delegating authority to their Human Agents - staff, lawyers, accountants, etc. We held a session at IIW about this - http://iiw.idcommons.net/Delegation_of_Authority_for_Organizations_%2B_Services_w/DID%E2%80%99s_%2B_VerfCreds
I think that we should consider using/evolving this same model for delegating authority to Agents. The service (e.g. UBS) provides information on the capabilities that can be used with its service, and the Identity owner can then delegate access to those capabilities to the agents. Ideally, that same delegation mechanism can actual be distributed beyond the Agents controlled by the Identity - per the document above, to delegating to other people (or more specifically, the delegates of other people).
I also feel like raising that kind of delegation above the DID communication level makes sense.
Image from Daniel H. presentation (Jan 2018)
Image from Daniel H. presentation (Jan 2018)
We've created a new HIPE detailing how connection will be established two parties. This HIPE follows the discussion in the Indy-Agent Wisdom Collaboration Google Doc. Please review and leave your comments on this HIPE.
HIPE: https://github.com/ryanwest6/indy-hipe/blob/master/text/connection-protocol/README.md
Discussion: https://github.com/hyperledger/indy-hipe/pull/18
We've created a new HIPE detailing how connections will be established between two parties. This HIPE follows the discussion in the Indy-Agent Wisdom Collaboration Google Doc. Please review and leave your comments on this HIPE.
HIPE: https://github.com/ryanwest6/indy-hipe/blob/master/text/connection-protocol/README.md
Discussion: https://github.com/hyperledger/indy-hipe/pull/18
We've created a new HIPE detailing how connections will be established between two parties. This HIPE follows the discussion in the Indy-Agent Wisdom Collaboration Google Doc. Please review and leave your comments on this HIPE.
HIPE: https://github.com/ryanwest6/indy-hipe/blob/master/text/connection-protocol/README.md
Discussion: https://github.com/hyperledger/indy-hipe/pull/18
Wrap up for my Dummies question above - mostly understood here - https://cran.r-project.org/web/packages/sodium/vignettes/intro.html except for the repudiation/non-repudiation part - which is what was confusing me.
Wrap up for my Dummies question above - mostly understood from here - https://cran.r-project.org/web/packages/sodium/vignettes/intro.html except for the repudiation/non-repudiation part - which is what was confusing me.
We've submitted another HIPE detailing message types based on conversations held in the community. Please review this HIPE and add your comments, even if you don't have much to say.
HIPE: https://github.com/dbluhm/indy-hipe/tree/message-types/text/message-types
Discussion: https://github.com/hyperledger/indy-hipe/pull/19
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZgJtb3ctyPSnayoQ8) @swcurran I had always wondered where the term `authcrypt` had come from — thanks for the link!
Read through the HIPE on establishing a connection - good stuff. I think we need to remove everything about routing from the HIPE. The messages discussed should be just what Alice and Bob's Edge Agents (the ones that are connecting) need to see, and we should assume that the messages magically travel from Alice to Bob. In a separate HIPE we'll talk about the nuts and bolts of how such messages get from the one Agent to another - eg. how Alice's agent wraps the message for routing, etc.
In this HIPE the first message (offer) might have to be a special case of core sending when only one public key is known between the parties, anoncrypt must be used vs. authcrypt for the rest.
I'm looking through the indy-agent repo on the flow of sending proofs and requests for the General-Identity schema. I understand this is just an example. Would be nice to standardize the way parties exchange some information between them during (or right after) the connection establishment process, and General-Identity seems like a good way. Are edge agents assumed to just issue and store credential to themselves for this purpose? Their cred-def won't be on the ledger, but the proof request can be constrained to schemaId only.
Regarding authcrypt and anoncrypt: anoncyrpt is using libsodium's "sealed box" primitive (https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html). The link @swcurran provided is also good. Authcrypt has the same properties as libsodium's public key authenticated encryption (https://download.libsodium.org/doc/public-key_cryptography/authenticated_encryption.html)--including the need for the sender's private signing key--but libindy's implementation uses a combination of sealed box and a signature. As I understand it, anoncrypt is embodied in a sealed box that contains a signed ephemeral (symmetric) key plus anon-encrypted plaintext. The signature proves that the ephemeral key was selected by the sender, and reveals the sender's identity--but only to the possessor of the recipient's public key. Once the overall message has been unsealed, the signature isn't repudiable but the recipient can't prove that said signature was associated with the plaintext message, because that association has now been broken. @gudkov or @sergey.minaev , can you please clarify?
Regarding authcrypt and anoncrypt: anoncyrpt is using libsodium's "sealed box" primitive (https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html). The link @swcurran provided is also good. Authcrypt has the same properties as libsodium's public key authenticated encryption (https://download.libsodium.org/doc/public-key_cryptography/authenticated_encryption.html )--including the need for the sender's private signing key--but libindy's implementation uses a combination of sealed box and a signature. As I understand it, anoncrypt is embodied in a sealed box that contains a signed ephemeral (symmetric) key plus anon-encrypted plaintext. The signature proves that the ephemeral key was selected by the sender, and reveals the sender's identity--but only to the possessor of the recipient's public key. Once the overall message has been unsealed, the signature isn't repudiable but the recipient can't prove that said signature was associated with the plaintext message, because that association has now been broken. @gudkov or @sergey.minaev , can you please clarify?
Regarding authcrypt and anoncrypt: anoncyrpt is using libsodium's "sealed box" primitive (https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html). The link @swcurran provided is also good. Authcrypt has the same properties as libsodium's public key authenticated encryption (https://download.libsodium.org/doc/public-key_cryptography/authenticated_encryption.html )--including the need for the sender's private signing key--but libindy's implementation uses a combination of sealed box and a signature. As I understand it, anoncrypt is embodied in a sealed box that contains a signed ephemeral (symmetric) key plus plaintext symmetrically encrypted with that ephemeral key. The signature proves that the ephemeral key was selected by the sender, and reveals the sender's identity--but only to the possessor of the recipient's public key. Once the overall message has been unsealed, the signature isn't repudiable but the recipient can't prove that said signature was associated with the plaintext message, because that association has now been broken. @gudkov or @sergey.minaev , can you please clarify?
Regarding authcrypt and anoncrypt: anoncyrpt is using libsodium's "sealed box" primitive (https://download.libsodium.org/doc/public-key_cryptography/sealed_boxes.html). The link @swcurran provided is also good. Authcrypt has the same properties as libsodium's public key authenticated encryption (https://download.libsodium.org/doc/public-key_cryptography/authenticated_encryption.html )--including the need for the sender's private signing key--but as I understand it, libindy's implementation uses a combination of sealed box and a signature. If I am correct, anoncrypt is embodied in a sealed box that contains a signed ephemeral (symmetric) key plus plaintext symmetrically encrypted with that ephemeral key. The signature proves that the ephemeral key was selected by the sender, and reveals the sender's identity--but only to someone who can open the sealed box. That would be the possessor of the recipient's public key. Once the overall message has been unsealed, the signature isn't repudiable but the recipient can't prove that said signature was associated with the plaintext message, because that association has now been broken. @gudkov or @sergey.minaev , can you please clarify?
BTW, if anybody is wondering about this "repudiability" thing, please read https://github.com/sovrin-foundation/protocol/blob/master/janus/repudiation.md
@TelegramSam ^^
@kdenhartog
@kdenhartog ^^
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=JfGa5GxbuqcTiBndM) @danielhardman authcrypt contains libsodium's crypto box and sender verkey wrapped with seal box. There is no explicit signature and proof of origin is based on checking of Diffie Hellman result from sender verkey and recipient private key. As result it is impossible to proof origin to 3d party without disclosing of recipient private key.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=T5LGWdgFfNekRbFrQ) @tomislav Under the covers right now, we have the "Government" issuing them an ID of some kind when the agent is starting up for the first time that all "General-Identity" proof requests are fulfilled with. While something like this would be optimal, that first ID could be provided by a university or perhaps the agency itself when a new agent is added. I think it makes sense to build up a known list of credential definitions that are trusted forms of identification rather then having it based on a self-attested attribute or self-issued credential.
Has joined the channel.
Hi, I followed the indy agent nodejs quick start guide, found here, https://github.com/hyperledger/indy-agent/blob/master/nodejs/quick-start-guide.md
and I now have the indy agent up and running. When i submit a query for a proof of request I receive the following error.
TypeError: Cannot read property 'cred_info' of undefined
alice_1 | at Object.exports.prepareRequest (/home/indy/nodejs/indy/src/proofs/index.js:83:64)
alice_1 | at
@gudkov Thank you for providing more detail, but I still need you to clarify your sentence. One way to understand it would be: "authcrypt consists of libsodium's crypto box around the main message, followed by the sender verkey wrapped in a sealed box". Another way to understand it would be: "authcrypt is a single sealed box, inside of which there is a crypto box around the main message followed by the sender verkey outside the crypto box". I am guessing you mean the second interpretation. Am I right?
@gudkov Thank you for providing more detail, but I still need you to clarify your sentence. One way to understand it would be: "authcrypt consists of libsodium's crypto box around the main message, followed by the sender verkey wrapped in a sealed box" -- cryptobox(main message) + sealedbox(sender verkey). Another way to understand it would be: "authcrypt is a single sealed box, inside of which there is a crypto box around the main message followed by the sender verkey outside the crypto box" -- sealedbox(cryptobox(main message) + sender verkey). I am guessing you mean the second interpretation. Am I right?
@gudkov Thank you for providing more detail, but I still need you to clarify your sentence. One way to understand it would be: "authcrypt consists of libsodium's crypto box around the main message, followed by the sender verkey wrapped in a sealed box" -- cryptobox(main message) + sealedbox(sender verkey). Another way to understand it would be: "authcrypt is a single sealed box, inside of which there is a crypto box around the main message followed by the sender verkey outside the crypto box" -- sealedbox(cryptobox(main message) + sender verkey). I am guessing you intend the second interpretation. Am I right?
@swcurran I think we'll definitely have a need for a general transport HIPE but I'm also wondering if we need to treat the connection process with its own transport HIPE detailing some of the grittier parts of bootstrapping connections. What do you (and others) think?
I agree that the first message (at least) of the connection message might be a bit special because only one DID is known, but I'm thinking after that, there should be enough info. From the second message on, both sides know the pairwise DIDs that will be used.
Within a domain, the transport level messaging may have to share other information about DID-to-Agent routing. I'm claiming that such information will be part of the transport discussions between Agencies within a Domain.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=YM7nt3ab2hTxtPC7J) @ghouston10 What version of libindy are you using? The most recent build?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=T5LGWdgFfNekRbFrQ) @tomislav @tomislav I think it really depends upon the purpose of establishing a connection. For some business domains, they may want certain data known to the domain to be asserted and they may not care about general identity. For example (and forgive me, but it may not be absolutely correct), if a bank wanted to just know that another institution was a recognized bank, then maybe the first proof request they would perform would be on receiving a proof of the other institution's ABA routing number. Once they had that proof of a number, then they could do certain business actions with the connection. I think @jljordan_bcgov mentions this a establishing a "relationship" on top of a "connection". I don't disagree that general identity proof requests would be generally useful for human to human connections, but I want to emphasize that we shouldn't automate that into the connection process but rather let the business process dictate what proof requests are useful inside their own domain.
@dbluhm @swcurran I think that whether a general purpose transport HIPE fits for creating connections depends on the definition and approach to the general purpose transport. Currently, the simple anon-encrypted/base64 approach works for both scenarios, but a new more sophisticated approach may not fit both scenarios in order to address inherent routing and forward secrecy.
@dbluhm @swcurran I think that whether a general purpose transport HIPE fits for creating connections depends on the definition and approach to the general purpose transport. Currently, the simple anon-encrypted/base64 approach works for both scenarios, but a new more sophisticated approach may not fit both scenarios in order to address concerns like inherent routing and forward secrecy.
I'm having fun trying to come up with the transport HIPE. It will need adjustments and evolution before it can be used, I'm sure, but I think it will make things a lot easier in the long run.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wrNxX6QPd5DkRixrz) @danielhardman Yes, it is second one: sealedbox(cryptobox(main message) + sender verkey + nonce)
@saholman I beleive so. I just followed the steps on this page to build libindy.
https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ` INFO|indy::services::ledger | src/services/ledger/mod.rs:433 | parse_get_schema_response >>> get_schema_response: "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GET / - - ms - -`; what can we do here?
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ` INFO|indy::services::ledger | src/services/ledger/mod.rs:433 | parse_get_schema_response >>> get_schema_response: "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2) is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GET / - - ms - -`; what can we do here?
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ` INFO|indy::services::ledger | src/services/ledger/mod.rs:433 | parse_get_schema_response >>> get_schema_response: "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and set_protocol_version(2) is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GET / - - ms - -`; what can we do here?
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ` INFO|indy::services::ledger | src/services/ledger/mod.rs:433 | parse_get_schema_response >>> get_schema_response: "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GET / - - ms - -`what can we do here
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ` INFO|indy::services::ledger | src/services/ledger/mod.rs:433 | parse_get_schema_response >>> get_schema_response: "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and set_protocol_version(2) is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)\",\"reqId\":1531212863077992000,\"identifier\":\"URjFG3bZjyhNhd2oejr3T1\",\"op\":\"REQNACK\"}"
ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
GET / - - ms - -`what can we do here
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ```ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.```
what can we do her
we are currently trying to start the nodejs indy-agent and get a protocol version error from plenum: ```ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Transaction has been failed: "client request invalid: InvalidClientRequest(\'validation error [SafeRequest]: Message version (1) differs from current protocol version. Make sure that the latest LibIndy is used and `set_protocol_version(2)` is called (protocolVersion=1)\',)"
TRACE|indy::api::ledger | src/api/ledger.rs:656 | indy_parse_get_schema_response: schema_id: "", schema_json: ""
(node:50767) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction
at Object.callback (/Users/tkdp/Development/ChainID/Project/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
(node:50767) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:50767) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.```
what can we do here?
Has joined the channel.
Hello - what is the best channel for evernym vcx discussion?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=MTatFh9pQBT5GQxeT) @ThomasKrech You can call indy_set_protocol_version(2) to switch to second version of Node protocol. See https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.4.0-1.5.0.md#pool-api for information
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=EGXiXAPnCfrWxRkB4) @gudkov hi, ok thanks; I'm new to indy-sovrin and I'm currently do not know where to invoke this function
Hello, I'm trying to install vcx (I'm assuming ubuntu 16.04 support). On
```
$ cargo build
```
I get:
```
= note: /usr/bin/ld: cannot find -lnullpay
collect2: error: ld returned 1 exit status
error: aborting due to previous error
error: Could not compile `libvcx`.
```
Has anybody got this? It appears that libnullpay source, or build instructions may not have made it into the repo?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=89sFHQ6XB3qFngz9M) @gudkov Is there a writeup of this somewhere the explains the details?
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=pfEfQi4n43wobSpg2) @TelegramSam The only real difference between anoncrypt and authcrypt is the key that is used for signing and to encrypt. Anoncrypt uses an ephemeral key pair with the recipients public key to compute the encryption key to encrypt and sign the data. Authcrypt uses the senders key pair instead of the ephemeral key pair. Both use an Ed25519 private key to sign. Anoncrypt hides the sender.
is it possible to more than one user in a single port ? like- alice and bob in a single port 3000. please help...
is it possible to run more than one user in a single port ? like- alice and bob in a single port 3000. please help...
@TelegramSam - is the comment from vimmerru on this page what you are looking for? https://github.com/hyperledger/indy-hipe/pull/9
I found it really interesting.
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wkzoJHgX3cZuMt7vC) @AvikHazra Not with the current implementation. That idea is the concept of an agency and would need parsing and routing of the message of the running service to the different wallets/agents.
Does anyone know the format of the result of `indy_build_get_ddo_request` is? Is it supposed to return a DDO of all attributes set for a certain DID formatted based on the ddo spec? Currently, it errors out on the ledger and there are no unit tests or any usage of this. Perhaps feature coming in soon?
Might be a indy-node question...
Has joined the channel.
Has joined the channel.
Hi, I am following the indy agent nodejs quick start guide, found here, https://github.com/hyperledger/indy-agent/blob/master/nodejs/quick-start-guide.md
When I run ./manage cli within the von network I recieve the following error:
libpbc.so.1: cannot open shared object file: No such file or directory
I do not know specifics on the nodejs agent, but from this error I suspect that you do not have a PBC library installed -- or it is not on your `LD_LIBRARY_PATH`
I do not know specifics on the nodejs agent, but from this error I suspect that you do not have PBC library installed -- or it is not on your `LD_LIBRARY_PATH`
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=hnhLwW2XXQru6R5yh) @ghouston10 I do not know specifics on the nodejs agent, but from this error I suspect that you do not have PBC library installed -- or it is not on your `LD_LIBRARY_PATH`
@n3m thanks.
Also, is there a description anywhere as to what exactly indy agent is?
Standardization regarding the agents is currently in the works, and I believe there are no low level technical documents explaining every nut and bolt.
From a high level overview this documents paints a picture of the Sovrin ecosystem and explains the role of Agents: https://sovrin.org/wp-content/uploads/2018/03/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf. There is also a bit more detailed explanation here: https://github.com/sovrin-foundation/protocol
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RX9rx7TzFtSfqLb9B) @ghouston10 Standardization regarding the agents is currently in the works, and I believe there are no low level technical documents explaining every nut and bolt.
From a high level overview this documents paints a picture of the Sovrin ecosystem and explains the role of Agents: https://sovrin.org/wp-content/uploads/2018/03/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf. There is also a bit more detailed explanation here: https://github.com/sovrin-foundation/protocol
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DcvpH6AoxwjRTXyem) @ghouston10 Standardization regarding the agents is currently in the works, and I believe there are no low level technical documents explaining every nut and bolt.
From a high level overview this documents paints a picture of the Sovrin ecosystem and explains the role of Agents: https://sovrin.org/wp-content/uploads/2018/03/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf. There is also a bit more detailed explanation here: https://github.com/sovrin-foundation/protocol
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uoSPHJKCo6s3hwooy) @ghouston10 Try using libindy v1.3 https://github.com/hyperledger/indy-sdk/releases/tag/v1.3.0
@ghouston10 I will update the README.md to help you and others avoid these issues in the future.
@ghouston10 I will update the README to help you and others avoid these issues in the future.
libpbc.so.1: cannot open shared object file: No such file or directory
Having this error for several days now and I cant get it resolved.
Can anyone please help with me this error. I have been stuck at the same point for the last few days and have made zero progress. I am following what seems to be very basic instructions from this link
https://github.com/bcgov/von-network#running-the-network-locally
I install docker and clone the von-network. I run ./manage build and ./manage start ,to start up the standard 4-node Hyperledger Indy network which executes successfully. I then open up a new terminal and run ./manage cli withinin the von-network directory and I receive the following error:
libpbc.so.1: cannot open shared object file: No such file or directory
Is there anything that I need to install/run before I start following the instructions on this guide. It doesn't state that anything is required so I have no idea what is causing the error or how it can be resolved.
Any help would be much appreciated.
@n3m I do have the PBC library installed and in my LD_LIBRARY_PATH
We will be conducting a 2 day workshop to work on the Indy Agent protocol/specification and interoperable implementations July 30 - 31. We will start 8:00 AM (MDT each day and end at 5:00 PM (MDT) each day with a 1 hour break at 12:00 PM (MDT). We will mainly be participating through a virtual zoom meeting. BYU will be hosting a location in Utah for those who would like to participate face-to-face. Contact Matthew Hailstone (matthew_hailstone@byu.edu) for details if you are interested in attending the face-to-face gathering in Utah. All participants should be up to speed on the Agent discussions and on the Agent Protocol related HIPEs. Please plan to attend at any portion of the workshop during those two days to participate/contribute to the discussions.
Here are the zoom meeting details for each day:
--------------------------------------------
Topic: Hyperledger Indy Agent Workshop
Time: Jul 30, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
--------------------------------------------
Topic: Hyperledger Indy Agent Workshop
Time: Jul 31, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
https://github.com/sovrin-foundation/ssi-protocol/pull/2
Here's a loose outline for JWMs. I suspect there will be lots of questions that I am ready to discuss to improve this. Also, I chose to place this in the SSI-protocol repo instead of a HIPE so that we could get active discussion from the larger community such as uPort and DIF folks.
https://github.com/hyperledger/indy-hipe/pull/21
Hey folks, attached is a HIPE about Transport Layer Messaging that I promised to take a shot at. This is likely far too simple to be complete and I offer it mainly to get the conversation going. As noted in the pull request - pictures are desperately needed and I hope to get to that soon, but I have some other work to do.
The assumptions are "interesting". I think they are reasonable, but they still leave much up to an implementation.
I did not look at what @kdenhartog posted a short time ago and so don't know if that affects this.
@swcurran Daniel mentioned you were working on this and I forgot to reach out after he told me. Ill take a deeper look at it tomorrow. At first glance, we're looking to accomplish similar things and have common ideas. Yours definitely goes deeper into design philosophy so ill likely be copying most of that info in. Great job! We're moving quickly on this stuff.
Has joined the channel.
hello,
hello sir, is there any way to create normal user like alice or bob dynamically in indy-agent ?
hello, is there any way to create normal user like alice or bob dynamically in indy-agent ?
Has joined the channel.
@swcurran, some points of feedback on the transport HIPE.
1. I don't buy the strong form of the Sender Anonymity or Receiver Anonymity requirement. I'm not sure how these got entrenched in our thinking, because I agree with you that the community seems to have begun articulating these as fundamental--but I think we've gone a bit too far. If you think about sovereign nations in the non-digital world, and about heads of state communicating with one another, it is certainly true that one head of state need not know all the people and processes used by another head of state when delivering a message at the other kingdom's borders. But I think *some* knowledge may be reasonable (e.g., "I can give this to the postmaster and ask it to be couried directly to the palace without passing through the hands of the ambassador. It is for the king's eyes only." Such a statement implies a little knowledge about the internals of the other monarch's kingdom). Similarly, I think it is reasonable for one sovereign identity owner to know a little bit about the internals of another sovereign domain--enough to know which keys are considered closely held by the identity owner (at the edge) versus loosely held (in the cloud). The microledger spec further imagines that identity owners would tell one another what permissions are ascribed to each key that they intend to use in the relationship, so they can cooperate to enforce access. If Monarch A gets a letter purporting to represent the wishes of Monarch B, but it is only signed by Monarch B's postmaster, Monarch A needs to know whether B wishes the postmaster to be taken seriously....
The "Transport DID (TDID)" section lost me a bit. Are you intending to say that there is a DID and a key at which mail will be delivered for a sovereign domain, and that this DID+key is conceptually distinct from the other keys associated with the domain? In other words, that you may deliver to an endpoint which is serviced by a DID and key that are not in and of themselves "members" of the sovereign domain? (If so, then I am feeling fine about it.)
Why are we introducing DIDs instead of the lower level construct of keys as the operational input needed for wire messages? This would require every agent within a domain to have a DID. Instead, can we say that wire messages are sent to and from *keys*, not assuming that DIDs are necessarily involved? In a similar vein, do we always have to provide a DID as the target for a "forward" message, or could we just provide a key? (I have been assuming that agents within a sovereign domain have a locally unique name, but not a DID. There are some deep reasons for this that we could discuss in a separate conversation.)
We have to assume that message responses are asynchronous; to do otherwise eliminates many transport protocols. However, we could define a "synchronous mode" that would be supported by transports that allow it, whereby the deliverer of the message awaits a response and transmits it back immediately (e.g., without closing the port first). This would be great for http and would not be hard to build, probably.
"The choice of whether to use anoncrypt or authcrypt is based on the state of the known DIDs" -- I think this is only partly true. Even if it is possible to authcrypt, it must be a choice to anoncrypt instead. This allows Alice to send Bob anonymous love letters even if Alice and Bob know each other from work. (Whether Bob's agents are programmed to accept anonymous letters is another question.)
Your paragraph that begins "ASIDE: this is where": There is only one endpoint for a pairwise DID--the endpoint where mail can be delivered. I *think* that's what you're calling a TDID (though I don't understand why "DID" is in its name or its definition; I was thinking of it as an endpoint with a key, not an endpoint with a DID...). Anyway, It appears that you're imagining another DID and another endpoint here, which raised my eyebrows. So this is something I want to learn more about.
Application Level Error Handling: I think it may be desirable to provide a "reply-to" property with a message, that would allow errors to be reported. The problem is that, done wrong, this is a way to spam an unsuspecting third party with error messages. So we need to think about that. How do we detect transmission errors in physical post? We usually don't, unless we use a "return receipt requested" feature of some kind...
@swcurran, some points of feedback on the transport HIPE.
I don't buy the strong form of the Sender Anonymity or Receiver Anonymity requirement. I'm not sure how these got entrenched in our thinking, because I agree with you that the community seems to have begun articulating these as fundamental--but I think we've gone a bit too far. If you think about sovereign nations in the non-digital world, and about heads of state communicating with one another, it is certainly true that one head of state need not know all the people and processes used by another head of state when dropping off a message at the other kingdom's borders. But I think *some* knowledge may be reasonable (e.g., "I can give this to the postmaster and ask it to be couriered directly to the palace without passing through the hands of the ambassador. It is for the king's eyes only." Such a statement implies a little knowledge about the internals of the other monarch's kingdom). Similarly, I think it is reasonable for one sovereign identity owner to know a little bit about the internals of another sovereign domain--enough to know which keys are considered closely held by the identity owner (at the edge) versus loosely held (in the cloud). The microledger spec further imagines that identity owners would tell one another what permissions are ascribed to each key that they intend to use in the relationship, so they can cooperate to enforce access. If Monarch A gets a letter purporting to represent the wishes of Monarch B, but it is only signed by Monarch B's postmaster, Monarch A needs to know whether B wishes the postmaster to be taken seriously....
The "Transport DID (TDID)" section lost me a bit. Are you intending to say that there is a DID and a key at which mail will be delivered for a sovereign domain, and that this DID+key is conceptually distinct from the other keys associated with the domain? In other words, that you may deliver to an endpoint which is serviced by a DID and key that are not in and of themselves "members" of the sovereign domain? (If so, then I am feeling fine about it.)
Why are we introducing DIDs instead of the lower level construct of keys as the operational input needed for wire messages? This would require every agent within a domain to have a DID. Instead, can we say that wire messages are sent to and from *keys*, not assuming that DIDs are necessarily involved? In a similar vein, do we always have to provide a DID as the target for a "forward" message, or could we just provide a key? (I have been assuming that agents within a sovereign domain have a locally unique name, but not a DID. There are some deep reasons for this that we could discuss in a separate conversation.)
We have to assume that message responses are asynchronous; to do otherwise eliminates many transport protocols. However, we could define a "synchronous mode" that would be supported by transports that allow it, whereby the deliverer of the message awaits a response and transmits it back immediately (e.g., without closing the port first). This would be great for http and would not be hard to build, probably.
"The choice of whether to use anoncrypt or authcrypt is based on the state of the known DIDs" -- I think this is only partly true. Even if it is possible to authcrypt, it must be a choice to anoncrypt instead. This allows Alice to send Bob anonymous love letters even if Alice and Bob know each other from work. (Whether Bob's agents are programmed to accept anonymous letters is another question.)
Your paragraph that begins "ASIDE: this is where": There is only one endpoint for a pairwise DID--the endpoint where mail can be delivered. I *think* that's what you're calling a TDID (though I don't understand why "DID" is in its name or its definition; I was thinking of it as an endpoint with a key, not an endpoint with a DID...). Anyway, It appears that you're imagining another DID and another endpoint here, which raised my eyebrows. So this is something I want to learn more about.
Application Level Error Handling: I think it may be desirable to provide a "reply-to" property with a message, that would allow errors to be reported. The problem is that, done wrong, this is a way to spam an unsuspecting third party with error messages. So we need to think about that. How do we detect transmission errors in physical post? We usually don't, unless we use a "return receipt requested" feature of some kind...
Indy HIPE Status Notes
1. The HIPE on credential revocation has finished its Final Comment Period and been accepted unanimously by Indy maintainers. It was merged and is now known as Indy HIPE 0011. You can view it at https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation.
2. Per a decision of Indy maintainers on Monday, July 9, the HIPE on concurrency improvements in Indy is now entering its Final Comment Period. We believe it is ready to be accepted.
You can view the PR for this HIPE at https://github.com/hyperledger/indy-hipe/pull/16.
The HIPE will be accepted and merged on Monday, July 23 unless there is significant latebreaking dissonance from community members.
Feedback on @ryanwest6 's connection protocol HIPE:
1. Offer and Request, then Response are part of a more generic pattern (I have been calling it a "flow") that can be used for any negotiation. It is not unique to connections, and I think we should reference the more generic pattern rather than treating it as special to connections. See https://github.com/sovrin-foundation/ssi-protocol/tree/master/flow/std/negotiate_msg. Note that there could be multiple rounds of offer->request or request->offer before the request and the offer are aligned and both parties accept. The point of negotiation in a connection might be the terms of the connection, or might involve some type of low-trust claim about who the parties are so they can recognize each other. Think about how LinkedIn Connection Requests work ("Hey, this is Terry. We met at the conference the other day. Let's connect." --> "Hey, Terry, this is Jim. You're not going to spam me with recruitment offers, are you?" --> "Naw. I just want to stay in touch." --> OK)
2. Either the Offer or the request can be out of band. Or both can. It is not until a connection response that the offer must move in band.
3. I think a connection offer and a connection request need a place for a freeform introductory message from one human to another.
4. We are missing the idea of topicalization and message thread sequencing as described
here: https://github.com/sovrin-foundation/protocol/blob/master/janus/message-packaging.md#topical-messages. This does not need to be in the Application-Level connection messages, but should be moved outside. I think the id of a message is redundant with this idea.
5. I see mentions of the public ledger. This must work for microledgers and private DIDs, too--not just agains the public ledger.
6. Why is the verkey attribute in a connection request not the same as the verification cay used to encrypt messages in transport? I would think that it should be.
7. I think there's a confusion about authcrypt and anoncrypt here. All messages delivered to a DID are packaged with a "forward" message and anon-encrypted when handed to the endpoint for that DID. That endpoint anon-decrypts and examines the resulting "forward" message to decide where to route it. The message is then routed to the agent(s) who own the DID, who may either anon- or auth-decrypt it (depending on whether the sender wanted to be identified; for connection responses, it should always be auth-crypted, probably). The result of this second decryption is finally an Application-level message like a Connection Request. We don't wait until after the connection is established to begin using this; we do it as soon as we have a DID to send to.
8. I question the value of the acknowledgments. We are talking about a disconnected, asynchronous protocol, where any message might be lost in delivery. Once both parties know that the other party has provided a DID and verkey, and that they have, they know that there's a two-way intent to be connected. Whether that connection is actually broken or working is not a concern unique to the connection protocol--it's a general concern of the channel no matter what messages get exchanged. And acknowledgments only partly address the need, because the minute after we deliver a message saying a connection is open, one side could change its mind and stop connecting. Thus, the acknowledgement doesn't really say, "I acknowledge that the connection is open when you receive it," but rather "At the time I sent this, I considered the connection open." But that would be true of *any* message sent by the other party; it's not uniquely conveyed by an acknowledgment.
Alice knows that Bob has provided a DID+verkey+url, and that she has, as soon as she sends her auth-encrypted connection response. Bob knows that Alice has provided the ingredients of a connection, and that he has, as soon as he receives her response. No additional info is learned after that.
You could say, "Well, Bob's acknowledgment lets Alice learn that Bob received her response." Fine. But so would any other message that Bob ever sends her. And if she doesn't receive this acknowledgment, she still knows that Bob intends to talk, since he's already sent her his DID. If talking isn't working at the moment, it's not a matter of intent, but a matter of a failed transmission mechanism. And guess what--the failed transmission mechanism will stymie the acknowledgement...
@swcurran @danielhardman I think a better word for Anonymity is Encapsulation.
I agree @TelegramSam - it's not that we want anonymity, its that we want to allow an agent to encapsulate it's implementation, revealing only what's necessary. The more it reveals, the more other parties have to understand the conventions it is using. As with any interface, to achieve relatively arbitrary interoperability we want to be very careful in what conventions we declare as expected as if an specific implementation goes too far - it won't interoperate with anyone.
I've advocated it reveal the minimum from a transport perspective (endpoint, transport key), but could be talked up to including more.
Has joined the channel.
TOMORROW! 7/13/2018: Indy Agent WG Call
“representation of the message through the transport”
- AgentToAgent transport HIPE
- Core Message Structure HIPE
- Message Types HIPE
- Connection Protocol HIPE
- Indy Agent Design/Discussion
Time: Jul 13, 2018 7am PT, 8amMT, 10amET, 3pm BST
(US and Canada) https://byu.zoom.us/j/2627891784
@danielhardman Thanks for all the detailed feedback on the HIPEs. Would you mind reposting your comments in the HIPE Pull Request conversations so we can have all HIPE comments organized in one place for further discussion?
Now that `libindy` API is heavily re-factored, is it possible to update reference agents in the `indy-agent` repo to reflect those changes, or at least to put info about the currently supported version of `libindy` in the README. I know people are trying to play around with the agent implementations and are facing issues because they are using Indy SDK master branch.
@danielhardman I'm a little confused at the purpose of a DID from your comments and recent discussion about DID and keys. I have been under the impression for a very long time that DIDs are the primary identifiers for identity holders and represent connections/relationships. The keys associated with the DIDs are used for encryption/decryption and signing/verification. It seems now that we are advocating keys as the primary "identifiers" for identifying the entity from whom or to whom the message is sent. Could you help me understand when DIDs are to be used on their purpose and when keys are to be used and their purpose? This distinction is crucial I think in correctly creating a transport layer structure protocol as well as a core message protocol.
@danielhardman I'm a little confused at the purpose of a DID from your comments and recent discussion about DIDs and keys. I have been under the impression that DIDs are the primary identifiers for identity holders and represent connections/relationships. The keys associated with the DIDs are used for encryption/decryption and signing/verification. It seems now that we are advocating keys as the primary "identifiers" for identifying the entity from whom or to whom the message is sent. Could you help me understand when DIDs are to be used and their purpose and when keys are to be used and their purpose? This distinction is crucial I think in correctly creating a transport layer structure protocol as well as a core message protocol.
@mhailstone In my view, a DID is an identifier for an actual or potential relationship between sovereign domains. One DID per relationship. Multiple entities may participate in a pairwise relationship -- various agents on either side, for example. The participating entities need to be uniquely identified so they can receive delegated authority that can be revoked as needed, and so they can be held accountable. They don't do this with DIDs; they do this with keys. Thus, keys are a delegation-of-authority mechanism, not an identification-of-relationship mechanism. What I've been hearing from others recently feels to me like it is conflating two very different dimensions of identity -- relationships vs. delegation -- and trying to use DIDs for both. Please see the first 9 slides of this preso, where relationships and DIDs are the blue axis and agents and delegated keys are the red axis: https://docs.google.com/presentation/d/1B6XPzEeVaZFHv14y6JZ0f7Hdj0jnvTM99-9D-7Vbj4g/edit. To give DIDs to agents is to confuse the delegation and relationship axes. Relationships are established through a connection protocol such as the one in @ryanwest6 's excellent HIPE. That's how and where DIDs get created. Delegation is a unilateral thing that doesn't require this dance, and it's governed by keys. If we give DIDs to agents, then are we also going to do a connection protocol for between the various agents in the sovereign domain, and maintain a relationship state machine for every agent-to-agent relationship? And rotate keys via ledger txns?
The view has been asserted that identity owners should have no visibility into the domain of an other. I get the desire to encapsulate, but I think it's unrealistic to provide total opacity. As long as the phenomenon of proxying and delegation exists, another party must be told what the role of certain proxies might be. This conveyance of delegation config between two sovereign domains need not be very detailed--England and France don't have to tell each other the names and assignments of everybody in their respective diplomatic corps--but they do have to introduce one another to their respective ambassadors and prime ministers, and clarify what the responsibilities and authorities of those officials might be. Similarly, if one party in a relationship is a corporation has thousands of agents working on its behalf, and the other party is John Q. Public, there is no need for the corporation to exhaustively enumerate all its agents and keys to John. But it is reasonable for the corporation to tell John about the keys that will help him recognize two or three of the corporation's delegates that are relevant to their interaction.
@mhailstone In my view, a DID is an identifier for an actual or potential relationship between sovereign domains. One DID per relationship. Multiple entities may participate in a pairwise relationship -- various agents on either side, for example. The participating entities need to be uniquely identified so they can receive delegated authority that can be revoked as needed, and so they can be held accountable. They don't do this with DIDs; they do this with keys. Thus, keys are a delegation-of-authority mechanism, not an identification-of-relationship mechanism. What I've been hearing from others recently feels to me like it is conflating two very different dimensions of identity -- relationships vs. delegation -- and trying to use DIDs for both. Please see the first 9 slides of this preso, where relationships and DIDs are the blue axis and agents and delegated keys are the red axis: https://docs.google.com/presentation/d/1B6XPzEeVaZFHv14y6JZ0f7Hdj0jnvTM99-9D-7Vbj4g/edit. To give DIDs to agents is to confuse the delegation and relationship axes. Relationships are established through a connection protocol such as the one in @ryanwest6 's excellent HIPE. That's how and where DIDs get created. Delegation is a unilateral thing that doesn't require this dance, and it's governed by keys. If we give DIDs to agents, then are we also going to do a connection protocol for between the various agents in the sovereign domain, and maintain a relationship state machine for every agent-to-agent relationship? And rotate keys for each agent via ledger txns?
The view has been asserted that identity owners should have no visibility into the domain of an other. I get the desire to encapsulate, but I think it's unrealistic to provide total opacity. As long as the phenomenon of proxying and delegation exists, another party must be told what the role of certain proxies might be. This conveyance of delegation config between two sovereign domains need not be very detailed--England and France don't have to tell each other the names and assignments of everybody in their respective diplomatic corps--but they do have to introduce one another to their respective ambassadors and prime ministers, and clarify what the responsibilities and authorities of those officials might be. Similarly, if one party in a relationship is a corporation that has thousands of agents working on its behalf, and the other party is John Q. Public, there is no need for the corporation to exhaustively enumerate all its agents and keys to John. But it is reasonable for the corporation to tell John about the keys that will help him authenticate two or three of the corporation's delegates that are relevant to their interaction.
Has joined the channel.
@n3m i've just created 2 pull requests to upgrade agent
https://github.com/hyperledger/indy-agent/pulls
@VitalijReicherdt will these changes be commited to github
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=7ci7Qv5cinewNSAz4) @ghouston10 These changes are in github commited as pull request. I hope the PR will be approved and merged into master
approver are typically @mhailstone, @saholman, @dbluhm
approver are typically @mhailstone, @saholman, @dbluhm
Within the indy agent, when you create a credential definition, a post request is sent to /api/issuer/create_schema
Where is this code located and how can I access it, so I can understand what is actually executing.
Feedback on @dbluhm 's hipe about message type:
I think we need to distinguish between the need to describe the type of a message in two different contexts:
describe the type from within the message
describe the type from outside the message
The type that's visible inside a message is guaranteed to be there even if we divorce the message from its transport or context and save just the raw bytes of the message to disk. It is important to have this, so that messages can be self-contained. This is why JPEG files have an internal header that identifies them as JPEGs, PDF files have an internal header that identifies them as PDFs, and so forth.
However, a type declared internally is of no use to something that sees a message payload only as an encrypted blob of bytes. So we also need to declare type in a way that's external to the message itself, such that things that are processing the message (or routing it to other things to process) have the option of learning something about what they are handling.
The current proposal feels to me like it conflates these two concerns, placing a type declaration outside the message content but inside some other container that must unify the two.
The original A2A design called for a type declaration to be a message type of its own. You could take any other message and make it a payload of a type message. This is very close to what this proposal recommends, except that in the original view, the thing you were looking about when you were done wasn't a message of arbitrary type but guaranteed to have type as a field--but rather a "type" message that had another message as its payload. If we could think about it that way, I think we'd be better off.
Feedback on @dbluhm 's hipe about message type ("Core Message Structure"):
I think we need to distinguish between the need to describe the type of a message in two different contexts:
describe the type from within the message
describe the type from outside the message
The type that's visible inside a message is guaranteed to be there even if we divorce the message from its transport or context and save just the raw bytes of the message to disk. It is important to have this, so that messages can be self-contained. This is why JPEG files have an internal header that identifies them as JPEGs, PDF files have an internal header that identifies them as PDFs, and so forth.
However, a type declared internally is of no use to something that sees a message payload only as an encrypted blob of bytes. So we also need to declare type in a way that's external to the message itself, such that things that are processing the message (or routing it to other things to process) have the option of learning something about what they are handling.
The current proposal feels to me like it conflates these two concerns, placing a type declaration outside the message content but inside some other container that must unify the two.
The original A2A design called for a type declaration to be a message type of its own. You could take any other message and make it a payload of a type message. This is very close to what this proposal recommends, except that in the original view, the thing you were looking about when you were done wasn't a message of arbitrary type but guaranteed to have type as a field--but rather a "type" message that had another message as its payload. If we could think about it that way, I think we'd be better off.
Feedback on @dbluhm 's hipe about message type ("Core Message Structure"):
I think we need to distinguish between the need to describe the type of a message in two different contexts:
describe the type from within the message
describe the type from outside the message
The type that's visible inside a message is guaranteed to be there even if we divorce the message from its transport or context and save just the raw bytes of the message to disk. It is important to have this, so that messages can be self-contained. This is why JPEG files have an internal header that identifies them as JPEGs, PDF files have an internal header that identifies them as PDFs, and so forth.
However, a type declared internally is of no use to something that sees a message payload only as an encrypted blob of bytes. So we also need to declare type in a way that's external to the message itself, such that things that are processing the message (or routing it to other things to process) have the option of learning something about what they are handling.
The current proposal feels to me like it conflates these two concerns, placing a type declaration outside the message content but inside some other container that must unify the two.
The original A2A design called for a type declaration to be a message type of its own. You could take any other message and make it a payload of a type message. This is very close to what this proposal recommends, except that in the original view, the thing you were looking at when you were done wasn't a message of arbitrary type but guaranteed to have type as a field--but rather a "type" message that had another message as its payload. If we could think about it that way, I think we'd be better off.
@danielhardman - what is the "original A2A design"? I'm not familiar with that.
@kdenhartog - as I understand it - JWM is at the same conceptual level as the Indy-SDK anonCrpt/AuthCrypt (I'm not sure which) - e.g. it is about how a chunk of data (such as a message) is encrypted and decrypted. Is that right?
When I used that phrase, I meant the design that is documented in the sovrin protocol repo at: https://github.com/sovrin-foundation/protocol/blob/master/janus/message-packaging.md#typed-messages
Calling it "original" may be a bit of a misnomer. It's the oldest design work on A2A that I encountered, at about a year old. And it underpinned the preso I gave about A2A way back in January. But it wasn't made visible to the community until IIW this spring, so it's not fair to think anybody else had seen it.
Agent call starting in about 7 minutes:
https://byu.zoom.us/j/2627891784
Here is the presentation that I used this morning... https://docs.google.com/presentation/d/1f8m9_g87oGie2jgU1Gb3F6HuxG0rgCAzQGANs8z3a_Q/edit?usp=sharing
Here is the presentation that I used for this morning's Agent Call... https://docs.google.com/presentation/d/1f8m9_g87oGie2jgU1Gb3F6HuxG0rgCAzQGANs8z3a_Q/edit?usp=sharing
Has joined the channel.
Here is the folder where the recording is for this morning's Agent call:
https://drive.google.com/drive/folders/1A3VDHvg-RNfVY0LAmSyXviJzaXFy-dBs
Here is the link to the Google document agenda/minutes:
https://docs.google.com/document/d/1OuGqlYWufwjZTU5cLHXtcNNIKQE8tZC1SNmhlNTX8iY/edit#heading=h.oq3lduavadon
@swcurran Near the end of the call today, you mentioned the concept of multiple application keys being associated with a DID. Would a portion of those application keys be used for the internal routing from Alice's agent domain (1 -> 2 -> 8), or is the routing concern and configuration independent of the application keys?
@swcurran Near the end of the call today, you mentioned the concept of multiple application keys being associated with a DID. Would a portion of those application keys be used for the internal routing from Alice's agent domain `(1 -> 2 -> 8)`, or is the routing concern and configuration independent of the application keys?
@swcurran Near the end of the call today, you mentioned the concept of multiple application keys being associated with a DID. Would a portion of those application keys be used for the internal routing of Alice's agent domain `(1 -> 2 -> 8)`, or is the routing concern and configuration independent of the application keys?
@kdenhartog Also, from the call today, would we always want to couple the auth/anon crypt functions with returning a JWM result in the indy-sdk? Or, should there be a convenience function in addition to those available calls?
@mhailstone I haven't found a reason where a JWM would be used to describe anything other than how a message was encrypted or decrypted. This is also why I've often referred to them as JWEs. We're essentially taking the JWE spec and tweaking it to our specific implementation to describe the encryption scheme and keys used to encrypt a message, so I saw it as valuable to strongly tie it to AnonCrypt and AuthCrypt. I'm open to creating a separate function API available (and think its the best way to do it), but I do think that Authcrypt/AnonCrypt should make those calls within it's method and return what the JWM formatter method returns.
@mhailstone I haven't found a reason where a JWM would be used to describe anything other than how a message was encrypted or decrypted. This is also why I've often referred to them as JWEs. We're essentially taking the JWE spec and tweaking it to our specific implementation to describe the encryption scheme and keys used to encrypt a message, so I saw it as valuable to strongly tie it to AnonCrypt and AuthCrypt. I'm open to creating a separate function API available (and think its the best way to do it), but I do think that Authcrypt/AnonCrypt should make those calls within it's method body and return what the JWM formatter method returns.
@mhailstone - independent of routing. Basically - those additional keys would be for any Agent in the domain that is expected at some point to handle Application Level messages. Whether or not any such agents also serve as a routing node is independent of that.
Also, @swcurran was your presentation built off of this https://github.com/sovrin-foundation/protocol/blob/master/janus/love-letters.md
@kdenhartog - I did borrow part of the picture. However, I removed some of the pairing of the keys because it goes against the encapsulation principle of routing vs. application level. It was one of the documents that while perhaps technically correct and intended, generates the confusion between the application layer messages and routing.
@swcurran @mhailstone @kdenhartog @darrell.odonnell @ryanwest6 @nage @TelegramSam and anybody else who was on Friday's call: I got a bit heated about the question of whether TDIDs were DIDs. I apologize. I needed to be more open minded, because there were good ideas being shared.
By way of apology, I've been trying to think about the question more objectively, taking both sides of the debate and exploring where it leads me. I didn't get to any kind of closure, but I feel like the attempt was instructive. I wrote it up and offer it FWIW: https://docs.google.com/document/d/1PvTfVgj2CEBozZb6HeZMQ0ab_zu2zd7tBbH8Hnq3mFM/edit?usp=sharing
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=sBtSYQWwnimuhy9zP) @danielhardman it's an awesome bunch of thinking going on. Thanks for consolidating these thoughts that have bounced around in various channels and meetings. I'm happy to see that things are being brought together. As far as getting "heated" I get more heated than that - we're a passionate bunch!!!
Has joined the channel.
I was going to begin working on IS-810 (the ticket to add multiple keys to an associated did_doc), but I get the feeling that we haven't reach consensus on the best way to achieve this based upon our call last Friday. In particular, I think we're stuck on the idea of if each agent would be given an associated DID, or if the agents keys and endpoints would be placed in the DID of the domain (identity owner). Either way works for me, but this decision does make a difference in terms of implementation, so I'd like to come to a collective decision on a good enough solution to move forward (and we can change it later if we need to). @danielhardman @gudkov @mhailstone @swcurran does anyone have a strong opinion on how to do this? I'll write up a doc sharing the implementation I had in mind and we can work from there.
I was going to begin working on IS-810 (the ticket to add multiple keys to an associated did_doc), but I get the feeling that we haven't reach consensus on the best way to achieve this based upon our call last Friday. In particular, I think we're stuck on the idea of if each agent would be given an associated DID, or if the agents keys and endpoints would be placed in the DID of the domain (identity owner). Either way works for me, but this decision does make a difference in terms of implementation, so I'd like to come to a collective decision on a good enough solution to move forward (and we can change it later if we need to). @danielhardman @gudkov @mhailstone @swcurran does anyone have a strong opinion on how to do this? I'll add a write up to @danielhardman about the Indy-SDK implementation I had in mind and we can work from there.
I was going to begin working on IS-810 (the ticket to add multiple keys to an associated did_doc), but I get the feeling that we haven't reach consensus on the best way to achieve this based upon our call last Friday. In particular, I think we're stuck on the idea of if each agent would be given an associated DID, or if the agents keys and endpoints would be placed in the DID of the domain (identity owner). Either way works for me, but this decision does make a difference in terms of implementation, so I'd like to come to a collective decision on a good enough solution to move forward (and we can change it later if we need to). @danielhardman @gudkov @mhailstone @swcurran does anyone have a strong opinion on how to do this?
As a side note, I'd prefer to not rush getting something into 1.6 that doesn't align with what we decide on. I would rather we develop a good solution to the problem and we get it in 1.7 instead.
@kdenhartog - agree that we should get it right. I suggest you start with a HIPE that ensures alignment with DIDDocs - e.g. indy-sdk functions that support DIDDoc updates.
Before commenting on your general question about what keys go in a DIDDoc, I need to review Daniel
@kdenhartog - agree that we should get it right. I suggest you start with a HIPE that ensures alignment with DIDDocs - e.g. indy-sdk functions that support DIDDoc updates.
Before commenting on your general question about what keys go in a DIDDoc, I need to review Daniel's document. Later today... :-)
Has joined the channel.
Has joined the channel.
hi, Within the nodejs indy agent, when you create a credential definition, by simply clicking a button, a post request is sent to /api/issuer/create_cred_def.
Do you know where this code is located and how I can access it, so I can understand what is actually executing.
code:
VitalijReicherdt (Wed, 18 Jul 2018 14:57:07 GMT):
@ghouston10 in `ui/routes/api.js` you can fin all routes...
```
router.post('/issuer/create_cred_def', auth.isLoggedIn, async function (req, res) {
await indy.issuer.createCredDef(req.body.schema_id, req.body.tag);
res.redirect('/#issuing');
});
```
VitalijReicherdt (Wed, 18 Jul 2018 14:57:07 GMT):
@ghouston10 in `ui/routes/api.js` you can find all routes...
```
router.post('/issuer/create_cred_def', auth.isLoggedIn, async function (req, res) {
await indy.issuer.createCredDef(req.body.schema_id, req.body.tag);
res.redirect('/#issuing');
});
```
dklesev (Wed, 18 Jul 2018 14:58:26 GMT):
Has joined the channel.
ghouston10 (Wed, 18 Jul 2018 14:58:47 GMT):
@VitalijReicherdt thanks
shazzle (Wed, 18 Jul 2018 17:12:12 GMT):
Has joined the channel.
mhailstone (Wed, 18 Jul 2018 19:31:45 GMT):
All,
Here are the current details of the Friday Agent call:
Agenda:
- Connection Establishment
- Message Type - URN structure
Topic: Indy Agent Design/Discussion
Time: Jul 20, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
swcurran (Thu, 19 Jul 2018 16:27:10 GMT):
For those on the call last week - I think we've uncovered why there was confusion on the need/non-need for tracking "TID" - the key/endpoint for encrypting a message for EVERY agent. For interoperability - we need to require that for messages going to a Domain Endpoint - eg. across Domains. Within a domain - we need not require that, and Daniel (and probably others) assumed we wouldn't be doing that, while I assumed we would. The correct answer is - it's up to the Domain to decide. What is done within a Domain stays in a Domain and we don't need to monitor that.
I'm going to update the HIPE and the presentation I created accordingly and we'll see if that makes it easier to understand.
swcurran (Thu, 19 Jul 2018 16:27:10 GMT):
For those on the call last week - I think we've uncovered why there was confusion on the need/non-need for tracking "TID" - the key/endpoint for encrypting a message for EVERY agent. For interoperability - we need to require that for messages going to a Domain Endpoint - eg. across Domains and folks were good with that. However, within a domain - we need not require that, and Daniel (and probably others) assumed we wouldn't be doing that, while I assumed we would. The correct answer is - it's up to the Domain to decide. What is done within a Domain stays in a Domain and we don't need to decide that.
I'm going to update the HIPE and the presentation I created accordingly and we'll see if that makes it easier to understand.
mhailstone (Thu, 19 Jul 2018 18:00:25 GMT):
I've heard the term "Sovereign Domain" used a few times in calls and discussions, and I'd like to throw out a definition. Here is a draft description of a "Sovereign Domain":
A virtual boundary representing the data and control over data and keys (through agents and other potential mechanisms) that an Identity Owner governs. This may span over devices and agencies.
I was thinking that an Identity Owner would control their data across all devices and agencies, and this would constitute a "domain" or "sovereign domain". @swcurran, I'm seeing that your use of "domain" above is more consistent with the notion that a "domain" is the same as an "agency". I think I am misunderstanding the differences or nuances from both ideas. Are these ideas complimentary or in conflict? Thanks. :)
dbluhm (Thu, 19 Jul 2018 18:32:47 GMT):
I'm not sure I have all the pieces (I was a little confused by @swcurran's message) but I don't think it is intended that domain = agency. As I understand it, a domain is more like the area of influence that an identity owner has. The identity owner does not have control of the agency that they use but the agency is providing an endpoint for a domain nonetheless. I think that's what is meant by a domain endpoint here -- or, in other words, the point of entry into a domain from without it.
swcurran (Thu, 19 Jul 2018 18:41:33 GMT):
I like the term Domain to represent all of the Agents and one endpoint controlled by an Identity. I also include the constraint that all of the Agents are built by the same vendor and can have internal knowledge of one another that cannot be assumed about Agents in another Domain.
swcurran (Thu, 19 Jul 2018 18:41:33 GMT):
I like the term Domain to represent all of the Agents and one endpoint collaborating on behalf of an Identity. I also include the constraint that all of the Agents are built by the same vendor and can have internal knowledge of one another that cannot be assumed about Agents in another Domain.
swcurran (Thu, 19 Jul 2018 18:41:33 GMT):
I like the term Domain to represent all of the Agents (and one endpoint) collaborating on behalf of an Identity. I also include the constraint that all of the Agents are built by the same vendor and can have internal knowledge of one another that cannot be assumed about Agents in another Domain.
swcurran (Thu, 19 Jul 2018 18:47:08 GMT):
In practice, an Identity might use several Agent Vendors (one from Evernym, one from IBM, one from AgentsRUs) and those would be separate domains. I think we would be safe (at least for V1) in assuming that even though they are linked to the same Identity (person, organization), they are separate domains and don't interact with each other - just with the Identity.
mhailstone (Thu, 19 Jul 2018 19:03:38 GMT):
Ok. This is great. Thank you. So, I'll summarize another way by saying that an Agency would create a Domain for an Identity Owner that would include all the Agents collaborating for an Identity Owner inside the Agency. An Agency can have multiple Domains (one for each Identity Owner), and a Domain can have multiple Agents (managed by the Domain of the Identity Owner inside the Agency). Agree?
mhailstone (Thu, 19 Jul 2018 19:05:22 GMT):
Would Domains inside an Agency share the same Domain Endpoint? (The Endpoint for every Domain inside an Agency would be under the same TDID.)
kdenhartog (Thu, 19 Jul 2018 20:35:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=rTsWQgnanpkAjrpby) @swcurran I've thought a little differently than this. In this line of thinking are you assuming that a pairwise DID could involve multiple domains? For example could I have half of my agents through one vendor and half through another vendor which would mean I have two domains? Even though I have control/influence over agents from two vendors for 1 pairwise relationship?
kdenhartog (Thu, 19 Jul 2018 20:35:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=rTsWQgnanpkAjrpby) @swcurran I've thought a little differently than this. In this line of thinking are you assuming that a pairwise DID could involve multiple domains? For example could I have half of my agents through one vendor and half through another vendor which would mean I have two domains? Even though I have control/influence over agents from two vendors for 1 pairwise relationship? How would we refer to the collection of agents across multiple domains? Would it be the same if only agents in my domains know the endpoints in another one of my domains? E.g. 1@K is my Evernym Agency Agent, 2@K is my Evernym Cloud Agent, 3@K is my phone running connect.me, 4@K is my IBM Watson agent, , and 1@A is Alice's Agency Agent. I want a message to go 1@A -> 1@K -> 2@K -> 3@K -> 4@K -> 3@K -> 2@K -> 1@K -> 1@A with processing happening at each step of the way. I don't think this is something we are going to assume is a first implementation use case, but if we're going to consider it as a future upgrade, I want to understand the language we'll use to describe it in order to prevent us from muddying the language to describe moving messages between our Agency Domains.
swcurran (Thu, 19 Jul 2018 20:48:20 GMT):
@kdenhartog - while in theory I could create a pairwise DID that references multiple domains, I think that is an unnecessary complication and can be left out of V1 of the protocol without loss. If we later find it is needed, it can be added.
kdenhartog (Thu, 19 Jul 2018 20:53:02 GMT):
@swcurran I just realized I was adding that as an edit rather than a separate message. Does this make sense why I want to define it?
kdenhartog (Thu, 19 Jul 2018 20:54:47 GMT):
I propose that we refer to this as idea with multiple domains as a Sovereign Domain, where as all agents within 1 agency are just a domain.
kdenhartog (Thu, 19 Jul 2018 20:54:47 GMT):
I propose that we refer to this idea with multiple domains as a Sovereign Domain, where as all agents within 1 agency are just a domain.
kdenhartog (Thu, 19 Jul 2018 20:54:47 GMT):
I propose that we refer to this idea with multiple vendors as a Sovereign Domain, where as all agents within 1 vendor are just a domain.
swcurran (Thu, 19 Jul 2018 20:57:05 GMT):
@kdenhartog - I don't believe the first messaging protocol should only support peer-to-peer app level messaging (in terms I used last) week, with the possible (but not necessary) exception of a message sent in parallel to multiple peers (one to many). We should not support a message intended to be processed in a serial manner as described above. That's just way too complex.
swcurran (Thu, 19 Jul 2018 20:57:52 GMT):
If you are talking about it just from routing (instead of "processing"), I'm back to the sender should not need to know how to route the message all the way to the recipient - just to the next agent to move it along.
kdenhartog (Thu, 19 Jul 2018 21:01:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=qPCurcQ2v4couehaz) @swcurran I thought the reason we we're handling routing of messages in the way we were is so that a domain can chose to handle complexity of this level both at the processing level and at the routing level?
kdenhartog (Thu, 19 Jul 2018 21:01:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=qPCurcQ2v4couehaz) @swcurran I thought the reason we we're handling routing of messages in the way we were is so that a domain can chose to handle complexity of this level both at the processing level and at the routing level? The application message could define that it needs to understand where the processing is handled (e.g. part of the data is signed by 1 agent and the other part is signed by another agent) but that is defined at the application level, so we don't need to consider it as long as it's not prevented which you're routing proposal suggests is fine because the only time sovereign domains interact is through their agencies.
swcurran (Thu, 19 Jul 2018 21:10:50 GMT):
I don't know if a use case where I need to split App Level processing by 2 agents of one message.
swcurran (Thu, 19 Jul 2018 21:11:35 GMT):
So in the proposal I put forward, there is no support for that. One Agent is sending a message to One Agent.
swcurran (Thu, 19 Jul 2018 21:11:35 GMT):
So in the proposal I put forward, there is no support for that. One Agent is sending a message to One Agent at the Application Layer.
swcurran (Thu, 19 Jul 2018 21:12:03 GMT):
It is sending it via many agents at the Tranport Layer.
kdenhartog (Thu, 19 Jul 2018 21:13:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DJAkuN3s6S947uX3j) @swcurran genomic data processing which is offloaded to a cloud agent (e.g. IBM watson) but is considered acceptable by the edge agent e.g. the phone so it also signs the message to give strong authorization that the data has not been made up/ the IBM watson agent isn't impersonating the identity owner and making false genomic data.
swcurran (Thu, 19 Jul 2018 21:17:24 GMT):
My quick answer is: Verifiable Credentials for delegation/approval and multiple messages to accomplish the transaction. Not a single message, but an App Layer series of messages.
kdenhartog (Thu, 19 Jul 2018 21:18:20 GMT):
It wouldn't be a must have case at the moment, but it's an example of the complexity of messages that we might have to handle at the routing layer. Another example is the signing via multiple devices to authorize a large money transfer. It's up to the two identity owners to decide what they want to be able to do (at the application layer). FWIW, I don't believe we are disabling this use case in my eye. I just am wanting to understand the language to know how we describe a message that may flow through multiple vendors.
kdenhartog (Thu, 19 Jul 2018 21:19:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DPTr9i8985MxzPtFa) @swcurran This works just as well too.
swcurran (Thu, 19 Jul 2018 21:20:59 GMT):
I disagree that such a matter should be handled at the routing level.
kdenhartog (Thu, 19 Jul 2018 21:21:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=gLaBxZ6mWtG3kRkC6) @swcurran I'm not saying it should be.
kdenhartog (Thu, 19 Jul 2018 21:22:57 GMT):
What I'm implying is that the routing layer should enable (and does) this routing if the application layer needs to handle it in that way.
kdenhartog (Thu, 19 Jul 2018 21:22:57 GMT):
What I'm implying is that the routing layer should allow (and does) this routing if the application layer needs to handle it in that way.
kdenhartog (Thu, 19 Jul 2018 21:26:58 GMT):
If we assume that an application can handle messaging in this way though, we'll need a way to describe a domain which allows a message to travel through multiple vendors. A less complex example would be if I use an Evernym Agency agent and a CLI agent. Would this still be classified as a single domain even though the agents are produced by two separate vendors (Evernym and Hyperledger)
kdenhartog (Thu, 19 Jul 2018 21:26:58 GMT):
If we assume that an application can handle messaging in this way though, we'll need a way to describe a domain which allows a message to travel through multiple vendors. A less complex example would be if I use an Evernym Agency agent and a CLI agent. Would this still be classified as a single domain even though the agents are produced by two separate vendors? (Evernym and Hyperledger)
swcurran (Thu, 19 Jul 2018 21:30:13 GMT):
The problem is that to handle an arbitrary message addressed to multiple parties for arbitrary processing makes the routing WAY more complex. If you leave it to the App Layer above - the routing is easy - one to one every time.
swcurran (Thu, 19 Jul 2018 21:31:01 GMT):
Multiplex might be an exception (the identical message sent to multiple Agents for processing) might be an exception, but I think it is super complex.
kdenhartog (Thu, 19 Jul 2018 21:38:45 GMT):
I don't understand how this adds additional complexity. Say for example I have an app message that has this format
{ "type": "payment",
"amount": 10,000,
"Signatures" : ["DID#key1" : signature1,
"DID#key2" : signature2 ] }
Agent 1 formats the message then authcrypts it then puts it in a forward message format and anon crypts it and sends it to agent 2's endpoint who anondecrypt's realizes the message is for it, then authdeccrypts the message and appends it's signature to the signatures array reencrypts it all back up and routes it to the agency which then sends it across. Processing 2 messages for this type of use case I would argue is more complex because I have to associate the two messages and hold them in storage until I have both and then process them together rather than letting the routing handle it and the application package it all properly. In this case, the person who is verifying payment has all the data in a single message which is less complex.
kdenhartog (Thu, 19 Jul 2018 21:42:00 GMT):
Point of the use case though is that the application should be able to decide routing flows as well as messaging structures and by allowing for both types we're allowing a more enriching application layer.
kdenhartog (Thu, 19 Jul 2018 21:42:00 GMT):
Point of the use case though is that the application should be able to decide routing flows as well as messaging structures and by allowing for both types we're allowing a more enriching application layer. A good application layer family will need to account many different sovereign domain structures. If it accounts for only specific setups, then many users won't be able to support it.
kdenhartog (Thu, 19 Jul 2018 21:42:00 GMT):
Point of the use case though is that the application should be able to decide routing flows as well as messaging structures and by allowing for both types we're allowing a more enriching application layer. A good application layer family will need to account for many different sovereign domain structures. If it accounts for only specific setups, then many users won't be able to support it.
dbluhm (Thu, 19 Jul 2018 22:17:56 GMT):
@mhailstone Is the agenda for the call tomorrow somewhere I could view/edit?
kdenhartog (Thu, 19 Jul 2018 22:40:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wRAPhTkbpoGdfYTNv) @mhailstone @dbluhm here
mhailstone (Thu, 19 Jul 2018 22:55:14 GMT):
@kdenhartog Thank you for answering.
@dbluhm If you have anything to add, just let me know.
Review HIPE #18 (https://github.com/hyperledger/indy-hipe/pull/18) for the Connection Establishment discussion.
Review HIPE #19 (https://github.com/hyperledger/indy-hipe/pull/19) for the Message Type - URN discussion.
mhailstone (Thu, 19 Jul 2018 22:55:14 GMT):
@kdenhartog Thank you for answering.
@dbluhm If you have anything to add, just let me know.
Review HIPE #18 (https://github.com/hyperledger/indy-hipe/pull/18) for the Connection Establishment discussion.
Review HIPE #19 (https://github.com/hyperledger/indy-hipe/pull/19) for the Message Type - URN discussion.
srinivasanraghavan (Fri, 20 Jul 2018 02:23:48 GMT):
Has joined the channel.
dbluhm (Fri, 20 Jul 2018 03:19:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=pi9miaNfXASzb4PJ8) @mhailstone I was planning to add more detail on the connection establishment agenda item to kind of seed the discussion with a few topics and provide somewhere to start with note taking. So, I was referring to the actual google doc that we've been using along with our discussions. Thanks for calling that to my attention though, @kdenhartog
dbluhm (Fri, 20 Jul 2018 03:22:10 GMT):
At this point though, I'll just wait for the meeting tomorrow. Thanks and talk to you all in the morning!
srinivasanraghavan (Fri, 20 Jul 2018 03:24:34 GMT):
Hi all I have a fair idea of the Indy SDK code base .. Help me with indy agent code base . Or this is only in spec mode
dbluhm (Fri, 20 Jul 2018 03:30:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZC7RoBPAp6vYNBezr) @srinivasanraghavan @mhailstone and @saholman have done an excellent job creating something that we've called a "reference agent" meaning it gives a really good idea of how we expect things to work in the real world but might not necessarily be production ready. This could lives in the nodejs folder of that repository and one of those two could probably give a better introduction to that code than I could. Most of the work regarding agents lately, however, have been working together as a community to establish protocols for communication and other important operations that agents perform.
dbluhm (Fri, 20 Jul 2018 03:30:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZC7RoBPAp6vYNBezr) @srinivasanraghavan @mhailstone and @saholman have done an excellent job creating something that we've called a "reference agent" meaning it gives a really good idea of how we expect things to work in the real world but might not necessarily be production ready. This code lives in the nodejs folder of that repository and one of those two could probably give a better introduction to that code than I could. Most of the work regarding agents lately, however, have been working together as a community to establish protocols for communication and other important operations that agents perform.
dbluhm (Fri, 20 Jul 2018 03:30:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZC7RoBPAp6vYNBezr) @srinivasanraghavan @mhailstone and @saholman have done an excellent job creating something that we've called a "reference agent" meaning it gives a really good idea of how we expect things to work in the real world but might not necessarily be production ready. This code lives in the nodejs folder of that repository and either @mhailstone or @saholman could give a better introduction to that code than I could. Most of the work regarding agents lately, however, have been working together as a community to establish protocols for communication and other important operations that agents perform.
dbluhm (Fri, 20 Jul 2018 03:30:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZC7RoBPAp6vYNBezr) @srinivasanraghavan @mhailstone and @saholman have done an excellent job creating something that we've called a "reference agent" meaning it gives a really good idea of how we expect things to work in the real world but might not necessarily be production ready. This code lives in the nodejs folder of that repository and either @mhailstone or @saholman could give a better introduction to that code than I could. Most of the work regarding agents lately, however, has been working together as a community to establish protocols for communication and other important operations that agents perform.
dbluhm (Fri, 20 Jul 2018 03:32:24 GMT):
That is to say that we are still defining how agents work so code contained in Indy-agent is likely to change
srinivasanraghavan (Fri, 20 Jul 2018 03:43:26 GMT):
Thanks @dbluhm .
mhailstone (Fri, 20 Jul 2018 13:35:13 GMT):
@dbluhm Here is the Google document: https://docs.google.com/document/d/1pX3YQfAs22W4JxzeU4YW-IxeMTUkeBGx-rKsugUlaRI/edit#
mhailstone (Fri, 20 Jul 2018 13:47:07 GMT):
Agent call in 14 minutes: https://byu.zoom.us/j/2627891784
danielhardman (Fri, 20 Jul 2018 14:07:23 GMT):
I believe I was the first one to begin using "sovereign domain" as a term. My meaning was "everything over which an identity owner exercises sovereignty". Basically their kingdom. I think this more or less drops right into the outline that @swcurran is using, and that it is pretty distinct from an agency.
danielhardman (Fri, 20 Jul 2018 14:07:23 GMT):
I believe I was the first one to popularize "sovereign domain" as a term. My meaning was "everything over which an identity owner exercises sovereignty". Basically their kingdom. I think this more or less drops right into the outline that @swcurran is using, and that it is pretty distinct from an agency.
dbluhm (Fri, 20 Jul 2018 14:41:39 GMT):
Oh shoot
dbluhm (Fri, 20 Jul 2018 14:41:43 GMT):
I thought it was at 9
dbluhm (Fri, 20 Jul 2018 14:41:57 GMT):
:thumbsdown:
nage (Fri, 20 Jul 2018 15:08:38 GMT):
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#crypto_pfs
mhailstone (Fri, 20 Jul 2018 20:02:47 GMT):
Here is the link to the folder that has the uploaded recording of the Agent call today:
https://drive.google.com/drive/folders/1CZ9JfDAZXZEOiJvT1g_pxk7ihf-x8gXA
Also, here is the link to the agenda document we have created and will edit throughout next week for the Agent2Agent 2 Day vConference/Workshop:
https://docs.google.com/document/d/1URfeAtm_o14KEd7k0CxRTh8HS-YNZKWumR-29AMPDEQ/edit?ts=5b4fd6df#
mhailstone (Fri, 20 Jul 2018 22:03:57 GMT):
@danielhardman @swcurran I’m reading the Sovrin Protocol repository and documentation in preparation for the 2 day vConference. I came across this paragraph, and I was confused:
>Because Relationships and Attributes are orthogonal, an Issuer does not issue credentials to a particular DID. Remember DIDs are contextual to a relationship, and Credentials should be usable in different relationships without sharing correlation handles across relationships or contexts.
https://github.com/sovrin-foundation/protocol#the-relationship-attribute-plane
Doesn’t the Issuer need to establish a connection and issue the credential to the pairwise DID of that connection? But, because of the “link secret”, a credential holder can fulfill proof requests with a proof derived from any credential issued to any pairwise DID. Is that correct?
swcurran (Fri, 20 Jul 2018 22:17:10 GMT):
My understanding:
Technically, no. The Issuer must have a Schema and a CredDef. In the CredRequest, the Holder must say what Credential they want and their Blinded Link Secret. The Holder can then receive the Credential.
How the request/issue data is delivered is not relevant to the actual credential contents. So, for example, if the Issuer and Holder are in person, no DID-based connection is necessary. We've actually got an implementation of an off-line Proof Request/Proof sequence that does not require any pairwise DID-relationship.
To put it another way - no part of the pairwise DID relationship data between the issuer and holder goes into the Credential. The pairwise relationship is established to allow various messages to go back and forth to, for example, enable the issuer to know how they know the holder - e.g. "Ah...this is Student 39859309 and we have some data about her".
mhailstone (Fri, 20 Jul 2018 22:21:35 GMT):
Excellent. Thanks @swcurran . So, how the credential is delivered (most commonly would be through a pairwise DID connection) is independent of how the credential is created and how proofs are created from credentials.
mhailstone (Fri, 20 Jul 2018 22:26:33 GMT):
Another statement clarification:
> Each DID/Agent combination requires a separate key. An endpoint must be unique per relationship, so an agent must support multiple endpoints.
https://github.com/sovrin-foundation/protocol#the-relationship-agent-plane
Has this changed since the Transport (D)ID discussion?
swcurran (Fri, 20 Jul 2018 22:27:03 GMT):
100% on the latter (proofs from credentials - we've done it) and I'm pretty well certain the same is true for credential creation.
BTW - we think that in-person verification could be a really good thin edge use case - bars, events where you have to show your drivers license, etc. No pairwise DIDs needed - just take the credential you have from the Driver's Licence issuer, prep a selective disclosure proof request, create the proof, and deliver it for verification.
mhailstone (Fri, 20 Jul 2018 22:28:17 GMT):
Very intriguing use case. :)
swcurran (Fri, 20 Jul 2018 22:34:40 GMT):
Here is current thinking on that.
Across domains - wire encryption/no plaintext is necessary, so key/endpoint is needed. However, that is pulled from the destination DID, so all good. Daniel and I are debating whether the routing data for a shared Domain Endpoint should be minimized, which if it does would require a second layer of routing encryption.
Within a domain - it's totally up to the implementation. They may or may not need to encrypt all plaintext between nodes.
As such, we don't have to talk about TDIDs anymore from an interoperability perspective. They are internal to a Domain and may or may not be needed.
I'm planning to remove references to them from the HIPE.
swcurran (Fri, 20 Jul 2018 22:34:40 GMT):
Here is current thinking on that.
Across domains - wire encryption/no plaintext is necessary, so key/endpoint is needed. However, that is pulled from the destination DID, so all good - no separate TDID. Daniel and I are debating whether the routing data for a shared Domain Endpoint should be minimized, which if it does would require a second layer of routing encryption.
Within a domain - it's totally up to the implementation. They may or may not need to encrypt all plaintext between nodes.
As such, we don't have to talk about TDIDs anymore from an interoperability perspective. They are internal to a Domain and may or may not be needed.
I'm planning to remove references to them from the HIPE.
swcurran (Fri, 20 Jul 2018 22:34:40 GMT):
Here is current thinking on that.
Across domains - wire encryption/no plaintext is necessary, so key/endpoint is needed. However, that is pulled from the destination DID, so all good - no separate TDID. Daniel and I are debating whether the routing data for a shared Domain Endpoint should be minimized (show only the DID, not the DID#key combination), which if it does would require a second layer of routing encryption.
Within a domain - it's totally up to the implementation. They may or may not need to encrypt all plaintext between nodes.
As such, we don't have to talk about TDIDs anymore from an interoperability perspective. They are internal to a Domain and may or may not be needed.
I'm planning to remove references to them from the HIPE.
mhailstone (Fri, 20 Jul 2018 22:39:26 GMT):
What is meant by a shared Domain Endpoint? Is this the Agency scenario?
swcurran (Fri, 20 Jul 2018 22:41:28 GMT):
Where all the DIDs of all the identities use the same endpoint - e.g. https://ssiagency.ibm.com
kdenhartog (Sat, 21 Jul 2018 03:13:58 GMT):
This is one of the reason why I want to avoid letting cloud agents have access to data. https://thehackernews.com/2018/07/apple-china-icloud-data.html?m=1
DonClaude (Sun, 22 Jul 2018 19:53:56 GMT):
Has joined the channel.
xnopre (Mon, 23 Jul 2018 13:39:33 GMT):
Has joined the channel.
dbluhm (Mon, 23 Jul 2018 16:26:39 GMT):
@mhailstone @swcurran and others: It was proposed this morning in the Indy-Maintainers call that at the beginning of our Agent Summit we approve and close all agent related HIPEs that we can and then focus the remaining time on the controversial topics with the goal of having an approved HIPE for each of the topics by the end of the Summit. I think this fits well with what has been proposed so far in our agenda and would provide very tangible output from the proceedings. What thoughts do you have on this?
dbluhm (Mon, 23 Jul 2018 16:26:39 GMT):
@mhailstone @swcurran and others: It was proposed this morning in the Indy-Maintainers call that, at the beginning of our Agent Summit, we approve and close all agent related HIPEs that we can and then focus the remaining time on the controversial topics with the goal of having an approved HIPE for each of the topics by the end of the Summit. I think this fits well with what has been proposed so far in our agenda and would provide very tangible output from the proceedings. What thoughts do you have on this?
swcurran (Mon, 23 Jul 2018 17:19:21 GMT):
@dbluhm @mhailstone That's a different goal from what is proposed in the Agenda - and would seem to be less aggressive and not focused on delivering code. Not against it, but it's not what I hope to get out of it. I think the HIPE documents can get in the way of the discussion. Preference would be to an easier mechanism for the early discussion and then into HIPEs. Again - not against the HIPE process when the topic is ready, but if you go too early, I think it's much harder to make progress, just because of the use of github.
dbluhm (Mon, 23 Jul 2018 17:36:53 GMT):
@swcurran I think what you are saying is true of whats been happening so far with HIPEs. Too much talk and too little implementation and tests to back up the proposal. In the future, starting as soon as possible, we would like tests to accompany HIPEs that have reached an approproate level of discussion.
dbluhm (Mon, 23 Jul 2018 17:37:42 GMT):
I think I and the others that were present on the call this morning would be more than supportive of delivering code as well as a result of the summit
swcurran (Mon, 23 Jul 2018 17:40:00 GMT):
@dbluhm - not saying we aren't all in favour of that - I know that's the goal. I'm suggesting that the mechanisms of dealing with the HIPEs vs. progressing on the discussion/agreement while at the summit wouldn't be as good.
mhailstone (Mon, 23 Jul 2018 17:40:43 GMT):
@dbluhm @swcurran Sorry to be late to this conversation. I agree with @swcurran that the current intended goal of the Agent Summit is to focus on getting implementation details flushed out for an interoperable Agent protocol. I agree that many of the HIPEs are intended to that end, but we wanted to create an agenda of topics to discuss and prioritize for the Agent Summit. If the lead person wants to incorporate a related/specific HIPE in summarizing the topic, I think that would be fine, but the agenda should be focused on what the group feels are the most important topics to achieve the interoperability goal. I think initially going through the HIPEs as an approach would deter from the goal and purpose of the summit. I'm not against discussing the HIPEs, just the approach to finish them first as the prioritized agenda.
dbluhm (Mon, 23 Jul 2018 17:41:36 GMT):
I'll call @nage in for his opinion, as it was his suggestion
TelegramSam (Mon, 23 Jul 2018 17:47:31 GMT):
@dbluhm I have commentary on the Type HIPE. What's the best way to do that? Comments on the pull request, or an additional pull request of some type?
swcurran (Mon, 23 Jul 2018 17:50:18 GMT):
Both have been done. Comments have been added, and Daniel did a pull request against my fork to just make changes.
TelegramSam (Mon, 23 Jul 2018 17:51:08 GMT):
so which is the cannonical HIPE at this point? @dbluhm's, or yours?
swcurran (Mon, 23 Jul 2018 17:52:31 GMT):
They are different HIPEs, different purposes.
dbluhm (Mon, 23 Jul 2018 17:56:08 GMT):
@TelegramSam I think it depends on the extent of your coments/changes. If it's a substantial rewrite of a section of the HIPE, a PR seems better. If not, i think a comment would be fine.
TelegramSam (Mon, 23 Jul 2018 17:56:52 GMT):
I've started it as a comment. If you think it needs to be a pull request, I'll do that work.
TelegramSam (Mon, 23 Jul 2018 17:57:12 GMT):
@swcurran copy that. I was confused about what you meant.
swcurran (Mon, 23 Jul 2018 17:57:59 GMT):
I've been good at that lately. :-).
dbluhm (Mon, 23 Jul 2018 17:58:26 GMT):
If you've already started the comment, it's probably not worth it to make it a PR. Whatever is easier
TelegramSam (Mon, 23 Jul 2018 18:13:19 GMT):
It got large.
dbluhm (Mon, 23 Jul 2018 18:20:55 GMT):
@mhailstone @swcurran
> the current intended goal of the Agent Summit is to focus on getting implementation details flushed out for an interoperable Agent protocol
So it's unclear to me exactly what form the product of this goal will take. What did you have in mind?
swcurran (Mon, 23 Jul 2018 18:24:33 GMT):
M thought is several levels:
Minimum: a whiteboard design/agreement with a commitment to write up the solution
Medium: a Google Doc of the design for sharing and comment collection/agreement
Ideal: A HIPE that covers the topic.
My feeling is that a HIPE is not realistic and will take away from the discussion time.
TelegramSam (Mon, 23 Jul 2018 18:41:18 GMT):
Figuring out what should be in the HIPE (and likely commit someone there to write said HIPE) I think is the right goal.
dbluhm (Mon, 23 Jul 2018 18:48:30 GMT):
@mhailstone do you have the Agent Summit event details somewhere that I could easily share it? Is the agenda google doc the best thing to share?
mhailstone (Mon, 23 Jul 2018 20:05:48 GMT):
The suggestion in last Friday's Agent call was to have some kind of an artifact or document written up, similar to how Rebooting Web of Trust conferences work. Like @swcurran said, the minimum goal would be to have a agreement and commitment for a solution on a topic. Having Google documents and HIPEs would be a nice target, but may not be done at the summit. Having an assignment to have those written after the summit would be part of the minimum I think as well.
mhailstone (Mon, 23 Jul 2018 20:05:48 GMT):
The suggestion in last Friday's Agent call was to have some kind of an artifact or document written up, similar to how Rebooting Web of Trust conferences work. Like @swcurran said, the minimum goal would be to have agreement and a commitment for a solution on a topic. Having Google documents and HIPEs would be a nice target, but may not be done at the summit. Having an assignment to have those written after the summit would be part of the minimum I think as well.
nage (Tue, 24 Jul 2018 00:59:01 GMT):
@mhailstone the idea there was to corral active items and make sure we had the right action items elsewhere on the agenda (or work item commitments), not to handle each HIPE there in the meeting. It is a common tactic and W3C meetings to try and make sure f2f time is getting used up on the most pressing issues and not see ending on things that are already moving forward using the asynchronous HIPE process.
nage (Tue, 24 Jul 2018 00:59:01 GMT):
@mhailstone the idea there was to corral active items and make sure we had the right action items elsewhere on the agenda (or work item commitments), not to handle each HIPE there in the meeting. It is a common tactic and W3C meetings to try and make sure f2f time is getting used up on the most pressing issues and not deep ending on things that are already moving forward using the asynchronous HIPE process.
swcurran (Tue, 24 Jul 2018 05:34:44 GMT):
So it sounds like we're all in agreement. Get to the minimum as I've listed above and anything beyond that is awesome.
DoctorX (Wed, 25 Jul 2018 03:24:54 GMT):
Hello, Guys.
I am reading some doc to try to figure out how to setup a fresh Indy network. One more thing, in https://github.com/hyperledger/indy-sdk/blob/05868745e44634398b56032051e8a516d8621080/doc/getting-started/getting-started.md, the steward use `steward_did_info = {'seed': '000000000000000000000000Steward1'}` to create a did, and then it can signannsubmit the transaction, like this: `nym_request = await ledger.build_nym_request(steward_did, steward_faber_did, steward_faber_key, None, role)
await ledger.sign_and_submit_request(pool_handle, steward_wallet, steward_did, nym_request)`. That because there is Steward Agent on the ledger and its NYM DID generated from seed 000000000000000000000000Steward1, right? And then any DID generated from this seed, will be treat as this Steward Agent, is that correct?
DoctorX (Wed, 25 Jul 2018 03:26:05 GMT):
I am reading some doc to try to figure out how to setup a fresh Indy network. One more thing, in https://github.com/hyperledger/indy-sdk/blob/05868745e44634398b56032051e8a516d8621080/doc/getting-started/getting-started.md, the steward use `steward_did_info = {'seed': '000000000000000000000000Steward1'}` to create a did, and then it can signannsubmit the transaction, like this: ```
`nym_request = await ledger.build_nym_request(steward_did, steward_faber_did, steward_faber_key, None, role)
await ledger.sign_and_submit_request(pool_handle, steward_wallet, steward_did, nym_request)`
``` . That because there is Steward Agent on the ledger and its NYM DID generated from 000000000000000000000000Steward1, right? And then any DID generated from this seed, will be treat as this Steward Agent, is that correct?
DoctorX (Wed, 25 Jul 2018 03:26:58 GMT):
I am reading some doc to try to figure out how to setup a fresh Indy network. One more thing, in https://github.com/hyperledger/indy-sdk/blob/05868745e44634398b56032051e8a516d8621080/doc/getting-started/getting-started.md, the steward use `steward_did_info = {'seed': '000000000000000000000000Steward1'}` to create a did, and then it can signannsubmit the transaction, like this:
```
nym_request = await ledger.build_nym_request(steward_did, steward_faber_did, steward_faber_key, None, role)
await ledger.sign_and_submit_request(pool_handle, steward_wallet, steward_did, nym_request)
```
. That because there is Steward Agent on the ledger and its NYM DID generated from 000000000000000000000000Steward1, right? And then any DID generated from this seed, will be treat as this Steward Agent, is that correct?
swcurran (Wed, 25 Jul 2018 03:28:16 GMT):
Hey folks, I did a major rewrite of the Transport Messaging HIPE to address feedback from the community, and update the Slides presentation I did to reflect the changes. The major changes:
* Eliminated discussion of "within domain" requirements - since those are implementation specific. For example, we should not require encryption when routing a message from agent to agent within a domain. That narrowed the scope of the HIPE and allowed elimination of weird terms like TDIDs.
* Documented a way to reduce the routing information made available to the shared Domain Endpoint (aka the Agency Endpoint), and correspondingly added an identity-specific "Cloud Routing Agent" that has all of the routing available.
* The reduction creates additional complexity - another layer of encryption from Sender to Cloud Routing Agent, and made the minimum DIDDoc an endpoint + 3 keys vs. previous endpoint + 2 keys.
* Added a sample DIDDoc to show the contents of a DIDDoc that matches DID Spec requirements.
Revised Slides presentation: https://drive.google.com/open?id=1f8m9_g87oGie2jgU1Gb3F6HuxG0rgCAzQGANs8z3a_Q
Revised HIPE: https://github.com/swcurran/indy-hipe/blob/d408bf248c6a0f2db42c1cb7cce6c76672319a30/text/transport-layer-messaging/README.md
Those planning to attend the Agent2Agent Workshop next week should take a look.
@danielhardman @mhailstone @TelegramSam @kdenhartog @dbluhm @RyanWest
mhailstone (Wed, 25 Jul 2018 22:10:38 GMT):
All,
We are still planning on the Friday Agent call which is the last call before the 2 day Agent2Agent vConference/Workshop/Summit July 30-31.
Here is the agenda and details for the Friday call:
Agenda:
- Ensure assignments are made to each topic in the Agenda Google document (https://docs.google.com/document/d/1URfeAtm_o14KEd7k0CxRTh8HS-YNZKWumR-29AMPDEQ/edit?ts=5b4fd6df#)
- 10-15 minutes to go over each topic that is proposed in the Agenda Google document
Topic: Indy Agent Design/Discussion
Time: Jul 27, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
andrewtan (Thu, 26 Jul 2018 03:10:17 GMT):
Has joined the channel.
sklump (Thu, 26 Jul 2018 11:38:36 GMT):
Has left the channel.
ghouston10 (Thu, 26 Jul 2018 14:43:46 GMT):
Hi, im working with the indy agent node js implementation. When alice accepts a credential from acme, for example, acme will then call exports.request within indy/src/credentials/handlers.js which will then call exports.acceptRequest within indy/src/credentials/index.js and it is here the values are set for the credential.
I am looking to know how exports.request within indy/src/credentials/handlers.js is actually called, as I am trying to create an agent where the issuer can then manually enter in values for the credential.
Just struggling at the moment to fully understand the data flow and functionality and understanding this aspect would be beneficial. Any help would be much appreciated.
bdeva (Thu, 26 Jul 2018 15:24:26 GMT):
Has joined the channel.
vladan.divac (Thu, 26 Jul 2018 15:44:13 GMT):
Has joined the channel.
TelegramSam (Thu, 26 Jul 2018 16:47:07 GMT):
@swcurran thinking about your updated doc. Now, making a pairwise identifier really means making a whole collection of keys in a distributed fashion.
TelegramSam (Thu, 26 Jul 2018 16:47:30 GMT):
it isn't just "I make a key, you make a key", but you make a set of keys, and I make a set of keys...."
swcurran (Thu, 26 Jul 2018 17:22:40 GMT):
Yes, that's how I interpret where we have arrived in the discussion. I hope that is right.
I can see another way to go - there is one agent handling the conversation/decryption, and then it figures out who will handle the message. In that model - the sender only ever sees one "device" - and we're back to one key.
danielhardman (Thu, 26 Jul 2018 17:37:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=6RoX4mZ5zgxNawLX3) @DoctorX Technically, the seed is a seed for the *key* owned by the DID, not a seed for the DID itself. However, I believe the DID (which could be any random value) is derived deterministically from the key for convenience, so as a happy accident, the seed also governs the DID value as well. So: as long as you use the same seed, you will populate the wallet with the same DID+key, and will be able to act as that party in the future.
DoctorX (Fri, 27 Jul 2018 07:16:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=BNugzHMbbizmYiASX) @danielhardman I got you. That means the Agent should protect the *seed* carefully. Thanks, Daniel.
TelegramSam (Fri, 27 Jul 2018 12:06:26 GMT):
@swcurran it could be a forward, or it could be a 'redirect' authorized by main agent. That starts to feel a little like a relationship ledger, though perhaps not.
mhailstone (Fri, 27 Jul 2018 13:54:02 GMT):
Agent call starting in 6 minutes: https://byu.zoom.us/j/2627891784
mhailstone (Fri, 27 Jul 2018 13:57:28 GMT):
Agenda document for call: https://docs.google.com/document/d/1FIxUYDKTbNBAL_0NVPzyHe4MCuoZELCHIBLzT3dc1rs/edit#
dbluhm (Fri, 27 Jul 2018 14:11:51 GMT):
From Agent call chat: the agenda for the agent2agent summit https://docs.google.com/document/d/1URfeAtm_o14KEd7k0CxRTh8HS-YNZKWumR-29AMPDEQ/edit?ts=5b4fd6df#
swcurran (Fri, 27 Jul 2018 15:16:46 GMT):
From the Agent Call today:
Pre-Conference Collection form. Please give us your view on the importance of the different topics.
https://goo.gl/forms/epNtwRQWLTRVARdA2
swcurran (Fri, 27 Jul 2018 15:16:46 GMT):
From the Agent Call today:
Pre-Conference Collection Google Input form. Please give us your views on the importance of the different topics.
https://goo.gl/forms/epNtwRQWLTRVARdA2
mhailstone (Fri, 27 Jul 2018 16:05:17 GMT):
Here is the link to the recording of today's call:
https://drive.google.com/drive/folders/1UoD4lIfzABBJjuvXGo6pEqBBncHAksuw
mhailstone (Fri, 27 Jul 2018 20:15:40 GMT):
Here is a draft of the slides I'll use to get our "Warm Up: One-To-One Instant Messaging" topic started on Monday morning:
https://docs.google.com/presentation/d/122dFhAqq5HtvT3c0idduOXn-eH64j4EiqBWOv_R8-z0/edit#slide=id.g3e56b70bb0_0_22
dbluhm (Fri, 27 Jul 2018 20:43:58 GMT):
Did we ever have a follow-up conversation about using something like protobuf? It's been some time since it was first mentioned
swcurran (Sat, 28 Jul 2018 00:17:13 GMT):
I still think it might make sense, but don't have the expertise to push it. Perhaps part of the Core Message Protocol.
swcurran (Sat, 28 Jul 2018 00:17:13 GMT):
I still think it might make sense, but don't have the expertise to push it. Perhaps part of the Core Message Protocol discussion.
mhailstone (Sat, 28 Jul 2018 04:10:33 GMT):
Here is a draft of the slides I'll use to get our "Establishing Connections" topic started for the Agent2Agent vConference:
https://docs.google.com/presentation/d/1DwH0Q-PFpiUgMT-PwEOy2sRkmNG2bCKkw67Khe3u4os/edit?usp=sharing
Dominic (Mon, 30 Jul 2018 13:53:17 GMT):
Has joined the channel.
nage (Mon, 30 Jul 2018 14:14:55 GMT):
agent-summit-provo1.jpeg
nage (Mon, 30 Jul 2018 14:15:26 GMT):
agent-summit-provo2.jpeg
mhailstone (Mon, 30 Jul 2018 14:31:59 GMT):
https://docs.google.com/document/d/1Gt8tq6tXiQMcbEPyxtkz4q0_lzei5SLxfoKoB-VMuPQ/edit#
mhailstone (Mon, 30 Jul 2018 14:32:18 GMT):
https://drive.google.com/drive/folders/1Vof1CQDh2ZzSnuAP_vtn0vu5SPvCdNV_
nbouma (Mon, 30 Jul 2018 14:35:31 GMT):
Has joined the channel.
swcurran (Mon, 30 Jul 2018 14:36:50 GMT):
Scribe Notes for One-to-One Instant Messaging: https://docs.google.com/document/d/1plQ7GDC5Os1y9Xvx1vYarkfIgVAJNUViD4LhZpwpsuk/edit#
swcurran (Mon, 30 Jul 2018 14:37:43 GMT):
Presentation for session: https://docs.google.com/presentation/d/122dFhAqq5HtvT3c0idduOXn-eH64j4EiqBWOv_R8-z0/edit#slide=id.g3e56b70bb0_0_22
nage (Mon, 30 Jul 2018 14:47:07 GMT):
https://xmpp.org/rfcs/rfc3921.html
nage (Mon, 30 Jul 2018 14:47:07 GMT):
https://xmpp.org/rfcs/rfc3921.html#messaging
devin-fisher (Mon, 30 Jul 2018 14:54:58 GMT):
Is there an option for video conferencing?
devin-fisher (Mon, 30 Jul 2018 15:06:01 GMT):
Is there a link for a conference call?
n3m (Mon, 30 Jul 2018 15:08:51 GMT):
give me a sec
n3m (Mon, 30 Jul 2018 15:09:11 GMT):
https://byu.zoom.us/j/2627891784
n3m (Mon, 30 Jul 2018 15:09:18 GMT):
@devin-fisher
swcurran (Mon, 30 Jul 2018 15:18:56 GMT):
Slides for Transport: https://docs.google.com/presentation/d/1f8m9_g87oGie2jgU1Gb3F6HuxG0rgCAzQGANs8z3a_Q/edit#slide=id.p
nage (Mon, 30 Jul 2018 15:23:54 GMT):
agent-domains.jpeg
nage (Mon, 30 Jul 2018 15:24:36 GMT):
agent-domains2.jpeg
haggs (Mon, 30 Jul 2018 17:00:48 GMT):
https://docs.google.com/document/d/1dFmQ_5NlAIrCYx7AYvvEeYlyvzv-2u3cpQqWTadJbPA/edit# -> RSM Doc That Might Be Useful?
n3m (Mon, 30 Jul 2018 17:02:02 GMT):
https://github.com/sovrin-foundation/protocol/blob/master/relationship-state-machine.md
nage (Mon, 30 Jul 2018 17:16:50 GMT):
https://github.com/reputage/didery
dbluhm (Mon, 30 Jul 2018 17:42:27 GMT):
https://w3c-ccg.github.io/didm-veres-one/
Dominic (Mon, 30 Jul 2018 19:27:55 GMT):
Hi, I recently heard about indy-agent, and I'm trying to get a high-level overview understanding of what it does, and how it compares to indy-sdk.
I suppose my first question would be: Does indy-agent enforce the use of the sovrin network specifically, or is it general-purpose?
If it's general purpose, does it require a blockchain? If so, would it work with any blockchain (are there specific requirements for the blockchain), and if not, would it be technically be usable with something different (eg. a trusted database).
darrell.odonnell (Mon, 30 Jul 2018 19:54:10 GMT):
Clipboard - July 30, 2018 1:54 PM
darrell.odonnell (Mon, 30 Jul 2018 19:54:11 GMT):
regarding High/Low "Trust" Agents - I raised Canada's Pan-Canadian Trust Framework assurance levels.
darrell.odonnell (Mon, 30 Jul 2018 19:54:26 GMT):
That image is from here: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=30678§ion=HTML*
TelegramSam (Mon, 30 Jul 2018 21:59:12 GMT):
https://docs.google.com/document/d/1uFRBK5DIpqU_nTGSGytkNZvfeaBZ5jjgRhU930egvk8/edit#
kdenhartog (Mon, 30 Jul 2018 22:13:49 GMT):
https://medium.facilelogin.com/jwt-jws-and-jwe-for-not-so-dummies-b63310d201a3
nage (Mon, 30 Jul 2018 22:14:12 GMT):
jwt = jose.serialize_compact(jwe)
# 'eyJhbGciOiAiUlNBLU9BRVAiLCAiZW5jIjogIkExMjhDQkMtSFMyNTYifQ.SsLgP2bNKYDYGzHvLYY7rsVEBHSms6_jW-WfglHqD9giJhWwrOwqLZOaoOycsf_EBJCkHq9-vbxRb7WiNdy_C9J0_RnRRBGII6z_G4bVb18bkbJMeZMV6vpUut_iuRWoct_weg_VZ3iR2xMbl-yE8Hnc63pAGJcIwngfZ3sMX8rBeni_koxCc88LhioP8zRQxNkoNpvw-kTCz0xv6SU_zL8p79_-_2zilVyMt76Pc7WV46iI3EWIvP6SG04sguaTzrDXCLp6ykLGaXB7NRFJ5PJ9Lmh5yinAJzCdWQ-4XKKkNPorSiVmRiRSQ4z0S2eo2LtvqJhXCrghKpBNgbtnJQ.Awelp3ryBVpdFhRckQ-KKw.1MyZ-3nky1EFO4UgTB-9C2EHpYh1Z-ij0RbiuuMez70nIH7uqL9hlhskutO0oPjqdpmNc9glSmO9pheMH2DVag.Xccck85XZMvG-fAJ6oDnAw'
nage (Mon, 30 Jul 2018 22:58:36 GMT):
lets not repeat this mistake of the past https://en.wikipedia.org/wiki/Object_identifier
nage (Mon, 30 Jul 2018 22:59:31 GMT):
(specifically this is painful https://www.hl7.org/oid/)
drummondreed (Tue, 31 Jul 2018 03:13:27 GMT):
GREAT point @nage. ++++1
danielhardman (Tue, 31 Jul 2018 04:22:04 GMT):
+1 to @nage's point
danielhardman (Tue, 31 Jul 2018 04:23:33 GMT):
@nage and @kdenhartog : I've been thinking more deeply about the correlation risk that you described earlier today, and it is becoming somewhat more concerning to me now that it felt to me at first. I hope we have a chance to explore in more detail tomorrow.
RuWander (Tue, 31 Jul 2018 08:33:25 GMT):
Has joined the channel.
dbluhm (Tue, 31 Jul 2018 12:17:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=rm7N3pZXDe4dWNezD) @danielhardman I'm also really looking forward to this discussion
mhailstone (Tue, 31 Jul 2018 14:12:14 GMT):
Agent vConference
https://byu.zoom.us/j/2627891784
danielhardman (Tue, 31 Jul 2018 14:38:51 GMT):
I mentioned customercommons.org. Here's a related document that explains the concept: https://docs.google.com/document/d/1Wf7kaXRn85pSEy8kKiX7GsVmZ295x_HbX5M0Ddu7D1s/edit
nage (Tue, 31 Jul 2018 15:05:18 GMT):
For more correlation thinking visit https://panopticlick.eff.org/ and ponder uniqueness and profiling
TelegramSam (Tue, 31 Jul 2018 15:08:52 GMT):
Ducking out of call for 90 minutes for a prior commitment.
nhelmy (Tue, 31 Jul 2018 15:41:28 GMT):
Does anyone have the new DID doc that @drummondreed just presented out
nhelmy (Tue, 31 Jul 2018 15:41:28 GMT):
Does anyone have the new DID google doc writeup that @drummondreed just presented out
drummondreed (Tue, 31 Jul 2018 16:18:04 GMT):
@nhelmy Just to clarify, this Google doc is a writeup of how to use a DID reference to identify a digital object like a spec. https://docs.google.com/document/d/1t-AsCPjvERBZq9l-iXn2xffJwlNfFoQhktfIaMFjN-c/edit?usp=sharing
drummondreed (Tue, 31 Jul 2018 16:18:24 GMT):
This the doc I showed in the Agent Workshop this morning.
danielhardman (Tue, 31 Jul 2018 17:26:33 GMT):
Ticket about pack_msg(): https://jira.hyperledger.org/browse/IS-855
nhelmy (Tue, 31 Jul 2018 17:27:03 GMT):
@drummondreed thanks for the clarity--didn't realize i replicated a term used in a different context
esplinr (Tue, 31 Jul 2018 18:34:53 GMT):
I'm still at the tire shop. It sounds like my car is almost done.
esplinr (Tue, 31 Jul 2018 18:34:56 GMT):
Has Ryan already presented today? He put together an end-to-end demo of LibVCX to give you a better overview then you had yesterday.
dbluhm (Tue, 31 Jul 2018 19:28:12 GMT):
I missed a chunk of this morning but as far as I know, Ryan has not presented today, @esplinr
danielhardman (Tue, 31 Jul 2018 21:55:26 GMT):
DID for messages invented and governed by this group: did:sov:BzCbsNYhMrjHiqZDTUASHg
kdenhartog (Tue, 31 Jul 2018 21:59:22 GMT):
https://github.com/sovrin-foundation/launch/blob/master/sovrin-keygen.zip
danielhardman (Tue, 31 Jul 2018 22:00:49 GMT):
(Kyle's message identifies a simple tool that anyone can download to create DIDs and keys. It's just a zip file that contains an html page that you can load in an offline browser. The html references a single .js file (tweetnacl) that implements libsodium primitives.)
nage (Tue, 31 Jul 2018 22:16:04 GMT):
The proposal at RWOT for variable length schemas https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/topics-and-advance-readings/AttributeBasedCredentials_and_VariableLengthDataGraphs.md
nage (Tue, 31 Jul 2018 22:17:30 GMT):
the working draft https://docs.google.com/document/d/1njvX4U7Q-2trvqrTZQQynSCgU3JgxDLXESvb34hYhI0/edit
nage (Tue, 31 Jul 2018 22:17:47 GMT):
(was never finished)
peacekeeper (Tue, 31 Jul 2018 22:44:00 GMT):
Many greetings from the Decentralized Web Summit, hope you're having a productive day in Provo.
kdenhartog (Tue, 31 Jul 2018 22:52:54 GMT):
https://github.com/sovrin-foundation/protocol/blob/1a706c94c50d9ecf95ff014b03842d18645add1a/themis/schema.md
esplinr (Wed, 01 Aug 2018 00:32:05 GMT):
It was a really interesting day. Thank you to the team who organized the workshop. And thanks for representing us at DWS @peacekeeper.
mhailstone (Wed, 01 Aug 2018 15:25:29 GMT):
All,
Here are the links to the folders for the Agent2Agent vConference/Workshop/Summit for Monday July 30th and Tuesday July 31st:
Monday July 30th:
https://drive.google.com/drive/folders/1qJbS9vn5nMKuM5NboepJ_ZIC2ZbF2jwn
Tuesday July 31st:
https://drive.google.com/drive/folders/12oXEaL-wn5VsnGENaeV7lepDrM_mAKCh
It was an excellent two days of discussion and decisions! Thanks to all who participated online and in person.
dbluhm (Wed, 01 Aug 2018 16:34:04 GMT):
I don't recall whether we officially established what would be going in our interim jose header that is tacked onto the front of messages packed up for the wire
n3m (Wed, 01 Aug 2018 17:09:38 GMT):
@TelegramSam and @kdenhartog said they are going to create a proposal for that, and present it to us
haggs (Wed, 01 Aug 2018 18:54:28 GMT):
Thank you @mhailstone and BYU for hosting and everyone for the excellent and invigorating discussion!
mhailstone (Wed, 01 Aug 2018 21:26:53 GMT):
All,
We will still have a Friday Agent call this week. Thanks to the great collaboration of those involved, we made some amazing headway.
Agenda
- Summary of Decisions made at Agent 2 Agent Workshop
Topic: Indy Agent Design/Discussion
Time: Aug 3, 2018 7:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
dbluhm (Wed, 01 Aug 2018 23:20:41 GMT):
I submitted a PR with a cleaned up version of the test suite I demoed at the Agent vConference/Agent 2 Agent Workshop. I reassert that it's not complete but hopefully it will be a good starting point.
dbluhm (Wed, 01 Aug 2018 23:20:41 GMT):
I submitted a PR with a cleaned up version of the test suite I demoed at the Agent vConference/Agent 2 Agent Workshop to the indy-agent repository. I reassert that it's not complete but hopefully it will be a good starting point.
dbluhm (Wed, 01 Aug 2018 23:21:22 GMT):
@mhailstone, please review my PR and make comments as you see fit :slight_smile:
danielhardman (Thu, 02 Aug 2018 15:44:29 GMT):
Here is a link to the notes I wrote up from our agent summit: http://bit.ly/2KkdWjE
danielhardman (Thu, 02 Aug 2018 15:44:41 GMT):
(This doc is is the same Indy folder as the recordings)
mhomaid (Thu, 02 Aug 2018 15:54:02 GMT):
Has joined the channel.
swcurran (Thu, 02 Aug 2018 19:28:50 GMT):
@danielhardman - did you go over the document in detail on the call today? Or put another way - I've got a presentation for tomorrow for the Agent Call. Is it worth doing or was the detail deep enough today?
jljordan_bcgov (Thu, 02 Aug 2018 19:47:18 GMT):
Is the agent call 7am Mountain or Pacific?
swcurran (Thu, 02 Aug 2018 19:55:45 GMT):
7am Pacific.
danielhardman (Thu, 02 Aug 2018 20:00:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=5bGntyCYAoLRRSGzr) @swcurran I didn't go over the doc in detail. I spent about 2 min saying things like "We found some tickets that we needed to write, and others that we needed to prioritize higher; see my doc for more details." So a deeper dive may be profitable. (I will be at a funeral tomorrow, BTW, so will miss the meeting...)
danielhardman (Thu, 02 Aug 2018 20:00:52 GMT):
Reviewing the doc may be profitable for another reason, as well: my notes may not be a complete or an accurate capture. It would be good for others who attended the summit to check that.
swcurran (Thu, 02 Aug 2018 20:14:35 GMT):
OK - I'll keep going. I'm collating mine, Matthew's and I'll include yours in the summary. We can use the presentation to drive discussion as always. This is not a group of passive listeners :-). Updates to the presentation can be made as we go.
swcurran (Thu, 02 Aug 2018 20:14:35 GMT):
OK - I'll keep going. I'm collating mine, Matthew's and (now) yours in the summary. We can use the presentation to drive discussion as always. This is not a group of passive listeners :-). Updates to the presentation can be made as we go.
jljordan_bcgov (Thu, 02 Aug 2018 20:27:39 GMT):
@mhailstone says 7am Mountain in the message above
swcurran (Thu, 02 Aug 2018 21:32:48 GMT):
Arrggh...OK. I guess we'll have to go with 7AM Mountain time since this has gone out on multiple channels. Matthew is away, so not even sure we can change the time - we're using his Zoom channel.
jljordan_bcgov (Thu, 02 Aug 2018 21:34:08 GMT):
Hmm .. better connect with @Sean_Bohan since he sent a message on https://sovrin.slack.com/archives/C1BMH6FGD/p1533242637000190 with 7am Pacific
jljordan_bcgov (Thu, 02 Aug 2018 21:34:15 GMT):
I'm just the messenger
jljordan_bcgov (Thu, 02 Aug 2018 21:35:06 GMT):
looks like an open zoom room .. I just connected to it
jljordan_bcgov (Thu, 02 Aug 2018 21:35:32 GMT):
and normal time is 7am pacific ..
jljordan_bcgov (Thu, 02 Aug 2018 21:35:38 GMT):
so maybe he just made a typo?
swcurran (Thu, 02 Aug 2018 21:41:12 GMT):
*Folks *- there was a typo in the message above from Matthew about tomorrow's agent call. The call tomorrow is at 7AM Pacific, 8AM Mountain and so on. That is - the call time is the same time as it has been for all the calls.
Here is the corrected announcement:
```
All,
We will still have a Friday Agent call this week. Thanks to the great collaboration of those involved, we made some amazing headway.
Agenda
- Summary of Decisions made at Agent 2 Agent Workshop
Topic: Indy Agent Design/Discussion
Time: Aug 3, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
```
swcurran (Thu, 02 Aug 2018 21:41:12 GMT):
*Folks *- there was a typo in the message above from Matthew about tomorrow's agent call. The call tomorrow is at *7AM Pacific, 8AM Mountain* and so on. That is - the call time is the same time as it has been for all the calls.
Here is the corrected announcement:
```
All,
We will still have a Friday Agent call this week. Thanks to the great collaboration of those involved, we made some amazing headway.
Agenda
- Summary of Decisions made at Agent 2 Agent Workshop
Topic: Indy Agent Design/Discussion
Time: Aug 3, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
```
burdettadam (Thu, 02 Aug 2018 22:21:22 GMT):
un-official libvcx documentation https://burdettadam.github.io/sdk/vcx/libvcx/doc/vcx/
I ran `cargo doc --no-deps`.
dbluhm (Thu, 02 Aug 2018 22:39:45 GMT):
The test suite has been merged into indy-agent. In the near future, it would be great to start splitting up tasks in the community to implement tests for protocol explained HIPEs and that were discussed during the agent conference.
dbluhm (Thu, 02 Aug 2018 22:39:45 GMT):
The test suite has been merged into indy-agent. In the near future, it would be great to start splitting up tasks in the community to implement tests for protocol explained in HIPEs and that were discussed during the agent conference.
RubenLassau-Strauven (Fri, 03 Aug 2018 07:21:06 GMT):
Has joined the channel.
Aschi (Fri, 03 Aug 2018 07:23:11 GMT):
Has joined the channel.
zickau (Fri, 03 Aug 2018 09:59:02 GMT):
Has joined the channel.
dbluhm (Fri, 03 Aug 2018 14:26:57 GMT):
https://docs.google.com/presentation/d/1l-po2IKVhXZHKlgpLba2RGq0Md9Rf19lDLEXMKwLdco/edit
Slides that @swcurran shared in the call this morning summarizing the A2A vConference
json (Fri, 03 Aug 2018 14:28:00 GMT):
Hi everyone. Trying to get agent working on my windows PC. I installed the prerequisites but `npm install` isn't working, I get this error: ```Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
indy.cc
win_delay_load_hook.cc
c:\users\t925489\documents\blockchain\indy-agent\nodejs\node_modules\nan\nan_new.h(208): warning C4244: 'argument': conversion from 'unsigned __int64' to 'double', possible loss of data (compiling source file ..\src\indy.cc) [C:\Users\T925489\Docu
ments\Blockchain\indy-agent\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj]
..\src\indy.cc(231): note: see reference to function template instantiation 'v8::Local
json (Fri, 03 Aug 2018 14:28:16 GMT):
Any ideas what I might be doing wrong?
dbluhm (Fri, 03 Aug 2018 14:45:00 GMT):
https://github.com/sovrin-foundation/launch/blob/master/sovrin-keygen.zip
From Agent call chat. Can be used to generate your DID and keys.
dbluhm (Fri, 03 Aug 2018 14:45:24 GMT):
@saholman ^^ Any thoughts on @json 10's error?
swcurran (Fri, 03 Aug 2018 15:20:31 GMT):
Best answer is to use docker - don't build things natively :-). Doesn't help with this error, but will be a huge help going forward.
dbluhm (Fri, 03 Aug 2018 15:21:40 GMT):
I didn't want to keep anyone any longer on the call but I had a couple of thoughts I wanted to propose to those looking to use the agent test suite. As I understand things, it seems like we need some way to trigger actions from the agent test suite in the agent being tested. As an example, in establishing a connection, we want to verify that the tested agent can initiate as well as reciprocate in that process. My first thought was to implement this as another module and message family that was used only for testing. @swcurran @saholman @TelegramSam
dbluhm (Fri, 03 Aug 2018 15:21:40 GMT):
I didn't want to keep anyone any longer on the call but I had a couple of thoughts I wanted to propose to those looking to use the agent test suite. As I understand things, it seems like we need some way to trigger actions from the agent test suite in the agent being tested. As an example, in establishing a connection, we want to verify that the tested agent can initiate as well as reciprocate in that process. My first thought was to implement this as another module and message family that was used only for testing. @swcurran @saholman @TelegramSam Do you have thoughts to share about that? If we feel like this is a good idea, I'll propose a HIPE detailing the message family and how it would work
swcurran (Fri, 03 Aug 2018 15:31:05 GMT):
@dbluhm - I'd like to go through the Agent Test Suite and perhaps have some discussions and google docs spec'ing on how to keep building this before we do HIPEs. I think we need the big picture first and I don't have it yet. I'd like to maybe have a call or two next week to discuss this with you.
dbluhm (Fri, 03 Aug 2018 16:52:18 GMT):
I revised the [message type hipe](https://github.com/hyperledger/indy-hipe/pull/19) to reflect our discussions from the Agent Summit. Links to the various notes and presentations at the summit are linked to in the "References" section. Please review and add your comments as you see fit. We hope to have this and other HIPEs up for FCP (Final Comment Period) soon.
dbluhm (Fri, 03 Aug 2018 16:52:18 GMT):
I revised the [message type HIPE](https://github.com/hyperledger/indy-hipe/pull/19) to reflect our discussions from the Agent Summit. Links to the various notes and presentations at the summit are linked to in the "References" section. Please review and add your comments as you see fit. We hope to have this and other HIPEs up for FCP (Final Comment Period) soon.
dbluhm (Fri, 03 Aug 2018 23:23:40 GMT):
I created a HIPE detailing the idea of [message threading](https://github.com/dbluhm/indy-hipe/blob/message-threading/text/message-threading/README.md). Please review and add your comments.
I saw this HIPE as a prerequisite to a revised connection HIPE; more revisions to come.
saholman (Fri, 03 Aug 2018 23:28:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Gp2maJBq4Jjjnc8ke) @json 10 If your running on windows, I think @swcurran is right. Things are going to be a lot simpler using docker. If you aren't familiar with docker or you really want to run it natively, just install docker and run `docker run -it -p 3000:3000 ubuntu` and then follow the getting started guide inside the ubuntu container.
saholman (Fri, 03 Aug 2018 23:28:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=4eaCw56MZP5irZ2v4) @dbluhm Thanks for all of your work getting these hipes updated!
danielhardman (Sat, 04 Aug 2018 03:13:56 GMT):
I didn't get time to work on agent stuff today as would have been desirable. However, I wanted to share a spreadsheet that I worked up, that analyzes connections as a state machine. This has bearing on the HIPE from @RyanWest (PR #18). I think it is largely compatible with his vision, but there are some subtleties worth discussing. Specifically: I have eliminated the ACK and ACK ACK. This is because I think any messages that flow after the connection is made accomplish the same purpose, without us allocating a special message type and special message send for them (e.g., if I immediately sent a proof request after establishing a connection, the same knowledge would be gained). Also, I think the ACKs tell us less than we'd suppose, since any connection can decay as soon as a message is sent. Also, I'm assuming the notion of negotiation back-and-forth (request and offer and request and offer...) until both parties are satisfied, even though I don't imagine most connections will negotiate much. And I'm accepting the reality that each party may have a different view of the connection's state, so I'm only trying to model the view on one side.
Maybe we can discuss in next week's agent meeting, or I can record a 10-min video where I walk through my thinking...
https://docs.google.com/spreadsheets/d/1RLJhhlWCUBYpKn18S5BGi7HH9MfGiZdHBxKjsJavoMs/edit?usp=sharing
TelegramSam (Sat, 04 Aug 2018 12:03:14 GMT):
Interim JOSE header: https://docs.google.com/document/d/1NVPXeEAFTYX8SZRLqfNGl0NCZ5GWbEhgFWtesCILxa8/edit#
TelegramSam (Sat, 04 Aug 2018 12:03:44 GMT):
The intent is to add that to the appropriate HIPE designating interim use.
swcurran (Sun, 05 Aug 2018 22:01:08 GMT):
I've update the Transport Protocol HIPE per discussions from last week. @TelegramSam I included in that the text from the JOSE header google doc above. The HIPE covers three things - Wire Messages, the Routing message type "Forward" and the assumptions that a domain will make about another domain (e.g. existence and use of shared, untrusted Domain Endpoint and Routing Agent).
Changes are here: https://github.com/hyperledger/indy-hipe/pull/21/commits/35c9a8fda2011763d85df2a57bccc67bcdc28760
I've reworked it to where we have arrived, but it's still (IMHO) too long, as it is explaining a lot. It might be necessary if it was cut down to just the facts.
brmatt (Mon, 06 Aug 2018 03:41:24 GMT):
Has joined the channel.
bsuichies (Mon, 06 Aug 2018 09:54:39 GMT):
Has joined the channel.
esplinr (Mon, 06 Aug 2018 19:00:46 GMT):
I forget who it was that asked me for a libvcx demo. It's about 20 minutes into last week's Indy Working Group call:
https://drive.google.com/open?id=1xdIUvqmZ7qsCuJvv5UtY0tz3m8YUtlVa
dbluhm (Mon, 06 Aug 2018 19:05:08 GMT):
@danielhardman I'm looking through your spreadsheet about connections and watching your accompanying video as well. Thanks for putting those together. You focused more on the transitions from one state to the next rather than what is transmitted with each step so I wanted to paraphrase what I interpreted and get your feedback to make sure I was on the same page:
Alice initiates a connection with Bob:
1. Alice sends an out of band invitation to Bob.
2. Bob accepts the invitation, proposing a DID and key to be used. (I'm not sure I understood this correctly but that is what I interpreted from your assumption: "The invitation phase ends when the initiating (inviting) party is contacted and is able to transmit a Connection Request that is A2A encrypted with the DID+key they propose to use.")
3. Alice sends a Connection Request to Bob using the information provided by Bob when he accepted the invitation.
4. Bob sends a "Connection Outcome" to Alice, notifying of acceptance or rejection. (Is anything else transmitted here?)
danielhardman (Mon, 06 Aug 2018 21:05:55 GMT):
drummond
danielhardman (Mon, 06 Aug 2018 23:20:51 GMT):
@dbluhm Thanks for taking the time to digest what I created. The way you've summarized it is very close to the way I think about it, but there is a slight difference related to how the invitation phase is managed.
The party that receives the invitation (Bob) may already have an agent and a bunch of sovrin-enabled capabilities, or may have nothing but a cell phone or email client. If the latter, then we need a way to supply the missing capabilities. This is the flow that I call "onboarding", and which I want to think about as being distinct from connection flow. Let's assume that if onboarding is needed, Bob can start from the invitation he receives, and go all the way to having an edge agent (app on his phone) plus a cloud agent at an agency, in what feels to him like a single step taking only a few seconds. Once this is done, Bob is now in the state of any other invited person in the ecosystem: he has an invitation, and he has Sovrin capabilities, but he has not allocated any resources or a DID+keys yet, to manage the relationship that will be built if he pursues the invitation.
danielhardman (Mon, 06 Aug 2018 23:20:51 GMT):
@dbluhm Thanks for taking the time to digest what I created. The way you've summarized it is very close to the way I think about it, but there is a slight difference related to how the invitation phase is managed.
The party that receives the invitation (Bob) may already have an agent and a bunch of sovrin-enabled capabilities, or may have nothing but a cell phone or email client. If the latter, then we need a way to supply the missing capabilities. This is the flow that I call "onboarding", and which I want to think about as being distinct from connection flow. Let's assume that if onboarding is needed, Bob can start from the invitation he receives, and go all the way to having an edge agent (app on his phone) plus a cloud agent at an agency, in what feels to him like a single step taking only a few seconds. Once this is done, Bob is now in the state of any other invited person in the ecosystem: he has an invitation, and he has Sovrin capabilities, but he has not allocated any resources or a DID+keys yet, to manage the relationship that will be built if he pursues the invitation.
danielhardman (Mon, 06 Aug 2018 23:21:28 GMT):
More coming... (accidentally hit Return)... hold on...
danielhardman (Mon, 06 Aug 2018 23:21:28 GMT):
So the invited party (Bob) needs to allow the inviter (Alice) to send him a Connection Request. He could do this by allocating a DID and keys himself, and sending Alice information about the DID he has allocated to receive her CR. But that would mean he's spending his own resources before he even hears what Alice proposes for this relationship.
What I imagined instead, in this particular incarnation of the state machine, is that Bob fetches Alice's CR from a URL she has designated in the invitation. Alice's CR contains her own DID+keys, and Bob can then either ignore the CR, or allocate a DID+keys and reply to Alice's CR over traditional A2A channels--either sending a connection outcome message ("I accept") or a Connection Offer that is a counter-offer ("You said you wanted to be friends forever and tell each other all our secrets. How about if we're just friends for 10 minutes, and you promise to delete all my data when we're done with this eBay transaction?"). Thus, the fact that Alice was able to deliver the CR (whether or not it passed over A2A channels) is the event that puts the relationship in the "negotiation" phase from Alice's perspective.
danielhardman (Mon, 06 Aug 2018 23:29:10 GMT):
Either way, any negotiation messages and the final outcome message from the connection flow are passed over A2A channels.
danielhardman (Mon, 06 Aug 2018 23:29:51 GMT):
We could imagine a different state machine, in which Bob always provides a DID+keys at the end of the invitation phase, and then Alice transmits A2A-style to Bob. This asks Bob to take more on faith.
danielhardman (Mon, 06 Aug 2018 23:30:44 GMT):
If we get lots of connection spam, I think it would be nice not to have to allocate a DID and keys before we see the other party's Connection Request and reject it.
danielhardman (Tue, 07 Aug 2018 13:20:51 GMT):
I'm thinking about putting the following content into a new HIPE about a "direct response mode" where A2A can take advantage of HTTP request/response semantics. Wanted to get community reaction first... https://docs.google.com/document/d/1w08h7bOXC2U_IxnQRvEaeu3tPDKplujX5sXKPDchbGs/edit#
dbluhm (Tue, 07 Aug 2018 15:20:08 GMT):
@danielhardman out of curiosity, why not call the "connection outcome" a "connection response"?
dbluhm (Tue, 07 Aug 2018 15:28:19 GMT):
Thanks for your explanation; that makes more sense to me now.
dbluhm (Tue, 07 Aug 2018 15:47:38 GMT):
Just drawing some more connections, this sounds similar to the idea @kdenhartog brought up during the agent summit of introduction "deaddrops" or using an agency to store the connection request that can be found using a nonce. The nonce would then be part of the url sent in the invitation.
dbluhm (Tue, 07 Aug 2018 15:47:38 GMT):
Just drawing some more connections, this sounds similar to the idea @kdenhartog brought up during the agent summit about introduction "deaddrops" or using an agency to store the connection request that can be found using a nonce. The nonce would then be part of the url sent in the invitation.
kdenhartog (Tue, 07 Aug 2018 17:47:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=qF2BJnCyDQmC4yucE) we could break it out to 3 separate HIPEs: Wire Messages, Forward Messages, Domains. Thoughts?
danielhardman (Tue, 07 Aug 2018 17:49:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cgsi6EWcrcnqw2Mja) @dbluhm All messages other than the first one are responses, in some sense. The word "outcome" is a specific kind of response that moves the interaction to a terminal state.
danielhardman (Tue, 07 Aug 2018 17:49:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cgsi6EWcrcnqw2Mja) @dbluhm All messages other than the first one are responses, in some sense. The word "outcome" is a specific kind of response that moves the interaction to a terminal state. Also, consider other flows like credential issuance and proof presentation. The final message in these sequences is a "credential" or a "proof", not a "credential response" or a "proof response". So I am using "outcome" as a category of messages that may have 2 members of the category: a "Connection Acceptance" message and a "Connection Rejection" message. Both are connection outcomes. Both are responses. But I like calling them outcomes as opposed to generic responses.
danielhardman (Tue, 07 Aug 2018 17:53:44 GMT):
(It could also be possible that acceptance and rejection are both expressed with a single message type. The name for such a message type would be "Connection Outcome", probably. I don't care which we do. I'm just using outcome in its generic sense here, not making a strong claim about what to call specific JSON structures.
danielhardman (Tue, 07 Aug 2018 18:01:27 GMT):
I have been working on some ideas about how to report errors in A2A comms. They are coherent enough to share; if people like them, I will put them in HIPE form: https://docs.google.com/document/d/1PJJoPGOFkgsGWfJwmLhjVgH1CyjDgDskZTzxN3D35Oo/edit?usp=sharing
TelegramSam (Tue, 07 Aug 2018 20:59:09 GMT):
@danielhardman Super good thinking. I'm thinking now about which of these error types are low hanging fruit, and if errors are a message family of their own (leaning this way) or should be defined within a family.
dbluhm (Tue, 07 Aug 2018 21:24:47 GMT):
@danielhardman this is getting down into the details again but I'm thinking about negotiation about the connection between Alice and Bob. Say we're to the point where Bob has received Alice's Connection Request. My first assumption that may need to be corrected is that Alice doesn't yet know how to communicate with bob over A2A encryption and routing. That then implies that Bob needs to transmit the pieces of information Alice needs as part of his connection counteroffer. Are we on the same page?
dbluhm (Tue, 07 Aug 2018 21:29:06 GMT):
Would Bob then go ahead and generate a DID and key pair for the relationship so that Alice can then communicate back to Bob? (this seems to mean that Bob essentially accepts the connection which doesn't seem right...) Or would the messages exchanged to negotiate the connection be held on temporary communication channels? Or is everything just in plain text once it is off the wire?
rmarsh (Tue, 07 Aug 2018 21:37:17 GMT):
Has joined the channel.
danielhardman (Tue, 07 Aug 2018 22:26:23 GMT):
@dbluhm My assumption has been that the Connection Request must include information about where to respond to the inviter (Alice) in A2A fashion. If Bob is uninterested in connecting, he can ignore the CR and not allocate a DID. If, on the other hand, he has at least moderate interest in connecting, he has 2 choices. Both require him to allocate a DID+keys+endpoint and respond in A2A fashion with a message that communicates his side of the connection; one response is an acceptance, and the other is a counter offer.
danielhardman (Tue, 07 Aug 2018 22:41:49 GMT):
@TelegramSam What I'd been thinking is that groups (e.g., Sovrin Foundation, HL, etc) could define/publish/maintain/curate a catalog of error codes. Imagine some list at a URL like http://sovrin.org/a2a-specs/error-codes that returns a doc like this (where each `code` is given a `friendly-text` and possibly has comments about what other fields of the message are used:
```unsupported-crypto: The sender used a crypto library that the receiver doesn't support. Supported encryption libraries are identified in the fix-hint message property.
wont-talk-to-anonymous: The sender used anon-encrypt, but the receiver's policy requires the sender to identify itself.
missing-message-in-thread: The receiver saw message N in a thread, but missed message N-1, N-2, etc. Some or all of the missing message numbers are enumerated in problem-items message property.
unrecognized-message-type: The message type that was received is not one that the receiver knows how to handle.```
... and so forth
There wouldn't be separate message types or message families for the `problem-report` messages--there'd just be that one type. Since almost all its message properties are optional, we could add new properties to it while remaining backward compatible. This would let us communicate about a very broad range of problems in a very flexible way, without lots of message types. The more I thought about errors, the less I liked the traditional approach where error messages are super tightly defined--because I think A2A interactions will rarely have the same coder/team on both sides of the interaction, so we need to maximize flexibility.
I don't know if my way of thinking is the ideal one, so I'm not arguing for it very hard. I'm just trying to describe it so we can discuss further.
danielhardman (Tue, 07 Aug 2018 22:41:49 GMT):
@TelegramSam What I'd been thinking is that groups (e.g., Sovrin Foundation, HL, etc) could define/publish/maintain/curate a catalog of error codes. Imagine some list at a URL like http://sovrin.org/a2a-specs/error-codes that returns a doc like this (where each `code` is given a `friendly-text` and possibly has comments about what other fields of the message are used:
```unsupported-crypto: The sender used a crypto library that the receiver doesnt support. Supported encryption libraries are identified in the fix-hint message property.
wont-talk-to-anonymous: The sender used anon-encrypt, but the receivers policy requires the sender to identify itself.
missing-message-in-thread: The receiver saw message N in a thread, but missed message N-1, N-2, etc. Some or all of the missing message numbers are enumerated in problem-items message property.
unrecognized-message-type: The message type that was received is not one that the receiver knows how to handle.```
... and so forth
There wouldn't be separate message types or message families for the `problem-report` messages--there'd just be that one type. Since almost all its message properties are optional, we could add new properties to it while remaining backward compatible. This would let us communicate about a very broad range of problems in a very flexible way, without lots of message types. The more I thought about errors, the less I liked the traditional approach where error messages are super tightly defined--because I think A2A interactions will rarely have the same coder/team on both sides of the interaction, so we need to maximize flexibility.
I don't know if my way of thinking is the ideal one, so I'm not arguing for it very hard. I'm just trying to describe it so we can discuss further.
mero (Wed, 08 Aug 2018 10:33:17 GMT):
Has joined the channel.
Christian (Wed, 08 Aug 2018 10:43:26 GMT):
Has joined the channel.
TelegramSam (Wed, 08 Aug 2018 11:05:16 GMT):
It's good thinking. I love the idea that there is one error type (or just a few) to make development and debugging easier.
swcurran (Wed, 08 Aug 2018 15:44:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tsBfH5FfhajT7HnN4) @danielhardman @danielhardman - finally catching up on things after holiday Monday and feeling a bit off the last few days. Getting better.
I love the RSM for the establishment flow - very cool!
One thing that threw me off was the same person sending the invite and the connReq. Shouldn't the State Machine have another state ("They answered invite") and another event (perhaps "InviteAccepted") to handle that? Alice needs a trigger to send the connReq, as well as (I think) some information obtained from the trigger in order to send the connReq.
swcurran (Wed, 08 Aug 2018 15:44:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tsBfH5FfhajT7HnN4) @danielhardman - finally catching up on things after holiday Monday and feeling a bit off the last few days. Getting better.
I love the RSM for the establishment flow - very cool!
One thing that threw me off was the same person sending the invite and the connReq. Shouldn't the State Machine have another state ("They answered invite") and another event (perhaps "InviteAccepted") to handle that? Alice needs a trigger to send the connReq, as well as (I think) some information obtained from the trigger in order to send the connReq.
swcurran (Wed, 08 Aug 2018 16:20:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=PWgscQqNZi9zYy6dk) @danielhardman Wow...that's a lot of detail - all good and valid. I am definitely just an observer here - I'm not hands on in dealing with this issue.
I have two opposing reactions to it. On the one hand, when one is trying to sort out errors, all that information should be extremely useful. On the other - it might be really hard to populate all of that information for each error that might occur. Thus - helpful for the developer and painful for the developer. :-)
It's a given that we have to have a formal set of error codes - I'm thinking at minimum like HTTP - and since the A2A protocol is both async and at a much higher level than HTTP, by definition, the error handling will have to be more thorough. Given the way we are defining message types (did;spec) and publishing specifications for them, I really like the idea of doing something similar here - as you have described. Perhaps the error handling should be a message Family (Error) and a set of Error Types, with attributes based on the error (message) type? That gives us a good way to define and specify arguments for each error.
Alternative - that each message family include a set of error message types that relate to the message family. A HIPE like this would define the guidelines to use and perhaps some common errors, but the specific error message types would be built along side the family.
And of course the middle ground is more the decorator model. A family of "core" error messages that all could use, and then leave it to each family to define and use additional message types specific to what the family has implemented. The HIPE includes guidelines and an initial (and subsequently growing) list of core error messages, with guidelines on building out family-specific error messages. In all cases, the "did;spec/" protocol MUST point to the published error message specification.
kdenhartog (Wed, 08 Aug 2018 16:56:37 GMT):
In my short experience pen testing, error codes revealed the most information about a system when I was first discovering the landscape of the system. This is something that can be used to correlate and reduce privacy. Generic codes that are vague about problems are actually very useful for preventing fingerprinting of the domain/agents. On the other hand, we definitely need valuable error codes to help developers resolve their problems. My suggestion is that we add some sort of tier system to the error codes depending on the trust level of the connection. As an example, an agent that's trying to setup an agent at the beginning will get error: connection failed and that's about it. Where as an agent that has a connection, but hasn't exchanged creds shouldn't be treated the same as an agent that has exchanged creds and established trust, or has maintained a persistent connection for a long time. In terms of what the criteria for these errors are I really haven't thought in depth about it yet. For an example of how errors are abused today, check this out: https://nilminus.wordpress.com/web-application-penetration-testing/information-gathering-2/testing-for-error-code/
haggs (Wed, 08 Aug 2018 17:43:28 GMT):
I agree that error codes can reveal way too much. In the case of HTML 1.1 you can even sometimes get a whole stack of errors that reveals OS, Webserver, etc.
haggs (Wed, 08 Aug 2018 17:44:43 GMT):
I know for example the US Bank portal uses a generic "Unknown Error Occurred" for almost everything, including no connection to internet, wrong password, wrong id, id not found, etc.
haggs (Wed, 08 Aug 2018 17:57:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=6txLdfcu6RMyErTzt) This will be tricky to create the levels of tiers, these should definitely be in a standard message structure and we should be careful even when and if we update that error message structure and that it's done at the same time, same latency/timeout for all agents (as to not reveal how long it took which might indicate the size of your database, compute power, etc), etc. I think a large part of this will be implementation prescription for agents as I see this exploit something someone could easily not think of when developing along with thoughtful considerations of the different tiers. I don't have any solutions to offer, only agreeing, but I'll think about the tiered system.
haggs (Wed, 08 Aug 2018 19:02:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=5EWsDEFqsR7TG6g2B) @swcurran This is a tough call and as well I'm just a mere observer, but to add to this I think the "helpful for the developer and painful for the developer" is dual-fold decision.
a) Given, as you mentioned, the much more thorough set of errors and verbosity of error codes that A2A will have to handle, and knowing even at the HTTP 1.1 level most developers consistently mess up or don't follow (because it's confusing and hard!) the RFC7231 spec for error handling (https://hackernoon.com/correct-error-handling-is-hard-307ea72759c7) I think expectations for guiding developer implementation or simply won't be followed or too confusing for someone just trying to make something. However, I completely see the other opposing reaction and populating the information problem...
b) Going off of the _assumption_ that some developers won't use them correctly (based on HTML 1.1 historical problems), that gives way to the issues @kdenhartog brought up about correlation and fingerprinting that could be big attack vectors.
So in that case, I'm torn as well and think the middle ground or the first option your presented make more sense to me. However I'm merely speculating here and adding things that might be food for thought, as an observer.
kdenhartog (Wed, 08 Aug 2018 19:09:49 GMT):
What if we did something like a Debug error mode and a production error mode where if Debug mode is enabled very verbose errors are used, and production error mode keeps things to a minimum? This is definitely going to be a hard challenge to balance because I can see both sides as having valid reasons to support them. I'll keep thinking on this to see if I come up with any other ideas.
swcurran (Wed, 08 Aug 2018 21:37:13 GMT):
We're looking for a topic for the agent meeting on Friday. I'm not able to lead the meeting, but will be there - I have to call from a place I can't talk a lot.
My thoughts:
* Connection Establishment - reviewing Daniel's spreadsheet and adding data - what are the messages, what might the (implementation specific) connection events look like?
* HIPE Status - any reorgs - particularly - what to do with transport HIPE (I'm going to send a proposal)
Other ideas?
disrupt101 (Thu, 09 Aug 2018 14:32:17 GMT):
Has joined the channel.
swcurran (Thu, 09 Aug 2018 15:56:38 GMT):
@danielhardman - do you want to do a session on the State Machine for Connection Establishment on the Agenda call tomorrow/Friday?
Vlad (Thu, 09 Aug 2018 15:57:49 GMT):
Has joined the channel.
mhailstone (Thu, 09 Aug 2018 21:38:04 GMT):
As a reminder and clarification, the time is 8:00 AM MDT (US - Mountain Daylight Time). Looking forward to the discussion. :)
mhailstone (Thu, 09 Aug 2018 21:41:53 GMT):
All,
We are having a discussion about establishing connections:
Daniel Hardman - Viewing the Connection Establishment as a State Machine
https://docs.google.com/spreadsheets/d/1RLJhhlWCUBYpKn18S5BGi7HH9MfGiZdHBxKjsJavoMs/edit?usp=sharing
Note that there is a link in the spreadsheet to a video walkthrough of this that you might look at ahead of time. Focus can then be primarily on the flow (is it right?) and the data (what goes back and forth?).
Topic: Hyperledger Indy Agent Design/Discussion - Friday 8/10/2018
Time: Aug 10, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
marrowdev (Fri, 10 Aug 2018 14:24:38 GMT):
Has joined the channel.
mhailstone (Fri, 10 Aug 2018 20:10:51 GMT):
Here is a link to the folder with today's call video/audio/chat:
https://drive.google.com/drive/folders/1M0FxZ0gqLhlAe79P-Nby2Jk8XY5cnUg6
TelegramSam (Sat, 11 Aug 2018 14:27:04 GMT):
I have committed the heinous crime of submitting a pull request for a commit without a sign-off. What's the easiest way to fix that?
TelegramSam (Sat, 11 Aug 2018 14:27:07 GMT):
https://github.com/hyperledger/indy-hipe/pull/32
mhailstone (Sat, 11 Aug 2018 14:41:34 GMT):
Something like this:
`git rebase --exec 'git commit --amend --no-edit -n --signoff' -i b9261153d33b833adc21c6ef6412ea551d48c406`
swcurran (Sat, 11 Aug 2018 16:55:05 GMT):
#gitguru
VuiLenDi (Mon, 13 Aug 2018 08:45:04 GMT):
Has joined the channel.
mboyd (Mon, 13 Aug 2018 15:27:11 GMT):
I've created a doc for this situation that lives in the SDK... if you still need it, [here you go](https://github.com/hyperledger/indy-sdk/blob/master/doc/signing-commits.md)
mboyd (Mon, 13 Aug 2018 15:27:21 GMT):
@TelegramSam
dbluhm (Mon, 13 Aug 2018 18:14:44 GMT):
@danielhardman
dbluhm (Mon, 13 Aug 2018 18:36:29 GMT):
@danielhardman after talking with @nage about negotiations during connection establishment, we ended up feeling that the type of key used in the relationship made the most sense as something to be negotiated during connection. Any other terms would be negotiated after establishing the connection. What are your thoughts on moving other negotiations (like the example you gave of negotiating the expiration of the connection) to a post-connection negotiation?
dbluhm (Mon, 13 Aug 2018 18:39:32 GMT):
I think this might help keep the connection protocol simple and make any negotiations held during connection establishment more directly related to the literal connection itself
nage (Mon, 13 Aug 2018 19:42:02 GMT):
plus if we do it post-connection we can leverage the credentials and messaging protocols for logging and evidence both parties agreed
nage (Mon, 13 Aug 2018 19:42:55 GMT):
so the TOFU connection is *the* connection request, and you're relationship could be in the "terms of connection not yet accepted" relative to your relationship state machine or willingness to leverage the connection.
nage (Mon, 13 Aug 2018 19:43:21 GMT):
but we can hash that out after we get through the basics of microledgers and credentials exchange
mhailstone (Mon, 13 Aug 2018 21:08:06 GMT):
@danielhardman @dbluhm Here are some puml files according to @danielhardman spreadsheet:
```@startuml
state "(new relationship)" as new_relationship
state "no change" as no_change_new_invite : resend or new invite that supersedes
state "no change" as no_change_new_req : resend or new req that supersedes
state "no change" as no_change_new_offer_i : I resend\nor make new offer that supersedes,\nbut can still accept original
state "no change" as no_change_new_offer_they : They resend\nor make new offer that supersedes,\nbut can still accept original
state "my misbehavior" as my_misbehavior_receive_req : should receive req instead,\nand should not send except over A2A
state "my misbehavior" as my_misbehavior_send_offer : should send offer instead
state "my misbehavior" as my_misbehavior_send_req : should send req instead
state "remote misbehavior" as remote_misbehavior_send_offer : ignore\nthey should send offer instead
state "remote misbehavior" as remote_misbehavior_send_req : ignore\nthey should send req instead
state "remote misbehavior" as remote_misbehavior : ignore
[*] --> disconnected
disconnected --> i_am_invited : "receive conn invite"
disconnected --> they_are_invited : "send conn invite"
disconnected --> impossible : send conn req\nreceive conn req\nsend conn offer\nreceive conn offer\nsend conn outcome\nreceive conn outcome\nsend error\nreceive error\ntimeout
state "I am invited" as i_am_invited
state "They are invited" as they_are_invited
they_are_invited -right-> no_change_new_invite : "send conn invite"
i_am_invited --> new_relationship : "send conn invite"
i_am_invited -left-> no_change_new_invite : "receive conn invite"
i_am_invited -right-> my_misbehavior_receive_req : "send conn req"
they_are_invited --> new_relationship : "receive conn invite"
they_are_invited --> they_can_accept : "send conn req"
they_are_invited -up-> impossible : receive conn req\nreceive conn offer\nreceive conn outcome\nreceive error
i_am_invited --> i_can_accept : "receive conn req"
i_am_invited -up-> impossible : send conn offer\nreceive conn offer\nsend conn outcome\nsend error
they_are_invited --> my_misbehavior_send_req : "send conn offer"
they_are_invited -up-> disconnected : send conn outcome (if rejected)\nsend error\ntimeout
i_am_invited -up-> disconnected : "receive conn outcome (if rejected)\nreceive error"\ntimeout
i_am_invited --> remote_misbehavior : "receive conn outcome"
state "They can accept" as they_can_accept
state "I can accept" as i_can_accept
they_can_accept --> new_relationship : send conn invite\nreceive conn invite
they_can_accept -right-> no_change_new_req : "send conn req"
i_can_accept --> new_relationship : send conn invite\nreceive conn invite
i_can_accept --> my_misbehavior_send_offer : "send conn req"
they_can_accept --> remote_misbehavior_send_offer : "receive conn req"
i_can_accept -left-> no_change_new_req : "receive conn req"
they_can_accept -up-> my_misbehavior_send_req : "send conn offer"
i_can_accept --> no_change_new_offer_i : "send conn offer"
they_can_accept --> no_change_new_offer_they : "receive conn offer"
i_can_accept --> remote_misbehavior_send_req : "receive conn offer"
they_can_accept -up-> disconnected : send conn outcome (if rejected)\nreceive conn outcome (if rejected)\nsend error\nreceive error\ntimeout
i_can_accept --> accepted : "send conn outcome\nif accepted"
i_can_accept -up-> disconnected : send conn outcome (if rejected)\nreceive conn outcome (if rejected)\nsend error\nreceive error\ntimeout
they_can_accept --> accepted : "receive conn outcome\nif accepted"
i_can_accept -up-> remote_misbehavior : "receive conn outcome"
new_relationship --> [*]
accepted --> [*]
@enduml```
mhailstone (Mon, 13 Aug 2018 21:08:20 GMT):
```@startuml
state "(new relationship)" as new_relationship
[*] --> disconnected
disconnected -down-> i_am_invited : "receive conn invite"
disconnected -down-> they_are_invited : "send conn invite"
state "I am invited" as i_am_invited
state "They are invited" as they_are_invited
i_am_invited --> new_relationship : "send conn invite"
they_are_invited --> new_relationship : "receive conn invite"
they_are_invited -down-> they_can_accept : "send conn req"
i_am_invited -down-> i_can_accept : "receive conn req"
they_are_invited -left-> disconnected : send conn outcome (if rejected)\nsend error\ntimeout
i_am_invited -right-> disconnected : "receive conn outcome (if rejected)\nreceive error"\ntimeout
state "They can accept" as they_can_accept
state "I can accept" as i_can_accept
they_can_accept --> new_relationship : send conn invite\nreceive conn invite
i_can_accept --> new_relationship : send conn invite\nreceive conn invite
they_can_accept --> disconnected : send conn outcome (if rejected)\nreceive conn outcome (if rejected)\nsend error\nreceive error\ntimeout
i_can_accept --> accepted : "send conn outcome\nif accepted"
i_can_accept --> disconnected : send conn outcome (if rejected)\nreceive conn outcome (if rejected)\nsend error\nreceive error\ntimeout
they_can_accept --> accepted : "receive conn outcome\nif accepted"
new_relationship --> [*]
accepted --> [*]
@enduml```
vtech (Tue, 14 Aug 2018 06:11:21 GMT):
Has joined the channel.
mitovskaol (Tue, 14 Aug 2018 18:15:31 GMT):
Has joined the channel.
danielhardman (Tue, 14 Aug 2018 20:55:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=k9MiESdCriZW7GniS) @dbluhm I agree that some of the examples of negotiation that I used are artificial. However, there is another issue that's ripe for negotiation, that must happen early (can't use @nage's TOFU preference, even though I also would prefer it otherwise). It's payment/cost. If a company is inviting someone to connect, and that someone doesn't want to incur any costs as part of the connection (they don't already have a cloud agent and don't want to pay to get one, just to facilitate this connection), then negotiating about whether the inviter would sponsor a cloud agent on behalf of the invitee needs to be possible. This can't be done after, because by the time we're "after", the cloud agent must already exist.
So my short answer is: sure, we can try to limit negotiation before. But so far I'm not feeling like we can build a connection protocol where all negotiation happens after.
nage (Tue, 14 Aug 2018 21:18:54 GMT):
interesting use case. How would you propose that negotiation occur? Would it be terms of service + tokens?
swcurran (Tue, 14 Aug 2018 22:20:04 GMT):
Hey Folks, I've broken the "Transport Layer" HIPE into three separate HIPEs
- Wire Messages - the protocol for handling sending Agent Messages across hops from one Agent to another on their journey to the Receiver
- Cross Domain Messaging - the "Forward" message type and the assumptions the Sender can make about the Agent configuration
- DIDDoc Conventions - conventions within a DIDDoc - notably, how to find the endpoint/key for the Domain Endpoint and the key of the Routing Agent.
The topics are intertwined, but the HIPEs can/should be broken into 3 separate PRs. Since I didn't really know how to do that (although I can guess...) I thought I would just promote this for review for now and I can deal with the separate PRs as a follow on.
Please let me know what you think of the HIPEs - the content, and the process.
Thanks!
mhailstone (Tue, 14 Aug 2018 22:33:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=3dEfoSEHqdKiJGKzD) @danielhardman Would you consider negotiation during the "invitation" phase appropriate then? I'm considering "invitation" messages out-of-band of agent messages, so any kind of interaction/negotiation could happen during that time. When an invitation is accepted/negotiated, then according to the implementation of the invitation, one party would initiate the "connection request" message as an agent message as the first message of the connection flow.
danielhardman (Tue, 14 Aug 2018 22:41:11 GMT):
@mhailstone and @nage: I'm not sure how to model this. It's messy. Maybe the simplest thing would be: the invitation can be treated as take-it-or-leave-it, and can include information about a free sponsorship offer. If any negotiation is necessary, the invitee accepts the sponsorship and fires up a cloud agent, whereupon the negotiation can happen over a connected channel. Possibly the negotiation causes the first cloud agent to be abandoned (treated as a temporary throwaway "burner" cloud agent), replaced with something more attractive to the invitee?
swcurran (Tue, 14 Aug 2018 23:20:48 GMT):
I think we should work hard to make the Agent creation process be as isolated as possible from the connection process. I agree it is a possible byproduct and there is a need to allow both to happen, but the establish connection protocol should have as little knowledge of that process as possible. I don't think the messages should reference issues like that.
mhailstone (Tue, 14 Aug 2018 23:31:37 GMT):
All,
In our Friday Agent call, we will be discussing "Establishing Connections". If you have other topics you'd like to suggest, be contact @mhailstone or @swcurran via email or RocketChat.
Topic: Indy Agent Design/Discussion - Friday 8/17/2018
Time: Aug 17, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Tue, 14 Aug 2018 23:31:37 GMT):
All,
In our Friday Agent call, we will be discussing "Establishing Connections". If you have other topics you'd like to suggest, please contact @mhailstone or @swcurran via email or RocketChat.
Topic: Indy Agent Design/Discussion - Friday 8/17/2018
Time: Aug 17, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
TelegramSam (Wed, 15 Aug 2018 10:36:00 GMT):
I'm a fan of the split @swcurran
SRibeiro (Wed, 15 Aug 2018 19:48:15 GMT):
Has joined the channel.
devin-fisher (Wed, 15 Aug 2018 22:43:55 GMT):
Last fall as Evernym was building the MVP version of VCX and its cloud agent, I did an analysis of knowledge is passed as each stage of a connection interaction is completed. At the time, the risk of changing course with our MVP product was too high to propose changes things but I think its insights could be useful now.
https://docs.google.com/presentation/d/1jnnvnibFfk_X-YZC12NTsF10sMIwKnYMefJ4_VhGSLo/
The document is terse and don't say much about the setup. It uses snail mail as a metaphor. Bob and Alice exchange postcards.
devin-fisher (Wed, 15 Aug 2018 23:02:25 GMT):
@danielhardman Seems to me that in the use-case where on-boarding is required during a connection establishment with non-agency entity the process could flow like this:
First, connection is between the user being on-boarded and the agent provider (agency). That connection could be direct, edge agent to agency.
Second, after connection is established, a negotiation about the service could happen. If successful, the cloud agent created and the edge agent could be configured to use it.
Third, the connection to entity that initiated the on-boarding could be establish. Using the edge agent and the newly form cloud agent.
I think the use of cloud agent negotiation will have to happen the first time I open my edge agent anyway. We can just put the origin connection process on hold till the agent usage negotiation process is complete.
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError````
which i thought tht the lines between ```// OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END```; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError````
which i thought that the lines between ```// OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END```; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError```
which i thought that the lines between ```// OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END```; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError``` which i thought that the lines between ```// OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END```; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError``` which i thought that the lines between ```OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END``` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError``` which i thought that the lines between ```OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END``` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError```which i thought that the lines between ```OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END``` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an ```AnoncredsCredDefAlreadyExistsError```which i thought that the lines between ```OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END``` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an `AnoncredsCredDefAlreadyExistsError` which i thought that the lines between `OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```
public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage for several different users; the following code is functional on the first invocation; on the second one i get an `AnoncredsCredDefAlreadyExistsError` which i thought that the lines between `OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```
public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 12:38:25 GMT):
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage several different users; the following code is functional on the first invocation; on the second one i get an `AnoncredsCredDefAlreadyExistsError` which i thought that the lines between `OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```
public async issueDebitCardCredential(indyClient: IndyClient): Promise
tomislav (Thu, 16 Aug 2018 13:37:31 GMT):
@ThomasKrech You only need to call `sdk.issuerCreateSchema` and `sdk.issuerCreateAndStoreCredentialDef` only once. This is when the agency becomes an issuer of credentials for this definition. Ideally, these calls would be followed by writing them on the ledger. To issue an offer/credential to a user subsequently, you just need to call `sdk.issuerCreateCredentialOffer` and `sdk.issuerCreateCredential` for each user.
tomislav (Thu, 16 Aug 2018 13:38:28 GMT):
You need to save the credentialDefinitionId created the first time, and pass it later in the offer and credential calls
ThomasKrech (Thu, 16 Aug 2018 13:42:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RAZNWNL9wrDQ3qjeX) @tomislav
Hi, i try to use the following code (copied from the indy-agent-stuff (part: "GOVID") and adapted it in my server implementation;
my server should be able to manage several different users; the following code is functional on the first invocation; on the second one i get an `AnoncredsCredDefAlreadyExistsError` which i thought that the lines between `OMIT AGAIN CREATION OF CREDENTIAL DEFINITION - BEGIN / END` is the place to circumvent that; in order to proceed i just did the WORKAROUND;
can somebody tell me what I do wrong?
```
public async issueDebitCardCredential(indyClient: IndyClient): Promise
ThomasKrech (Thu, 16 Aug 2018 13:44:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=pfc4EyPzEk8z4aXNX) hi @tomislav, i think i must also store the personalInformationCredDef? and how do i get these information on a potential server restart?
jljordan_bcgov (Thu, 16 Aug 2018 15:12:21 GMT):
From the DIF Slack ...
Proposed DID Document service endpoint descriptor for Hubs: https://gist.github.com/csuwildcat/9d39babfac98f88c3eb140051402c0d2
jljordan_bcgov (Thu, 16 Aug 2018 15:14:45 GMT):
perhaps some relevance to the discussions on A2A protocols
tlooker (Thu, 16 Aug 2018 22:18:35 GMT):
Has joined the channel.
josh.hill (Thu, 16 Aug 2018 22:21:55 GMT):
Has joined the channel.
swcurran (Thu, 16 Aug 2018 22:33:26 GMT):
I think it would be really helpful if the protocol around the Relationship State Machine and specifically the operations that update the DIDDoc elements was outlined. How does domain replicate an update to the attributes of a DID to the other instances of the RSM - either on the Public Ledger or to the other instance(s) of the DID on microledgers? This work would include defining how a DID on the public ledger would support all of the attributes defined in the DID Spec.
Question for @danielhardman, @devin-fisher and perhaps @esplinr - how much of that code and/or documentation already exists that should be used as a starting place, or should someone just start to build up a HIPE from scratch? And...if that documentation exists, can we begin to turn it into a concrete HIPE such that interoperable implementations are possible?
swcurran (Thu, 16 Aug 2018 22:35:58 GMT):
I think this is somewhat (but not crucially) related to the Connection Establishment discussion. Since the Connection Establishment includes setting up the initial instance of the DIDDoc attributes, I think we should assume that as part of that, the Identities will be delivering as much or as little of the DiDDoc attributes as necessary.
danielhardman (Thu, 16 Aug 2018 22:56:54 GMT):
@swcurran: Devin already started building this HIPE. See https://github.com/hyperledger/indy-hipe/pull/31
swcurran (Thu, 16 Aug 2018 23:12:01 GMT):
Ah good stuff - I'll take a look. Now I recall seeing that. Seeing the code link was cool - but it's to a fork of the entire Indy-SDK. I'll have to look harder to find the code related to the RSM. Homework time!!
jljordan_bcgov (Fri, 17 Aug 2018 04:08:07 GMT):
Some of the DIF activities on replication of ID Hub _may_ have something to offer on the in the RSM discussion pertaining to a multi-agent ID Owner
jljordan_bcgov (Fri, 17 Aug 2018 04:08:07 GMT):
Some of the DIF activities on replication of ID Hub *_may_* have something to offer on the in the RSM discussion pertaining to a multi-agent ID Owner
KanupriyaPandey (Fri, 17 Aug 2018 08:51:04 GMT):
Has joined the channel.
danielhardman (Fri, 17 Aug 2018 12:09:13 GMT):
At our recent A2A summit, I presented the idea of a message that is just a bundle of other messages, and suggested that this might be desirable. There was some pushback along the lines of, “Batches might be a nice optimization, but we don’t need it right now. Just send the messages one at a time.”
I don’t actually disagree with the timing observation. We’ve got plenty of other things on our plates right now, so I’m happy to worry about this later. But I wanted to see if I could make a case for bundling that’s a little stronger than just, “this is an optimization we can get around to whenever.” Hopefully you’ll agree with me enough to adopt this concept when we need it. Please have a look at: https://docs.google.com/document/d/1vnIk6hXDjTdJs8AcOMgWL_U162cyGubAYEpArDcd-LU/edit
mhailstone (Fri, 17 Aug 2018 15:47:35 GMT):
Thanks to all for the discussion on the Friday Agent call that just ended. We have consensus on the connection flow process/messages depicted in the following PlantUML diagram:
```@startuml
Alice --> Bob : invite
rnote left
* endpoint information
endpoint did
or
endpoint uri
endpoint key
* connection key (one time use)
end note
Bob --> Alice: request
rnote right
anon_crypted(endpoint_key, {
@type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward_to_key",
key: one time encryption key,
content: {
@type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/request",
key: connection key,
content: auth_crypted(connection key, {
did: // did on a public ledger
or
did_doc:
})
}
})
end note
Alice --> Bob: response
rnote left
anon_crypted(endpoint_key, {
@type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward",
to: "ABC",
content: {
@type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/response",
to: "did:sov:ABC",
content: auth_crypted("123", {
did: // did on a public ledger
or
did_doc:
})
}
})
end note
Bob --> Alice: future messages
rnote right
anon_crypted(endpoint_key, {
@type: "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward",
to: "ABC",
content: {
@type: ,
from: "did:sov:ABC",
content: auth_crypted( , )
}
})
end note
@enduml```
mhailstone (Fri, 17 Aug 2018 15:48:05 GMT):
We will make suggestions to the connection HIPE to be updated as well.
swcurran (Fri, 17 Aug 2018 15:48:50 GMT):
@saholman @mhailstone - awesome job today. Great work!
swcurran (Fri, 17 Aug 2018 15:48:50 GMT):
@saholman @mhailstone - awesome job today. Great work! Thanks!
mhailstone (Fri, 17 Aug 2018 15:49:37 GMT):
@swcurran Agreed!
jonathanreynolds (Fri, 17 Aug 2018 15:57:05 GMT):
It was great to see a discussion that lead to the proposed solution being simplified.
jonathanreynolds (Fri, 17 Aug 2018 15:58:01 GMT):
Has anyone given any thought to message handling plugins in the agent design. Seems like this is a useful direction to explore and was touched on during the agent summit.
jonathanreynolds (Fri, 17 Aug 2018 15:58:01 GMT):
Has anyone given any thought to message handling plugins in the agent design? Seems like this is a useful direction to explore and was touched on during the agent summit.
jonathanreynolds (Fri, 17 Aug 2018 15:59:24 GMT):
This is a slight jump ahead but if this is a direction that has support it would be good to discuss some standards to encourage reuse.
saholman (Fri, 17 Aug 2018 16:08:04 GMT):
@jonathanreynolds That is exactly how we are thinking about handling it. We want to build/are building a simple agent framework that we can just add modules to for everything including connections.
jonathanreynolds (Fri, 17 Aug 2018 16:14:52 GMT):
That's great. Are you pushing the code to github yet? I'd love to see what you have done so far in terms of a plugin API and how the agent keeps track of any workflows beyond simple request/response.
saholman (Fri, 17 Aug 2018 17:14:40 GMT):
Its mostly ideas and diagrams right now, but we will keep you updated. Basically we are just trying to build a new reference agent that follows the model discussed at the agent summit. I think the best thing we all can do right now is to try to build our own agent and update the test suite as we do so.
danielhardman (Fri, 17 Aug 2018 17:20:31 GMT):
@swcurran and @mhailstone Apparently the comment that I made in today's call about private individuals not being allowed to write DIDs to the public ledger is no longer accurate. Lawyers and BOT people at the SF analyzed the risk and discussed at a recent Trust Framework meeting. They concluded that, although there is some legal uncertainty, the risk to Sovrin's legality is low enough that this proscription is not needed.
swcurran (Fri, 17 Aug 2018 17:36:26 GMT):
@danielhardman nice! Thanks for the clarification.
jljordan_bcgov (Fri, 17 Aug 2018 18:55:30 GMT):
Frankly the idea and an IP address is "personal data" is very misguided as well. Yes the way many providers implement their networks does reveal locations and so forth but the technology itself doesn't have to be that way. I wonder if there is any legal case that has set that precedent?
jljordan_bcgov (Fri, 17 Aug 2018 18:55:30 GMT):
Frankly IMO the idea and an IP address is "personal data" is very misguided as well. Yes the way many providers implement their networks does reveal locations and so forth but the technology itself doesn't have to be that way. I wonder if there is any legal case that has set that precedent?
jljordan_bcgov (Fri, 17 Aug 2018 18:56:15 GMT):
We need some way for machines to find each other and talk so that we can do real world things ...
mhailstone (Fri, 17 Aug 2018 19:32:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=WAQex3vptp7qEniBg) @jljordan_bcgov I would agree with that notion as well. A dynamically assigned IP address could be associated with multiple individuals at different times and over a longer period of time wouldn't be deterministic toward an individual. Data over the wire sent to the IP address would be identifiable/correlatable, though (if you have access to it). Static IP addresses are reusable as well, but are more correlatable.
mhailstone (Fri, 17 Aug 2018 19:46:45 GMT):
Here is the link to the folder containing the recording of today’s Friday Agent call.
https://drive.google.com/drive/folders/1ojcbiUuEs4enb9NIXQvnXq2Qr4H693KP
swcurran (Fri, 17 Aug 2018 22:42:40 GMT):
I've cancelled the PR for the HIPE that I originally entered about Transport Messaging Protocol and created three new PRs for the HIPEs that spun out of that effort - one on Wire Messages, one on Cross Domain Messaging, and a last one on DIDDoc Conventions.
Would like feedback on all three, and particularly from @peacekeeper on the DIDDoc one (alignment with DID Spec) and @kdenhartog and @TelegramSam on the Wire Messages one.
I've not yet updated the Wire Messages one after the discussion this morning but will do so.
tlooker (Sun, 19 Aug 2018 23:06:12 GMT):
Hi Guys, I’m new to the chat and trying to get up to speed with the latest progressions in the indy-agent WG. I had a couple of questions/clarifications around the connection flow posted above.
1. Is the “one time encryption key” in the root object of the Bob --> Alice: request, the connection key, just not renamed?
2. With the current Bob --> Alice: request, does the agent see the inner message type? If so I heard it briefly discussed on the latest indy call that this visibility to the cloud agent might want to be preserved to allow auto cloud agent message policies in future. Does this mean the standard messaging structure will mean all message types are disclosed to the cloud agent always or does this only stand for the connection message family?
mhailstone (Mon, 20 Aug 2018 14:54:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=FJmiySGqrzGtAwMNG) @tlooker The "one time encryption key" is not the same as the key created with the pairwise DID in the connection, but literally a one time use key to encrypt the data and to help identify who the entity is from/to. For the second point (and others please chime in if opinions differ), if you forward a message, then you can hide the message type from the agent and the intended agent would only see the message type. It is up to the sender whether they want to disclose the message type to the agency/routing agent or not. @swcurran @saholman am I getting that right?
kdenhartog (Mon, 20 Aug 2018 15:54:04 GMT):
@swcurran there's a few things that I need to do a PR against your wire protocol HIPE to ask some questions about a few things. Expect a PR by Wednesday.
swcurran (Mon, 20 Aug 2018 16:11:34 GMT):
@kdenhartog I'm doing some updates on it now. You can just add comments or do pr against my fork.
tlooker (Mon, 20 Aug 2018 20:21:42 GMT):
@mhailstone Great thanks for the clarification, just to understand further though, the connection key apart of the connection invitation/offer from Alice is the same as the key shown on line 16 in the UML above isn't it, as it is the connection key (one time use)? Furthermore are we envisaging that Alice's edge agent at the generates connection invitation/offer phase, sends another message not represented here, to her cloud agent registering the connection key, so that when the cloud agent receives the connection request from Bobs agent, it knows based on the connection key to forward the message to Alices, edge agent?
mhailstone (Mon, 20 Aug 2018 20:26:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=P3fkucyTxfZNWhR6E) @tlooker You are right that the "one time use" key is used in the cloud agent (or whatever tiered agent infrastructure exists in the agency) in forwarding the message to the edge agent. The implementation of the invitation would need to configure or otherwise let the cloud/routing agents know about the key and which edge agent the key is associated with.
tlooker (Mon, 20 Aug 2018 20:34:10 GMT):
@mhailstone Thanks, also do you know if anyone has done / is doing a review on libvcx as it appears this library has a bit of overlap with the spec developing in this WG, from my understanding libvcx is currently tethered to evernym's closed source agent, but if the library was modified it could be a good base line library for edge agents?
mhailstone (Mon, 20 Aug 2018 20:38:23 GMT):
Agreed. As I understand it, the libvcx merge into the sdk should help provide a more smooth agent development experience. You're probably already aware, but for reference, the libvcx HIPE is here: https://github.com/hyperledger/indy-hipe/pull/29. @esplinr should be able to answer questions regarding libvcx.
Christian (Mon, 20 Aug 2018 20:54:02 GMT):
Hi. I have setup IndyNode network and a Steward. I want to onboard Faber as a trust anchor, i have Faber as a separate VM, i havent been able to find any documentation on how exactly to generate a connection request from Steward and how to send back the Connection response from Faber to Steward. Any help
tlooker (Mon, 20 Aug 2018 21:04:09 GMT):
Thanks @mhailstone I hadn't checked the HIPE for the past couple of days, looks like they are progressing towards interoperability https://jira.hyperledger.org/browse/IS-871
baconsandwich (Wed, 22 Aug 2018 11:26:02 GMT):
Has joined the channel.
baconsandwich (Wed, 22 Aug 2018 11:28:03 GMT):
Can you point me to a step by step description (possibly with graphs) of a workflow for the verification of a claim e.g. during a login. I am interested to know how a client contacts his agent, then how its agent finds out how to contact the target DIDs agent and how they communicate.
danielhardman (Thu, 23 Aug 2018 03:04:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xxNTb7kSKt4xxLDKr) @baconsandwich I don't have such docs handy (though i believe they exist). However, let me offer this much, quickly: the client-to-agent part is up to implementers. One client might contact its agent over a raw socket; another might do so over https; etc. The agent-contacting-agent part happens when a DID is looked up on the ledger, retrieving a DID Document that proves which keys are associated with the DID and that provides a URL at which the DID's agent may be contacted. You may find the following resources helpful: the README.md files in PRs 35, 36, and 37 in the indy-hipe repo (github.com/hyperledger/indy-hipe). You may also want to learn about the function in indy-sdk called indy_build_get_ddo_request (see https://github.com/hyperledger/indy-sdk/blob/3647740238ddf17dbf1104df26f547977ce3244f/libindy/src/api/ledger.rs#L313), which builds a request to the indy ledger asking for a remote party's DID Doc. (You can then submit the request with indy_send_request()).
danielhardman (Thu, 23 Aug 2018 03:08:14 GMT):
@swcurran and @mhailstone and @kdenhartog and @MALodder and others working on A2A HIPEs: one detail that we need to think about is timing as it relates to usage of keys. If Alice sends a message to Bob at time 1, rotates her key at time 2, and then Bob receives the message at time 3, Bob may deem the message illegitimate if he simply looks up Alice's DID Doc at the time the message was received. What he ideally wants is to look up the DID Doc at the time when Alice claims to have sent the message. This is perfectly possible in Indy. Problem is, an Alice impersonator can get one of Alice's old keys and claim she sent a message back when that key was valid. Does the double ratchet provided by Signal solve this?
mhailstone (Thu, 23 Aug 2018 03:24:07 GMT):
All,
We are having our Friday Agent call at the usual time. Sam Curren will be discussing message IDs.
Topic: Indy Agent Design/Discussion - Friday 8/24/2018
Time: Aug 24, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
n3m4nja (Thu, 23 Aug 2018 14:04:44 GMT):
https://blog.bigchaindb.com/certified-for-life-dd685c1ab61c
Hasse (Thu, 23 Aug 2018 15:30:53 GMT):
Has joined the channel.
jljordan_bcgov (Thu, 23 Aug 2018 15:35:35 GMT):
@baconsandwich not sure if this Plant UML diagram of the Alice/Faber example is helpful https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.svg
jljordan_bcgov (Thu, 23 Aug 2018 15:36:02 GMT):
there are other docs in and around that area of the indy-sdk docs directory
swcurran (Thu, 23 Aug 2018 16:01:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ws5zqZkbp9M5uHgDx) @danielhardman One thing to remember is that if the data is on a microledger, there will be an Agent Message sent to notify Bob that the key was rotated. That will reduce (but perhaps not eliminate) the likelihood. Since message ordering is not guaranteed so there could still be an issue. Does that reduce the it enough for now?
danielhardman (Thu, 23 Aug 2018 16:12:38 GMT):
Yes, I think it reduces the risk of Alice impersonators enough, for now, that I don't feel need for immediate additional protections. But I don't think it eliminates it. In the long run, we need an answer.
Regardless, I still think we may need a way to make a claim about when a message was sent, so the receiver knows which version of a DID Doc to test the key against.
TelegramSam (Thu, 23 Aug 2018 18:25:27 GMT):
Draft slides for tomorrow's discussion about message IDs: https://docs.google.com/presentation/d/1q3oPJ_ODdw4HEOTSWCmkIKpNGN8lhV66VnDbZ50gPB8/edit?usp=sharing
dbluhm (Thu, 23 Aug 2018 20:47:03 GMT):
@mhailstone I'm a bit out of the loop (travelling) but as I was reviewing your PR against the connection HIPE, I noticed that no mention of connection offers (in terms of negotiation) was made. Was this deliberately omitted for now?
mhailstone (Thu, 23 Aug 2018 20:53:48 GMT):
@dbluhm Yes. From our discussion on Friday Aug. 17, the group agreed that the invitation phase proposed by @danielhardman would be adopted in place of an offer message in the connection flow.
dbluhm (Thu, 23 Aug 2018 21:19:51 GMT):
I'm on the same page there but we had discussed the connection offer message being used as a counter offer message for negotiations.
dbluhm (Thu, 23 Aug 2018 21:21:13 GMT):
Have we punted negotiations during connection establishment until later?
danielhardman (Fri, 24 Aug 2018 00:23:45 GMT):
I think we decided that negotiation during connections is a bit esoteric. There might be a case for them, but it wouldn't be mainstream; the only scenario that we unambiguously believed in was Nathan's about negotiating a type of crypto for compatibility. So we kind of decided to ignore that issue for now.
dbluhm (Fri, 24 Aug 2018 02:34:09 GMT):
Thanks for the update!
TelegramSam (Fri, 24 Aug 2018 14:56:08 GMT):
https://docs.google.com/document/d/1vWSn_tCk_2P-oSBKcHaQ9kg-O1oB_YtZTcA76dgpZew/edit?usp=sharing
mhailstone (Fri, 24 Aug 2018 18:35:25 GMT):
Here is the link to the Friday Agent call today:
https://drive.google.com/drive/folders/11dWon1kur_rreIjDE4N-4ysSexNqV6Z8
baconsandwich (Sat, 25 Aug 2018 16:50:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fNC2qBfe8RmPP4ai8) @jljordan_bcgov thank you, I will see if I can get some useful info from that
baconsandwich (Mon, 27 Aug 2018 09:57:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=khnhAbrDFFwK7qX6y) @danielhardman I finally had the chance to look into your answer more thourougly. Since you are referring to PRs in HIPE, does that mean that no agent-to-agent communication is implemented atm? The thing is, that I was looking at the [transaction documentation](https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#nym) and could find anything related to a URL of a DID's agent. Or this stored in a ATTRIB transaction? Again, my question is basically: How do I find the agent for a DID?
baconsandwich (Mon, 27 Aug 2018 09:57:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=khnhAbrDFFwK7qX6y) @danielhardman I finally had the chance to look into your answer more thourougly. Since you are referring to PRs in HIPE, does that mean that no agent-to-agent communication is implemented atm? The thing is, that I was looking at the [transaction documentation](https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#nym) and could find anything related to a URL of a DID's agent. Or this stored in a ATTRIB transaction? Again, my question is basically: How does an agent find the agent of the target DID?
swcurran (Mon, 27 Aug 2018 14:41:18 GMT):
@baconsandwich - A2A Communication does work and has been done multiple times but different groups. The point of the HIPEs is to define common ways to build them so Agents built by the different groups are interoperable. That is a work in progress.
As to your question about the URL - yes, for now it goes into an ATTRIB. That is an area for interoperability - improving Indy-Node to use mechanisms that explicitly align with the DID Spec vs. conventions in the use of ATTRIB name/value pairs.
swcurran (Mon, 27 Aug 2018 14:41:18 GMT):
@baconsandwich - A2A Communication does work and has been done multiple times by different groups. The point of the HIPEs is to define common ways to build them so Agents built by the different groups are interoperable. That is a work in progress.
As to your question about the URL - yes, for now it goes into an ATTRIB. That is an area for interoperability - improving Indy-Node to use mechanisms that explicitly align with the DID Spec vs. conventions in the use of ATTRIB name/value pairs.
baconsandwich (Mon, 27 Aug 2018 14:46:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZYcBymuNz8a36Mj7x) @swcurran So, there is not consensus yet on how to encode a URL or similar in an ATTRIB transaction and is left to the implementation, although a standard is discussed in HIPE? I am just repeating to make sure I understood it correctly.
baconsandwich (Mon, 27 Aug 2018 14:46:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZYcBymuNz8a36Mj7x) @swcurran So, there is no consensus yet on how to encode a URL or similar in an ATTRIB transaction and is left to the implementation, although a standard is discussed in HIPE? I am just repeating to make sure I understood it correctly.
baconsandwich (Mon, 27 Aug 2018 14:46:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZYcBymuNz8a36Mj7x) @swcurran So, there is no consensus yet on how to encode a URL (or similar) in an ATTRIB transaction and the format is left to the implementation, although a standard is discussed in HIPE? I am just repeating to make sure I understood it correctly.
swcurran (Mon, 27 Aug 2018 14:47:20 GMT):
Yes - that's right. My expectation (but could be wrong) is that Indy-Node will accept transactions that define how to store elements of a DIDDoc - using DID Spec terminology.
swcurran (Mon, 27 Aug 2018 14:48:54 GMT):
The HIPE about the "Relationship State Machine" will be improved to lead to that. https://github.com/hyperledger/indy-hipe/pull/31
swcurran (Mon, 27 Aug 2018 14:48:54 GMT):
The HIPE about the "Relationship State Machine" will evolvve to lead to that. https://github.com/hyperledger/indy-hipe/pull/31
swcurran (Mon, 27 Aug 2018 14:48:54 GMT):
The HIPE about the "Relationship State Machine" will evolve to lead to that. https://github.com/hyperledger/indy-hipe/pull/31
kdenhartog (Mon, 27 Aug 2018 20:51:57 GMT):
I'll be available to give my talk this week @swcurran @mhailstone
mhailstone (Mon, 27 Aug 2018 21:34:55 GMT):
Excellent! Thanks for the update @kdenhartog
danielhardman (Tue, 28 Aug 2018 01:43:18 GMT):
@swcurran, I was thinking about how A2A would work over some different protocols besides http -- specifically, SMTP and BlueTooth. I don't think we have to know in great detail right now, but I think it's a good mental exercise to ask the question. The role played by 9 in your current cross-domain HIPE is played by an SMTP server in email; it's not clear to me what happens in BlueTooth.
Anyway, I don't think it undermines anything we've been talking about, but perhaps it makes the context of our own mental explorations a bit clearer. I wonder if perhaps we should consider renaming your HIPE: "Cross-Domain Messaging for Cloud" (cloud, I think, being the defining characteristic of how we're using 9 and 8). That way if we described Cross-Domain Messaging for BlueTooth or for SMTP or for
danielhardman (Tue, 28 Aug 2018 01:43:53 GMT):
(the smiley face is supposed to be an 8 )
swcurran (Tue, 28 Aug 2018 18:45:13 GMT):
@danielhardman - great thought. It would be really good if someone with experience in those mechanisms. I think these would be additional HIPEs as I agree, it doesn't change the "across the 'Net" nature of what we have now.
I've thought a bit about Bluetooth for the in-person verification for unconnected Identities - think a Waiter/Bartender. Connected identities could also use the connection. The biggest challenge I see is how much of a disaster Bluetooth is to deal with, but perhaps that gets abstracted away.
Wow...hadn't at all thought of SMTP. That's an interesting one.
Fine to change the name of the HIPE - that is reasonable.
swcurran (Tue, 28 Aug 2018 18:45:13 GMT):
@danielhardman - great thought. It would be really good if someone with experience in those mechanisms took a look. I think these would be additional HIPEs as I agree, it doesn't change the "across the 'Net" nature of what we have now.
I've thought a bit about Bluetooth for the in-person verification for unconnected Identities - think a Waiter/Bartender. Connected identities could also use the connection. The biggest challenge I see is how much of a disaster Bluetooth is to deal with, but perhaps that gets abstracted away.
Wow...hadn't at all thought of SMTP. That's an interesting one.
Fine to change the name of the HIPE - that is reasonable.
mhailstone (Tue, 28 Aug 2018 20:17:15 GMT):
All,
Our Friday Agent call will focus on the JWM message format presented by Kyle Den Hartog.
Topic: Indy Agent Design/Discussion - Friday 8/31/2018
Time: Aug 31, 2018 3:00 PM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
laurasp (Wed, 29 Aug 2018 11:24:22 GMT):
Has joined the channel.
VitalijReicherdt (Wed, 29 Aug 2018 14:12:07 GMT):
in the reference implementation, we have 1 client wallet per agent... in this case is an endpoint with IP:PORT enough for P2P between 2 wallets.
If i have more wallets per agent, is endpoint not enough for P2P, because the message is encoded i need the right wallet for decode the message...
How is this problem to solve with standard sdk? I can put the additional params (wallet name or so) in http body, but this is not really a good solution in my opinion.
mhailstone (Wed, 29 Aug 2018 15:32:21 GMT):
I wanted to update everyone that the https://github.com/hyperledger/indy-agent repository has merged some pull requests. Many thanks to those submitting pull requests! Particularly, @ArthurManz provided a great update using docker and an upgrade to indy-sdk 1.6.1. I recommend that you take a look at the new changes in the repository. We hope to incorporate the decisions represented in the HIPEs after they are officially accepted and encourage those interested to help out in contributing to those solutions for all/new languages in the reference implementation. Thank you!
saholman (Wed, 29 Aug 2018 15:36:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=sCxcyPEnvA7AmoXRC) @VitalijReicherdt Even though the SDK supports multiple wallets, we have made the assumption that each agent only has one wallet. One wallet should be sufficient to manage multiple connections, DIDs, credentials, etc. What is your use case for multiple wallets?
swcurran (Wed, 29 Aug 2018 15:39:12 GMT):
@VitalijReicherdt agreed that the limit of IP:PORT as an endpoint in a DID is insufficient. This is expected to be changed in Indy-SDK so that you can both have multiple endpoints associated with a DID and that the endpoint can be a URI.
swcurran (Wed, 29 Aug 2018 15:39:12 GMT):
@VitalijReicherdt agreed that the limit of one IP:PORT as an endpoint in a DID is insufficient. This is expected to be changed in Indy-SDK so that you can both have multiple endpoints associated with a DID and that the endpoint can be a URI.
VitalijReicherdt (Wed, 29 Aug 2018 15:50:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=kju3sn2K7qo5pvy8m) @saholman I work on POC, we develop an agent which can manage user with their wallets. In our POC, we have 3 agents (3 docker container), every agent manage 1 steward wallet and 1-N client wallets.
saholman (Wed, 29 Aug 2018 15:51:56 GMT):
Ok, that makes sense. Sounds like a great agency implementation!
saholman (Wed, 29 Aug 2018 15:55:08 GMT):
Ok, that makes sense. Sounds like a great agency implementation! The way to do that now is to have a forward message arrive at the agency with a "to" field that contains a DID. The agency should then know which agent the message should go to based on that did. This isn't really set in stone though, so if you have a better way to do it go for it! :slight_smile: For more information on the forward message, look at @mhailstone's post awhile back with the PUML document and see how we are using forward messages. https://chat.hyperledger.org/channel/indy-agent?msg=FP87hvzPgWDz8W9sD
gskerry (Wed, 29 Aug 2018 15:56:09 GMT):
Has joined the channel.
VitalijReicherdt (Wed, 29 Aug 2018 16:19:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=XDCd8yuhH4HgaMmP8) @saholman yes, i will forward the message to the right wallet, but the message is encrypted and i need a endpoint key to decrypt this message... to get the endpoint key, i need the information about wallet name, to read the endpoint did and than endpoint key from this wallet. So I must send the wallet name NOT encrypted, as additional request param
VitalijReicherdt (Wed, 29 Aug 2018 16:21:37 GMT):
my workaround is to send with request body 2 params, targetWalletName or so and encrypted message
bdeva (Wed, 29 Aug 2018 16:23:56 GMT):
@VitalijReicherdt We had similar issues with multi-wallet support and routing. As an intermediate solution until the message formats are finalized we created a unique endpoint for each wallet and keep track which endpoint fits to which wallet. Unfortunately up until now endpoints cannot be stored in the ledger that contain URLs but just IP:port. We pass on the endpoints in the connection_offers/requests instead of storing them on the ledger until this limitation is fixed.
bdeva (Wed, 29 Aug 2018 16:23:56 GMT):
@VitalijReicherdt We had similar issues with multi-wallet support and routing. As an intermediate solution until the message formats are finalized we created a unique endpoint for each wallet and keep track which endpoint fits to which wallet. Unfortunately up until now endpoints cannot be stored in the ledger that contain URLs but just IP:port. We pass on the endpoints in the connection_offers/requests instead of storing them on the ledger until this limitation is fixed. This way you dont need to send wallet names but just public endpoints around.
saholman (Wed, 29 Aug 2018 16:27:05 GMT):
@VitalijReicherdt You probably need to send every message intended for one of those wallets to the sovrin steward endpoint first (what we call the agency endpoint) so that you can decrypt the message the same way each time.
bdeva (Wed, 29 Aug 2018 16:31:09 GMT):
This also became handy when implementing a cloud agent/agency which provides endpoints to multiple mobile edge agents.
bdeva (Wed, 29 Aug 2018 16:43:37 GMT):
@saholman I think the multi-wallet case makes sense when running multiple users (for example different branches of the same organization that require separate access) on the same instance of the agent implementation.
VitalijReicherdt (Wed, 29 Aug 2018 16:53:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QyhYzqnxfBeoNDkqr) @saholman ok, that is a possible solution, i think, it's better as my workaround. thanks!
saholman (Wed, 29 Aug 2018 16:56:43 GMT):
@bdeva Maybe, but based on the Friday agent discussions I think it makes the most sense to have those agents behind an agency. That being said though, your idea of separate endpoints seems like it would also work!
bdeva (Wed, 29 Aug 2018 17:05:48 GMT):
@saholman Are the descriptions of the different kind of agents (cloud agent/agency, mobile edge agent, etc.) in the readme of the indy-agent repo up to date with the Friday discussions or are there any significant changes to that?
saholman (Wed, 29 Aug 2018 17:10:54 GMT):
Which README? I'm not seeing one describing the different types. The Sovrin Glossary should probably be the source of truth for those definitions.
bdeva (Wed, 29 Aug 2018 17:11:55 GMT):
This one: https://github.com/hyperledger/indy-agent/tree/master/docs
mhailstone (Wed, 29 Aug 2018 17:36:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xrPxWtCJ4pLkYMa9P) @bdeva Good point. That document is not totally current, but still useful. We should probably steer readers to the https://github.com/hyperledger/indy-hipe repository for the latest information and discussion.
kdenhartog (Thu, 30 Aug 2018 00:13:18 GMT):
Here's an introductory look at the slides for my presentation on JWMs friday. I assume there's going to be a lot of questions since I haven't shared many details about them so far. I'd greatly appreciate comments or questions that you have about them so I can address them in the slides of the presentation and be prepared friday to discuss. https://docs.google.com/presentation/d/1y-r0zbugF0-j75GUWBC_3tIHDokPa8f1eQYU6IW14N8/edit#slide=id.g40985f9265_0_43
TelegramSam (Thu, 30 Aug 2018 16:38:53 GMT):
@dbluhm I made a pull request for the threading stuff we talked about last friday. Holler with commentary.
dbluhm (Fri, 31 Aug 2018 07:04:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=6hMA9FmeTFPLmEHwM) @TelegramSam I left a review with a couple of questions. Thanks for the PR!
dbluhm (Fri, 31 Aug 2018 07:11:37 GMT):
@mhailstone @ryanwest6 let me know about your PR against his connection protocol HIPE. He asked me to take a look at it before merging it himself and just haven't had a chance to look at it-- sorry to become a blocker on the HIPE. It looks like I have some discussions to catch up on regarding the connection protocol but before I got behind, I was working on a revision that you can find [here](https://github.com/dbluhm/indy-hipe/tree/connection-protocol/text/connection-protocol). In my revision, I spent a little more time thinking and taking about the key/crypto negotiation. I also tried to streamline the format a bit. I'm not committed to using my revision over direct revisions of Ryan's original PR but if anyone has comments for one way or the other, I'd be happy to hear them.
dbluhm (Fri, 31 Aug 2018 07:11:37 GMT):
@mhailstone, @ryanwest6 let me know about your PR against his connection protocol HIPE. He asked me to take a look at it before merging it himself and just haven't had a chance to look at it-- sorry to become a blocker on the HIPE. It looks like I have some discussions to catch up on regarding the connection protocol but before I got behind, I was working on a revision that you can find [here](https://github.com/dbluhm/indy-hipe/tree/connection-protocol/text/connection-protocol). In my revision, I spent a little more time thinking and taking about the key/crypto negotiation. I also tried to streamline the format a bit. I'm not committed to using my revision over direct revisions of Ryan's original PR but if anyone has comments for one way or the other, I'd be happy to hear them.
TelegramSam (Fri, 31 Aug 2018 09:18:36 GMT):
Related to message structure, from the mind of Tim Bray: https://www.tbray.org/ongoing/When/201x/2018/08/30/Event-Structure
mhailstone (Fri, 31 Aug 2018 13:45:48 GMT):
The Agent call will begin in 15 minutes: https://byu.zoom.us/j/2627891784
kdenhartog (Fri, 31 Aug 2018 15:31:35 GMT):
Slides from the agent call today on JWMs https://docs.google.com/presentation/d/1y-r0zbugF0-j75GUWBC_3tIHDokPa8f1eQYU6IW14N8/edit#slide=id.g40985f9265_0_0
sureshtedla (Fri, 31 Aug 2018 17:29:11 GMT):
Has joined the channel.
gen_el (Sat, 01 Sep 2018 15:04:55 GMT):
Has joined the channel.
SherifMuhammed (Sun, 02 Sep 2018 15:07:33 GMT):
Hi , Is it possible to use Indy as an Authenticator ?
tkdp (Tue, 04 Sep 2018 09:12:11 GMT):
Has joined the channel.
brycebudd (Tue, 04 Sep 2018 15:53:57 GMT):
Has joined the channel.
TelegramSam (Tue, 04 Sep 2018 17:24:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ic2kE4ApSosa29J3w) @SherifMuhammed It is possible to authenticate using the components of Indy, but there is not (yet, anyway) a packed way to do so.
SherifMuhammed (Tue, 04 Sep 2018 21:13:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=baRBPRtFWgAYzW4oP) @TelegramSam @TelegramSam ,Could you please advise, about how to implements such a scenario?
mhailstone (Wed, 05 Sep 2018 21:43:06 GMT):
All,
We are going to discuss a possible agent plugin/module architecture model presented by Spencer Holman.
Topic: Indy Agent Design/Discussion - Friday 9/7/2018
Time: Sep 7, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Thu, 06 Sep 2018 15:07:37 GMT):
All,
Apologize so late. Here is the link to the video folder for last Friday’s call:
https://drive.google.com/drive/folders/1CIUrZZamD5vxYYa3YCUxUYy-iC53Rknq
esplinr (Thu, 06 Sep 2018 19:58:07 GMT):
Many of you are familiar with Evernym's Connect.Me application. We want to contribute it to the Indy community to make it a reference mobile agent, but there is some work to do to remove dependencies on Evernym's agency and Sovrin specific technology. However, we want people to see what we have done, so here is a preview of the code:
https://github.com/evernym/sovrin-connector-preview
Note the lack of an open source license. We still need to finalize a lot of things.
tomislav (Thu, 06 Sep 2018 21:12:19 GMT):
Wow! Thank you for sharing this, this is fantastic. Can't wait to set it up and check it out
tomislav (Thu, 06 Sep 2018 21:12:19 GMT):
Wow! Thank you for sharing this, this is fantastic. Can't wait to set it up and check it out @esplinr
mawi (Fri, 07 Sep 2018 09:23:27 GMT):
Has left the channel.
AxelNennker (Fri, 07 Sep 2018 10:10:20 GMT):
Message types https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/connections/index.js#L12 and https://github.com/hyperledger/indy-agent/tree/master/docs do not match. Not that they have but...
PhillipGibb (Fri, 07 Sep 2018 11:07:41 GMT):
@esplinr that is great. This is a missing piece for me at the moment - for using vcx
PhillipGibb (Fri, 07 Sep 2018 11:09:57 GMT):
Anyone using the indy-agent to connect to a local (docker) pool?
I am having trouble ledgering an agent DID with an endpoint.
The code sets up a steward which is only stored in the wallet.
The ledgering the agent did fails because the steward verkey cannot be found
PhillipGibb (Fri, 07 Sep 2018 11:38:05 GMT):
nevermind, :face_palm: it is all about the seed
dbluhm (Fri, 07 Sep 2018 14:50:42 GMT):
For those on the agent call this morning, if you could summarize the HIPE discussion here in Rocket.chat, that would be great! @mhailstone @burdettadam
haggs (Fri, 07 Sep 2018 15:31:39 GMT):
Sure I'll take a stab
haggs (Fri, 07 Sep 2018 15:38:01 GMT):
"HIPEs pointing to code or possibly pseudocode? as needed. Different types of HIPEs, proposal: one is more philosophy based where the other comes with code
Process
Philosophy
Tactical design" were the notes I had
haggs (Fri, 07 Sep 2018 15:39:16 GMT):
We should be aiming for code and resolve, but we are running on a lot of assumptions in our HIPEs about DIDocs and the sdk parts that haven't been coded or thought through
nhelmy (Fri, 07 Sep 2018 16:47:49 GMT):
Does anybody have the slides from today's Agent call? @mhailstone or should i just be patient :nerd:
saholman (Fri, 07 Sep 2018 17:12:15 GMT):
https://docs.google.com/presentation/d/18xwDGMSzpNd2UeM2rBGYv_w8cbMeyKyN87Ix7nH-IP8/edit?usp=sharing
saholman (Fri, 07 Sep 2018 17:12:15 GMT):
@nhelmy https://docs.google.com/presentation/d/18xwDGMSzpNd2UeM2rBGYv_w8cbMeyKyN87Ix7nH-IP8/edit?usp=sharing
mhailstone (Fri, 07 Sep 2018 17:12:22 GMT):
Here is a link to the recording of today's Agent call: https://drive.google.com/drive/folders/1Xbjl-QqK7F0qByYPtjg2JWd8QR6S3uX-
nhelmy (Fri, 07 Sep 2018 17:17:59 GMT):
Thanks! @saholman
saholman (Fri, 07 Sep 2018 17:21:12 GMT):
For those trying to run the new modular agent, you will need to change the path in the config.yml file to point to your modules directory until we get the modules_path setup.
swcurran (Fri, 07 Sep 2018 17:23:46 GMT):
Since the agents are intended to be executables, should we just use PATH?
saholman (Fri, 07 Sep 2018 17:26:46 GMT):
We could, but I don't think that makes sense yet since these executables aren't intended to be called from the command line by a person. We could just have it check in the modules directory though, so just `../modules` from where the agent is running.
esplinr (Fri, 07 Sep 2018 17:46:26 GMT):
I understand that there were some questions on the call today about libvcx, and the progress we are making integrating it into the Indy SDK.
esplinr (Fri, 07 Sep 2018 17:47:47 GMT):
The current status is that the pull request is merged, but we consider the library experimental.
esplinr (Fri, 07 Sep 2018 17:48:25 GMT):
It still depends on the proprietary Evernym Agency, and the Evernym manner of creating agent connections. We need to bring it inline with the standard used in the reference agents.
esplinr (Fri, 07 Sep 2018 18:24:00 GMT):
You can track the work here:
https://jira.hyperledger.org/browse/IS-849
peacekeeper (Fri, 07 Sep 2018 19:13:16 GMT):
What's the current status/roadmap for microledgers? Is this available (even in an experimental form)? I can't see this topic on the roadmap: https://wiki.hyperledger.org/projects/indy/roadmap
esplinr (Fri, 07 Sep 2018 19:36:13 GMT):
Lovesh has been working on some POCs. The Evernym Indy team won't be adding it to our roadmap until we see the results of his efforts.
esplinr (Fri, 07 Sep 2018 19:36:17 GMT):
@peacekeeper
kdenhartog (Fri, 07 Sep 2018 19:44:43 GMT):
@peacekeeper here's a link to his branch https://github.com/lovesh/indy-sdk/tree/rsm
peacekeeper (Fri, 07 Sep 2018 19:56:44 GMT):
Thx!
PhillipGibb (Sat, 08 Sep 2018 05:29:52 GMT):
I am using the Indy-agent together with the docker nodes from indy-sdk and the genesis file from the cli directory
The Steward is setup with the seed: 000000000000000000000000Steward1
Then when the nym is signed and submitted I get:
`Some(NodeReply("{\"reason\":\"client request invalid: UnauthorizedClientRequest(\'Th7MpTaRZVRYnPiabds81Y is neither Trustee nor owner of ...`
PhillipGibb (Sat, 08 Sep 2018 06:32:00 GMT):
cli:
`ledger get-nym did=Th7MpTaRZVRYnPiabds81Y`
results in:
```Following NYM has been received.
Metadata:
+------------------------+-----------------+---------------------+------------------+
| Identifier | Sequence Number | Request ID | Transaction time |
+------------------------+-----------------+---------------------+------------------+
| Th7MpTaRZVRYnPiabds81Y | 2 | 1536388222753295000 | - |
+------------------------+-----------------+---------------------+------------------+
Data:
+------------------------+------------------------+-------------------------+---------+
| Identifier | Dest | Verkey | Role |
+------------------------+------------------------+-------------------------+---------+
| V4SGRU86Z58d6TV7PBUe6f | Th7MpTaRZVRYnPiabds81Y | ~7TYfekw4GUagBnBVCqPjiC | STEWARD |
+------------------------+------------------------+-------------------------+---------+```
PhillipGibb (Sat, 08 Sep 2018 06:32:33 GMT):
where V4SGRU86Z58d6TV7PBUe6f is a TRUSTEE
PhillipGibb (Sat, 08 Sep 2018 06:33:57 GMT):
If I can't send a nym to the ledger with the Steward DID then how do I use the TRUSTEE DID (I only have the Steward seed)
PhillipGibb (Sat, 08 Sep 2018 06:54:32 GMT):
So it works if I make use of the seed: 000000000000000000000000Trustee1
avestaa (Mon, 10 Sep 2018 16:18:39 GMT):
Has joined the channel.
json (Mon, 10 Sep 2018 21:28:26 GMT):
Hey guys. Testing out the new `docker compose` way of running the Nodejs agent... getting some errors & no luck on any of the Localhost ports
json (Mon, 10 Sep 2018 21:28:32 GMT):
Clipboard - September 10, 2018 3:28 PM
json (Mon, 10 Sep 2018 21:28:38 GMT):
Anyone seen this?
swcurran (Tue, 11 Sep 2018 03:59:00 GMT):
@json - have you run it with the old agents? I found that when I first ran it I was getting problems because docker was used using cache layers. Try rebuilding using the no cache option - `docker-compose build --no-cache` and then try `docker-compose up` after that. The build will take a while... :-)
swcurran (Tue, 11 Sep 2018 03:59:00 GMT):
@json - have you run it with the previous version of the agents? I found that when I first ran it I was getting problems because docker was used using cache layers. Try rebuilding using the no cache option - `docker-compose build --no-cache` and then try `docker-compose up` after that. The build will take a while... :-)
swcurran (Tue, 11 Sep 2018 03:59:00 GMT):
@json - have you run it with the previous version of the agents? I found that when I first ran it with new latest version I was getting problems because docker was used using cache layers. Try rebuilding using the no cache option - `docker-compose build --no-cache` and then try `docker-compose up` after that. The build will take a while... :-)
swcurran (Tue, 11 Sep 2018 03:59:00 GMT):
@json - have you run it with the previous version of the agents? I found that when I first ran it with new latest version I was getting problems because docker was used using cached layers. Try rebuilding using the no cache option - `docker-compose build --no-cache` and then try `docker-compose up` after that. The build will take a while... :-)
xnopre (Tue, 11 Sep 2018 08:38:44 GMT):
Hi all,
1/ For a prover, is it mandatory to receive a "credential offer" to be able to send a "credential request" ? Or how can an actor send a "credential request" to an issuer without "credential offer" ?
2/ How can a prover retrieve a "credential definition" (apparently to be done by an issuer) ?
Thanks
json (Tue, 11 Sep 2018 15:02:11 GMT):
thanks @swcurran , I'll try and report back!
json (Tue, 11 Sep 2018 22:02:59 GMT):
tried again with docker-compose build --no-cache, didn't work. Same time out error as last time. It sucks that I'm doing this on Windows 7 , perhaps its an issue with how docker runs in a virtualbox vm? anyone get it working on win?
haggs (Tue, 11 Sep 2018 22:40:21 GMT):
@json What does `docker-compose ps` do for you? Also have you tried --verbose? The Indy error alludes to an unknown indy error so it's hard to tell.
haggs (Tue, 11 Sep 2018 22:40:49 GMT):
Optionally, not sure if this would work, but you could try changing the default 60 second timeout
haggs (Tue, 11 Sep 2018 22:41:03 GMT):
`COMPOSE_HTTP_TIMEOUT`
haggs (Tue, 11 Sep 2018 22:42:39 GMT):
Or check if HTTP/HTTPS is getting in your way and possibly disable? Just some thoughts, not an expert by any means
josh.hill (Wed, 12 Sep 2018 03:34:18 GMT):
@json Have you modified any files? The docker-compose file perhaps?
kdenhartog (Wed, 12 Sep 2018 04:43:16 GMT):
@json is this a timeout when you're interacting with the ledger or another agent?
swcurran (Wed, 12 Sep 2018 15:23:36 GMT):
@json - just reran the script on Win10 and it worked fine. The other thing I've found is problematic is how the IP address is being set - the lines in the manage script where `DOCKERHOST` is set. Do you get a "command not found" error with that? If so, you could replace that with the following and see if that helps - `export DOCKERHOST=${APPLICATION_URL-$(docker run --rm --net=host codenvy/che-ip)}`
swcurran (Wed, 12 Sep 2018 15:25:11 GMT):
@json - sorry - I had posted a reply to the wrong problem :-(. Sorry about that - deleted the note.
mhailstone (Wed, 12 Sep 2018 15:50:46 GMT):
All,
The agenda we have for this Friday's Agent call is:
Managing DID-Related Data In A Domain by Stephen Curran @swcurran
Looking forward to another great discussion on Friday!
Topic: Indy Agent Design/Discussion - Friday 9/14/2018
Time: Sep 14, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
kenebert (Wed, 12 Sep 2018 16:56:52 GMT):
Has joined the channel.
json (Wed, 12 Sep 2018 17:44:53 GMT):
Clipboard - September 12, 2018 11:44 AM
json (Wed, 12 Sep 2018 17:44:54 GMT):
thanks for the replies guys. docker-compose ps looks like this, seenms ok to me?
json (Wed, 12 Sep 2018 17:45:14 GMT):
Haven't modified any files. will try verbose next.. is it just docker-compose up --verbose?
json (Wed, 12 Sep 2018 17:45:14 GMT):
Haven't modified any files. will try verbose next.. is it just `docker-compose up --verbose`?
json (Wed, 12 Sep 2018 17:46:04 GMT):
@kdenhartog Timeout happens about 60 seconds after i launch it, I'm not able to interact with anything at all (none of the websites load, either)
haggs (Wed, 12 Sep 2018 17:48:10 GMT):
in this case actually `docker-compose --verbose up`
haggs (Wed, 12 Sep 2018 17:48:18 GMT):
60 secs in the default timeout
haggs (Wed, 12 Sep 2018 17:48:22 GMT):
is*
json (Wed, 12 Sep 2018 20:29:14 GMT):
```
faber_1 | uERROR|indy::errors::indy | src/errors/in
dy.rs:73 | Casting error to ErrorCode: Timeout
rllib3.connectionpool._make_request: https://192.168.99.100:2376 "GET /v1.25/con
tainers/99705c61f1c4e6b0981e51391d53a9218c565d3fcc31a911cfd6ae58f24163ac/json HT
TP/1.1" 200 None
faber_1 | { IndyError: PoolLedgerTimeout
urllib3.connectionpool._make_request: https://192.168.99.100:2376 "GET /v1.25/co
ntainers/8a1b098b40b6181fea2f56e3d1bebf6f4fcf879b164374cf08d2d4ae955f6fe6/json H
TTP/1.1" 200 None
faber_1 | at Object.callback (/~/nodejs/node_modules/indy-sdk/src/wrapIndy
Callback.js:15:10)
fcaber_1 |ompose.cli.verbose_proxy.proxy_callable: docker logs ->
json (Wed, 12 Sep 2018 20:29:26 GMT):
Here's the result of verbose
json (Wed, 12 Sep 2018 20:29:57 GMT):
192.168.899.100 is docker machine IP
json (Wed, 12 Sep 2018 20:29:57 GMT):
192.168.99.100 is docker machine IP
haggs (Wed, 12 Sep 2018 21:16:00 GMT):
@json Did you follow all steps to make sure pool of local nodes in Docker is the same ip/posts in your transaction genesis? Sounds like an issue with your VM
Rantwijk (Thu, 13 Sep 2018 13:51:28 GMT):
Has joined the channel.
json (Thu, 13 Sep 2018 14:24:45 GMT):
Clipboard - September 13, 2018 8:23 AM
json (Thu, 13 Sep 2018 14:24:47 GMT):
@haggs Not sure what steps you're referring to? I grabbed the head of master from the indy-agent repo, and tried docker compose build. It seems that the pool of nodes ip/ports are defined in docerk-compose.yml? Also, from within the docker host I can ping each of the nodes by their IP (173.17.0.x), I can also ping them from the host machine by adding a static route throguh the docker VM to get to that subnet. And I did port forwarding on VirtualBox's adapter (see screenshot)
json (Thu, 13 Sep 2018 14:24:47 GMT):
@haggs Not sure what steps you're referring to? I grabbed the head of master from the indy-agent repo, and tried docker-compose build. It seems that the pool of nodes ip/ports are defined in docker-compose.yml? Also, from within the docker host I can ping each of the nodes by their IP (173.17.0.x), I can also ping them from the host machine by adding a static route throguh the docker VM to get to that subnet. And I did port forwarding on VirtualBox's adapter (see screenshot)
json (Thu, 13 Sep 2018 14:24:47 GMT):
@haggs Not sure what steps you're referring to? I grabbed the head of master from the indy-agent repo, and tried docker-compose build. It seems that the pool of nodes ip/ports are defined in docker-compose.yml? Also, from within the docker host I can ping each of the nodes by their IP (173.17.0.x), I can also ping them from the host machine by adding a static route through the docker VM to get to that subnet. And I did port forwarding on VirtualBox's adapter (see screenshot)
kdenhartog (Thu, 13 Sep 2018 17:19:42 GMT):
@json Yeah this is a problem with where your IndySDK is sending messages. IndySDK is configured to send messages to 10.0.0.2 (the IPs are statically set in this file - https://github.com/hyperledger/indy-sdk/blob/master/cli/docker_pool_transactions_genesis) change the IPs in this file locally to 127.0.0.1 or change the IP of your docker network to match the file and it should work.
MaheshSharma (Fri, 14 Sep 2018 07:31:12 GMT):
Has joined the channel.
MaheshSharma (Fri, 14 Sep 2018 08:00:33 GMT):
I'm using Indy-cli: We have run command pool(pool1):wallet(alice_wallet):did(Av6...4c3):indy> ledger nym did= adddid verkey= add verkey but we have get from this command:Transaction has been rejected: Invalid format of command params. Please check format of posted JSONs, Keys, DIDs and etc...
json (Fri, 14 Sep 2018 15:27:54 GMT):
@kdenhartog ah thanks, I think this led to another problem. I realized there's no indy-sdk folder in node-modules, so I tried `npm install`. It fails during the indy-sdk install with this error:
```Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
indy.cc
win_delay_load_hook.cc
c:\users\t925489\documents\blockchain\indy-agent\nodejs\node_modules\nan\nan_new.h(208): warning C4244: 'argument': conversion from 'unsigned __int64' to 'double', possible loss of data (compiling source file ..\src\indy.cc) [C:\Users\T925489\Documents\Blockchain\indy-agent\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj]
..\src\indy.cc(248): note: see reference to function template instantiation 'v8::Local
json (Fri, 14 Sep 2018 16:07:43 GMT):
do I have to set up the Indy SDK build environment first? (https://github.com/hyperledger/indy-sdk/blob/master/doc/windows-build.md)? Have not done this yet
json (Fri, 14 Sep 2018 17:56:34 GMT):
AH I see. It seems that npm install happens within the docker-compose process, so I'm thinking I don't have to `npm install` on the host machine. I found some genesis tx data within nodejs/indy/src/pool/index.js, but it seems that the testPoolIp var is already set to 127.0.0.1... any thoughts?
json (Fri, 14 Sep 2018 17:56:37 GMT):
Clipboard - September 14, 2018 11:56 AM
smithbk (Fri, 14 Sep 2018 18:51:00 GMT):
Hi, I'm just beginning to explore the indy-agent repo. Is there any swagger doc (or other) for the user-to-agent and/or agent-to-agent protocol?
smithbk (Fri, 14 Sep 2018 18:52:05 GMT):
or any design docs?
mhailstone (Fri, 14 Sep 2018 19:39:39 GMT):
@smithbk Great initial question. :) But, there actually isn't any swagger document because the protocol is meant to be transport agnostic. A good place to start might be to familiarize yourself with the indy-hipe repository. Here is the PR on the connection protocol: https://github.com/hyperledger/indy-hipe/blob/928eb157e1672199f1a9e7405ecd1c0e7b6658be/text/connection-protocol/README.md
mhailstone (Fri, 14 Sep 2018 19:39:39 GMT):
@smithbk Great initial question. :) But, there actually isn't any swagger document because the protocol is meant to be transport agnostic. A good place to start might be to familiarize yourself with the indy-hipe repository. Here is the PR on the connection protocol: https://github.com/hyperledger/indy-hipe/blob/928eb157e1672199f1a9e7405ecd1c0e7b6658be/text/connection-protocol/README.md. The Wire Messages HIPE is probably a good start as well: https://github.com/hyperledger/indy-hipe/blob/0d807234634a7f95678845ca016b9a9090d1266b/text/wire-messages/README.md
smithbk (Fri, 14 Sep 2018 19:50:23 GMT):
@mhailstone thanks
MaheshSharma (Sat, 15 Sep 2018 10:55:35 GMT):
Any documents for setup and run this python project?https://github.com/hyperledger/indy-agent/tree/master/python
dbluhm (Sat, 15 Sep 2018 14:10:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=D2Hfg3mkxZzpQMv6K) @MaheshSharma The Python agent isn't nearly as polished as the nodejs implementation. I suggest it be used primarily for reference on how to do certain things with Indy over actually running the code *at the moment*. We're actively working on it. @trthhrtz we should get your changes merged into the hyperledger repo
dbluhm (Sat, 15 Sep 2018 14:13:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=D2Hfg3mkxZzpQMv6K) @MaheshSharma That being said, the README should explain how to run it. If it isn't clear enough, DM me and I'll make sure it gets updated.
MaheshSharma (Sat, 15 Sep 2018 14:20:48 GMT):
@dbluhm Thanks. We will setup nodejs.
smithbk (Mon, 17 Sep 2018 18:24:21 GMT):
@mhailstone Can you point me to the series of HIPEs mentioned here, other than the two links you pasted above. ```There are a series of related HIPEs that combine with this HIPE to address the interoperability, including in particular, Agent Messages, DIDDoc Conventions, and Cross Domain Messaging. Those HIPEs should be considered together in understanding Agent-to-Agent interoperability.```
Thanks
json (Mon, 17 Sep 2018 19:51:55 GMT):
Hey all. Managed to get indy-agent running on Linux using docker-compose. Guess there's some problems with docker on windows. Anyways, now that it's running I have a problem where the browser just hangs when visiting localhost:3XXX, sometimes it pulls the login form but other times it's just blank, and I can't log in anyawys (Can't fill in the form or click login button). Any ideas?
json (Mon, 17 Sep 2018 19:51:55 GMT):
Hey all. Managed to get indy-agent running on Linux using docker-compose. Guess there's some problems with docker on windows. Anyways, now that it's running I have a problem where the browser just hangs when visiting localhost:3XXX, sometimes it pulls the login form but other times it's just blank, and I can't log in anyways (Can't fill in the form or click login button). Any ideas?
json (Mon, 17 Sep 2018 19:51:58 GMT):
Clipboard - September 17, 2018 1:51 PM
json (Mon, 17 Sep 2018 19:52:52 GMT):
Clipboard - September 17, 2018 1:52 PM
dbluhm (Mon, 17 Sep 2018 21:08:38 GMT):
@mhailstone @danielhardman or anyone else that may happen to know: I am currently reviewing the connection protocol HIPE, in particular @mhailstone's most recent edits when I came to the idea of "connection keys." Can one of you define what a connection key is for me and its intended use along with how connection keys might be used when connections weren't initiated with an invitation (in the case that Alice is connecting with Faber and just sends a Connection Request to Faber's agent using information published to the ledger)?
kdenhartog (Tue, 18 Sep 2018 00:48:20 GMT):
@dbluhm connection keys are one time use keys used encrypt the request and response and then thrown away. This is done to prevent the key from being able to correlate two parties from their out of band channel to the connection messages later. As for the second question, I'm not sure we went through this. On one hand, you could use the same protocol where the invitation is sent directly to the agent. More efficiently, I could see Alice sending a offer (aka response) first and then the request is sent back from Faber to alice using the information in the Did Doc provided in the offer.
MaheshSharma (Tue, 18 Sep 2018 06:55:21 GMT):
We have a setup Indy - agent project.https://github.com/hyperledger/indy-agent/tree/master/nodejs But showing Error:```
(node:22) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
bob_1 | (node:22) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code
``` Please help me.
RBorst (Tue, 18 Sep 2018 15:53:28 GMT):
Has joined the channel.
PhillipGibb (Wed, 19 Sep 2018 07:06:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=F6bviWZGtQegd9zpQ) @MaheshSharma Did you get everything sorted?
MaheshSharma (Wed, 19 Sep 2018 07:08:09 GMT):
@PhillipGibb Node js demo currently working fine. Thanks.
PhillipGibb (Wed, 19 Sep 2018 07:09:24 GMT):
nice
AxelNennker (Wed, 19 Sep 2018 09:20:49 GMT):
Looking for something I just heard about 'Agent Authorization Policy' which allows to remove my edge agent (mobile phone)'s permission. Where can I find info about this?
mhailstone (Wed, 19 Sep 2018 15:43:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=q8aRfdYMNEsGRp4bD) @dbluhm If an invitation is not initiated, which I highly doubt because an agent needs to have the information contained in the invitation somehow before a Connection Request is given, then all the normal information inside a Connection Request is sufficient. There is no need to use a "connection key" because the agent receiving the Connection Request is assumed to know how to route/handle that message when the sending agent sends the Connection Request message.
mhailstone (Wed, 19 Sep 2018 18:52:52 GMT):
Here is the link to last Friday's Indy Agent call:
https://drive.google.com/drive/folders/1w6ClyzRA443vHhEDbY34s3vzQdxLx7z0
mhailstone (Wed, 19 Sep 2018 18:53:25 GMT):
The agenda we have for this Friday's Agent call is:
Relationship State Machine / Microledgers by Devin Fisher @devin-fisher
Looking forward to another great discussion on Friday!
Topic: Indy Agent Design/Discussion - Friday 9/21/2018
Time: Sep 21, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them
If I am missing something here, other can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them
If I am missing something here, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
If I am missing something here, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
As far as I know, there is no code available for this functionality.
If I am missing something here, or if I am mistaken, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
As far as I know, there is no code available for this functionality.
If I am missing something here, or if I am mistaken, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/trustee_protocols.md
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
As far as I know, there is no code available for this functionality.
If I am missing something here, or if I am mistaken, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/protocol/dkms/trustee_protocols.md:
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
As far as I know, there is no code available for this functionality.
If I am missing something here, or if I am mistaken, others can expand and/or correct me
n3m (Wed, 19 Sep 2018 19:02:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SirQtxCRuuCjxNzky) @AxelNennker Concepts are described here: https://github.com/sovrin-foundation/protocol/blob/master/dkms/
Specific file you are looking for might be:
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent_authorization_policy.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/agent-authz-policy-ledger-interactions.md
- https://github.com/sovrin-foundation/protocol/blob/master/dkms/trustee_protocols.md:
There are a lot of valuable ideas in the other files also, and these might cross reference them. Might not be a bad idea to just go through all of them because it all ties into one important topic.
As far as I know, there is no code available for this functionality.
If I am missing something here, or if I am mistaken, others can expand and/or correct me
Shyam_Pratap_Singh (Thu, 20 Sep 2018 06:47:24 GMT):
Has joined the channel.
freeman (Fri, 21 Sep 2018 12:38:36 GMT):
Has joined the channel.
freeman (Fri, 21 Sep 2018 12:41:24 GMT):
hi i am trying to test the nodejs demo but when i open page for alice or bob :3000 or :3001 a login screen appears and i dont know how to proceed, any help
freeman (Fri, 21 Sep 2018 12:41:25 GMT):
?
n3m (Fri, 21 Sep 2018 12:47:51 GMT):
@freeman based on these files: https://github.com/hyperledger/indy-agent/blob/master/nodejs/config.js and https://github.com/hyperledger/indy-agent/blob/master/nodejs/docker-compose.yml I would say that the password is `PASSWORD=123`
freeman (Fri, 21 Sep 2018 12:51:03 GMT):
@n3m thanks i didnt look into the files, i 'll give it a try :thumbsup:
mhailstone (Fri, 21 Sep 2018 13:45:37 GMT):
Friday Agent call in 15 minutes: https://byu.zoom.us/j/2627891784
freeman (Fri, 21 Sep 2018 17:03:07 GMT):
do you also talk about identity hubs here?
dbluhm (Fri, 21 Sep 2018 17:07:03 GMT):
We focus mostly on the Agent side, our "equivalent" to Hubs, but we are working to be interoperable with hubs
freeman (Fri, 21 Sep 2018 17:12:45 GMT):
is there any difference between cloud agents and hubs, or they have lot in common
freeman (Fri, 21 Sep 2018 17:13:15 GMT):
or pretty m,uch the same?
mhailstone (Fri, 21 Sep 2018 19:42:21 GMT):
All,
Here is the link to our Friday Agent call video/audio/etc today: https://drive.google.com/drive/folders/1CGsTJIW7MFh3FgEV0xqm8HUzo1_Yggnp
dbluhm (Fri, 21 Sep 2018 20:26:38 GMT):
I heard the test suite was mentioned on the call today. Here's an update: the test suite is ready to be used. However, that doesn't imply that it is complete. Tests need to be implemented and I'm happy to help but I do not claim sole responsibility for test development.
n3m (Fri, 21 Sep 2018 21:39:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=NW6aLZhzjzXt4MsEK) @freeman I believe @kdenhartog can provide some answers here
n3m (Fri, 21 Sep 2018 21:39:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=NW6aLZhzjzXt4MsEK) @freeman I believe @kdenhartog can provide some answers here. Let's see what he has to say.
jljordan_bcgov (Sun, 23 Sep 2018 03:59:23 GMT):
There are differences between ID hubs and Agents as they are currently being considered by their respective communities (who are also collaborating). A key difference I believe is that agents are designed to handle verifiable credentials (and DIDs) while ID hubs contemplate containing all kinds of personal data that may or may not be verifiable claims based.
jljordan_bcgov (Sun, 23 Sep 2018 03:59:39 GMT):
There are other differences and well for sure.
Dubh3124 (Sun, 23 Sep 2018 15:57:24 GMT):
Has joined the channel.
Dubh3124 (Sun, 23 Sep 2018 16:01:46 GMT):
I have been going over the python indy-agent and want to start hacking away at it, but before I start is there any updates coming down the pipe for this?
n3m (Sun, 23 Sep 2018 16:26:10 GMT):
@Dubh3124 Are you asking will there be new functionality or will the code change ?
4 The thing with the agents in the ind-agent repo is that they are not complete or compatible. At the current moment there is an effort on standardizing the Agent Protocol so that Interoperability can be achieved.
This is happening on different fronts:
-- Between the parties inside the Indy ecosystem so that all agents that live there can talk to each other
-- Between various different Identity Projects so that different Identity systems can communicate with each others
Short answer is, there will be updates that will change the inner working of the agents that exist in that repo, but I am not sure if those are the updates you were asking about.
Every agent has a different owner, so functionality wise I am not familiar what the roadmap for those agents looks like.
n3m (Sun, 23 Sep 2018 16:26:10 GMT):
@Dubh3124 Are you asking will there be new functionality or will the code change ?
The thing with the agents in the ind-agent repo is that they are not complete or compatible. At the current moment there is an effort on standardizing the Agent Protocol so that Interoperability can be achieved. So they are not meant as a basis for production code yet.
This is happening on different fronts:
-- Between the parties inside the Indy ecosystem so that all agents that live there can talk to each other
-- Between various different Identity Projects so that different Identity systems can communicate with each others
Short answer is, there will be updates that will change the inner working of the agents that exist in that repo, but I am not sure if those are the updates you were asking about.
Every agent has a different owner, so functionality wise I am not familiar what the roadmap for those agents looks like.
Dubh3124 (Sun, 23 Sep 2018 16:53:35 GMT):
Oops I didn't post the indy-agent link I was referring to; https://github.com/hyperledger/indy-agent/tree/master/python . I am mainly asking about both functionality and code change. I am just trying to keep/stay current with Indy, nothing I am working is production code. Actually, in regards to creating another agent, there is a project called Quart which is Flask-like ASGI framework and wanted to integrate the two.
ClearFoundation (Mon, 24 Sep 2018 06:40:01 GMT):
Has joined the channel.
freeman (Mon, 24 Sep 2018 15:02:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=yv5t3DfpTskpfvpFo) @n3m I will appreciate the help. is that I have some doubts. lets say i provide an image hosting service and I want to use indy for authentication and store files(this is what I dont fully understand) for all the users (for what i read) in a DIF Identity Hubs or cloud agents(can I use any of both for that), but the users who wants to store its own files may do it with their own edge agents. Do i have to provide those edge agents? otherwise, How to access files from users if each one of them set it in different schema?
freeman (Mon, 24 Sep 2018 15:02:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=yv5t3DfpTskpfvpFo) @n3m, @kdenhartog I will appreciate the help. is that I have some doubts. lets say i provide an image hosting service and I want to use indy for authentication and store files(this is what I dont fully understand) for all the users (for what i read) in a DIF Identity Hubs or cloud agents(can I use any of both for that), but the users who wants to store its own files may do it with their own edge agents. Do i have to provide those edge agents? otherwise, How to access files from users if each one of them set it in different schema?
freeman (Tue, 25 Sep 2018 11:35:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=yv5t3DfpTskpfvpFo) @n3m, @kdenhartog I will appreciate the help. is that I have some doubts. lets say i provide an image hosting service and I want to use indy for authentication and store files(this is what I dont fully understand) for all the users (for what i read) in a DIF Identity Hubs or cloud agents(can I use any of both for that), but the users who wants to store its own files may do it with their own edge agents. Do i have to provide those edge agents? otherwise, How to access files from users if each one of them set it in different schema?
AxelNennker (Tue, 25 Sep 2018 13:59:06 GMT):
Is it true that the indy-agent implementation sends anoncrypted messages always as {"message": base64message} instead of putting just the base64message on the wire?
AxelNennker (Tue, 25 Sep 2018 14:04:45 GMT):
https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/messages/index.js
AxelNennker (Tue, 25 Sep 2018 14:05:30 GMT):
Why not just post the message and get rid of the waste?
AxelNennker (Tue, 25 Sep 2018 14:06:30 GMT):
Also here https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/handler/index.js#L27
sebastian (Tue, 25 Sep 2018 15:20:08 GMT):
Has joined the channel.
danielhardman (Tue, 25 Sep 2018 17:28:08 GMT):
I'd like to suggest a feature that could be added to A2A comms. This feature, if we pursued it, might modify our threading spec slightly, or it might be totally orthogonal. The feature is what I'll call "thread tracing." It is a way to track what is happening in a complex interaction, across multiple parties, for troubleshooting purposes. I imagine it as something that reports to a sink (monitor of some kind) the arrival of a new message in a thread at a particular party, such that it becomes possible to say: "Oh, the credential offer has been received by 3. Oh, the credential request has been emitted by 7." And so forth.
Evernym has learned that this sort of tracing would be invaluable in troubleshooting; even when Evernym agents comprise both halves of an interaction, and even when the interaction is relatively straightforward, there are still ways that the protocol can get stalled, and sometimes it can be very hard to debug them. When all elements of the software stack for both parties are not owned by the same software vendor, it gets vastly more complex... Besides troubleshooting, there may also be some auditing use cases.
Of course, this feature subverts privacy, so it would have to be totally voluntary. I imagine a sender registers a desire for an interaction to be traced by external monitor/sink X, and then every participant in the interaction decides whether they are willing to honor the request by reporting the progress of the interaction to that monitor when it touches them. I could imagine a tech support person some day trying to help someone figure out why Alice is not able to complete an interaction, and asking her to turn on interaction tracing and doing an experimental, non-privacy-dependent experiment so they can observe where something is stalling.
Is it worth writing a HIPE about this?
TelegramSam (Tue, 25 Sep 2018 21:14:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=zys7A7f8WahziYnp3) @danielhardman I think the need for cross-whatever debugging is pretty fundamental to a good developer experience. The need to see (and likely export) recent messages sent/received by an agent will help that. A tool that combines exported logs from different agents for browsing on a timeline would make that very actionable. What you are proposing sounds like a real-time version of that. You run a tool that gives you an HTTP debugging URI, and you give that to the agents you are testing. Those agents then all send those reports to the debugging service for inspection.
TelegramSam (Tue, 25 Sep 2018 21:25:07 GMT):
To avoid either another spec discussion, or too much reliance on a self-reporting protocol, what if it was just a webhook that consumed json?
TelegramSam (Tue, 25 Sep 2018 21:26:11 GMT):
the agent has the choice on how to filter which messages it sends to the webhook, and it feels very developer-ish (which it should).
swcurran (Wed, 26 Sep 2018 01:12:02 GMT):
@danielhardman - good approach! We're big on making any eco-system developer-friendly and I agree that this will be big help for that. Obviously has to be default off and easily turned off again once activated. But I agree, the distributed debugging will be hard enough, and nice to have a built in monitor without having to add log messages in for debugging. Definitely HIPE-worthy.
TelegramSam (Wed, 26 Sep 2018 10:55:47 GMT):
Requestbin is open source, and has a docker config. https://github.com/Runscope/requestbin
mhailstone (Wed, 26 Sep 2018 20:02:00 GMT):
All,
Our Friday Agent call agenda:
- All things Agent Test Suite by Daniel Bluhm
- Open Discussion (time permitting)
Topic: Indy Agent Design/Discussion - Friday 9/28/2018
Time: Sep 28, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Wed, 26 Sep 2018 20:02:00 GMT):
All,
Our Friday Agent call agenda:
- All things Agent Test Suite by Daniel Bluhm
- Open Discussion (time permitting)
Topic: Indy Agent Design/Discussion - Friday 9/28/2018
Time: Sep 28, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Wed, 26 Sep 2018 20:02:00 GMT):
All,
Our Friday Agent call agenda:
- All things Agent Test Suite by Daniel Bluhm
- Open Discussion (time permitting)
Topic: Indy Agent Design/Discussion - Friday 9/28/2018
Time: Sep 28, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
Thanks for @TelegramSam for conducting the call!
mccown (Wed, 26 Sep 2018 22:04:05 GMT):
Has joined the channel.
MaheshSharma (Thu, 27 Sep 2018 11:04:35 GMT):
How to send Trust Anchor proof request to issuer throw Indy-cli?
Like: according indy-agent node js demo,Alice agent send proof request to bob's agent and faber university. if possible send Trust Anchor proof request to issuer (faber university,Acme Corporation)throw Indy-cli?
karthick15v (Fri, 28 Sep 2018 06:19:20 GMT):
Has joined the channel.
dbluhm (Fri, 28 Sep 2018 13:59:13 GMT):
Is there going to be an issue with the call if it's still in @mhailstone 's personal meeting room thing on zoom?
dbluhm (Fri, 28 Sep 2018 13:59:25 GMT):
@TelegramSam ^^
TelegramSam (Fri, 28 Sep 2018 14:00:17 GMT):
Might be.
TelegramSam (Fri, 28 Sep 2018 14:01:15 GMT):
New Meeting URL: https://zoom.us/j/691024912
TelegramSam (Fri, 28 Sep 2018 14:04:58 GMT):
Friday Agent call URL ^
darrell.odonnell (Sat, 29 Sep 2018 19:33:41 GMT):
uggh - that explains why the room hadn't started. I figured everyone was at RWoT.
Dubh3124 (Sun, 30 Sep 2018 04:43:15 GMT):
So for testing purposes I am mimicking the agent 2 agent onboarding process by storing Agent1's agent1_agent2 (steward_faber_did for similarity) did and verkey in Agent2's wallet. I noticed after storing the did and verkey (did.store_their_did), when listing the dids in Agent2's wallet the did/verkey I stored doesn't show. However, I can still use did. key_for_local_did to get the verkey. Is this by design?
berserkr (Sun, 30 Sep 2018 08:25:25 GMT):
Has joined the channel.
phaniac (Mon, 01 Oct 2018 18:05:13 GMT):
Has joined the channel.
DixonSiu (Tue, 02 Oct 2018 02:37:39 GMT):
Has joined the channel.
DixonSiu (Tue, 02 Oct 2018 02:37:49 GMT):
Hello,
DixonSiu (Tue, 02 Oct 2018 02:37:49 GMT):
Hello,
Hello, this is Dixon from Tokyo. I'm working on Personium Project (OSS) and would like to modify/integrate Personium to become an agent of Sovrin Ecosystem.
mhailstone (Tue, 02 Oct 2018 13:45:32 GMT):
@DixonSiu Welcome! Here is a great place to get started: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md.
Also, the current reference agent can be found at: https://github.com/hyperledger/indy-agent
We are still discussing important changes to the design and infrastructure of agents in the HIPE (Hyperledger Indy Project Enhancements) repository: https://github.com/hyperledger/indy-hipe and https://github.com/hyperledger/indy-hipe/pulls
arjunkhera (Wed, 03 Oct 2018 13:04:06 GMT):
Has joined the channel.
KjeldMortensen (Wed, 03 Oct 2018 14:04:33 GMT):
Has joined the channel.
mitovskaol (Wed, 03 Oct 2018 18:38:48 GMT):
nathan
manishcm (Thu, 04 Oct 2018 18:23:56 GMT):
Has joined the channel.
kdenhartog (Thu, 04 Oct 2018 18:47:30 GMT):
@TelegramSam @mhailstone @swcurran I've updated the AMES HIPE which describes the pack/unpack functions. https://github.com/kdenhartog/indy-hipe/tree/AMES/text/AMES I'd like to go over it tomorrow on the Agent call. Could you take a look over it before then?
swcurran (Thu, 04 Oct 2018 22:30:40 GMT):
@kdenhartog - I'm not going to be able to review it or be on the call. :-(. Sorry about that - hanging out in Salt Lake City and being kept very busy...
mhailstone (Thu, 04 Oct 2018 23:05:42 GMT):
All,
Here is the Friday Agent call agenda:
- Review of HIPEs: Wire Messages, AMES - Matthew Hailstone
- Review of pack/unpack function in Indy-SDK - Kyle Den Hartog
- Open Discussion
Topic: Indy Agent Design/Discussion - Friday 10/5/2018
Time: Oct 5, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Thu, 04 Oct 2018 23:08:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ndQcdASCJ6cmgcuZn) @kdenhartog Will do! Thanks for preparing to talk on that tomorrow. Sorry for the delay. RocketChat crashed on me and just saw this thread.
mhailstone (Fri, 05 Oct 2018 00:25:13 GMT):
@kdenhartog I like the HIPE. The only question/comment I have currently is why have the pack methods return two possible outputs: JSON serialization or Compact serialization? Even thought it's an extra step in the process, it still is an extra step. It's not a big deal, but I'm curious to understand. Maybe that result is common for the JWE spec? Thanks!
kdenhartog (Fri, 05 Oct 2018 05:50:33 GMT):
Originally, that's how it was done to fit with JWEs. In my current rewrite, I've removed the compact serialization.
arunwij (Fri, 05 Oct 2018 06:18:15 GMT):
Hello! I am developing Node JS web application base on Indy-SDK. When Designing the agent, is it okay if one NodeJS server manages multiple User Accounts/Users, or Do i need separate server instance for each user?
arunwij (Fri, 05 Oct 2018 06:18:15 GMT):
Hello! I am developing Node JS web application base on Indy-SDK. I want to clarify how agent architecture works in indy. When Designing the agent, is it okay if one NodeJS server manages multiple User Accounts/Users, or Do i need separate server instance for each user?
arunwij (Fri, 05 Oct 2018 06:18:15 GMT):
Hello! I am developing Node JS web application base on Indy-SDK. I want to clarify how agent architecture works in indy. When Designing the agent, is it okay if one NodeJS server manages multiple User Accounts/Users, or Do i need separate server instance (may be processes) for each user?
arunwij (Fri, 05 Oct 2018 06:18:15 GMT):
Hello! I highly appreciate if you can give me your suggestions. I want to clarify how agent architecture works in indy. I am developing Node JS web application base on Indy-SDK. When Designing the agent, is it okay if one NodeJS server manages multiple User Accounts/Users, or Do i need separate server instance (may be processes) for each user?
TelegramSam (Fri, 05 Oct 2018 13:30:25 GMT):
@arunwij It is important that you keep the user details separate, such as wallets and connections. Outside that, you can use any user/process arrangement that you need for your purposes.
mhailstone (Fri, 05 Oct 2018 13:46:12 GMT):
Agent call starting in 14 minutes: https://byu.zoom.us/j/2627891784
jlin (Fri, 05 Oct 2018 15:07:51 GMT):
Has joined the channel.
mhailstone (Fri, 05 Oct 2018 16:03:00 GMT):
All,
Here is the link to the video of today’s call:
https://drive.google.com/drive/folders/1Kh0kESOIO9au6ecqwY8UQEWoYPVvzdtN
Much appreciation to @kdenhartog for sharing where his work on the pack/unpack functions are in the Indy-SDK and the associated AMES HIPE (https://github.com/hyperledger/indy-hipe/pull/43).
kdenhartog (Fri, 05 Oct 2018 16:13:54 GMT):
Update relevant to call today. I'm not going to be adding the functionality @TelegramSam proposed for parsing "to" keys out. This is much easier to do this in Python or Node.js and I'd prefer not to hold this work up. If someone feels it's absolutely necessary to have at the SDK layer, please make a PR request against my branch and I'll merge it in.
dbluhm (Fri, 05 Oct 2018 16:46:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=e31112d4-2070-4ce1-9c57-6b066f7f9d0d) @kdenhartog I'll have to read up on it but I may be interested in doing this if it makes sense
kdenhartog (Fri, 05 Oct 2018 20:50:50 GMT):
agentrus.png
TelegramSam (Sat, 06 Oct 2018 11:37:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Bx9HJxqH2XoLDBLNW) @dbluhm it'll help as long as unpack wants the verkey as an argument. I'm planning to make a PR for this, but if you try you'l beat me to it.
swcurran (Mon, 08 Oct 2018 03:33:09 GMT):
@kdenhartog - my $0.02CDN on this.
Extracting the "to" verkey is not be sufficient for the edge-to-edge encryption case, and not needed for the Wire Message and Forward use cases.What is needed is either the "from" verkey or the "from" DID#key. Without one of those, the Recipient will not know from whom the message came - both the DID and the agent within the DIDs domain is needed. I believe that information will need to be included in EVERY message where the recipient needs to know that (there might be a few where that is not needed).
With the "to" verkey, a utility could be written to find the "from" DID, but that would still not let the Recipient know the "from" agent. Assuming the authorization will be based on knowing the Agent - and assuming replying to the message also requires knowing the Agent - we need more than the "to" verkey. We don't want information about the sender in the header, so that information must go in the ciphertext.
Am I missing something? Given that, I would say unpack() does not need to be extended to return the to verkey.
swcurran (Mon, 08 Oct 2018 03:33:09 GMT):
@kdenhartog - my $0.02CDN on this.
Extracting the "to" verkey is not be sufficient for the edge-to-edge encryption case, and not needed for the Wire Message and Forward use cases.
What is needed is either the "from" verkey or the "from" DID#key. Without one of those, the Recipient will not know from whom the message came - and both the DID and the agent within the DID domain is needed. I believe that information will need to be included in EVERY message where the recipient needs to know that (there might be a few where that is not needed).
With the "to" verkey, a utility could be written to find the "from" DID, but that would still not let the Recipient know the "from" agent. Assuming the authorization will be based on knowing the Agent - and assuming replying to the message also requires knowing the Agent - we need more than the "to" verkey. We don't want information about the sender in the header, so that information must go in the ciphertext.
Am I missing something? Given that, I would say unpack() does not need to be extended to return the to verkey.
kdenhartog (Mon, 08 Oct 2018 07:06:36 GMT):
The"from" key is already included, but you make a great point about adding the full key. Thanks for pointing this out, this should be fine for now. In the future, let's double back on this and make sure messages won't correlate two DIDs communicating based on messages going back and forth.
kdenhartog (Mon, 08 Oct 2018 07:06:36 GMT):
The"from" key is already included, but you make a great point about adding the full DID. Thanks for pointing this out, this should be fine for now. In the future, let's double back on this and make sure messages won't correlate two DIDs communicating based on messages going back and forth.
kdenhartog (Mon, 08 Oct 2018 07:11:20 GMT):
Also, as an update I've got the code encrypting and partially decrypting right now. It appears I have some bugs in how things are going encoding and decoding. Additional tests need to be written this week to find the bug and get everything working.
baconsandwich (Tue, 09 Oct 2018 13:31:57 GMT):
Am I correct, that it is the agents responsibility to store the DIDs of NYMs that "are known" to a user but not owned by him (in his wallet)? For example when a Trustee or Stewart writes a new NYM to the ledger how do they retrieve the list of known DIDs?
baconsandwich (Tue, 09 Oct 2018 13:33:03 GMT):
Consequentially an agent would have to maintain a list by himself.
MaheshSharma (Tue, 09 Oct 2018 14:50:45 GMT):
Hello, Showing Error in the indy-agent node.js if submit Proof Requests. Please help me ```
```
MaheshSharma (Tue, 09 Oct 2018 14:50:45 GMT):
Hello, Showing Error in the indy-agent node.js if submit Proof Requests. Please help me ```
alice_1 | TypeError: Cannot read property 'cred_info' of undefined
alice_1 | at Object.exports.prepareRequest (/~/nodejs/indy/src/proofs/index.js:83:64)
```
MaheshSharma (Tue, 09 Oct 2018 14:50:45 GMT):
Hello, Showing Error in the indy-agent node.js demo. if submit Proof Requests. Please help me ```
alice_1 | TypeError: Cannot read property 'cred_info' of undefined
alice_1 | at Object.exports.prepareRequest (/~/nodejs/indy/src/proofs/index.js:83:64)
``` https://github.com/hyperledger/indy-agent/tree/master/nodejs
wip-abramson (Tue, 09 Oct 2018 17:41:12 GMT):
Has joined the channel.
haggs (Wed, 10 Oct 2018 02:03:03 GMT):
@MaheshSharma https://github.com/hyperledger/indy-agent/blob/697fe5b8109ad6239a4e1e15dcf4cb0085741e86/nodejs/indy/src/proofs/index.js#L83 iS where that's coming from
haggs (Wed, 10 Oct 2018 02:11:53 GMT):
@MaheshSharma 'let proofRequest = await indy.crypto.authDecrypt(pairwise.my_did, message.message);'
'let credsForProofRequest = await sdk.proverGetCredentialsForProofReq(await indy.wallet.get(), proofRequest);' are right near the water line: https://github.com/hyperledger/indy-agent/blob/697fe5b8109ad6239a4e1e15dcf4cb0085741e86/nodejs/indy/src/proofs/index.js#L83
haggs (Wed, 10 Oct 2018 02:12:25 GMT):
Hopefully that like helps , mind sharing your machine and dev environment for when you figure it out?
mhailstone (Thu, 11 Oct 2018 01:57:12 GMT):
All,
The topic for this Friday's Agent call will be:
- The specification format for message families - Stephen Curran
Topic: Indy Agent Design/Discussion
Time: Oct 12, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
osesov (Thu, 11 Oct 2018 15:06:35 GMT):
Has joined the channel.
json (Thu, 11 Oct 2018 15:47:13 GMT):
Hi guys, wondering if someone can answer a docker-compose question. In docker-compose.yml inside indy-agent/nodejs, where does it get the images from? ie in this line , ``` #
# Agents
# alice:
image: indy-agentjs ```
json (Thu, 11 Oct 2018 15:47:13 GMT):
Hi guys, wondering if someone can answer a docker-compose question. In docker-compose.yml inside indy-agent/nodejs, where does it get the images from? ie in this line , ``` #
# Agents
#
alice:
image: indy-agentjs ```
json (Thu, 11 Oct 2018 15:47:13 GMT):
Hi guys, wondering if someone can answer a docker-compose question. In docker-compose.yml inside indy-agent/nodejs, where does it get the images from? ie in this line , ``` #
# Agents
#
alice:
image: indy-agentjs ```
I can't find `indy-agentjs` on docker hub, so i'm not sure where this is sourced from?
json (Thu, 11 Oct 2018 16:02:57 GMT):
Ok, nvm. I believe it's compiled when built, ```build:
context: .``` makes Docker consume the file named `Dockerfile` which tells it how to build indy-agentjs
TelegramSam (Thu, 11 Oct 2018 16:04:59 GMT):
I don't think we have a good statement of vision for reference cloud agents. Here is my attempt, and I welcome feedback (in doc or here): https://docs.google.com/document/d/1Iweg0KevxLFM8n7SVkiM9Nq4kiJofd7k6tgGeFQpbWQ/edit#
TelegramSam (Fri, 12 Oct 2018 11:28:01 GMT):
The connection protocol work by @trthhrtz has been merged into the indy-agent repository. Thanks and congratulations to Kuzma for your contribution!
mhailstone (Fri, 12 Oct 2018 13:45:00 GMT):
Agent call starting in 15 minutes: https://byu.zoom.us/j/2627891784
kdenhartog (Fri, 12 Oct 2018 15:57:33 GMT):
@baconsandwich
kdenhartog (Fri, 12 Oct 2018 15:57:33 GMT):
@baconsandwich the agent is responsible for storing DIDs that they plan to interact with. Think of this storage like a caching mechanism. They are not responsible for storing the DIDs of everyone though, which is instead the ledger's job. The ledger can be queried to update the wallet as well. Also, in the case of relationship DIDs that are stored off chain, their wallet acts as the caching mechanism for all updates that they've been told by the owner of the DID and related metadata that is being stored in the wallet. These off chain DIDs use microledgers to handle this, which is well documented in the HIPE repo pull request.
TelegramSam (Sat, 13 Oct 2018 12:21:43 GMT):
MR for Vue.js refacor of python ref agent https://github.com/hyperledger/indy-agent/pull/27
haggs (Sat, 13 Oct 2018 20:07:31 GMT):
Will look later @TelegramSam nice work!
DavidHoltz (Sat, 13 Oct 2018 22:03:27 GMT):
Has joined the channel.
TelegramSam (Mon, 15 Oct 2018 13:45:58 GMT):
@haggs Thanks for giving it a look. I'd be very interested in feedback.
TelegramSam (Mon, 15 Oct 2018 19:10:52 GMT):
I think it may be worth pushing the module registration refactor down the schedule some.
danielhardman (Mon, 15 Oct 2018 21:50:01 GMT):
Is anybody interested in comparing Indy's payments interface to the work being done at interledger? https://interledger.org/rfcs/0001-interledger-architecture/#interledger-model
TelegramSam (Tue, 16 Oct 2018 17:41:05 GMT):
Kuzma's merge (which was incorrectly done) has been reverted.
TelegramSam (Tue, 16 Oct 2018 17:41:14 GMT):
PR 31 contains his new code.
TelegramSam (Tue, 16 Oct 2018 17:48:32 GMT):
And PR 31 is now merged with Kuzma's work.
jcnauta (Wed, 17 Oct 2018 14:59:15 GMT):
Has joined the channel.
swcurran (Wed, 17 Oct 2018 15:17:13 GMT):
All,
The topic for this Friday's Agent call will be about Getting Started/Approaches with Indy and Indy Agent Development
- Current issues or problems that people are encountering and possible ideas considered (Thomas Shelton)
- How BC is currently using Docker in their development process and how it facilitates developers consuming their artifacts (Stephen Curran)
- Another example of how to incorporate Docker and debugging in the development process (Mike Lodder)
Topic: Indy Agent Design/Discussion
Time: Oct 19, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/968045741
Or iPhone one-tap :
US: +16465588656,,968045741# or +16699006833,,968045741#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 968 045 741
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 968 045 741
SIP: 968045741@zoomcrc.com
swcurran (Wed, 17 Oct 2018 15:17:13 GMT):
All,
The topic for this Friday's Agent call will be *Getting Started/Approaches with Indy Agent Development*
- Current issues or problems that people are encountering and possible ideas considered (Thomas Shelton)
- How BC is currently using Docker in their development process and how it facilitates developers consuming their artifacts (Stephen Curran)
- Another example of how to incorporate Docker and debugging in the development process (Mike Lodder)
Topic: Indy Agent Design/Discussion
Time: Oct 19, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/968045741
Or iPhone one-tap :
US: +16465588656,,968045741# or +16699006833,,968045741#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 968 045 741
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 968 045 741
SIP: 968045741@zoomcrc.com
mhailstone (Wed, 17 Oct 2018 16:58:17 GMT):
All,
Here is the link to the recording of last Friday's call: https://drive.google.com/drive/folders/1w6y-54bUHP2UlKfeMdROrIWCAybXhNx6
TelegramSam (Wed, 17 Oct 2018 19:06:10 GMT):
New PR for the Vue.js update, now with new and improved message passing features included by Kuzma.
TelegramSam (Wed, 17 Oct 2018 19:06:11 GMT):
https://github.com/hyperledger/indy-agent/pull/32
mhailstone (Wed, 17 Oct 2018 19:19:36 GMT):
@TelegramSam Approved and merged PR
TelegramSam (Wed, 17 Oct 2018 19:30:56 GMT):
-- ref agent standup --
I finished and submitted the Vue.js refactor to the ref agent. Forward js work should use Vue.js, and I'm here to help.
swcurran (Wed, 17 Oct 2018 21:04:27 GMT):
@TelegramSam - Any instructions on using the python agent? I'm trying to run it. I got the server started at an address and I have a token. Don't know how to use it.
swcurran (Wed, 17 Oct 2018 21:04:38 GMT):
Setting up a docker-compose file so I can see what it does.
swcurran (Wed, 17 Oct 2018 21:05:04 GMT):
Maybe have a Zoom session?
swcurran (Wed, 17 Oct 2018 21:21:58 GMT):
Got it working. Now to figure out what to do with it.
swcurran (Wed, 17 Oct 2018 21:29:29 GMT):
OK - done for now - I was able to start up two agents and create a wallet for each (once). I could not get them to connect - not sure what "endpoint" was intended to be. I'm sure there is more to be done to get this going. I have the code live mounted, but have not tested using it that way.
It would be good to get a live demo to know what is supposed to happen.
swcurran (Wed, 17 Oct 2018 23:11:57 GMT):
Put in a PR for the work that I just did. If you want to try it, you can clone this repo - https://github.com/swcurran/indy-agent and then see the instructions in the python folder and the docker-compose-manage.md
I could not get a connection to happen yet, but I think I just need to spend a bit more time with the devs to figure out why.
dbluhm (Thu, 18 Oct 2018 00:16:25 GMT):
The endpoints that you're supposed to hit are not currently very obvious. We need to add this in to the documentation. But connection offers should hit the endpoint `/offer` and you need to include http. So to send one to local host on port 8080, the string would be `http://localhost:8080/offer`
dbluhm (Thu, 18 Oct 2018 00:16:46 GMT):
Not sure if this is the issue you are experiencing or not @swcurran
swcurran (Thu, 18 Oct 2018 00:29:19 GMT):
No luck - but a different error. The Sender agent gets an error, the Recipient agent doesn't get anything (not surprising). Here's the stack trace:
```
agent1_1 | Received "{"type":"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/sovrin.org/ui/1.0/send_invite","id":"7dc8dd4739794431a3844f95298a6735","content":{"name":"StephenAlice","endpoint":"http://localhost:3001/offer"}}"
agent1_1 | Task exception was never retrieved
agent1_1 | future:
swcurran (Thu, 18 Oct 2018 00:29:56 GMT):
Running on localhost ports 3000 and 3001
TelegramSam (Thu, 18 Oct 2018 12:46:52 GMT):
@swcurran open a browser to the ip and port listed.
TelegramSam (Thu, 18 Oct 2018 12:48:41 GMT):
it looks like one of those ports has something else running on it already.
swcurran (Thu, 18 Oct 2018 17:30:53 GMT):
Opening browser to that port lets me log in.
TelegramSam (Thu, 18 Oct 2018 19:12:02 GMT):
the broken one? might be an orphaned instance.
swcurran (Thu, 18 Oct 2018 20:17:34 GMT):
Both can be accessed, and I can log into both. When I try to do a connection from one, it gives me that error, and continues. The other never gets touched and likewise continues along.
dbluhm (Thu, 18 Oct 2018 21:05:10 GMT):
I submitted a PR to indy-agent that will assist in routing by message family rather than by whole type strings. @TelegramSam and others, your feedback would be appreciated.
dbluhm (Thu, 18 Oct 2018 21:05:25 GMT):
https://github.com/hyperledger/indy-agent/pull/35
swcurran (Fri, 19 Oct 2018 13:52:11 GMT):
Note the new Zoom for this morning's call:
Topic: Indy Agent Design/Discussion
Time: Oct 19, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/968045741
swcurran (Fri, 19 Oct 2018 13:53:11 GMT):
Agenda document: https://docs.google.com/document/d/1PYB4Gb_AIlGEb5c8wVdgmg-dam1YLUaKUKEi1axwg_A/edit?usp=sharing
lynn.bendixsen (Fri, 19 Oct 2018 14:08:19 GMT):
Has joined the channel.
swcurran (Fri, 19 Oct 2018 16:46:01 GMT):
The recording from today's Indy Agent Working Group Call is now posted: https://drive.google.com/drive/folders/1k2JBdmK8dKSqvi7ZTuZNJKpueX7L2hZM?usp=sharing
swcurran (Fri, 19 Oct 2018 16:48:13 GMT):
Notes from the meetings and links referenced in the call are included in the Agenda: https://docs.google.com/document/d/1PYB4Gb_AIlGEb5c8wVdgmg-dam1YLUaKUKEi1axwg_A/edit?usp=sharing
TelegramSam (Sat, 20 Oct 2018 03:45:08 GMT):
doc updates. The scope document needs particular review: https://github.com/hyperledger/indy-agent/pull/36
nhelmy (Mon, 22 Oct 2018 05:49:27 GMT):
@Gdl
nhelmy (Mon, 22 Oct 2018 05:51:51 GMT):
@TelegramSam @kenebert Here's what I got so far around credentials. Feels like I need to know more about how data will be inputted in the UI but here's a start. https://github.com/unveil-social/indy-agent/tree/nader-wip/python
nhelmy (Mon, 22 Oct 2018 05:51:51 GMT):
@TelegramSam @kenebert Here's what I got so far around the indy-agent credentials module. Feels like I need to know more about how data will be inputted in the UI but here's a start. https://github.com/unveil-social/indy-agent/tree/nader-wip/python
arunwij (Wed, 24 Oct 2018 13:50:37 GMT):
Hello Everyone, I highly appreciate if anyone can give me guide one this. Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter?Thank you.
arunwij (Wed, 24 Oct 2018 13:50:37 GMT):
Hello Everyone, I highly appreciate if anyone can give me guide one this. Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. Ho identity user going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter?Thank you.
arunwij (Wed, 24 Oct 2018 13:50:37 GMT):
Hello Everyone, I highly appreciate if anyone can give me guide one this. Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. How identity owner going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter? Thank you.
arunwij (Wed, 24 Oct 2018 13:50:37 GMT):
Hello Everyone, I highly appreciate if anyone can give me guide one this. Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. How identity owner going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter? (Does indy have a solution for this?) Thank you.
arunwij (Wed, 24 Oct 2018 13:50:37 GMT):
Hi can someone give me guide one this? Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. How identity owner going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter? (Does indy have a solution for this?) Thank you.
mhailstone (Wed, 24 Oct 2018 16:34:50 GMT):
All,
The agenda for this Friday's Agent call is:
- IIW Review
- Reference Agent Review
Topic: Indy Agent Design/Discussion
Time: Oct 26, 2018 9:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
mhailstone (Wed, 24 Oct 2018 16:34:50 GMT):
Please note that the Agent call Friday will be on the regular BYU zoom again.
arunwij (Thu, 25 Oct 2018 03:18:18 GMT):
Hi can someone give me guide one this? Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. How identity owner going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter? (Does indy have a solution for this?) Thank you.
arunwij (Thu, 25 Oct 2018 03:18:18 GMT):
Hi can someone give me guide on this? Think if a person without having any verifiable credential(VC) initially. How that person going to get first VC from a issuer. How identity owner going to verify it is him/her. Do we have to have physical contact with the issuing entity? What are the possible solutions for this matter? (Does indy have a solution for this?) Thank you.
arjunkhera (Thu, 25 Oct 2018 12:31:01 GMT):
@arunwij , this is an open ended question. Think about it like this, in real world, when you are born you don't have any previous credentials. You always build them up as time passes. Indy is just a means of providing the ability to share and manage credentials in the digital form. So for example, if Indy was to be made live today, efforts will be made to onboard existing physical credentials in a digital form first. The network will gain the necessary traction only with time and usage.
twshelton (Thu, 25 Oct 2018 13:39:18 GMT):
@arunwij Initially I think we'll follow the same norms we follow today. Physical contact will likely be the best approach initially to establish a connection but there are different approaches to handle cases where physical contact is not possible such as a dead-drop at a trusted virtual location. Once the connection is made, credentials can be issued as needed. For example, you may need to visit your university to collect your transcripts after graduation. You would establish a connection with the university at that that time and they can issue you a VC (diploma).
jmason900 (Thu, 25 Oct 2018 15:13:21 GMT):
Has joined the channel.
haggs (Thu, 25 Oct 2018 20:48:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=voHh4Dot8GLN2cBT8) @nhelmy https://github.com/hyperledger/indy-agent/compare/master...unveil-social:nader-wip Here's a good compare for those interested. I'll have to look at this later.
haniavis (Thu, 25 Oct 2018 22:47:17 GMT):
Has joined the channel.
arunwij (Fri, 26 Oct 2018 03:02:08 GMT):
@arjunkhera @twshelton Thank you for the answers. @twshelton can you explain what are the approaches we can use when a physical connection is not possible? Can we have a consensus-based mechanism, where reputed trust anchors or identity owners vote for our initial self-attested identity?
ShubhamSingh18 (Fri, 26 Oct 2018 07:13:45 GMT):
Has joined the channel.
jljordan_bcgov (Fri, 26 Oct 2018 13:43:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=vxyvm2EFQvashpi9P) @arunwij Here is a lnk to a Medium article by a colleague in the Canadian government. It describes how we are approaching these kinds of questions in the identity space. https://medium.com/@trbouma/trusted-digital-identity-processes-and-methods-25cfbfbbee2e
What you are talking about here are processes by which identity verification can be accomplished.
In the end I tend to divide up the question of trust into two parts ... is there a trustworthy technical means to transmit bits from A to B (I think we are approaching this with Indy and other decentralized identity tech) and secondly do I trust the processes by which the issuer issued those bits to some entity. That is a social / business / legal question that each verifier needs to answer for themselves. If a group of verifiers get together and come to a shared view on what these trusted processes should be then we might call that a trust framework ... becauce this is a shared view amongst a group describing the set of conditions whereby they will trust the data issued by issuers adhering to the processes described in the trust framework
mhailstone (Fri, 26 Oct 2018 13:52:20 GMT):
The agent call will begin in 10 minutes: https://byu.zoom.us/j/2627891784
TelegramSam (Fri, 26 Oct 2018 14:49:37 GMT):
Indy Agent Working Group Call Survey
Our community has expanded substantially since we began this call, and we are seeking to choose a meeting time that allows anyone interested to join our calls. We realize that not every time will work for everybody, and this step will gather data about what will work and what will not.
Visit this link to indicate meeting times that work for you. Make sure you select your timezone, then click (or paint, dragging when mouse button is down) across the times that work for you. Exclude any existing meetings or other conflicts, but please paint any other times that you would be able to make a call. Our call times are 90 minutes.
Please circulate this link with anybody you know in the community that would like to attend this call.
Link for time selection: http://whenisgood.net/ssbykct
danielhardman (Fri, 26 Oct 2018 15:37:51 GMT):
agent taxonomy deck: http://bit.ly/2JgDMpT
indy a2a for web deck: http://bit.ly/2qcbmEH
darrell.odonnell (Fri, 26 Oct 2018 16:40:05 GMT):
for next week's (short) discussion about App / Agent / Wallet I will toss out a question to seed some thinking: *Is Evernym's Connect.Me a Wallet? An App? An Agent?*
danielhardman (Fri, 26 Oct 2018 17:37:45 GMT):
My preferred answer to @darrell.odonnell 's question is:
```Connect.Me IS an app. It HAS a wallet. The app USES an agent as one of its components.```
I like this answer because it maps most clearly to the architectural paradigms I want to advocate. But I must acknowledge that others are using the terms differently. So I'm recommending/advocating on the basis of preference here, not necessarily on the basis of how terms are widely used.
darrell.odonnell (Fri, 26 Oct 2018 18:00:55 GMT):
Cool and that aligns with my general concept. So further questions: *Do multiple Agents use a single Wallet? Similarly, do multiple Apps have access to a single Wallet?*
danielhardman (Fri, 26 Oct 2018 19:55:09 GMT):
Typically, a mobile app consists of a front end that runs on the mobile device, and a back end that runs in the cloud. I can imagine several different app development paradigms that give different answers to Darrell's questions:
1. A rich agent like the one inside Connect.Me could cooperate with an equally rich cloud agent owned by the same person, such that the "app" has two agents "in" it -- one in the cloud, and one on the mobile device.
2. A dumb app has no real agent code running inside it, but it hosts web views that are built entirely by a cloud agent. The wallet and all state are stored by the back end. Thus, there is no real agent on the mobile device, but only one agent--and it's in the cloud.
3. A rich agent like the one inside Connect.Me is installed alongside thin agents (see http://bit.ly/agents-by-complexity) that each specialize in a single pairwise relationship. So Alice has Connect.Me on her phone, but also a Sovrin-enabled Fitbit app, and a Sovrin-enabled banking app, and a Sovrin-enabled app from her school, etc. These thin agents note that the rich agent has registered to handle URIs of type "ssi://". They use URI-based message passing to pass A2A messages back and forth between themselves and the rich agent. The thin agents ask the rich agent to store the key and DID and credentials for their one relationship in the rich agent's wallet, and they each possess a key that they use to authcrypt the A2A messages that they exchange with the rich agent. This allows multiple apps to have Sovrin/Indy features, but only one app to be the master gatekeeper for the wallet. (If we don't do something like this, then each Sovrin-enabled app will silo the person's identity; you'll have the identity shard for Fitbit, and the identity shard for banking, etc). You'll also have a problem with independent link secrets.
darrell.odonnell (Fri, 26 Oct 2018 20:14:59 GMT):
@danielhardman your #3 sounds to me like Agents (Connect.Me and the "thin ones") hitting a single wallet. I would love to see a strong line drawn between Agent & Wallet to see where the thin agent would talk to the Wallet. I need to think and doodle on this one though.
darrell.odonnell (Fri, 26 Oct 2018 20:17:11 GMT):
your deck from today will help with that thinking
ShubhamSingh18 (Sat, 27 Oct 2018 06:46:16 GMT):
Getting this error while sending the connection request from Alice to Bob
ShubhamSingh18 (Sat, 27 Oct 2018 06:46:18 GMT):
Task exception was never retrieved
future:
dbluhm (Sat, 27 Oct 2018 12:54:50 GMT):
We need to more clearly document this but when sending the connection offer, the URL needs to look like `http://172.17.0.3:8095/offer`
dbluhm (Sat, 27 Oct 2018 12:55:24 GMT):
@ShubhamSingh18
arunwij (Sat, 27 Oct 2018 13:51:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=KBLTbwyyAv3ttcPkR) Thank you for the explanation @jljordan_bcgov. This is far more complicated than what I thought earlier. I have gone through the article and yes, identity verification processes what I am looking for. I get that, we need to create some kind of agreement between issuers (create trust framework). I have gone through the Pan-Canadian Trust Framework as well. Do you have any information on how actually this digital trust framework work which steps initial identity owner should take (some example). If you have some info let me know. Thank you again for the guidance.
jljordan_bcgov (Sat, 27 Oct 2018 15:01:37 GMT):
It will be a bit of information overload but here is a like to a github repo with some drafts where you can find the kind of conformance criteria I’m pointing to ... https://github.com/canada-ca/PCTF/blob/master/verified-person/verified-person.md @arunwij [ ](https://chat.hyperledger.org/channel/indy-agent?msg=sSZjxzibmdSkPm99i)
jljordan_bcgov (Sat, 27 Oct 2018 15:02:35 GMT):
If you look around that repo you will find quite a few documents that would comprise a national level trust framework
arunwij (Mon, 29 Oct 2018 03:25:23 GMT):
@jljordan_bcgov Thank you for the information.
manishcm (Mon, 29 Oct 2018 05:45:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jQoRT73dARsP8Y2aq) @danielhardman @danielhardman As per #3, should there be exactly one rich agent based application i.e Connect.Me? Should all thin agent based apps need to have hard dependency on Connect.Me for the Sovrin based functionality to work?
manishcm (Mon, 29 Oct 2018 05:45:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jQoRT73dARsP8Y2aq) @danielhardman As per #3, should there be exactly one rich agent based application i.e Connect.Me? Should all thin agent based apps need to have hard dependency on Connect.Me for the Sovrin based functionality to work?
ShubhamSingh18 (Mon, 29 Oct 2018 06:51:21 GMT):
Can we create our own network in place of sovrin network
manishcm (Mon, 29 Oct 2018 07:00:54 GMT):
@ShubhamSingh18 Yes. Have a look at BCovrin Indy Network: https://von.pathfinder.gov.bc.ca/clicky-things
manishcm (Mon, 29 Oct 2018 07:03:23 GMT):
You can also create a virtual Indy network for dev purpose: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker
ShubhamSingh18 (Mon, 29 Oct 2018 07:14:05 GMT):
Can anyone tell me the architecture of hyperledger indy and how the components are connected to each other
ShubhamSingh18 (Mon, 29 Oct 2018 07:18:42 GMT):
if any diagram please give
haggs (Mon, 29 Oct 2018 17:34:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=80afe978-b9dd-4320-8c7d-94e35319fe42) @dbluhm Thanks for that! We should add that to hyperledger/indy-agent/python README.md as well as @swcurran 's forked repo which has the (really convenient and nice) .manage scripts for docker-compose-manage.md. Alternatively we could conditionally check for the `http://` inside the agent code?
mhailstone (Mon, 29 Oct 2018 20:55:13 GMT):
All,
Here is the link to the recording of Friday's Agent call: https://drive.google.com/drive/folders/1JOyXUHccJsKLIY0zcsFp8NMV71RhPPVB
Dubh3124 (Mon, 29 Oct 2018 23:19:39 GMT):
Has there been a consensus in regards to packaging/unpackaging agent to agent connections (messages?). I found some information and slides in the indy-agent Google docs on wire messaging but it seems more related to Sovrin. If there is more information in regards to this I would appreciate it.
dbluhm (Mon, 29 Oct 2018 23:32:48 GMT):
@Dubh3124 this is a point of active discussion. The indy-hipe repository contains what has been proposed so far (most of those proposals are still in PRs)
dbluhm (Mon, 29 Oct 2018 23:36:53 GMT):
There's definitely a more elegant way to handle a bad url than what we're doing now. I think we need more changes with the different exposed endpoints as well. I'll definitely try to get docs updated though (or accept PRs from others with doc fixes)
dbluhm (Mon, 29 Oct 2018 23:37:02 GMT):
@haggs ^
danielhardman (Mon, 29 Oct 2018 23:48:19 GMT):
On the Friday agent call, @smithbk asked a great question about why we wouldn't use TLS between client and server, even if we turned browsers or other web-ish things into static agents. I promised I'd engage on this topic on Rocket.Chat. I spent a bit of time trying to make my thoughts coherent, and came up with the following doc. Would be glad of feedback:
https://docs.google.com/document/d/1npeO4U1w8VffmSglvp5jrRc4xwlZiMrDYK0KOe6U3FE/edit#
haggs (Tue, 30 Oct 2018 01:29:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fd630298-f17c-4602-9216-011216634965) @dbluhm Sounds like a PR for doc fixes should be in the works. I'll work on a rough draft as there are multiple readme fixes that I can see that might help the community (py env, docker entirely, and a mix in the middle) and others I'm missing. RE "I think we need more changes with the different exposed endpoints as well." Just to extrapolate on that, are you referring to non-http endpoints or just different ports and setups (devops specific)? Thanks for the input!
swcurran (Tue, 30 Oct 2018 02:08:42 GMT):
@dbluhm @TelegramSam Should I assume the PR I put in about docker-compose is not going to be accepted? I've not seen any feedback. We continue to evolve von-image with more features (more of a ledger browser has been added).
https://github.com/hyperledger/indy-agent/pull/33
kdenhartog (Tue, 30 Oct 2018 02:32:21 GMT):
https://signal.org/blog/sealed-sender/ @MALodder
NikitaVolkov (Tue, 30 Oct 2018 12:05:00 GMT):
Has joined the channel.
dbluhm (Tue, 30 Oct 2018 13:45:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Aq77qWc4jdYgFt7WL) @swcurran Just haven't had time to review it yet
TelegramSam (Tue, 30 Oct 2018 14:42:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jQoRT73dARsP8Y2aq) Per #2. I'm wondering if you have a UI that acts like a thin agent, and that way authentication happens the agent way, not some arbitrary user way. In other words, the 'real' agent is in the cloud, but the UI is a special built agent that performs the role of an administrative UI. I'm still thinking through how that UI agent manages keys in a user sane way.
TelegramSam (Tue, 30 Oct 2018 14:43:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Aq77qWc4jdYgFt7WL) @swcurran Reviewing this is on my short list
TelegramSam (Tue, 30 Oct 2018 15:08:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Lov8ZpxS54HhzmM8f) @danielhardman Super Good. Comments in Article. I'm interested in discussing client configuration in Option 1.
TelegramSam (Tue, 30 Oct 2018 20:56:21 GMT):
@dbluhm's PR for routing by message families has been merged..
danielhardman (Wed, 31 Oct 2018 00:29:59 GMT):
I proposed some changes to @dbluhm 's proposed HIPE about message threading. The exec summary is:
1. Rename some fields that were just a little too opaque for my tastes (e.g., "tid" --> "thid"). This is minor.
2. Rework the concept of last sequence number to make it capable of supporting n-wise interactions (e.g., 3 parties trying to coordinate an appointment).
By accident, I merged in all the changes from recent HIPE merges. So it looks like my PR to Daniel Bluhm's PR is big, when it is mostly not. Here's a link to just the substantive part: https://github.com/dbluhm/indy-hipe/pull/2/commits/a6a94c940a5939038bc73df4e32d6d088037da50
As I wrote my tweak, several questions came to my mind that I think deserve larger discussion:
a. Can a particular field in an A2A message have more than one datatype? In my tweak, I suggested that `lrec` could sometimes have a value that's an int, and sometimes have a value that's an array of strings. I'm not sure if this is wise. Would we be better off saying that `lrec` is always an int, and `lrecs` is always an array of strings, and that as a general rule, A2A messages never allow free variation in datatypes (thus being friendlier to stuff like stuffing A2A messages into protobufs and such)?
b. Do we have any conventions on casing or abbreviations? This decorator uses posix style (mashallthewordstogetherinlowercase). I don't love that, but it has the virtue of terseness. Then there's python's snake_case. And of course java's camelCase, and Win32's TitleCase, and CSS's kabob-case. We will probably not be able to impose uniformity on things--after all, anybody can invent message types, and attributes can have whatever names the msg type inventors choose, as long is it makes a JSON parser happy--but for some really core decorators, it might be nice to be consistent... Is that a different HIPE ("best practices in msg family design")?
danielhardman (Wed, 31 Oct 2018 00:29:59 GMT):
I proposed some changes to @dbluhm 's proposed HIPE about message threading. The exec summary is:
1. Rename some fields that were just a little too opaque for my tastes (e.g., "tid" --> "thid"). This is minor.
2. Rework the concept of last sequence number to make it capable of supporting n-wise interactions (e.g., 3 parties trying to coordinate an appointment).
By accident, I included in my sub-PR all the changes from recent HIPE merges. So it looks like my PR to Daniel Bluhm's PR is big, when it is mostly not. Here's a link to just the substantive part: https://github.com/dbluhm/indy-hipe/pull/2/commits/a6a94c940a5939038bc73df4e32d6d088037da50
As I wrote my tweak, several questions came to my mind that I think deserve larger discussion:
a. Can a particular field in an A2A message have more than one datatype? In my tweak, I suggested that `lrec` could sometimes have a value that's an int, and sometimes have a value that's an array of strings. I'm not sure if this is wise. Would we be better off saying that `lrec` is always an int, and `lrecs` is always an array of strings, and that as a general rule, A2A messages never allow free variation in datatypes (thus being friendlier to stuff like stuffing A2A messages into protobufs and such)?
b. Do we have any conventions on casing or abbreviations? This decorator uses posix style (mashallthewordstogetherinlowercase). I don't love that, but it has the virtue of terseness. Then there's python's snake_case. And of course java's camelCase, and Win32's TitleCase, and CSS's kabob-case. We will probably not be able to impose uniformity on things--after all, anybody can invent message types, and attributes can have whatever names the msg type inventors choose, as long is it makes a JSON parser happy--but for some really core decorators, it might be nice to be consistent... Is that a different HIPE ("best practices in msg family design")?
TelegramSam (Wed, 31 Oct 2018 13:55:59 GMT):
I've canceled my PR for type spec guidelines, and have a new PR that includes those as updates to a recently approved HIPE by @dbluhm : https://github.com/hyperledger/indy-hipe/pull/53
TelegramSam (Wed, 31 Oct 2018 15:40:46 GMT):
@danielhardman my above PR has guidelines, but not the one you call out for case. I think we should recommend one style (perhaps strongly) in those guidelines.
danielhardman (Wed, 31 Oct 2018 16:28:05 GMT):
My 2 cents preference for case recommendations, from most to least preferred, is: kabob-case, snake_case, camelCase, posixcase, TitleCase, SHOUTCASE. Unless someone touts SHOUTCASE, I won't argue the virtues or flaws of each one, because I think it's a bit of a stylistic choice based on which programming experiences have been most influential on a person. Maybe we should just run a simple poll and see if there's enough gravitas for any of these options to coalesce around it, and just go where the will of the community takes us.
haggs (Wed, 31 Oct 2018 16:49:11 GMT):
Just a quick (and probably stupid) question around the HIPE 53 about message families "We propose that message types are ledger resolvable DIDs with an endpoint specifier and path:", will all message families have to be _public_ ledger resolvable?
haggs (Wed, 31 Oct 2018 16:56:07 GMT):
Also one vote for kabobCase in the message family names as that seems to have been the convention
bhagadorn (Wed, 31 Oct 2018 18:57:57 GMT):
Has joined the channel.
danielhardman (Wed, 31 Oct 2018 19:30:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fmF5KdLXmaEeW8x9m) @haggs IMO, the answer is No.
XML namespaces don't have to resolve--they just have to be unique. If they *do* resolve, that's nifty. But the programming logic rarely cares what might be on the other side of a URI for the namespace; almost invariably, it just cares that a reference is unambiguous.
The value of resolution of XML namespaces is to help human programmers learn about the semantics associated with the namespace. The point of resolution of a DID reference to docs about a message family is the same. It would be a good practice to have them resolve. But if they don't, it wouldn't break run-time use of those message types; it would just make it harder for people to learn what those message types mean.
danielhardman (Wed, 31 Oct 2018 19:30:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fmF5KdLXmaEeW8x9m) @haggs IMO, the answer is No.
Consider XML namespaces. They don't have to resolve--they just have to be unique. If they *do* resolve, that's nifty. But the programming logic rarely cares what might be on the other side of a URI for the namespace; almost invariably, it just cares that a reference is unambiguous.
The value of resolution of XML namespaces is to help human programmers learn about the semantics associated with the namespace. The point of resolution of a DID reference to docs about a message family is the same. It would be a good practice to have them resolve. But if they don't, it wouldn't break run-time use of those message types; it would just make it harder for people to learn what those message types mean.
danielhardman (Wed, 31 Oct 2018 19:30:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=fmF5KdLXmaEeW8x9m) @haggs IMO, the answer is No.
Consider XML namespaces. They don't have to resolve--they just have to be unique. If they *do* resolve, that's nifty. But the programming logic rarely cares what might be on the other side of a URI for the namespace; almost invariably, it just cares that a reference is unambiguous.
The value of resolution of XML namespaces is to help human programmers learn about the semantics associated with the namespace. The point of resolution of a DID reference to docs about a message family is the same. It would be a good practice to have them resolve. But if they don't, it wouldn't break run-time use of those message types; it would just make it harder for people to learn what those message types mean so they could write useful code to process them.
NateThelen (Wed, 31 Oct 2018 22:00:31 GMT):
Has joined the channel.
mhailstone (Thu, 01 Nov 2018 05:07:37 GMT):
All,
The topics scheduled for Friday are:
- Apps / Agents / Wallets (Darrell O'Donnell)
- Connection Protocol / HIPE 46 (Michael Lodder)
Topic: Indy Agent Design/Discussion
Time: Nov 2, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
sasiedu (Thu, 01 Nov 2018 14:52:14 GMT):
Has joined the channel.
TelegramSam (Thu, 01 Nov 2018 15:22:56 GMT):
another reminder about the meeting time survey: Indy Agent Working Group Call Survey
Our community has expanded substantially since we began this call, and we are seeking to choose a meeting time that allows anyone interested to join our calls. We realize that not every time will work for everybody, and this step will gather data about what will work and what will not.
Visit this link to indicate meeting times that work for you. Make sure you select your timezone, then click (or paint, dragging when mouse button is down) across the times that work for you. Exclude any existing meetings or other conflicts, but please paint any other times that you would be able to make a call. Our call times are 90 minutes.
Please circulate this link with anybody you know in the community that would like to attend this call.
Link for time selection: http://whenisgood.net/ssbykct
swcurran (Thu, 01 Nov 2018 19:44:23 GMT):
FYI - document from the DIF folks about message Identity Hub Request and Response. I've not taken a thorough read, but we might want to add some notes about what we're thinking in the Indy world.
https://hackmd.io/_nmlmbh1SlKdr1TOPYmX_w
danielhardman (Fri, 02 Nov 2018 10:23:36 GMT):
I've written a doc that I want to socialize. It relates to DIF Hubs, to DID Auth, to the indywebshim concept I brought up last week, and to a thing I've called "Security Contexts" but never really explained in detail. (In this doc, I changed the term "Security Contexts" to "Message Trust Contexts" because I think it's more expressive.)
The doc aims to refine our thinking on what's trustable in A2A communication under different scenarios.
It's long. I wish I knew how to make it shorter. But if you'll give it some time, I think it has important ideas. Some of them are controversial, and might need some pushback. That's fine.
Maybe we could discuss on the agent call a week from now?
https://docs.google.com/document/d/13ykeuY8sWFktvrL_3d5W2R8EKWprwD3vjVM7B4Lq5HY/edit
danielhardman (Fri, 02 Nov 2018 10:25:07 GMT):
^^ @peacekeeper and @kdenhartog , given your Spring 2018 RWOT paper on DID Auth, I would be interested in your thoughts on this section especially: https://docs.google.com/document/d/13ykeuY8sWFktvrL_3d5W2R8EKWprwD3vjVM7B4Lq5HY/edit#heading=h.47sxzey2yvot
haggs (Fri, 02 Nov 2018 13:25:39 GMT):
Just a friendly link for those of use trying to catch up with it all :D RWOT DID Auth paper: https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.pdf
mhailstone (Fri, 02 Nov 2018 13:45:01 GMT):
Agent call starts in 15 minutes: https://byu.zoom.us/j/2627891784
mhailstone (Fri, 02 Nov 2018 15:38:24 GMT):
Thanks all for an amazing call today! Looking forward to the discussion and comments on HIPEs: https://github.com/hyperledger/indy-hipe/pulls
danielhardman (Fri, 02 Nov 2018 15:47:45 GMT):
I have a terminology suggestion. For DIDs that are not rooted on the public ledger, how about the term "edge DIDs" instead of "microledger DIDs" or "private DIDs"? My reasoning is that I want to write a new DID method, "did:edge", as opposed to "did:sov". Edge DIDs would be the same regardless of the blockchain ecosystem that uses them, and the DID method would be the relationship state machine, whether or not they're persisted with microledgers.
danielhardman (Fri, 02 Nov 2018 16:26:44 GMT):
@TelegramSam: I have left comments on your PR re. the connection protocol. Most are small. The big one is here: https://github.com/hyperledger/indy-hipe/pull/54#discussion_r230431253
lynn.bendixsen (Fri, 02 Nov 2018 19:00:17 GMT):
There is a Meetup happening in Provo, Utah at the Sovrin Foundation offices. Everyone who would like to come is welcome to attend. The main topic for this one will be "Indy Agents". To RSVP, go here: https://www.meetup.com/Utah-Sovrin-Meetup/events/256008527/?isFirstPublish=true
mhailstone (Fri, 02 Nov 2018 19:17:21 GMT):
All,
Here is the recording of today's Friday Agent call: https://byu.zoom.us/recording/detail?meeting_id=g7Mj515BRtaQAGZT2OOIkw%3D%3D
mhailstone (Fri, 02 Nov 2018 19:17:21 GMT):
All,
Here is the recording of today's Friday Agent call: https://drive.google.com/drive/folders/1_MVQlW23LOu5P5Ya7tGxpf2m2nstnxmq
drummondreed (Mon, 05 Nov 2018 03:16:46 GMT):
@lynn.bendixsen Suggestion: when you publicize a Meetup, put at least the date in your message—it saves a click-through for those of us who might be able to make it depending on the date.
mhailstone (Mon, 05 Nov 2018 14:12:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=N26utA4izoexdCaWH) @lynn.bendixsen Is this in Draper or Provo? When I clicked on the Meetup, the location said Draper, but your comment says Provo.
lynn.bendixsen (Mon, 05 Nov 2018 16:07:43 GMT):
Thanks @drummondreed for the suggestion! The Meetup is this Friday, November 9, 2018 at 11:00 AM Mountain time.
lynn.bendixsen (Mon, 05 Nov 2018 16:07:43 GMT):
Thanks @drummondreed for the suggestion! The Meetup is this Friday, November 9, 2018.
TelegramSam (Mon, 05 Nov 2018 18:03:54 GMT):
I think the non-secrets indy-sdk API is what we should use for ref agent wallet storage.
dbluhm (Mon, 05 Nov 2018 18:18:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9CTBZ25B9dT4SnJ9T) @TelegramSam Are you referring to storing connection state, messages (inbox), etc?
TelegramSam (Mon, 05 Nov 2018 19:59:29 GMT):
Yep.
kdenhartog (Mon, 05 Nov 2018 22:17:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9CTBZ25B9dT4SnJ9T) @TelegramSam +1 this is what I was using when I was building the route table functionality
dbluhm (Mon, 05 Nov 2018 23:19:05 GMT):
@swcurran Using your dockerize magic for the python agent, I'm running into an error:
```
Step 6/8 : ADD --chown=indy:indy indy_config.py /etc/indy/
ERROR: Service 'webserver' failed to build: Unknown flag: chown
```
I'm guessing this is due to docker version problems? Would you happen to know?
swcurran (Mon, 05 Nov 2018 23:24:48 GMT):
Quite possibly. Are you up to date on docker?
swcurran (Mon, 05 Nov 2018 23:25:50 GMT):
That's a current feature of docker - https://docs.docker.com/engine/reference/builder/#add
swcurran (Mon, 05 Nov 2018 23:26:10 GMT):
Not sure when it was added.
swcurran (Mon, 05 Nov 2018 23:26:29 GMT):
It was added in release v17.09.0-ce.
swcurran (Mon, 05 Nov 2018 23:27:46 GMT):
We can go back to the old way to do it, which would be two steps ADD and then RUN with a chown linux command
dbluhm (Mon, 05 Nov 2018 23:29:28 GMT):
My version numbers for docker installed from Fedora repos don't line up with the versioning on the website. I'm looking into it but good to know we have a backup at least.
swcurran (Mon, 05 Nov 2018 23:30:56 GMT):
You used the docker install info? That's weird.
swcurran (Mon, 05 Nov 2018 23:31:53 GMT):
https://docs.docker.com/install/linux/docker-ce/fedora/
swcurran (Mon, 05 Nov 2018 23:32:40 GMT):
More generally: https://docs.docker.com/install/#supported-platforms
dbluhm (Mon, 05 Nov 2018 23:34:07 GMT):
Hm... If possible, I think it'd be good to stick with packages from the official repositories. I'll switch it to an ADD and a RUN with chown and see if there aren't any other problems.
swcurran (Mon, 05 Nov 2018 23:36:39 GMT):
I'd guess you aren't on the official platform. You are on a release 13 months old at least.
swcurran (Mon, 05 Nov 2018 23:37:21 GMT):
That's pretty ancient
dbluhm (Mon, 05 Nov 2018 23:37:41 GMT):
I was referring to the official Fedora repositories
swcurran (Mon, 05 Nov 2018 23:39:30 GMT):
Did you install "docker" or "docker-ce"? That could be why you are on such an old release.
swcurran (Tue, 06 Nov 2018 00:50:05 GMT):
@dbluhm - what version of docker do you get on fedora.
swcurran (Tue, 06 Nov 2018 00:50:05 GMT):
@dbluhm - what version of docker do you get on fedora?
swcurran (Tue, 06 Nov 2018 17:16:00 GMT):
Hey all, if you are a developer interested in trying out the Hyperledger Indy Agent nodeju demo using just a browser, check out
https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md
This is from the Hyperledger "Blockchain for Business" course on edX - I did the Indy chapter of the course - https://www.edx.org/course/blockchain-for-business-an-introduction-to-hyperledger-technologies
Please let me know if you have any issues with the demo.
swcurran (Tue, 06 Nov 2018 17:16:00 GMT):
Hey all, if you are a developer interested in trying out the Hyperledger Indy Agent nodejs demo using just a browser, check out
https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md
This is from the Hyperledger "Blockchain for Business" course on edX - I did the Indy chapter of the course - https://www.edx.org/course/blockchain-for-business-an-introduction-to-hyperledger-technologies
Please let me know if you have any issues with the demo.
kdenhartog (Tue, 06 Nov 2018 21:07:09 GMT):
Forgot to post this doc in here, but I figure it would be relevant to us. It's intended to find interop and portability across different DID based projects, but it will help us establish the different layers that could potentially make our systems incompatible. https://hackmd.io/s/ryOo-7Rn7
mhailstone (Tue, 06 Nov 2018 22:23:59 GMT):
All,
Here is the agenda for the Indy Agent call:
- Meeting time - new poll - http://whenisgood.net/ssbykct
-- Sam Curren
- Follow up - summaries (short):
-- JWE - pack/unpack - summarize - Mike Lodder
-- Connection Protocol - summarize - Sam Curren
- Relationship State Machine - Microledgers
- Open Discussion
Topic: Indy Agent Design/Discussion - 11/09/2018
Time: Nov 9, 2018 8:00 AM Mountain Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android: https://byu.zoom.us/j/2627891784
Or iPhone one-tap :
US: +16465588656,,2627891784# or +16699006833,,2627891784#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 646 558 8656 or +1 669 900 6833
Meeting ID: 262 789 1784
International numbers available: https://zoom.us/u/dlOZ5fySX
Or an H.323/SIP room system:
H.323:
162.255.37.11 (US West)
162.255.36.11 (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 (Brazil)
69.174.57.160 (Canada)
Meeting ID: 262 789 1784
SIP: 2627891784@zoomcrc.com
kh.nguyen (Wed, 07 Nov 2018 01:36:21 GMT):
Has joined the channel.
mwherman2000 (Thu, 08 Nov 2018 22:34:48 GMT):
Has joined the channel.
mhailstone (Fri, 09 Nov 2018 14:48:06 GMT):
Agent call with start in 12 minutes https://byu.zoom.us/j/2627891784
pknowles (Fri, 09 Nov 2018 16:56:21 GMT):
Has joined the channel.
danielhardman (Fri, 09 Nov 2018 16:59:47 GMT):
@JanL (I think I have the right handle) wanted to socialize a HIPE proposal that was built around the concept of consent receipts, but was having trouble with Rocket Chat--so I said I'd drop a link here. https://github.com/hyperledger/indy-hipe/pull/55
TelegramSam (Fri, 09 Nov 2018 17:46:43 GMT):
Starting next week, the Agent Call will be on Wed, 1pm-2:30pm US Mountain Time, at this zoom link: https://zoom.us/j/856588081
TelegramSam (Fri, 09 Nov 2018 17:47:19 GMT):
I have a Google Calendar event that I'd be happy to add you to, please dm me your email address.
haggs (Fri, 09 Nov 2018 17:47:51 GMT):
please do
haggs (Fri, 09 Nov 2018 17:48:16 GMT):
Just to be clear, non observing DST mountain time?
TelegramSam (Fri, 09 Nov 2018 17:51:54 GMT):
argh.
TelegramSam (Fri, 09 Nov 2018 17:52:10 GMT):
2pm right now. we'll see how that shifts about around the world.
TelegramSam (Fri, 09 Nov 2018 17:52:41 GMT):
I sent a Google Calendar invite to everyone who added their email to the attendees list on the last agenda.
peacekeeper (Mon, 12 Nov 2018 07:47:28 GMT):
Is one of the agent implementations (node, python) extensible right now with new message families/type, or are they hardcoded? I thought I once saw some kind of .yml configuration file for agents, but I can't find that now...
mhailstone (Mon, 12 Nov 2018 14:03:59 GMT):
There is an open pull request that we still need to go over and decide how to pull in or not, or design it in a different way. https://github.com/hyperledger/indy-agent/pull/23
mhailstone (Mon, 12 Nov 2018 14:03:59 GMT):
@peacekeeper There is an open pull request that we still need to go over and decide how to pull in or not, or design it in a different way. https://github.com/hyperledger/indy-agent/pull/23
TelegramSam (Mon, 12 Nov 2018 14:55:34 GMT):
Under advice of @drummondreed, we now have a perpetual meeting notes doc for the agent call: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
umamaheswarv (Mon, 12 Nov 2018 16:48:49 GMT):
Has joined the channel.
danielhardman (Mon, 12 Nov 2018 17:27:11 GMT):
A question about the threading HIPE proposal (@dbluhm and @TelegramSam): Suppose my application message is a proof request, and suppose it has to be routed through 3 intermediaries between the two edges. What should the ID of the `forward` message be that contains the proof request inside it, in packed/encrypted form? Should there be any relationship between the ID of the forward and the ID of the inner message it contains? If no, then how can an error at an intermediate point in the routing be related to a message known to one of the edges?
danielhardman (Mon, 12 Nov 2018 17:27:11 GMT):
A question about the threading HIPE proposal (@dbluhm and @TelegramSam): Suppose my application message is a proof request, and suppose it has to be routed through 3 intermediaries between the two edges. What should the ID of the `forward` message be that contains the proof request inside it, in packed/encrypted form? Should there be any relationship between the ID of the forward and the ID of the inner message it contains? If no, then how can an error at an intermediate point in the routing be related to a message known to one of the edges?
danielhardman (Mon, 12 Nov 2018 17:27:11 GMT):
A question about the threading HIPE proposal ( @dbluhm and @TelegramSam): Suppose my application message is a proof request, and suppose it has to be routed through 3 intermediaries between the two edges. What should the ID of the `forward` message be that contains the proof request inside it, in packed/encrypted form? Should there be any relationship between the ID of the forward and the ID of the inner message it contains? If no, then how can an error at an intermediate point in the routing be related to a message known to one of the edges?
haggs (Mon, 12 Nov 2018 18:31:23 GMT):
Good idea @TelegramSam I can certainly do that
tlooker (Mon, 12 Nov 2018 19:32:17 GMT):
@danielhardman My first question is why does there need to be an inner forward. If we end up taking the approach outlined by PR #43 (AMES) then the outer most message will contain information on the recipient(s), so could routing not be done off this information? I imagined the outer most message containing an identifier (i.e the to field in the recipient list) known to both the edge agents i.e a pairwise Did. For each network hop the message would be encrypted with the verkey of the service endpoint for the next network hop, where by each hop would know only where to send the message to next based on their routing table. For example Bob wants to send Alice a message. Alice has a domain endpoint agent, routing agent and edge agent. Bob creates a message then packs it using AMES, in the recipient list is the pairwise verkey of Alices edge agent, he then encrypts this entire message with the domain endpoint verkey and sends it to the domain endpoint (Note: On connection with Bob, Alice configured her routing agent and domain endpoint agent, to each have a routing record, the domain endpoint agent would have a routing record mapping the pairwise verkey to the routing agent endpoint and the routing agent would have a routing record mapping the pairwise verkey to the edge agent). The domain endpoint agent would then decrypt this message, lookup the recipients against its routing records, find a record for the routing agent, re-encrypt the message with the routing agents verkey and send (the process is then repeated until the edge agent is reached).
swcurran (Mon, 12 Nov 2018 19:46:30 GMT):
@tlooker - the need for the what amounts 3 wrappings of the data is that there is specific hiding of data from the Domain Endpoint. Alice encrypts the "Agent Message" (e.g. a Proof Request) to the ultimate recipient's (the Proofer) and also encrypts it as a forward to the recipient's Routing Agent. Then Alice encrypts that in a forward for the next hop in the process - which could be Bob's Domain endpoint.
Lots of encryption layers, but based on "need to know" information hiding.
swcurran (Mon, 12 Nov 2018 19:46:30 GMT):
@tlooker - the need for the what amounts 3 wrappings of the data is that there is specific hiding of data from the Domain Endpoint. Alice encrypts the "Agent Message" (e.g. a Proof Request) to the ultimate recipient (the Proofer) and encrypts that as a forward to the recipient's Routing Agent. Then Alice encrypts that in a forward for the next hop in the process - which could be Bob's Domain endpoint.
Lots of encryption layers, but based on "need to know" information hiding.
swcurran (Mon, 12 Nov 2018 19:46:30 GMT):
@tlooker - the need for the what amounts 3 wrappings of the data is that there is specific hiding of data from the Domain Endpoint. Alice encrypts the "Agent Message" (e.g. a Proof Request) to the ultimate recipient (the Proofer) and encrypts that as a forward to the recipient's Routing Agent. Then Alice encrypts that forward in an outer forward for the next hop in the process - which could be Bob's Domain endpoint.
Lots of encryption layers, but based on "need to know" information hiding.
swcurran (Mon, 12 Nov 2018 19:46:30 GMT):
@tlooker - the need for the what amounts 3 wrappings of the data is that there is specific hiding of data from the Domain Endpoint and routing agents. Alice encrypts the "Agent Message" (e.g. a Proof Request) to the ultimate recipient (the Proofer) and encrypts that as a forward to the recipient's Routing Agent. Then Alice encrypts that forward in an outer forward for the next hop in the process - which could be Bob's Domain endpoint.
Lots of encryption layers, but based on "need to know" information hiding.
tlooker (Mon, 12 Nov 2018 19:49:41 GMT):
@swcurran yeap I understand the need to hide the message contents from the intermediaries, but say the message is a proof request, if I take that message and pack that using AMES and put the pairwise did as the recipient (in the recipient list) then no intermediary will know the messages contents?
tlooker (Mon, 12 Nov 2018 19:50:05 GMT):
sorry I shouldnt say pairwise did as the recipient just the verkey
swcurran (Mon, 12 Nov 2018 19:50:17 GMT):
It wasn't so much the message content as the intended recipient.
swcurran (Mon, 12 Nov 2018 19:50:17 GMT):
It wasn't so much the message content as the intended recipient that drives the need for the extra encryption layer.
swcurran (Mon, 12 Nov 2018 19:50:17 GMT):
It wasn't so much the message content as the intended recipient that drives the need for the extra encryption layer. The goal was to hide the details of where the message was going from the Domain Endpoint.
danielhardman (Mon, 12 Nov 2018 19:51:39 GMT):
AMES has absolutely no effect on the need to use multiple forwards. They're completely orthogonal issues.
TelegramSam (Mon, 12 Nov 2018 19:52:32 GMT):
@danielhardman I think taking a design stab at the forward message family would help inform the thread/error reporting issue.
danielhardman (Mon, 12 Nov 2018 19:53:08 GMT):
The forward message family was already defined in HIPE 0022 (cross-domain messaging).
danielhardman (Mon, 12 Nov 2018 19:53:23 GMT):
We could add more detail, but since that HIPE has been merged, I'm assuming it's normative.
TelegramSam (Mon, 12 Nov 2018 19:54:24 GMT):
Perfect.
swcurran (Mon, 12 Nov 2018 19:54:34 GMT):
@TelegramSam - keep in touch on the error handling. I'm doing some work on that as well and have some ideas to share. Hope to have a sketch maybe today or tomorrow.
TelegramSam (Mon, 12 Nov 2018 19:55:26 GMT):
I can see expansion of the routing family, specifically inbound routing setup and teardown, but that should be good enough for now.
TelegramSam (Mon, 12 Nov 2018 19:59:33 GMT):
And now I'm thinking about which levels of routing you tell others about, and pre-destination routing vs post-destination routing...
tlooker (Mon, 12 Nov 2018 20:01:24 GMT):
I understand the drive to want to separate them as that was my original thought too, however wont we be effectively be nesting or duplicating data by having recipients packed inside recipients? @swcurran if I send the domain endpoint a message where the recipient is a verkey, the domain endpoint either knows where to send it next or it doesn't, the most it could know is the next network hop?
danielhardman (Mon, 12 Nov 2018 20:04:06 GMT):
@tlooker I want to expand on my perhaps-cryptic comment about AMES and forwarding being orthogonal.
A design principle that informs many choices about A2A is the idea that an agent doesn't have to know anything about contexts other than their own and their immediate environs. It is theoretically possible to build a system where an intermediary, 2 or 3 steps removed from the final destination of a message, sees that X is the final destination, and takes action accordingly. But we've gone a different way: if an agent isn't the final destination of a message, then the message it receives is a `forward` message that tells it what to do next. That's all. It doesn't see the final destination (good for privacy), and it doesn't care about the type of the thing that it's forwarding.
Thus, all agents, whether they are intermediaries or final destinations, always do the same thing: they open a message *meant for them, NOT someone else*, and run it through a handler. If the handler causes them to subsequently emit another message that was embedded in the message they received (as will be the case for `forward` messages), that's fine--but it's a minor detail. Routing messages are just another message family.
If we wanted AMES to address routing, then we'd have a different system, where routing messages are special.
tlooker (Mon, 12 Nov 2018 20:15:04 GMT):
@danielhardman Thanks for the clarification, I do understand that we are approaching routing in that fashion I'm just starting to wonder whether routing is more fundamental and therefore should be considered lower level, so rather than have a forwarding message for example each agent would have the common behaviour of lookup the recipient list of a received message and first check if the message is for them unpack and if not check if they know how to route the message. With the current forwarding message approach, how do you envisage sending a message from one edge agent to multiple edge agent i.e alice sends a message from her phone to bobs ipad, laptop and phone? If routing were lower level then Bob could disclose the verkey for each edge agent in the pairwise did doc he shares with alice (via microlegers), Alice could then form the message using AMES with multiple recipients and if the routing table for the domain endpoint agent and routing agent is setup, the messages would be deliverable to all recipients?
tlooker (Mon, 12 Nov 2018 20:15:04 GMT):
@danielhardman Thanks for the clarification, I do understand that we are approaching routing in that fashion I'm just starting to wonder whether routing is more fundamental and therefore should be considered lower level, so rather than have a forwarding message for example each agent would have the common behaviour of lookup the recipient list of a received message and first check if the message is for them and if not check if they know how to route the message. With the current forwarding message approach, how do you envisage sending a message from one edge agent to multiple edge agent i.e alice sends a message from her phone to bobs ipad, laptop and phone? If routing were lower level then Bob could disclose the verkey for each edge agent in the pairwise did doc he shares with alice (via microlegers), Alice could then form the message using AMES with multiple recipients and if the routing table for the domain endpoint agent and routing agent is setup, the messages would be deliverable to all recipients?
tlooker (Mon, 12 Nov 2018 20:15:04 GMT):
@danielhardman Thanks for the clarification, I do understand that we are approaching routing in that fashion I'm just starting to wonder whether routing is more fundamental and therefore should be considered lower level, so rather than have a forwarding message for example each agent would have the common behaviour of lookup the recipient list of a received message and first check if the message is for them and if not check if they know how to route the message. With the current forwarding message approach, how do you envisage sending a message from one edge agent to multiple edge agent i.e alice sends a message from her phone to bobs ipad, laptop and phone? If routing were lower level then Bob could disclose the verkey for each edge agent in the pairwise did doc he shares with alice (via microledgers), Alice could then form the message using AMES with multiple recipients and if the routing table for the domain endpoint agent and routing agent is setup, the messages would be deliverable to all recipients?
tlooker (Mon, 12 Nov 2018 20:15:04 GMT):
@danielhardman Thanks for the clarification, I do understand that we are approaching routing in that fashion I'm just starting to wonder whether routing is more fundamental and therefore should be considered lower level, so rather than have a forwarding message for example each agent would have the common behaviour of lookup the recipient list of a received message and first check if the message is for them and if not check if they know how to route the message. With the current forwarding message approach, how do you envisage sending a message from one edge agent to multiple edge agents i.e alice sends a message from her phone to bobs ipad, laptop and phone? If routing were lower level then Bob could disclose the verkey for each edge agent in the pairwise did doc he shares with alice (via microledgers), Alice could then form the message using AMES with multiple recipients and if the routing table for the domain endpoint agent and routing agent is setup, the messages would be deliverable to all recipients?
danielhardman (Mon, 12 Nov 2018 20:21:01 GMT):
What you describe in your last sentence is exactly how it works. We don't need routing to be more low-level to accomplish it.
TelegramSam (Mon, 12 Nov 2018 20:22:22 GMT):
@tlooker we could expand a forward message to have multiple destinations to help that problem. There is also the case where the 'destination' as known by the sender is actually an intermediate agent, such as the user's cloud agent. The cloud agent may know more about how to do the final hop and can route the message to the real, final, destination.
TelegramSam (Mon, 12 Nov 2018 20:22:56 GMT):
that's really a restate of your last sentance though, on rearead.
TelegramSam (Mon, 12 Nov 2018 20:22:56 GMT):
that's really a restate of your last sentance though, on reread.
tlooker (Mon, 12 Nov 2018 20:25:55 GMT):
@TelegramSam @danielhardman ok that makes more sense, if the forward message supported multiple recipients then I can see it working.
danielhardman (Tue, 13 Nov 2018 05:13:14 GMT):
I have raised a PR with a HIPE proposal about how to request message tracing during A2A communication: https://github.com/hyperledger/indy-hipe/pull/59
danielhardman (Tue, 13 Nov 2018 05:13:14 GMT):
I have raised a PR with a HIPE proposal about how to request message tracing during A2A communication: https://github.com/hyperledger/indy-hipe/blob/bd113060ced87d2eaa5327ef3395e9de9ae4853b/text/thread-tracing/README.md
danielhardman (Tue, 13 Nov 2018 05:20:40 GMT):
https://github.com/hyperledger/indy-hipe/blob/bd113060ced87d2eaa5327ef3395e9de9ae4853b/text/thread-tracing/README.md
HiranKumar (Tue, 13 Nov 2018 05:21:04 GMT):
Has joined the channel.
danielhardman (Tue, 13 Nov 2018 05:37:46 GMT):
I have proposed a HIPE for conventions around how to enable message tracing, for troubleshooting purposes: https://github.com/hyperledger/indy-hipe/pull/60
arunwij (Tue, 13 Nov 2018 09:22:27 GMT):
Is there a payment model defined for agencies, stewards to get paid in Indy based identity network.
danielhardman (Tue, 13 Nov 2018 20:47:37 GMT):
There is a payment handler interface into which a payment mechanism can be plugged. The interface would easily model Bitcoin, and almost as easily model Ethereum. It could also be adapted to something like Venmo or Paypal with more thought. There is an implementation of this payment interface called libnullpay that lets you pretend to do payments. The Sovrin Foundation has implemented the interface for a token that they are releasing.
danielhardman (Tue, 13 Nov 2018 20:47:37 GMT):
@arunwij There is a payment handler interface into which a payment mechanism can be plugged. The interface would easily model Bitcoin, and almost as easily model Ethereum. It could also be adapted to something like Venmo or Paypal with more thought. There is an implementation of this payment interface called libnullpay that lets you pretend to do payments. The Sovrin Foundation has implemented the interface for a token that they are releasing.
danielhardman (Tue, 13 Nov 2018 20:48:12 GMT):
I have raised a PR for defining a file format for agent wire messages and for application plaintext messages. It's quite simple and, I think, not controversial. Would be glad of feedback. https://github.com/hyperledger/indy-hipe/blob/717d8e59c59600969c5ca37dd44fdabf69321dd7/text/agent-file-format/README.md
arunwij (Wed, 14 Nov 2018 05:18:32 GMT):
@danielhardman Thank you. I also want to know how identity owners, identity issuers get charged using this network. Is there a transactional cost? so agencies, and stewards get paid for transaction count.
arunwij (Wed, 14 Nov 2018 05:18:32 GMT):
@danielhardman Thank you. I also want to know how identity owners, identity issuers get charged using this network. Is there a transactional cost? (so agencies, and stewards get paid per transaction count? )
arunwij (Wed, 14 Nov 2018 05:21:26 GMT):
I heard about paid credentials as well.
danielhardman (Wed, 14 Nov 2018 05:39:15 GMT):
On transactional cost: maybe. It will depend on whether someone is "sponsored" or not. If you're a refugee, you may not have to pay anything, for example. But most people will have to pay a small fee (probably a cent or two) to write a record to the ledger.
Paid credentials are a thing--but they are not associated with any ledger writes, so that's independent.
danielhardman (Wed, 14 Nov 2018 05:55:13 GMT):
(My previous answer is an answer for *Sovrin*, not for Indy. Indy doesn't have any requirement that anything incur fees. It just has a hook to which fees can be attached, if a particular instance of Indy decides to do so.)
arunwij (Wed, 14 Nov 2018 07:16:26 GMT):
@danielhardman Thank you for the clarification.
gy8409i (Wed, 14 Nov 2018 09:10:44 GMT):
Has joined the channel.
TelegramSam (Wed, 14 Nov 2018 15:50:09 GMT):
= Indy Agent Call =
Meeting is _TODAY_ at 1pm US/Mountain. This is a new time, and a new zoom link. Also notice the Perpetual Meeting Notes doc. This will stay the same for future meetings, so you can bookmark it.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/856588081
Perpetual Meeting Notes: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit?usp=sharing
mwherman2000 (Wed, 14 Nov 2018 19:42:44 GMT):
My feedback added to the the following Medium.com article: https://hackernoon.com/the-one-thing-missing-from-erc-721-standard-for-digital-collectibles-on-the-blockchain-9ee26e4a918c
Once a Non-Fungible Entity (e.g. [Person], [Organization], [Thing], Cryptokitty, Purchase Order, Invoice, Shipping Instructions, Delivery Confirmation, etc.) have been fully realized and encased in concrete plus 100 layers of titanium and digitally signed so that it can never be altered, why can't it be accessed using a trusted service within a smart contract VM?…why can't there be a set of simple standard VM-level interop methods for querying any NFE found anywhere on the planet, selecting an entity or entities from the result set, and then calling on a standard set of accessors to deserialize the properties desired by a smart contract invocation which, in turn, is being called by an off-chain app or another on-chain smart contract?
mwherman2000 (Wed, 14 Nov 2018 19:44:23 GMT):
Is anyone aware of a blockchain/VM project that is already undertaking this approach for direct NFE access from a smart contract?
danielhardman (Wed, 14 Nov 2018 22:42:40 GMT):
I added a slide to explain what I understood about @TelegramSam 's perspective on our agent call just now: https://docs.google.com/presentation/d/1UnC_nfOUK40WS5TD_EhyDuFe5cStX-u0Z7wjoae_PqQ/edit#slide=id.g47063b60f4_0_9. Sam, I tried to capture it accurately; did I?
I also added some verbiage to slide 3 (https://docs.google.com/presentation/d/1UnC_nfOUK40WS5TD_EhyDuFe5cStX-u0Z7wjoae_PqQ/edit#slide=id.g46da93b149_0_287) to explain why I was getting tripped up on the use of "public". There are 2 squares that are public, not 1. When Sam used the word, I think he meant top right square. I was trying to suggest that most of his benefits could be accomplished in the bottom right square, which is "Anywise" but "Private".
I think the Hybrid model that Sam described is going to show up in the ecosystem. I'm less confident that it should be best practice, or that we should embrace it now. I do think it will require coding support in libindy that is not currently planned, over and above microledger support.
Regarding the use of ledger-based DIDs for pairwise connections: if we proceed down this road and allow implementations based on them, then individuals (not just orgs) can do this. This has GDPR ramifications because the ledger does not have a right-to-be-forgotten mechanism. So when I hear the argument, "look, we already have pairwise DID support implemented, if we use the public ledger to store them", I get a sick feeling in my stomach. As soon as there is 1 personal DID on the public ledger, the ledger is susceptible to lawsuit about right-to-be-forgotten. This may not be a problem for Indy, generally--but for Sovrin, it is a big deal. Some stewards are very nervous about it.
danielhardman (Wed, 14 Nov 2018 22:44:12 GMT):
Perhaps this concern could be mitigated by only allowing trust anchors to write to the ledger, and by instructing trust anchors to only write DIDs for orgs...
dbluhm (Wed, 14 Nov 2018 22:49:57 GMT):
I think we need to focus more discussion on how we can accelerate getting microledger functionality released into indy-sdk.
nage (Wed, 14 Nov 2018 22:51:39 GMT):
I agree with Daniel H that some of the Hybrid model is concerning. @TelegramSam do you mean this as an ontology and terminology breakdown or intend that there are serious uses for non pairwise keys for interactions beyond credential issuance?
haggs (Wed, 14 Nov 2018 22:54:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RXhZ6XWt824QfdFQb) @dbluhm Looking forward to watching to recording heard it was a great discussion! Was midflight.
On that note, what if we roll out some more functionality and just assume some things? Seems like the agent WG is very forward thinking rightly so, but in the meantime what do we know for sure and can implement for sake of practicality.
swcurran (Wed, 14 Nov 2018 22:56:54 GMT):
@danielhardman is a way to address the public or microledger handling be to have DID-create/update code in libindy know when instructed to write a DID to where it should be replicated? E.g Could it know to either makes a call to the ledger or invokes the appropriate A2A messages.
swcurran (Wed, 14 Nov 2018 22:56:54 GMT):
@danielhardman is a way to address the public or microledger handling be to have DID-create/update code in libindy know when instructed to write a DID to where it should be replicated? E.g Could it know to either make a call to the ledger or invoke the appropriate A2A messages.
kdenhartog (Wed, 14 Nov 2018 23:01:57 GMT):
@TelegramSam do you have a link to the Indy agents notes? Or better yet a way that I can find them? I'm going to add them to the Wiki if there's no objections to that.
kdenhartog (Wed, 14 Nov 2018 23:01:57 GMT):
@TelegramSam do you have a link to the Indy agents notes? Or better yet a way that I can find them? I'm going to add them to the Wiki if there's no objections to that. Found em a little bit higher up in chat :)
swcurran (Wed, 14 Nov 2018 23:02:58 GMT):
Re: Isn't Right-To-Be-Forgotten from a "DID on the ledger" perspective self-managed and covered by the elimination of the endpoint referenced in the DIDDoc and the deletion of the associated private keys? If there is no functioning endpoint and no way to decrypt a message, how are you remembered from a DID? If another organization recorded your DID, then it is that organization that needs to forget it, not the ledger.
I'm sure its a far more complicated question than that. :-)
swcurran (Wed, 14 Nov 2018 23:02:58 GMT):
Re: Isn't Right-To-Be-Forgotten from a "DID on the ledger" perspective self-managed and covered by the elimination of the endpoint referenced in the DIDDoc and the deletion of the associated private keys? If there is no functioning endpoint and no way to decrypt a message, how are you remembered from a DID? If another organization recorded your DID, then it is that organization that needs to forget it, not the ledger.
I'm sure it is a far more complicated question than that. :-)
gy8409i (Thu, 15 Nov 2018 01:27:33 GMT):
Is there going to be an official agent to release in the future? Or only reference agent is on the plan? Should we develop the agent all by our own?
gy8409i (Thu, 15 Nov 2018 01:32:54 GMT):
Another question is the ppt shared today in the meeting about "Public DIDs for Private Relationships" is still under discussion or you have got a conclusion?
danielhardman (Thu, 15 Nov 2018 04:23:28 GMT):
@gy8409i We did not reach a conclusion yet. See above.
Re. release of an agent: People have to write their own agents. Reason: everybody wants different things from their agents. However, a couple of the reference agents that we're about to release are *substantial* efforts with a lot of useful features. One is a reference mobile app, for example. I think it will be possible to get large amounts of value from some of the reference agents (basically, use one as the core of something you want to release), not just study the code and build your own from scratch.
danielhardman (Thu, 15 Nov 2018 04:25:34 GMT):
@swcurran : GDPR experts say that it IS more complicated than that. But I'm not such an expert. Elizabeth Reneiris (Global Policy Counsel at Evernym) has been testifying before EU policymakers on this issue, along with a number of other lawyers. She is pretty adamant about this conclusion. I think @drummondreed may also know something. I refer you to them.
danielhardman (Thu, 15 Nov 2018 04:31:04 GMT):
@swcurran re. "way to address the public or microledger handling": Yes. The way to switch codepaths would be to look at the DID method (if looking at "did:sov:...", go to the Sovrin ledger; if looking at "did:peer:...", go into microledger mode). That's code that has to be written, but mostly it's associated with microledger work, so I wouldn't count that work as completely "extra." There's also code that would have to be written to propagate relationship information to the other party in a connection, any time you change your own keys or authorizations. Again, that's not "extra", over and above microledger tasks. But there's also changes to how DIDs can be used as an index, and that work *is* extra--required only by the Hybrid mode, and not by what we have today or what we'd build for hyperledgers. It's code that uses the sender rather than the target of a message to look up the relationship that should be provide context for a message. That's the main code I don't want to write.
gy8409i (Thu, 15 Nov 2018 04:41:53 GMT):
Is there any cloud agent implementation guidance yet?
gy8409i (Thu, 15 Nov 2018 04:46:15 GMT):
I saw the architecture design that if I'm running an agency and a lot of cloud agents for each of my customer, I should at least implement provisioning extension and routing extension. Here is the source doc I referenced https://raw.githubusercontent.com/hyperledger/indy-sdk/master/doc/design/005-dkms/images/image_9.png
drummondreed (Thu, 15 Nov 2018 05:22:41 GMT):
@swcurran The GDPR and blockchain question is indeed quite a deep one with no clear answers yet. I highly recommend this paper that the EU Blockchain Observatory published just a few weeks ago: https://www.eublockchainforum.eu/sites/default/files/reports/20181016_report_gdpr.pdf
mxs1491 (Thu, 15 Nov 2018 10:29:28 GMT):
Has joined the channel.
TelegramSam (Thu, 15 Nov 2018 16:01:10 GMT):
> It's code that uses the sender rather than the target of a message to look up the relationship that should be provide context for a message.
I've heard requests for that feature independent of this discussion.
TelegramSam (Thu, 15 Nov 2018 16:02:51 GMT):
> @danielhardman: Sam, I tried to capture it accurately; did I?
TelegramSam (Thu, 15 Nov 2018 16:03:02 GMT):
Yes, I believe that is accurate.
TelegramSam (Thu, 15 Nov 2018 16:05:01 GMT):
Late thought: We have been heavily discussing peer DIDs, but I have not heard this from any other SSI community member. So, either we need to evangelize heavily and reach perfect adoption, or we WILL need to allow support for connections with DIDs done poorly on other DID methods. Even if we don't allow them on our own, the ability to create connections between agents this way may be very important.
TelegramSam (Thu, 15 Nov 2018 17:02:16 GMT):
@nage @danielhardman ^
haggs (Thu, 15 Nov 2018 17:54:33 GMT):
Page 19 of the EU BLockchain Obervatory really gets into the weeds about right to be forgotten and public blockchain
haggs (Thu, 15 Nov 2018 17:57:19 GMT):
Still don't understand its guidance, and it uses the words linkability somewhat how we use correlatability. It seems like the higher value items, like SSN, have to have more protection and less linkability? From that end I think some of this liability falls upon your agent/agency architecture. Just my 2 cents.
TelegramSam (Thu, 15 Nov 2018 17:58:29 GMT):
anything within an agent can be forgotten, it's the ledger that's the wrinkle.
nhelmy (Thu, 15 Nov 2018 19:50:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xF8jW45NkJj73QfYF) @danielhardman @danielhardman As a developer in the Agent space for quite some time, I've been trying to find a codebase that is close to something I can just fork and contribute to, and I've been having a lot of trouble. There are a couple clear candidates, namely Hyperledger Indy Agent (both nodejs and python agents), libvcx (which is being absorbed into indy sdk), connect.me (unclear how different from the previous one), and the VON agents. I have been attending the Agent WG calls regularly, went to the last two IIW's, and even traveled to Utah for the Agent Summit in August. I came out of that weekend having a lot of energy and thinking that work on a Reference Agent could commence, alongside the Test Suite, to get us all towards basic working agents. In the months since, I've had a lot of trouble getting this momentum going. Me and my colleague Bryant talked to the BYU team for a while, and they quickly let us know that the nodejs agent is more or less on hiatus. Then we started working with some of the Sovrin folks, namely Sam Curren, on the python agent. Obviously these things are a work-in-progress but, for example, I have been working on a Credentials module for the python agent (which currently lacks one--it's something that definitely needs to be built and its fairly well defined). I have forked this code and, using Indy's anoncreds design & API as a basis, I have stubbed out the features/functions and started to skeleton the code. The Agent itself is somewhat confusing and not well-documented, and I'm quickly realizing I won't be able to use the existing interface to test any of my code. Essentially, I'm trying to study the code in these various repos/languages and synthesize the lessons to port them over to an actual implementation, but finding a simple starting point has been challenging. I'm not trying to sound ungrateful, but attending the calls every week, and creating tickets in Hyperledger JIRA, is still not tantamount to open source collaboration and the idea of a "reference agent" has been floated around for months under different auspices--"it's being worked on", "it's being released soon", "come help build it out", etc. I'm trying to do the latter but I need a little help. With so much interest in Agents, there has to be actual code that we can use & directly contribute to. We're not new to libindy but we're not sdk experts either.
nhelmy (Thu, 15 Nov 2018 19:50:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xF8jW45NkJj73QfYF) @danielhardman As a developer in the Agent space for quite some time, I've been trying to find a codebase that is close to something I can just fork and contribute to, and I've been having a lot of trouble. There are a couple clear candidates, namely Hyperledger Indy Agent (both nodejs and python agents), libvcx (which is being absorbed into indy sdk), connect.me (unclear how different from the previous one), and the VON agents. I have been attending the Agent WG calls regularly, went to the last two IIW's, and even traveled to Utah for the Agent Summit in August. I came out of that weekend having a lot of energy and thinking that work on a Reference Agent could commence, alongside the Test Suite, to get us all towards basic working agents. In the months since, I've had a lot of trouble getting this momentum going. Me and my colleague Bryant talked to the BYU team for a while, and they quickly let us know that the nodejs agent is more or less on hiatus. Then we started working with some of the Sovrin folks, namely Sam Curren, on the python agent. Obviously these things are a work-in-progress but, for example, I have been working on a Credentials module for the python agent (which currently lacks one--it's something that definitely needs to be built and its fairly well defined). I have forked this code and, using Indy's anoncreds design & API as a basis, I have stubbed out the features/functions and started to skeleton the code. The Agent itself is somewhat confusing and not well-documented, and I'm quickly realizing I won't be able to use the existing interface to test any of my code. Essentially, I'm trying to study the code in these various repos/languages and synthesize the lessons to port them over to an actual implementation, but finding a simple starting point has been challenging. I'm not trying to sound ungrateful, but attending the calls every week, and creating tickets in Hyperledger JIRA, is still not tantamount to open source collaboration and the idea of a "reference agent" has been floated around for months under different auspices--"it's being worked on", "it's being released soon", "come help build it out", etc. I'm trying to do the latter but I need a little help. With so much interest in Agents, there has to be actual code that we can use & directly contribute to. We're not new to libindy but we're not sdk experts either.
nhelmy (Thu, 15 Nov 2018 19:50:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xF8jW45NkJj73QfYF) @danielhardman As a developer in the Agent space for quite some time, I've been trying to find a codebase that is close to something I can just fork and contribute to, and I've been having a lot of trouble. There are a couple clear candidates, namely Hyperledger Indy Agent (both nodejs and python agents), libvcx (which is being absorbed into indy sdk), connect.me (unclear how different from the previous one), and the VON agents. I have been attending the Agent WG calls regularly, went to the last two IIW's, and even traveled to Utah for the Agent Summit in August. I came out of that weekend having a lot of energy and thinking that work on a Reference Agent could commence, alongside the Test Suite, to get us all towards basic working agents. In the months since, I've had a lot of trouble getting this momentum going. Me and my colleague Bryant talked to the BYU team for a while, and they quickly let us know that the nodejs agent is more or less on hiatus. Then we started working with some of the Sovrin folks, namely Sam Curren, on the python agent. Obviously these things are a work-in-progress but, for example, I have been working on a Credentials module for the python agent (which currently lacks one--it's something that definitely needs to be built and its fairly well defined). I have forked this code and, using Indy's anoncreds design & API as a basis, I have stubbed out the features/functions and started to skeleton the code. The Agent itself is somewhat confusing and not well-documented, and I'm quickly realizing I won't be able to use the existing interface to test any of my code. Essentially, I'm trying to study the code in these various repos/languages and synthesize the lessons to port them over to an actual implementation, but finding a simple starting point has been challenging as the existing implementations are POC's or otherwise non-extensible. I'm not trying to sound ungrateful, but attending the calls every week, and creating tickets in Hyperledger JIRA, is still not tantamount to open source collaboration and the idea of a "reference agent" has been floated around for months under different auspices--"it's being worked on", "it's being released soon", "come help build it out", etc. I'm trying to do the latter but I need a little help. With so much interest in Agents, there has to be actual code that we can use & directly contribute to. We're not new to libindy but we're not sdk experts either.
nhelmy (Thu, 15 Nov 2018 19:50:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xF8jW45NkJj73QfYF) @gy8409i @danielhardman As a developer in the Agent space for quite some time, I've been trying to find a codebase that is close to something I can just fork and contribute to, and I've been having a lot of trouble. There are a couple clear candidates, namely Hyperledger Indy Agent (both nodejs and python agents), libvcx (which is being absorbed into indy sdk), connect.me (unclear how different from the previous one), and the VON agents. I have been attending the Agent WG calls regularly, went to the last two IIW's, and even traveled to Utah for the Agent Summit in August. I came out of that weekend having a lot of energy and thinking that work on a Reference Agent could commence, alongside the Test Suite, to get us all towards basic working agents. In the months since, I've had a lot of trouble getting this momentum going. Me and my colleague Bryant talked to the BYU team for a while, and they quickly let us know that the nodejs agent is more or less on hiatus. Then we started working with some of the Sovrin folks, namely Sam Curren, on the python agent. Obviously these things are a work-in-progress but, for example, I have been working on a Credentials module for the python agent (which currently lacks one--it's something that definitely needs to be built and its fairly well defined). I have forked this code and, using Indy's anoncreds design & API as a basis, I have stubbed out the features/functions and started to skeleton the code. The Agent itself is somewhat confusing and not well-documented, and I'm quickly realizing I won't be able to use the existing interface to test any of my code. Essentially, I'm trying to study the code in these various repos/languages and synthesize the lessons to port them over to an actual implementation, but finding a simple starting point has been challenging as the existing implementations are POC's or otherwise non-extensible. I'm not trying to sound ungrateful, but attending the calls every week, and creating tickets in Hyperledger JIRA, is still not tantamount to open source collaboration and the idea of a "reference agent" has been floated around for months under different auspices--"it's being worked on", "it's being released soon", "come help build it out", etc. I'm trying to do the latter but I need a little help. With so much interest in Agents, there has to be actual code that we can use & directly contribute to. We're not new to libindy but we're not sdk experts either.
TelegramSam (Fri, 16 Nov 2018 13:42:57 GMT):
I've been doing some design work with Agent Message Families for Admin Messages. Here is a hackmd link for a formal documentation attempt, with footnotes at the bottom that are applicable to agent message design in general. I welcome your comments, questions, and suggestions: https://hackmd.io/mz5kXFTHRZOcy51XHQz7qg?view
darrell.odonnell (Fri, 16 Nov 2018 14:29:53 GMT):
@TelegramSam we should probably get the Hyperledger Calendar updated with the new Indy Agent WG times. (https://calendar.google.com/calendar/embed?src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=UTC)
TelegramSam (Fri, 16 Nov 2018 14:34:55 GMT):
Done. Thanks for the reminder.
mxs1491 (Fri, 16 Nov 2018 15:00:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=7XTkZ76znNjojpzGx) @drummondreed There is also a in depth analysis on GDPR and the Blockchain that was published by Michèle Finck (one of the contributors of the EU report) available on ssrn.com. I have a marked up version of the paper, but as this is my first interaction here, not sure if appropriate to share through this channel. If interested DM me and I am happy to share.
nage (Fri, 16 Nov 2018 16:17:18 GMT):
@danielhardman we had discussed the idea that the Sovrin DID method could explicitly allow for a DNS-like hierarchical resolution in the past, meaning I resolve in the local wallet, then to my trusted parties, then to the ledger, in order to allow peer dids and sov dids to look and behave in the "same way" at least from a developer practicality perspective. The did:peer vs did:sov approach seems to draw a hard line between the two, which in some cases is desirable, but in others quite problematic. I apologize if I just missed the call or deck with the resoning here, but can you explain why you think the bright line there is helpful?
TelegramSam (Fri, 16 Nov 2018 16:36:08 GMT):
I've written up a few observations and my questions as it relates to publishing of DIDs, I welcome comments, suggestions, and questions: https://hackmd.io/awDm1PPZTHaoXZ6ATnLP0A
TelegramSam (Fri, 16 Nov 2018 16:36:16 GMT):
@danielhardman @nage ^
nage (Fri, 16 Nov 2018 16:38:55 GMT):
I'm very nervous about the correlation issues attached with the groupwise construct, I think we'd need the crypto folks to weigh in on that one before we can endorse it
nage (Fri, 16 Nov 2018 16:39:16 GMT):
the best distinction we could draw before was public, and "not public"
danielhardman (Fri, 16 Nov 2018 16:52:34 GMT):
@nage I have a vague recollection of the DNS analogy for DID resolution as something mentioned in passing in a casual way, but in my mind it was not an important concept. I am interested in your comment that the bright line distinction is problematic. Could you elaborate?
To respond to your question about why I think it's helpful: DID methods are tied to legalities, to documented semantics, to trust frameworks, etc. I would think that knowing at a glance which set of assumptions applies to a DID--and not figuring that out in a convoluted way--one potentially alterable outside the creation of the DID itself--might result is much simpler and safer code. But that is more of a gut reaction, not a deeply reasoned argument.
tplooker (Fri, 16 Nov 2018 21:19:35 GMT):
Has joined the channel.
devin-fisher (Fri, 16 Nov 2018 21:25:46 GMT):
@TelegramSam I think Matthew was publishing recording when we were using his zoom room. Now that we have a new zoom room, are we still planning on publishing recordings. If so, did we record Wednesday? If so, where can I find it?
stanleyc-trustscience (Fri, 16 Nov 2018 21:30:16 GMT):
Has joined the channel.
tplooker (Fri, 16 Nov 2018 21:41:53 GMT):
@danielhardman I have been thinking more about message routing, would you say that any agent that receives say a forward message will only ever do one thing with that message, i.e forward it? Would there ever be the case where the message is meant for them so the forward message would invoke them handling it themselves? I.e effectively double handling the message?
The reason I think this would be the case and hence why I'd argue routing needs to be more fundamental, is currently the forward message contains the necessary information needed by the final agent in a complete routing scenario, to un-pack the inner content message. Take for example the following case:
Bob and Alice are already connect and Bob wants to send Alice a message. Alices agent configuration consists of her edge agent and a domain endpoint agent.
1. Bob creates a message and wraps that in a forward message like below.
{
"@type" : "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/routing/1.0/forward",
"to" : "did:sov:1234abcd#4",
"msg" : "
tplooker (Fri, 16 Nov 2018 21:44:01 GMT):
Unless of course the contents of the msg field is not encrypted and instead is a message like that defined in AMES?
TelegramSam (Fri, 16 Nov 2018 23:05:51 GMT):
@tplooker Only the inner message is forwarded when forwarding is used in this manner.
tplooker (Fri, 16 Nov 2018 23:07:55 GMT):
@TelegramSam Ok great so the message inside "msg" is an AMES message? With a recipient header allowing the next agent to unpack it?
TelegramSam (Fri, 16 Nov 2018 23:08:52 GMT):
Yes.
TelegramSam (Fri, 16 Nov 2018 23:10:01 GMT):
and the recipient there isn't leaking anything, because you need the forwarding agent to send it to them anway.
TelegramSam (Fri, 16 Nov 2018 23:10:01 GMT):
and the recipient there isn't leaking anything, because you need the forwarding agent to send it to them anyway.
tplooker (Fri, 16 Nov 2018 23:12:02 GMT):
Ok but agent unpacking the forward can then see the recipients of inner message?
tplooker (Fri, 16 Nov 2018 23:12:02 GMT):
Ok but the agent unpacking the forward can then see the recipients of inner message?
tplooker (Fri, 16 Nov 2018 23:12:02 GMT):
Ok but the agent unpacking the forward can then see the recipients of the inner message?
tplooker (Fri, 16 Nov 2018 23:13:18 GMT):
As it isn't encrypted irrespective of the forward message itself?
TelegramSam (Fri, 16 Nov 2018 23:15:10 GMT):
the recipients block of the inner message is basically the same as the to: field in the outer message.
TelegramSam (Fri, 16 Nov 2018 23:15:20 GMT):
but the message contents are encrypted
TelegramSam (Fri, 16 Nov 2018 23:15:33 GMT):
so, the agent doing the forwarding does know where the message is going.
TelegramSam (Fri, 16 Nov 2018 23:16:18 GMT):
when you have multiple routing steps, only the immediate routing step is visible to the forwarding agent. none of the next steps are visible.
tplooker (Fri, 16 Nov 2018 23:17:05 GMT):
Ok cool thats what I thought, just seems like duplication of information though with the recipient information being re-stated at two levels.
tplooker (Fri, 16 Nov 2018 23:17:05 GMT):
Ok cool thats what I thought, just seems like duplication of information though with the recipient information being stated at two levels.
TelegramSam (Sun, 18 Nov 2018 03:18:03 GMT):
@tplooker that is true, though it's a fairly minor duplication. Keeping the two layers separate (wire message vs agent message) has some good architectural advantages.
yisheng (Mon, 19 Nov 2018 07:18:55 GMT):
Has joined the channel.
mwherman2000 (Mon, 19 Nov 2018 13:35:40 GMT):
Here's an article that provides some background/context/inspiration for the comments I made during last week's meeting (relatively short): https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/
pknowles (Mon, 19 Nov 2018 13:53:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=KtyzcaqhCvHQZnpHG) @mwherman2000 The new DID spec will be useful to you. You can take a look under the hood to see what constructs the DID architecture will allow. https://w3c-ccg.github.io/did-spec/
pknowles (Mon, 19 Nov 2018 13:53:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=KtyzcaqhCvHQZnpHG) @mwherman2000 The new DID spec will be useful to you. You can take a look under the hood to see what constructs are provided by the DID architecture. https://w3c-ccg.github.io/did-spec/
nage (Mon, 19 Nov 2018 19:09:35 GMT):
If you are working on schemas or overlays please join us in #indy-semantics where we will be continuing conversations on json-ld, updates to anoncreds protocol and other encoding, types and schema related stuff.
pknowles (Mon, 19 Nov 2018 22:34:15 GMT):
User User_1 added by pknowles.
TelegramSam (Mon, 19 Nov 2018 22:35:18 GMT):
Call recordings for last week's Agent call are finally up: https://drive.google.com/drive/u/0/folders/1Zc0inl2DrakhZQY4LGU2Mu2TvQ7TcJld
TelegramSam (Mon, 19 Nov 2018 22:36:36 GMT):
I also linked them in the rolling agenda doc.
mhailstone (Tue, 20 Nov 2018 16:47:22 GMT):
All,
The Indy Agent call will be tomorrow (Wednesday, Nov. 21st) from 1:00 PM - 2:30 PM US/Mountain time. Here is the agenda and links for the meeting:
Agent Related HIPE Review
Message Threading:
https://github.com/hyperledger/indy-hipe/blob/613ed302bec4dcc62ed6fab1f3a38ce59a96ca3e/text/message-threading/README.md
Updated Message Type:
https://github.com/hyperledger/indy-hipe/blob/e67d93aea3e0f4b0019d1ae3a9b8a4a96b30e142/text/0021-message-types/README.md
Message Tracing:
https://github.com/hyperledger/indy-hipe/blob/996adb82e61ab63b37a56254b92f57100ff8c8d9/text/message-tracing/README.md
Agent File Format:
https://github.com/hyperledger/indy-hipe/blob/996adb82e61ab63b37a56254b92f57100ff8c8d9/text/message-tracing/README.md
Open Discussion
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
https://zoom.us/j/856588081
HiranKumar (Wed, 21 Nov 2018 06:31:23 GMT):
I tried to install node network using indy-node installation.But failed got an error while installing indy-plenum
HiranKumar (Wed, 21 Nov 2018 06:31:27 GMT):
Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-uv4s4kwz/python-rocksdb/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-wxw2rg93-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-uv4s4kwz/python-rocksdb/
HiranKumar (Wed, 21 Nov 2018 07:34:10 GMT):
The following packages have unmet dependencies:
indy-node : Depends: indy-plenum (= 1.6.53) but it is not going to be installed
Depends: libsodium18 but it is not installable
PhillipGibb (Wed, 21 Nov 2018 14:05:19 GMT):
Hi, In terms of agent/user to agent/user messaging:
is indy-agent messaging similar to the messaging used in vcx?
TelegramSam (Wed, 21 Nov 2018 14:21:10 GMT):
@PhillipGibb vcx messaging uses a provisional format that works with any other vcx solution. The next version of community accepted messaging formats is not yet complete.
TelegramSam (Wed, 21 Nov 2018 14:21:23 GMT):
As you can imagine, this is our highest priority moving forward.
PhillipGibb (Wed, 21 Nov 2018 17:37:34 GMT):
@TelegramSam awesome. I want to start working on something. Where can I start?
TelegramSam (Wed, 21 Nov 2018 18:59:56 GMT):
@PhillipGibb you want to start building on top of something for your own solution, or you want to contribute to the reference agent, or both?
PhillipGibb (Wed, 21 Nov 2018 19:50:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZG7Zj7MM6eboPTHw3) @TelegramSam You mean the indy-agent? Both really. I am very happy you contribute and to use.
I see Messaging Protocol in the docs, is this a protocol that indy agent developers will use for their cloud agents? The part I struggle with is what if there are other issuers and verifiers that do not use that Messaging Protocol - do we need a Message Translator?
So now we have a DID Resolver at DIF
Probably a Schema Resolver - for looking up supported schemas/credential definitions across blockchains
And now a Message Resolver - for translating messages between different agents - eg between uPort, vcx() and indy agents?
PhillipGibb (Wed, 21 Nov 2018 19:51:48 GMT):
@TelegramSam I am happy to start working, start a HIPE? On such a Message Translator for the Community, what do you think?
tplooker (Wed, 21 Nov 2018 20:02:12 GMT):
Agent WG call happening now on https://zoom.us/j/856588081
TelegramSam (Wed, 21 Nov 2018 20:49:22 GMT):
@PhillipGibb There is the goal of making the base message format the same between uPort, Indy, and DIF Hubs.
TelegramSam (Wed, 21 Nov 2018 20:49:31 GMT):
So in that case, no translator would be needed.
stanleyc-trustscience (Wed, 21 Nov 2018 21:02:56 GMT):
Heard someone in the WG call referring vcx as "the old vcx", is the VCX project sort of being depreciated?
stanleyc-trustscience (Wed, 21 Nov 2018 21:02:56 GMT):
Heard someone in the WG call referring vcx as "the old vcx", is the VCX project being sort of depreciated?
stanleyc-trustscience (Wed, 21 Nov 2018 23:55:25 GMT):
Was just browsing through python reference agent at:
https://github.com/hyperledger/indy-agent/blob/master/python/indy-agent.py#L128
This seems to be looping through all DIDs stored in agent's wallet. Is there a better way to figure out the VerKey of the message, instead of doing this sort of brute-force type of search?
stanleyc-trustscience (Wed, 21 Nov 2018 23:55:25 GMT):
Was just looking at python reference agent at:
https://github.com/hyperledger/indy-agent/blob/master/python/indy-agent.py#L128
This seems to be looping through all DIDs stored in agent's wallet. Is there a better way to figure out the VerKey of the message, instead of doing this sort of brute-force type of search?
stanleyc-trustscience (Wed, 21 Nov 2018 23:55:25 GMT):
Was just looking at python reference agent at:
https://github.com/hyperledger/indy-agent/blob/master/python/indy-agent.py#L128
This seems to be looping through all DIDs stored in agent's wallet. Is there a better way to figure out the VerKey of the message, instead of doing this brute-force type of search?
stanleyc-trustscience (Thu, 22 Nov 2018 00:57:01 GMT):
@TelegramSam Is it possible to provide the parent folder link of this location?
https://drive.google.com/drive/u/0/folders/1Zc0inl2DrakhZQY4LGU2Mu2TvQ7TcJld
So that it's easier to see past recording by navigating in google drive directory? Assuming all recording are stored under the same parent folder
stanleyc-trustscience (Thu, 22 Nov 2018 00:57:01 GMT):
@TelegramSam Is it possible to provide the parent folder link of this location?
https://drive.google.com/drive/u/0/folders/1Zc0inl2DrakhZQY4LGU2Mu2TvQ7TcJld
So that it's easier to see past recordings by navigating in google drive directory? Assuming all recording are stored under the same parent folder
dbluhm (Thu, 22 Nov 2018 01:29:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=pwwAeZo6oJ9JoPq6j) @stanleyc-trustscience I don't believe this is how we see doing this in the long run. @kdenhartog and @MALodder are working on pack and unpack methods to be used as the "wire message" format for agent messages.
TelegramSam (Thu, 22 Nov 2018 13:28:05 GMT):
@stanleyc-trustscience The new wire message format that @dbluhm referred to contains a 'to' address that will not require trial decryption. The reference agent does so currently as a hack while we wait for that upgrade.
TelegramSam (Thu, 22 Nov 2018 13:33:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=EwuSZFiQjQm2aHFJ6) @stanleyc-trustscience The very parent folder is here: https://drive.google.com/drive/u/0/folders/111FWCb8cIsEzN-5yhTACyXtKwCnenLDu
TelegramSam (Thu, 22 Nov 2018 13:34:14 GMT):
Note that the Agent call used to be on Friday, and we haven't renamed it yet.
TelegramSam (Thu, 22 Nov 2018 13:35:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=sFxpMFhLom3TaewmK) @stanleyc-trustscience Not necessarily. The part we will need to be updating is the agent protocol it uses, which doesn't support the new message family design or the almost done wire level protocol.
TelegramSam (Thu, 22 Nov 2018 15:23:52 GMT):
Recorded Agent call: https://drive.google.com/drive/u/0/folders/1Bjb4uUWHKAgv0wtbJYr2tTOSDfpRDbq2
TelegramSam (Thu, 22 Nov 2018 15:24:14 GMT):
link also in the Perpetual Agenda Doc: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#
stanleyc-trustscience (Thu, 22 Nov 2018 20:44:31 GMT):
@TelegramSam Thank you Sam, that was really helpful
carsten (Fri, 23 Nov 2018 03:59:31 GMT):
Has joined the channel.
HiranKumar (Fri, 23 Nov 2018 09:09:05 GMT):
I tried to setup the network and starting the nodes using this link https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md.But it is failed due to the below error .Anyone please help me to solve this issue.
HiranKumar (Fri, 23 Nov 2018 09:09:50 GMT):
Command "/usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-uv4s4kwz/python-rocksdb/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, _file_, 'exec'))" install --record /tmp/pip-wxw2rg93-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /tmp/pip-build-uv4s4kwz/python-rocksdb/
HiranKumar (Fri, 23 Nov 2018 09:13:24 GMT):
Clipboard - November 23, 2018 2:42 PM
HiranKumar (Fri, 23 Nov 2018 09:13:32 GMT):
I installed a node of network using docker in a linux vm.And the docker container is running like as shown below
HiranKumar (Fri, 23 Nov 2018 09:13:37 GMT):
Clipboard - November 23, 2018 2:42 PM
HiranKumar (Fri, 23 Nov 2018 09:14:14 GMT):
I tried to connect the network from the local machine using indy-cli.
HiranKumar (Fri, 23 Nov 2018 09:15:44 GMT):
But got the below error
HiranKumar (Fri, 23 Nov 2018 09:15:52 GMT):
Clipboard - November 23, 2018 2:45 PM
HiranKumar (Fri, 23 Nov 2018 09:16:12 GMT):
Anyone please help me to solve this issue
TelegramSam (Fri, 23 Nov 2018 15:53:19 GMT):
@HiranKumar are you looking to explore indy-agent? If so, you might check Stephen Curren's PR against the indy-agent branch. He has a docker compose script that we are evaluating.
As far as help with indy-sdk / local network issues, you'll find deeper knowledge in the #indy-sdk and #indy-node channels.
janl (Mon, 26 Nov 2018 10:10:00 GMT):
Has joined the channel.
TelegramSam (Mon, 26 Nov 2018 16:10:10 GMT):
New Merge in the Python reference Agent from @haggs: new command line arguments for attaching to a wallet.
lwan2000 (Mon, 26 Nov 2018 17:11:40 GMT):
Has joined the channel.
dbluhm (Mon, 26 Nov 2018 21:49:55 GMT):
@haggs or others: I recently attempted to try out @swcurran's docker setup for the python reference agent but due to issues on my end I haven't been able to fully test it yet. Have you tried out his docker setup by chance?
TelegramSam (Tue, 27 Nov 2018 17:37:10 GMT):
I got the docker stuff to work from a demo perspective, but have not yet been able to get it to work integrated into a development workflow.
TelegramSam (Tue, 27 Nov 2018 17:37:21 GMT):
Note: I'm using Docker on Windows 10, which is Hyper V based.
mhailstone (Tue, 27 Nov 2018 17:58:48 GMT):
@TelegramSam here is a copy of a modified `docker-compose` file that I'm using to attach to the processes and debug the node.js reference agent code:
```version: '3'
networks:
services:
ipam:
config:
- subnet: 173.17.0.0/24
services:
#
# Pool
#
pool:
build:
context: .
dockerfile: indy-pool.dockerfile
args:
- pool_ip=173.17.0.100
ports:
- 9701-9708:9701-9708
networks:
services:
ipv4_address: 173.17.0.100
#
# Agents
#
government:
image: indy-agentjs
build:
context: .
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
# command: "bash -c 'npm start'"
environment:
- PORT=3000
- NAME=Government
- EMAIL=government@example.com
- PASSWORD=123
- USERNAME=government
- PUBLIC_DID_ENDPOINT=173.17.0.99:3000
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3000:3000
- 9220:9229
depends_on:
- pool
networks:
services:
ipv4_address: 173.17.0.99
alice:
image: indy-agentjs
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
# command: "bash -c 'npm start'"
environment:
- PORT=3001
- NAME=Alice
- EMAIL=alice@example.com
- PASSWORD=123
- USERNAME=alice
- PUBLIC_DID_ENDPOINT=173.17.0.11:3001
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3001:3001
- 9221:9229
depends_on:
- pool
- government
networks:
services:
ipv4_address: 173.17.0.11
#
#
bob:
image: indy-agentjs
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
# command: "bash -c 'npm start'"
environment:
- PORT=3002
- NAME=Bob
- EMAIL=bob@example.com
- PASSWORD=123
- USERNAME=bob
- PUBLIC_DID_ENDPOINT=173.17.0.22:3002
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3002:3002
- 9222:9229
depends_on:
- pool
- government
networks:
services:
ipv4_address: 173.17.0.22
faber:
image: indy-agentjs
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
# command: "bash -c 'npm start'"
environment:
- PORT=3003
- NAME=Faber University
- EMAIL=faber@example.com
- PASSWORD=123
- USERNAME=faber
- PUBLIC_DID_ENDPOINT=173.17.0.33:3003
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3003:3003
- 9223:9229
depends_on:
- pool
- government
networks:
services:
ipv4_address: 173.17.0.33
acme:
image: indy-agentjs
# command: "bash -c 'npm start'"
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
environment:
- PORT=3004
- NAME=Acme Corporation
- EMAIL=acme@example.com
- PASSWORD=123
- USERNAME=acme
- PUBLIC_DID_ENDPOINT=173.17.0.44:3004
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3004:3004
- 9224:9229
depends_on:
- pool
- government
networks:
services:
ipv4_address: 173.17.0.44
thrift:
image: indy-agentjs
# command: "bash -c 'npm start'"
command: "bash -c 'node --inspect=0.0.0.0 ./bin/www'"
environment:
- PORT=3005
- NAME=Thrift Bank
- EMAIL=thrift@example.com
- PASSWORD=123
- USERNAME=thrift
- PUBLIC_DID_ENDPOINT=173.17.0.55:3005
- DOCKERHOST=${DOCKERHOST}
- RUST_LOG=${RUST_LOG}
- TEST_POOL_IP=${TEST_POOL_IP}
ports:
- 3005:3005
- 9225:9229
depends_on:
- pool
- government
networks:
services:
ipv4_address: 173.17.0.55
```
mhailstone (Tue, 27 Nov 2018 17:59:42 GMT):
The new command to start the inspector and additional ports were what was changed.
TelegramSam (Tue, 27 Nov 2018 19:56:04 GMT):
Indy-Agent MR 43: Addition of the AdminWalletConnection family, as well as some minor core improvements. https://github.com/hyperledger/indy-agent/pull/43
TelegramSam (Tue, 27 Nov 2018 20:04:34 GMT):
Merged PR 42 from @dbluhm: Minor fixes and removal of unneeded docs files. https://github.com/hyperledger/indy-agent/pull/42. Thanks Daniel!
mhailstone (Tue, 27 Nov 2018 20:53:39 GMT):
Indy Agent Call - 11/28/2018
All,
The Indy Agent call will be tomorrow 1:00 - 2:30 PM US/Mountain Time.
The agenda will be:
- Agent Related HIPE Review
- Open Discussion
Also, here is the zoom meeting and Google document links:
https://zoom.us/j/856588081
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
janl (Tue, 27 Nov 2018 22:01:58 GMT):
I have introduced a new HIPE covering consent receipt (https://github.com/hyperledger/indy-hipe/pull/55). Hopefully we have spare time to discuss it in tomorrow agent call. I would like to give a high level overview and answer any questions. Thanx
TelegramSam (Wed, 28 Nov 2018 15:18:58 GMT):
We have not declared the list of supported browsers for the Reference Agent Admin Console that is part of the Python Ref Agent. Opinions?
TelegramSam (Wed, 28 Nov 2018 15:21:07 GMT):
on a slightly related note, any opinions on including lodash as a dependency? We use Vue.js, which is intentionally light when compensating for js limitations. Lodash is established and solves many object/array code utility issues.
canadaduane (Wed, 28 Nov 2018 16:00:33 GMT):
Has joined the channel.
dbluhm (Wed, 28 Nov 2018 17:09:05 GMT):
Merged PR 42 from @TelegramSam which adds the admin_wallet_connection family to the python reference agent
dbluhm (Wed, 28 Nov 2018 17:09:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=3Jcv34rJyFFTyfvxT) @TelegramSam I'm open to adding lodash as a dependency.
TelegramSam (Wed, 28 Nov 2018 18:29:13 GMT):
New PR: Demonstrating using callbacks with agent message threads: https://github.com/hyperledger/indy-agent/pull/44
TelegramSam (Wed, 28 Nov 2018 18:29:22 GMT):
I can talk about this on the call today.
MALodder (Wed, 28 Nov 2018 19:30:47 GMT):
So I will be occupied with other meetings today and will not be on the call
dbluhm (Wed, 28 Nov 2018 22:20:42 GMT):
Submitted a new PR: https://github.com/hyperledger/indy-agent/pull/45
This one removes a somewhat inappropriately named `model.py`
kdenhartog (Thu, 29 Nov 2018 01:20:24 GMT):
@TelegramSam brave browser support would be awesome! It's built on Chromium so it should be easy. Also, If want to go full crypto Beaker browser would be another cool one.
TelegramSam (Thu, 29 Nov 2018 14:42:19 GMT):
Anything Chromium should be easy. Mostly, I'm thinking of IE11, which lacks most of the newer language support.
TelegramSam (Thu, 29 Nov 2018 16:15:59 GMT):
Wed Agent Call recording posted: https://drive.google.com/drive/u/0/folders/18jh9ecOkxUB7-FIJPNH5n8ikbu0-bTbZ
TelegramSam (Thu, 29 Nov 2018 16:16:08 GMT):
(also linked in the meeting notes doc)
HiranKumar (Thu, 29 Nov 2018 17:12:34 GMT):
In an identity management system of a company,who created the did for each user(employee)?.
kdenhartog (Thu, 29 Nov 2018 17:15:17 GMT):
the employee would because they're generating the private keys.
HiranKumar (Thu, 29 Nov 2018 17:16:14 GMT):
What are the key values needed for creating a did
HiranKumar (Thu, 29 Nov 2018 17:16:15 GMT):
?
kdenhartog (Thu, 29 Nov 2018 17:16:30 GMT):
key values?
kdenhartog (Thu, 29 Nov 2018 17:17:11 GMT):
I'm not sure what you're referencing here. key is a fairly overloaded term in our space.
kdenhartog (Thu, 29 Nov 2018 17:17:38 GMT):
are you thinking of a key as in important values?
HiranKumar (Thu, 29 Nov 2018 17:18:29 GMT):
endpoinddid and the did are same?
HiranKumar (Thu, 29 Nov 2018 17:18:33 GMT):
or different
kdenhartog (Thu, 29 Nov 2018 17:19:48 GMT):
oh, gotcha. No those are two separate values. Think of a DID as a point that points to important pieces of data like endpoints (how I can send messages to that entity) and keys (how I can authorize that I'm speaking with the correct entity)
kdenhartog (Thu, 29 Nov 2018 17:20:10 GMT):
This data is referred to as the DID Doc
HiranKumar (Thu, 29 Nov 2018 17:21:47 GMT):
ok
HiranKumar (Thu, 29 Nov 2018 17:22:29 GMT):
So for communication purpose we are using this endpoint did.right?
HiranKumar (Thu, 29 Nov 2018 17:23:15 GMT):
And did is for identifying the entity.right?
kdenhartog (Thu, 29 Nov 2018 17:26:25 GMT):
correct, although the endpoint may be a DID (@drummondreed please correct me if this is not spec compliant) most people think of them as URLs
kdenhartog (Thu, 29 Nov 2018 17:26:25 GMT):
correct, although the endpoint may be a DID ( @drummondreed please correct me if this is not spec compliant) most people think of them as URLs
drummondreed (Thu, 29 Nov 2018 17:38:36 GMT):
Yes, the endpoint can be referenced with a DID—that's a common pattern emerging.
HiranKumar (Thu, 29 Nov 2018 17:53:51 GMT):
ok
HiranKumar (Thu, 29 Nov 2018 17:55:39 GMT):
What is a node in an indy hyper ledger
HiranKumar (Thu, 29 Nov 2018 17:56:40 GMT):
I mean in the network
TelegramSam (Thu, 29 Nov 2018 18:14:00 GMT):
a node is a validator of ledger transactions.
HiranKumar (Thu, 29 Nov 2018 18:14:34 GMT):
Is the did is created as part of the wallet creation?
HiranKumar (Thu, 29 Nov 2018 18:15:08 GMT):
Thanks @TelegramSam
TelegramSam (Thu, 29 Nov 2018 19:29:57 GMT):
DIDs and associated keys are stored in the wallet. One wallet can store as many DIDs/keys as the wallet owner requires.
donqui (Fri, 30 Nov 2018 15:34:12 GMT):
Has joined the channel.
HiranKumar (Mon, 03 Dec 2018 05:37:18 GMT):
For communication between agents,do we need to create endpointdid for all agents
swcurran (Mon, 03 Dec 2018 11:10:19 GMT):
@danielhardman and I have proposed a new HIPE about agent to agent messaging error handling that introduces a new message type - "problem-report" that is useful for some categories of errors. The HIPE also describes some (currently) recommended approaches to many error handling categories. There are also some thoughts about adjustments to other HIPEs (threading, tracing and the "Forward" message type) to improve error handling capabilities.
https://github.com/hyperledger/indy-hipe/pull/65
DirkT (Mon, 03 Dec 2018 14:52:16 GMT):
Has joined the channel.
HiranKumar (Tue, 04 Dec 2018 11:12:50 GMT):
How can we store the credentials and do the verification process without using ledger?
swcurran (Tue, 04 Dec 2018 11:49:11 GMT):
@HiranKumar what is tour use case - offline use? That is possible with caching, assuming you know what you are going to prove our verify. Only tricky part is agreeing on how fresh the proof of non-revocation the Verifier is willing to accept.
If not about offline use, then the ledger is used to get schema, credential definition and revocation information during proving and verifying.
swcurran (Tue, 04 Dec 2018 11:49:11 GMT):
@HiranKumar what is your use case - offline use? That is possible with caching, assuming you know what you are going to prove our verify. Only tricky part is agreeing on how fresh the proof of non-revocation the Verifier is willing to accept.
If not about offline use, then the ledger is used to get schema, credential definition and revocation information during proving and verifying.
swcurran (Tue, 04 Dec 2018 11:49:11 GMT):
@HiranKumar what is your use case - offline use? That is possible with caching, assuming you know what you are going to prove or verify. Only tricky part is agreeing on how fresh the proof of non-revocation the Verifier is willing to accept.
If not about offline use, then the ledger is used to get schema, credential definition and revocation information during proving and verifying.
TelegramSam (Tue, 04 Dec 2018 13:50:39 GMT):
PR from @dbluhm in Python Ref Agent. This merge contains some small but important refactors against the core Agent and Message classes that will serve as a base for future improvements. https://github.com/hyperledger/indy-agent/commit/4d5d51fb5aa8566fd94d1a6ee8df4464a86120fd
TelegramSam (Tue, 04 Dec 2018 13:50:39 GMT):
Merged PR from @dbluhm in Python Ref Agent. This merge contains some small but important refactors against the core Agent and Message classes that will serve as a base for future improvements. https://github.com/hyperledger/indy-agent/commit/4d5d51fb5aa8566fd94d1a6ee8df4464a86120fd
dbluhm (Tue, 04 Dec 2018 18:01:48 GMT):
Merged PR #44 from @TelegramSam that demonstrates using threading to report errors. https://github.com/hyperledger/indy-agent/pull/44#pullrequestreview-181398152
dbluhm (Tue, 04 Dec 2018 18:01:48 GMT):
Merged PR #44 from @TelegramSam that demonstrates using threading to report errors. https://github.com/hyperledger/indy-agent/pull/44
MiguelFJimenezSola (Tue, 04 Dec 2018 19:25:56 GMT):
Has joined the channel.
TelegramSam (Tue, 04 Dec 2018 20:12:57 GMT):
new PR. Refactoring the Message class: https://github.com/hyperledger/indy-agent/pull/46
kdenhartog (Tue, 04 Dec 2018 20:57:59 GMT):
I've moved Pack/Unpack to FCP with the blessing of @TelegramSam and @MALodder in alignment with the HIPE now
MALodder (Tue, 04 Dec 2018 21:18:44 GMT):
Agreed
TelegramSam (Tue, 04 Dec 2018 21:21:15 GMT):
Email sent to the mailing list.
danielhardman (Tue, 04 Dec 2018 22:07:27 GMT):
I have been exploring the idea of writing a did:peer method spec. This would document how to manage a relationship and its associated DIDs and keys purely through peer-to-peer communication. It would not be specific to Indy, though it would be implemented using Indy messaging concepts because A2A addresses many of the mechanisms it needs. Anybody want to collaborate?
tplooker (Tue, 04 Dec 2018 23:44:35 GMT):
Im also keen to hear from anyone who is thinking about routing records in particular how we achieve safe maintenance of them between agents, starting to write a HIPE but any input would be greatly appreciated!
TelegramSam (Wed, 05 Dec 2018 01:19:11 GMT):
@tplooker The Agent meeting tomorrow is all about routing.
TelegramSam (Wed, 05 Dec 2018 01:19:24 GMT):
@danielhardman I'm quite interested in collaborating on the topic.
danielhardman (Wed, 05 Dec 2018 06:59:02 GMT):
@TelegramSam I am thinking that we want a message family that includes the following message types: join_us (that is, provide my genesis txns for kicking off the relationship), leave_us (abandon/terminate my part of a relationship), update_me, reject_update, ack_update. I want to have you teach me about the JSON Diff concept so we can handle any single atomic change in update_me.
danielhardman (Wed, 05 Dec 2018 06:59:02 GMT):
@TelegramSam I am thinking that we want a message family that includes the following message types: `join_us` (that is, provide my genesis txns for kicking off the relationship), `leave_us` (abandon/terminate my part of a relationship), `update_me`, `reject_update`, `ack_update`. I want to have you teach me about the JSON Diff concept so we can handle any single atomic change in `update_me`.
danielhardman (Wed, 05 Dec 2018 06:59:02 GMT):
@TelegramSam I am thinking that we want a message family that includes the following message types: `join_us` (that is, provide my genesis txns for kicking off the relationship), `leave_us` (abandon/terminate my part of a relationship), `update_me`, `reject_update`, `ack_update`. I want to have you teach me about the JSON Diff concept so we can handle any single atomic change in `update_me`. We may also need `ack_join` and `reject_join`. Maybe we can combine ack and reject into `respond` instead...
danielhardman (Wed, 05 Dec 2018 07:02:26 GMT):
We may also need `ack_join` and `reject_join`. Maybe we can combine ack and reject into `respond` instead...
HiranKumar (Wed, 05 Dec 2018 07:15:26 GMT):
While creating schma defention,I got the below error .CommonInvalidStructure.
HiranKumar (Wed, 05 Dec 2018 07:15:28 GMT):
[ '8y8Ft18TqRRcYHFZPy63rb:2:userinformation:1.2',
{ ver: '1.0',
id: '8y8Ft18TqRRcYHFZPy63rb:2:userinformation:1.2',
name: 'userinformation',
version: '1.2',
attrNames: [ '"name"', '"username"', '"password"' ],
seqNo: 49 } ]
HiranKumar (Wed, 05 Dec 2018 07:16:07 GMT):
It returned while executing sdk.issuerCreateAndStoreCredentialDef(
HiranKumar (Wed, 05 Dec 2018 07:16:33 GMT):
schema is just
HiranKumar (Wed, 05 Dec 2018 07:16:46 GMT):
[ '8y8Ft18TqRRcYHFZPy63rb:2:userinformation:1.2',
{ ver: '1.0',
id: '8y8Ft18TqRRcYHFZPy63rb:2:userinformation:1.2',
name: 'userinformation',
version: '1.2',
attrNames: [ '"name"', '"username"', '"password"' ],
seqNo: 49 } ]
danielhardman (Wed, 05 Dec 2018 14:10:15 GMT):
Someone contacted me directly to ask for a summary of indy agent status -- basically, "how feasible is it to write an agent, and where is the info that would let me do it?" I thought the answer to that question would be of general interest, so I am reposting what I responded here. Of course, my opinion isn't gospel, but this is how I see it, FWIW.
danielhardman Technical Ambassador 7:08 AM
The A2A mechanism in Indy is actually composed of several different pieces, and they are documented separately. Each is maturing very rapidly, but each is less than fully mature:
1. A "wire format" that explains how agents serialize and encrypt messages when they send them over an arbitrary transport (bluetooth, SSH tunnel, https, mobile push notifications, etc). The HIPE for this is in Final Comment Period and will likely be merged in a couple weeks: https://github.com/hyperledger/indy-hipe/pull/43
2. Several HIPEs that describe agent messages at a higher level (when they are JSON and before they get serialized and encrypted): https://github.com/hyperledger/indy-hipe/tree/master/text/0017-agent-message-structure (merged and more or less final), https://github.com/hyperledger/indy-hipe/tree/master/text/0021-message-types (also merged), https://github.com/hyperledger/indy-hipe/pull/30, https://github.com/hyperledger/indy-hipe/pull/65, https://github.com/hyperledger/indy-hipe/pull/64, https://github.com/hyperledger/indy-hipe/pull/61
3. Conventions around DID Docs that tell agents how to communicate with one another (merged and more or less final): https://github.com/hyperledger/indy-hipe/tree/master/text/0023-diddoc-conventions. Note that today's Indy Agent call will discuss some further nuances of routing that may end up being written in a different HIPE.
4. Conventions around how agents get connected in the first place (this one is still a bit controversial but is beginning to move toward closure): https://github.com/hyperledger/indy-hipe/pull/54
5. Discussions about the notion of microledgers -- how agents can share and persist state for their relationships without using the main public ledger at all. These discussions are probably still a month away from becoming settled, and 2 months away from become an agreed standard. They are the least mature. https://github.com/hyperledger/indy-hipe/pull/31, https://github.com/hyperledger/indy-hipe/pull/50
6. Reference agents. This is the purpose of the indy-agent repo. That repo contains code contributed by multiple parties, and is likely to contain more as more and more interesting types of agents emerge. For example, I am working on an email-based agent, and I suspect we'll also see an agent for an embedded IoT device soon. There is also a reference edge agent that's a rich mobile app that's in the process of being contributed, and an agent that is a rich cloud agent for a consumer. The agents that are there right now tend to focus more on institutional use cases. All of the code in this repo is in flux and will need updates as some of the HIPEs above get merged and become "official."
The bottom line with all of this is that it is possible to write an Indy agent today, but there are many questions about doing so that are still being answered. As a result, most of the progress on agents is being made by organizations that are willing to thrash a bit and are brave about asking lots of questions and having a few dead ends. There is not a tidy, polished recipe that people can just follow and know that they'll produce exactly what they need, and there is not an "Agent Developer's Guide" yet, either. Both of those things are much needed and will emerge in the next several months, I believe.
swcurran (Wed, 05 Dec 2018 14:18:55 GMT):
Excellent answer - great summary. Now let's keep removing the awkward bits!
danielhardman (Wed, 05 Dec 2018 14:29:25 GMT):
Since today's indy agent call is all about routing, I've been meditating lately on how to explain some of our thinking there in an easy way. I worry that some of the routing might feel complex, when it actually falls out of a few basic principles and two roles that add flexibility in a communication chain, "relay" and "mediator". (As I mentioned above, I've also been working on an email-based agent, and this has taken me down a road that forces the more common http-based patterns to be generalized...) I started a doc in HIPE format but haven't raised it as a PR because I became uncertain where it belonged. I'm hoping I can share the doc on the call, for a least a few minutes. But in case the agenda is already filled, here's a link to it for anyone who's interested. https://github.com/dhh1128/indy-hipe/blob/mediators-and-relays/text/mediators-and-relays/README.md
mhailstone (Wed, 05 Dec 2018 15:02:29 GMT):
All,
We have our Indy Agent call at 1:00 - 2:30 PM US/Mountain time.
Agenda
- Message Routing - Tobias Looker
- "Mediator" and "relay" in a communication chain - Daniel Hardman
- Open Discussion
The minutes/agenda Google document and zoom link are:
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#heading=h.oi6go5oamtlh
https://zoom.us/j/856588081
TelegramSam (Wed, 05 Dec 2018 15:54:41 GMT):
After reviewing Daniel's doc, I think we may want to switch presentation order with Tobias. We'll have that conversation at the start of the meeting.
MALodder (Wed, 05 Dec 2018 16:09:42 GMT):
@danielhardman Let me know when you have submitted the routing PR as I am curious as to what you have to say
jakubkoci (Wed, 05 Dec 2018 16:11:10 GMT):
Has joined the channel.
mboyd (Wed, 05 Dec 2018 16:50:24 GMT):
FYI, the Sovrin Connector Application code has now been merged into https://github.com/sovrin-foundation/connector-app. I am in the slow process of learning how it works and how to build it. My goal is to collaboratively create a reference mobile app that conforms to the current A2A communication standards.
mboyd (Wed, 05 Dec 2018 16:50:24 GMT):
FYI, the Sovrin Connector Application code has now been merged into https://github.com/sovrin-foundation/connector-app. I am in the slow process of learning how it works and how to build it. My goal is to collaboratively create a reference mobile app that conforms to the current A2A communication standards.
@danielhardman you may be the person in this group that understands the current state of this app's communication protocol. Any more information on the work needed to change this code base into a reference agent would be much appreciated.
mboyd (Wed, 05 Dec 2018 16:52:08 GMT):
^^ or at least some snapshot of the protocol that is closer to our current thinking
TelegramSam (Wed, 05 Dec 2018 17:12:52 GMT):
@mboyd Wire level is coming fast, app level structure has been well accepted, still filling out the message families.
JonathanGiglio (Wed, 05 Dec 2018 17:52:34 GMT):
Has joined the channel.
tplooker (Wed, 05 Dec 2018 19:18:29 GMT):
@mboyd and anyone else that is keen on a reference mobile app or where to get started, we have just merged in a sample Xamarin app (https://github.com/streetcred-id/agent-framework/tree/master/samples/xamarin-mobile-sample) which consumes the Agent-Framework SDK (repo in which the sample is contained) essentially a c# version of libVCX that is closer in step with the current WG thinking on A2A in general, we are in the process of adding more samples and documentation at the moment.
tplooker (Wed, 05 Dec 2018 19:20:46 GMT):
@TelegramSam Happy to swap and let you present first @danielhardman, majority of my presentation is asking questions around how we would like routing to function and proposing a draft solution.
TelegramSam (Wed, 05 Dec 2018 19:22:24 GMT):
sounds good!
tplooker (Wed, 05 Dec 2018 20:07:06 GMT):
https://zoom.us/j/856588081
tplooker (Wed, 05 Dec 2018 20:07:06 GMT):
Hi guys since the call I have reworked the routing records example, I dont believe it is ready to submit as a HIPE yet but if anyone would like to take a checkout https://github.com/tplooker/indy-hipe/blob/agent-message-routing/text/agent-message-routing/README.mdhttps://github.com/tplooker/indy-hipe/blob/agent-message-routing/text/agent-message-routing/README.md, any comments and or recommendations welcome!
tplooker (Wed, 05 Dec 2018 20:07:22 GMT):
@mboyd ^
mboyd (Wed, 05 Dec 2018 20:07:48 GMT):
thx
mhailstone (Wed, 05 Dec 2018 20:07:57 GMT):
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
mhailstone (Wed, 05 Dec 2018 20:08:17 GMT):
https://zoom.us/j/856588081
dbluhm (Wed, 05 Dec 2018 21:13:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uzQeawcNDcqdorDtR) @kdenhartog I left a couple of comments with questions in the HIPE.
kdenhartog (Wed, 05 Dec 2018 21:34:30 GMT):
I saw that I'll take a look at them and fix them after my meetings today. Thanks for reading through them.
PatrikStas (Wed, 05 Dec 2018 21:35:04 GMT):
Has joined the channel.
TelegramSam (Wed, 05 Dec 2018 22:29:09 GMT):
All: How complete do we want the docker stuff before we approve the PR? I've tested it, and it works well as long as you don't fall into any docker gotchas. I've made it out of a number of those problem areas with a little help from Docker informed folks, but not all those I've documented are mentioned in the PR's readme files.
Thoughts?
dbluhm (Wed, 05 Dec 2018 22:39:01 GMT):
I think that overall, the more information we have in the docs, the fewer questions we'll have to answer over and over in chat. So if we can at least link to good resources, I think that would be a welcome addition worth waiting a little longer for.
TelegramSam (Thu, 06 Dec 2018 17:08:15 GMT):
New PR: Renames UI module and messages to Admin, as well as invitation persistance via the non secrets api. Also extracted messages to a new BasicMessage module and message family.
https://github.com/hyperledger/indy-agent/pull/47
HiranKumar (Fri, 07 Dec 2018 07:10:44 GMT):
Why we got the error likw walletaccessfailed
HiranKumar (Fri, 07 Dec 2018 07:10:46 GMT):
?
swcurran (Fri, 07 Dec 2018 08:09:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RSFQ5rNKAEd7ccv7G) @TelegramSam I've got a bit of time now to update the docs. Sorry for the delay - I've been less connected than I thought as we were travelling around. More time now as things wrap up.
swcurran (Fri, 07 Dec 2018 08:18:55 GMT):
@TelegramSam - is there an agent call recording from this week I can listen to?
HiranKumar (Fri, 07 Dec 2018 09:50:08 GMT):
While executing sdk.issuerCreateAndStoreCredentialDef using the schema ["Th7MpTaRZVRYnPiabds81Y:2:userinfor126:1.2",{"ver":"1.0","id":"Th7MpTaRZVRYnPiabds81Y:2:userinfor126:1.2","name":"userinfor126","version":"1.2","attrNames":["name","password","place","username","age"],"seqNo":92}]
HiranKumar (Fri, 07 Dec 2018 09:50:42 GMT):
I got the error CommonInvalidstructiure -113
HiranKumar (Fri, 07 Dec 2018 09:50:57 GMT):
Would you please help me to solve this issue
donqui (Fri, 07 Dec 2018 09:53:08 GMT):
@HiranKumar try posting in the indy-sdk channel there should be more people online there, and paste any logs around the error if you have any
donqui (Fri, 07 Dec 2018 09:53:08 GMT):
@HiranKumar try posting in the indy-sdk channel there should be more people online there, and paste logs around the error if you have any
HiranKumar (Fri, 07 Dec 2018 09:53:46 GMT):
Thanks @donqui
TelegramSam (Fri, 07 Dec 2018 16:45:38 GMT):
@swcurran Posted: https://drive.google.com/drive/u/0/folders/1DbsblDdm2O-MxQqhcoEm8rZR2FDVJ3yx
TelegramSam (Fri, 07 Dec 2018 16:45:45 GMT):
(Sorry I was slow)
TelegramSam (Fri, 07 Dec 2018 16:46:02 GMT):
Call recordings from this week's agent call: https://drive.google.com/drive/u/0/folders/1DbsblDdm2O-MxQqhcoEm8rZR2FDVJ3yx
tplooker (Fri, 07 Dec 2018 22:30:34 GMT):
Hi guy since the call I have modified the routing records example, as I dont believe it is ready as a HIPE yet, anyone interested in checking it out, please take a look at https://github.com/tplooker/indy-hipe/blob/agent-message-routing/text/agent-message-routing/README.md
tplooker (Fri, 07 Dec 2018 22:30:34 GMT):
Hi guys since the call I have modified the routing records example, as I don't believe it is ready as a HIPE yet, anyone interested in checking it out, please take a look at https://github.com/tplooker/indy-hipe/blob/agent-message-routing/text/agent-message-routing/README.md
tplooker (Fri, 07 Dec 2018 22:35:46 GMT):
Also @danielhardman I hope you don't mind me using your picture in my example
danielhardman (Fri, 07 Dec 2018 23:12:35 GMT):
@tplooker Not at all. In fact, if any of the diagrams are helpful in original form, here's where I built them so you can make variations: https://docs.google.com/presentation/d/1L-lbj6aHrbtprA1fa4BsJBxNtW3YS_D811auuxfoevY/edit (all the graphics inside the diagrams are public domain or CC0, too)
jeff_g (Sun, 09 Dec 2018 12:37:21 GMT):
Has joined the channel.
SanjayJain (Sun, 09 Dec 2018 19:16:55 GMT):
Has joined the channel.
JeromeK13 (Mon, 10 Dec 2018 09:12:33 GMT):
Has joined the channel.
TelegramSam (Mon, 10 Dec 2018 15:54:51 GMT):
@tplooker I have mixed feelings about using a message type as a record format.
TelegramSam (Mon, 10 Dec 2018 16:00:01 GMT):
Also, I think the 'microledger transmissions' will be part of the message itself.
TelegramSam (Mon, 10 Dec 2018 16:01:08 GMT):
But awesome work.
tplooker (Mon, 10 Dec 2018 22:40:15 GMT):
@TelegramSam I agree the persisted record doesn't need to conform to a message type (will update accordingly), but we will still need this message type for when an agent requests a routing record or records(s) from another agent wont we?
tplooker (Mon, 10 Dec 2018 22:41:07 GMT):
In general do we think this approach to routing given the potential issues is good enough to proceed with?
tplooker (Mon, 10 Dec 2018 22:46:21 GMT):
Part of me doesnt believe the key squatting concern is a major issue (although there are potential DOS attack vectors). I think routing records should always be updated or exist prior to the update or creation of a dependent DID, because to me updating the DID prior to confirming the message is deliverable would be invalid behavior, regardless of the mechanism used to transmit the DID and or routing record updates?
tplooker (Mon, 10 Dec 2018 22:46:21 GMT):
Part of me doesnt believe the key squatting concern is a major issue (although there are potential DOS attack vectors, but I believe we can mitigate these). I think routing records should always be updated or exist prior to the update or creation of a dependent DID, because to me updating the DID prior to confirming the message is deliverable would be invalid behavior, regardless of the mechanism used to transmit the DID and or routing record updates?
tplooker (Mon, 10 Dec 2018 23:15:44 GMT):
Have we standardized anywhere the format of the services section in a DID for types such as "Agency"? I see an example in HIPE 22 by @swcurran but wondering if this has been formally ratified? This is key to the routing approach I am proposing as a routing agent needs to be able to resolve this section of the DID.
arunwij (Tue, 11 Dec 2018 04:46:58 GMT):
Hello, What is the reason using a *nonce* in *connection offer*, *connection response* and other A2A messages.
arunwij (Tue, 11 Dec 2018 04:46:58 GMT):
Hello, What is the reason using a *nonce* in *connection offer*, *connection response* and other A2A messages?
arunwij (Tue, 11 Dec 2018 04:46:58 GMT):
Hello All, What is the reason using a *nonce* in *connection offer*, *connection response* and other A2A messages?
HiranKumar (Tue, 11 Dec 2018 08:21:13 GMT):
executing init-logger,I got an error like unknown group or command init-logger
HiranKumar (Tue, 11 Dec 2018 14:07:12 GMT):
I have a schema got from parseGetSchemaResponse as shown below
HiranKumar (Tue, 11 Dec 2018 14:07:24 GMT):
["Th7MpTaRZVRYnPiabds81Y:2:userinfo:0.2", {
ver: "1.0",
id: "Th7MpTaRZVRYnPiabds81Y:2:userinfo:0.2",
name: "userinfo",
version: "0.2",
attrNames: ["password", "username", "name"],
seqNo: 11
}]
HiranKumar (Tue, 11 Dec 2018 14:08:30 GMT):
while executing issuerCreateAndStoreCredentialDef,I got the below error
HiranKumar (Tue, 11 Dec 2018 14:08:40 GMT):
issuerCreateAndStoreCredentialDef
HiranKumar (Tue, 11 Dec 2018 14:13:34 GMT):
CommonInvalidStructure
TelegramSam (Tue, 11 Dec 2018 15:36:28 GMT):
@tplooker I've been thinking about routing to keys vs routing to DIDs. Still thinking
TelegramSam (Tue, 11 Dec 2018 15:38:30 GMT):
@tplooker I don't think Key/DID squatting is a problem under two conditions: 1. Practice of registering desired route before publishing it, and 2. requirement to posess a key (or other registration method, such as ledger recording) that relates to the public key / DID being registered. Under those cases (which I believe are easy), we can safely acknowledge the problem and then ignore it.
TelegramSam (Tue, 11 Dec 2018 15:39:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ZR5ErSJcZH6jiWQ3n) @tplooker Yes and No. An Agency DID is just one that contains an endpoint, rather than a DID of an endpoint.
TelegramSam (Tue, 11 Dec 2018 15:40:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=nsTjjj7xMiAS5btNS) @arunwij The nonce provices both the ability to avoid replay attacks, and can give the sender the ability to coorelate a response to a message they sent. @thread mechanisms can also be used for message correlation.
TelegramSam (Tue, 11 Dec 2018 15:47:58 GMT):
@HiranKumar You might find better help in #indy-sdk
TelegramSam (Tue, 11 Dec 2018 17:30:47 GMT):
@tplooker on routing to DID vs key: HIPE 22 Indicates routing via DID: https://github.com/hyperledger/indy-hipe/tree/master/text/0022-cross-domain-messaging
If we continue that direction, we should register routes by DID as well.
kdenhartog (Tue, 11 Dec 2018 20:17:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=nsTjjj7xMiAS5btNS) @arunwij I'm not seeing a nonce used in *connection offer* or *connection response*. In general though we use nonces usually for preventing replay attacks, but also for other standard uses of nonces such as unique ephemeral identifiers.
sam-kaw (Tue, 11 Dec 2018 22:01:02 GMT):
Has joined the channel.
devin-fisher (Tue, 11 Dec 2018 22:14:43 GMT):
@TelegramSam Do you have an impression of how much impact Global Forum will have on the Agent WG call tomorrow? I might want to postpone the topic I proposed last week if we expect a small gathering.
pknowles (Tue, 11 Dec 2018 23:31:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ELmug7YzSm8YGxdfa) @devin-fisher The Semantics WG was down from 7 people to 4 for today's call. That might give you a rough guideline.
kdenhartog (Tue, 11 Dec 2018 23:42:45 GMT):
@devin-fisher my rough estimate is agent call would be missing between 5 to 8 people so about half
devin-fisher (Tue, 11 Dec 2018 23:43:48 GMT):
Hey @kdenhartog, do you know if Sam is at the World Forum?
kdenhartog (Tue, 11 Dec 2018 23:46:55 GMT):
He won't be missing, so my guess is he'll be on the call. The 6 people I know that will be missing are Daniel, Nathan, Stephen C, Paul Knowles, Drummond, and I.
TelegramSam (Wed, 12 Dec 2018 03:45:27 GMT):
I'll be on the call.
TelegramSam (Wed, 12 Dec 2018 03:47:08 GMT):
I vote we go ahead @devin-fisher, unless you have tons of questions that you think the missing folks will be able to help with.
dznz (Wed, 12 Dec 2018 03:50:29 GMT):
Has joined the channel.
danielhardman (Wed, 12 Dec 2018 04:33:06 GMT):
I've opened a new HIPE about a protocol for trust pings: https://github.com/hyperledger/indy-hipe/pull/67
danielhardman (Wed, 12 Dec 2018 05:58:19 GMT):
I've opened another new HIPE about timing information in message: https://github.com/hyperledger/indy-hipe/pull/68
danielhardman (Wed, 12 Dec 2018 09:16:07 GMT):
I've opened another new HIPE to provide a reference example of how to document a message family: https://github.com/hyperledger/indy-hipe/pull/69
drummondreed (Wed, 12 Dec 2018 11:08:17 GMT):
Awesome!
mhailstone (Wed, 12 Dec 2018 13:50:59 GMT):
All,
We have our Indy Agent call at 1:00 - 2:30 PM US/Mountain time.
Agenda
- HIPEs to pay attention to:
-- Message Localization: https://github.com/hyperledger/indy-hipe/blob/801db6c556004ee00f4d7bbd161c8ce62113d0a7/text/localized-messages/README.md
-- Message Timing: https://github.com/hyperledger/indy-hipe/blob/2167762c31dec10777a36d14c5038130b1a06670/text/message-timing/README.md
-- Trust Pings: https://github.com/hyperledger/indy-hipe/blob/5ae9255739eb1ffa261efa5a2dcca290733cfdbd/text/trust-ping/README.md
-- Problem Reports: https://github.com/hyperledger/indy-hipe/blob/6a5e4fe2d7e14953cd8e3aed07d886176332e696/text/error-handling/README.md
- Message Context for received messages - Devin Fisher
- Schema 2.0 Brief - Ken
- Open Discussion
The minutes/agenda Google document and zoom link are:
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#heading=h.oi6go5oamtlh
https://zoom.us/j/856588081
mboyd (Wed, 12 Dec 2018 21:25:42 GMT):
If you are building a mobile edge agent application, please join us on on the Sovrin Foundation at https://chat.sovrin.org/channel/connector-app
HiranKumar (Thu, 13 Dec 2018 11:58:02 GMT):
I got WalletAccessFailed error even if the wallet is already exist. Why?
TelegramSam (Thu, 13 Dec 2018 14:51:30 GMT):
@HiranKumar Are you opening the wallet, or creating a new one?
TelegramSam (Thu, 13 Dec 2018 14:51:40 GMT):
Recordings for yesterday's Agent Call: https://drive.google.com/drive/u/0/folders/1f88v4cLexUtITpeQgY1TG3UMXyhKvfow
HiranKumar (Thu, 13 Dec 2018 15:18:38 GMT):
@TelegramSam,I was trying to create a wallet,then I got a message like WalletAleardy exist.After that it trying to open the wallet,Then I got the message like WalletAccessFailed.
HiranKumar (Thu, 13 Dec 2018 15:56:39 GMT):
parseGetSchemaResponse returns LedgerInvalidTransaction error.
HiranKumar (Thu, 13 Dec 2018 15:56:51 GMT):
schemaResponse is { result:
{ reqId: 1544716454465560000,
seqNo: null,
type: '107',
data: { name: 'Government-ID', version: '1.2' },
identifier: 'DEb6ABy8b9BF8Wk8cP51Lz',
state_proof:
{ root_hash: '7ffB4UCNXS3ELsinJf94h4J8NMYZ8rerb3PWE8xK9SVg',
proof_nodes:
'+QJu+FGAgICAoIuh5pTirPLLH9QP1PUplIYazqtzyW+vRoozdLX0PmfrgICAgICg+u2XmoNkmVoJetvk2DFn5gDz4eMzj7WsX3FX5VI0HuCAgICAgID4xbhZIEViNkFCeThiOUJGOFdrOGNQNTFMejoxOmI2YmY3YmM4ZDk2ZjNlYTlkMTMyYzgzYjNkYThlNzc2MGU0MjAxMzg0ODU2NTczNzJkYjRkNmE5ODFkM2ZkOWW4aPhmuGR7ImxzbiI6MjAsImx1dCI6MTU0NDcxNjQ1NCwidmFsIjoiNDA4MmEzZjA3ZTk3YzFmNzk2YmQ0ZmUyZWMyMjg5NTRjNWY4M2VmZmRiMGFiYjNlZGJlYmI5YTc4MWQwY2E2OSJ9+QFRoNPSP24JsVps7QufK62cHm4MLrVBpYu1VMlThcJrixajgICgmpq6PvRB/76zSDjdvXO+dATJAmHaV82rEVG2ZoAO+TCghZ5GeA0yzqT1m1OyeFHb0bSsFirkiKCAsqQ1pHES1+egt2eBzUrwYs4NQqfGtlHI1gmZE7JKyPq2++bnKDCBRMmgRACCCbNLp/Y1alRAAWwlk5HNK8m01axYGilOiw+nIhmAgICAoCRyJt6FDmJQ60JcPeVA5EXTnNrRiLBPYNq9dgI6SYlCoL15O/l86cbvx789Xkst2SAGYw3yn+zVJUJ7UrfljuVXoH0lXE47VtUlFvwnCC5rgY878m6TpeEZTJIKd4SUxXtqoBvSoTludXD0XkhTPm4YxfCcAdCaiDvkzM8w6O4v5/e1oDs6GXxRL8inD2b3RY1v/ufksDHNqfFKaK2MEIjNIZwagA==',
multi_signature: [Object] },
dest: 'DEb6ABy8b9BF8Wk8cP51Lz',
txnTime: null },
op: 'REPLY' }
HiranKumar (Thu, 13 Dec 2018 16:12:22 GMT):
I got CommonInvalidStructre error while executing issuerCreateAndStoreCredentialDef using the schema = {
ver: "1.0",
id: "Th7MpTaRZVRYnPiabds81Y:2:userinfo4:1.2",
name: "userinfo4",
version: "1.2",
attrNames: ["username", "password", "name"],
seqNo: 24
}
HiranKumar (Thu, 13 Dec 2018 16:12:44 GMT):
Is there anyhting wrong
CHempel (Thu, 13 Dec 2018 16:22:37 GMT):
Has joined the channel.
SanjayJain (Thu, 13 Dec 2018 21:38:11 GMT):
while building the docker image, seeing:
SanjayJain (Thu, 13 Dec 2018 21:38:11 GMT):
while building the python indy-agent docker image, seeing:
SanjayJain (Thu, 13 Dec 2018 21:38:13 GMT):
...
SanjayJain (Thu, 13 Dec 2018 21:38:16 GMT):
Removing intermediate container 13d089da687a
Step 24/27 : ARG PORT
---> Running in d62f69c24d6f
---> ab98600cfdb9
Removing intermediate container d62f69c24d6f
Step 25/27 : ENV PORT ${PORT}
---> Running in 314404c17be4
---> 0be6f91e991d
Removing intermediate container 314404c17be4
Step 26/27 : EXPOSE $PORT
EXPOSE requires at least one argument
SanjayJain (Thu, 13 Dec 2018 23:14:10 GMT):
@TelegramSam it seems just https://github.com/hyperledger/indy-agent/tree/master/python doc needs to be fixed from "$ docker build -t indy-agent ." to "$ docker build --build-arg PORT=
danielhardman (Fri, 14 Dec 2018 07:06:40 GMT):
@mhailstone and @TelegramSam Can I have 20 min or so of the next agent call to demo the reference email agent I have written, and to talk about what I learned in the process of writing it?
arunwij (Fri, 14 Dec 2018 08:20:37 GMT):
Why should we put *master secret id* in *endpoint did* attribute?
`let masterSecretId = await indy.did.getEndpointDidAttribute('master_secret_id');`
arunwij (Fri, 14 Dec 2018 08:20:37 GMT):
Why should we put *master secret id* in *endpoint did* attribute?
`let masterSecretId = await indy.did.getEndpointDidAttribute('master_secret_id');`
I got this line from indy nodejs reference agent.
arunwij (Fri, 14 Dec 2018 08:20:37 GMT):
Why should we put *master_secret _id* in *endpoint did* attribute?
`let masterSecretId = await indy.did.getEndpointDidAttribute('master_secret_id');`
I got this line from indy nodejs reference agent.
arunwij (Fri, 14 Dec 2018 08:20:37 GMT):
Hi, Why should we put *master_secret _id* in *endpoint did* attribute?
`let masterSecretId = await indy.did.getEndpointDidAttribute('master_secret_id');`
I got this line from indy nodejs reference agent.
danielhardman (Fri, 14 Dec 2018 08:29:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=hbFjwcof4CZPug3PR) I just saw that we are going to be discussing a bunch of HIPEs. So maybe my request should be delayed by a week?
TelegramSam (Fri, 14 Dec 2018 14:51:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=7KQcSbRq6gQTS7Jqj) @SanjayJain If you've found corrections that need to be made, the fastest way is to submit a pull request. If unable, we'll try and get that change made.
mhailstone (Fri, 14 Dec 2018 16:48:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=PdnF3HuAnjsLkbX6g) @arunwij This probably isn't the best approach, but it was a convience to store the `master_secret_id` locally in the wallet and make it accessible.
mhailstone (Fri, 14 Dec 2018 16:49:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=hbFjwcof4CZPug3PR) @danielhardman @danielhardman that sounds fantastic! Looking forward to the call next week to see your demo. :)
TelegramSam (Fri, 14 Dec 2018 20:16:25 GMT):
I realized that using ephemeral wallets is very useful during development. I am submitting a PR for such a feature, in a way that is designed to prevent any accidental deleation of a user's non-ephemeral wallets. https://github.com/hyperledger/indy-agent/pull/48
danielhardman (Sat, 15 Dec 2018 09:17:46 GMT):
@TelegramSam How does this relate to the in-memory wallets in @ianco 's PR about wallets?
danielhardman (Sat, 15 Dec 2018 11:14:10 GMT):
I have created a HIPE proposal that explains the theory and conventions associated with A2A decorators. Would love public comment: https://github.com/hyperledger/indy-hipe/pull/71
danielhardman (Sun, 16 Dec 2018 00:19:42 GMT):
I created another HIPE. This one discusses how A2A communication could adapt itself to a synchronous protocol (one capable of simple request/response, like HTTP) without losing its essential nature and guarantees. As always, feedback requested: https://github.com/hyperledger/indy-hipe/pull/72
arunwij (Sun, 16 Dec 2018 05:05:02 GMT):
@mhailstone Thank you!
drummondreed (Sun, 16 Dec 2018 12:26:50 GMT):
@danielhardman I think we should start calling you the Bard of Agents. That HIPE reads wonderfully—it's like a tutorial on the whole subject of how async and sync/REST can work together. If we can get all our HIPEs to that level of readability, game over :-)
swcurran (Sun, 16 Dec 2018 15:11:55 GMT):
Agreed @danielhardman is the Bard :-). I wasn't as enthused about that HIPE, but loved the tic-tac-toe Message Family example. Like them or not, the writing is stellar!
danielhardman (Mon, 17 Dec 2018 00:33:02 GMT):
On the HIPE about A2A and synchronous, I am feeling a bit conflicted, myself. I wanted to document the idea, because several people have asked for a solution. But having put it in black and white, I'm wondering if it's worth pursuing. Right now, I think the HIPE should just linger in limbo unless/until significant interest in the topic materializes. If it doesn't, then that tells us the HIPE shouldn't have legs.
TelegramSam (Mon, 17 Dec 2018 16:45:13 GMT):
The Threading HIPE is nearly complete. @danielhardman is proposing a name change for `seqnum`. Please stop by and leave comments so we can get this HIPE approved: https://github.com/hyperledger/indy-hipe/pull/30
danielhardman (Tue, 18 Dec 2018 02:01:36 GMT):
I created another HIPE. This one is about feature discovery: how does one agent query another to see what message families it supports? Comments appreciated: https://github.com/hyperledger/indy-hipe/pull/73
DuckLover (Tue, 18 Dec 2018 10:57:07 GMT):
Has joined the channel.
dnnn (Tue, 18 Dec 2018 13:02:59 GMT):
Has joined the channel.
TelegramSam (Tue, 18 Dec 2018 22:21:21 GMT):
New PR: https://github.com/hyperledger/indy-agent/pull/51
This is an update created during the Sovrin December Hackathon with @dbluhm and I. It updates the UI, but also adds connection and message persistance, with a simple BasicMessage interface.
TelegramSam (Wed, 19 Dec 2018 19:58:47 GMT):
agent call, now: https://zoom.us/j/856588081
TelegramSam (Wed, 19 Dec 2018 19:58:54 GMT):
meeting notes: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#
kdenhartog (Wed, 19 Dec 2018 20:58:12 GMT):
PR for those wanting to code review the pack/unpack functionalityhttps://github.com/hyperledger/indy-sdk/pull/1210
kdenhartog (Wed, 19 Dec 2018 20:58:12 GMT):
PR for those wanting to code review the pack/unpack functionality https://github.com/hyperledger/indy-sdk/pull/1210
allisongs (Thu, 20 Dec 2018 03:56:04 GMT):
Has joined the channel.
tplooker (Thu, 20 Dec 2018 05:10:53 GMT):
New HIPE for Agent message routing, keen for discussion around some of the points I have raised near the bottom of the HIPE. https://github.com/hyperledger/indy-hipe/blob/1bd710c400cbbbe0d3f739cbefb929162e379ccc/text/agent-message-routing/README.md
axel (Thu, 20 Dec 2018 16:22:11 GMT):
Has joined the channel.
danielhardman (Thu, 20 Dec 2018 22:58:07 GMT):
@tplooker I had a very quick skim, and I'm really excited about the ideas in your PR. Will try to engage more meaningfully late next week.
danielhardman (Thu, 20 Dec 2018 22:59:52 GMT):
I'm going to deliberately withdraw HIPE PR #69 about the tictactoe protocol. I think what we need instead is a "how to write a protocol (message family)" HIPE, with the tictactoe protocol checked in to the HIPE's folder as an example. So I'll be coming up with a replacement PR as soon as I can get to it.
danielhardman (Thu, 20 Dec 2018 22:59:52 GMT):
I'm going to deliberately withdraw HIPE PR #69 about the tictactoe protocol. I think what we need instead is a "how to write a protocol (message family)" HIPE, with the tictactoe protocol checked in to the HIPE's folder as an example. So I'll be coming up with a replacement PR as soon as I can get to it. Until then, I'll leave the PR open so it can be read.
tplooker (Thu, 20 Dec 2018 23:03:07 GMT):
@danielhardman great, any feedback would be awesome its definitely not complete but I thought it was at a point where community input was required.
MayukhGhosh (Fri, 21 Dec 2018 09:58:31 GMT):
Has joined the channel.
TelegramSam (Fri, 21 Dec 2018 16:10:43 GMT):
New Ref Agent PR: Refactor agent message sending and receiving to prepare for the new wire protocol. Breaking changes to the provisional protocol were needed to support the refactor and bring the format closer to the wire format under proposal.
https://github.com/hyperledger/indy-agent/pull/52
sanjeevkkn (Thu, 27 Dec 2018 04:36:58 GMT):
Has joined the channel.
danielhardman (Thu, 27 Dec 2018 08:08:18 GMT):
I have proposed a new HIPE about how one party can request, and another party can send, acknowledgment
messages (ACKs) to confirm receipt and clarify the status of complex processes. I think it has some good ideas in it, but it also raises several deep issues that I would like to discuss on an upcoming agent call: https://github.com/hyperledger/indy-hipe/pull/77
aappddeevv (Thu, 27 Dec 2018 21:28:07 GMT):
Has joined the channel.
anant706 (Fri, 28 Dec 2018 17:23:08 GMT):
Has joined the channel.
danielhardman (Sat, 29 Dec 2018 02:07:08 GMT):
Okay, I have significantly improved the HIPE on discovery of features/protocols supported by an agent. New revision here: https://github.com/hyperledger/indy-hipe/blob/ec6f2ac8355b625a987a68cf7a49ef1d3ea22c96/text/feature-discovery/README.md
danielhardman (Sat, 29 Dec 2018 02:07:22 GMT):
I also rewrote the tictactoe HIPE, turning it into a HIPE about how to define protocols, with the Tic Tac Toe protocol as an example: https://github.com/hyperledger/indy-hipe/blob/933d80125b25d02ce796ce71ad7df7173c55d7bc/text/protocols/README.md
pknowles (Sat, 29 Dec 2018 14:00:20 GMT):
In order to receive *Indy Semantics WG call calendar invites*, please add your contact details to the following distribution list. https://docs.google.com/document/d/1NL36ZIksk4DmquRNvxpyZugWyjqCYa6n20FMzUnf-fY/edit?usp=sharing
pknowles (Sat, 29 Dec 2018 14:00:20 GMT):
In order to receive *Indy Semantics WG calendar invites*, please add your contact details to the following distribution list. https://docs.google.com/document/d/1NL36ZIksk4DmquRNvxpyZugWyjqCYa6n20FMzUnf-fY/edit?usp=sharing
mwherman2000 (Sun, 30 Dec 2018 23:37:47 GMT):
@kdenhartog Any thoughts on how to workaround the following issue? https://github.com/kdenhartog/indy-dev/issues/12
kdenhartog (Wed, 02 Jan 2019 19:54:01 GMT):
@mwherman2000 thanks for pointing this out to me. I hadn't seen this issue on my notifications. I've responded on the issue now.
nage (Wed, 02 Jan 2019 23:13:23 GMT):
As a follow-up from today's call, here is a cross-post to #identity-wg: Getting started on an Identity Wallets project proposal that I hope to propose as soon as Ursa has had a release that Indy can depend on. If you'd like to sponsor the project or help edit the proposal, please let me know.
It is very early in the document's development, but you may take a peek here https://docs.google.com/document/d/1x9O2m-jr282srH1BRcOJQjTROes8T7lnosI2_IPB26E
ashokkj (Thu, 03 Jan 2019 02:08:46 GMT):
Has joined the channel.
danielhardman (Thu, 03 Jan 2019 02:52:57 GMT):
@swcurran : Today on the agent call you mentioned a concern that ACKs cannot be handled generally because they need protocol-specific knowledge to be useful. You mentioned a similar concern about problem-report. I think I know what you are worried about, but I am not certain. I probably am not quite groking it because I am feeling very confident that a generic ACK and a generic problem-report are nearly always the right answer. So I am probably missing something. I am wondering if you could expound a bit.
Here is the part of the concern that I think I understand: In order to emit an ACK at the right place in, say, a credential issuance protocol, I must have knowledge of what's happening in credential issuance. In other words, on the emitting side, I can't use the ACK in a generic way, but only in a specific context. That seems true to me, but not the source of a concern about the usefulness of general ACK. On the receiving side, if I receive an ACK, I can't handle it generically, but rather in the context of whatever interaction is active. In other words, I have to know things about credential issuance (or protocol X or Y) before I can process the generic ACK. Again, I think this is true. But I don't see why this leads to the conclusion: "we might as well have protocol-specific ACKs". If we did that, then I could share no code and no documentation about ACKs between ACKs as they manifest in protocols X, Y, and Z. It would obscure a general pattern.
What am I missing?
danielhardman (Thu, 03 Jan 2019 02:57:22 GMT):
On today's agent call, the topic of attachments came up. @TelegramSam asked if I'd submitted my HIPE proposal on that subject, and I said yes. Then I went back and looked, and I saw that it was still sitting in my fork, not in PR form. So here's that HIPE proposal, as fodder for discussion. An example why this might be relevant is that it would allow us to bridge from the world of A2A messaging to the world of predefined document formats, such as UBL (which is XML-based). Instead of having to convey all info about, say, a purchase order via JSON, we could pass the communication particulars via A2A, but the actual content of the purchase order as an attached UBL doc. And the same could be done for many other formats as well.
danielhardman (Thu, 03 Jan 2019 02:57:22 GMT):
Different topic...
On today's agent call, the topic of attachments came up. @TelegramSam asked if I'd submitted my HIPE proposal on that subject, and I said yes. Then I went back and looked, and I saw that it was still sitting in my fork, not in PR form. So here's that HIPE proposal, as fodder for discussion. An example why this might be relevant is that it would allow us to bridge from the world of A2A messaging to the world of predefined document formats, such as UBL (which is XML-based). Instead of having to convey all info about, say, a purchase order via JSON, we could pass the communication particulars via A2A, but the actual content of the purchase order as an attached UBL doc. And the same could be done for many other formats as well.
danielhardman (Thu, 03 Jan 2019 02:57:22 GMT):
Different topic...
On today's agent call, the topic of attachments came up. @TelegramSam asked if I'd submitted my HIPE proposal on that subject, and I said yes. Then I went back and looked, and I saw that it was still sitting in my fork, not in PR form. So here's that HIPE proposal, as fodder for discussion: https://github.com/hyperledger/indy-hipe/pull/78. An example why this might be relevant is that it would allow us to bridge from the world of A2A messaging to the world of predefined document formats, such as UBL (which is XML-based). Instead of having to convey all info about, say, a purchase order via JSON, we could pass the communication particulars via A2A, but the actual content of the purchase order as an attached UBL doc. And the same could be done for many other formats as well.
xadhoom76 (Thu, 03 Jan 2019 11:18:37 GMT):
Has joined the channel.
TelegramSam (Thu, 03 Jan 2019 17:20:08 GMT):
Call recording from yesterday's agent call: https://drive.google.com/drive/u/0/folders/1n15REPQKDGpUUD4J3A7e-sSmqDnF2KeE
TelegramSam (Thu, 03 Jan 2019 17:20:53 GMT):
(I also finally got the previous call uploaded, sorry about the delay. Link in the pepertual meeting notes doc: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#)
swcurran (Thu, 03 Jan 2019 17:45:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DJhdkFxaFuHoAS9KK) @danielhardman I think the difference is just shades of grey.
As you put it "a generic ACK....are nearly always the right answer". My thought is that a contextually useful ACK - e.g. most beyond "I received your message" - is "nearly always" specific to a message family and hnce is more complex to handle in a generic function. Any ACK that needs to know something of the protocal internals (state) needs to be handled (at least partially) by the protocal.
Another way of putting it is that I tend to think of Message Families as a (more or less) independent services, and that any specific instance of an Agent will have a list of registered Message Families and it will be difficult for a Message Family to find out what other Message Families are loaded in the Wallet and is their internal state. Hence, to know how to get the Message Family-specific information needed for all but the simplest of ACKs will be complex for a generic function. With that mental model, it's easy to see why I'm on the other end of the spectrum at the usefulness of generic ACKs [FYI "Message Family" = "protocol" in that paragraph].
So - I think a generic ACK can be useful, but will not alleviate the need for Message Family specific implementations of ACKs that understand the context of the protocol being executed. Both are needed (as you think), I just think message family specific ones will be more important.
danielhardman (Thu, 03 Jan 2019 19:35:39 GMT):
@swcurran I am really, truly trying to understand. But I am still struggling.
There is no question in my mind that knowing what to do with an ACK inside of, say, a payment protocol, will require payment-specific knowledge. But why does that mean I need a payment-specific ACK message? Why can't the generic ack arrive at an agent, and the agent say, "Ah, this is a message that's part of thread X, which is a payment protocol thread. So route the ack to the payment protocol handler."
Are you assuming that all routing/handling will be done on the basis of message family only?
swcurran (Thu, 03 Jan 2019 21:33:51 GMT):
What I'm saying is since the ACK is going to have to be protocol specific, why not just be explicity about making it part of the protocol? I think that's less complex. Not saying it can't be done as you say, just that it is more complex for what I think is the common case.
danielhardman (Thu, 03 Jan 2019 22:07:54 GMT):
I *am* imagining making the generic ACK part of the payment protocol--so the phrase "be explicit about making it part of the protocol" isn't adding up for me. When you define the payment protocol, you say, "At this point in the protocol, you are required to send an ACK." And rather than defining the message type, fields, and processing logic for payment acks, which is likely to be 99.9% identical to how acks work in every other protocol, we just say "It's our old friend the ack message, which was defined in HIPE X." How would redefining the ACK message in every new protocol that needs it be less work?
danielhardman (Thu, 03 Jan 2019 22:07:54 GMT):
I *am* imagining making the generic ACK part of the payment protocol--so your contrasting suggestion to "be explicit about making it part of the protocol" isn't adding up for me. When you define the payment protocol, you say, "At this point in the protocol, you are required to send an ACK." And rather than defining the message type, fields, and processing logic for payment acks, which is likely to be 99.9% identical to how acks work in every other protocol, we just say "It's our old friend the ack message, which was defined in HIPE X." How would redefining the ACK message in every new protocol that needs it be less work?
danielhardman (Thu, 03 Jan 2019 22:13:01 GMT):
I think maybe I am not understanding what you mean by "protocol specific". The effect that the ACK has on the state of a given protocol will be protocol-specific. But the content of the message, and the meaning of its fields, would be general, would they not?
danielhardman (Thu, 03 Jan 2019 22:21:01 GMT):
@TelegramSam and @swcurran : What would you think about departing from the term "decorator" and using the term "mixin" instead? I have heard Sam use "annotation" many times, and I think that feels very natural as well, because of the "@" that we are putting on the front of field names of this type. But if I get precise about definitions, what we are doing is not really as close to the idea of annotations/decorators as it is to the idea of mixins. A mixin is an alternative to multiple inheritance, where you can give an object properties from some other bundle without inheriting from it. The operative word with a mixin is "include". This is exactly what we are doing with @type, @id, @thread, and so forth. On the other hand, an annotation or decorator is about adding metadata to something. It sort of fits; you could say that what we are adding with @type and @id is metadata. But I am finding that sometimes the fields we add with this mechanism are pretty central to a protocol; they are not guaranteed to be optional and to only be relevant at a different level of analysis from the main data of the message.
And if you go for the "mixin" notion, what do you think about using "+" instead of "@" as the prefix char? My reasoning on this is that "+" communicates mixin-ness nicely, but also that this has the happy consequence of avoiding the collision with JSON-LD @ notation.
danielhardman (Thu, 03 Jan 2019 22:21:01 GMT):
@TelegramSam and @swcurran : What would you think about departing from the term "decorator" and using the term "mixin" instead? I have heard Sam use "annotation" many times, and I think that feels very natural as well, because of the "@" that we are putting on the front of field names of this type. But if I get precise about definitions, what we are doing is not really as close to the idea of annotations/decorators as it is to the idea of mixins. A mixin is an alternative to multiple inheritance, where you can give an object properties from some other bundle without inheriting from it. The operative word with a mixin is "include". This is exactly what we are doing with @type, @id, @thread, and so forth. On the other hand, an annotation or decorator is about adding metadata to something. It sort of fits; you could say that what we are adding with @type and @id is metadata. But I am finding that sometimes the fields we add with this mechanism are pretty central to a protocol; they are not guaranteed to be optional and to only be relevant at a different level of analysis from the main data of the message.
And if you go for the "mixin" notion, what do you think about using "+" instead of "@" as the prefix char? My reasoning on this is that "+" communicates mixin-ness nicely, but also that this has the happy consequence of avoiding the collision with JSON-LD @ notation.This would give you field-level mixin names like "myfield+l10n", and message-level mixin names like "+thread".
danielhardman (Thu, 03 Jan 2019 22:21:01 GMT):
@TelegramSam and @swcurran : What would you think about departing from the term "decorator" and using the term "mixin" instead? I have heard Sam use "annotation" many times, and I think that feels very natural as well, because of the "@" that we are putting on the front of field names of this type. But if I get precise about definitions, what we are doing is not really as close to the idea of annotations/decorators as it is to the idea of mixins. A mixin is an alternative to multiple inheritance, where you can give an object properties from some other bundle without inheriting from it. The operative word with a mixin is "include". This is exactly what we are doing with @type, @id, @thread, and so forth--we are *including* them. On the other hand, an annotation or decorator is about adding metadata to something. It sort of fits; you could say that what we are adding with @type and @id is metadata. But I am finding that sometimes the fields we add with this mechanism are pretty central to a protocol; they are not guaranteed to be optional and to only be relevant at a different level of analysis from the main data of the message.
And if you go for the "mixin" notion, what do you think about using "+" instead of "@" as the prefix char? My reasoning on this is that "+" communicates mixin-ness nicely, but also that this has the happy consequence of avoiding the collision with JSON-LD @ notation.This would give you field-level mixin names like "myfield+l10n", and message-level mixin names like "+thread".
manishcm (Fri, 04 Jan 2019 05:11:15 GMT):
email
pknowles (Fri, 04 Jan 2019 07:46:19 GMT):
@danielhardman My two pence worth ... "that this (i.e. "+") has the happy consequence of avoiding the collision with JSON-LD @ notation" :thumbsup: [Cc: @mtfk ]
mtfk (Fri, 04 Jan 2019 07:46:19 GMT):
Has joined the channel.
TelegramSam (Fri, 04 Jan 2019 13:33:47 GMT):
I think mixin implies that `@attributes` are an extensible pattern, and that (so far) has not been the intent. I still lean to decorator (though my cold-addled brain did say annotation multiple times on the last agent call...)
danielhardman (Fri, 04 Jan 2019 15:07:13 GMT):
@TelegramSam Can you say more about "extensible pattern"? If that had been our extent, what would we observe? Would it be that we expect many people to write custom mixins?
TelegramSam (Fri, 04 Jan 2019 15:11:29 GMT):
@danielhardman Yes. I believe decorators should be reserved for elements widely adopted within the community.
TelegramSam (Fri, 04 Jan 2019 15:12:21 GMT):
Mixins imply that developers should be comfortable developing their own for convenience.
swcurran (Fri, 04 Jan 2019 22:08:02 GMT):
How about we go back to the definitions of these - https://en.wikipedia.org/wiki/Mixin and https://en.wikipedia.org/wiki/Decorator_pattern. It all comes done to patterns :-). A third way of looking at it would be https://en.wikipedia.org/wiki/Aspect-oriented_programming, but I think that is more limited to what we are doing with decorators (as we currently call them).
swcurran (Fri, 04 Jan 2019 22:08:20 GMT):
Based on these descriptions, I think "decorator" is the most accurate and we should keep it.
swcurran (Fri, 04 Jan 2019 22:10:56 GMT):
And to use this to drive home another preference - I'd really like to have decorator specifications to be versioned - e.g. to handle the specification of a decorator to look exactly the same as a message family. That implies a DID-based name space, and (at least) a decorator version and type. The name-space allows for creation of decorators built by others, along with the "core" set of decorators.
swcurran (Fri, 04 Jan 2019 22:12:39 GMT):
Why I think we are talking about decorators (but could be totally wrong):
```
What problems can the Decorator design pattern solve? [4]
Responsibilities should be added to (and removed from) an object dynamically at run-time.
A flexible alternative to subclassing for extending functionality should be provided.
```
swcurran (Fri, 04 Jan 2019 22:16:33 GMT):
BTW - one other thought on this. I think "thread" should not be a decorator, but a core part of the message. That means that it would be defined here - https://github.com/hyperledger/indy-hipe/tree/master/text/0021-message-types as required to be supported in all messages. This implies that `@id` becomes a required field in every message, which I suspect is a very slight de-optimization. There will be very few messages that don't have at least an `@id`, if not a full thread structure.
tplooker (Fri, 04 Jan 2019 22:32:29 GMT):
@swcurran I agree with your last point, at a very minimum there should be a clear requirement for the `@id` decorator in a message as threading and error handling effectively relies on its presence.
TelegramSam (Sat, 05 Jan 2019 14:37:27 GMT):
@swcurran In my mind, decorators are in effect designating core parts of messages.
TelegramSam (Sat, 05 Jan 2019 14:38:26 GMT):
On versioning Decorators: I'd love to, but have been unable to come up with a way of doing so that is worth the added complexity.
TelegramSam (Sat, 05 Jan 2019 14:39:53 GMT):
Also on decorators: I think we bleeding from "Super commonly supported message attributes" (which I believe was the original intent) to "subclassing and extending message types" which I believe is the wrong move.
danielhardman (Mon, 07 Jan 2019 17:38:12 GMT):
@swcurran It is interesting that you would link to the wikipedia articles and then conclude that this is an argument in favor of decorators. I read the wikipedia article on mixins and thought *that* was exactly what we are doing. :-) But after some pondering, I see where your head is at, and I think your perspective is clearer than mine was.
It seems to me that the difference between mixin and decorator boils down to whether we are modifying a class as a whole (all instances), or ad-hoc modifying a single instance of a class. If the former, we're following the mixin pattern. If the latter, we're following the decorator pattern.
We've been doing both. In some HIPEs, we're requiring a certain "decorator" to be present in every instance of the class. But we've also talked about adding decorators to individual instances of a class in ad-hoc fashion. So although we could use "mixin" to describe part of what we're doing, I think we could use "decorator" to describe all of what we're doing. So that's a very long way of explaining why I'm comfortable keeping "decorator" and abandoning my "mixin" suggestion... You convinced me. :-)
danielhardman (Mon, 07 Jan 2019 17:39:27 GMT):
I agree with @TelegramSam that versioning decorators is a can of worms. I'd rather do it the hard way (@thread2 someday, instead of @thread) than try to do it a standard way that introduces a lot of complexity.
danielhardman (Mon, 07 Jan 2019 17:48:19 GMT):
One of the problems we're trying to solve here is adding functionality (fields/structure) to a message type without redefining it over and over again, and without resorting to the metaphor of inheritance (which IMO has some nasty baggage we don't want). That's the mixin use case; it allows us to say that a message type "includes" a chunk of structure without "inheriting" it.
Another problem we're trying to solve is adding functionality to a message *instance*, as when we include some localization info or an ad hock ACK request on a given message. This is the decorator use case.
A third problem we're trying to solve is to add fragments of semantics/metadata to things that are NOT messages. The localization HIPE mentions several possible scopes like this, including a message family, a thread, a connection, etc. It's not clear to me how much we care about this third problem, but I bring it up because it's interesting and it pushes the limits of both the mixin and decorator pattern definitions.
If we wanted to be pure, we could call our mechanism the "X" mechanism, and say that X manifests as mixins when we alter the content of a message type, definitionally--and manifests as decorators when we alter the content of a message instance, ad hoc fashion. And maybe X manifests as other ways in other scopes.
But I'm also content to just call this mechanism decorators, for simplicity.
danielhardman (Mon, 07 Jan 2019 17:49:57 GMT):
BTW, Evernym is planning to use the A2A mechanism for internal communications inside its agency, and is planning to "decorate" messages with some information that the agency will need to manage security and message trust contexts well. I bring this up because @TelegramSam wondered whether this mechanism would be used for non-interoperable, non-general stuff.
mwherman2000 (Mon, 07 Jan 2019 18:02:48 GMT):
RE: adding functionality (fields/structure) to a message type without redefining it over and over again, and without resorting to the metaphor of inheritance @danielhardman, are there some potential synergies here with the Indy schema efforts?
mwherman2000 (Mon, 07 Jan 2019 18:02:48 GMT):
RE: adding functionality (fields/structure) to a message type without redefining it over and over again, and without resorting to the metaphor of inheritance @danielhardman, are there some potential synergies here with the Indy schema efforts? CC: @pknowles
pknowles (Mon, 07 Jan 2019 18:27:05 GMT):
overlays-stack.pdf
danielhardman (Mon, 07 Jan 2019 19:12:02 GMT):
@mwherman2000 Yes, of course. That is why the current protocol HIPE has a paragraph at the end about this very topic: https://github.com/hyperledger/indy-hipe/blob/1ad96c10bda9b18f1b9210d381d36a614fc6931e/text/decorators/README.md#rationale-and-alternatives
danielhardman (Mon, 07 Jan 2019 19:12:02 GMT):
@mwherman2000 Yes, of course. That is why the current decorator HIPE has a paragraph at the end about this very topic: https://github.com/hyperledger/indy-hipe/blob/1ad96c10bda9b18f1b9210d381d36a614fc6931e/text/decorators/README.md#rationale-and-alternatives
pknowles (Mon, 07 Jan 2019 20:40:42 GMT):
@danielhardman I've sent you a deck that might help. If you need any additional input, feel free to contact me directly.
Dubh3124 (Tue, 08 Jan 2019 01:49:40 GMT):
Is there a significant performance cost from constantly opening and closing wallets?
dbluhm (Tue, 08 Jan 2019 05:14:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=yz28BmQ4N5ihn9f7p) @Dubh3124 I can't say for sure what's happening in libindy on either of these operations but repeatedly opening wallets definitely adds onto run times
dbluhm (Tue, 08 Jan 2019 05:14:52 GMT):
@Dubh3124 I can't say for sure what's happening in libindy on either of these operations but repeatedly opening wallets definitely adds onto run times significantly
HiranKumar (Tue, 08 Jan 2019 10:30:56 GMT):
Hi
HiranKumar (Tue, 08 Jan 2019 10:31:40 GMT):
while executing sdk.proverCreateProof,I got a ComonInvalidStructure error,
HiranKumar (Tue, 08 Jan 2019 10:31:53 GMT):
proverCreateProof ( wh, proofReq, requestedCredentials, masterSecretName,
schemas, credentialDefs, revStates ) -> proof
wh
6
proofReq
{ name: 'General-Identity',
version: '0.2',
requested_attributes:
{ attr1_referent: { name: 'name' },
attr2_referent: { name: 'username' },
attr3_referent: { name: 'password' } },
requested_predicates: {},
nonce: '79069089185839494242704518282647' }
requestedCredentials
{ self_attested_attributes: {},
requested_attributes:
{ attr1_referent:
{ cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767',
revealed: true },
attr2_referent:
{ cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767',
revealed: true },
attr3_referent:
{ cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767',
revealed: true } },
requested_predicates: {} }
masterSecretName
df840341-d8b7-4511-bb60-11ab46bc86c9
schemas
[ 'Th7MpTaRZVRYnPiabds81Y:2:userinfo:1.2',
{ ver: '1.0',
id: 'Th7MpTaRZVRYnPiabds81Y:2:userinfo:1.2',
name: 'userinfo',
version: '1.2',
attrNames: [ 'name', 'password', 'username' ],
seqNo: 13 } ]
credentialDefs
[ 'Th7MpTaRZVRYnPiabds81Y:3:CL:13:IDRAMP',
{ ver: '1.0',
id: 'Th7MpTaRZVRYnPiabds81Y:3:CL:13:IDRAMP',
schemaId: '13',
type: 'CL',
tag: 'IDRAMP',
value: { primary: [Object] } } ]
revStates
{}
HiranKumar (Tue, 08 Jan 2019 10:33:19 GMT):
Please help me to solve this issue
sstone1 (Tue, 08 Jan 2019 16:01:32 GMT):
Has left the channel.
kdenhartog (Tue, 08 Jan 2019 18:53:26 GMT):
@HiranKumar I ran into this issue and was stumped for a few days. What ended up solving it for me was publishing the credential def to the ledger. I was creating the cred_def, but I wasn't publishing it which caused me to error out.
firewater (Wed, 09 Jan 2019 07:04:11 GMT):
Has joined the channel.
HiranKumar (Wed, 09 Jan 2019 12:23:33 GMT):
Thanks @kdenhartog.Thanks for your reply
HiranKumar (Wed, 09 Jan 2019 12:23:43 GMT):
issuerCreateCredential expects numer for openBlobStorageReader.I got an error like this while executing issuerCreateCredential .
How can I solve it
ardagumusalan (Wed, 09 Jan 2019 13:33:53 GMT):
Has joined the channel.
tomislav (Wed, 09 Jan 2019 15:58:49 GMT):
@HiranKumar Use the `indy.openBlobStorageReader` https://github.com/hyperledger/indy-sdk/blob/e7e180f59421d0438817aa376dc807c8af4c73c5/wrappers/nodejs/src/index.js#L200
tomislav (Wed, 09 Jan 2019 16:02:54 GMT):
Is there an agent call today?
TelegramSam (Wed, 09 Jan 2019 18:19:03 GMT):
There is an agent call today.
TelegramSam (Wed, 09 Jan 2019 18:19:38 GMT):
I've made significant updates to the connection protocol HIPE, which will be discussed at the agent call. HIPE doc: https://github.com/hyperledger/indy-hipe/blob/f533b11a42c448518a2fd1aa72505c5144eea2f8/text/connection-protocol/README.md
firewater (Wed, 09 Jan 2019 18:54:33 GMT):
how can i get the libindy.so file for ubuntu linux ?
tomislav (Wed, 09 Jan 2019 18:59:43 GMT):
Not sure if it's available as .so file for ubuntu, but certainly there is deb package. Either way, it would be here https://repo.sovrin.org/lib/apt/xenial/rc/
firewater (Wed, 09 Jan 2019 20:16:17 GMT):
i am using https://www.npmjs.com/package/indy-sdk
firewater (Wed, 09 Jan 2019 20:17:06 GMT):
it requires libindy.so for ubuntu, so i suppose there is a way to get it.
twshelton (Wed, 09 Jan 2019 21:22:24 GMT):
@firewater ... try this ... https://github.com/hyperledger/indy-sdk#installing-the-sdk. It should give you the files you need
danielhardman (Wed, 09 Jan 2019 21:35:01 GMT):
@swcurran : Re your assertion that @id and maybe @thread should be required on all messages, I think we might be generalizing too soon. Could it be that the reason we are seeing threading as a universal pattern is that all the messages we have imagined *interaction* oriented? If we did something like multicast or broadcast (e.g., streaming sensor data from an agent that can't listen, only talks), would we still want them? I'm kind of iffy. Maybe. It would allow a receiver to talk about a specific message--just not with the sender. Maybe that case is so marginal that we should generalize anyway?
danielhardman (Wed, 09 Jan 2019 21:35:01 GMT):
@swcurran : Re your assertion that @id and maybe @thread should be required on all messages, I think we might be generalizing too soon. Could it be that the reason we are seeing threading as a universal pattern is that all the messages we have imagined are *interaction* oriented? If we did something like multicast or broadcast (e.g., streaming sensor data from an agent that can't listen, only talks), would we still want them? I'm kind of iffy. Maybe. It would allow a receiver to talk about a specific message--just not with the sender. Maybe that case is so marginal that we should generalize anyway?
swcurran (Wed, 09 Jan 2019 22:28:58 GMT):
@danielhardman I don't think so. Since we've declared A2A to be async, the **vast** majority of messages will be at minimum request/response messages - interactions as you point out. In the (to this point only imagined) case of a uni-directional/no response/no error handling message, I would think an implementation could happily insert a really short number/string for the @id value to meet the letter of the standard, if not the spirit. I vote we generalize away :-).
kdenhartog (Wed, 09 Jan 2019 22:46:56 GMT):
I'd like some clarifications around decorators, and I believe @swcurran has mentioned this before. Do we believe that some decorators are going to be required (e.g. @type and @thread) where as some will be optional (@sig)? If so do we want to treat these in the same way where we generalize them to assume if they're required or optional that they should support all message families?
swcurran (Wed, 09 Jan 2019 22:50:45 GMT):
@kdenhartog - my suggestion is that those that we believe are required, we move out of "decorator" status and into core. @id/@thread is (I think) the only one that fits that category. @danielhardman has already put into the "Decorators" HIPE a list of the "accepted/proposed" decorators and pointers to their specs, and I think that makes sense and should be continued.
TelegramSam (Wed, 09 Jan 2019 22:51:37 GMT):
I think of decorators _as_ core. so 'moving' them doesn't make sense.
TelegramSam (Wed, 09 Jan 2019 22:51:37 GMT):
I think of decorators _as_ core. so 'moving' them doesn't make sense to me.
TelegramSam (Wed, 09 Jan 2019 22:52:11 GMT):
anything that isn't likely to be broadly applicable across message families shoulnd't (in my mind) be a decorator.
swcurran (Wed, 09 Jan 2019 22:54:04 GMT):
I disagree on @id/@thread. Another categorization that might be helpful are decorators that are intended to be cross-cutting and handled by the Agent Message Dispatcher (tracking, timing), and those that are likely to be handled by individual message families (e.g. @sig, @request_ack, @localization).
swcurran (Wed, 09 Jan 2019 22:54:04 GMT):
I disagree on @id/@thread.
Another categorization that might be helpful are decorators that are intended to be cross-cutting and handled by the Agent Message Dispatcher (tracking, timing), and those that are likely to be handled by individual message families (e.g. @sig, @request_ack, @localization).
kdenhartog (Wed, 09 Jan 2019 22:54:18 GMT):
I think there's a distinct difference between something like @sig and something like @type and we should clarify that. In my mind @type is a core decorator, whereas @sig is an optional decorator that is applicable across message families, but isn't required like @type
TelegramSam (Wed, 09 Jan 2019 22:54:48 GMT):
certainly optional / required is a differentiator
swcurran (Wed, 09 Jan 2019 22:54:54 GMT):
We've never (as far as I know) called @type a decorator.
swcurran (Wed, 09 Jan 2019 22:55:02 GMT):
It's in the core message definition.
TelegramSam (Wed, 09 Jan 2019 22:55:19 GMT):
if It has an @, it's an attribute?
TelegramSam (Wed, 09 Jan 2019 22:55:19 GMT):
if It has an @, it's a decorator?
kdenhartog (Wed, 09 Jan 2019 22:55:33 GMT):
yeah that's how I thought of it
kdenhartog (Wed, 09 Jan 2019 22:57:39 GMT):
Either way, I'm noticing there is some dissonance on this subject. Might be a good subject for a call when we get some time.
swcurran (Wed, 09 Jan 2019 22:57:49 GMT):
Ah...well that's a difference. :-). I didn't know that.
swcurran (Wed, 09 Jan 2019 23:10:38 GMT):
I thought that the @ was to indicate there was something special about the field - either core or a decorator, and decorator implied optional.
swcurran (Wed, 09 Jan 2019 23:11:11 GMT):
I think that's a good definition - and hence my push on @id should be required and messages should be rejected if they don't have that.
swcurran (Wed, 09 Jan 2019 23:11:11 GMT):
I think that's a good definition - and hence my push on @id/@thread should be required and messages should be rejected if they don't have that.
TelegramSam (Wed, 09 Jan 2019 23:11:41 GMT):
decorator is I think a bad name for what it implies.
TelegramSam (Wed, 09 Jan 2019 23:12:05 GMT):
the original idea behind the @ was that @ed attributes were reserved.
TelegramSam (Wed, 09 Jan 2019 23:12:35 GMT):
decorator _does_ apply well to the `@110n` stuff, but not to type and id.
TelegramSam (Wed, 09 Jan 2019 23:13:23 GMT):
I'm pretty against @thread being explicitly required. The threading HIPE states what it should implicitly be if absent, and I think that's sufficient.
TelegramSam (Wed, 09 Jan 2019 23:14:27 GMT):
I'm less against @id being required, though I think @danielhardman does have a good point. It's an easy one to abide though.
danielhardman (Wed, 09 Jan 2019 23:15:35 GMT):
I'm also against @thread being required, but I'm pretty comfortable with @id being required. If we announce that, then I think we need to describe decorators differently. This could be done by some changes to the verbiage of the decorator HIPE.
swcurran (Wed, 09 Jan 2019 23:16:38 GMT):
I'm saying that @id OR @thread is required. Completely agree that on the first message, @id is not required. But @thread is needed on everything else. That's what "@id/@thread" was meant to imply.
swcurran (Wed, 09 Jan 2019 23:16:38 GMT):
I'm saying that @id OR @thread is required. Completely agree that on the first message, @thread is not required. But @thread is needed on everything else. That's what "@id/@thread" was meant to imply.
swcurran (Wed, 09 Jan 2019 23:16:38 GMT):
I'm saying that @id OR @thread is required. Completely agree that on the first message, ~@id~ @thread is not required. But @thread is needed on everything else. That's what "@id/@thread" was meant to imply.
danielhardman (Wed, 09 Jan 2019 23:17:25 GMT):
Do you men "on the first message, *@thread* is not required"?
danielhardman (Wed, 09 Jan 2019 23:17:25 GMT):
Do you mean "on the first message, *@thread* is not required"?
swcurran (Wed, 09 Jan 2019 23:17:57 GMT):
:flushed: yes. Fixing it :-)
danielhardman (Wed, 09 Jan 2019 23:20:20 GMT):
How do you feel about this explanation of @:
Fields without @ are problem-domain-specific. That is, if they appear in messages for playing tictactoe, they have a meaning specific to tictactoe. If they appear in messages for credential exchange, they have some semantics tied to credential exchange.
On the other hand, fields with @ are not problem-domain-specific. They address general communication issues. They still might be optional or required--but regardless, they deal with cross-cutting communication-related issues, not the problem domain of the message.
danielhardman (Wed, 09 Jan 2019 23:21:10 GMT):
(BTW, I am more and more feeling like I want to use + as the prefix char, not @. It has to do with some evolving thinking I've had around JSON-LD compatibility. I'm saving that for a separate day, though.)
swcurran (Wed, 09 Jan 2019 23:23:24 GMT):
Something to think about. Doesn't explain "field.@sig" and "field.@l10n" so it's not complete.
TelegramSam (Wed, 09 Jan 2019 23:23:32 GMT):
I think I'd prefer _ as a prefix before +.
TelegramSam (Wed, 09 Jan 2019 23:24:20 GMT):
@danielhardman I do like the 'cross cutting communication issues' vs not.
kdenhartog (Wed, 09 Jan 2019 23:24:50 GMT):
second the distinguishing aspect of "cross cutting communication issues"
mwherman2000 (Wed, 09 Jan 2019 23:28:44 GMT):
Is there an overarching, community-based, vision document that describes how all the Indy pieces are envisioned to work together? ... naturally, with some sort of graphic/visual depiction?
kdenhartog (Wed, 09 Jan 2019 23:29:40 GMT):
I think your doc get's the closest to this @mwherman2000 but no. The only other thing I've seen is my (poor attempt) at explaining it in my slides at HGF.
mwherman2000 (Wed, 09 Jan 2019 23:31:47 GMT):
I've 2 or 3 different ones on the go @kdenhartog ...is there one you prefer? Signed, Starving For Feedback
mwherman2000 (Wed, 09 Jan 2019 23:32:30 GMT):
Most of them are here: http://hyperonomy.com
mwherman2000 (Wed, 09 Jan 2019 23:32:30 GMT):
Most of them are here: http://hyperonomy.com Checkout the right most column of titles.
kdenhartog (Wed, 09 Jan 2019 23:35:08 GMT):
I've only seen the one you posted to the CCG and were working on at the HGF. In general, it's a great overview that highlights in great depth the composite overview of Indy.
kdenhartog (Wed, 09 Jan 2019 23:37:43 GMT):
https://hyperonomy.com/2018/12/21/decentralized-identifiers-dids-architecture-reference-model-arm/
kdenhartog (Wed, 09 Jan 2019 23:37:50 GMT):
This one here is the one I've seen
mwherman2000 (Wed, 09 Jan 2019 23:40:21 GMT):
👍
kdenhartog (Wed, 09 Jan 2019 23:45:07 GMT):
As I review it though, I still differ on whether a thing requires a DID. While it does fit the spec to apply DIDs to things, I differ on it's application because I believe there's other specifications that better tailor to identifying objects which are incapable of making decisions AND never will. This distinction leads me to believe that because the cryptographic property is unused, that the usecase would better fit a UUID. To better understand your reasoning though, what unique characteristics of a DID exist over UUIDs that make them better suited to represent inanimate objects which will never autonomously perform an action?
danielhardman (Wed, 09 Jan 2019 23:49:09 GMT):
@kdenhartog Be careful about the use of the word "thing". Michael is advocating a definition that's quite different from the one in the Sovrin glossary. In Michael's parlance, "thing" is by definition inert. In Sovrin's parlance, "thing" can include IoT things. Michael would call those "actors", not "things". Michael's parlance comes from Archimate. (Correct me if I'm wrong here, @mwherman2000 ).
I'm not advocating anything particular here, either about definitions or about how we analyze the problem. I'm just pointing out the subtlety so everybody knows to parse words carefully.
kdenhartog (Wed, 09 Jan 2019 23:51:55 GMT):
I believe I'm thinking of Thing correctly then. Something like an asteroid would fall under a Thing in his definition, whereas something like an IoT device (which needs a decision tree to perform a set of actions) which has an actor representing it, would remain an actor with another actor haviing guardianship over the IoT device.
danielhardman (Wed, 09 Jan 2019 23:52:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wrZW8FH7NRf7kfJbW) @swcurran Actually, I think it sort of does. Signing a particular piece of content is not a domain-specific mechanism; it's a generally useful mechanism that applies to all sorts of scopes in all sorts of messages. Hence, field.@sig. Communicating locale info is a little harder to argue, but you could explain it like this: The phenomenon of localization crops up over and over in all kinds of messages, at all kinds of level of detail. It may have some relationship to specific domain-specific fields, but as a phenomenon, it's not domain-specific.
danielhardman (Wed, 09 Jan 2019 23:54:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=5kRKr2vPQtg2n7p6Y) @TelegramSam We can't use _ because we're using snake_case for normal field names; that would give us myfield_l10n which is ambiguous; is it a decorated field or not? Wouldn't you rather have myfield+l10n?
danielhardman (Wed, 09 Jan 2019 23:54:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=5kRKr2vPQtg2n7p6Y) @TelegramSam We can't use underscore because we're using snake_case for normal field names; that would give us myfield_l10n which is ambiguous; is it a decorated field or not? Wouldn't you rather have myfield+l10n?
TelegramSam (Wed, 09 Jan 2019 23:55:15 GMT):
myfield+I10n is good. I feel wierd about +thread
danielhardman (Wed, 09 Jan 2019 23:55:54 GMT):
hmm
danielhardman (Wed, 09 Jan 2019 23:57:23 GMT):
I might like it more because it confirms my other prejudice, that this is really a mixin rather than a decorator. :-) I'm content to let it simmer--and in the overall scheme of things, if we use a char other than my favorite one, I won't argue much. I do think the overlap with @context in JSON-LD is unfortunate. Still pondering...
mwherman2000 (Wed, 09 Jan 2019 23:58:34 GMT):
From https://www.evernym.com/wp-content/uploads/2017/07/SovrinProvisionalTrustFramework2017-03-22.pdf ....
mwherman2000 (Wed, 09 Jan 2019 23:59:00 GMT):
```
Thing. A Sovrin Entity that cannot be held legally accountable. A Thing may be either an animal
(e.g., pet, livestock), a natural object (e.g., house, car, phone), or digital object (e.g., software
program, network service, data structure). Mutually exclusive with Identity Owner.
```
mwherman2000 (Wed, 09 Jan 2019 23:59:25 GMT):
I'm not changing "a Thing" here :-)
mwherman2000 (Wed, 09 Jan 2019 23:59:25 GMT):
I'm not changing "a Thing" here :-) @danielhardman
mwherman2000 (Thu, 10 Jan 2019 00:00:33 GMT):
I believe the additional term (from our Basel Friday Workshop) is the recognition of `Actors` and how Actors and Things are different.
kdenhartog (Thu, 10 Jan 2019 00:01:06 GMT):
@danielhardman @TelegramSam I think the biggest difficulty around which ever we select is going to be finding suitable JSON parsers as well as knowing what languages support for variable declaration. For example in rust, the JSON parser does support translations from `thread` to `+thread` built into the seralizer, but I couldn't declare a variable in a struct +thread.
danielhardman (Thu, 10 Jan 2019 00:01:45 GMT):
Right. But you couldn't decleare a variable in a struct @thread either, could you?
danielhardman (Thu, 10 Jan 2019 00:01:45 GMT):
Right. But you couldn't declare a variable in a struct @thread either, could you?
mwherman2000 (Thu, 10 Jan 2019 00:03:08 GMT):
Visually, I describe the relationship between Actors and Things here (as part of an overarching "DID Data Model"): https://hyperonomy.com/2019/01/04/the-path-from-a-id-did-to-a-real-life-something/
kdenhartog (Thu, 10 Jan 2019 00:03:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wcMEijkQzBxPG2FAg) @mwherman2000 I don't feel like this definition suffices for the nuance I was trying to extract. While being legally accountable vs not is important, in my opinion whether or not a `thing` has a supporting decision tree and can process logic is the nuance that I find important. For example, a digital object can support processing logic, but a natural object could not.
danielhardman (Thu, 10 Jan 2019 00:04:03 GMT):
@mwherman2000 : Using the definition of thing that you quoted, a "thing" in Sovrin can include items that take action on their own. Am I incorrect that your "thing" disallows that?
danielhardman (Thu, 10 Jan 2019 00:04:15 GMT):
What I am suggesting is that your "thing" is a subset of Sovrin's "thing"
mwherman2000 (Thu, 10 Jan 2019 00:04:57 GMT):
The Sovrin defintion isn't perfect. I class Actors as: People, Organizations, and Software Agents.
kdenhartog (Thu, 10 Jan 2019 00:05:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=J4zjZP3d9RgDdfJqu) @danielhardman Correct. With regards to rust, we do the same trick with the `@` symbol as we would with `+` I haven't investigated if this holds true for other languages. In particular, I'd want to dig deeper into how other JSON serializers handle this. Particularly Python and JS because the JSON parsers are integrated as standard packages.
danielhardman (Thu, 10 Jan 2019 00:06:03 GMT):
@mwherman2000 I am not asserting that Sovrin's definition is perfect. I am asserting that it is different from yours. Please tell me whether this is true, yes or no, in your opinion.
mwherman2000 (Thu, 10 Jan 2019 00:07:17 GMT):
More generally, `an Actor is something (a business entity) that is capable of performing behavior`.
danielhardman (Thu, 10 Jan 2019 00:07:42 GMT):
yes...
mwherman2000 (Thu, 10 Jan 2019 00:07:45 GMT):
Reference: http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc489946042
kdenhartog (Thu, 10 Jan 2019 00:08:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tzQtrJdhGwMcFAyPY) Would a `thing` be something incapable of performing behavior then? (This is what I was trying to allude to with the ability to process logic even if it's preprogrammed)
kdenhartog (Thu, 10 Jan 2019 00:08:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tzQtrJdhGwMcFAyPY) Would a `thing` be something incapable of performing behavior then? (This is what I was trying to allude to by choosing the phrase process logic)
mwherman2000 (Thu, 10 Jan 2019 00:09:19 GMT):
No ...that's the differentiator ...at least at my current level of thinking.
kdenhartog (Thu, 10 Jan 2019 00:10:32 GMT):
Do you have a definition of an entity incapable of performing behavior?
mwherman2000 (Thu, 10 Jan 2019 00:10:38 GMT):
You can have programs, logic, AI, ML, etc. at lower levels (e.g. technology/infrastructure layer) but let's agree that these are Things and not Actors ...in and of themselves/
kdenhartog (Thu, 10 Jan 2019 00:11:04 GMT):
Sorry term, not definition
mwherman2000 (Thu, 10 Jan 2019 00:11:39 GMT):
A business entity capable of performing a bahavior is an Actor: Person, Org, Software Agent (at the business level)
danielhardman (Thu, 10 Jan 2019 00:11:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=BRzipQnsvQZhpxuZT) @mwherman2000 So, Michael, if I understand you correctly, your preferred way to view the world is that Things and Actors are mutually exclusive.
mwherman2000 (Thu, 10 Jan 2019 00:12:06 GMT):
Yes ...M.E.
danielhardman (Thu, 10 Jan 2019 00:12:23 GMT):
A "Thing" in Sovrin's official glossary is not mutually exclusive with your term "Actor". This is the disconnect I was warning about.
mwherman2000 (Thu, 10 Jan 2019 00:12:44 GMT):
The other trait I've included (in addition) is that Things have Owners. ...and Owners are Actors.
mwherman2000 (Thu, 10 Jan 2019 00:12:54 GMT):
Got it
kdenhartog (Thu, 10 Jan 2019 00:13:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=H88igD5rEF436nLmA) @mwherman2000 This part I agree with and it makes sense.
danielhardman (Thu, 10 Jan 2019 00:16:36 GMT):
Sovrin:
dog = thing
car = thing
AI = thing (acts, but can't be held legally responsible)
Alice = identity owner
Archimate:
dog = thing
car = thing
AI = Actor
Alice = Actor that is also owner
kdenhartog (Thu, 10 Jan 2019 00:16:36 GMT):
Ok I believe I understand the difference between a Thing and an Actor. Let me try repeating to make sure I understand your terminology. An actor is an entity which is capable of performing a behavior while a thing is an entity which is incapable of performing a behavior on it's own behalf. Rather an Actor which possesses some form of property rights over a thing must perform a behavior on behalf of said thing.
mwherman2000 (Thu, 10 Jan 2019 00:18:01 GMT):
AI is not an Actor according ArchiMate ...that a misquote from somewhere.
danielhardman (Thu, 10 Jan 2019 00:18:24 GMT):
how can it not be an actor when "it is a business entity capable of performing a behavior"?
kdenhartog (Thu, 10 Jan 2019 00:18:47 GMT):
yeah that threw a wrench in my understanding as well.
mwherman2000 (Thu, 10 Jan 2019 00:19:34 GMT):
I've been using the term Somethings as generic term for an Actor or a Thing.
mwherman2000 (Thu, 10 Jan 2019 00:19:51 GMT):
AI is not a business entity.
danielhardman (Thu, 10 Jan 2019 00:20:07 GMT):
Ah. And what is "business entity", then?
mwherman2000 (Thu, 10 Jan 2019 00:20:08 GMT):
AI is a technology that is capable of supporting a Software Agent.
kdenhartog (Thu, 10 Jan 2019 00:20:23 GMT):
So would a DAO possess no business entities in Archimate?
danielhardman (Thu, 10 Jan 2019 00:21:36 GMT):
In Sovrin, a software agent = a thing. In Archimate, a software agent = an actor?
mwherman2000 (Thu, 10 Jan 2019 00:22:50 GMT):
I'm trying to be to `ArchiMate-y` in these definitions ;-)
mwherman2000 (Thu, 10 Jan 2019 00:23:16 GMT):
If you are talking about the software that comprises a Software Agent, the software is a Thing.
mwherman2000 (Thu, 10 Jan 2019 00:23:16 GMT):
If you are talking about the software that comprises a Software Agent, the software or program is a Thing.
mwherman2000 (Thu, 10 Jan 2019 00:24:01 GMT):
If you're talking about the Software Agent as a business entity capable of performing behavior, then it's an Actor.
mwherman2000 (Thu, 10 Jan 2019 00:24:31 GMT):
Here is the best (most relevant) quote from ArchiMate spec:
mwherman2000 (Thu, 10 Jan 2019 00:24:38 GMT):
```
1. The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.
2. The Application Layer depicts application services that support the business, and the applications that realize them.
3. The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services. Physical elements are added for modeling physical equipment, materials, and distribution networks to this layer.
```
kdenhartog (Thu, 10 Jan 2019 00:25:50 GMT):
Ok I think I'm understanding the nuance. A function in a piece of code is a thing, where as a production instance of a piece of software which consumes that function and performs business logic is an Actor. Is this correct?
kdenhartog (Thu, 10 Jan 2019 00:25:50 GMT):
Ok I think I'm understanding the nuance. A function in a piece of code is a thing, where as a production instance of a piece of software which consumes that function and performs business logic is an Actor on behalf of the business. Is this correct?
mwherman2000 (Thu, 10 Jan 2019 00:26:12 GMT):
That's getting quite close I think
kdenhartog (Thu, 10 Jan 2019 00:27:00 GMT):
so in the instance of a DAO, the smart contract is a thing, but when the smart contract is deployed and being actually used to run a DAO it's now an Actor.
mwherman2000 (Thu, 10 Jan 2019 00:27:30 GMT):
Without drilling down too much, yes ...that the nuance.
mwherman2000 (Thu, 10 Jan 2019 00:27:30 GMT):
Without drilling down too much, yes ...that's the nuance.
kdenhartog (Thu, 10 Jan 2019 00:28:40 GMT):
gotcha, this helps me to understand. I get it now. so it's not only whether it's capable of performing behavior, but also if it is actually doing so on behalf of an organization which makes it an actor.
mwherman2000 (Thu, 10 Jan 2019 00:29:53 GMT):
Not strictly an organization ...because a Person can be an Actor without having an Organizational affiliation, for example.
kdenhartog (Thu, 10 Jan 2019 00:31:36 GMT):
I was thinking that might be a gotcha, thanks for clarifying.
mwherman2000 (Thu, 10 Jan 2019 00:47:02 GMT):
I needed to scroll back to find the spark that set off this discussion :-) ... here it is `This distinction leads me to believe that because the cryptographic property is unused, that the usecase would better fit a UUID. To better understand your reasoning though, what unique characteristics of a DID exist over UUIDs that make them better suited to represent inanimate objects which will never autonomously perform an action?`
mwherman2000 (Thu, 10 Jan 2019 00:51:02 GMT):
Again, my raison d'etre for wanting to use DID Entities to represent Things is that what I really want to represent is Non-Fungible Entities (aka Somethings aka Actors and Things) ...and I want some sort of signed, trusted, irrefutable, etc. representation/framework/specification for NFEs/Somethings/Actors/Things ...this is why #iDIDit in the first place. :-)
mwherman2000 (Thu, 10 Jan 2019 00:54:21 GMT):
As suggested by a number of folks (aka People), I dove head-first into the draft DID specification ...found a few dozen issues ...ok, actually 3 dozen issues. Now I'm working to roll those to find a small number of root cause issues that are easier to discuss and solve (vs. the 36 very detailed issues). That's why and where I'm at.
mwherman2000 (Thu, 10 Jan 2019 00:54:21 GMT):
As suggested by a number of folks (aka People), I dove head-first into the draft DID specification ...found a few dozen issues ...ok, actually 3 dozen issues. Now I'm working to roll those *up* to find a small(er) number of root cause issues that are easier to discuss and solve (vs. the 36 very detailed issues). That's why and where I'm at.
mwherman2000 (Thu, 10 Jan 2019 00:54:59 GMT):
My primary NFE use case is Business Documents.
pknowles (Thu, 10 Jan 2019 02:55:36 GMT):
I just had my custom 3 and a half hour snooze. You chaps have been busy! So ... @mwherman2000 @kdenhartog @danielhardman - It would appear that you're getting close to nailing the nuances between Actors, Things, etc. Well done to Michael for putting the magnifying glass on these definitions.
pknowles (Thu, 10 Jan 2019 02:55:36 GMT):
I just had my customary 3 and a half hour snooze. You chaps have been busy! So ... @mwherman2000 @kdenhartog @danielhardman - It would appear that you're getting close to nailing the nuances between Actors, Things, etc. Well done to Michael for putting the magnifying glass on these definitions.
pknowles (Thu, 10 Jan 2019 02:55:36 GMT):
I just had my customary 3 and a half hour snooze. You chaps have been busy! So ... @mwherman2000 @kdenhartog @danielhardman - It would appear that you're getting close to nailing the nuances between Actors, Things, etc. Well done to Michael for putting the magnifying glass on those definitions.
pknowles (Thu, 10 Jan 2019 03:00:38 GMT):
Moving onto "Decorators", @danielhardman @TelegramSam @swcurran , I have some input that I'd like to throw into the mix. As you can imagine, after a year of constructing the Overlays architecture, I now see all data objects in 3-D!
pknowles (Thu, 10 Jan 2019 03:00:38 GMT):
Moving onto "Decorators", @danielhardman @TelegramSam @swcurran , I have some input that I'd like to throw into the mix. As you can imagine, after a year of constructing the Overlays architecture, I now see all data objects in 3d!
pknowles (Thu, 10 Jan 2019 03:00:38 GMT):
Moving onto "Overlays / Decorators" ... @danielhardman @TelegramSam @swcurran - I have some input that I'd like to throw into the mix. As you can imagine, after a year of living and breathing Overlays, I now see all data packages in 3d!
pknowles (Thu, 10 Jan 2019 03:00:38 GMT):
Moving onto "Overlays / Decorators" ... @danielhardman @TelegramSam @swcurran - I have some input that I'd like to throw into the mix. As you can imagine, after a year of living and breathing Overlays, I now see all data constructs in 3d!
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
First up, what you perceive to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those objects. Anything that is _fairly_ common across message types can be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a 'keep' statement rather than a "Drop" statement. Using the Overlays architecture, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
First up, what you perceive to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those objects. Anything that is _fairly_ common across message types can be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts like a traditional _Keep_ statement would rather than a _Drop_ statement. In other words, if you specify the component, it stays. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything else) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What you perceive to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those objects. Anything that is _fairly_ common across message types can be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts like a traditional _Keep_ statement would rather than a _Drop_ statement. In other words, if you specify the component, it stays. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything else) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those objects. Anything that is _fairly_ common across message types can be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts like a traditional _Keep_ statement would rather than a _Drop_ statement. In other words, if you specify the component, it stays. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything else) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts like a traditional _Keep_ statement would rather than a _Drop_ statement. In other words, if you specify the component, it stays. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything else) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts like a traditional _Keep_ statement would rather than a _Drop_ statement. In other words, if you specify the component, it stays. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything else) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a traditional _Keep_ statement would. In other words, if the component is specified in the subset overlay, it remains. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally anything at all) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a traditional _Keep_ statement would. In other words, if the component is specified in the subset overlay, it remains. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally anything at all) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
So ... What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a traditional _Keep_ statement would. In other words, if the component is specified in the subset overlay, it remains. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally anything at all) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
So ... What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a traditional _Keep_ statement would. In other words, if the component is specified in the subset overlay, it remains. With my Overlays architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything at all) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 03:42:26 GMT):
So ... What is perceived to be a stable message type can become a "Message Base". `@id` might be burnt into the metadata block of those base objects. Anything that is _fairly_ common across message types can actually be stored in the main body of the Message Base rather than residing in the metadata block. A subset overlay can be used to restrict certain components in the main body of the Message Base. For example, if `@thread` is not required 100% of the time, you could use a subset overlay to omit that component. A subset overlay basically acts as a traditional _Keep_ statement would. In other words, if the component is specified in the subset overlay, it remains. With my "Overlays" architecture hat on, your Message Bases should remain stable per message type. Any nuances, coloration, tweaks, etc. (literally, anything at all) can be resolved using Overlays.
pknowles (Thu, 10 Jan 2019 04:12:48 GMT):
@danielhardman If you send me an example of an outputted message type, perhaps we can determine how the "Message Base" and "Overlay stack" should be constructed to get us to that endpoint.
pknowles (Thu, 10 Jan 2019 04:12:48 GMT):
@danielhardman If you send me an example of an outputted message type, perhaps we can determine how the "Message Base" and "Overlay stack" should be constructed to get us to that final endpoint.
pknowles (Thu, 10 Jan 2019 04:12:48 GMT):
@danielhardman If you send me an example of an outputted message type, perhaps we can determine what the "Message Base" and "Overlay stack" might look like to get us to that final endpoint.
pknowles (Thu, 10 Jan 2019 04:12:48 GMT):
@danielhardman If you send me an example of an outputted message type, perhaps we can determine what the "Message Base" and "Overlay stack" might look like to get us to that final endpoint. That'll help me to better understand what the different components are within the message construct.
pknowles (Thu, 10 Jan 2019 04:12:48 GMT):
@danielhardman If you send me an example of an outputted message type, perhaps we can determine what the "Message Base" and "Overlay stack" might look like to get us to that final endpoint. That exercise will help me better understand what the different components are within the message construct.
danielhardman (Thu, 10 Jan 2019 04:27:15 GMT):
@pknowles Here is an example of a simple request/response message pair with all properties present. Some, you will notice, have names beginning with "@". These are what we call "decorators". Others are simple fields that have a meaning specific to the problem domain of feature discovery (what this HIPE is about). https://github.com/hyperledger/indy-hipe/blob/127a3a8e372b99d94ccbefc9d44f82ef3c75ef50/text/feature-discovery/README.md#messages
danielhardman (Thu, 10 Jan 2019 04:29:37 GMT):
Here is another example. This one is from the HIPE that describes how we imagine conveying localization information for messages: https://github.com/hyperledger/indy-hipe/blob/318f265d508a3ddf1da7d91c79ae4ae27ab9142b/text/localized-messages/README.md#decorator-at-message-scope
pknowles (Thu, 10 Jan 2019 04:31:57 GMT):
@danielhardman Fantastic. I'll get back to you as soon as I've got some solid suggestions.
HiranKumar (Thu, 10 Jan 2019 05:48:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=4dFHDBzPEmf5L4eya) @tomislav Thanks @tomislav
firewater (Thu, 10 Jan 2019 06:11:27 GMT):
I am trying to connect to indy-node with nodejs from my agent via node indy sdk wrapper but i got common invalid state error. What could be the issue?
firewater (Thu, 10 Jan 2019 06:11:52 GMT):
exports.setup = async function () {
// see PlenumProtocolVersion or indy-plenum.common.constans.CURRENT_PROTOCOL_VERSION
await sdk.setProtocolVersion(2);
let poolGenesisTxnPath = await exports.getPoolGenesisTxnPath(config.poolName);
let poolConfig = {
"genesis_txn": poolGenesisTxnPath
};
try {
await sdk.createPoolLedgerConfig(config.poolName, poolConfig);
} catch (e) {
if (e.message !== "PoolLedgerConfigAlreadyExistsError") {
throw e;
}
} finally {
pool = await sdk.openPoolLedger(config.poolName);
console.log('sad');
}
};
firewater (Thu, 10 Jan 2019 06:14:40 GMT):
https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/pool/index.js
firewater (Thu, 10 Jan 2019 06:14:40 GMT):
https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/pool/index.js#L17-L34
firewater (Thu, 10 Jan 2019 06:14:55 GMT):
line 17 to 34, I am connecting to http://159.89.115.24
firewater (Thu, 10 Jan 2019 06:19:58 GMT):
I am using the nodejs wrapper in indy-agent to connect to pool but i got common invalid state error. What could be the issue?
I am connecting to http://159.89.115.24 and the following code is as follow
https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/pool/index.js#L17-L34
mwherman2000 (Thu, 10 Jan 2019 14:23:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9STcMuSiYde8u4pLW) @kdenhartog To complete this discussion (negative cases): A piece/slice of Toast would not be considered a Thing (in this context) because it is Fungible (not a Non-Fungible Entity) - maybe a piece of Toast can be a Thing in the future when each slice of bread has bar code or serial number. An photo of a piece of Toast is a Thing - a photo of a piece of Toast is a Non-Fungible Entity.
A cell in the body (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ...again, at least not for the foreseeable future.
mwherman2000 (Thu, 10 Jan 2019 14:23:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9STcMuSiYde8u4pLW) @kdenhartog To complete this discussion (negative cases): A piece/slice of Toast would not be considered a Thing (in this context) because it is Fungible (not a Non-Fungible Entity) - maybe a piece of Toast can be a Thing in the future when each slice of bread has bar code or serial number. An photo of a piece of Toast is a Thing - a photo of a piece of Toast is a Non-Fungible Entity.
A cell in the body (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ...again, at least not for the foreseeable future.
mwherman2000 (Thu, 10 Jan 2019 14:23:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9STcMuSiYde8u4pLW) @kdenhartog To complete this discussion (negative cases): A piece/slice of (a particular type of) Toast would not be considered a Thing (in this context) because it is Fungible (not a Non-Fungible Entity) - maybe a piece of Toast can be a Thing in the future when each slice of bread has bar code or serial number. An photo of a piece of Toast is a Thing - a photo of a piece of Toast is a Non-Fungible Entity.
A cell in the body (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ...again, at least not for the foreseeable future.
firewater (Thu, 10 Jan 2019 16:51:21 GMT):
let say that i have gotten an identity from a third party issuer (eg: government agent). How can i implement identity update (eg: i move to new places and would like to change my address)?
firewater (Thu, 10 Jan 2019 16:51:49 GMT):
would be glad if someone can tell on which function in cli/sdk should be call in sequence
TelegramSam (Thu, 10 Jan 2019 17:01:13 GMT):
Agent Call Recordings from yesterday: https://drive.google.com/drive/u/0/folders/16zZwxetJacbuFlpEl5bBVazAosNCrZz_
TelegramSam (Thu, 10 Jan 2019 17:01:51 GMT):
@firewater are you wanting to update the address in an issued claim, or how to send that claim to other parties?
firewater (Thu, 10 Jan 2019 17:12:22 GMT):
@TelegramSam update the address in an issued claimed
TelegramSam (Thu, 10 Jan 2019 17:13:10 GMT):
you'll need to request a new claim from the issuer.
firewater (Thu, 10 Jan 2019 17:14:19 GMT):
that will be repeating the same process of requesting a claim?
TelegramSam (Thu, 10 Jan 2019 17:14:25 GMT):
yes.
firewater (Thu, 10 Jan 2019 17:16:06 GMT):
i see
firewater (Thu, 10 Jan 2019 17:16:46 GMT):
also i see all the demo available, all the issuance and approval is needed to do it manually in the user interface.
firewater (Thu, 10 Jan 2019 17:17:40 GMT):
eg: A submit claim to B -> B verify and issue to A -> A click verify
firewater (Thu, 10 Jan 2019 17:18:14 GMT):
is that feasible for it to be fully automated?
firewater (Thu, 10 Jan 2019 17:19:14 GMT):
meaning that B as an issuer agent automated the whole process without human intervention
firewater (Thu, 10 Jan 2019 17:20:57 GMT):
so what i want to achieve at the end is A submit claim to B (this is the only part that need human), others all automated.
firewater (Thu, 10 Jan 2019 17:20:57 GMT):
so what i want to achieve at the end is A submit claim to B (this is the only part that need human interaction), others all automated.
firewater (Thu, 10 Jan 2019 17:21:40 GMT):
would it be against self soverign identity principle?
TelegramSam (Thu, 10 Jan 2019 17:39:52 GMT):
not necessarily. As long as it is being automated at the request of the user, the principles still apply.
MattRaffel (Thu, 10 Jan 2019 18:29:29 GMT):
Has joined the channel.
xnopre (Fri, 11 Jan 2019 15:17:25 GMT):
Hi all. I have worked many weeks with `indy-sdk`, I have developped a POC to enforse DID creation, credentials generation, proof sharing, ... I have a little contributing on `indy-sdk` (samples and how-tos script for NodeJs). Now I take a look at `https://github.com/hyperledger/indy-agent`. I'm a little surprised. I was expecting to find some new concepts and new tools, in higher level than SDK, but it seems to be just like a demonstration, showing the use of SDK, adding HTTP communication between actors to exchange some data, .... but not really a library or tools that I can use for my application (in my mind, in place of low level operations with SDK). Could you confirm ? Or is there somewhere else some ready to use tools for the agent function ? Thanks
firewater (Fri, 11 Jan 2019 19:16:58 GMT):
what is the diff between and schema and creddef?
tplooker (Fri, 11 Jan 2019 20:39:09 GMT):
@xnopre You are correct, indy-sdk is more of a lower level SDK that exposes the low level tools required to build agents, the next abstraction up is VCX https://github.com/hyperledger/indy-sdk/tree/master/vcx that may be what you are looking for? Essentially VCX is a higher level SDK that comes with a credential exchange protocol among other features built in. There are other efforts ongoing showcasing agents such as https://github.com/hyperledger/indy-agent which is reference indy agent and https://github.com/streetcred-id/agent-framework which is a C# version of libVCX that works in a slightly different way.
esplinr (Fri, 11 Jan 2019 21:52:44 GMT):
Welcome @xnopre!
esplinr (Fri, 11 Jan 2019 22:22:26 GMT):
Now that the SDK has most of the key functionality, the agent work is becoming an area of focus. Vendors like Evernym (my employer) and organizations like the Sovrin Found, BYU, and BC.gov have implementations of agents. Our joint focus has been in agreeing to the standards for communication (visible in the indy-hipe repo), and starting a compatibility test suite. @TelegramSam has been leading an effort to build a Python reference agent.
esplinr (Fri, 11 Jan 2019 22:22:59 GMT):
We look forward to collaborating with you.
danielhardman (Sat, 12 Jan 2019 00:41:29 GMT):
I wanted to raise a topic that I've heard @swcurran and @tplooker alude to, and make a comment about it. It is the idea that the wire level messages may be able to short-circuit the need for a forward message type, either always or sometimes, and also eliminate the need for DIDs at that routing level, because the packaging done by @kdenhartog in pack/unpack can reveal the key of the destination. Thus, we could route by keys, not by DIDs, and we don't have to do wrapping and unwrapping; each intermediary can simply inspect the packaging and say, "Nope, not me. I'll forward to the next guy."
I may be summarizing the idea badly, but that's the gist of what I understood from brief comments about it on an agent call. Did I understand the concept?
If so, here are some thoughts about it. (If I misunderstood the idea, please disregard.)
Although this looks like a nice optimization (and indeed I get why it would save some overhead and simplify some things), I think we should not only not consider this, we should explicitly disallow it. If the packaging in a wire message discloses the key for anyone other than the immediate next recipient, we should agree that all agents should delete the message and refuse to cooperate in forward it.
Here's why.
1. This destroys privacy. Under a method where a forward message must be used to wrap each hop, the only thing that is every known by any given hop is who to send to next. Under the alternative proposal, everybody along the chain knows where messages are going to end up, and at least part of where they came from.
2. It creates an artificial distinction between the behavior of routing and all other protocols that agents deal in. When we have a forward message, forwarding is just another protocol. It doesn't have any special meaning to any intermediary. You get a forward message that you can decrypt; you do the decryption and see that it's a forward request, and if you support that protocol, you service the request. Under the alternative, routing is a very distinct behavior from processing agent messages. I think this violates the DRY principle and creates unnecessary complexity and maintenance burden.
3. It requires too much knowledge by intermediaries. If Alice sends to Bob, every hop has to know how to get to the final destination (and, as I noted in my privacy point #1, every hop gets to record the final destination), whereas under a regime that uses forward messages, only the sender needs to figure out a viable route. Since only the sender should have a need to know that Bob is using a mediator and a routing agent and that Bob is the destination, keeping this concern with the sender feels appropriate.
Perhaps there are variations on this idea, or nuances to it, that are worth discussing? I haven't thought all that through; just wanted to throw out a reaction to get a conversation started...
danielhardman (Sat, 12 Jan 2019 00:41:29 GMT):
I wanted to raise a topic that I've heard @swcurran and @tplooker alude to, and make a comment about it. It is the idea that the wire level messages may be able to short-circuit the need for a forward message type, either always or sometimes, and also eliminate the need for DIDs at that routing level, because the packaging done by @kdenhartog in pack/unpack can reveal the key of the destination. Thus, we could route by keys, not by DIDs, and we don't have to do wrapping and unwrapping; each intermediary can simply inspect the packaging and say, "Nope, not me. I'll forward to the next guy."
I may be summarizing the idea badly, but that's the gist of what I understood from brief comments about it on an agent call. Did I understand the concept?
If so, here are some thoughts about it. (If I misunderstood the idea, please disregard.)
Although this looks like a nice optimization (and indeed I get why it would save some overhead and simplify some things), I think we should not only not consider this, we should explicitly disallow it. If the packaging in a wire message discloses the key for anyone other than the immediate next recipient, we should agree that all agents should delete the message and refuse to cooperate in forwarding it.
Here's why.
1. This destroys privacy. Under a method where a forward message must be used to wrap each hop, the only thing that is every known by any given hop is who to send to next. Under the alternative proposal, everybody along the chain knows where messages are going to end up, and at least part of where they came from.
2. It creates an artificial distinction between the behavior of routing and all other protocols that agents deal in. When we have a forward message, forwarding is just another protocol. It doesn't have any special meaning to any intermediary. You get a forward message that you can decrypt; you do the decryption and see that it's a forward request, and if you support that protocol, you service the request. Under the alternative, routing is a very distinct behavior from processing agent messages. I think this violates the DRY principle and creates unnecessary complexity and maintenance burden.
3. It requires too much knowledge by intermediaries. If Alice sends to Bob, every hop has to know how to get to the final destination (and, as I noted in my privacy point #1, every hop gets to record the final destination), whereas under a regime that uses forward messages, only the sender needs to figure out a viable route. Since only the sender should have a need to know that Bob is using a mediator and a routing agent and that Bob is the destination, keeping this concern with the sender feels appropriate.
Perhaps there are variations on this idea, or nuances to it, that are worth discussing? I haven't thought all that through; just wanted to throw out a reaction to get a conversation started...
danielhardman (Sat, 12 Jan 2019 00:41:42 GMT):
^^ @TelegramSam
mwherman2000 (Sat, 12 Jan 2019 00:59:01 GMT):
@danielhardman "messsage swarms"?
firewater (Sat, 12 Jan 2019 03:34:39 GMT):
is cred definition need to be created once only and reuse or created everytime before issuer create credential for same schema?
swcurran (Sat, 12 Jan 2019 05:36:27 GMT):
@danielhardman - your first point is definitely not what we are proposing - far from it. The routing would continue to operate hop by hop on an as needed basis. The Agent routing a messages sees no more than what they see in the "to" field of the forward. No additional information is being exposed. We are just noting that we think the verkey in a pack()'d message and the "to" field are always going to be the same.
On the second point, you are welcome to have an "Forward" protocol if you want. I just don't think you need it, since this new way of doing pack() makes the point of forward redundant. Per previous point, the pack'd message in the forward already contains the necessary routing information.
swcurran (Sat, 12 Jan 2019 05:36:27 GMT):
@danielhardman - your first point is definitely not what we are proposing - far from it. The routing would continue to operate hop by hop on an as needed basis. The Agent routing a messages sees no more than what they see in the "to" field of the forward. No additional information is being exposed. We are just noting that we think the verkey in a pack()'d message and the "to" field are always going to be the same.
On the second point, you are welcome to have an "Forward" protocol if you want. I just don't think you need it, since this new way of doing pack() makes the point of forward redundant. Per previous point, the pack'd message in the forward already contains the necessary routing information through the exposed verkey.
On point three - I think you misunderstand the idea. There is no pack()'ing the full path. The pack() operations are exactly the same as is done as described in the Cross-Domain HIPE.
I'll try to get something written over the weekend that clarifies how this would work. It may not work, but it definitely wasn't intended to work as you are thinking. I'm pretty sure it's a drop-in replacement for what we already plan to do.
danielhardman (Sat, 12 Jan 2019 10:20:16 GMT):
@swcurran Okay, sounds like I've misunderstood a bit. I'll look forward to your writeup. Thanks for taking time to package the idea.
TelegramSam (Mon, 14 Jan 2019 14:03:51 GMT):
Also very interested. I think we'll need this idea explained at the agent call if not before to make significant progress on the routing HIPE.
misaelssantos (Mon, 14 Jan 2019 14:15:04 GMT):
Has joined the channel.
misaelssantos (Mon, 14 Jan 2019 14:21:07 GMT):
Hello!
the python code in indy-agent project is functional and is the documentartion readme updated?
misaelssantos (Mon, 14 Jan 2019 14:21:07 GMT):
Hello!
the python code in indy-agent project is functional and is the documentation readme updated?
TelegramSam (Mon, 14 Jan 2019 14:21:57 GMT):
@misaelssantos I believe that to be true. If you find something out of order, please let me know!
swcurran (Mon, 14 Jan 2019 14:44:38 GMT):
@danielhardman @TelegramSam - my flights yesterday were cancelled so didn't get to it. I did however get several hours on a treadmill to think more about it, and so will have a write up. I don't think it's earth shattering, but I think it has some nice properties that could be useful to adopt. We'll see what others think.
TelegramSam (Mon, 14 Jan 2019 14:44:54 GMT):
:thumbsup:
misaelssantos (Mon, 14 Jan 2019 14:45:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DK8JCFpRQTHkGss7L) @TelegramSam I'll talk to in pvt.
misaelssantos (Mon, 14 Jan 2019 14:45:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DK8JCFpRQTHkGss7L) @TelegramSam I'll talk to you in pvt.
xnopre (Mon, 14 Jan 2019 15:55:08 GMT):
@tplooker @esplinr Thanks for you answer, confirmations, and other informations. So, for me, no new tools or API in `indy-agent`, and this implementation is very similar than what we have done in our POC. I will take a look a VCX. There is no channel or forum talking and sharing about VCX ?
xnopre (Mon, 14 Jan 2019 16:12:28 GMT):
Looking at `indy-agent`, there are 1 process for each user, each process has its own HTTP port. In real life (= in my future solution), what is the idea for architecture ? I think I will not start as many processes as users... Isn't it ? I imagine that I will have only one process for all users, with different URLs for the (dynamic) endpoints of each user ? Perhaps something like this `https://my-agent-server.com/{DID_of_user}` ? Or perhaps a more anonymous URL with a random hash (`https://my-agent-server.com/{random_hash_for_each_user}`) if it is a bad idea to have the DID in the URL. What are the good ideas or good ways ? Where can I possibly find some documentation or explanations ? Thanks !! :-)
tomislav (Mon, 14 Jan 2019 16:22:30 GMT):
A very simple way to fix this would be, as you said, separate agent URL for each user. You can generate a Guid or Hash and associate that with a specific wallet. This is not a great approach as it is vulnerable to correlation. A better approach would be to use single URL for all users/wallets, and add routing associations, where each user associates destinations with their wallet. The central agent then reads every incoming message, checks the destination, resolves the routing table and forward the message to the appropriate wallet/user/process/queue, etc.
There are standardization HIPE's that discuss possible routing standards if you're looking for specific implementation - https://github.com/hyperledger/indy-hipe/pull/75
esplinr (Mon, 14 Jan 2019 16:27:45 GMT):
@xnopre LibVCX is part of the Indy SDK
esplinr (Mon, 14 Jan 2019 16:27:45 GMT):
@xnopre LibVCX is part of the Indy SDK, discussed in #indy-sdk
jljordan_bcgov (Mon, 14 Jan 2019 16:34:36 GMT):
@xnopre I think you would want to look at the HIPEs regarding message protocols, routing of messages
jljordan_bcgov (Mon, 14 Jan 2019 16:35:09 GMT):
https://github.com/hyperledger/indy-hipe/blob/1bd710c400cbbbe0d3f739cbefb929162e379ccc/text/agent-message-routing/README.md for example
jljordan_bcgov (Mon, 14 Jan 2019 16:35:42 GMT):
and https://github.com/hyperledger/indy-hipe/tree/1bd710c400cbbbe0d3f739cbefb929162e379ccc/text/agent-message-routing
TelegramSam (Mon, 14 Jan 2019 20:31:16 GMT):
merged PR 55 to indy-agent rep from @dbluhm with the last of our needed major refactors prior to building out the rest of our needed features.
TelegramSam (Mon, 14 Jan 2019 20:31:18 GMT):
https://github.com/hyperledger/indy-agent/pull/55#
TelegramSam (Mon, 14 Jan 2019 20:32:07 GMT):
Note: there is an active bug that prevents connecting to a wallet via the UI. You can avoid the bug by using command line wallet connection info, and we are working on the bug fix already.
TelegramSam (Mon, 14 Jan 2019 20:44:23 GMT):
PR for fix: https://github.com/hyperledger/indy-agent/pull/56
TelegramSam (Tue, 15 Jan 2019 00:08:26 GMT):
Fix PR was merged for above mentioned bug.
kdenhartog (Tue, 15 Jan 2019 00:50:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=t4XzeDBF2hhKCkw2G) @danielhardman With regards to the privacy aspects, I don't think this is broken because a Wire Message could wrap another wire message. Given that the forward message content is just a base64 encoded wire message the recipient would see the same data as they would using a forward message from what I can tell. This leads me to believe that number 1 and 3 won't be a problem based on what I know.
I agree with your point about number 2 giving special meaning for routing, but I'm not sold on the additional complexity aspects yet. I'll have to think about this more. To support your argument, I do believe removing the forward message will remove any sort of richness that may come from routing based on DIDs rather than keys, but I'm not certain that it's a profound difference. I think where using DID based routing (with forward messages) rather than key based routing (with only wire messages) would be when a key has been rotated and hops have been notified, but the sender was not.
In this case,
kdenhartog (Tue, 15 Jan 2019 00:50:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=t4XzeDBF2hhKCkw2G) @danielhardman With regards to the privacy aspects, I don't think this is broken because a Wire Message could wrap another wire message. Given that the forward message content is just a base64 encoded wire message the recipient would see the same data as they would using a forward message from what I can tell. This leads me to believe that number 1 and 3 won't be a problem based on what I know.
I agree with your point about number 2 giving special meaning for routing, but I'm not sold on the additional complexity aspects yet. I'll have to think about this more. To support your argument, I do believe removing the forward message will remove any sort of richness that may come from routing based on DIDs rather than keys, but I'm not certain that it's a profound difference.
I think where using DID based routing (with forward messages) rather than key based routing (with only wire messages) would be when a key has been rotated and hops have been notified, but the sender was not. In this case, we'd have a failed route because the intermediary hop might not have a way to resolve the key to an endpoint. A DID wouldn't be rotated though, and therefore wouldn't encounter this issue.
TelegramSam (Tue, 15 Jan 2019 01:09:44 GMT):
@xnopre What @tomislav described is good practice for external exposure. Internally to an agency, however, you may wish to employ those types of processes for internal routing and sharding requests/agents across servers.
It is important to recognize that the python reference agent in indy-agent is designed for readability and completeness, NOT for scale. Anybody running agents as a service (what we call agencies) will need to make a good number of architectural changes to run agents efficiently.
tplooker (Tue, 15 Jan 2019 01:36:09 GMT):
@kdenhartog I agree with your observation around the added complexity when routing via keys instead of DID's however I do think there is a version that prevents the above problem. Say I want to rotate a key for my connection with alice, first I generate a new key, then asking my routing agent to create a route for this new key, on confirmation this route is now placed (and messages are deliverable via the new key), I can communicate this updated key to Alice. Sometime later I may remove the route associated to my old key
kdenhartog (Tue, 15 Jan 2019 02:17:27 GMT):
Yeah, seems like a simple enough solution. I figured it wouldn't be much of a challenge, I was mainly trying to challenge my own thinking to see where it might lead. I think it would be ok to remove the forward message at this point.
TelegramSam (Tue, 15 Jan 2019 03:49:28 GMT):
If the message to be forwarded is still embedded in a new wire level message, then all we avoid is one layer of very simple message. Seems like a small gain for a huge architectural loss. I'll wait for the full writeup though.
xnopre (Tue, 15 Jan 2019 10:49:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=gQRfbdrp9KpxbFT6G) @TelegramSam @TelegramSam In this PR, only Python code seems to be modified. In `indy-agent`, there are 2 sections : python and nodejs. Python section was modified 14 hours ago, and nodejs section was modified 3 months ago. Is only python section up-to-date ? If I have good understood, the repo is "for sample" with how to implement agent with Indy, but are last good ideas only in python section ? .....
firewater (Tue, 15 Jan 2019 10:51:25 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and creds ids?
firewater (Tue, 15 Jan 2019 10:51:25 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and creds ids to be display on cloud agent?
firewater (Tue, 15 Jan 2019 10:51:25 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and creds ids to be display on issuer cloud agent?
firewater (Tue, 15 Jan 2019 10:51:25 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and corresponding creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and creds ids to be display on issuer cloud agent?
firewater (Tue, 15 Jan 2019 10:51:25 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and corresponding creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and corresponding creds ids to be display on issuer cloud agent?
firewater (Tue, 15 Jan 2019 12:38:09 GMT):
I would expect something as simple as sdk.listSchemaIds(walletHandle, filter) and sdk.listCredIds(walletHandle, filter)
TelegramSam (Tue, 15 Jan 2019 13:42:04 GMT):
@firewater the #indy-sdk channel is more appropriate for sdk related questions.
TelegramSam (Tue, 15 Jan 2019 13:50:11 GMT):
@knopre The python code is under current development, and is the closest to current HIPE standards, and that will be the case for quite some time. The nodejs code was an early contribution, and as such was written prior to most of the now accepted HIPEs. Community contributions are welcome for all code within indy-agent, but Sovrin Foundation efforts are focused on the python code for now.
firewater (Tue, 15 Jan 2019 15:51:51 GMT):
i am looking at the indy agent code. what is the different between createDid and createEndpointDid?
xnopre (Tue, 15 Jan 2019 16:03:57 GMT):
@TelegramSam Thanks for you answer ! It's a pity... I just have run the python demo, it's very different than nodejs section...
xnopre (Tue, 15 Jan 2019 16:04:19 GMT):
@tomislav and @jljordan_bcgov Thanks, I will take a look at the pointed hipes...
xnopre (Tue, 15 Jan 2019 16:25:39 GMT):
@dbluhm @TelegramSam I just tried to run the python section of `indy-agent`. I'm on MacOS. I tried to follow the README "using docker". I have some problems :
1/ Each screen start asking for "Wallet credentials". I fill with "Alice / 1234" or "Bob / 1234", but nothing happens when clicking "Open and Create", except than the name (Alice or Bob) appear on top right. I can click on "Connections" and see the 2 empty tables, but if I refresh the browser, I go back to "Wallet credentials" screen... :-/ ... But it's all OK if I start the program with `--wallet Alice 1234` or `--wallet Bob 1234`: in this case, no "login" page, the browser go to "Connections" page
2/ I'm using Docker on MacOS. So I can access to the WEB pages with `http://localhost:
xnopre (Tue, 15 Jan 2019 16:25:39 GMT):
@dbluhm @TelegramSam I just tried to run the python section of `indy-agent`. I'm on MacOS. I tried to follow the README "using docker". I have some problems :
1/ Each screen start asking for "Wallet credentials". I fill with "Alice / 1234" or "Bob / 1234", but nothing happens when clicking "Open and Create", except than the name (Alice or Bob) appear on top right. I can click on "Connections" and see the 2 empty tables, but if I refresh the browser, I go back to "Wallet credentials" screen... :-/ ... But it's all OK if I start the program with `--wallet Alice 1234` or `--wallet Bob 1234`: in this case, no "login" page, the browser go to "Connections" page
2/ I'm using Docker on MacOS. So I can access to the WEB pages with `http://localhost:
TelegramSam (Tue, 15 Jan 2019 17:24:30 GMT):
@xnopre I'm not able to replicate Issue 1. After entering the wallet credentials and seeing the connection screen, a browser refresh returns me to the connection screen bypassing the credential screen. Can you help us drill down to find the issue? (Tested on chrome, code running on Ubuntu VM)
TelegramSam (Tue, 15 Jan 2019 17:25:05 GMT):
Skipping the login page is desired behavior when you supply the `--wallet` command line args.
TelegramSam (Tue, 15 Jan 2019 17:30:28 GMT):
on issue 2: knowing the 'external' ip or hostname is one of our unsolved issues, particularly with docker. I had been planning to solve it with a config argument, but your method of extracting it from inbound connections is clever.
TelegramSam (Tue, 15 Jan 2019 17:35:10 GMT):
We are working on updating the connection protocol so that code will be changing, but we'll suffer from the same problem until we solve it systematically.
TelegramSam (Tue, 15 Jan 2019 17:35:32 GMT):
so, yeah. Submit a PR for that change, and we can work to include that improvement in the future.
TelegramSam (Tue, 15 Jan 2019 22:12:42 GMT):
Open Discussion: We have the opportunity to be json-ld non-conflicting if we change the `@` in our decorators to be another symbol. The symbol should be not super common in variable names (`_` is bad, for example) and should be easily typable and recognizable. Opinions?
I've created a simple tool to help visualize what this looks like: https://jsfiddle.net/d5axm80v/
@danielhardman is leaning towards `+`, and I'm partial to `:`. Go try out options, and let us know what you think!
dbluhm (Tue, 15 Jan 2019 22:37:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam The extra : kind of blends in with the other colons in json syntax
TelegramSam (Tue, 15 Jan 2019 22:49:01 GMT):
@dbluhm it does, but shines in the "field:i10n" case.
TelegramSam (Tue, 15 Jan 2019 22:49:01 GMT):
@dbluhm it does, but shines in the `"field:i10n"` case.
mwherman2000 (Wed, 16 Jan 2019 00:00:24 GMT):
`^`
mwherman2000 (Wed, 16 Jan 2019 00:00:24 GMT):
`^`?
mwherman2000 (Wed, 16 Jan 2019 00:00:24 GMT):
`^`?
```
{
"^type": "foo",
"^id": "1234567890",
"question": "What is your favorite color?",
"question^i10n": {
"language": "en",
"es": "en espanol"
}
}
```
mwherman2000 (Wed, 16 Jan 2019 00:00:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam `^`
mwherman2000 (Wed, 16 Jan 2019 00:00:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam `^`?
mwherman2000 (Wed, 16 Jan 2019 00:00:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam `^`? ...think of it like a little Christmas tree :-)
tomislav (Wed, 16 Jan 2019 02:13:25 GMT):
I like # or $. + is good, too.
tomislav (Wed, 16 Jan 2019 02:17:55 GMT):
What are the implications of being json-ld conflicting? Or compliant for that matter? It would be awesome to describe json-ld message standards schema.org style, only Sovrin.org
xnopre (Wed, 16 Jan 2019 10:55:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=aGQfDErydvW8X4RcD) @TelegramSam Issue 1/ : I cannot reproduce it anymore... Perhaps a link with the "synchronisation" option of my Chrome...
xnopre (Wed, 16 Jan 2019 10:56:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=kZjHevLcoThcaKy44) @TelegramSam OK, I'm preparing a PR ;-) . Do you think that getting IP address like this `socket.gethostbyname(socket.gethostname())` can work running the demo without docker (I cannot do this) ?
TelegramSam (Wed, 16 Jan 2019 13:47:30 GMT):
@xnopre I'll be testing that when evaluating the PR. I think it will work just fine.
TelegramSam (Wed, 16 Jan 2019 14:05:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=qRc3rw5ZfRZWZrRBD) @tomislav json-ld has some excellent properties, but has lots of.... well.... baggage that comes along with using it. Changing from our current designs make some of our requirements difficult to adopt. Being json-ld non-conflicting means that we have the option in the future to move that direction should we choose. It could also be added by somebody dediated in the interum without causing issues.
Having a mechanical definition of message types would be good (though not schema.org/Message based, shudder) but we have not yet moved there.
xnopre (Wed, 16 Jan 2019 14:07:27 GMT):
@TelegramSam PR done : https://github.com/hyperledger/indy-agent/pull/59 ;-) . Waiting for you feedbacks :-)
mwherman2000 (Wed, 16 Jan 2019 14:07:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam 1. Can the decorator symbol be used recursively? e.g. `aaa^bbb^ccc^ddd` ...or is only one level of selection supported?
2. Does this construction also need to work in a URL? ...e.g. in a REST like request? `http://example.com/something?foo=aaa^bbb^ccc^ddd`
mwherman2000 (Wed, 16 Jan 2019 14:07:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uT4CXdN2sHKfkHXE4) @TelegramSam 1. Can the decorator symbol be used recursively? e.g. `aaa^bbb^ccc^ddd` ...or is only one level of selection supported?
2. Does this construction also need to work in a URL? ...e.g. in a REST like request? `http://example.com/something?foo="aaa^bbb^ccc^ddd"`
xnopre (Wed, 16 Jan 2019 14:22:15 GMT):
@TelegramSam And a little FIX for the button "Send connection offer" disappearing in medium or small browser window ;-) : https://github.com/hyperledger/indy-agent/pull/60
mwherman2000 (Wed, 16 Jan 2019 14:31:42 GMT):
@danielhardman Is this an interesting set of use cases for the A2A protocol? https://docs.google.com/presentation/d/1BI3HuvluE_nd7k3hqeLIX6L7sQFtoGrjO07TFl0iZGo/edit#slide=id.p5
mwherman2000 (Wed, 16 Jan 2019 14:31:42 GMT):
@danielhardman Is this an interesting set of use cases validating for the A2A protocol? https://docs.google.com/presentation/d/1BI3HuvluE_nd7k3hqeLIX6L7sQFtoGrjO07TFl0iZGo/edit#slide=id.p5
danielhardman (Wed, 16 Jan 2019 14:43:32 GMT):
@mwherman2000 Wow, that is a wonderful and fascinating document! Yes, I can see lots of resonance for A2A in the content of those slides.
mwherman2000 (Wed, 16 Jan 2019 14:51:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=noBqh6u8b3jEaF3fZ) @danielhardman I believe this is what @trbouma is going to be talking in his webinar today. Checkout the posting in #indy-agent
mwherman2000 (Wed, 16 Jan 2019 14:51:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=noBqh6u8b3jEaF3fZ) @danielhardman I believe this is what @trbouma is going to be talking in his webinar today. Checkout the posting in #indy
trbouma (Wed, 16 Jan 2019 14:51:04 GMT):
Has joined the channel.
TelegramSam (Wed, 16 Jan 2019 15:41:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=TqXCwrsfcoFvCfRpn) @mwherman2000 multiple decorators in a single attribute has not been discussed, and I don't believe URL use is a requirement, though it would be convenient.
pknowles (Wed, 16 Jan 2019 16:43:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=iNaut6tQASyJxDuXr) @TelegramSam My two cents worth would be to not enable multiple decorators in a single attribute. The more flexible approach would be to layer decorators and link them through identifiers. If you were to allow multiple decorators within a single attribute, you basically limit any interoperability between objects contained within the layered endpoint message.
danielhardman (Wed, 16 Jan 2019 17:45:06 GMT):
@mwherman2000 I agree with @TelegramSam that we haven't discussed the question of recursion before. There *is* the notion of nested agent messages, each of which could have decorators inside it--so you could have decorators at many different levels. I guess that's a form of recursion. But I don't know that we've encountered a semantic goal that would require decorating a decorator directly. It's an interesting thought. If we can avoid recursion, it probably keeps things simpler, but may also constrain semantics a bit...
Using decorators outside of JSON is discussed in the decorator HIPE proposal, but the specific notion of embedding them in URIs is novel--and intriguing.
danielhardman (Wed, 16 Jan 2019 17:48:42 GMT):
I'm soliciting feedback on PR #76. This PR was opened originally as PR #68, and accumulated a little bit of feedback there. Then we decided to split two concepts apart, so #76 was created. It hasn't had any feedback since then. If that means it is not controversial, it would be nice to close it out as an item we can agree upon.
danielhardman (Wed, 16 Jan 2019 17:48:42 GMT):
Different topic: I'm soliciting feedback on PR #76. This PR was opened originally as PR #68, and accumulated a little bit of feedback there. Then we decided to split two concepts apart, so #76 was created. It hasn't had any feedback since then. If that means it is not controversial, it would be nice to close it out as an item we can agree upon.
TelegramSam (Wed, 16 Jan 2019 17:50:07 GMT):
@danielhardman heh. I JUST was looking at that to guide my simplemessage HIPE.
mwherman2000 (Wed, 16 Jan 2019 19:30:33 GMT):
@danielhardman @TelegramSam RE: "decorator recursion" e.g. `aaa^bbb^ccc^ddd` Caveat: I'm still learning what decorators/decoration is all about.
1. My idea was more related to Daniel's comment (but different) ...e.g. can there be "decorator"-like things within a (parent) decorator? ...i.e. the recursion thought was really about _recursive selection_ ...similar I think to where Daniel was headed but I think he was talking about recursive selection nested within messages ...a macro scope. I was thinking about decorators-within-decorators (a micro scope) without knowing if that even makes sense.
2. The URL question is an important one for any specification-based decisions that are expected to be long-lived (e.g. 100 years).
mwherman2000 (Wed, 16 Jan 2019 19:32:13 GMT):
p.s. I guess no one likes `^`?
tplooker (Wed, 16 Jan 2019 19:58:26 GMT):
zoom
pknowles (Thu, 17 Jan 2019 02:23:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=v6FqHvaw7ipLTiaWz) @danielhardman In relation to "overlays" interoperability, I'm hoping to spend some dedicated time on "decorators" over the coming weekend. It's still hot on my radar but my free time has just been swallowed up since we last spoke. [Cc: @mtfk ]
herveblanc (Thu, 17 Jan 2019 10:30:54 GMT):
I noticed https://sovrin.org/upcoming-sovrin-agent-connectathon/ happened yesterday. Did anyone pull a slide deck for this that could be shared here? Thx
herveblanc (Thu, 17 Jan 2019 10:55:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=j2FNsctA2QGB5Kgbs) I got the date wrong. @xnopre rightly pointed out the event is in Feb...
vsadriano (Thu, 17 Jan 2019 11:21:03 GMT):
Has joined the channel.
HiranKumar (Thu, 17 Jan 2019 12:27:55 GMT):
How can we get the schema defention using schema
TelegramSam (Thu, 17 Jan 2019 14:17:04 GMT):
== Agent Message Decorator Charactor ==
Arguments for or against go here: https://docs.google.com/document/d/17RfTrHpWGLd5Re8zso5f_VIbmxpZK-4N3jmE6PniZwo/edit?usp=sharing
Please add your comments directly to the doc (public editable)
HiranKumar (Thu, 17 Jan 2019 17:44:30 GMT):
Hi
HiranKumar (Thu, 17 Jan 2019 17:47:38 GMT):
I deployed my application in azure.But the application didnt get the indy.dll.I think it is due to the absence of libindy.In my local machine,I copied the libindy in a folder and specified the path in a the environment variable as like this D:\Projects\IdRamp\Blockchain\indy-sdk\libindy\lib.
HiranKumar (Thu, 17 Jan 2019 17:47:54 GMT):
So how can I solve this issue in azure
Yair (Fri, 18 Jan 2019 11:00:34 GMT):
Has joined the channel.
AlexanderVtyurin (Fri, 18 Jan 2019 12:25:08 GMT):
Has joined the channel.
alkopnin (Fri, 18 Jan 2019 12:36:21 GMT):
Hi guys,
Our team is working on Corda Agent (part of HL-lab) and in order to implement agent we made some fixes in vcx java wrapper. We would like to be synchronized with you and contribute the code. Do you have someone responsible for vcx java wrapper?
BTW
@AlexanderVtyurin could you share what we exaclty did?
alkopnin (Fri, 18 Jan 2019 12:36:21 GMT):
Hi guys,
Our team is working on Corda Agent (part of HL-lab) and in order to implement agent we made some fixes in vcx java wrapper. We would like to be synchronized with you and contribute the code. Do you have someone responsible for vcx java wrapper?
BTW
@AlexanderVtyurin could you share what we exaclty did?
AlexanderVtyurin (Fri, 18 Jan 2019 12:38:56 GMT):
Hello everyone. https://github.com/seniorjoinu/indy-sdk/commit/8ab8c0ce6f6efd441a7e2d09fb6ca9a0a080f36e - here is the commit with vcx java wrapper fixes. Some method signatures was incorrect and some native function invocations was incorrect too.
```
```
AlexanderVtyurin (Fri, 18 Jan 2019 12:38:56 GMT):
Hello everyone. https://github.com/seniorjoinu/indy-sdk/commit/8ab8c0ce6f6efd441a7e2d09fb6ca9a0a080f36e - here is the commit with vcx java wrapper fixes. Some method signatures was incorrect and some native function invocations was incorrect too.
TelegramSam (Fri, 18 Jan 2019 13:53:02 GMT):
@alkopnin @AlexanderVtyurin The #indy-sdk channel is the right place for sdk conversations.
TelegramSam (Fri, 18 Jan 2019 13:53:12 GMT):
(But awesome work!)
alkopnin (Fri, 18 Jan 2019 14:13:48 GMT):
Cool, thanks!
janl (Mon, 21 Jan 2019 08:19:59 GMT):
indy agent
xnopre (Mon, 21 Jan 2019 14:37:17 GMT):
I'm looking at "agent" concept, reading documents and code, but I don't really understand which data will be stored in the "edge" or "cloud" agent ? For example, if user's credentials are stored in the wallet associated with the edge agent, on the smartphone of the user, they will not be available if the smartphone is off (or offline). If I good understand, the solution is around the "cloud" agent. Is the idea to store the user's credential in the wallet associated with the cloud agent ? In this case, the cloud agent is probably a WEB service, for example provided by my platform, and this service is managing many users, am I right ? But in this cas, this WEB service has to store keys to open and access wallet for each user, isn't it ? But this can be a vulnarable "honey pot" ? .... Where can I find more information to find answer for this questions ? And perhaps some schema or diagram to illustrate solution ? Thanks :-)
haggs (Mon, 21 Jan 2019 15:15:02 GMT):
Hey @xnopre I think the best document that might help would be this one: https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.ody6evg9dhq7
haggs (Mon, 21 Jan 2019 15:15:23 GMT):
It's a little dated however, someone else might know of better documentation or describe things better!
TelegramSam (Mon, 21 Jan 2019 15:15:27 GMT):
New HIPE: Admin Messages https://github.com/hyperledger/indy-hipe/blob/3ca8dfe1a25cd05ea249189f56d0fc93a1635f01/text/admin-messages/README.md
It's time to formalize this concept.
TelegramSam (Mon, 21 Jan 2019 15:18:20 GMT):
@xnopre the doc linked by @haggs is good, but deep and a little unorganized. The core concept is that a user's keys would remain on their edge agent, and the cloud agent would only retain keys for those actions allowed them. In many cases, this will be minimal and they will only store messages for later retrieval by the edge agent. In some cases (like the cloud agent for an enterprise) they may have more power delegated to them and will hold more keys in the cloud wallet.
TelegramSam (Mon, 21 Jan 2019 15:54:11 GMT):
Updated Connection Protocol HIPE: https://github.com/hyperledger/indy-hipe/blob/250d65e224b982fa56a6521f4a10b4b2c25bba81/text/connection-protocol/README.md
I've removed peer DIDs in the invitation message, and updated the signature requirement of the response to reflect Kyle's Signature HIPE.
I've updated the questions at the bottom. Please review and consider!
swcurran (Mon, 21 Jan 2019 16:10:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=GrW5R33JahLBjjvxR) @TelegramSam Definitely need to clarify this soon. It's not clear to me that is the right answer. Or at least this needs to be explained in great detail.
xnopre (Mon, 21 Jan 2019 16:18:20 GMT):
@haggs @TelegramSam Thank you for your answer and links.
If I understand, the main idea is that cloud agent is there to store and temporize messages for owner, waiting to be able to join its edge agent ? cc @swcurran
haggs (Mon, 21 Jan 2019 20:32:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Cs2LD9fxMjfcZamH3) The part (of many, many parts) that might need clarifying is the "power delegated" for me. Power could extend from acting entirely on behalf of an identity owner (with a set of keys and described powers for...message types? The recent admin message family comes to mind) or in the case of a simple email relay like discussed last week in the agent call, this could simply be the power to "share DID or URL endpoints across agents"? Please correct me where I might be thinking down the wrong path
TelegramSam (Mon, 21 Jan 2019 20:45:55 GMT):
@haggs there are certainly things we need to work out there. I'd appreciate any comments on my recent Admin Messages HIPE.
haggs (Mon, 21 Jan 2019 20:47:58 GMT):
That's probably more constructive, will do!
tplooker (Tue, 22 Jan 2019 00:16:33 GMT):
Wonder if anyone has been throwing the idea around of wallet or agent trust. I've been thinking that certain issuers and verifiers may want proof that an agent/wallet is suitably protected before entrusting in a proof / issuing a credential. For example the Government may wish to say they only want to issue passports into wallets that have sufficient security mechanisms enabled. A verifier receiving a proof of a passport may also want to verify that the wallet is strongly protected and someone hasn't just picked up another persons phone and disclosed information on their behalf. Just an idea at this stage, wondering if anyone else has been thinking along those lines?
tplooker (Tue, 22 Jan 2019 00:16:33 GMT):
Wondering if anyone has been throwing the idea around of wallet or agent trust. I've been thinking that certain issuers and verifiers may want proof that an agent/wallet is suitably protected before entrusting in a proof / issuing a credential. For example the Government may wish to say they only want to issue passports into wallets that have sufficient security mechanisms enabled. A verifier receiving a proof of a passport may also want to verify that the wallet is strongly protected and someone hasn't just picked up another persons phone and disclosed information on their behalf. Just an idea at this stage, wondering if anyone else has been thinking along those lines?
tplooker (Tue, 22 Jan 2019 00:17:26 GMT):
By security mechanism i mean biometrics authentication or some form of strong authentication between the app and user
tplooker (Tue, 22 Jan 2019 00:17:26 GMT):
By security mechanism i mean biometrics authentication or some form of strong authentication between the app and user to authorize certain actions
mwherman2000 (Tue, 22 Jan 2019 00:45:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=9vfuT9otdgtLRzvQY) @tplooker Because @danielhardman will be thinking along these lines ;-), are you envisioning a decentralized solution like some of reputation based metric or multiple reviewers/voters? ...or something more centralized? e.g. security certification authority/assessments?
tplooker (Tue, 22 Jan 2019 00:48:08 GMT):
@mwherman2000 Im not sure of the shape as yet but essentially what I think would be ideal is an agent being able to prove they are suitably secured, this could be achieved in a variety of ways such as a wallet vendor credential, i.e an assertion from the wallet vendor the wallet is secured. Im unsure of how a reputation based system would work?
mwherman2000 (Tue, 22 Jan 2019 00:56:47 GMT):
@tplooker I'm just throwing out some ideas. Perhaps some sort of open source "common code" approach could be used ...something like have your provided a trusted/trustable implementation of interface(s) xyz, or have actual trusted common code that needs to be verifiably part of your solution.
mwherman2000 (Tue, 22 Jan 2019 00:56:47 GMT):
@tplooker I'm just throwing out some ideas. Perhaps some sort of open source "common code" approach could be used ...something like have your solution provided a trusted/trustable implementation of interface(s) xyz, or have actual trusted common code that needs to be verifiably part of your solution.
mwherman2000 (Tue, 22 Jan 2019 00:56:47 GMT):
@tplooker I'm just throwing out some ideas. Perhaps some sort of open source "common code" approach could be used ...something like has your solution provided a trusted/trustable implementation of interface(s) xyz, or have actual trusted common code that needs to be verifiably part of your solution.
danielhardman (Tue, 22 Jan 2019 00:57:48 GMT):
@tplooker and @mwherman2000 I have thought about this issue, but from a different use case perspective. I was thinking that if I were doing business with a given remote party, I might want to only accept their signature on legal contracts if that signature came from a key protected by biomatrics. In other words, I'd be unwilling to accept a signature that came from something that could be automated. I hadn't thought about your use case--only issue a credential or share a proof if the remote party has a wallet with particular characteristics. That use case feels more iffy to me, because there's no way of knowing what somebody does with a proof; it might not go into a wallet at all, no matter how strong a wallet the remote party possesses...
I also ran into this requirement when exploring refugee use cases. iRespond is working on Rohingya situations in Myanmar, and they want to guarantee that an aid worker cannot act as guardian for a refugee child and impersonate them to get foot and such. Thus, they want to allow an aid worker to be a limited form of guardian that can only proceed if there is also a key tied to a biometric for the identity owner. They went one step further, and suggested that the biometric needed to have a freshness criterion--the aid worker has to have used the child's biometrics to generate a countersigning key within the past X minutes.
danielhardman (Tue, 22 Jan 2019 00:57:48 GMT):
@tplooker and @mwherman2000 I have thought about this issue, but from a different use case perspective. I was thinking that if I were doing business with a given remote party, I might want to only accept their signature on legal contracts if that signature came from a key protected by biomatrics. In other words, I'd be unwilling to accept a signature that came from something that could be automated. I hadn't thought about your use case--only issue a credential or share a proof if the remote party has a wallet with particular characteristics. That use case feels more iffy to me, because there's no way of knowing what somebody does with a proof; it might not go into a wallet at all, no matter how strong a wallet the remote party possesses...
I also ran into this requirement when exploring refugee use cases. iRespond is working on Rohingya situations in Myanmar, and they want to guarantee that an aid worker cannot act as guardian for a refugee child and impersonate them to get food and services. Thus, they want to allow an aid worker to be a limited form of guardian that can only proceed if there is also a key tied to a biometric for the identity owner. They went one step further, and suggested that the biometric needed to have a freshness criterion--the aid worker has to have used the child's biometrics to generate a countersigning key within the past X minutes.
danielhardman (Tue, 22 Jan 2019 00:58:29 GMT):
One way to represent this info would be to self-attest it when naming keys in a DID document. Alice says, "this key is tied to a biometric; that key is not".
danielhardman (Tue, 22 Jan 2019 00:58:29 GMT):
One way to represent this info would be to self-attest it when naming keys in a DID document. Alice says, "this key of mine is tied to a biometric; that key is not".
danielhardman (Tue, 22 Jan 2019 00:58:29 GMT):
One way to represent this info would be to self-attest it when naming keys in a DID document. Alice says, "This key of mine is tied to a biometric; that key is not. This key is stored in a secure enclave; that one is not." This opens up the possibility of fingerprinting someone by the characterstics of their keys, and self attestation may not be reliable enough.
danielhardman (Tue, 22 Jan 2019 01:01:29 GMT):
We could certainly express key/signing requirements in a proof request, but we wouldn't have any way to test them in a pure peer interaction.
What we *could* do is introduce an intermediary that attests to the nature of a given key. For example, a biometric service could attest that a key is tied to a biometric, and that the biometric has been reverified as recently as X minutes ago. Of course, this undermines privacy and self-sovereignty, so it's of debatable value.
tplooker (Tue, 22 Jan 2019 01:10:08 GMT):
Interesting perspective! Essentially the direction I am coming from is if there are sub-par wallet implementations that dont enforce wallet protection strategies, then they can in effect undermine credential disclosure. We could push it back to a wallet vendor credential however this does cause unwanted disclosure of information
tplooker (Tue, 22 Jan 2019 01:11:21 GMT):
By pushing the trust back to the implementer of the wallet/agent technology we circumvent this to a degree
tplooker (Tue, 22 Jan 2019 01:11:48 GMT):
I.e if you trust the technology vendor then you can have greater trust in the disclosure?
kdenhartog (Tue, 22 Jan 2019 02:17:01 GMT):
We may be able to use a Sovrin certified vendor credential to handle this, but even then I could think of ways that a holder COULD (with a lot of wasted energy because it ultimately hurts the holder's security) circumvent this. On the other hand, I'm wondering what the negative implications of this could become. I could see issuers putting some extraneous requirements in place which hurts the sovereignty of individuals. For example, an oppressive regime may say that they'll only issue passports to citizens who use approved wallets (with backdoors built in).
tplooker (Tue, 22 Jan 2019 03:09:25 GMT):
@kdenhartog Yeah you are absolutley right by identifying the wallet vendor in any form, parties could accept or deny solely based on that information.
tplooker (Tue, 22 Jan 2019 03:10:23 GMT):
Wrapping it to a Sovrin issued wallet credential is definitely an improvement but not the perfect solution.
drummondreed (Tue, 22 Jan 2019 06:52:49 GMT):
Great discussion. These are all considerations we are looking at for DKMS (Decentralized Key Management System), an open standard for SSI wallets that needs to address these core trust issues. Those of us working on DKMS have been thinking that a standard certification of your DKMS wallet (in the form of a verifiable credential of course) could be a part of mainstream DKMS wallet implementations, and the more widely deployed DKMS is, the more that offering ZK proof of such a credential should not have negative privacy characteristics due to herd privacy.
jljordan_bcgov (Tue, 22 Jan 2019 15:29:54 GMT):
Yes .. we would also be interested in this approach of having some sense that the agent a citizen is using when they request their government issued identity credential is "well behaved" ... being able to provide a proof that the wallet has some thrid party accreditation such as sovrin or kantara or DIACC ... something like that .. or even if it comes from known vendors perhaps could be sufficient
jljordan_bcgov (Tue, 22 Jan 2019 15:30:21 GMT):
this will be essential I think for verifiers like banks
kdenhartog (Tue, 22 Jan 2019 16:07:28 GMT):
As I think about it more, while I see that there are negatives that could occur, I'm leaning towards the belief that independent 3rd party auditors (to avoid issues like above) certifying software with credentials would benefit more than hurt.
kdenhartog (Tue, 22 Jan 2019 16:07:28 GMT):
While I see that there are negatives that could occur, I'm leaning towards the belief that independent 3rd party auditors (to avoid issues like above) certifying software with credentials would benefit more than hurt.
kdenhartog (Tue, 22 Jan 2019 16:11:02 GMT):
Another cool way this might be done. We could use a Token Curarated Registry to manage the issuance of these credentials. This would add economic incentive complexity though, so definitely not an MVP type idea.
TelegramSam (Tue, 22 Jan 2019 16:34:35 GMT):
New Indy-Agent PR accepted from @xnopre with a layout fix for smaller screens. Thanks!
danielhardman (Tue, 22 Jan 2019 17:14:04 GMT):
@TelegramSam and @mwherman2000 et al.: We never got to closure on a prefix char for decorators. I saw various proposals, but nothing advocated strongly. Last I heard from Sam was the proposal for ~, which I find myself liking quite a bit because it has the virtue of not needing to be percent encoded in URLs. So that's my vote. Anybody else got a strong opinion?
TelegramSam (Tue, 22 Jan 2019 17:21:27 GMT):
+1 to voicing an opposing opinion now: I expect this to be cleared up and finalized at or before tomorrow's Agent Call.
mhailstone (Tue, 22 Jan 2019 17:23:15 GMT):
Here is the document link for reference on the decorator prefix preferences: https://docs.google.com/document/d/17RfTrHpWGLd5Re8zso5f_VIbmxpZK-4N3jmE6PniZwo/edit
danielhardman (Tue, 22 Jan 2019 17:29:54 GMT):
@mwherman2000 Can you say something about your preference for ^? I don't have a strong negative or positive reaction to it, but you said you liked it quite a lot, and I'm curious if there's goodness there I haven't considered.
danielhardman (Tue, 22 Jan 2019 17:30:11 GMT):
Did anybody ever try / (slash)?
kdenhartog (Tue, 22 Jan 2019 18:20:56 GMT):
I'm for 💩 or 🔥
kdenhartog (Tue, 22 Jan 2019 18:22:15 GMT):
Realistically, I think ~ is good
mwherman2000 (Tue, 22 Jan 2019 19:21:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xhvLZdS3WkP2pyi6k) @danielhardman I'm OK with ~ (tilde). :-)
danielhardman (Tue, 22 Jan 2019 22:49:57 GMT):
I've been thinking about how to make the connectathon a success. I put some ideas into slides; wonder what everybody thinks... https://docs.google.com/presentation/d/1429FKEcS1ogWdvJ9ubEx43hcWHqjKEggvpdFwvuDr5k/edit
danielhardman (Tue, 22 Jan 2019 22:54:14 GMT):
^^ @swcurran @TelegramSam @nage @kenebert @tplooker
nage (Tue, 22 Jan 2019 23:17:03 GMT):
I hope folks have seen the connect-a-thon agenda so far here: https://docs.google.com/document/d/1dfGj5yjpSHzRF6UVPv7Ld1PTFme3fsXEwpLs0_e6NGA/edit?ts=5c45e8d7
nage (Tue, 22 Jan 2019 23:17:23 GMT):
@danielhardman I haven't had a chance to look at your document or notes to consider how to reconcile them (I hope to get to that soon)
nage (Tue, 22 Jan 2019 23:18:21 GMT):
though I think most of the suggestions on slide 4 went into building the agenda. I started Tuesday as a 'see where we're at relative to the test suite' day
nage (Tue, 22 Jan 2019 23:18:33 GMT):
and the show-and-tell proposed is scheduled Wednesday
danielhardman (Tue, 22 Jan 2019 23:19:59 GMT):
I saw an earlier version of this doc, but not most of the content that's in it now--so thanks for surfacing it again. Excellent.
I don't think it's smart to frame everything in terms of the test suite; that's the most advanced form of interop. I think it's highly desirable, but I think we need some baby steps before we evaluate test suite compliance.
danielhardman (Tue, 22 Jan 2019 23:20:33 GMT):
That's why I suggested 3 levels of interop, where the first one just begins with us testing plaintext file compatibility, manually.
TelegramSam (Tue, 22 Jan 2019 23:33:38 GMT):
+1 for happy path connection protocol. I have more words on that soon.
TelegramSam (Tue, 22 Jan 2019 23:34:51 GMT):
Interesting thought for plaintext. I wonder if the right applicaiton of that is a non-encrypting test wire protocol, where the needed info is passed in plaintext. That would be easy to write to even on the spot, and swappable later for full wire level support.
TelegramSam (Tue, 22 Jan 2019 23:35:29 GMT):
aldready in the agenda is an end of day "how do we need to adjust tomorrow's schedule" which I think is good.
swcurran (Tue, 22 Jan 2019 23:58:44 GMT):
@nbrempel @jljordan_bcgov ^^^^^
andrew.whitehead (Wed, 23 Jan 2019 00:01:02 GMT):
Has joined the channel.
TelegramSam (Wed, 23 Jan 2019 00:06:47 GMT):
quick sketch of possible 'plaintext wirelevel format':
```{
"test_wire_format": true,
"recipient_key": "123456",
"sender_key": "8765432",
"agent_message: { "~type":"..." }
}```
TelegramSam (Wed, 23 Jan 2019 00:06:47 GMT):
quick sketch of possible 'plaintext wirelevel format':
```{
"test_wire_format": true,
"recipient_key": "123456",
"sender_key": "8765432",
"agent_message": { "~type":"..." }
}```
nbrempel (Wed, 23 Jan 2019 00:08:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Cq9m5LDF6BrnEKTwW) @swcurran Looks good to me
TelegramSam (Wed, 23 Jan 2019 00:09:01 GMT):
On Connection Protocol: There are three 'accepted' sovrin connection varients. I propose we consider the full Peer DID one first: copy paste invite URL, peer DID invite, peer DID request, peer DID response.
TelegramSam (Wed, 23 Jan 2019 00:09:39 GMT):
The other two (Public DID Invite, Implied Public DID Invite) can be considered lower priority.
nbrempel (Wed, 23 Jan 2019 00:21:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=uCSwaqLTCRxBXCpMq) @nage Schedule looks good to me. Just a heads up: @andrew.whitehead and I (BCGov) will be flying out Friday morning but we can partake in the hack portion via airplane wifi etc :)
rajeshkalaria (Wed, 23 Jan 2019 03:01:10 GMT):
Has joined the channel.
kdenhartog (Wed, 23 Jan 2019 04:31:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=KMhNPfAM6e8CXus5v) @TelegramSam Why do you need keys if it's plaintext?
kdenhartog (Wed, 23 Jan 2019 04:31:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=KMhNPfAM6e8CXus5v) @TelegramSam What are the keys used for if it's plaintext?
TelegramSam (Wed, 23 Jan 2019 04:56:10 GMT):
@kdenhartog just to mimic what we'd get out of an encrypted message.
kdenhartog (Wed, 23 Jan 2019 04:56:45 GMT):
gotcha
TelegramSam (Wed, 23 Jan 2019 18:49:10 GMT):
Accepted Python Ref Agent PR: Revised Connection Protocol (partial) This works, but ignores signature checking.
TelegramSam (Thu, 24 Jan 2019 16:23:31 GMT):
call recordings for yesterday's Agent Call: https://drive.google.com/drive/u/0/folders/1gma1_M1bKKMFsmFHVABu-11pAo8mYt1K
shader (Thu, 24 Jan 2019 22:23:20 GMT):
Has joined the channel.
Dubh3124 (Fri, 25 Jan 2019 05:15:15 GMT):
So if you have a cloud/hub agent (this agent has its own wallet) with multiple user wallets, when calling ledger.sign_and_submit_request(), is it safe to have the agent DID (i.e as submitter_did) sign for all users that are submitting a request?
Dubh3124 (Fri, 25 Jan 2019 05:48:26 GMT):
For instance, when building a NYM request, I've noticed the submitter did should be the agent DID (or the wallet associated with the agent that has Trust ANCHOR permission). However, when building schema request the submitter DID can be any DID from a wallet.
Dubh3124 (Fri, 25 Jan 2019 05:48:26 GMT):
For instance, when building a NYM request, I've noticed the submitter did should be the agent DID (or the wallet associated with the agent that has Trust ANCHOR permission). However, when building schema request the submitter DID can be any stored DID from a wallet.
Dubh3124 (Fri, 25 Jan 2019 06:27:55 GMT):
Nvm ignore, some confusion with my design
ashishchainworks (Fri, 25 Jan 2019 09:42:18 GMT):
Has joined the channel.
ashishchainworks (Fri, 25 Jan 2019 09:53:01 GMT):
Hi There, We need to build one agent app for Andriod. It seems Java version is not stable. Has any one buld app for Andriod? Which Libindy wrapper we should use?
ashishchainworks (Fri, 25 Jan 2019 09:53:01 GMT):
Hi There, We need to build one agent app for Andriod. It seems Java version is not stable. Has any one build app for Andriod? Which Libindy wrapper we should use? -Thanks for help.
nage (Fri, 25 Jan 2019 16:32:01 GMT):
@ashishchainworks have a look at https://github.com/sovrin-foundation/connector-app @burdettadam and @kdenhartog are working on getting this code building in public and can help with questions.
ashishchainworks (Fri, 25 Jan 2019 16:44:18 GMT):
Thanks Nage. Will check with @burdettadam and @kdenhartog
ashishchainworks (Fri, 25 Jan 2019 16:44:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jQoRT73dARsP8Y2aq) @danielhardman Hi @Daniel/@TelegramSam
danielhardman (Fri, 25 Jan 2019 18:57:47 GMT):
I've proposed a new HIPE about JSON-LD compatibility: https://github.com/hyperledger/indy-hipe/pull/83. Interested in feedback--particularly from those who felt that we hadn't clarified the relationship between @type and decorators. @devin-fisher @swcurran @TelegramSam @tplooker
ardagumusalan (Fri, 25 Jan 2019 20:11:45 GMT):
Hi, is there a list that I can add myself to be notified regarding community meetings?
pknowles (Fri, 25 Jan 2019 21:12:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cRp2fP7PoBgzTtGea) @ardagumusalan Here is the * Hyperledger community calendar* - https://calendar.google.com/calendar/embed?mode=AGENDA&src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=UTC
ardagumusalan (Fri, 25 Jan 2019 21:44:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cECst6eRShzoqKddP) @pknowles this is great. Thanks!
MikeRichardson (Fri, 25 Jan 2019 22:18:25 GMT):
Has joined the channel.
ashishchainworks (Sun, 27 Jan 2019 03:19:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=jQoRT73dARsP8Y2aq) @danielhardman Dear @danielhardman @TelegramSam In your A2A presentation, we have agent no 8 playing mail service and there are multiple 2 type agents in an Agency. Do we have any reference implementation of cloud agent hosted in an Agency. Is reference agent , available at https://github.com/hyperledger/indy-agent , Edge Agent or Cloud Agent or Cloud Agent in an Agency? -thks
mwherman2000 (Sun, 27 Jan 2019 16:35:33 GMT):
@ashishchainworks What Daniel calls a "dumb app" I refer to as an Edge Agent Lightweight App. Checkout elements (24) through (29) in the INDY ARM: https://hyperonomy.com/2019/01/13/hyperledger-indy-sovrin-comprehensive-architecture-reference-model-arm/
danielhardman (Sun, 27 Jan 2019 22:54:51 GMT):
The indy-agent repo is supposed to have multiple reference agents in it, but I think right now the most mature code it has is for a python-based cloud agent.
There is a reference edge agent as well, called the Sovrin Connector. This is a mobile app for iOS and Android. I don't know where its code is located; perhaps @esplinr or @nage can give us the URL.
Neither of these is the thing I called a "dumb app". The Sovrin Connector is a rich edge agent.
haggs (Sun, 27 Jan 2019 23:41:35 GMT):
https://github.com/sovrin-foundation/connector-app
haggs (Sun, 27 Jan 2019 23:41:35 GMT):
Sovrin Connector: https://github.com/sovrin-foundation/connector-app
ashishchainworks (Mon, 28 Jan 2019 06:58:25 GMT):
Thanks @mwherman2000 . I agree. It is a light weight app.
ashishchainworks (Mon, 28 Jan 2019 06:59:48 GMT):
Thanks Daniel. Do you recommend any Python Application Server?
TelegramSam (Mon, 28 Jan 2019 13:57:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=tJFTRqLSwGam285Gt) @Dubh3124 I'm not sure I understand your question well enough to give a good answer. Can you give us any additional details?
TelegramSam (Mon, 28 Jan 2019 14:01:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=A2izufAQTojHjxBHr) @ashishchainworks The python code in indy-agents has a built in server to handle requests. Is there something else you are looking for?
ashishchainworks (Mon, 28 Jan 2019 14:39:04 GMT):
Hi @TelegramSam, I was looking for industry leading app server like WebSphere/Tomcat in J2EE world.
TelegramSam (Mon, 28 Jan 2019 14:41:01 GMT):
@ashishchainworks most production python apps are hosted behind something like Nginx or Apache/mod_wsgi.
TelegramSam (Tue, 29 Jan 2019 00:20:52 GMT):
@dbluhm has pushed indy-sdk pack/unpack wire level support in a branch: https://github.com/hyperledger/indy-agent/tree/pack-unpack
Note that this requires a local build of indy-sdk and a force reinstall of the python sdk wrapper (instructions in readme) while we wait for package drops.
After packages drop, this will be merged into master.
Nice work@dbluhm and @kdenhartog and others!
dbluhm (Tue, 29 Jan 2019 00:43:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RYjXRJB98yM9v4qqS) @TelegramSam Also good to note that this was added specifically to the Python reference agent (under indy-agent/python) in case that wasn't clear.
dbluhm (Tue, 29 Jan 2019 00:43:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=RYjXRJB98yM9v4qqS) @TelegramSam Also good to note that this was added specifically to the Python reference agent (under indy-agent/python) in case that wasn't clear.
stefan.vogl (Tue, 29 Jan 2019 10:39:16 GMT):
Has joined the channel.
Sandeep (Wed, 30 Jan 2019 18:06:06 GMT):
Has joined the channel.
danielhardman (Wed, 30 Jan 2019 21:16:32 GMT):
My proposal about the issue of generic ACKs or generic problem reports in specific protocols: https://github.com/hyperledger/indy-hipe/blob/a4688b90cbb0f35e64866af2e24e92aff9830f2e/text/protocols/README.md#adopted-messages
swcurran (Wed, 30 Jan 2019 21:18:08 GMT):
@danielhardman - is that updated since we talked to address what I was seeing as the dispatching issue?
danielhardman (Wed, 30 Jan 2019 21:18:19 GMT):
Yes--that's why I wrote it
danielhardman (Wed, 30 Jan 2019 21:18:54 GMT):
But I want to see how you and others feel about what I'm proposing. I'm happy to rip it out if people don't like it.
danielhardman (Wed, 30 Jan 2019 21:18:59 GMT):
Just my best thinking so far.
danielhardman (Wed, 30 Jan 2019 22:34:28 GMT):
@mwherman2000 I've updated the "How to define a protocol" HIPE in two ways to reflect the learnings that you gave me on BPMN:
1. The "Prior Art" section now begins with a new subsection on BPMN, because I think of all prior art, BPMN's scope of concerns is closest to the problem domain of A2A protocols. I included a link to Camunda, mentioned BPMN's XML file format, and linked to a nice discussion about choreographies. I also suggested that we may want to use BPMN's
2. I went into the section of the HIPE that talks about state machines and diagrams, and added a discussion about using BPMN choreography diagrams there.
I would be glad of feedback.
https://github.com/hyperledger/indy-hipe/blob/f12c422213b19e4181cdd288671afe2218f82e2c/text/protocols/README.md#bpmn
https://github.com/hyperledger/indy-hipe/blob/f12c422213b19e4181cdd288671afe2218f82e2c/text/protocols/README.md#states-under-tutorial
danielhardman (Wed, 30 Jan 2019 22:34:28 GMT):
@mwherman2000 I've updated the "How to define a protocol" HIPE in two ways to reflect the learnings that you gave me on BPMN:
1. The "Prior Art" section now begins with a new subsection on BPMN, because I think of all prior art, BPMN's scope of concerns is closest to the problem domain of A2A protocols. I included a link to Camunda, mentioned BPMN's XML file format, and linked to a nice discussion about choreographies. I also suggested that we may want to use BPMN's diagrams.
2. I went into the section of the HIPE that talks about state machines and diagrams, and added a discussion about using BPMN choreography diagrams there.
I would be glad of feedback.
https://github.com/hyperledger/indy-hipe/blob/f12c422213b19e4181cdd288671afe2218f82e2c/text/protocols/README.md#bpmn
https://github.com/hyperledger/indy-hipe/blob/f12c422213b19e4181cdd288671afe2218f82e2c/text/protocols/README.md#states-under-tutorial
danielhardman (Wed, 30 Jan 2019 23:22:37 GMT):
All: I have raised a new PR with the mediator and relay stuff: https://github.com/hyperledger/indy-hipe/pull/85
dbluhm (Wed, 30 Jan 2019 23:29:43 GMT):
@TelegramSam @danielhardman and others: I definitely can't claim to be an expert in this area so take this for what it's worth but does the error reporting mechanism in the revised connection protocol vulnerable to being used in a DDoS attack? For example, someone looks over the ledger pulling down DIDs that likely point to agents of public entities then crafts a connection request that they know will fail but specify an endpoint that is actually the endpoint of a target. The attacker could then send this request to every endpoint it found on the ledger which then all try to send an error report to the targeted endpoint.
dbluhm (Wed, 30 Jan 2019 23:29:43 GMT):
@TelegramSam @danielhardman and others: I definitely can't claim to be an expert in this area so take this for what it's worth but is the error reporting mechanism in the revised connection protocol vulnerable to being used in a DDoS attack? For example, someone looks over the ledger pulling down DIDs that likely point to agents of public entities then crafts a connection request that they know will fail but specify an endpoint that is actually the endpoint of a target. The attacker could then send this request to every endpoint it found on the ledger which then all try to send an error report to the targeted endpoint.
kdenhartog (Wed, 30 Jan 2019 23:40:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cDsBfdDfK43nGQLBE) @dbluhm It may be possible to perform a DoS amplification attack with the error reporting work which is what you've described. I'd have to look at how people have solved this in the past. I think DNS ran into this problem and was able to come up with a solution.
haggs (Wed, 30 Jan 2019 23:54:42 GMT):
DNSSEC ceremonies?
haggs (Wed, 30 Jan 2019 23:54:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QENLvJio9ejYpzGpZ) @DuckLover @DuckLover I'll take a stab but I'm sure more experienced experts in this channel will chime in. I think right now the protocol and exact details for for creating that establishment of connection is a continual effort captured in this HIPE: https://github.com/hyperledger/indy-hipe/pull/54/. The reference agent (beautifully done in the video) might be making some assumptions about where the protocol is and will change as the protocol does.
Most recently the excellent work by @dbluhm and others has probably the best reference to establishment of connection between two agents that could be diagrammed. Running the reference agent and then viewing the JSON output in your terminal might give you the best reference to put into a visual sequence diagram. I hope that helps
danielhardman (Wed, 30 Jan 2019 23:55:06 GMT):
@dbluhm My read on it is that parties are not *required* to send error messages, almost ever, in A2A. They are *allowed* to send them at carefully chosen points, with carefully chosen meanings. One of the questions to ask when sending messages is: Can I get the message there? Another is: Should I send this? The latter question should be filtered through a security lens.
We should probably update the problem-report HIPE with a discussion of this topic. I believe there's already a mention in it about this risk.
kdenhartog (Thu, 31 Jan 2019 00:02:10 GMT):
Given that we have a connection setup first, I think the primary way this could be used is by sending problem-reports for the connection protocol. Most other situations would be significantly reduced by requiring a connection is already setup to send messages. It would still be possible, but it would be far more theoretical then practical to execute with already setup connections.
danielhardman (Thu, 31 Jan 2019 00:16:50 GMT):
A while ago, I wrote a HIPE about how to request two-way, sync communication over an A2A channel. I then paused the HIPE because I wasn't confident of some of my ideas. I have now done a light update of it, and I think it's now worthy of community review. I don't think we need this right away, but we will be seeing some patterns at the connect-a-thon that will eventually require a mechanism with approximately this feature set. Maybe there are better ways?
https://github.com/hyperledger/indy-hipe/pull/72
tplooker (Thu, 31 Jan 2019 00:21:01 GMT):
@danielhardman great timing, I was going to reach out about this and see where it had got to, will endeavor to squeeze in a review over the next week or so.
TelegramSam (Thu, 31 Jan 2019 15:11:07 GMT):
On the way to working out field based signatures, I ran into questions about the right way to proceed.
First Option:
```
{
"@id": "5678876542345",
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/request",
"label": "Bob",
"connection": {
"DID": "B.did@B:A",
"DIDDoc": {
// did Doc here.
}
}
}
```
On the response, you would sign the 'connection' attribute.
Then, I learned from the DID Spec that the DID MUST be present in a fully resolved did document. This means that we could only use the DIDDoc attribute alone.
Second Option:
```
{
"@id": "5678876542345",
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/request",
"label": "Bob",
"DIDDoc": {
// did Doc here, which MUST contain a DID to be fully resolved.
}
}
```
On the response, you would sign the 'DIDDoc' attribute.
This finds conflict with any non-peer DID usage flows. While we will be promoting Peer DIDs within the Indy and Sovrin communities, there are players in the ecosystem that may want to stick with publicly resolvable based DIDs for connections, and we will want a path forward to allow connections if the user is willing to accept those.
Do we allow use of either a DIDDoc _or_ just a DID?
Does the DID need to be signed in the response? (it would if the returned DID was not the same as used in the invitation)
Should we allow this in the request and response message types, or should we have different request and response message types that allow returning the DID alone?
Thoughts?
TelegramSam (Thu, 31 Jan 2019 15:12:00 GMT):
@danielhardman @tplooker @nage @swcurran @dbluhm and anybody else ^
danielhardman (Thu, 31 Jan 2019 15:49:55 GMT):
I've been thinking about this statement: "the DID MUST be present in a fully resolved did document." To me, the answer to Sam's question may depend on whether we should assume that the DID doc we receive is fully resolved. If we sign "connection", then we can tolerate DID Docs that aren't fully resolved. If we sign the DID Doc only, then we can't.
I'm feeling like signing "connection" is better. Doesn't hurt anything to be more flexible...
TelegramSam (Thu, 31 Jan 2019 16:03:48 GMT):
If we sign 'connection' it also makes the DID vs DIDDoc (or an optional DIDDoc rather) cleaner.
TelegramSam (Thu, 31 Jan 2019 16:04:06 GMT):
also open to better name for 'connection'.
nage (Thu, 31 Jan 2019 16:21:15 GMT):
First, the @type should be about the semantics of the message not control, so did:sov probably doesn't make sense there. Second it is *much* better to use credentials or self-signed data separately from a DID Doc, this might make more sense as some type of bundle message so that the data structure for labels and other attributes can be more formally structured (unless connection already has strong typing for a label -- we just want to avoid those types of attributes bleeding into did docs that are stored on immutable registries -- too much correlation leakage)
xaviervila (Thu, 31 Jan 2019 17:33:20 GMT):
Has joined the channel.
TelegramSam (Thu, 31 Jan 2019 18:03:37 GMT):
@nage I don't understand what you are saying. I suspect there is a huge amount of context missing.
Message types ('@type') use a DID as resolution to the type spec, so only control exerted there is by the owner of the DID referenced.
And none of this is stored on an immutable registry... it's an agent message passed from one peer to another.
nage (Thu, 31 Jan 2019 18:33:31 GMT):
My comment is colored by the Schema 2.0 effort and largely ignorant of this weeks discussions in the agent group
nage (Thu, 31 Jan 2019 18:33:49 GMT):
types are about the meaning of the data regardless of transport, movement or channel
nage (Thu, 31 Jan 2019 18:35:03 GMT):
so did:sov references only make sense in that the semantics are sourced from a private peer connection, and even in these cases a content-addressable derivation for the id makes more sense, which makes it independent of source. So pathed references to particular agents probably don't make sense, except as an additional context to reference what agent is considered as the authority over updates or resolving ambiguity
TelegramSam (Thu, 31 Jan 2019 19:04:48 GMT):
The type reference is NOT to an agent, but to a spec service pointer which resolves to a documentation URL. Also, it isn't a did:sov reference, but a DID reference which can use any method.
TelegramSam (Thu, 31 Jan 2019 19:06:57 GMT):
that doc reference can be content addressable storage, but that doesn't make sense when documentation updates are required without schema changes. The documentation contains not only the schema of the message, but also includes the other important protocol details releveant to the message family in use.
TelegramSam (Thu, 31 Jan 2019 19:07:39 GMT):
I've updated the connection protocol HIPE has been updated per yesterday's agent call conversation about signing attributes instead of signing the entire message: https://github.com/hyperledger/indy-hipe/blob/a580d00be443990dfcbcf12be5ac85808340de1f/text/connection-protocol/README.md
nage (Thu, 31 Jan 2019 20:43:30 GMT):
Types are not API routes. APIs have side effects, forwarding, and other data transformation semantics that are not about the type, and graph path for addressing a particular API or data item is more properly part of an object ID, not the type.
danielhardman (Thu, 31 Jan 2019 21:20:34 GMT):
@nage I think you are talking about quite a separate topic from the one Sam raised. I am agreeing everything you said but it feels like it doesn't relate to Sam's issue. Might be easier to resolve interactively.
danielhardman (Thu, 31 Jan 2019 21:20:41 GMT):
Separate thread: I have raised a new PR with an explainer around agents--what they are, how they work, how they can be categorized, how to write one, etc. This might be a useful resource for new community members who want an introduction to the concept. Something like it has been needed for a while. I suspect other community members can improve it in various ways, so please weigh in. https://github.com/hyperledger/indy-hipe/pull/86
vo2vo (Fri, 01 Feb 2019 04:40:14 GMT):
Has joined the channel.
nage (Fri, 01 Feb 2019 05:03:20 GMT):
Had a good discussion with @TelegramSam today and he helped me understand the requirements issues he is working from. I think there is still more overlap here, but it won't become apparent until later, and it isn't worth disrupting the good work going on preparing for the connectathon. I am satisfied that this issue will come back soon as the Schema work becomes more clear. Until then I might make some suggestions to rearrange some of how we identify type strings, but not untill we have a clearer way of communicating what value it will add.
phillip.gibb (Fri, 01 Feb 2019 10:52:20 GMT):
Has joined the channel.
DavidP (Fri, 01 Feb 2019 14:53:48 GMT):
Has joined the channel.
mwherman2000 (Fri, 01 Feb 2019 16:04:31 GMT):
RE: _raised a new PR with an explainer around agents--what they are, how they work, how they can be categorized_ @danielhardman This is a great primer for Agents ...a good characterization of Agents and their capabilities across several dimensions. Your HIPE was the inspiration for the following chart: https://hyperonomy.com/2019/02/01/architecture-driven-taxonomy-for-ssi-agents/ Your thoughts?
danielhardman (Fri, 01 Feb 2019 16:09:36 GMT):
@mwherman2000 I love it! Do you want to raise a PR against my PR, adding your diagram down in the "Categorizing Agents" section, with a link to your blog post?
mwherman2000 (Fri, 01 Feb 2019 16:11:12 GMT):
@danielhardman "The impossible I can do" but I don't know how to PR a PR? ;-)
mwherman2000 (Fri, 01 Feb 2019 16:12:13 GMT):
Do you mean to fork your repo?
mwherman2000 (Fri, 01 Feb 2019 16:13:10 GMT):
Should we go offline?
swcurran (Fri, 01 Feb 2019 16:13:29 GMT):
@mwherman2000 @danielhardman - have fun! :-)
danielhardman (Fri, 01 Feb 2019 16:15:35 GMT):
To PR my PR:
- fork the hyperledger/indy-hipe repo
- define 3 remotes: "origin" (your fork), "upstream" (hyperledger's copy), and "dhh1128" (my version)
- git fetch dhh1128
- create a new orphan github branch (git checkout --orphan agents)
- on the new branch, git merge dhh1128/agents
- push your changes to origin (your fork)
- on github, click "New Pull Request" button; define the PR so its source is the "agents" branch of your fork, and target is the "agents" branch of my repo
mwherman2000 (Fri, 01 Feb 2019 16:17:48 GMT):
Check my DM :-)
Doug-K1 (Fri, 01 Feb 2019 19:05:58 GMT):
Has joined the channel.
SaraInadam (Sat, 02 Feb 2019 10:53:07 GMT):
Has joined the channel.
DuckLover (Sat, 02 Feb 2019 16:54:40 GMT):
Hello, can someone maybe supply some information about the establishment of an secure connection between 2 Agents. Based on this video https://www.youtube.com/watch?v=9WZxlrGMA3s. I would like to create a sequence diagram this but not quite sure about the details
peacekeeper (Sat, 02 Feb 2019 18:50:33 GMT):
@TelegramSam @danielhardman Could you clarify what you mean by "a fully resolved did document" vs "DID Docs that aren't fully resolved"? This sounds really confusing to me, is there some other way this can be described?
haggs (Sat, 02 Feb 2019 19:04:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QENLvJio9ejYpzGpZ) @DuckLover I'll take a stab but I'm sure more experienced experts in this channel will chime in. I think right now the protocol and exact details for for creating that establishment of connection is a continual effort captured in this HIPE: https://github.com/hyperledger/indy-hipe/pull/54/. The reference agent (beautifully done in the video) might be making some assumptions about where the protocol is and will change as the protocol does.
Most recently the excellent work by @dbluhm and others has probably the best reference to establishment of connection between two agents. Hope that helps!
haggs (Sat, 02 Feb 2019 19:05:46 GMT):
I would recommend running the reference agent between alice and bob and then analyzing the JSON output in each terminal as a connection invite is generated and a pairwise DID relationship is created to get down to the more detailed view.
DuckLover (Sat, 02 Feb 2019 20:08:10 GMT):
I created a few days earlier a sequence diagram based on a paper that i need to find again but i was pretty sure that is was correct. In the video it seems all a little bit different because Alice is creating the connection request :thinking:
DuckLover (Sat, 02 Feb 2019 20:08:39 GMT):
secure_communication.pdf
DuckLover (Sat, 02 Feb 2019 21:34:34 GMT):
maybe an ugly link is better then the file
DuckLover (Sat, 02 Feb 2019 21:34:35 GMT):
https://www.draw.io/?lightbox=1&highlight=0000ff&edit=_blank&layers=1&nav=1&title=secure_communication(1).xml#R7Vxbk5s2FP41nkkedof75XEv2STTNLPtZpqkLx0Msq1ZQC7g3XV%2FfSUQoBsOJsZlXfshgQNIWOfTd76jI%2B%2FMvEle3mfBevUrikA8M7ToZWbezgxDN20f%2F0cs28riOtSwzGBEb2oND%2FAfQI0atW5gBHLuxgKhuIBr3hiiNAVhwdmCLEPP%2FG0LFPO9roMlkAwPYRDL1q8wKlbUqmtae%2BEDgMsV7dqz6YV5ED4uM7RJaX8zw1yUn%2BpyEtRt0fvzVRChZ8ZkvpuZNxlCRXWUvNyAmIxtPWzVc3cdV5v3zkBa9HnAnQfzQA%2BteWi4C2uuXRhVC09BvKFjMTOvPoFoCTL6xsW2HiX88mtyuEniT3ABYpjis%2Bs1yGACCny%2FeRtT831ru35ewQI8rIOQPPqM8YNtqyKJ8ZmOD7FLiwA%2FkjXncRysczgve9WwJQPhJsvhE%2Fgd5BVyiBVtCtLTTYOI8lbiCRDRpprB1sp2ExjS4ziYg%2Fi6cd0NihHpPkXlF8qLDD2C2og9qpWf5kqNENLFAsYxc%2Bdd%2BSF2%2FK3uggTGZEL8AbIoSANqpujXDXqu6iiI4TLFthC7tRxE2c%2FU9U8gK8ALY6J%2Bfw8QdkC2xbfQq3YNZjpHPXr6zAC%2BvmXFYN12qDGgk2zZNN0CDR9QrPXEXT3zWeCJeGNQskYwLcr%2B7euZfSvADmXFCi1RGsQs8FowaKcOhs5p3Rsdls2BQzdU6JDB4R8AG1%2FukwxuHlPPfLqL3v%2F5MfzNvbho8H3GxxTxoWYPGR%2BOPRY%2B7DM%2BJowPS%2BuJjzFii6nSNF8%2FPJwFzZQxuLegaUT4voLGG0XQKFB3JqSDEZK5LzpEQdOTkCxrDHB4Kka6iiGmkDMnTRiGe3OSPilO8s%2BUNCIlefuCY1KUZMkJ%2BGdUdPNRSi7%2BkGgod%2BgWPiYDA8MgvqJjW6A1M9IxWBTkAdwUTJdfyLXbC%2BeEIDUCm5g92cQ8QNYlA0bOyM%2BAmRhgxDW%2B%2FxYw8tryGTATA4yYQx0TMMp1nR5ZFEijK1LzIeE6DvKcOIxFCB6NbPuNOrE8%2Bc6e3L5wZ1v2jJE2lfEFFt%2FqZvHxd8betkNOtsyJ2Eqnn3K0yUKwW7wVQbYEXRKkTjpJvWanuxl%2F2ir5SW0ZiIMCJwHcW6p8THu4J5KxRVOznFMrHE9oovrC9Cm2TCU0JAY%2BR5TH1ahIDZWQa772cBRaEgphCgsYEPbSymQqLCRc4ilX8EjMSC4VtEmWrLAl3SlSWgKjiDzfxUZtwVGFs51TTCSJprxK33jGlihV5HGhXWJx6nCeqlv%2FSSRduEKzusU3gRaLHIzi%2Bx5JE8NANBqwAaozMCjZ5FKz3CMxysTYwtf5SW5owiTvyxa%2B%2FYOGRmaLPrXMgZDpdPRUfCgOvZirvhof9qg3%2Fkh47Jj5tSTRLzWXUyWXuukMUSadwHhNeuFw6NEcoSG9F3qwO4MtcxsN0GPgS06GbjJQCYrbj%2FgUf3PsVA1nAb8A8kpv7vMt2EQo3SZve0gNHnuUYti8g5r6Cw5VHsZnTp0Y7J9%2FdE57NgGxFAg8xJqY2lHOqERAJQCWTprhczpA9%2FfXASyvmD5PLK51UF7ppSx2k482KfLxfAF6Yi26L%2Fl4oo5xjxy6XAmxzxmsmeXN1w8PbwV6obZTJRVb9KzlS6TSOIlFljEaqSgKgIcnFcwpmslxivFzlOIJWsVwzYlxij9tSvH9YZTimHxDpvguI1OKMWoQ7MTDRNwolV2GRgbdt3c3NLYb96OdU0pMD%2BdDsSExSIzsw5oJzj6Uh37wPOzpw%2B70sKMfV%2F3CLSSqFg8LEJmr6TouROlfGfh7A%2FLijaQEP6M0BH1EYI9F7E2B6rKcXH9TF%2Bn4qpx1GOFnCOOv2n5zXOGn2GUxM5yYjEsEn%2FDhkhzyKwHVZdwdc4fioUbQP5L1guryPBMf6NFM30dPCSkdE5UFiq%2FAyWirDopa%2BS6WH5ggYEnve1yCYNnGccuZEwkthiCwLd2%2FdJiPOyzQ2JbF48oVEoCx65Zy%2BZwGgBmztIindJCUOyXKf7HlXRqtqy%2ByyFDCLRyc0qwXd%2BA1v1tl44N31PggV5oPOO%2BnLvDE6WLpAwWeIaz%2FSw2NPe%2FkXyNxK20dU468zilOM0%2BIrr5ChhlHnWaqor4khTjZnK9RmoNSN19J66dXso7%2BP6oo2xZ%2B9aXYPmaqqjejOdoeQ0d5xtx0HE5HGeX%2Bw1ZHOXqtqwastJbFII9fanX0Zu11n6VWYadhZAMvsmbinkTzZ1XcayoyG5rLg9RzhgUZS9jdZh85yDij5gjyrlWmEkA28nHwtIxB1UWm%2FKlrNjeDXGvvCTQMwqq6ws6fGE8Ex6aQs7rmQLFkClUK98hbbZzd9Up1tD2lsOkI65oNI7GbHo6ahrhDdz%2FlGCvFwGjKM44149cpDI4dfHt%2FeuiKhe3%2B8EtNF8Iu7ec4Fc5XGEx1kTvsgSTk%2BSYfTMVS6cgk5MqJd05%2BAltt8E6STYrJgKQCp0U9tqhhVD9QVeFnAPXg0%2FYPW1V%2Ba%2F96mPnuXw%3D%3D
mwherman2000 (Sun, 03 Feb 2019 00:30:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QENLvJio9ejYpzGpZ) @DuckLover Checkput https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L17-L59
...generated by these lines in the `getting_started-verbose.py` script: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L36-L76
I'm working a diagram ...should be ready sometime Monday.
DuckLover (Sun, 03 Feb 2019 01:28:17 GMT):
Does the code write all DID in the ledger? It is maybe not the modern standard but i need to work with the point that is used in the video
andrew.whitehead (Sun, 03 Feb 2019 01:41:50 GMT):
Is there a suggested MIME type for wire messages over HTTP? I can't see one anywhere
mwherman2000 (Sun, 03 Feb 2019 02:16:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=NXgnrz6twafHoqmkQ) @DuckLover Not automatically. It only writes to the Ledger what is needed for verification purposes.
mwherman2000 (Sun, 03 Feb 2019 02:17:46 GMT):
@DuckLover The script and the video are very similar ...same scenario ...I don't if they are exactly the same ...but they are close.
DuckLover (Sun, 03 Feb 2019 03:31:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=b7Jmmj6HR2dGDXQnK) @mwherman2000 i looked into the log and it looks like the agent from alice writes to the ledger directly. I am not sure that it is needed even in the earlier point of development. Shouldnt it normally be that the Faber sends the connection request because it can write to the ledger?
DuckLover (Sun, 03 Feb 2019 03:32:53 GMT):
Is it even possible that Alice creates an connection request without beeing able to write to the leder?
mwherman2000 (Sun, 03 Feb 2019 03:46:28 GMT):
@DuckLover It's super tedious to explain this as chat text. I've started on the diagram. It's a fairly tedious protocol - I hope the diagram will help a lot. The diagram will be annotated with the same numbering used for the tasks in the script. There will be an exact 1:1 correlation between the script code, the script logs, and the diagram.
Caveat: the `getting_started.py` simulates the details of what an agent-to-agent conversation would look like ...without using actual agents. The script is one long-hand piece of Python that calls directly into the Indy SDK to make all the calls a group of agents would have to make for the screnario. It's precise and accurate without having agents implemented as separate communicating/cooperating tasks, for example.
mwherman2000 (Sun, 03 Feb 2019 03:46:28 GMT):
@DuckLover It's super tedious to explain this as chat text. I've started on the diagram. It's a fairly tedious protocol - I hope the diagram will help a lot. The diagram will be annotated with the same numbering used for the tasks in the script. There will be an exact 1:1 correlation between the script code, the script logs, and the diagram.
Caveat: the `getting_started.py` simulates the details of what an agent-to-agent conversation would look like ...without using actual agents. The script is one long-hand piece of Python that calls directly into the Indy SDK to make all the calls a group of agents would have to make for the screnario. It's precise and accurate without having agents implemented as separate communicating/cooperating tasks.
DuckLover (Sun, 03 Feb 2019 04:55:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QuxtGSAFwwXmLesDk) @mwherman2000 thanks for your reply, i am really looking forward your diagram :-) Thank you for your effort
DuckLover (Sun, 03 Feb 2019 17:59:42 GMT):
At what time does the DID Owner (pairwise or verinym) define the agent endpoint in the did Doc?
mwherman2000 (Sun, 03 Feb 2019 20:50:04 GMT):
@DuckLover @swcurran @danielhardman @kdenhartog What do you think of this visualization/representation? 
...it's only represents the first set of tasks in the Alice buys a Car scenario (i.e. Government - Onboarding e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L21-L66).
mwherman2000 (Sun, 03 Feb 2019 20:50:04 GMT):
@DuckLover @swcurran @danielhardman @kdenhartog What do you think of this visualization/representation? https://raw.githubusercontent.com/mwherman2000/indy-dev/master/python/doc/images/Indy-SDK-Getting-Started-1.1-MessageFlow.png
...it's only represents the first set of tasks in the Alice buys a Car scenario (i.e. Government - Onboarding e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L21-L66).
mwherman2000 (Sun, 03 Feb 2019 20:50:04 GMT):
@DuckLover @swcurran @danielhardman @kdenhartog What do you think of this visualization/representation of the Alice buys a Car scenario? https://raw.githubusercontent.com/mwherman2000/indy-dev/master/python/doc/images/Indy-SDK-Getting-Started-1.1-MessageFlow.png
...it's only represents the first set of tasks in the scenario (i.e. Government - Onboarding e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L21-L66). It takes a little bit of _hunting around_ to go from task to task ...but I believe that also has a pedagogical benefit. I'll be working through the rest of the script/scenario in the same style. Please provide feedback/thumps/thumpsdown.
mwherman2000 (Sun, 03 Feb 2019 20:50:04 GMT):
@DuckLover @swcurran @danielhardman @kdenhartog What do you think of this visualization/representation of the Alice buys a Car scenario? https://raw.githubusercontent.com/mwherman2000/indy-dev/da28f23ee95b378d7f7b65de9e551fdbf6d7f712/python/doc/images/Indy-SDK-Getting-Started-1.1-MessageFlow.png
...it's only represents the first set of tasks in the scenario (i.e. Government - Onboarding e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L21-L66). It takes a little bit of _hunting around_ to go from task to task ...but I believe that also has a pedagogical benefit. I'll be working through the rest of the script/scenario in the same style. Please provide feedback/thumps/thumpsdown.
DuckLover (Sun, 03 Feb 2019 23:04:57 GMT):
Is the service endpoint the agent endpoint? If yes, how does the other party know it?
DuckLover (Sun, 03 Feb 2019 23:05:51 GMT):
and the stewards writes only the did and the verkey in the ledger. Where does the agent endpoint in the did doc come from?
DuckLover (Sun, 03 Feb 2019 23:07:11 GMT):
But i like the visualization of this, it is pretty easy to understand
tomislav (Sun, 03 Feb 2019 23:24:42 GMT):
The endpoint can be written on the ledger as an attribute of the DID.
tomislav (Sun, 03 Feb 2019 23:25:31 GMT):
If not on the ledger, it is included as part of the request/response exchange
DuckLover (Sun, 03 Feb 2019 23:35:24 GMT):
Isnt it missing in the diagram then?
mwherman2000 (Mon, 04 Feb 2019 05:30:04 GMT):
@DuckLover @tomislav This script (i.e. forked from @kdenhartog 's https://github.com/kdenhartog/indy-dev) _does not interface at the agent level_ ...this script is a long, sequential set of plain old calls into the Indy SDK that simulates the communications that would take place between 5 agents (Sovrin Steward, Government, Acme Corp, Faber College, and Thrift Bank) to implement the Alicw buys a Car scenario _without_ using multiple processes/tasks/threads to implement real agents. The script is a _low-level_ SDK sample whose primary intent is to illustrate and educate developers on the typical patterns of calls to employ when using the _Indy SDK_. The script is lower-level than agents and DID Documents, for example. It would be valuable to have a highly similar,parallel sample that talks to an Indy reference agent and/or using DID Documents.
NOTE: DID Documents aren't a necessity when it comes to using DIDs (note the discussion here: https://github.com/w3c-ccg/did-spec/issues/151#issuecomment-460058111).
mwherman2000 (Mon, 04 Feb 2019 05:30:04 GMT):
@DuckLover @tomislav This script (i.e. forked from @kdenhartog 's https://github.com/kdenhartog/indy-dev) _does not interface at the agent level_ ...this script is a long, sequential set of plain old calls into the Indy SDK that simulates the communications that would take place between 5 agents (Sovrin Steward, Government, Acme Corp, Faber College, and Thrift Bank) to implement the Alice buys a Car scenario _without_ using multiple processes/tasks/threads to implement real agents. The script is a _low-level_ SDK sample whose primary intent is to illustrate and educate developers on the typical patterns of calls to employ when using the _Indy SDK_. The script is lower-level than agents and DID Documents, for example. It would be valuable to have a highly similar,parallel sample that talks to an Indy reference agent and/or using DID Documents.
NOTE: DID Documents aren't a necessity when it comes to using DIDs (note the discussion here: https://github.com/w3c-ccg/did-spec/issues/151#issuecomment-460058111).
mwherman2000 (Mon, 04 Feb 2019 05:30:04 GMT):
@DuckLover @tomislav This script (i.e. forked from @kdenhartog 's https://github.com/kdenhartog/indy-dev) _does not interface at the agent level_ ...this script is a long, sequential set of plain old calls into the Indy SDK that simulates the communications that would take place between 5 agents (Sovrin Steward, Government, Acme Corp, Faber College, and Thrift Bank) to implement the Alice buys a Car scenario _without_ using multiple processes/tasks/threads to implement real agents. The script is a _low-level_ SDK sample whose primary intent is to illustrate and educate developers on the typical patterns of calls to employ when using the _Indy SDK_. The script is lower-level than agents and DID Documents, for example. It would be valuable to have a highly similar, parallel sample that talks to an Indy reference agent and/or using DID Documents.
NOTE: DID Documents aren't a necessity when it comes to using DIDs (note the discussion here: https://github.com/w3c-ccg/did-spec/issues/151#issuecomment-460058111).
mwherman2000 (Mon, 04 Feb 2019 05:30:04 GMT):
@DuckLover @tomislav This script (i.e. forked from @kdenhartog 's https://github.com/kdenhartog/indy-dev) _does not interface at the agent level_ ...this script is a long, sequential set of plain old calls into the Indy SDK that simulates the communications that would take place between 5 agents (Sovrin Steward, Government, Acme Corp, Faber College, and Thrift Bank) to implement the Alice buys a Car scenario _without_ using multiple processes/tasks/threads to implement real agents. The script is a _low-level_ SDK sample whose primary intent is to illustrate and educate developers on the typical patterns of calls to employ when using the _Indy SDK_. The script is lower-level, for example, than agents and DID Documents. It would be valuable to have a highly similar, parallel sample that talks to an Indy reference agent and/or using DID Documents.
NOTE: DID Documents aren't a necessity when it comes to using DIDs (note the discussion here: https://github.com/w3c-ccg/did-spec/issues/151#issuecomment-460058111).
mwherman2000 (Mon, 04 Feb 2019 05:30:04 GMT):
@DuckLover @tomislav This script (i.e. forked from @kdenhartog 's https://github.com/kdenhartog/indy-dev) _does not interface at the agent level_ ...this script is a long, sequential set of plain old calls into the Indy SDK that simulates the communications that would take place between 5 agents (Sovrin Steward, Government, Acme Corp, Faber College, and Thrift Bank) to implement the Alice buys a Car scenario _without_ using multiple processes/tasks/threads to implement real agents. The script is a _low-level_ SDK sample whose primary intent is to illustrate and educate developers on the typical patterns of calls to employ when using the _Indy SDK_. The script is lower-level, for example, than agents and DID Documents. It would be valuable to have a highly similar, parallel sample that talks to an Indy reference agent and/or using DID Documents.
NOTE: DID Documents aren't a requirement when it comes to using DIDs (note the discussion here: https://github.com/w3c-ccg/did-spec/issues/151#issuecomment-460058111).
HLFPOC (Mon, 04 Feb 2019 10:39:53 GMT):
Has joined the channel.
HLFPOC (Mon, 04 Feb 2019 10:42:21 GMT):
Hi Team, Can we create native apps (using IONIC framework) which can act as an agent to interact with indy nodes ? Is yes, then which indy sdk wrapper I would use in my android and iOS apps ?
HLFPOC (Mon, 04 Feb 2019 10:42:21 GMT):
Hi Team, Can we create native apps (using IONIC framework) which can act as an agent to interact with indy nodes ? Is yes, then which indy sdk wrapper I would use in my android and iOS apps as codebase will be common for both the platforms?
HLFPOC (Mon, 04 Feb 2019 10:42:21 GMT):
I have one doubt regarding Indy Agents, from what I have learnt, it that agents can be categorized on the basis of location (i.e.: edge or cloud). So if i have a scenario, in which I want the user(holder of creds) to have a mobile app, and interact with the network, can I go with implementing a cloud based agent rather than integrating mobile based (edge agents) in mobile ? If yes, then can you please explain if we have to create a separate agent for all the users or a common cloud based agent can handle wallets of multiple users ?
DuckLover (Mon, 04 Feb 2019 14:27:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=X72RxC7cekGS6amh8) @mwherman2000 Thats makes me not sure if i understand DID and DID Document :thinking: By sharing your DID, you give a person/organisation your PublicKey for a secure communication but also an endpoint (like an url) where the agents send their data to. Without providing an endpoint behind the DID how does the agent know where to send data to?
mwherman2000 (Mon, 04 Feb 2019 14:42:38 GMT):
At the low(er) level that I'm talking about (below the agent/DID Document level), the agent doesn't have any information about the endpoint ...at this level there are no agents ...but this is at the low-level _plumbing_ level ...i.e. the plumbing doesn't know about pumps and water taps, etc. ...hope the metaphor works.
DuckLover (Mon, 04 Feb 2019 14:53:23 GMT):
ahhh, okay i get it. Thanks
TelegramSam (Mon, 04 Feb 2019 15:10:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=JmmAH8XDwy9wGMB6G) @peacekeeper We pulled that language from https://w3c-ccg.github.io/did-spec/#did-subject under the Note. Open to better language there though.
TelegramSam (Mon, 04 Feb 2019 15:40:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=7zWD8And5R3Hca5XS) @andrew.whitehead We have not yet made that decision, but sounds like worth working out. :)
HLFPOC (Mon, 04 Feb 2019 16:41:40 GMT):
In my use case, I want to give the user a mobile based application which should be capable to interact with Indy nodes and do the required txns (like issue/request credentials).
From what I have learnt so far is that, we have to create agent application, which interacts with Indy nodes
And we have wrappers available of Indy SDK to create the agent app in different languages.
But I am planning to create mobile app using IONIC framework which can build cross platform native apps for both android and iOS
so wanted to understand whether I would be able to integrate Indy SDK in ionic app or I would have to go with Native app development and use Indy SDK wrapper for Android & iOS?
mwherman2000 (Mon, 04 Feb 2019 17:01:28 GMT):
Can someone help @HLFPOC ? ...with the above agent/SDK questions CC: @kdenhartog
mwherman2000 (Mon, 04 Feb 2019 17:01:28 GMT):
Can someone help @HLFPOC ? ...with the above agent/SDK questions CC: @kdenhartog @tomislav
mwherman2000 (Mon, 04 Feb 2019 18:10:33 GMT):
@danielhardman @pknowles Wondering outloud... Is the OSI Communications 7-Layer Model useful for partitioning some of the layers in the A2A and schema discussions?
Reference: https://en.wikipedia.org/wiki/OSI_model#Description_of_OSI_layers
tomislav (Mon, 04 Feb 2019 19:21:10 GMT):
@HLFPOC Ultimately, you need libindy native binary both for iOS and Android in order to run it. With ionic, you could use a plugin that exposes interfaces to both. I'm not sure if the Nodejs wrapper can be used in the context of embedded web view and call the platform specific API for you, out of the box. If that's the case, then you can use the nodejs wrapper. Connect me app was written in react native, which is of similar architectural setup for both platforms. https://github.com/evernym/sovrin-connector-preview
andrew.whitehead (Tue, 05 Feb 2019 03:19:22 GMT):
@TelegramSam I think I'd suggest something like application/vnd.hl-indy.wire-message (or agent-message)
andrew.whitehead (Tue, 05 Feb 2019 03:19:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CpA5yzkeyE4zMcAYY) @TelegramSam I think I'd suggest something like application/vnd.hl-indy.wire-message
HLFPOC (Tue, 05 Feb 2019 04:15:38 GMT):
Do we have any notification/event service available in Indy SDK or at agent level which notifies the user whenever some other user requests/issues some credentials ? As I was going through the Alice-Faber college demo, each time we have to reload the browser to see the updated changes..so just thought it would be beneficial to trigger some notification or event about any new transaction.
HLFPOC (Tue, 05 Feb 2019 04:15:38 GMT):
Do we have any notification/event service available in Indy SDK or at agent level which notifies the user whenever some other user requests/issues credentials ? As I was going through the Alice-Faber college demo, each time we have to reload the browser to see the updated changes..so just thought it would be beneficial to trigger some notification or event about any new transaction.
tomislav (Tue, 05 Feb 2019 04:18:54 GMT):
Notifications are higher level concepts, not suited for solving at indy-sdk level. In your example, the python agent could implement this using websockets or similar.
HLFPOC (Tue, 05 Feb 2019 05:49:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=MXjR8jTBXA2iRShaM) @tomislav I am not able to understand how agent will get to know once creds are issued without any notification/event from the ledger or peer. Can you share any reference app/code in which this kind of functionality is implemented? Thanks !
DuckLover (Tue, 05 Feb 2019 10:00:09 GMT):
Anyone experienced the bug that in the nodejs reference agent the "accept" button in messages after an connection_request send didnt work or has to be clicked several times?
HLFPOC (Tue, 05 Feb 2019 11:24:10 GMT):
@tomislav Can you please explain more about role of steward in Indy? As per my understanding, it is a bootstrap identity which has the role of Trust Anchor and has ability to add new Trust Anchors in the network. So if i have to create my own private Indy pool and add 3 new orgs in that pool so do I have to enroll 1st Org using steward identity ? If yes, where and how to define the steward seed value and do i have to make separate agent app for steward for creating DID of my organizations ?
danielhardman (Tue, 05 Feb 2019 11:32:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=7zWD8And5R3Hca5XS) @andrew.whitehead I'm going to contradict @TelegramSam here. The mime type for wire messages is `application/ssi-agent-wire` as defined in merged HIPE 0026: https://github.com/hyperledger/indy-hipe/tree/master/text/0026-agent-file-format#agent-wire-messages-aw
danielhardman (Tue, 05 Feb 2019 11:33:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=q2AhMBr5YW2i7C6Yg) @HLFPOC You are correct that a steward has the privilege of adding trust anchors. A trustee can also add a trust anchor to the network, I think--and it is possible that a trust anchor can add another trust anchor. The truly unique/necessary thing about a steward is that it can add a node--exactly one node--to the network. In other words, you must be a steward to add a validator.
danielhardman (Tue, 05 Feb 2019 11:47:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=GmNRJkJe7hgt9BwAM) @mwherman2000 Yes, we have periodically asked ourselves this question. I think for some audiences this might be quite helpful, and for other audiences it might just muddy the waters. The notion of a connection in A2A maps approximately to layer 5 (session). A2A wire messages maps to layer 6 (presentation). Agent plaintext is layer 7 (application)--but so is our concept of protocols (unless protocols are a missing layer 8).
A2A calls everything below layer 5 "transport", which is a simplification of OSI's layers, but not an incorrect one in that OSI only requires each layer of abstraction to understand the layer immediately beneath it. The wikipedia article about OSI has a very nice table for layer 4 (transport) that explains why A2A (which is transport-agnostic) cannot assume duplex communication pipes with reliable delivery.
Some concepts/terminology from OSI are not going to help us (e.g., "PDU")--even though they are present in our system, adopting the terms just makes the conceptual landscape denser.
I wonder if a one-page write-up of this topic would be valuable--either as an update to our wire HIPE or as a link referenced in it.
danielhardman (Tue, 05 Feb 2019 11:47:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=GmNRJkJe7hgt9BwAM) @mwherman2000 Yes, we have periodically asked ourselves this question. I think for some audiences this might be quite helpful, and for other audiences it might just muddy the waters. The notion of a connection in A2A maps approximately to layer 5 (session). A2A wire messages maps to layer 6 (presentation). Agent plaintext is layer 7 (application)--but so is our concept of protocols (unless protocols are a missing layer 8 ).
A2A calls everything below layer 5 "transport", which is a simplification of OSI's layers, but not an incorrect one in that OSI only requires each layer of abstraction to understand the layer immediately beneath it. The wikipedia article about OSI has a very nice table for layer 4 (transport) that explains why A2A (which is transport-agnostic) cannot assume duplex communication pipes with reliable delivery.
Some concepts/terminology from OSI are not going to help us (e.g., "PDU")--even though they are present in our system, adopting the terms just makes the conceptual landscape denser.
I wonder if a one-page write-up of this topic would be valuable--either as an update to our wire HIPE or as a link referenced in it.
danielhardman (Tue, 05 Feb 2019 11:55:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ga83MXwmGEKyQYWsd) @HLFPOC @HLFPOC I don't know the answer to your question, but I know several mobile developers who have wrestled with this question in one way or another. I will DM you their contact info.
TelegramSam (Tue, 05 Feb 2019 13:39:15 GMT):
@HLFPOC clear examples are on their way. They will use messaging between peers, and between an agent and the web administrative console (which is also a static agent) to provide proactive notification.
xnopre (Tue, 05 Feb 2019 15:23:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=a3pkH3rxfdhubsai3) @tomislav @tomislav @HLFPOC Unless I'm mistaken, NodeJS Wrapper for SDK is using a native library to bind JS code to `libindy` library, so I think NodeJs cannot be a solution for mobile apps.
@tomislav Thanks for the link to `sovrin-connector-preview`, this can be a good resource !
xnopre (Tue, 05 Feb 2019 15:23:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=a3pkH3rxfdhubsai3) @tomislav @HLFPOC Unless I'm mistaken, NodeJS Wrapper for SDK is using a native library to bind JS code to `libindy` library, so I think NodeJs cannot be a solution for mobile apps.
@tomislav Thanks for the link to `sovrin-connector-preview`, this can be a good resource !
xnopre (Tue, 05 Feb 2019 15:23:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=a3pkH3rxfdhubsai3) @tomislav @HLFPOC Unless I'm mistaken, NodeJS Wrapper for SDK is using a native library to bind JS code to `libindy` library, so I think NodeJs cannot be a solution for mobile apps.
@tomislav Thanks for the link to `sovrin-connector-preview`, this can be a good resource !
xnopre (Tue, 05 Feb 2019 15:23:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=a3pkH3rxfdhubsai3) @tomislav @HLFPOC Unless I'm mistaken, NodeJS Wrapper for SDK is using a native library to bind JS code to `libindy` library, so I think NodeJs cannot be a solution for mobile apps.
@tomislav Thanks for the link to `sovrin-connector-preview`, this can be a good resource !
xnopre (Tue, 05 Feb 2019 15:25:19 GMT):
@danielhardman I'm interested too to have contact with mobile developers who have wrestled with this question :-) Thanks
HLFPOC (Tue, 05 Feb 2019 15:33:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=n3eoJo3R7bGoGxnen) @TelegramSam Great! Any tentative timelines for releasing these samples ?
tomislav (Tue, 05 Feb 2019 19:46:01 GMT):
@xnopre You're right, can't use nodejs directly. Perhaps https://github.com/janeasystems/nodejs-mobile-cordova can be leveraged. It provides access to nodejs runtime using standard cordova bridge, while nodejs has access to the native libraries. May be worth a shot for those looking in cross platform options.
TelegramSam (Tue, 05 Feb 2019 21:15:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oX7ifJHDR4g3PiBk3) @HLFPOC Not as soon as we'd like, but I expect the development of credential exchange message families to be the primary focus during March.
xnopre (Wed, 06 Feb 2019 08:37:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=6nYbWg7oWE5bkRXGJ) @tomislav Very interesting plugin, which seems to be able to manage native modules, perhaps a solution ;-)
misaelssantos (Wed, 06 Feb 2019 12:49:40 GMT):
Guys,
What's the best approach to get published credential definition IDs from another agent?
The scenario is one agent trying to discover the public credential definitions from another DID (agent).
DavidP (Wed, 06 Feb 2019 12:58:45 GMT):
Hi! I was working on Sovrin Test Network. I got a trust anchor created by Sovrin support team and I can store in the ledger schemas by this trust anchor. But if I create a new trust anchor as from the old one, this new trust anchor is not able to store schemas in the ledger. Does someone know why it could be? or what is it happening?
DavidP (Wed, 06 Feb 2019 12:58:57 GMT):
thanks!!
DavidP (Wed, 06 Feb 2019 13:00:40 GMT):
As a clarification, this is not happening for DIDs, is only for schemas
xnopre (Wed, 06 Feb 2019 13:27:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=yiXpjfvSYm3AdbEBc) @misaelssantos I think this has to be out of ledger and out of indy, for example, the actor creating schema and cred-def can expose its "catalog" in an HTTP API. Am I right (other guys) ?
xnopre (Wed, 06 Feb 2019 13:29:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oXa3erBHwq5235ThC) @DavidP 36 If I good understood, you have a DID with "trust anchor" role, created by Sovrin support on TestNet, OK. How do you "create a new trust anchor" ? The right way is to create a new DID/key, and only a "steward" can give to this new DID the "trust anchor" role.
xnopre (Wed, 06 Feb 2019 13:29:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oXa3erBHwq5235ThC) @David.Yan If I good understood, you have a DID with "trust anchor" role, created by Sovrin support on TestNet, OK. How do you "create a new trust anchor" ? The right way is to create a new DID/key, and only a "steward" can give to this new DID the "trust anchor" role.
xnopre (Wed, 06 Feb 2019 13:29:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oXa3erBHwq5235ThC) @DavidP 36 If I good understood, you have a DID with "trust anchor" role, created by Sovrin support on TestNet, OK. How do you "create a new trust anchor" ? The right way is to create a new DID/key, and only a "steward" can give to this new DID the "trust anchor" role.
xnopre (Wed, 06 Feb 2019 13:29:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oXa3erBHwq5235ThC) @DavidP 36 If I good understood, you have a DID with "trust anchor" role, created by Sovrin support on TestNet, OK. How do you "create a new trust anchor" ? The right way is to create a new DID/key, and only a "steward" can give to this new DID the "trust anchor" role.
(PS : try to change your pseudo, because with space in your pseudo, we cannot notify you...)
xnopre (Wed, 06 Feb 2019 14:22:46 GMT):
Hi all. I'm trying to have a good large vision on "agent", but I don't really understand and I need some top level informations.
I have read some "hipes" in https://github.com/hyperledger/indy-hipe/tree/master/text.
I have read this doc (https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#heading=h.ody6evg9dhq7) but the last modification was the septembre 7, 2018.
I try to follow the exchanges in this channel, but I don't understand where are the discussions.
I have contributed dockerinzing `indy-agent` and ran it (https://github.com/hyperledger/indy-agent/pull/59).
I have dockerized (I will share it in a PR) the VCX demo, using the `dummy-cloud-agent`.
But even though, I'm lost... :confused:
Questions : Where is the project ? What is the roadmap ? Is there something I can use now, "out of the box" (`indy-agent`, `indy-sdk/vcx/dummy-cloud-agent`, ...), or do I have to implement my own agent ? What is the role of a cloud agent, just to transmit messages between actors, or also storing some data ? I saw some informations for "message format" and "A2A communication", but where are we now, is it finished or still in discussion ? ...
Sorry for as much questions, but I need help to understand... Thanks for some answers for some points :-)
DavidP (Wed, 06 Feb 2019 14:45:54 GMT):
Thanks @xnopre
In the Sovrin Trust Framework, I found:
Trust Anchor. An Identity Owner who may serve as a starting point in the Sovrin Web of Trust.
A Trust Anchor has two unique privileges:
1) to add new Identity Owners to the Sovrin Network, and
2) to issue Trust Anchor Invitations.
So I understood that a Trust Anchor could add new Trust Anchors.
I was trying:
let VerinymDIDRequest = await indy.buildNymRequest('
xnopre (Wed, 06 Feb 2019 15:09:21 GMT):
In my understand, yes, only stewards can set "trust anchor" role. Anyone to confirm or not ?
But you already got a trust anchor created by Sovrin support team, no ?
jakubkoci (Wed, 06 Feb 2019 15:16:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=AWivbJHJNNh7KyTK8) @xnopre Wouldn't be this resource https://github.com/sovrin-foundation/connector-app better than `sovrin-connector-preview`? I think it's the place where all to mobile app open-source work is happening right now.
TelegramSam (Wed, 06 Feb 2019 15:20:29 GMT):
Merged PR into indy-agent python code from @dbluhm. The indy-sdk based pack and unpack code previously in a branch is now in master. This uses the now released indy-sdk 1.8 and associated python wrapper.
Be sure to update the new libraries as noted in the readme, or the code will not run.
TelegramSam (Wed, 06 Feb 2019 15:23:52 GMT):
@xnopre I'll address the questions you raise, but I should mention the value of attending the Indy Agent call every week on Wed. to help keep current with the latest on what the community is working on. We try and update docs and things as improvements are made.
DavidP (Wed, 06 Feb 2019 15:25:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=gTrCdHcgcmgMX35zg) @xnopre @xnopre yes, I have one trust anchor created by support team, but for my experiment I need more. Thanks!
nanspro (Wed, 06 Feb 2019 15:27:31 GMT):
Has joined the channel.
swcurran (Wed, 06 Feb 2019 15:38:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=b6mTfgTWvXdQQrda8) @xnopre Ah, the big questions! :-). To put it simply, all the building blocks are in place and the higher level pieces are being built. The underlying ledger and SDK are in place, work and have even been used in production. You can build agents, and connect them together, establish connections, issue, hold, provie and revoke credentials, and the crypto is in place.
The current phase of structuring the pieces so that each implementation will work together, and will do so in a privacy-preserving way. Getting your two agents to talk is easy - getting all implementations to work is harder.
And it is an open source project, so people are building both what the community needs and what they need.
The upcoming connectathon is a key milestone where we hope the different implementations really come together.
Hope that helps.
swcurran (Wed, 06 Feb 2019 15:38:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=b6mTfgTWvXdQQrda8) @xnopre Ah, the big questions! :-). To put it simply, all the building blocks are in place and the higher level pieces are being built. The underlying ledger and SDK are in place, work and have even been used in production. You can build agents, and connect them together, establish connections, issue, hold, prove and revoke credentials, and the crypto is in place.
The current phase of structuring the pieces so that each implementation will work together, and will do so in a privacy-preserving way. Getting your two agents to talk is easy - getting all implementations to work is harder.
And it is an open source project, so people are building both what the community needs and what they need.
The upcoming connectathon is a key milestone where we hope the different implementations really come together.
Hope that helps.
swcurran (Wed, 06 Feb 2019 15:38:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=b6mTfgTWvXdQQrda8) @xnopre Ah, the big questions! :-). To put it simply, all the building blocks are in place and the higher level pieces are being built. The underlying ledger and SDK are in place, work and have even been used in production. You can build agents, and connect them together, establish connections, issue, hold, prove and revoke credentials, and the crypto is in place.
The current phase of structuring the pieces so that each implementation will work together, and will do so in a privacy-preserving way. Getting your two agents to talk is easy - getting all implementations to work together is harder.
And it is an open source project, so people are building both what the community needs and what they need.
The upcoming connectathon is a key milestone where we hope the different implementations really come together.
Hope that helps.
jakubkoci (Wed, 06 Feb 2019 15:55:35 GMT):
Is an agent call happening today? If so, where can I find the link to connect? I got the link via hyperledger mailing list previously, but it's a while from the last info e-mail about it.
TelegramSam (Wed, 06 Feb 2019 15:55:50 GMT):
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit#
TelegramSam (Wed, 06 Feb 2019 15:56:00 GMT):
Perpetual meeting notes, with call link and time at the top
jakubkoci (Wed, 06 Feb 2019 15:56:27 GMT):
Oh, nice, thanks :thumbup:
danielhardman (Wed, 06 Feb 2019 18:38:59 GMT):
@xnopre Have you already seen this HIPE, which is an agent explainer? https://github.com/hyperledger/indy-hipe/blob/31df09b3949021d790ebc364d7da1b9347821d87/text/0002-agents/README.md
TelegramSam (Wed, 06 Feb 2019 19:49:59 GMT):
Indy Agent call starting in 10 minutes. Link to notes doc, with call link and details at the top: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
ThiagoFontes (Wed, 06 Feb 2019 23:50:24 GMT):
Has joined the channel.
DuckLover (Thu, 07 Feb 2019 01:10:41 GMT):
Does the reference agent in nodejs support proofRequests from several Credentials?
danielhardman (Thu, 07 Feb 2019 03:30:09 GMT):
ALL: I am second-guessing our notion of having a DID reference as a way to identify message types. We need a way to identify something that's immutable--but we already have that with github commit hashes. And our HIPEs are github-centric. I'm wondering of the type of a message ought to be something like: https://github.com/hyperledger/indy-hipe/blob/6bb006e19836aa42086cd8e48d089bb847f2b31b/text/acks#1.0/ack
@drummondreed: is there any compelling reason why the URI that identifies a message family needs to be DID-based?
dbluhm (Thu, 07 Feb 2019 03:47:46 GMT):
Submitted a PR to indy-agent with significant improvements to selection of tested features in the agent test-suite. Included in this PR are also detailed instructions on writing tests and the tools available to assist in writing tests as well as instructions on defining "features."
PR: https://github.com/hyperledger/indy-agent/pull/64
Test Suite readme from PR: https://github.com/dbluhm/indy-agent/tree/test-suite-collection/test-suite
Test Suite HIPE: https://github.com/hyperledger/indy-hipe/tree/master/text/0016-agent-test-suite-v1
andrew.whitehead (Thu, 07 Feb 2019 03:59:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dmq2zJLosF5tmacqo) @danielhardman FYI that can be shortened to https://github.com/hyperledger/indy-hipe/tree/6bb0/text/acks#1.0/ack
HLFPOC (Thu, 07 Feb 2019 06:17:55 GMT):
I have one doubt regarding Indy Agents, from what I have learnt, it hat agents can be categorized on the basis of location (i.e.: edge or cloud). So if i have a scenario, in which I want the user(holder of creds) to have a mobile app, and interact with the network, can I go with implementing a cloud based agent rather than integrating mobile based (edge agents) in mobile ? If yes, then can you please explain if we have to create a separate agent for all the users or a common cloud based agent can handle wallets of multiple users ?
drummondreed (Thu, 07 Feb 2019 08:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dmq2zJLosF5tmacqo) @danielhardman That's a very good question. From the standpoint of pure syntax, there's not much difference. From the standpoint of immutability, let me ask a simple question: which do you think is going to be around longer: GitHub or Sovrin? Persistent identifiers are all about the persistent guarantees (or lack thereof). But from a practical perspective (e.g., our lifetimes), either could work. (I personally lean towards the elegance of using DIDs. Also, I'm preparing a proposal that @nage requested for DID syntax to address a digital object permanently stored on a ledger that is NOT a DID document, but rather a "unit of semantics" as he puts it (or he might have said "unit of language").
xnopre (Thu, 07 Feb 2019 08:49:24 GMT):
@DavidP Why do you not "play" with a local sovrin network ? There are many example ot run 4-nodes network, and generally, you can create a DID with seed `000000000000000000000000Steward1` which has steward role, i.e. can give "trust anchor" role to other DID. You can also do what you want ;-)
xnopre (Thu, 07 Feb 2019 10:45:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oB7k6dgBEHT32pncD) Thank you for the precision :-)
xnopre (Thu, 07 Feb 2019 10:45:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=oB7k6dgBEHT32pncD) @jakubkoci Thank you for the precision :-)
xnopre (Thu, 07 Feb 2019 10:47:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=SXKPuJK5rF8noddmp) @danielhardman Thank you for the link, I'm going to read this page that I had not seen yet :-)
xnopre (Thu, 07 Feb 2019 10:52:02 GMT):
@swcurran Thank you for your answers !
> You can build agents, and connect them together [...]
> Getting your two agents to talk is easy
Do you talk about "edge" agent or "cloud" agent ? I have developped a POC with 3 actors, this is edge agents if I have good understood. But my current need is to best understand what about "cloud" agents...
> The upcoming connectathon[...]
What about this ? Can you give me more informations (when, where, and how to get "results") ? Thanks :-)
xnopre (Thu, 07 Feb 2019 10:52:02 GMT):
@swcurran Thank you for your answers !
> You can build agents, and connect them together [...]
> Getting your two agents to talk is easy
Do you talk about "edge" agent or "cloud" agent ? I have developped a POC with 3 actors, this is edge agents if I have good understood. But my current need is to best understand what about "cloud" agents...
Thanks :-)
HLFPOC (Thu, 07 Feb 2019 12:23:37 GMT):
HI Team, I am trying to run Indy nodejs agent (https://github.com/hyperledger/indy-agent/tree/master/nodejs) , but after running the first command (docker-compose build), i am getting below error : /bin/sh: 1: npm: not found
ERROR: Service 'government' failed to build: The command '/bin/sh -c npm install' returned a non-zero code: 127
I checked the docker compose file and npm install is not present in the government service container, and checked docker images, nodejs_pool is created. Can anyone help in solving this issue ?
HLFPOC (Thu, 07 Feb 2019 12:23:37 GMT):
HI Team, I am trying to run Indy nodejs agent (https://github.com/hyperledger/indy-agent/tree/master/nodejs) , but after running the first command (docker-compose build), i am getting below error : /bin/sh: 1: npm: not found
ERROR: Service 'government' failed to build: The command '/bin/sh -c npm install' returned a non-zero code: 127
I checked the docker compose file and npm install command is not present in the government service container, and checked docker images, nodejs_pool is created. Can anyone help in solving this issue ?
swcurran (Thu, 07 Feb 2019 16:24:16 GMT):
@HLFPOC - npm is called in the Dockerfile in that folder. However, it should have been installed in the earlier part of the Dockerfile. Doesn't help (I'll try to run it later) but that's where the npm reference is coming from.
swcurran (Thu, 07 Feb 2019 16:36:55 GMT):
@HLFPOC Just ran `docker-compose build` for the nodejs agent and all worked fine. Docker is ususally pretty consistent on things like that. DM me with a little more details on system, commands run, and output.
TelegramSam (Thu, 07 Feb 2019 20:15:48 GMT):
Updated BasicMessage HIPE to include a minor localization include. https://github.com/hyperledger/indy-hipe/blob/7df770e4cb3163c1e97b224387fed320bf7d9013/text/basic-message/README.md
nhelmy (Thu, 07 Feb 2019 20:49:25 GMT):
drive
TelegramSam (Thu, 07 Feb 2019 21:09:52 GMT):
Recording of yesterday's Indy Agent call: https://drive.google.com/drive/u/0/folders/1hRCOQe1Xmm7i6Nqdbky5TnydrkuH4klH
xnopre (Fri, 08 Feb 2019 09:13:58 GMT):
@HLFPOC I just tried, after checked out the repo, it works for me. Try `docker-compose build --no-cache`, perhaps you have something specific in your Docker cache... cc @swcurran
xnopre (Fri, 08 Feb 2019 09:13:58 GMT):
@HLFPOC I just tried, after checked out the repo, it works for me. Try `docker-compose build --no-cache`, perhaps you have something specific in your Docker cache... Otherwise, can you post your command and the output, so we can see when and where the error occured... cc @swcurran
HLFPOC (Fri, 08 Feb 2019 09:57:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=GsKGtgJdrQJmpxR98) @xnopre Thanks , It is now running for me after executing `docker-compose build --no-cache` .
DuckLover (Fri, 08 Feb 2019 11:48:23 GMT):
Hello,
i currently looking at the reference agent demo where Faber creates and sends the Transcript to Alice. Why does the demo not include a form where the values for the credentials are typed in? Is there a idea behind? Something like that it is better to access those data from a local database or maybe that in the future all values could be pulled from other credentials?
xnopre (Fri, 08 Feb 2019 13:29:52 GMT):
@DuckLover No answer for your question, but which demo (language) are you looking for ? For information, the most relevant demo is the python demo, that is very different than NodeJs demo... ;-)
DuckLover (Fri, 08 Feb 2019 13:57:49 GMT):
I am talking about this demo: https://www.youtube.com/watch?v=9WZxlrGMA3s . It should be nodejs
xnopre (Fri, 08 Feb 2019 14:41:49 GMT):
@DuckLover Yes, this is the NodeJs demo that seems to be no more up-to-date (last modified 6 months ago), the current "good" reference is Python demo.
Anyone to confirm ?
DuckLover (Fri, 08 Feb 2019 15:29:11 GMT):
yeah sadly i have to work with this. Maybe someone know an anwser to my previous question anyway
TelegramSam (Fri, 08 Feb 2019 16:36:46 GMT):
Updated Connection Protocol HIPE based on last agent call changes: https://github.com/hyperledger/indy-hipe/blob/aa5fb2431964f84926af5a51d8e4dd9b6342482e/text/connection-protocol/README.md
TelegramSam (Fri, 08 Feb 2019 16:40:25 GMT):
@DuckLover @xnopre The Node Agent was early work that did a good job demonstrating a full set of credential behaviors, but was built prior to establishing standard protocols for the agent interactions.
The Python Agent is newer work and the closest to the current established (and proposed) standards, but currently lacks the depth of credential features of the Node Agent.
This is not ideal, but we are pushing as fast as we can. (Community contributions very welcome.) We expect to have credential features in Python within the next 2 months.
swcurran (Fri, 08 Feb 2019 18:28:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dcDa7drZXoMq2AwBD) @DuckLover It's a short cut for the demo. Absolutely, in a real world system, there would be a database behind the agent, and an api call made to query that backend system and get the values to insert into the credential.
tplooker (Fri, 08 Feb 2019 20:11:22 GMT):
@TelegramSam I remember a while back when we were talking about cross domain messaging on a call with @swcurran you said that the term domain was being used in another context outside of that defined in the cross domain messaging HIPE? Reason I ask is we are currently reviewing/rewriting these HIPE's and just wanted to clarify the nomenclature that should be used? The current definition as it stands is 'Domain - a set of Agents collaborating on behalf of an Identity' this gives rise to terminology such as a 'Domain Endpoint agent'. Anyone else have an opinion on this nomenclature?
danielhardman (Fri, 08 Feb 2019 21:48:46 GMT):
All: I've been thinking about how to make async request~reply patterns work with agents over HTTP. I put my thoughts in a doc and may move them into a HIPE at some point. Wanted to get early reaction, particularly from @swcurran @TelegramSam @tplooker @kdenhartog . https://docs.google.com/document/d/1JqltitoFh7Kh5neZFNw2eBK807PjWd4jaUhqCGH-LTo/edit#
danielhardman (Fri, 08 Feb 2019 21:50:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dQaJcJwPDznPaGDkA) @tplooker The official term is "sovereign domain", and "domain" is an acceptable short form if the context makes it clear. It is defined in the Sovrin Glossary, at https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.pufsrf9ucjvv, and in the SSI Notation HIPE, here: https://github.com/hyperledger/indy-hipe/tree/master/text/0014-ssi-notation#identity-owners
tplooker (Fri, 08 Feb 2019 22:08:26 GMT):
@danielhardman interesting, are you suggesting we use this outlined convention in place of just relying on threading and outbound channels? i.e a connection request as an HTTP POST just triggers 202 Accepted and in the background triggers an A2A connection response on a new HTTP POST to the resolved connections endpoint?
tplooker (Fri, 08 Feb 2019 22:11:59 GMT):
The above is how we are doing it at present
tplooker (Fri, 08 Feb 2019 22:11:59 GMT):
The above is how we are doing it at present in agent framework
tplooker (Fri, 08 Feb 2019 22:12:37 GMT):
We dont put anything in the body of an http response
danielhardman (Fri, 08 Feb 2019 22:32:01 GMT):
@tplooker If you are doing it with the new HTTP POST the other direction, then you are doing it the "right" way. That's the way I was hoping people were doing it for the connectathon.
The benefit of this way is that it doesn't require a web server on both sides. Many agents won't have the ability to listen except over a channel they open. We can explore that issue more deeply after the connectathon.
danielhardman (Fri, 08 Feb 2019 22:32:01 GMT):
@tplooker If you are doing it with the new HTTP POST the other direction, then you are doing it the "right" way. That's the way I was hoping people were doing it for the connectathon.
The benefit of this alternative way is that it doesn't require a web server on both sides. Many agents won't have the ability to listen except over a channel they open. We can explore that issue more deeply after the connectathon.
tplooker (Fri, 08 Feb 2019 22:36:26 GMT):
@danielhardman I totally agree and hence why I think your proposal for duplexed communication is important, many agents wont have web servers as you pointed out namely mobile edge agents that even have transient connectivity. Our thinking was in the simplest case to have a mobile edge agents endpoint resolve an cloud hosted inbox service that the mobile edge agent can poll to resolve any un-read messages.
tplooker (Fri, 08 Feb 2019 22:38:46 GMT):
The other thing to point out with the above proposal is what happens when a mediator is involved in the sending of a message, where does the resolution of the response originate, does the mediator perform the poll or relay the whole http response of the original request back to the originator?
danielhardman (Fri, 08 Feb 2019 22:52:47 GMT):
Doing duplex through a mediator is going to be tricky. I think it can be done, but not without some careful design and some real implementation effort.
If we standardized a feature like the one I outlined in the google doc, then perhaps all agencies would implement it. This might allow duplex through agencies, which would provide a lot of value. But whether other mediators like routing agents also support it would not be guaranteed, so there might still be many cases where it breaks down.
tplooker (Fri, 08 Feb 2019 22:59:14 GMT):
Agreed the implementation could definitely be very complex and requires alot of discussion, Im very keen to discuss this further at the connectathon though and gauge how we as a community assess this functionality as a priority.
jljordan_bcgov (Mon, 11 Feb 2019 01:19:09 GMT):
```Four key ideas guided Kahn’s thinking and the subsequent development of the networking protocols that were to become the bedrock of the Internet:
• Each distinct network would have to stand on its own and no internal changes could be required of any such network to connect it to the Internet.
• Communications would be on a best effort basis. If a packet didn't make it to the final destination, it would shortly be retransmitted from the source.
• Black boxes would be used to connect the networks (these would later be called gateways and routers). There would be no information retained by the gateways about the individual flows of packets passing through them, thereby keeping them simple and avoiding complicated adaptation and recovery from various failure modes.
• There would be no global control at the operations level.```
(Leiner et al., 1998)
jljordan_bcgov (Mon, 11 Feb 2019 01:19:43 GMT):
Leiner, B. M., Cerf, V. G., Clark, D. D., Kahn, R. E., Kleinrock, L., Lynch, D. C., Postel, J.,
Roberts, L. G., & Wolff, S. (1998, 20 Feb 98). A Brief History of the Internet (3.1), [Web Document]. Internet Society. Available: http://www.isoc.org/internet/history/brief.html
jljordan_bcgov (Mon, 11 Feb 2019 01:20:11 GMT):
Look like some familiar concepts? :)
drummondreed (Mon, 11 Feb 2019 06:55:57 GMT):
John, that just rocks. Thank you for reminding all of us of what we are actually developing. As Phil Windley puts it: "the Internet for identity".
mwherman2000 (Mon, 11 Feb 2019 15:10:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=22SnQXXPeWCe4mSxW) @drummondreed I hate being the dissenting voice all of the time but "the Internet for identity" doesn't make any sense. At best, it's "Identity for the Internet" but likely more appropriate to say "Internet for the World Wide Web".
Digital Identity/SSI is built on top of the Internet. The Internet isn't changing. It's not a new "Internet".
Wikipedia: The Internet (contraction of interconnected network) is the global system of interconnected computer networks that use the Internet protocol suite (TCP/IP) to link devices worldwide.
Quotes like the above are confuding to those who don't understand these terms.
mwherman2000 (Mon, 11 Feb 2019 15:15:54 GMT):
The only (recent) change to the Internet is when it changed from IPv4 to include IPv6.
mwherman2000 (Mon, 11 Feb 2019 15:15:54 GMT):
The only (recent, significant) change to the Internet is when it changed from IPv4 to include IPv6.
xnopre (Mon, 11 Feb 2019 16:49:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=i9kEf3TbJY9stHkBa) @TelegramSam @TelegramSam Thanks for precisions :-) . Can you detail what is missing for credential features in Python demo ?
xnopre (Mon, 11 Feb 2019 16:56:35 GMT):
Hi all :-) . These days, I have read many HIPEs (1) trying to understand and get a vision, to be able to imagine the "good" architecture for our application. I have many times seen this picture (https://raw.githubusercontent.com/hyperledger/indy-hipe/master/text/0023-diddoc-conventions/domains.jpg). When Alice wants to send a message to Bob, I don't really understand the path of this message throw agents, the sequence of hops between agents, with which encryption or not, which message type ("forward" or simple relay), ... And studying this picture, and HIPEs read, I don't really understand what is the role of "domain endpoint". Can someone give me more explanation ? Or where can I find schema and/or explanations ? Thanks
(1) Thanks for the links to @danielhardman , @TelegramSam , @swcurran , and others... :-)
tomislav (Mon, 11 Feb 2019 18:44:51 GMT):
Would this be a correct way to represent indy verkey in JWK format?
```
new JWK([
'kty' => 'OKP',
'crv' => 'Ed25519',
'x' => '11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo',
])
```
Assuming `x` is a byte array of the base58 encoded verkey.
swcurran (Mon, 11 Feb 2019 19:28:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=w4NRiERjTzWK2fNcx) @xnopre
Here's an attempt to provide an overview of why the flow might be as we show it in that picture, starting from Bob's side:
- Bob's phones are intermittently online, and he needs a permanent location (agent) to receive and hold messages for him - hence "3". "3" and "6" could be merged - they are just playing different roles - a dumb relay (3) for his mobile devices and an intelligent agent (6) that Bob accesses directly.
- The "domain endpoint" is for privacy. If Bob had a known, published, just-for-Bob endpoint, any messages going across the Internet to that endpoint would be known to be for Bob. Instead, messages for many entities like Bob go to the same endpoint and are then routed based on their verkey. Since Bob and all the entities like Bob have many verkeys for their different relationships, monitoring the traffic into the endpoint does not expose to whom the messages are for. This is "hiding in a crowd".
- The "domain endpoint" does have to know where to send the incoming message based on the Forward message's "to" field. That is either the destination DID (as in the existing "DIDDOC Conventions" HIPE) or the verkey of the embedded message (as things seem to be moving). Either way - Alice's agent that is to receive the message has to tell the domain endpoint - "hey, when you see this ID - send it to my agent at
rekmarks (Mon, 11 Feb 2019 23:21:21 GMT):
Has joined the channel.
TelegramSam (Tue, 12 Feb 2019 02:04:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cJ4KrtDCtZaqneSqi) @danielhardman I've added a similar, but alternative approach to the doc as a suggestion.
tplooker (Tue, 12 Feb 2019 05:36:21 GMT):
Hey guys a random thought, not sure if anyone is thinking along the same lines but it just dawned on me, with all this work going on by nathan to restructure the hyperledger projects perhaps the A2A protocol isn't actually A2A maybe we need to elevate further and say this is really just a DID messaging protocol? After all what constraints are we imposing on this protocol other than dids?
tplooker (Tue, 12 Feb 2019 05:39:33 GMT):
After all now we are going to use a service endpoint definition to express how to send messages (update to the did doc hipe coming soon) that's all we need to describe communication?
ashishchainworks (Tue, 12 Feb 2019 11:02:35 GMT):
I was reading a whitepaper from Sovrin: What goes on the Ledger; It mentions that pairwise pseudonyms don't go to the ledger. I agree with this approach that these should not go to ledger. However, in Getting Started story walk thru, it seems Faber College and Steward both are calling NYM for pairwise pseudonyms. Can any pls clarify where I am getting it wrong?
jljordan_bcgov (Tue, 12 Feb 2019 13:42:14 GMT):
Pairwise DIDs is a feature being built into the emerging messaging protocols and agents being discussed in this forum. It’s a capability that was added after the getting started demo @ashishchainworks [ ](https://chat.hyperledger.org/channel/indy-agent?msg=upFZpf9QkzRPnmnov)
jljordan_bcgov (Tue, 12 Feb 2019 13:44:34 GMT):
I like the general idea here ... I also think that Indy is selling itself very very short by marketing itself as an “identity” solution. It’s really a generalized peer to peer secure and private data exchange platform @tplooker [ ](https://chat.hyperledger.org/channel/indy-agent?msg=93a45572-9c05-43ba-b7ab-8da5be726e03)
TelegramSam (Tue, 12 Feb 2019 14:56:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=93a45572-9c05-43ba-b7ab-8da5be726e03) @tplooker It is definately `*a* DID messaging protocol`, but we can't say it's *the* DID messaging protocol. Not yet, anyway. :sunglasses:
tomislav (Tue, 12 Feb 2019 15:49:36 GMT):
And that's how TSL 2.0 came to be, kids.
tomislav (Tue, 12 Feb 2019 15:49:36 GMT):
And that's how TSL 2.0 came to be, kids. ** closes history book **
tomislav (Tue, 12 Feb 2019 15:49:36 GMT):
And that's how TSL 2.0 came to be, kids. *** closes history book ***
tomislav (Tue, 12 Feb 2019 15:49:36 GMT):
And that's how TSL 2.0 came to be, kids.
*** closes history book ***
tplooker (Tue, 12 Feb 2019 16:12:49 GMT):
I agree, I think for separations sake we need to coin new terminology for the messaging protocol its self that sits outside of indy and agents nonmenclature ie not just A2A protocol. @jljordan_bcgov you are right I think one of the goals of the project restructure should be to try and shed more light on this aspect.
tplooker (Tue, 12 Feb 2019 16:12:51 GMT):
I agree, I think for separations sake we need to coin new terminology for the messaging protocol its self that sits outside of indy and agents nonmenclature ie not just A2A protocol. @jljordan_bcgov you are right I think one of the goals of the project restructure should be to try and shed more light on this aspect.
TelegramSam (Tue, 12 Feb 2019 22:48:16 GMT):
Several new merged PRs to the indy-agent repo. Includes connection protocol (with signed responses) and test suite updates with bidirectional connection protocol testing.
tplooker (Wed, 13 Feb 2019 06:20:46 GMT):
PR to update did-doc conventions https://github.com/hyperledger/indy-hipe/pull/92
andrew.whitehead (Wed, 13 Feb 2019 07:11:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=gipzyTJBGvPqbWoXo) @tplooker Looks like routingKeys was renamed to mediatorKeys? But only in some places. The connection spec uses routing_keys so it would be nice for them to be consistent whatever the decision. Also *Preparation :)
danielhardman (Wed, 13 Feb 2019 08:46:03 GMT):
@tplooker and @TelegramSam I don't understand why we're thinking this isn't agent protocol but rather DID messaging protocol. Agents, not DIDs, are doing the messaging, and agents, not DIDs are the eventual recipients. We don't communicate DID-to-DID, but agent-to-agent. And the protocol requires agent behaviors such as routing to make it work.
danielhardman (Wed, 13 Feb 2019 08:46:57 GMT):
@tomislav Do you mean TLS? I don't understand the parallel you're seeing.
danielhardman (Wed, 13 Feb 2019 08:48:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=upFZpf9QkzRPnmnov) @ashishchainworks This is just a difference in timing of content. The Getting Started Guide describes what is available today; the whitepaper describes the way it should work. We will eventually update the GSG to keep things off ledger.
zoltan.lux (Wed, 13 Feb 2019 12:36:14 GMT):
Has joined the channel.
TelegramSam (Wed, 13 Feb 2019 16:24:37 GMT):
Minor Connection Protocol HIPE Update - no major changes, just small clarifications. https://github.com/hyperledger/indy-hipe/blob/ac648e276dec49821068c8bf90b5091f05faddd5/text/connection-protocol/README.md
tplooker (Wed, 13 Feb 2019 17:34:27 GMT):
@andrew.whitehead thanks all fixed, @swcurran rational which I agreed with, is we have two types of routing, mediators (which the sender knows about) and relays which the sender is unaware of. To be more explicit about what the `routing keys` are for we decided to change this to mediator keys.
tomislav (Wed, 13 Feb 2019 17:45:12 GMT):
My ocd radar picked up two naming conventions used throughout the HIPES in JSON attribute names: lowerCamelCase and under_score. We should probably pick one and be consistent
swcurran (Wed, 13 Feb 2019 17:51:42 GMT):
The suggestion has been made that we stick with "_" since that is what is used in indy-sdk. That's the best argument I've heard, since that is unlikely to change. Thoughts?
tplooker (Wed, 13 Feb 2019 18:34:17 GMT):
Only reason I diverged from this in my update to the did docs conventions is that they have used lowerCamelCase
tplooker (Wed, 13 Feb 2019 18:34:17 GMT):
Only reason I diverged from this in my update to the did docs conventions is that they have used lowerCamelCase in the did spec
andrew.whitehead (Wed, 13 Feb 2019 18:36:47 GMT):
I believe the connection spec uses camel case consistently apart from 'serviceEndpoint'
TelegramSam (Wed, 13 Feb 2019 19:25:36 GMT):
`serviceEndpoint` was chosen for consistancy with the DID spec, but I struggle with the gap as well.
TelegramSam (Wed, 13 Feb 2019 19:27:06 GMT):
I still feel like `mediator_keys` is an overfit to current thinking, where `routing_keys` is still true but more likely to endure as a named concept.
kdenhartog (Wed, 13 Feb 2019 21:38:30 GMT):
As I pointed out on the zoom call today, I am no longer with Evernym, but am available and looking for positions within the community. If anyone knows of opportunities please let me know. I've also got a few resumes from some of the other people let go and would be willing to make introductions.
nbrempel (Wed, 13 Feb 2019 22:17:53 GMT):
Hey everyone, I had some thoughts around test/compliance suites after the discussion and demonstration by @dbluhm today.
I think it will be valuable to have a versioned compliance suite that can be run locally to develop against. The compliance suite could also have some sort of public agent registry to see which agents are currently aligned to which version of every spec.
Part of publishing a change to a message family specification could require adding a test suite and a version bump to the compliance suite. Then the community could see how quickly each agent implementation is keeping up with the changes.
Here is an example compliance suite and registry for XMPP server implementations to illustrate what I'm thinking of: https://compliance.conversations.im (source: https://github.com/iNPUTmice/caas)
What do you all think about modelling the Indy Agent compliance suite in this way?
dbluhm (Wed, 13 Feb 2019 22:38:03 GMT):
We've been talking for a while about having a hosted Sovrin instance of the test suite ("am-i-sovrin-yet.sovrin.org" or something, for example) and issuing credentials to certify compliance but it hasn't advanced much further than talks yet. I think it's a great idea.
TelegramSam (Wed, 13 Feb 2019 22:51:07 GMT):
Also think it's a great idea. Let's talk more at the connectathon
nbrempel (Wed, 13 Feb 2019 22:52:36 GMT):
Great! Let's talk more about it next week for sure.
TelegramSam (Wed, 13 Feb 2019 23:16:08 GMT):
Also, I don't think this depth of automated testing will be possible with [admin] message families of some sort.
nbrempel (Wed, 13 Feb 2019 23:20:19 GMT):
do you mean _without_ [admin] messages of some sort?
TelegramSam (Wed, 13 Feb 2019 23:31:56 GMT):
....yes. That's what I mean.
nbrempel (Wed, 13 Feb 2019 23:32:14 GMT):
k, thought so. In that case, I agree :)
swcurran (Thu, 14 Feb 2019 01:16:50 GMT):
I think the concept of admin messages is needed, but I don't think that the examples in the HIPE are right. They should be meta messages for setting up handling rather than triggers for specific protocols.
tomislav (Thu, 14 Feb 2019 15:08:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=BvKbdHkbPe686oZJR) I agree. `mediator_keys` is specific to a certain type of agent, while `routing_keys` more generally describes the purpose of the key, which can be used across mediators or other types of agents.
xnopre (Thu, 14 Feb 2019 15:15:19 GMT):
@swcurran
> Here's an attempt to provide an overview of why the flow might be as we show it in that picture, starting from Bob's side: [...]
Thank you for your answer !! :-)
I still have questions (sorry in advance for so many questions ;-) ) :
1/ Alice stores in the blockchain its DIDDOC associated with its DID `A.did@A:B` (specific for the relation with B) or associated with its public "offcial" DID `A.did` ?
2/ Why do the DIDDOC (https://github.com/hyperledger/indy-hipe/tree/master/text/0023-diddoc-conventions#diddoc) contain a collection of public keys and endpoints ? Why not only one for the relation `A:B` ? What are all this keys and endpoints ?
3/ In the schema (https://raw.githubusercontent.com/hyperledger/indy-hipe/master/text/0023-diddoc-conventions/domains.jpg), what is "6" ? Is there for example a WEB application (= an edge agent not on mobile but on desktop) ?
4/ To talk to Bob, what must Alice know ? I suppose `B.did@A:B`, OK. But to which agent or endpoint will she send her messages for Bob ? To the "domain endpoint" or to the "routing endpoint" (I don't understand the difference between this 2 concepts) ? Which path is right : 1->9->4 ? 1->2->9->4 ? 1->2->3->4 ? And is the path from B to A the same (inverse), or a "symmetric" path ?
5/ And where are stored the Alice's data ? Only in "1" (edge mobile agent) ? (it's actually my option) Are other agent only "relay" agent, just able to store messages and follow them when receiver is reachable ? Or are some agent more "intelligent", containing some date (credentials) and able to response to some proof request (for example) ?
Thanks for you help :-)
xnopre (Thu, 14 Feb 2019 15:15:19 GMT):
@swcurran
> [swcurran said : ] Here's an attempt to provide an overview of why the flow might be as we show it in that picture, starting from Bob's side: [...]
Thank you for your answer !! :-)
I still have questions (sorry in advance for so many questions ;-) ) :
1/ Alice stores in the blockchain its DIDDOC associated with its DID `A.did@A:B` (specific for the relation with B) or associated with its public "offcial" DID `A.did` ?
2/ Why do the DIDDOC (https://github.com/hyperledger/indy-hipe/tree/master/text/0023-diddoc-conventions#diddoc) contain a collection of public keys and endpoints ? Why not only one for the relation `A:B` ? What are all this keys and endpoints ?
3/ In the schema (https://raw.githubusercontent.com/hyperledger/indy-hipe/master/text/0023-diddoc-conventions/domains.jpg), what is "6" ? Is there for example a WEB application (= an edge agent not on mobile but on desktop) ?
4/ To talk to Bob, what must Alice know ? I suppose `B.did@A:B`, OK. But to which agent or endpoint will she send her messages for Bob ? To the "domain endpoint" or to the "routing endpoint" (I don't understand the difference between this 2 concepts) ? Which path is right : 1->9->4 ? 1->2->9->4 ? 1->2->3->4 ? And is the path from B to A the same (inverse), or a "symmetric" path ?
5/ And where are stored the Alice's data ? Only in "1" (edge mobile agent) ? (it's actually my option) Are other agent only "relay" agent, just able to store messages and follow them when receiver is reachable ? Or are some agent more "intelligent", containing some date (credentials) and able to response to some proof request (for example) ?
Thanks for you help :-)
TelegramSam (Thu, 14 Feb 2019 16:32:29 GMT):
last agent call recordings: https://drive.google.com/drive/u/1/folders/1y3dBmFLe_enXecDmIXxkOBTCN4tmbOUj
TelegramSam (Thu, 14 Feb 2019 17:52:48 GMT):
Python Ref Agent has been updated with BasicMessage HIPE support.
smithbk (Thu, 14 Feb 2019 17:59:50 GMT):
I'm trying to run the agent test-suite on macos. My `cargo build` of libindy v1.8 passed and I set both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH to my `indy-sdk/target/debug` directory. When running `pytest`, I got the following error. Any help is appreciated. ```/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py:573: in run_until_complete
return future.result()
env/lib/python3.7/site-packages/pytest_asyncio/plugin.py:78: in setup
res = await gen_obj.__anext__()
conftest.py:83: in wallet_handle
json.dumps({'key': 'test-agent'})
env/lib/python3.7/site-packages/indy/wallet.py:127: in open_wallet
open_wallet.cb)
env/lib/python3.7/site-packages/indy/libindy.py:35: in do_call
error = _get_indy_error(err)
env/lib/python3.7/site-packages/indy/libindy.py:72: in _get_indy_error
error_details = _get_error_details()
env/lib/python3.7/site-packages/indy/libindy.py:83: in _get_error_details
getattr(_cdll(), 'indy_get_current_error')(byref(error_c))
/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ctypes/__init__.py:369: in __getattr__
func = self.__getitem__(name)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
dbluhm (Thu, 14 Feb 2019 18:09:38 GMT):
Are you running the latest version of the python wrapper? You can double check by running `pip install -r requirements.txt` with your virtual environment loaded in the test-suite directory
smithbk (Thu, 14 Feb 2019 18:20:19 GMT):
Thanks for the help folks ... @dbluhm found my user error :-(
swcurran (Thu, 14 Feb 2019 21:48:30 GMT):
@xnopre - some good questions. Here's a stab at them:
> 1/ Alice stores in the blockchain its DIDDOC associated with its DID `A.did@A:B` (specific for the relation with 😎 or associated with its public "offcial" DID `A.did` ?
The expectation we are building to is that Alice will not store a DIDDoc for Bob on the blockchain. She will store it in her wallet(s), send it to Bob and he will store it in his. In the future, only issuers of credentials and entrprises that want a publicly-known DID will put their DIDDocs on the blockchain.
> 2/ Why do the DIDDOC (https://github.com/hyperledger/indy-hipe/tree/master/text/0023-diddoc-conventions#diddoc) contain a collection of public keys and endpoints ? Why not only one for the relation `A:B` ? What are all this keys and endpoints ?
The public keys are for each Agent that Bob wants Alice to know about for their relationship. We don't want Agents to share keys, so if Bob wants Alice to send messages to his different devices/agents, he will add a key for each one.
In the DID Spec, the multiple endpoints are to enable contacting the DID's Controller for different types of services In Agent-to-Agent messaging, our original plan (as seen in that HIPE) is that there would only need to be one service endpoint in the DIDDoc and the different services would be invoked by using different messages. For other reasons, that may change - we're discussing that now in the Agent Working Group.
> 3/ In the schema (https://raw.githubusercontent.com/hyperledger/indy-hipe/master/text/0023-diddoc-conventions/domains.jpg), what is "6" ? Is there for example a WEB application (= an edge agent not on mobile but on desktop) ?
"6" is intended to be an example of an agent that is in the cloud. For example, it might be used to handle messages with a default response. For example, every time a proof request for a certain credential is received, always send back a proof. There might be a Web Interface that the Bob uses to configure the rules for that Agent.
In the example, it's just to remind people that not all agents have to be mobile.
> 4/ To talk to Bob, what must Alice know ? I suppose `B.did@A:B`, OK. But to which agent or endpoint will she send her messages for Bob ? To the "domain endpoint" or to the "routing endpoint" (I don't understand the difference between this 2 concepts) ? Which path is right : 1->9->4 ? 1->2->9->4 ? 1->2->3->4 ? And is the path from B to A the same (inverse), or a "symmetric" path ?
Your question is the core of why that HIPE was written and continues to be evolved. If Bob has a bunch of agents, each with different keys and purposes how does Alice know how to encrypt the message so that Bob can respond? The HIPE you are reading only went so far in accomplishing that understanding, and it is still being evolved. Very little of this has actually been implemented, and it's in the implementation that it will solidify.
I think all the questions you are asking are covered in the HIPE, so I'm just repeating what should be there - my fault if it is not clear. We probably should DM for specific question.
Re: Domain Endpoint vs Routing Agent - the difference is the Owner of those Agents. the DE is owned by a big cloud provider - e.g. Microsoft or Agents-R-Us. The RA is owned by Bob. The DE is for many people/enterprise to use so no one can tell exactly who is receiving an incoming message. The DE's only role is to route messages to the intended RA - e.g. Bob in this case. Bob's RA would tell the DE ahead of time "Hey, if you see a message for B.did@A:B, send it to me". Since the messages are encrypted, the DE can't actually see anything about the message.
The message path is not symetrical. Each identity owner defines how they want messages (incoming and outgoing) routed in their domain.
> 5/ And where are stored the Alice's data ? Only in "1" (edge mobile agent) ? (it's actually my option) Are other agent only "relay" agent, just able to store messages and follow them when receiver is reachable ? Or are some agent more "intelligent", containing some date (credentials) and able to response to some proof request (for example) ?
The challenge with providing a simple answer to that question is people have multiple devices (phones, ipads, laptops) and they want to do things from all of the devices, and we (Agent builders) want to allow them to do that in a way that is safe and secure. We want to create protocols that make it easy for developers/companies to build agents that are secure and convenient. That's always a tradeoff, and at times that makes things pretty complex.
danielhardman (Thu, 14 Feb 2019 23:14:13 GMT):
I am feeling more and more positive about @tplooker 's suggestion that we rename "A2A" to make it less strongly tied to the notion of an agent. My earlier pushback in this channel was technical--an agent is going to be involved in making the protocol work, for sure--but I'm realizing that the political value of not using "agent" (an Indy buzzword) might be high, because there are some potential allies that need what we've built but don't want to associate themselves with Indy (which they consider a very specific blockchain). So now I'm thinking about whether we should call this communication mechanism something like "DID-to-DID communication" or "D2D" for short. This might fit naturally into the ledger-agnostic posture of the Hyperledger Envoy project that @nage has begun socializing.
stefan.vogl (Fri, 15 Feb 2019 06:24:54 GMT):
Hello, I'm rather new to the hyperledger projects. I'm working in a project, that aims to implement an identity eco system based on DIDs and Verifiable Claims / Credentials.
We would like to have the following kinds of use cases:
* Registration to an online service (maybe even login) -> prove some defined data to an online service
* Prove something at the point of sale
From an architectural point of view, we would like to have a cloud agent and agency (in the most privacy friendly way, there is) to enable users to have:
* multiple devices
* backup and recovery
* maybe mechanisms to enable some actions without user interaction
At the moment we are very unsure what protocol to use for Agent 2 Agent communication and messaging. We would like to have a code base, that we can build a prototype on and develop it into a stable production system later on. My understanding is (and that may be completely wrong), that if I use the current indy-agent and indy-sdk implementation, I will have to throw everything away, when the new Hyperledger Envoy (or whatever it will be called) is "finished". Is that correct? Or will there be an "upgrade path" to the new protocol?
Is there anything already implemented in the new protocol, that we can use for our implementation, or is this all completely theoretical?
I would very much appreciate, if you could give me some information, or point me in the right direction, because this is a critical point in our project, and we want to make the right decision.
TelegramSam (Fri, 15 Feb 2019 14:57:41 GMT):
@stefan.vogl The new Envoy project will be born out of Indy Agents, and that history will provide an upgrade path.
TelegramSam (Fri, 15 Feb 2019 14:58:33 GMT):
The protocols we are currently developing will the foundational protocols of that new agent project. If you get started here, you will have on an onramp when that project happens.
DuckLover (Fri, 15 Feb 2019 22:43:52 GMT):
Hello, if one agent creates a schema and creddef and send credential definiton to another agent. How can a third agent use this credential definiton in this proof_request? I cant find the Creddef via Tag
DuckLover (Sat, 16 Feb 2019 00:08:29 GMT):
I use the reference agent in nodejs as the base and create a schema and a creddef at the startup. The same spot the GovID is created:
```
async function issueWhsIdCredential() {
let schemaName = 'WHS-ID';
let schemaVersion = '1.0';
let signatureType = 'CL';
let whsIdSchema;
let whsIdSchemaId = `${stewardDid}:2:${schemaName}:${schemaVersion}`;
try {
whsIdSchema = await indy.issuer.getSchema(whsIdSchemaId);
} catch(e) {
[whsIdSchemaId, whsIdSchema] = await sdk.issuerCreateSchema(stewardDid, schemaName, schemaVersion, [
'name',
'hochschule',
'studiengang',
'matrikelnummer',
]);
await indy.issuer.sendSchema(await indy.pool.get(), stewardWallet, stewardDid, whsIdSchema);
whsIdSchema = await indy.issuer.getSchema(whsIdSchemaId);
}
let whsIdCredDef;
[whsIdCredDefId, whsIdCredDef] = await sdk.issuerCreateAndStoreCredentialDef(stewardWallet, stewardDid, whsIdSchema, 'WHS-ID', signatureType, '{"support_revocation": false}');
await indy.issuer.sendCredDef(await indy.pool.get(), stewardWallet, stewardDid, whsIdCredDef);
console.log("This is the whsIdCredDefId: " + whsIdCredDefId);
exports.setEndpointDidAttribute('WHS-IDCredDefId', whsIdCredDefId);
}
```
When i am trying to send a cred_offer to alice it cant find the CredDef by the Cred_Def_id even if the id is correct in the follwing function:
```
exports.sendOffer = async function (theirDid, credentialDefinitionId) {
let credOffer = await sdk.issuerCreateCredentialOffer(await indy.wallet.get(), credentialDefinitionId);
...
```
It seems like the error happens because the wallets are different but shouldnt every agent have the credDef and should find or where and how does the function search for the creddef?
tomislav (Sat, 16 Feb 2019 01:49:17 GMT):
@DuckLover A credential definition contains private key data based on the schema. When Creddef is created, the public part of it is written on the ledger. If you send the credDef to another agent, you're really sending the public part of it. A credential is issued by signing it using the definition private data. So you can't just pass around the cred def between agents. Each agent has to create definition for themselves.
When you send an offer to Alice, the next step for Alice would be to create a Credential Request from the offer and send that back. Offer -> Request (signed by Alice) -> Credential (counter signed by Issuer of offer)
DuckLover (Sat, 16 Feb 2019 02:28:44 GMT):
Ahh okay. Thanks for the explanation. So i created now a CredDef for every agent with an id thats starts with their did by using the indy.issuer.createDef function but it seems like when i send a proof_request to another agent the cred_id in the proof_request cant be used or it cant find anything to that. How do i prevent that?
DuckLover (Sat, 16 Feb 2019 02:36:18 GMT):
Why does the reference agent in nodejs sends proof_requests with cred_def_id if it cant by used and every agent has his own as i understand?
```
{
"name": "WHS-ID",
"version": "1.0",
"requested_attributes": {
"attr1_referent": {
"name": "hochschule",
"restrictions": [{"cred_def_id": "XTrEq4danDT5Z4JJtY8ZWM:3:CL:17:WID"}]
},
"attr2_referent": {
"name": "durchschnitt",
"restrictions": [{"cred_def_id": "Th7MpTaRZVRYnPiabds81Y:3:CL:15:SID"}]
},
"attr3_referent": {
"name": "studiengang",
"restrictions": [{"cred_def_id": "XTrEq4danDT5Z4JJtY8ZWM:3:CL:17:WID"}]
}
},
"requested_predicates": {}
}
```
As i understand this created proof request cannot be parsed on the receivers site without replacing the id with their cred_def_id?
tomislav (Sat, 16 Feb 2019 14:43:13 GMT):
Not every agent needs a cred_def, only the issuers of credentials. When you issue a credential to alice, she can then process proof requests with cred_def carried in the credential she received
stefan.vogl (Sat, 16 Feb 2019 18:36:51 GMT):
@TelegramSam thank you, for your answer, that helps
xnopre (Mon, 18 Feb 2019 12:31:08 GMT):
Hi all. How compatible is the "dummy cloud agent" (https://github.com/hyperledger/indy-sdk/tree/master/vcx/dummy-cloud-agent) with current idea and projects (HIPEs) for "agent" ? Is it a good idea to use it now, for my application, or is it better to develop my own new "agency" ? Thanks
dbluhm (Mon, 18 Feb 2019 14:30:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=YTgG5MzbwHdDQtePM) @xnopre Not at all compatible, unfortunately
ianco (Mon, 18 Feb 2019 17:33:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=YTgG5MzbwHdDQtePM) @xnopre The dummy cloud agent is compatible with VCX, so if you are developing using VCX then you use the dummy cloud agent
ianco (Mon, 18 Feb 2019 17:33:50 GMT):
You'd have to ask the VCX team about any future plans to be compatible with the emerging standards and HIPE's
vsadriano (Tue, 19 Feb 2019 10:28:55 GMT):
Hi! I'm running hyperledger education sample in NodeJS and it's ok! But I'm would like to run more than one user in same agent. Is it possible? (an multi user cloud agent) TKS!
vsadriano (Tue, 19 Feb 2019 10:28:55 GMT):
Hi! I'm running hyperledger education sample in NodeJS and it's ok! But I'm would like to run more than one user in same agent. Is it possible? A serveral number of wallets openning in same agent? TKS!
sklump (Tue, 19 Feb 2019 13:58:50 GMT):
Has joined the channel.
sklump (Tue, 19 Feb 2019 13:59:30 GMT):
I'm in Provo. What time does the connectathon start?
ruggero.montalto-tno (Tue, 19 Feb 2019 14:03:18 GMT):
Has joined the channel.
mboyd (Tue, 19 Feb 2019 16:00:26 GMT):
9:00am
mboyd (Tue, 19 Feb 2019 16:01:04 GMT):
Connectathon agenda: https://docs.google.com/document/d/1dfGj5yjpSHzRF6UVPv7Ld1PTFme3fsXEwpLs0_e6NGA
TelegramSam (Tue, 19 Feb 2019 16:03:56 GMT):
Morning Folks! Connectathon is getting started. The channel for that event is on the Sovrin RocketChat (chat.sovrin.org) #connectathon channel. Tune in there for deeper involvement.
ashokkj (Wed, 20 Feb 2019 02:56:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=hvajnJ8NYhFdmrqET) @tomislav In that case, Ledger also stores only the Public information of cred def issued by Trust anchor. Am I right? Then how verifier verify the Private info of Cred Def ? Do the verifier will contact the trust Anchor (Issuer) for verification of Private attributes of cred def? I want to know which are Private & public attributes in Cred Def. I guess Self attested Revealed attributes are public for sure. How about Encoded Revealed Attributes are they Public too ? I am guessing Predicates are private. Please let me know is my understanding is correct or not.
MALodder (Wed, 20 Feb 2019 03:14:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=m6iDaoWv9eY8tq4aQ) @ashokkj The ledger only stores the Public key for the issuer in the cred def. The private key and attributes are not on the ledger. The private key is kept in the issuers wallet. The attribute values are known between the issuer and the Prover. The verifier only learns revelaed attribute values from a Prover. Predicates only reveal the range of the numeric attribute like 18< x <100
MALodder (Wed, 20 Feb 2019 03:15:15 GMT):
Revealed attributes are not public but they are known by the verifier and hte prover
MALodder (Wed, 20 Feb 2019 03:15:52 GMT):
when you say private attributes in a cred def, I belive you are referring to *blinded* attributes that the issuer agrees to sign
MALodder (Wed, 20 Feb 2019 03:16:06 GMT):
without knowing their true vlaue
MALodder (Wed, 20 Feb 2019 03:16:06 GMT):
without knowing their true value
ashokkj (Wed, 20 Feb 2019 03:30:14 GMT):
Thanks for the reply Mike. from @tomislav conversation I could make out Cred Def contains Public attributes (First Name, Last Name , etc) Private attributes (Degree, experience, SSN, Address etc) . Only Public attribute would be shared between agents. My question was when Issuer creates Cred Def for User, do ledger store Public attributes of Cred Def, Cred Def ID & its public key or only Cred Def ID & its public key only ?
mwherman2000 (Wed, 20 Feb 2019 19:44:59 GMT):
Is the Indy Agent call on the regular Zoom address?
TelegramSam (Wed, 20 Feb 2019 19:45:50 GMT):
yes, regular call zoom address.
xnopre (Thu, 21 Feb 2019 10:25:11 GMT):
@dbluhm @ianco Thanks for your answers :-)
DuckLover (Thu, 21 Feb 2019 11:13:49 GMT):
Hello, i am working currently on the Reference Agent with Nodejs Wrapper and is there a way to do a benchmark test on the ledger? How long it takes to write or validate data on my current setup?
DuckLover (Thu, 21 Feb 2019 14:56:38 GMT):
or can someone provide a few diagrams on the reference agent setup or the architecture of indy-sdk?
haggs (Thu, 21 Feb 2019 15:03:00 GMT):
@DuckLover Not sure which reference agent version/codebase you're speaking about, but currently there is no connection to a ledger (suspension of disbelief, if you will). Setup outside of the Readme? I would really move over to the Python Ref Agent to get the latest and greatest protocols.
haggs (Thu, 21 Feb 2019 15:07:25 GMT):
As far as indy-sdk: @kdenhartog wrote an amazing architecture overview: https://github.com/kdenhartog/indy-sdk/blob/a2b6e19f72678f28c7930d320eb57b526aa52485/doc/design/012-libindy-architecture-overview/README.md
haggs (Thu, 21 Feb 2019 15:08:29 GMT):
https://github.com/hyperledger/indy-sdk/tree/master/docs/design/012-libindy-architecture-overview Here's the current version on master
DuckLover (Thu, 21 Feb 2019 15:10:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=hcjZQ5zgeodk2FW7o) @haggs thanks that the kind of diagrams i need.
JoshCook (Thu, 21 Feb 2019 19:31:07 GMT):
Has joined the channel.
JoshCook (Thu, 21 Feb 2019 19:34:20 GMT):
Hey everyone, i have been stuck on an issue, i am creating a indy app for my college for my final project, it will be similar to the alice and faber demo, my question is, : do i have to setup my own VON network for my college, or do i just create a regular agent, i want my college to basically be a trust anchor and be able to issue transcripts to alumni students.
emilyz5 (Thu, 21 Feb 2019 21:33:45 GMT):
Has joined the channel.
spacemandev (Thu, 21 Feb 2019 21:42:25 GMT):
Has joined the channel.
TelegramSam (Fri, 22 Feb 2019 00:07:25 GMT):
@JoshCook you don't need a VON instance in such a case. An issuer agent is just fine.
runiner (Fri, 22 Feb 2019 17:37:41 GMT):
Has joined the channel.
JoshCook (Fri, 22 Feb 2019 18:36:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=G7qHF226c9CT5wbZH) @TelegramSam awesome, thanks. Is every student that requests the credential (transcript) an agent themselves? like in the demo for instance alice is on web app at port :5000 and faber is on port :5001 (hypothetically) does this mean every person who is going to be using the web app to request credentials needs to have their own port#?
i have tested and played around with so many demos and getting started guides with indy on all aspects. Trying to figure out what indy i need (node, agent, sdk)
Thanks again
JoshCook (Fri, 22 Feb 2019 18:37:23 GMT):
i also would like to use mainly python
danielhardman (Fri, 22 Feb 2019 19:08:16 GMT):
Conversations on the topic of DID Doc support and microledgers are unfolding in several different places -- rocket.chat, slack, google docs, jira. Not all of the same people are in each place, and I didn't want to copy and paste a lot of text all over. So I put some thoughts in a doc. Please have a look, and please forward this on to other people if you think they should be aware:
https://docs.google.com/document/d/17qzu5jm2CIA32oArG4cRp7g0D_20cwUqB4sX4LIkodc/edit#
nanspro (Sat, 23 Feb 2019 02:11:30 GMT):
Has left the channel.
TelegramSam (Mon, 25 Feb 2019 16:29:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=kDioL2McxzoNwmano) @JoshCook Each entity needs their own agent. In current code, that equates to a unique port.
tplooker (Mon, 25 Feb 2019 20:19:18 GMT):
Hey @TelegramSam if there is room on this weeks call I would like to raise the concept of an ephemeral challenge protocol I have been working on?
MALodder (Tue, 26 Feb 2019 04:33:08 GMT):
@tplooker Can I take a look at that from a security/crypto perspective
tplooker (Tue, 26 Feb 2019 19:29:06 GMT):
@MALodder sure, hopefully I will have a HIPE prepared sometime this week, it is really an application level message protocol that wraps the current challenges (i,e proof requests) into a protocol that doesn't require persistent connections.
sklump (Tue, 26 Feb 2019 19:47:48 GMT):
Here's something new and puzzling:
When I try to `pip install python3-indy==1.8.1-dev-985` _(or anything more recent than 1.8.1), the result is
`...has requirement python3-indy==1.8.1-dev-985, but you'll have python3-indy 1.8.1 which is incompatible.`
Has anyone seen this and defeated it?
sklump (Tue, 26 Feb 2019 19:47:48 GMT):
Here's something new and puzzling:
When I try to `pip install python3-indy==1.8.1-dev-985` _(or anything more recent than 1.8.1)_, the result is
`...has requirement python3-indy==1.8.1-dev-985, but you'll have python3-indy 1.8.1 which is incompatible.`
Has anyone seen this and defeated it?
dbluhm (Tue, 26 Feb 2019 20:13:44 GMT):
@sklump I've just pointed at the github repository before for a specific commit or branch
dbluhm (Tue, 26 Feb 2019 20:13:53 GMT):
pip handles that pretty well
tomislav (Tue, 26 Feb 2019 20:14:27 GMT):
@tplooker @MALodder Would be great to include some specifics on generating unique challenge to prevent replay attacks for the generic flow, I'm assuming this is related to/will be used in the auth challenge.
tplooker (Tue, 26 Feb 2019 20:23:04 GMT):
@tomislav I was thinking about this before the way I have thought about it until now is we will have different types of challenges i.e a proof/presentation request could be one, proof of possession of a key could be another. In the case of a proof request @MALodder correct me if I am wrong but the proof request involves nonce generation that could be relied on as a source of randomness to counter replay attacks? Optionally if we see it as warranted I can include a nonce at the message level?
tplooker (Tue, 26 Feb 2019 20:23:04 GMT):
@tomislav I was thinking about this before, the way I have thought about it until now is we will have different types of challenges, i.e a proof/presentation request could be one, proof of possession of a key could be another. In the case of a proof request @MALodder correct me if I am wrong but the proof request involves nonce generation that could be relied on as a source of randomness to counter replay attacks? Optionally if we see it as warranted I can include a nonce at the message level?
MALodder (Tue, 26 Feb 2019 20:26:54 GMT):
@tomislav so if we look at the downsides of a bad nonce this is what can happen:
1- The verifier must generate the nonce otherwise the prover could cheat and fake proofs
2- Randomness helps with security for the prover (verifier cannot learn hidden values) and soundness for the verifier (soundness is prover can't cheat)
Replay attacks can affect both sides but mostly affect the verifier because the verifier could be tricked into accepting a proof that the Prover already computed but may no longer be valid. Usually we rely on hardware or cryptographically secure pseudo random number generators for a nonce. In the case of IoT, it might be helpful to look to external sources for better entropy like the root hash of the Sovrin ledger.
tplooker (Tue, 26 Feb 2019 23:08:50 GMT):
I have created a new draft HIPE that I have called an ephemeral challenge protocol, @kdenhartog @tomislav @nage in particular this may be of interest to you guys as we discussed this concept on the last day of the connectathon. I am planning on producing a couple more HIPEs that detail how this procotol can be realised in an implementation. Feedback welcome :)! https://github.com/hyperledger/indy-hipe/blob/8af3a15eea6bd9c2244df86019953012b45e700d/text/ephemeral-challenge-protocol/README.md
tplooker (Tue, 26 Feb 2019 23:12:39 GMT):
In particular I have an example of how we can use the protocol on top of oauth to realize several use cases that yield a low barrier of implementation for existing websites
daidoji (Wed, 27 Feb 2019 00:11:09 GMT):
Has joined the channel.
sklump (Wed, 27 Feb 2019 13:32:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=X5g6wCoMwvyzFcwoX) @dbluhm Thanks, the bug was on my side.
tplooker (Wed, 27 Feb 2019 19:55:30 GMT):
zoom
nage (Wed, 27 Feb 2019 20:55:59 GMT):
Layer of layers drawing for discussing indy-sdk, libraries and framework divisions and how we can modulators the SDK going forward https://docs.google.com/drawings/d/14lVjP4UzteIqO2aJOy3JinjcGkKH-KYjIKqRgbXU2a0/edit?usp=drivesdk
nage (Wed, 27 Feb 2019 20:56:30 GMT):
Also Envoy is an open source protocol library, so we should consider alternative names for the new agent project
dbluhm (Wed, 27 Feb 2019 21:39:03 GMT):
@tplooker awesome work on the ephemeral challenge HIPE. I think you've opened a ton of eyes to an area that has been previously unexplored.
tplooker (Wed, 27 Feb 2019 23:49:42 GMT):
Very early stage HIPE designed to get the conversation started around how OAuth integration would look https://github.com/hyperledger/indy-hipe/pull/96!
tplooker (Wed, 27 Feb 2019 23:49:42 GMT):
Very early stage HIPE designed to get the conversation started around how OAuth integration would look with the ephemeral challenge protocol https://github.com/hyperledger/indy-hipe/pull/96
tplooker (Wed, 27 Feb 2019 23:51:08 GMT):
Note I have the OAuth integration HIPE based off the ephemeral challenge protocol HIPE due to the dependency, this is the main place to read about the integration https://github.com/hyperledger/indy-hipe/blob/2db4ff4aecb070898e98ebf10516f60d6cb67be2/text/oauth-ephemeral-integration/README.md
TelegramSam (Thu, 28 Feb 2019 15:29:33 GMT):
Indy Agent Call Recording: https://drive.google.com/drive/u/1/folders/1qmibSMoBPRgpBe6vg4R7KImNn-lljDuc
Rowan_Shedden (Thu, 28 Feb 2019 21:12:37 GMT):
Has joined the channel.
tplooker (Thu, 28 Feb 2019 21:18:41 GMT):
Has anyone seen this https://github.com/decentralized-identity/did-auth-jose? As I was saying on the call yesterday I think if we want non-repudiation for auth-crypted messages, perhaps we want the internal format to be a JWS format which contains an agent message inside? Then when the recipient (i.e ephemeral challenge or a connection invite) and the sender would like to provide non-repudiation, they can just send the JWS?
tplooker (Thu, 28 Feb 2019 21:18:41 GMT):
Has anyone seen this https://github.com/decentralized-identity/did-auth-jose? As I was saying on the call yesterday I think if we want non-repudiation for auth-crypted messages, perhaps we want the internal format to be a JWS format which contains an agent message inside? Then when the recipient isnt known (i.e ephemeral challenge or a connection invite) and the sender would like to provide non-repudiation, they can just send the JWS?
Rowan_Shedden (Thu, 28 Feb 2019 21:20:15 GMT):
I have a question on the message flow between agents when establishing a connection. The flow is connection_offer (ta->alice), connection_request (alice->ta), connection_response (ta-alice) and connection_acknowledgement (alice->ta). The question I have is how does the ta obtain the verkey of the alice in order to anon encrypt the connection_response message? It works fine in the other direction, where the connection_offer originates from the ta because it can write the DID and verkey to the ledger and alice can retrieve it from there, but alice can't write to the ledger so how does the ta get the verkey?
Rowan_Shedden (Thu, 28 Feb 2019 21:20:15 GMT):
I have a question on the message flow between agents when establishing a connection. The flow is connection_offer (ta->alice), connection_request (alice->ta), connection_response (ta-alice) and connection_acknowledgement (alice->ta). The question I have is how does the ta obtain the verkey of alice in order to anon encrypt the connection_response message? It works fine in the other direction, where the connection_offer originates from the ta because it can write the DID and verkey to the ledger and alice can retrieve it from there, but alice can't write to the ledger so how does the ta get the verkey?
tplooker (Thu, 28 Feb 2019 21:23:18 GMT):
@Rowan_Shedden Alice discloses her verkey in the connection request.
Rowan_Shedden (Thu, 28 Feb 2019 21:25:19 GMT):
Clipboard - March 1, 2019 8:25 AM
Rowan_Shedden (Thu, 28 Feb 2019 21:26:08 GMT):
apparently not ... according to the connection_request spec the verkey is not part of the message ...
I don't see a place for verkey in the connection_request
tplooker (Thu, 28 Feb 2019 21:27:08 GMT):
@Rowan_Shedden sorry where is this from? This is the most up to date connection protocol version https://github.com/hyperledger/indy-hipe/blob/b3f5c388ea25e728db4be9a32b9dd0ef249f3b3c/text/connection-protocol/README.md
Rowan_Shedden (Thu, 28 Feb 2019 21:28:30 GMT):
Clipboard - March 1, 2019 8:28 AM
Rowan_Shedden (Thu, 28 Feb 2019 21:28:57 GMT):
I got mine from here: https://hyperledger-indy.readthedocs.io/projects/agent/en/latest/README.html
Rowan_Shedden (Thu, 28 Feb 2019 21:32:48 GMT):
which do I believe? The 2 message formats are quite different.
tplooker (Thu, 28 Feb 2019 21:35:27 GMT):
@Rowan_Shedden Ah ok, sorry about that, yes the current HIPE is the new format the community is adopting, so referencing that is better, are you just trying to generally understand the protocol or are you designing your own agent?
Rowan_Shedden (Thu, 28 Feb 2019 21:46:18 GMT):
I have already built the agents and have a working system, using the existing protocols ... but the compromise I had to make was that all connections had to originate from a non trust anchor due to the limitation I just asked about. I could have just broken the connection_request message and added the verkey, but I wanted to stay true to the documentation.
Rowan_Shedden (Thu, 28 Feb 2019 21:47:13 GMT):
I asked my contact in Evernym about this and he suggested I ask the community, hence my post on this forum.
Rowan_Shedden (Thu, 28 Feb 2019 21:49:36 GMT):
I have spent a lot of time building the existing system I have, which is used to demonstrate Sovrin, so I'm not disposed to having to re-write it to adopt the new protocol.
Rowan_Shedden (Thu, 28 Feb 2019 21:51:39 GMT):
in the new protocol I don't see the verkey being shared anywhere and also no mention of anon or auth encrypting the data in those new connection messages. So, is that all out the window now, with the new protocol?
andrew.whitehead (Thu, 28 Feb 2019 21:53:47 GMT):
The keys are obtained from the DID Document, which may be included or found on the ledger. The new protocol assumes that authcrypt-style wire message format (pack & unpack) is used: https://github.com/hyperledger/indy-hipe/tree/master/text/0028-wire-message-format
andrew.whitehead (Thu, 28 Feb 2019 21:53:47 GMT):
The keys are obtained from the DID Document, which may be included or found on the ledger. The new protocol assumes that authcrypt-style wire message format (pack & unpack): https://github.com/hyperledger/indy-hipe/tree/master/text/0028-wire-message-format
MattRaffel (Thu, 28 Feb 2019 21:54:36 GMT):
Agent to Agent doesnt replace what you're doing with auth encrypting etc. A2A is about messages between agents.
Rowan_Shedden (Thu, 28 Feb 2019 21:55:13 GMT):
Well, in that case, back to my original question ... how would a non trust anchor write to the ledger?
MattRaffel (Thu, 28 Feb 2019 21:56:30 GMT):
`indy_submit_request` api
Rowan_Shedden (Thu, 28 Feb 2019 21:57:33 GMT):
I'be not seen that api before, do you have a link to the documentation?
tplooker (Thu, 28 Feb 2019 21:58:45 GMT):
@Rowan_Shedden not all dids and or did docs need to be committed to a ledger either, we are developing what has been coined peer did support where two parties can connect in a pairwise fashion exchanging the did docs directly. Hence why you can either disclose the did and did doc in the connection request or just the did.
MattRaffel (Thu, 28 Feb 2019 21:58:53 GMT):
you're best bet is to look through the samples in the repo: https://github.com/hyperledger/indy-sdk
the samples and how tos are the best documentation
Rowan_Shedden (Thu, 28 Feb 2019 21:59:47 GMT):
thanks, that's where I got all my info on the current system I have built .....
tplooker (Thu, 28 Feb 2019 22:02:15 GMT):
@Rowan_Shedden for a reference implementation of an agent I would recommend this https://github.com/hyperledger/indy-agent/tree/master/python also the readme here https://github.com/hyperledger/indy-agent points at several other agent implementations that are emerging and achieve interoperability at the recent agent connectathon
Rowan_Shedden (Fri, 01 Mar 2019 05:37:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=FwGYZH5RypNcDLMSr) @MattRaffel are you suggesting that if I use this function that I can submit a NYM message to the ledger without having to be a trust anchor?
MattRaffel (Fri, 01 Mar 2019 15:57:52 GMT):
@Rowan_Shedden I'm not completely sure of the context, in terms of what you are seeking to achieve. If you haven't I strongly encourage recreating one of the samples. Assuming you are using java: https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/Anoncreds.java
I believe the shorter answer is no. Pairwise Dids do not require agent or a endpoint be a trust anchor because those are stored in the wallet not on ledger.
Write NYM transaction for new DID can be performed only by trust anchor+ role.
Simple user can send NYM for his did, like key rotation.
Get request doesn't require signature and any role
MattRaffel (Fri, 01 Mar 2019 15:57:52 GMT):
@Rowan_Shedden I'm not completely sure of the context, in terms of what you are seeking to achieve.
A2A is functionality that exists on a level "higher". Its purpose is to facility communication channels. Agents still need to use indy sdk APIs to create credentials etc....A2A protocols do not do that.
If you haven't I strongly encourage recreating one of the samples, as they do answer a lot of questions. Assuming you are using java: https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/Anoncreds.java
I believe the shorter answer is no. Pairwise Dids do not require agent or a endpoint be a trust anchor because those are stored in the wallet not on ledger.
Write NYM transaction for new DID can be performed only by trust anchor+ role.
Simple user can send NYM for his did, like key rotation.
Get request doesn't require signature and any role
Vikrum (Fri, 01 Mar 2019 22:39:48 GMT):
Has joined the channel.
Rowan_Shedden (Mon, 04 Mar 2019 05:43:34 GMT):
thanks Matt for your explanation, I appreciate your patience with me. I have recreated the samples and looked at that code, but it didn't give me the answer my question which is why I asked the forum. However, your statement "Write NYM transaction for new DID can be performed only by trust anchor+ role." above does answer my question. And it proves what I suspected. That is, you can only initiate the connection_offer (and subsequent to and fro request/response/acknowledgement) to a trust anchor as only a trust anchor can write the NYM transaction for a new DID. That seems like a hole in the connection messaging protocol which I suppose is possibly one of the reasons for moving to the newer connection_invitation protocol.
dbluhm (Mon, 04 Mar 2019 12:09:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wxHHa9u2h8t2W5a6u) @Rowan_Shedden For nearly all connections, it is not necessary to write a DID to the ledger.
lorenz.loesch (Mon, 04 Mar 2019 15:35:47 GMT):
Has joined the channel.
TelegramSam (Mon, 04 Mar 2019 20:57:58 GMT):
I've created a tag for the test suite as it was at the end of the connectathon: https://github.com/hyperledger/indy-agent/tree/test-2019-02-22
JanRzepecki (Tue, 05 Mar 2019 09:45:23 GMT):
Has joined the channel.
wangdong (Tue, 05 Mar 2019 13:48:33 GMT):
I am developing the iOS edge-agent with cordova plugin.
wangdong (Tue, 05 Mar 2019 13:48:57 GMT):
And I got an error. Not sure what is wrong.
wangdong (Tue, 05 Mar 2019 13:49:14 GMT):
dyld: Library not loaded: @rpath/Indy.framework/Indy
Referenced from: /Users/dong/Library/Developer/CoreSimulator/Devices/98872EEC-A137-49D9-82B3-5A86A39455F8/data/Containers/Bundle/Application/8B4D6912-49FD-47AF-8DE0-7A92A0EF7D3D/HelloWorld.app/HelloWorld
Reason: image not found
wangdong (Tue, 05 Mar 2019 13:49:28 GMT):
Does anyone get this before?
danielhardman (Tue, 05 Mar 2019 18:19:45 GMT):
I raised a new PR against indy-hipe. This is not for a HIPE; it's for a tweak to something already merged. I want to update the "Agent File Format" HIPE to use the verbiage "DIDComm" instead of "A2A". I am also proposing that we change the file extensions from *.ap and *.aw to *.dp and *.dw, and that we change the MIME type from "application/ssi-agent-wire" to "application/didcomm-wire", etc. https://github.com/hyperledger/indy-hipe/pull/99
peteoleary (Wed, 06 Mar 2019 16:19:41 GMT):
Has joined the channel.
peteoleary (Wed, 06 Mar 2019 20:21:04 GMT):
Hi all. I have been using the NodeJS agent to follow the Alice/Faber/etc. walkthrough and have gotten stuck. The agents don't seem to be picking up transaction written to the ledger by other agents. I feel like I am missing an obvious step somewhere.
devin-fisher (Wed, 06 Mar 2019 21:30:23 GMT):
Here is a doc to facilitate discussion about conventions around our JSON messages. Take a look, comment, add more conventions, etc
https://docs.google.com/document/d/1flfXrvZ0ehzB6v69VjVLJXFyITCLjla58d7SNYVNhac/edit
charliez (Thu, 07 Mar 2019 01:45:34 GMT):
Has joined the channel.
TelegramSam (Thu, 07 Mar 2019 17:26:36 GMT):
call recording: https://drive.google.com/drive/u/1/folders/1Dx5frDCeztu210H7NSj7nG5FTK4XesO_
tomislav (Thu, 07 Mar 2019 19:30:04 GMT):
@esplinr I'd like to contribute couple of pipelines for GitLabs. Are you the person who can help with checking some runner capabilities and toolings available?
esplinr (Thu, 07 Mar 2019 19:34:38 GMT):
That's great to hear tomislav. @MALodder is leading the effort.
fhmarino (Fri, 08 Mar 2019 02:00:30 GMT):
Has joined the channel.
itbill (Fri, 08 Mar 2019 05:46:50 GMT):
Has joined the channel.
danielhardman (Fri, 08 Mar 2019 18:43:09 GMT):
During our last agent WG call, @tplooker and I were debating the virtues of signing messages versus fields in a message. We got on the subject of repudiation and digital signatures. I got some feedback that some people may have wondered why I thought repudiation was such a big deal. I decided to propose a HIPE that explains this topic carefully, so we can refer to it in many other HIPEs where this issue comes up as a tangent. Here is my PR: https://github.com/hyperledger/indy-hipe/pull/100.
This doc doesn't argue the specific question Tobias and I were hung up on (whether signatures belong at the scope of a message or lower down). It explicitly acknowledges that signatures are the right answer for the use case Tobias was describing (see the section entitled "Unknown Recipient").
magicindustries (Sat, 09 Mar 2019 01:26:58 GMT):
Has joined the channel.
tplooker (Sun, 10 Mar 2019 19:53:42 GMT):
To clarify where I stand on this issue, I agree with what @danielhardman outlines in the above HIPE, signing an entire message should only be performed when and where appropriate, what I do believe which perhaps differs from others, is that when an entire message is signed it is more of a wire level concept (i.e where and how it is represented) rather than an application level one, hence my push to use a standardized format such as a JWS to represent this construct as opposed to a nested agent message.
DucaDellaForcoletta (Mon, 11 Mar 2019 13:17:27 GMT):
Has joined the channel.
DucaDellaForcoletta (Mon, 11 Mar 2019 13:24:04 GMT):
Hello, I'm developing a POC on indy. In the issuer agent the error WalletAlredyOpen (206) is raised in case of two concurrent open_wallet. How do you manage concurrent open request? In the von-agent implementation example a lock is applied on each request but seems very strange in case of massive concurrent request. Thanks
mhailstone (Tue, 12 Mar 2019 12:52:52 GMT):
I just read @swcurran 's tweet. Super cool! What is AgentBook?
mhailstone (Tue, 12 Mar 2019 15:24:45 GMT):
https://twitter.com/scurranC3I/status/1105210624785764353
jljordan_bcgov (Tue, 12 Mar 2019 16:12:06 GMT):
It's a new testing type service that allows people running an agent to post an invitation to allow others to connect to them
https://docs.google.com/document/d/1L8lqoywRzfzZA7iVPXQCHyQ7jY6drlRfwqnHkDAPNCY/edit
jljordan_bcgov (Tue, 12 Mar 2019 16:12:23 GMT):
and we have an example running at https://agentbook.vonx.io
jljordan_bcgov (Tue, 12 Mar 2019 16:12:23 GMT):
and we have an example running at http://agentbook.vonx.io
swcurran (Tue, 12 Mar 2019 16:56:24 GMT):
@jljordan_bcgov - what are you doing???? International Premiere is this Thursday on the Indy WG call.
swcurran (Tue, 12 Mar 2019 16:56:32 GMT):
No sneak previews...
jljordan_bcgov (Tue, 12 Mar 2019 17:18:49 GMT):
ah right .. I forgot
jljordan_bcgov (Tue, 12 Mar 2019 17:18:49 GMT):
ah right .. I forgot ... folks will have to join the call thursday!
twshelton (Tue, 12 Mar 2019 17:19:23 GMT):
@swcurran ... thats awesome ... sounds like it will be an exciting call :)
mhailstone (Tue, 12 Mar 2019 19:48:22 GMT):
@swcurran @jljordan_bcgov Looking forward to Thursday then! :)
Alexi (Tue, 12 Mar 2019 20:14:22 GMT):
Has joined the channel.
reithmayer (Wed, 13 Mar 2019 07:47:20 GMT):
Has joined the channel.
peteoleary (Wed, 13 Mar 2019 14:13:57 GMT):
Hey everyone. I have been following the Indy SDK walkthrough https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md using both the Jupyter notebook example and also the NodeJS agent https://github.com/hyperledger/indy-agent/tree/master/nodejs.
My question is this: in the Jupyter notebook code there is a variable transcript_schema_id which is set when Government creates the Transcript schema definition. Faber then uses transcript_schema_id to get the Transcript schema in order to create a credential definition. In the Jupyter script, Government and Faber are running in the same process so one can pass transcript_schema_id to the other. When Government and Faber are running in different processes, this is not possible of course.
My question is: how does Faber become aware that Government has created the Transcript schema? In the NodeJS agent demo, the agents call the getDidMetadata method and parse the list of schema IDs from the result. When I create the Transcript schema in the Government agent, the getDidMetadata method does return the newly created schema ID. However, the same method returns no new schema IDs in the other agents.
I have checked the log files on the node server and the the schema definition message appears in all 4 logs so everything appears to be working according to my understanding of the Indy Plenum overview https://github.com/hyperledger/indy-plenum/blob/master/docs/source/main.md.
Curiously, when I send a connection request from Government to Faber I see similar activity in the logs and the relationship does get established on both sides. So, there is working IPC between the two agents it's just not working for schema definitions.
I feel like I am missing something very basic here!
abdfaye (Wed, 13 Mar 2019 15:47:43 GMT):
Has joined the channel.
abdfaye (Wed, 13 Mar 2019 17:04:39 GMT):
Hi, is there an agent implementation currently supporting revocation?
tomislav (Wed, 13 Mar 2019 19:07:43 GMT):
@abdfaye What specifically about agents and revocation are you looking for? Revocation message protocol or agent API support?
JuanCamilo_0314 (Wed, 13 Mar 2019 19:56:39 GMT):
Has joined the channel.
nhelmy (Wed, 13 Mar 2019 20:35:37 GMT):
Hey Everyone, I recently wrote a paper at RWOT8 about self-signed and self-issued credentials. Curious to get comments and feedback from those in the community interested in consumer-facing SSI applications, web of trust, identity for all, and semantic web. You can leave comments on the doc or ping me for further discussion.
https://docs.google.com/document/d/1CeCZQh0pvkPSKwsAW6eDgLtTrXU3d4kArp9o2YjjGdQ/edit?usp=sharing
nhelmy (Wed, 13 Mar 2019 20:35:37 GMT):
Hey Everyone, I recently wrote a paper at RWOT8 about peer-to-peer claims exchange using self-signed and self-issued credentials. Curious to get comments and feedback from those in the community interested in consumer-facing SSI applications, web of trust, identity for all, and semantic web. You can leave comments on the doc or ping me for further discussion.
https://docs.google.com/document/d/1CeCZQh0pvkPSKwsAW6eDgLtTrXU3d4kArp9o2YjjGdQ/edit?usp=sharing
mhailstone (Thu, 14 Mar 2019 03:03:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=QjyHZj9fnAYvnJpXm) @peteoleary The node.js reference agent is not scanning or searching on the ledger for schema definitions. It retrieves a schema from the ledger `issuer/index.js:16`, but it finds the schema identifier that is saved locally in the wallet from a list of schemas that was created by that agent/wallet. In order to do a proof request, I made a textbox to show a sample proof request for a credential definition that is (again) created on that agent/wallet. You can copy and paste the proof request into another agent's proof request tab to modify/execute it against another agent. A credential definition is retrieved from the ledger by having the credential definition identifier (similar to the schema identifier). Hope this answers your question. Sorry for the delay and possible frustration. Let me know if you have additional questions. Glad your using the node.js agent code. We need more eyes on it. :)
TelegramSam (Thu, 14 Mar 2019 04:04:58 GMT):
Agent Call recording: https://drive.google.com/drive/u/1/folders/19W67CctCzACjDb4MBeAjg0tgDfLjrIlH
abdfaye (Thu, 14 Mar 2019 09:10:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CwYps53AdA5ey86uc) @tomislav I was more thinking about agent API support
charliez (Thu, 14 Mar 2019 12:38:00 GMT):
Hey, channel, I'm testing the sovrin test network by replaying the AnoncredsRevoc example under indy-sdk repo, and I got the following error message:
`Indy Error[113]: Error: Invalid structure, Caused by: RevocationRegistry not found for timestamp: 1552565450`
Anyone has any idea about this error?
Thanks
charliez (Thu, 14 Mar 2019 12:38:42 GMT):
the same AnoncredsRevoc example running fine with my local indy network
charliez (Thu, 14 Mar 2019 12:40:39 GMT):
I also got the following error/warning when trying to connect to the sovrin test network:
`src/services/pool/pool.rs:675 | Error during retrieving nodes: IndyError { inner: Node is not a validator Invalid library state }`
danielhardman (Thu, 14 Mar 2019 17:13:49 GMT):
@TelegramSam @swcurran @tomislav @tplooker How does everybody feel about making the following tweak to the Connection Protocol (now merged as HIPE 31), in Connection Request and Connection Response:
* The field named "DID" renamed to "did"
* The field named "DIDDoc" renamed to "did_doc"
This brings it into conformance with our chosen convention, snake_case. I don't like having some fields that abandon that convention for no good reason.
swcurran (Thu, 14 Mar 2019 18:00:37 GMT):
Just Do It
kdenhartog (Thu, 14 Mar 2019 18:01:12 GMT):
@danielhardman @TelegramSam do we have any good methodology for "registering" core and non-core protocols. Registering is a bad word but it frames the model im looking for which is an easy way for a developer new to the space to discover implemented protocol docs.
kdenhartog (Thu, 14 Mar 2019 18:02:18 GMT):
I was thinking @danielhardman had done something like this already and I know it was discussed to use the ledger later. What should we do until we have infrastructure in place for this?
danielhardman (Thu, 14 Mar 2019 18:14:07 GMT):
@kdenhartog One of the current HIPE proposals (I thought it was the protocol explainer HIPE, or maybe the feature discovery HIPE) had a list of known protocols, and I was imagining maintaining that list there. However, as I think about it now, that's a bad idea, because it means we have to constantly update a largely static HIPE doc just to enumerate protocols. How about if we simply create a new doc at the root of the indy-hipe repo called "Known Protocols" (known_protocols.md), which is like a Table of Contents that links out to other protocols? The Known Protocols doc could describe each protocol in a sentence or two, and then a link to its HIPE. That way, it would be easy to go to one place to discover anything interesting. Updating that doc could be trivial (all merge requests accepted), since the data in it is purely an index. Any time someone proposes a HIPE that's about a new protocol, their PR should include a tweak to known_protocols.md as well...
Individual protocol HIPEs ought to be updated, IMO, to include a section called "Implementations" that contains notes about implementation progress, and links to agents that are known to implement it. But such info shouldn't be highly dynamic. If you want the latest word on how well an agent implements a protocol, you should go to the information page for the agent (which ought to be linked to from github.com/hyperledger/indy-agent/README.md), and study the latest test suite results.
danielhardman (Thu, 14 Mar 2019 18:14:07 GMT):
@kdenhartog One of the current HIPE proposals (I thought it was the protocol explainer HIPE, or maybe the feature discovery HIPE) had a list of known protocols, and I was imagining maintaining that list there. However, as I think about it now, that's a bad idea, because it means we have to constantly update a largely static HIPE doc just to enumerate protocols. How about if we simply create a new doc at the root of the indy-hipe repo called "Known Protocols" (known_protocols.md), which is like a Table of Contents that links out to protocol specs? The Known Protocols doc could describe each protocol in a sentence or two, and then a link to its HIPE. That way, it would be easy to go to one place to discover anything interesting. Updating that doc could be trivial (all merge requests accepted), since the data in it is purely an index. Any time someone proposes a HIPE that's about a new protocol, their PR should include a tweak to known_protocols.md as well...
Individual protocol HIPEs ought to be updated, IMO, to include a section called "Implementations" that contains notes about implementation progress, and links to agents that are known to implement it. But such info shouldn't be highly dynamic. If you want the latest word on how well an agent implements a protocol, you should go to the information page for the agent (which ought to be linked to from github.com/hyperledger/indy-agent/README.md), and study the latest test suite results.
MattRaffel (Thu, 14 Mar 2019 18:16:43 GMT):
could we still have some kind of query protocol, where an agent sends message to another agent asking "do you understand the protocol specified in this message"?
MattRaffel (Thu, 14 Mar 2019 18:16:43 GMT):
could we still have (or already do have) some kind of query protocol, where an agent sends message to another agent asking "do you understand the protocol specified in this message"?
danielhardman (Thu, 14 Mar 2019 18:17:15 GMT):
@MattRaffel That is the Feature Discovery protocol; see https://github.com/hyperledger/indy-hipe/pull/73
danielhardman (Thu, 14 Mar 2019 18:17:35 GMT):
What Kyle is asking for is a way to know which protocols exist, not which protocols a particular agent supports.
danielhardman (Thu, 14 Mar 2019 18:17:35 GMT):
What Kyle is asking for is a way to know which protocols exist, as opposed to which protocols a particular agent supports.
kdenhartog (Thu, 14 Mar 2019 18:56:46 GMT):
Perfect, I'll work on a adding that document. Some community members in the broader SSI space asked me about this and this lines up with what I'd like to see until it's unscalable. At that point we can reevaluate and see how we can Decentralize this more while making it scalable.
nbrempel (Thu, 14 Mar 2019 22:32:12 GMT):
Hey everyone, I'm seeing a new error that I'm having trouble tracking down. Can anyone help me with this one?
I'm trying to write a credential definition to the ledger with `issuer_create_and_store_credential_def ` and I'm getting the following error:
```
indy.error.IndyError: (
devin-fisher (Fri, 15 Mar 2019 15:59:19 GMT):
Collaboration doc for DID Comm Message Best Practices:
https://docs.google.com/document/d/1flfXrvZ0ehzB6v69VjVLJXFyITCLjla58d7SNYVNhac
peteoleary (Fri, 15 Mar 2019 18:10:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=p8nWuzAyZA2HEhpzX) @mhailstone Thanks for the reply. So, if I am understanding you correctly a proof request would be sent from one agent to the other in order to get the identifier for either a schema definition or credential definition? Can you point me to an example of what these proof requests would look like?
mhailstone (Fri, 15 Mar 2019 18:42:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=zHoMy6iAsPYuun3Dv) @peteoleary Here is an example of a proof request after creating a schema { name: 'Government-Schema', version: '1.0', fields: ['name','email','tax_id']} and a credential definition that uses that schema with a tag "GOVID":
```{
"name": "GOVID-Proof",
"version": "0.1",
"requested_attributes": {
"attr1_referent": {
"name": "name",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
},
"attr2_referent": {
"name": "tax_id",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
},
"attr3_referent": {
"name": "email",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
}
},
"requested_predicates": {}
}```
mhailstone (Fri, 15 Mar 2019 18:42:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=zHoMy6iAsPYuun3Dv) @peteoleary Yes, by receiving the proof request which contains the identifier, you can do a lookup on the ledger. Here is an example of a proof request after creating a schema { name: 'Government-Schema', version: '1.0', fields: ['name','email','tax_id']} and a credential definition that uses that schema with a tag "GOVID":
```{
"name": "GOVID-Proof",
"version": "0.1",
"requested_attributes": {
"attr1_referent": {
"name": "name",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
},
"attr2_referent": {
"name": "tax_id",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
},
"attr3_referent": {
"name": "email",
"restrictions": [{"cred_def_id": "VmpZ95kMbJW3H5JLCRGvEs:3:CL:29:GOVID"}]
}
},
"requested_predicates": {}
}```
phillip.gibb (Sun, 17 Mar 2019 10:38:48 GMT):
video
phillip.gibb (Sun, 17 Mar 2019 10:40:09 GMT):
Hi there, any chance that a video was made available from the last Indy WG world call?
aronvanammers (Mon, 18 Mar 2019 14:14:22 GMT):
Has joined the channel.
TelegramSam (Mon, 18 Mar 2019 15:37:40 GMT):
@phillip.gibb The Agent call, or the Indy Call?
TelegramSam (Mon, 18 Mar 2019 15:38:21 GMT):
The following HIPEs have been moved to FCP status. Please review them and comment on any changes needed before acceptance:
https://github.com/hyperledger/indy-hipe/pull/100 - Repudiation Explainer
https://github.com/hyperledger/indy-hipe/pull/86 - Agents Explainer
https://github.com/hyperledger/indy-hipe/pull/85 - Mediators and Relays
https://github.com/hyperledger/indy-hipe/pull/83 - JSON-LD compatibility
aguel (Mon, 18 Mar 2019 18:09:48 GMT):
Has joined the channel.
phillip.gibb (Tue, 19 Mar 2019 11:51:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=rB4cLbyXQaxRFcxsz) @TelegramSam The one where they had 30 or so agents connected, agent book?
TelegramSam (Tue, 19 Mar 2019 13:30:35 GMT):
That's the Indy Call on Thursdays. @Sean_Bohan recorded that.
smithbk (Tue, 19 Mar 2019 15:45:15 GMT):
Anyone, for interoperability, has the attribute encoding been defined yet? In particular, how should we compute the "encoded" value in the `cred_values_json` arg passed to `issuer_create_credential` as shown below: ``` :param cred_values_json: a credential containing attribute values for each of requested attribute names.
Example:
{
"attr1" : {"raw": "value1", "encoded": "value1_as_int" },
"attr2" : {"raw": "value1", "encoded": "value1_as_int" }
}
```
mwherman2000 (Tue, 19 Mar 2019 19:33:14 GMT):
I'm sort of catching up on the A2A communications protocol... is there a way to query a specific Agent to ask which specific protocol families it supports? ...something like `NEP-10`: https://github.com/neo-project/proposals/blob/master/nep-10.mediawiki
dbluhm (Tue, 19 Mar 2019 19:34:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=cb2vmx2WjEApHey3g) @mwherman2000 I believe there is a HIPE on feature discovery by Daniel Hardman that covers this
dbluhm (Tue, 19 Mar 2019 19:35:48 GMT):
https://github.com/dhh1128/indy-hipe/blob/9c7722d208cfe0a336cb67a626cbbb192ae73f8c/text/feature-discovery/README.md
mwherman2000 (Tue, 19 Mar 2019 19:52:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=65bf7c50-04f0-48fd-a78c-b38789bbd68c) @dbluhm That's very close @dbluhm CC: @danielhardman Couple drill down questions:
1. In the response object example from the HIPE (https://github.com/dhh1128/indy-hipe/blob/9c7722d208cfe0a336cb67a626cbbb192ae73f8c/text/feature-discovery/response.json), shouldn't `protocols` be an array object to allow more than one protocol to be returns from the query?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/response",
"@thread": { "thid": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU" },
"protocols": {
"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.0": {
"roles": ["player"],
"mtypes": ["move", "outcome"]
}
}
}
```
2. The HIPE talks about using `*` as a wildcard character in the filter expression. Is the following construction also valid when I want an agent to return an array of all of the protocols an Agent supports?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;*"
}
```
mwherman2000 (Tue, 19 Mar 2019 19:52:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=65bf7c50-04f0-48fd-a78c-b38789bbd68c) @dbluhm That's very close @dbluhm CC: @danielhardman Couple drill down questions:
1. In the response object example from the HIPE (https://github.com/dhh1128/indy-hipe/blob/9c7722d208cfe0a336cb67a626cbbb192ae73f8c/text/feature-discovery/response.json), shouldn't `protocols` be an array object to allow more than one protocol to be returned from the query?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/response",
"@thread": { "thid": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU" },
"protocols": {
"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.0": {
"roles": ["player"],
"mtypes": ["move", "outcome"]
}
}
}
```
2. The HIPE talks about using `*` as a wildcard character in the filter expression. Is the following construction also valid when I want an agent to return an array of all of the protocols an Agent supports?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;*"
}
```
mwherman2000 (Tue, 19 Mar 2019 19:52:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=65bf7c50-04f0-48fd-a78c-b38789bbd68c) @dbluhm That's very close @dbluhm CC: @danielhardman Couple drill down questions:
1. In the response object example from the HIPE (https://github.com/dhh1128/indy-hipe/blob/9c7722d208cfe0a336cb67a626cbbb192ae73f8c/text/feature-discovery/response.json), shouldn't `protocols` be an array object to allow more than one protocol to be returned from the query?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/response",
"@thread": { "thid": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU" },
"protocols": {
"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.0": {
"roles": ["player"],
"mtypes": ["move", "outcome"]
}
}
}
```
2. The HIPE talks about using `*` as a wildcard character in the filter expression. Is the following construction also valid when I want an agent to return an array of all of the protocols that an Agent supports?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;*"
}
```
mwherman2000 (Tue, 19 Mar 2019 19:52:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=65bf7c50-04f0-48fd-a78c-b38789bbd68c) @dbluhm That's very close @dbluhm CC: @danielhardman Couple drill down questions:
1. In the response object example from the HIPE (https://github.com/dhh1128/indy-hipe/blob/9c7722d208cfe0a336cb67a626cbbb192ae73f8c/text/feature-discovery/response.json), shouldn't `protocols` be an array object to allow more than one protocol to be returned from the query?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/response",
"@thread": { "thid": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU" },
"protocols": {
"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.0": {
"roles": ["player"],
"mtypes": ["move", "outcome"]
}
}
}
```
2. The HIPE talks about using `*` as a wildcard character in the filter expression. Is the following construction also valid when I want an Agent to return an array of all of the protocols that a particular Agent supports?
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;*"
}
```
swcurran (Tue, 19 Mar 2019 21:23:46 GMT):
For the Indy Agent WG Call tomorrow we'll be discussing the Credential Exchange message family (Families?) for Issuing Credentials and Presenting Proofs. The proposed HIPE for the message families was updated this morning. Everyone planning to be on the call should read the latest and come ready to discuss. We'd like to get these protocols nailed down.
https://github.com/hyperledger/indy-hipe/pull/89
Call is at Noon Pacific Time - check your local time zone!
swcurran (Tue, 19 Mar 2019 21:23:46 GMT):
For the Indy Agent WG Call tomorrow we'll be discussing the Credential Exchange message family (families?) for Issuing Credentials and Presenting Proofs. The proposed HIPE for the message families was updated this morning. Everyone planning to be on the call should read the latest and come ready to discuss. We'd like to get these protocols nailed down.
https://github.com/hyperledger/indy-hipe/pull/89
Call is at Noon Pacific Time - check your local time zone!
andrew.whitehead (Tue, 19 Mar 2019 22:24:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=dMGQTA27AbZryyNoz) @smithbk There's a proposal and discussion here, but it sounds like nothing is decided yet: https://github.com/hyperledger/indy-hipe/pull/47
swcurran (Tue, 19 Mar 2019 22:30:17 GMT):
@smithbk - the encoding is going into the Schema 2.0 work which is going to be finalized and started to be worked on Real Soon Now. @kenebert is a good person to talk about that. Until then, I think the idea is just to limp along with no good answer.
kdenhartog (Wed, 20 Mar 2019 01:08:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ciYmKm3Nd8E2aoexc) @mwherman2000 can you provide this feedback through the HIPEs so that we can continue this conversation? I'm concerned it will get lost in this channel. In short I agree we should support what you've described.
With regards to 2, I think it would just be `*` rather than prepending the DID, because that DID is supposed to be associated with core protocols. In either case I think it would be better to do `"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec*"` to make sure we're finding the specs and not like a test agent service for that protocol.
kdenhartog (Wed, 20 Mar 2019 01:08:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=ciYmKm3Nd8E2aoexc) @mwherman2000 can you provide this feedback through the HIPEs so that we can continue this conversation? I'm concerned it will get lost in this channel. In short I agree we should support what you've described in question 1.
With regards to 2, I think it would just be `*` rather than prepending the DID, because that DID is supposed to be associated with core protocols. In either case I think it would be better to do `"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec*"` to make sure we're finding the specs and not like a test agent service for that protocol.
mwherman2000 (Wed, 20 Mar 2019 01:18:20 GMT):
@kdenhartog Thk u for the feedback. It may seem odd but I'm going to file it here: https://github.com/w3c-ccg/did-resolution/issues/32 ...we're investigating some options for the `did-url` grammar and the ";" operator may or may not go forward.
kdenhartog (Wed, 20 Mar 2019 01:19:01 GMT):
It won't get looped back into the discovery protocol discussion if you do that, but I agree it should be discussed there as well.
kdenhartog (Wed, 20 Mar 2019 01:19:14 GMT):
Different audiences look for feedback in different places is all
mwherman2000 (Wed, 20 Mar 2019 01:19:45 GMT):
I plan to link back to the HIPE ...doesn't make sense to make a bunch of intermediate changes IMO.
kdenhartog (Wed, 20 Mar 2019 01:21:39 GMT):
gotcha, that makes sense now
mwherman2000 (Wed, 20 Mar 2019 01:27:31 GMT):
Logged as https://github.com/w3c-ccg/did-resolution/issues/34
janl (Wed, 20 Mar 2019 17:52:31 GMT):
If there is room in today's Agent call here is a copy of the Consent Receipt lifecycle presentation that I would like to present. Last weeks timezone change threw me off and missed the call. In any case I am open for comments if u want to post it online or take up in the call. Thanks https://drive.google.com/open?id=1zYKZJUCYa5kncWSpcfuxAmi197aCJ-Ek
pknowles (Wed, 20 Mar 2019 18:10:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=5tawisoKq2BT5wujL) @janl I believe they have you down to present on March 27th. @swcurran or @TelegramSam will be able to confirm.
swcurran (Wed, 20 Mar 2019 18:31:04 GMT):
Yes - @janl - we have a full agenda planned for this week and have you down for next week's call. Hope that works - please confirm for next week.
swcurran (Wed, 20 Mar 2019 18:32:14 GMT):
Indy Agent Call in 30 minutes about the Credential Exchange Protocols.
Please join us for a rousing conversation about all things Indy Agent.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/856588081
Perpetual Meeting Notes: https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit?usp=sharing
janl (Wed, 20 Mar 2019 18:38:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=BMmZvB8x2azWfmjpY) @swcurran Yes, I can confirm for next week. Thanx
Alexi (Wed, 20 Mar 2019 20:01:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=xRGt3NnRiFwTqcXzg) @swcurran are these meetings recorded? / anywhere i can hear what was discussed post meeting?
dbluhm (Wed, 20 Mar 2019 20:02:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=NkMu6CFkr8wHiZcJr) @Alexi Yes, meetings are recorded and posted online
dbluhm (Wed, 20 Mar 2019 20:03:18 GMT):
https://docs.google.com/document/d/1VFdLCiPK5M1TEaL65FjbgYYu5j3e4ozISKTGIERGxU0/edit
dbluhm (Wed, 20 Mar 2019 20:03:32 GMT):
At the end of each meetings agenda is a link to the recording for the meeting
Alexi (Wed, 20 Mar 2019 20:03:39 GMT):
@dbluhm awesome, thanks!
mgbailey (Wed, 20 Mar 2019 20:11:06 GMT):
Has left the channel.
swcurran (Wed, 20 Mar 2019 21:37:09 GMT):
As a follow up from the Indy Agent WG call today, I added this comment to the Credential Exchange HIPE https://github.com/hyperledger/indy-hipe/pull/89#issuecomment-475037806
Those on the call - it would be great if you could review that and let me know if I missed something/made a mistake (I can edit the comment) or add your own comments to the docs.
Thanks!
kenebert (Thu, 21 Mar 2019 02:24:57 GMT):
@smithbk @swcurran The work on rich schemas (Schema 2.0) is getting started. Brent Zundel and I are working on the HIPEs to put the design work that encompasses the compatibility with the new Verifiable Credentials Data Model specification and the new rich schemas and associated encodings into a reviewable format. This last week was spent on making sure we had accurate descriptions of the ZKP style proofs in the specification before the candidate recommendation vote on Tuesday.
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the DID in the feature discovery HIPE example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using a DID Resolver? ...or...
b) is the list of message families supported by a particular Agent simply a capability internal to the implementation of the Agent (and either not or not necessarily stored on a Ledger)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using a DID Resolver? ...or...
b) is the list of message families supported by a particular Agent simply a capability internal to the implementation of the Agent (and either not or not necessarily stored on a Ledger)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply a capability internal to the implementation of the Agent (and either not or not necessarily stored on a Ledger)? ...and feature discovery is simply leveraging _DID syntax_ (and nothing more)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the _second_ DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply a capability internal to the implementation of the Agent (and either not or not necessarily stored on a Ledger)? ...and feature discovery is simply leveraging _DID syntax_ (and nothing more)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the _second_ DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some sort of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply a capability internal to the implementation of the Agent (and either not or not necessarily stored on a Ledger)? ...and feature discovery is simply leveraging _DID syntax_ (and nothing more)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the _second_ DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some sort of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply an _internal implementation details" of an Agent (and either not or not necessarily stored on a Ledger)? ...and feature discovery is simply leveraging _DID syntax_ (and nothing more)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the _second_ DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some sort of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply an _internal implementation detail_ of an Agent (and either not or not necessarily stored on a Ledger)? ...and feature discovery is simply leveraging _DID syntax_ (and nothing more)?
mwherman2000 (Thu, 21 Mar 2019 13:29:07 GMT):
@kdenhartog @danielhardman Looking at the _second_ DID in the feature discovery HIPE _request_ example JSON...
```json
{
"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/feature-discovery/1.0/request",
"@id": "yWd8wfYzhmuXX3hmLNaV5bVbAjbWaU",
"query": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/tictactoe/1.*"
}
```
How is an Agent (generally) expected to solve/resolve the `query`? ...that is, (I'm having trouble wording my question),
a) are the message families supported by a particular Agent recorded on the INDY VDR (aka Indy Ledger)? ...and hence, resolvable using some sort of DID Resolver functionality? ...or...
b) is the list of message families supported by a particular Agent simply an _internal implementation detail_ of an Agent (and either not or not necessarily stored on a Ledger)? ...implying that the feature discovery request syntax is simply leveraging _DID syntax_ (and nothing more)?
TelegramSam (Thu, 21 Mar 2019 14:56:57 GMT):
@mwherman2000 Option B.
danielhardman (Thu, 21 Mar 2019 16:02:59 GMT):
@mwherman2000 I agree with Sam. Option B.
mwherman2000 (Thu, 21 Mar 2019 17:14:36 GMT):
@TelegramSam @danielhardman Thank you, that's what I was hoping. It's a new and interesting use case for the `did-url` grammar. I've added it as `did-url` use case #18: https://github.com/mwherman2000/did-url-spec/blob/master/README.md#lower-level-did-url-use-cases
mwherman2000 (Thu, 21 Mar 2019 17:17:54 GMT):
It highlights we not designing a grammar simply for DID Resolution but a grammar for a range of applications that use `did-url` syntax: https://github.com/mwherman2000/did-url-spec/blob/master/README.md#purpose ...DID Resolution is just one application example.
mwherman2000 (Thu, 21 Mar 2019 17:17:54 GMT):
It highlights we not designing a `did-url` grammar simply for DID Resolution but a grammar for a range of applications that use `did-url` syntax: https://github.com/mwherman2000/did-url-spec/blob/master/README.md#purpose ...DID Resolution is just one application example.
TelegramSam (Thu, 21 Mar 2019 18:41:49 GMT):
meeting recording posted: https://drive.google.com/open?id=1RqrMAl2uxC_HzUhIYAwD5pHt0ZLHxbNG
kdenhartog (Thu, 21 Mar 2019 22:05:33 GMT):
B as well
kdenhartog (Thu, 21 Mar 2019 22:07:29 GMT):
With regards to error reporting at the wire level (Say I try to unpack and I get an error), what ideas did people have for handling this? I'd like to see us get some basic interop on error handling, and I think this is a good case to work on.
kdenhartog (Thu, 21 Mar 2019 22:08:30 GMT):
@danielhardman @TelegramSam @tplooker @swcurran and Tomislav (I don't know his handle) were the people I hoped would weigh in on this
danielhardman (Thu, 21 Mar 2019 22:46:21 GMT):
@kdenhartog IMO, some vital questions that will drive a lot of decisions about error reporting are:
1. Who can I tell about the problem? (Possible answers include: the sender, the receiver, mediators in between the two; any combination is possible.)
2. Does the problem have a predictable outcome (for example, message must be damaged because it can't be decrypted --> must react as if message were undeliverable) vs. a fuzzy one (for example, message is using a weaker cipher suite than the receiver wanted --> ?)
3. Is the problem recoverable? (sent to an unknown DID = unrecoverable; sent but delivered so slowly that it timed out = recoverable)
I suggest that we find the list of questions (of which these 3 are representative) and the list of possible answers, and then make a matrix (e.g., questions as rows, answers as columns). In each cell, we could say what the recommended error reporting action is. In some cases, the action will be to report the error to just one party. In some cases, the action will be not to report the error at all (avoiding an amplification attack). Etc.
Once we have the matrix and agree upon it, then we can do a standard impl of it--perhaps down in unpack().
kdenhartog (Thu, 21 Mar 2019 23:07:34 GMT):
@swcurran I'm working on creating a PR against the credential HIPE, and I'm looking at the `offers` attribute comment under `credential-offer` changes. Is it replacing the `credential_preview` attribute or the `~attach` attribute?
kdenhartog (Thu, 21 Mar 2019 23:09:45 GMT):
Also relevant, uPort doesn't require a credential_definition. They recommend using schema.org when possible.
kdenhartog (Thu, 21 Mar 2019 23:16:06 GMT):
DIF hubs don't appear to describe a cred_def like object either. My plan is to add what we've agreed on then make a secondary commit with changes I'm suggesting to support other credential formats in this protocol.
danielhardman (Fri, 22 Mar 2019 03:49:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Xes3cnmr4TvpgFjRC) This change has now been made in the indy-hipe repo; see https://github.com/hyperledger/indy-hipe/pull/107. I have also raised a PR against the indy-agent repo, updating the test suite; see https://github.com/hyperledger/indy-agent/pull/96. Note that agents will not pass the Connection Protocol tests until they update the field names they produce and consume.
danielhardman (Fri, 22 Mar 2019 07:10:16 GMT):
I have made significant revisions to the attachment HIPE, based on discussions that we had at the agent connect-a-thon. The doc now discusses embedding vs. more generic attachment vs. inlining, and explains the rules that could be used to decide which is appropriate. A new review of the HIPE would be appreciated, especially by people who had opinions on this topic, like @tplooker , @TelegramSam , @swcurran , and @kdenhartog . https://github.com/hyperledger/indy-hipe/pull/78
sklump (Fri, 22 Mar 2019 17:10:05 GMT):
Wow, that looks like the details have been tough to hammer out. I must get a better look next week.
sklump (Fri, 22 Mar 2019 17:10:05 GMT):
Wow, that looks like the details must have been tough to hammer out. I must get a better look next week.
Gruszka (Fri, 22 Mar 2019 21:43:30 GMT):
Has joined the channel.
TelegramSam (Mon, 25 Mar 2019 21:36:44 GMT):
Proposal: To allow for credentials exchange interop at IIW, we need a fixed target. How about we agree on a 0.1 message family proposal that works most easily with the existing SDK, and then continue the current HIPE for a 1.0 release that is more complete and better designed.
Proposal for 0.1 message family: https://hackmd.io/oWSw18DLTYCmHi_ty_gYvg
Thoughts?
TelegramSam (Mon, 25 Mar 2019 21:37:33 GMT):
@nage @danielhardman @tomislav @swcurran @tplooker ^
Ryan2 (Tue, 26 Mar 2019 04:48:08 GMT):
Has joined the channel.
tplooker (Tue, 26 Mar 2019 09:58:42 GMT):
Yeap I'm happy to progress with that
lepar (Tue, 26 Mar 2019 13:54:48 GMT):
Has joined the channel.
danielhardman (Tue, 26 Mar 2019 14:14:54 GMT):
@TelegramSam I'm okay with the spirit of that proposal. However, let's eliminate the credential-proposal message from it, since we won't be using it at all in the 0.1 family at IIW, and anybody at IIW who sees it and has not been on indy-agent calls will just require explanation. Also, near the bottom of your proposal, can we please rename "claims presentation" to "credential presentation"?
MALodder (Tue, 26 Mar 2019 14:40:04 GMT):
:thumbsup:
swcurran (Tue, 26 Mar 2019 15:32:37 GMT):
We plan (at least tentatively) to use credential-proposal in our demonstration, so we can leave that.
swcurran (Tue, 26 Mar 2019 15:33:22 GMT):
I'll change the presentation term, although IMHO presentation claims makes more sense.
swcurran (Tue, 26 Mar 2019 15:34:30 GMT):
Done.
swcurran (Tue, 26 Mar 2019 19:42:40 GMT):
Hey Folks, BC Gov has posted a new lightweight *_Code With Us_* procurement opportunity (aka bounty) for *Interoperable Hyperledger Indy Mobile Agent Capabilities*. Click here to see the details: https://bcdevexchange.org/opportunities/cwu/opp-interoperable-hyperledger-indy-mobile-agent-capabilities
To apply for the opportunity, you must register with the BC Dev Exchange website (link above) and then submit a short proposal by April 1, 2019. The proposal evaluation criteria is provided in the posting.
There is a github issue linked to the opoortunity for questions and answers, or you feel free to ask directly here. We'll repost any questions to the github issue.
@TelegramSam - please add this to the announcements on the Indy Agent call this week.
swcurran (Tue, 26 Mar 2019 19:42:40 GMT):
Hey Folks, BC Gov has posted a new lightweight *_Code With Us_* procurement opportunity (aka bounty) for "*Interoperable Hyperledger Indy Mobile Agent Capabilities*". Click here to see the details: https://bcdevexchange.org/opportunities/cwu/opp-interoperable-hyperledger-indy-mobile-agent-capabilities
To apply for the opportunity, you must register with the BC Dev Exchange website (link above) and then submit a short proposal by April 1, 2019. The proposal evaluation criteria is provided in the posting.
There is a github issue linked to the opoortunity for questions and answers, or you feel free to ask directly here. We'll repost any questions to the github issue.
@Sean_Bohan @nage - please add this to the announcements on the Indy call this week.
swcurran (Tue, 26 Mar 2019 19:42:40 GMT):
Hey Folks, BC Gov has posted a new lightweight *_Code With Us_* procurement opportunity (aka bounty) for *Interoperable Hyperledger Indy Mobile Agent Capabilities*. Click here to see the details: https://bcdevexchange.org/opportunities/cwu/opp-interoperable-hyperledger-indy-mobile-agent-capabilities
To apply for the opportunity, you must register with the BC Dev Exchange website (link above) and then submit a short proposal by April 1, 2019. The proposal evaluation criteria is provided in the posting.
There is a github issue linked to the opoortunity for questions and answers, or you feel free to ask directly here. We'll repost any questions to the github issue.
@Sean_Bohan @nage - please add this to the announcements on the Indy call this week.
dbluhm (Tue, 26 Mar 2019 19:48:41 GMT):
@swcurran mind if I repost onto the Sovrin Rocket.chat #jobs channel? ^^
dbluhm (Tue, 26 Mar 2019 19:48:41 GMT):
@swcurran mind if I repost onto the Sovrin Rocket.chat jobs channel? ^^
swcurran (Tue, 26 Mar 2019 19:49:09 GMT):
Please do - spread the word!
dbluhm (Tue, 26 Mar 2019 19:49:20 GMT):
:thumbsup:
pknowles (Tue, 26 Mar 2019 20:15:26 GMT):
@tomislav See *Interoperable Hyperledger Indy Mobile Agent Capabilities* post above. ^^
Alexi (Wed, 27 Mar 2019 15:49:35 GMT):
hey, just wanted to point out that on https://wiki.hyperledger.org/display/indy/Hyperledger+Indy the indy agent working group call is listed as being on Fridays but i believe its today (Wednesdays) right?
swcurran (Wed, 27 Mar 2019 15:53:31 GMT):
Thanks - I've fixed that. It's today at 11 Mountain, 12 Pacific.
mwherman2000 (Wed, 27 Mar 2019 17:21:29 GMT):
What is the link to the document that describes how A2A errors are handling/propagated? The general use case I'm interested in is when the value of a attribute other than an `id` is a DID and the DID is invalid: a) either syntactically invalid or b) the resource doesn
mwherman2000 (Wed, 27 Mar 2019 17:21:29 GMT):
What is the link to the document that describes how A2A errors are handling/propagated? The general use case I'm interested in is when the value of a attribute other than an `id` is a DID and the DID is invalid: a) either syntactically invalid or b) the resource doesn't exists or is otherwise not resolvable (at either the DID Document or DID Document fragment level).
mwherman2000 (Wed, 27 Mar 2019 17:21:29 GMT):
What is the link to the document that describes how A2A errors are handling/propagated? The general use case I'm interested in is when the value of a attribute other than an `id` attribute is a DID and the DID is invalid: a) either syntactically invalid or b) the resource doesn't exists or is otherwise not resolvable (at either the DID Document or DID Document fragment level).
mwherman2000 (Wed, 27 Mar 2019 17:21:29 GMT):
What is the link to the document that describes how A2A errors are handling/propagated? The general use case I'm interested in is when the value of a attribute other than an `id` attribute is a DID and the DID is invalid: a) either syntactically invalid or b) the resource doesn't exist or is otherwise not resolvable (at either the DID Document or DID Document fragment level).
TelegramSam (Wed, 27 Mar 2019 17:58:30 GMT):
@mwherman2000 We have an error report HIPE https://github.com/hyperledger/indy-hipe/pull/65
TelegramSam (Wed, 27 Mar 2019 17:59:40 GMT):
but the two issues you mention are complicated because DIDs are not (yet, at least) common in A2A messages, and a 'resource doesn't exist' error is not broadly applicable to message based communication.
danielhardman (Wed, 27 Mar 2019 20:51:32 GMT):
For anyone who is interested in the Peer DID method spec before next Wednesday's call, here is a link for further reading: https://openssi.github.io/peer-did-method-spec/index.html
danielhardman (Wed, 27 Mar 2019 22:04:56 GMT):
All: I have updated the feature-discovery HIPE per some good feedback from @TelegramSam and @swcurran . I think it is now mature enough to consider FCP status. Note that the name of the protocol is now "protocol-discovery" instead of the more generic "feature-discovery". I think that improves the accuracy of its name vis-a-vis its intent. @mwherman2000 I don't know if this will cause you to have broken hyperlinks in your preso where feature discovery was used as an example of did-url usage; you might want to check.
The PR is still at: https://github.com/hyperledger/indy-hipe/pull/73
mwherman2000 (Thu, 28 Mar 2019 00:42:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=AmFF2Wee2wCLY7DNr) @danielhardman Thanks for the heads up @danielhardman ...it's not a serious problem.
mwherman2000 (Thu, 28 Mar 2019 00:51:00 GMT):
@danielhardman I believe there are going to be some additional syntax changes need in the protocol-discovery HIPE based on some anticipated `did-uri` grammar changes ...to be very specific, in the `did-uri` grammar for `id` attributes ...i.e. replacement of the ";" with "#",
Reference: https://github.com/w3c-ccg/did-resolution/issues/34#issue-423024524
mwherman2000 (Thu, 28 Mar 2019 00:51:00 GMT):
@danielhardman I believe there are going to be some additional syntax changes need in the protocol-discovery HIPE based on some anticipated `did-uri` grammar changes ...to be very specific, in the `did-uri` grammar for `id` attributes ...i.e. replacement of the ";" with "#" in the request/response,
Reference: https://github.com/w3c-ccg/did-resolution/issues/34#issue-423024524
danielhardman (Thu, 28 Mar 2019 15:38:56 GMT):
Makes sense.
danielhardman (Fri, 29 Mar 2019 08:52:28 GMT):
I have raised a first draft of a HIPE about introductions: https://github.com/hyperledger/indy-hipe/pull/110
lukasA (Fri, 29 Mar 2019 09:45:55 GMT):
Has joined the channel.
rchristman (Fri, 29 Mar 2019 17:18:09 GMT):
Has joined the channel.
AnnaJ (Fri, 29 Mar 2019 20:00:44 GMT):
Has joined the channel.
george.aristy (Fri, 29 Mar 2019 20:55:29 GMT):
Has joined the channel.
swcurran (Fri, 29 Mar 2019 23:19:43 GMT):
For those that are planning on using the 0.1 version of the Credential Exchange protocol (e.g. not the version being refined in the HIPE), we've tweaked the spec. and are dropping the `credential-proposal` and `presentation-proposal` messages from the implementation. They have been marked as struck out in the document.
https://hackmd.io/oWSw18DLTYCmHi_ty_gYvg?view
swcurran (Fri, 29 Mar 2019 23:19:43 GMT):
For those that are planning on using the 0.1 version of the Credential Exchange protocol (e.g. the pre-IIW version, not the version being refined in the HIPE), we've tweaked the spec. and are dropping the `credential-proposal` and `presentation-proposal` messages from the implementation. They have been marked as struck out in the document.
https://hackmd.io/oWSw18DLTYCmHi_ty_gYvg?view
mwherman2000 (Sat, 30 Mar 2019 02:15:23 GMT):
I've been working on a `did-uri-spec` specification for generic DID URI grammars...
*Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) *
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md
…which emphasized the different application areas or domains that use DID and how they can be supported with the did-url-spec grammar.
An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).
Here’s a short webcast (16 minutes) that describes this capability:
Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
If you have an idea for DID application domain (in addition to DID Documents), I’ve love to hear from you and help you understand how the did-url-spec specification and grammar can help you and your project.
mwherman2000 (Sat, 30 Mar 2019 02:15:23 GMT):
I've been working on a `did-uri-spec` specification for generic DID URI grammars...
*Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) *
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md
…which emphasized the different application areas or domains that use DID and how they can be supported with the did-url-spec grammar.
An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).
Here’s a short webcast (16 minutes) that describes this capability:
Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
One of the specific use cases I talk about in the second webcast is the Indy Agent Protocol Discovery HIPE.
mwherman2000 (Sat, 30 Mar 2019 02:15:23 GMT):
I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar...
*Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) *
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md
…which emphasized the different application areas or domains that use DID and how they can be supported with the did-url-spec grammar.
An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).
Here’s a short webcast (16 minutes) that describes this capability:
*Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3*
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
One of the specific use cases I talk about in the second webcast is the Indy Agent Protocol Discovery HIPE. I'd appreciate hearing your feedback.
mwherman2000 (Sat, 30 Mar 2019 02:15:23 GMT):
I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar...
*Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) *
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md
…which emphasizes the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar.
An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).
Here’s a short webcast (16 minutes) that describes this capability:
*Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3*
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
One of the specific use cases I talk about in the second webcast is the Indy Agent Protocol Discovery HIPE. I'd appreciate hearing your feedback.
mwherman2000 (Sat, 30 Mar 2019 02:15:23 GMT):
FYFeedback: I've been working on a `did-uri-spec` specification for a generic/baseline DID URI grammar...
*Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) *
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md
…which emphasizes the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar.
An interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).
Here’s a short webcast (16 minutes) that describes this capability:
*Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3*
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
One of the specific use cases I talk about in the second webcast is the Indy Agent Protocol Discovery HIPE. I'd appreciate hearing your feedback.
mwherman2000 (Sat, 30 Mar 2019 19:13:17 GMT):
Here's 20-minute talk on the Domain-specific #DID Grammar (DSDG) for DID Document Collections ...
... checkout video #3 in the #Hyperonomy playlist: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
This webcast also describes how the $supportedCapabilities DID Method transformer option will (most likely) work.
Henrycoffin (Sun, 31 Mar 2019 09:29:35 GMT):
Has joined the channel.
tplooker (Sun, 31 Mar 2019 19:47:50 GMT):
@swcurran how will the receiver of the credential offer respond to the would be issuer with their email, for the IIW demo?
Zohaib_Sohail (Mon, 01 Apr 2019 09:22:19 GMT):
Has joined the channel.
Zohaib_Sohail (Mon, 01 Apr 2019 09:22:57 GMT):
I am not getting the concept of indy-agents. In real app, every instance should have a indy-agent installed? if yes then it can only be done with desktop application because a web browser would not be able to handle all functionalities of indy-agent.
Also, want some info about Agent providers and ready-to-use agent offerings?
dbluhm (Mon, 01 Apr 2019 13:46:02 GMT):
An agent is anything that can speak the agent protocol and (usually) has a wallet. Identity owners own one or many agents. Possession of an agent enables an identity owner to interact with others in a Self-Sovreign Identity world. Today, the community has reached consensus on and standardized three different protocols: the connection protocol, enabling the establishment of secure communication between two parties; the BasicMessage protocol, a very simple chat protocol; and the trust ping protocol, a secure connection liveness check. In the near future, agents compliant with the agent test suite will be able to exchange verifiable credentials and much more.
dbluhm (Mon, 01 Apr 2019 13:46:42 GMT):
@Zohaib_Sohail ^^^
dbluhm (Mon, 01 Apr 2019 13:48:02 GMT):
There are several known implementations of agents today. A simple directory of those agents, with links to more info, can be found at https://github.com/hyperledger/indy-agent in the main readme
dbluhm (Mon, 01 Apr 2019 13:51:22 GMT):
A HIPE (Hyperledger Indy Project Enhancement) by Daniel Hardman gives a good overview of agents, as well: https://github.com/dhh1128/indy-hipe/blob/36913b80685b224143439933473a86e8a7d2a8b2/text/0002-agents/README.md
swcurran (Mon, 01 Apr 2019 15:17:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DfKewebDhq4nqJpq6) @tplooker Plan now is that there is an interaction between the mobile agent (MA) and the Email Verification Service (EVS) website, and it's agent. MA Owner goes to EVS website and enters email address, gets an invitation (shortlived) in response that is handled by the MA. It connects with EVS and after connection is offered a credential. The EVS Website is the business rules provider, and the EVS agent is a generic (or at best, configured) IndyCat Agent.
swcurran (Mon, 01 Apr 2019 15:17:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=DfKewebDhq4nqJpq6) @tplooker Plan now is that there is an interaction between the mobile agent (MA) and the Email Verification Service (EVS) website, and it's agent. MA Owner goes to EVS website and enters email address, gets an invitation (shortlived) in response that is handled by the MA. It connects with EVS and after connection is offered a credential. The EVS Website is the business rules provider, and the EVS agent is a generic (or at most, configured) IndyCat Agent.
swcurran (Mon, 01 Apr 2019 15:18:01 GMT):
Convo about this is happening on the VONX rocketchar.
swcurran (Mon, 01 Apr 2019 15:18:01 GMT):
Convo about this is happening on the VONX rocketchat.
swcurran (Mon, 01 Apr 2019 16:49:06 GMT):
FYI - the BC Gov Indy Agent Code With Us Opportunity procurement closes today at 4PM Pacific time. If you are interested, you must submit your proposal by that time on the website.
https://www.bcdevexchange.org/opportunities/cwu/opp-interoperable-hyperledger-indy-mobile-agent-capabilities
ZichengWang (Mon, 01 Apr 2019 20:45:30 GMT):
Has joined the channel.
mbanerjee (Mon, 01 Apr 2019 22:02:24 GMT):
Has joined the channel.
dbluhm (Tue, 02 Apr 2019 15:39:44 GMT):
I submitted a PR with a draft HIPE on messages used during testing, as discussed during the agent connectathon: https://github.com/hyperledger/indy-hipe/pull/111
Comments and feedback welcome :slight_smile:
TelegramSam (Tue, 02 Apr 2019 16:52:03 GMT):
Merged PR to indy-agent: Demonstrates using a browser extension as a static agent to connect the UI. Included estension (must be used in an unpacked state) tested with chrome, firefox, and brave. https://github.com/hyperledger/indy-agent/pull/79
TelegramSam (Tue, 02 Apr 2019 17:35:31 GMT):
Merged another PR that updates the test suite. Note: we are tagging releases to make it easier to validate against test suite versions. The tag `test-2019-02-22` refers to the test suite as of the end of the connectathon. Master has new updates. When we update the test suite with significant changes, we'll tag another release.
VS09 1 (Wed, 03 Apr 2019 06:35:07 GMT):
Has joined the channel.
Dubh3124 (Thu, 04 Apr 2019 06:03:17 GMT):
What is the current logic of opening and closing a wallet? From looking at the codebase of a few of the indy-agents (specifically the python ref indy agent and the IndyCat Agent) I see the wallet being opened but never closed. Currently, I have a python decorator that opens the wallet, execute a function, then closes the wallet. Is there a better alternative to this?
```
def open_close_wallet(func):
@functools.wraps(func)
async def wrapped(*args, **kwargs):
kwargs["wallet_handle"] = await wallet.open_wallet(
args[0].wallet_config, args[0].wallet_credentials
)
try:
if not kwargs["wallet_handle"]:
raise Exception
else:
resp = await func(*args, **kwargs)
await wallet.close_wallet(kwargs["wallet_handle"])
return resp
except Exception:
log.exception("Error while executing function: " + func.__name__)
await wallet.close_wallet(kwargs["wallet_handle"])
raise
return wrapped
```
andrew.whitehead (Thu, 04 Apr 2019 06:32:46 GMT):
@Dubh3124 This method should work just fine, it's just a little slow if you're constantly opening and closing the wallet. I would also put the `close_wallet` call in a `finally` block instead of having it in two places.
Dubh3124 (Thu, 04 Apr 2019 06:41:31 GMT):
I am experimenting with a Hub agent that is a multi-tenant wallet host. I notice the slowness of opening and closing wallets so trying to find a better solution. Thanks for the input on the `finally`, I will change that
andrew.whitehead (Thu, 04 Apr 2019 07:06:56 GMT):
You could implement a wallet manager that keeps the wallet handle open for a certain amount of time and closes it if not accessed, although that would only help when you're accessing the same wallet multiple times, not so much if you're switching tenants frequently. IndyCat agent will likely do something like that eventually instead of keeping the wallet permanently open
Dubh3124 (Thu, 04 Apr 2019 07:12:34 GMT):
Hmm that is a good idea to treat it as a session manager kind of thing, but I wonder what is the security implications of keeping a wallet open.
danielhardman (Thu, 04 Apr 2019 21:19:53 GMT):
@tplooker @kdenhartog @TelegramSam @swcurran @saholman have some new thinking about the idea of connectionless interactions (e.g., the ephemeral challenge protocol that Tobias has outlined). I don't want to go to the effort of writing a long doc about it until we can talk interactively. Could I get some time (maybe 20 min?) on a meeting soon where all of you will be there? I think I can give Tobias the ephemeralness he's after (no back-and-forth to build connections), but in a way that doesn't require a bunch of new, ephemeral protocols and new signature mechanisms. it also will make adjusting to ephemeral use cases much easier inside agent code.
tplooker (Thu, 04 Apr 2019 21:21:44 GMT):
Very keen to chat about this, but I am busy at the moment, would 12-12:30 NZT suit?
swcurran (Thu, 04 Apr 2019 21:24:51 GMT):
That's 4:00 Pacific time. That works for me.
swcurran (Thu, 04 Apr 2019 21:25:31 GMT):
I'll send a zoom out and we'll see how we do.
danielhardman (Thu, 04 Apr 2019 21:49:47 GMT):
Okay, I'll be there. Thanks for finding time!
kdenhartog (Thu, 04 Apr 2019 21:58:06 GMT):
I'd like to join as well
swcurran (Thu, 04 Apr 2019 22:01:57 GMT):
Check your email, Kyle - should be there. Gmail.
dbluhm (Fri, 05 Apr 2019 00:32:47 GMT):
@danielhardman and others, would love to hear about what you discussed
danielhardman (Fri, 05 Apr 2019 06:10:33 GMT):
@dbluhm : https://docs.google.com/presentation/d/1rg9H_9GwtELkrpCDBSJ6A7biPe80LaBVDXxThkOTUXM/edit
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/fa7bd048bb30eb46c73c9a82510d54dd0b73b45d/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/fd0e4843/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/fd0e4843/text/protocols/uris.md
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/4fb8d67/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/4fb8d67/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/4fb8d67/text/protocols/uris.md
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/uris.md
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/uris.md
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/parties-roles-participants.md
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/uris.md
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/parties-roles-participants.md
https://github.com/hyperledger/indy-hipe/blob/8ab53b2/text/protocols/state-details.md
danielhardman (Sat, 06 Apr 2019 04:51:57 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include:
https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/README.md#types-of-protocols
https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/README.md#composable
https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/uris.md
https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/parties-roles-participants.md
https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/state-details.md
danielhardman (Sat, 06 Apr 2019 04:52:04 GMT):
https://github.com/hyperledger/indy-hipe/blob/fd0e4843/text/protocols/state-details.md
danielhardman (Sat, 06 Apr 2019 04:52:04 GMT):
https://github.com/hyperledger/indy-hipe/blob/4fb8d67/text/protocols/state-details.md
danielhardman (Sat, 06 Apr 2019 15:09:48 GMT):
https://github.com/hyperledger/indy-hipe/blob/4fb8d67/text/protocols/parties-roles-participants.md
swcurran (Sun, 07 Apr 2019 00:42:55 GMT):
A quick update on some message protocols we (BC Gov, Streetcred) are working on for an upcoming demo. If anyone is thinking of trying to be interoperable with us - here's what we're working on.
First is an "introduction-service" protocol. This will likely not be used again, as the "introduction" protocol HIPE that Daniel has proposed will be used in the long term. However, for the short term we're using a simpler process that fits exactly our use case. Specs: https://hackmd.io/jhjVAB2fQkiwRnG6CFNvGQ
Second, we are going to use an "action-menu" protocol, where one agent sends another agent a list of options and the other agent selects one option and sends back the selected option. Specs: https://hackmd.io/s/HkpyhdGtV
pknowles (Sun, 07 Apr 2019 05:13:55 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. Would I be correct in thinking that encrypted pairwise channels make these tokens superfluous to requirements when using Hyperledger Indy?
pknowles (Sun, 07 Apr 2019 06:09:13 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC constructs within encrypted pairwise channels, are JWTs superfluous to requirements?
pknowles (Sun, 07 Apr 2019 06:09:13 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements?
pknowles (Sun, 07 Apr 2019 06:09:13 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? By all means, point me to a HIPE or W3C channel that discusses this topic so that I can have a read.
pknowles (Sun, 07 Apr 2019 06:09:13 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? Feel free to point me to a HIPE or a W3C WG link that discusses this topic. Thanks, all.
pknowles (Sun, 07 Apr 2019 06:09:13 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? Feel free to point me to a HIPE or a W3C WG link that discusses this topic. Thanks, y'all (said in very posh British accent!)
pknowles (Sun, 07 Apr 2019 06:52:07 GMT):
My query above is sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. I thought it might be useful for context. Namely, "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 06:52:07 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. I thought it might be useful for context. Namely, "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 06:52:07 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. I thought it might be useful to add some context here. Namely, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 06:52:07 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. I thought it might be useful for me to add some context here. Namely, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 06:52:07 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. For context purposes, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 07:19:17 GMT):
From Kantara Initiative's Consent Receipt Specification: "The transmission of a JSON Consent Receipt should use the following specifications: JSON Web Token (JWT) [RFC 7519] / JSON Web Encryption (JWE) [RFC 7516] / JSON Web Signature (JWS) [RFC 7515]" [Ref. https://drive.google.com/drive/u/0/folders/1FFU47tCTu7XbNnpD2oZlbgglrKiTh5yb ]
pknowles (Sun, 07 Apr 2019 07:19:17 GMT):
From _Kantara Initiative's Consent Receipt Specification_: "The transmission of a JSON Consent Receipt should use the following specifications: JSON Web Token (JWT) [RFC 7519] / JSON Web Encryption (JWE) [RFC 7516] / JSON Web Signature (JWS) [RFC 7515]" [Ref. https://drive.google.com/drive/u/0/folders/1FFU47tCTu7XbNnpD2oZlbgglrKiTh5yb ]
pknowles (Sun, 07 Apr 2019 07:20:37 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? Feel free to point me to a HIPE or a W3C WG link that discusses this topic. Thanks, y'all (said in very posh British accent!)
pknowles (Sun, 07 Apr 2019 07:20:37 GMT):
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? Feel free to point me to a HIPE or a W3C WG link that discusses this topic.
pknowles (Sun, 07 Apr 2019 07:20:37 GMT):
JSON Web Tokens (JWTs) are an open, industry standard RFC 7519 method for representing claims securely between two parties. In VC exchange within encrypted pairwise channels, are JWTs superfluous to requirements? Feel free to point me to a HIPE or a W3C WG link that discusses this topic.
pknowles (Sun, 07 Apr 2019 07:20:40 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. For context purposes, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 07:20:47 GMT):
From _Kantara Initiative's Consent Receipt Specification_: "The transmission of a JSON Consent Receipt should use the following specifications: JSON Web Token (JWT) [RFC 7519] / JSON Web Encryption (JWE) [RFC 7516] / JSON Web Signature (JWS) [RFC 7515]" [Ref. https://drive.google.com/drive/u/0/folders/1FFU47tCTu7XbNnpD2oZlbgglrKiTh5yb ]
pknowles (Sun, 07 Apr 2019 07:22:04 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. For context purposes, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 07:22:04 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. Namely, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)."
pknowles (Sun, 07 Apr 2019 07:22:04 GMT):
My query above was sparked from a question raised in _Kantara Initiative's Consent & Information Sharing WG_. Namely, ... "Must the Consent receipt always (in the end) be in the form of JWT? Might it be in JSON form and not signed or in JSON and signed, bot not coded as JWT ... What are the possible variants the CR Viewer has to be able to read? It says in the spec that JWT (JWE and JWS are also mentioned, but these seem to be a part of JWT) should be used (not must be used)." [Cc: @AndrewHughes3000 ]
TelegramSam (Mon, 08 Apr 2019 14:00:07 GMT):
Agent Call Recordings Posted: https://wiki.hyperledger.org/display/indy/2019-04-03+Agent+Call
swcurran (Mon, 08 Apr 2019 20:02:49 GMT):
I had someone today question the term "peer-to-peer messaging" for what we are doing with Indy agents that have agency/routing agents in between the endpoints. His claim is that "peer-to-peer" messaging implies/requires that the two peers know the IP address of each other and talk directly. Thoughts from others on that? Do we need to have a different term?
tplooker (Mon, 08 Apr 2019 20:11:43 GMT):
Is there any documentation they can point to that talks about the claim? I hadn't heard of an inextricable link between peer and IP address? If they are talking about P2P tech in general most existing implementation would have peers identify by their IP address but I dont see why that imposes a constrain on future tech?
tplooker (Mon, 08 Apr 2019 20:16:29 GMT):
Personally `peer` feels pretty divorced from the technology to me?
jljordan_bcgov (Mon, 08 Apr 2019 20:20:28 GMT):
peer DIDs encrypt the message in question ... we still say p2p on internet even though there are routers
jljordan_bcgov (Mon, 08 Apr 2019 20:20:55 GMT):
no intermediary can intercept the message and mess with it
jljordan_bcgov (Mon, 08 Apr 2019 20:21:26 GMT):
they could in theory discard it by they won't know where its going in the inter identity domain zone
jljordan_bcgov (Mon, 08 Apr 2019 20:22:02 GMT):
in the intra identity domain zone there could be ways for cloud agency providers could attempt to interfere with message forwarding
jljordan_bcgov (Mon, 08 Apr 2019 20:22:10 GMT):
at the transport layer
TelegramSam (Mon, 08 Apr 2019 20:32:51 GMT):
We also use "peers" to route the message. It is important that agent messaging not be TCP dependant.
TelegramSam (Mon, 08 Apr 2019 20:33:59 GMT):
peer in this case means that there is no service required to perform an intermediary role. There is no Amazon, Facebook, etc in the middle of the operation.
swcurran (Mon, 08 Apr 2019 21:54:55 GMT):
Thanks for the feedback. I'll share that. I agree - it certainly doesn't bother me as a term. Further, looking up the Wikipedia definition (which I should have done first) suggests that his definition was not right and our use of it is correct.
https://en.wikipedia.org/wiki/Peer-to-peer
drummondreed (Tue, 09 Apr 2019 18:51:52 GMT):
I agree that there should be no problem referring to agent-to-agent messaging as P2P, even if it uses routing agents. But the most accurate term is A2A.
kdenhartog (Tue, 09 Apr 2019 20:28:57 GMT):
There may be some nuances of P2P that make this statement true. We're not disabling P2P by any means (agents can talk directly to one another) making it optionally P2P by his definition. However, with certainty we're using end to end encryption.
jljordan_bcgov (Tue, 09 Apr 2019 20:56:08 GMT):
And I understand the "DIDComm" is the further generalized term for A2A communications
pmaruindy (Wed, 10 Apr 2019 02:46:22 GMT):
Has joined the channel.
pranavkirtani (Wed, 10 Apr 2019 03:59:41 GMT):
Has joined the channel.
pranavkirtani (Wed, 10 Apr 2019 04:26:38 GMT):
is there any documentation on settting up indy-sdk on windows 10?
I see the following error src\indy.cc(1133): error C3861: 'indy_pack_message': identifier not found [D:\indy-sdk\indy-sdk\samples\nodejs\node_
modules\indy-sdk\build\indynodejs.vcxproj]
nicholas (Wed, 10 Apr 2019 19:12:27 GMT):
Has joined the channel.
esplinr (Wed, 10 Apr 2019 23:16:42 GMT):
@pranavkirtani Best to ask in #indy-sdk. But first read:
https://github.com/hyperledger/indy-sdk#windows=
esplinr (Wed, 10 Apr 2019 23:16:42 GMT):
@pranavkirtani Best to ask in #indy-sdk. But first read:
https://github.com/hyperledger/indy-sdk#windows
tplooker (Thu, 11 Apr 2019 03:18:38 GMT):
In light of the fact that we have settle on the existence of ephemeral mode type of operation with DIDCom messages. Are we happy to change the current URL based conventions for invites to be more generic i.e change the query parameter from `c_i` to `m` and rely on the decoded type of the message to decide what the message is?
DavidP (Thu, 11 Apr 2019 09:39:51 GMT):
Hi, once we check the values of the wallet (proverSearchCredentialsForProofReq and proverFetchCredentialsForProofReq) with the requested attributtes in the proof of request. Does Indy provide any feature to release which one is missing? Thanks in advance
kdenhartog (Thu, 11 Apr 2019 11:54:21 GMT):
@andrew.whitehead @dbluhm have you 2 (and any others that have independently implemented pack/unpack api) seen PR #1537 in Indy SDK? We're concerned that it will create a breaking change with your implementions. Im thinking it will, so I'd like your opinions on whether we should accept this change. I'm fine with it given the current implemention was declared "experimental" for 1.8.0 release
Cc: @sergey.minaev @lovesh @TelegramSam @danielhardman and @MALodder
kdenhartog (Thu, 11 Apr 2019 11:54:21 GMT):
@andrew.whitehead @dbluhm have you 2 (and any others that have independently implemented pack/unpack api) seen PR #1537 in Indy SDK? We're concerned that it will create a breaking change with your implementions. Im thinking it will, so I'd like your opinions on whether we should accept this change. I'm fine with it given the current implemention was declared "experimental" for 1.8.0 release
Cc: @jovfer @lovesh @TelegramSam @danielhardman and @MALodder
lovesh (Thu, 11 Apr 2019 11:54:23 GMT):
Has joined the channel.
danielhardman (Thu, 11 Apr 2019 12:55:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=nAHvNtPL888yFpmC3) @tplooker I don't think "m" is unique enough to successfully register a URL handler for it. I get the thinking, though. I'm pondering...
dbluhm (Thu, 11 Apr 2019 15:15:06 GMT):
@kdenhartog thanks for the heads up! This will indeed break the JS implementation so I'll make sure and push an update out for that once the PR is merged.
sklump (Thu, 11 Apr 2019 15:45:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=118d6c33-c792-4c54-a90a-d9ba68fe916f) I hate to be that guy, but to what do `m`, `c_i` refer?
esplinr (Thu, 11 Apr 2019 15:52:52 GMT):
Thank you @sklump for being "that guy".
esplinr (Thu, 11 Apr 2019 15:52:55 GMT):
I also don't know.
dbluhm (Thu, 11 Apr 2019 15:54:54 GMT):
in invitation URLs, the c_i parameter is the base64 url encoded connection invitation
TelegramSam (Thu, 11 Apr 2019 16:07:37 GMT):
call recordings from yesterday's meeting posted: https://wiki.hyperledger.org/display/indy/2019-04-10+Agent+Call
Alexi (Thu, 11 Apr 2019 16:20:28 GMT):
@DavidP If understand your question correctly, when you call prover_fetch_credentials_for_proof_req if the result of this is a list. If the list is empty it means wither the attribute is was not found / the attribute given the restrictions was not found
Alexi (Thu, 11 Apr 2019 16:20:28 GMT):
@DavidP If understand your question correctly, when you call prover_fetch_credentials_for_proof_req the result of this is a list. If the list is empty it means wither the attribute is was not found / the attribute given the restrictions was not found
Alexi (Thu, 11 Apr 2019 16:20:28 GMT):
@DavidP If understand your question correctly, when you call prover_fetch_credentials_for_proof_req the result of this is a list. If the list is empty it means either the attribute is was not found / the attribute given the restrictions was not found
Alexi (Thu, 11 Apr 2019 16:20:28 GMT):
@DavidP If understand your question correctly, when you call prover_fetch_credentials_for_proof_req the result of this is a list. If the list is empty it means either the attribute was not found / the attribute given the restrictions was not found
sklump (Thu, 11 Apr 2019 16:20:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CLWwv9wugooMmzyy6) @dbluhm Ah, 'connection invitation', great. What about 'm'? Uhh, message?
dbluhm (Thu, 11 Apr 2019 16:37:19 GMT):
That's what I'd guess @tplooker is suggesting, yeah
andrew.whitehead (Thu, 11 Apr 2019 17:01:47 GMT):
@kdenhartog No problem updating our implementation once it's accepted
sklump (Thu, 11 Apr 2019 17:09:09 GMT):
As long as the API is the same, von_anchor will have no trouble. The only gotcha is the persistence of packed messages under the old regime to unpack with the new.
sklump (Thu, 11 Apr 2019 17:09:09 GMT):
As long as the API is the same, von_anchor will have no trouble. The only gotcha is the persistence of packed messages under the old regime to unpack with the new. I don't think there are any at this stage.
TelegramSam (Thu, 11 Apr 2019 18:47:21 GMT):
One value of `c_i` is that it would be semi-uncommon. `m` is a little to common to provide the same value, but maybe `a_m` for agent message or `d_m` for did message?
andrew.whitehead (Thu, 11 Apr 2019 18:51:48 GMT):
Maybe a little unicode envelope emoji :incoming_envelope:
tplooker (Thu, 11 Apr 2019 20:04:47 GMT):
Im happy with `a_m` or `d_m` as a substitute or even the emoji if its valid in a url @andrew.whitehead :) !
tplooker (Thu, 11 Apr 2019 20:05:32 GMT):
I dont really understand the point that it needs to be less obvious really, as the value of m is either a valid DIDCom message or its not
tplooker (Thu, 11 Apr 2019 20:05:32 GMT):
I dont really understand the point that it needs to be less obvious really, as the value of `m` is either a valid DIDCom message or its not
tomislav (Thu, 11 Apr 2019 20:47:09 GMT):
I feel like both case should supported
- Using a single query parameter for all message types makes for a lot better developer experience and is a scalable solution. It also allows for a use case where the message could be encrypted without revealing the information
- Using separate query parameters has its good use cases, since it allows URL processing in routing/domain services to happen without inspecting the content. This has applications in providing better user experience. For example: a vendor can register universal links where they want to redirect all messages with "m" query to their authenticator app, while everything else to the main wallet app.
Perhaps we shouldn't impose these restrictions now but use both cases and re-evaluate this after some time to see if there is a need to either consolidate or decide not to because we may end up needing only few cases.
tomislav (Thu, 11 Apr 2019 20:47:09 GMT):
I feel like both cases have compelling arguments
- Using a single query parameter for all message types makes for a lot better developer experience and is a scalable solution. It also allows for a use case where the message could be encrypted without revealing the information
- Using separate query parameters has its good use cases, since it allows URL processing in routing/domain services to happen without inspecting the content. This has applications in providing better user experience. For example: a vendor can register universal links where they want to redirect all messages with "m" query to their authenticator app, while everything else to the main wallet app.
Perhaps we shouldn't impose these restrictions now but use both cases and re-evaluate this after some time to see if there is a need to either consolidate or decide not to because we may end up needing only few cases.
tomislav (Thu, 11 Apr 2019 20:47:09 GMT):
I feel like both cases have compelling arguments
- Using a single query parameter for all message types makes for a lot better developer experience and is a scalable solution. It also allows for a use case where the message could be encrypted without revealing the information what type it is.
- Using separate query parameters has its good use cases, since it allows URL processing in routing/domain services to happen without inspecting the content. This has applications in providing better user experience. For example: a vendor can register universal links where they want to redirect all messages with "m" query to their authenticator app, while everything else to the main wallet app.
Perhaps we shouldn't impose these restrictions now but use both cases and re-evaluate this after some time to see if there is a need to either consolidate or decide not to because we may end up needing only few cases.
kdenhartog (Fri, 12 Apr 2019 02:50:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=wasmSDWZ8Xq6kLNpu) @andrew.whitehead Thanks I'll move this forward with them and alert you both once it's merged in SDK @dbluhm
danielhardman (Fri, 12 Apr 2019 23:50:19 GMT):
I have begun writing a new HIPE draft about Message Trust Contexts. I'm doing the early draft work on hackmd.io instead of github as an experiment. Let me know what you think: https://hackmd.io/s/HJG3et9KV
danielhardman (Fri, 12 Apr 2019 23:54:09 GMT):
@tplooker and @sklump @andrew.whitehead We need a value for the query string argument in a URI that makes it possible to register an agent on a mobile device as the handler for all URIs that match the regex. Otherwise a connection invitation will not be intercepted by SSI-aware software but will instead always get handled by the mobile device's browser. Even "c_i" is not great. "m" definitely won't work.
tplooker (Sat, 13 Apr 2019 00:08:35 GMT):
Will review this doc, soon and yes I agree I was merely pointing out that connection invitations are not going to be the only type of DIDCom message send in the url encoded format and hence we need to change this query parameter or url format to reflect that
tplooker (Sat, 13 Apr 2019 00:08:35 GMT):
Will review this doc soon and yes I agree I was merely pointing out that connection invitations are not going to be the only type of DIDCom message send in the url encoded format and hence we need to change this query parameter or url format to reflect that
danielhardman (Sat, 13 Apr 2019 16:43:45 GMT):
@tplooker what about "?didcomm=xxxxx" as the param? Or, to make it even less likely to collide, "?A2A="?
ayushprd (Sat, 13 Apr 2019 18:04:32 GMT):
Has joined the channel.
pranavkirtani (Mon, 15 Apr 2019 06:18:47 GMT):
I found a react native implementation of indy-agent, is there any demo UI where I can try issuing and verification flows?
https://github.com/sovrin-foundation/connector-app
pawanbhobe (Mon, 15 Apr 2019 12:13:49 GMT):
Has joined the channel.
sklump (Mon, 15 Apr 2019 14:04:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CrY7N7vs9vyqQM2CH) @danielhardman Capital letters in URIs are gauche, no? Just looking at `?A2A` instead of `?a2a` makes my little (shift, then backspace after typo) finger complain. I acknowledge that this is the most pedantic comment on the Internet today.
sklump (Mon, 15 Apr 2019 14:04:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CrY7N7vs9vyqQM2CH) @danielhardman Capital letters in URI parameters are gauche, no? Just looking at `?A2A` instead of `?a2a` makes my little (shift, then backspace after typo) finger complain. I acknowledge that this is the most pedantic comment on the Internet today.
sklump (Mon, 15 Apr 2019 14:04:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CrY7N7vs9vyqQM2CH) @danielhardman Capital letters in URI parameters are gauche, no? Because Java URL filters care about case where URL spec does not. Just looking at `?A2A` instead of `?a2a` makes my little (shift, then backspace after typo) finger complain. I acknowledge that this is the most pedantic comment on the Internet today.
sklump (Mon, 15 Apr 2019 14:04:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=CrY7N7vs9vyqQM2CH) @danielhardman Capital letters in URI parameters are gauche, no? Because Java servlet filters care about case where URL spec does not. Just looking at `?A2A` instead of `?a2a` makes my little (shift, then backspace after typo) finger complain. I acknowledge that this is the most pedantic comment on the Internet today.
danielhardman (Mon, 15 Apr 2019 15:31:52 GMT):
@sklump That's *exactly* why I capitalized. We need a parameter in query strings that is *for sure* going to be used only for agents who understand DIDComms, and that will never appear organically in an unrelated query string's params. Otherwise agents registering to handle such URIs won't reliably get them.
sklump (Mon, 15 Apr 2019 15:43:15 GMT):
@danielhardman in that case, ?didcomm=... is better as it explicitly identifies the purpose. My two cents only.
danielhardman (Mon, 15 Apr 2019 15:51:34 GMT):
Okay, that one works for me too.
TelegramSam (Mon, 15 Apr 2019 15:54:17 GMT):
it's worth pointing out that anything we use will not eliminate a secondary check. First, we capture a URL by regex or presence check of the designated URL param. Second, we evaluate the value of that param to see if it is a proper message. If the second step eval fails, we throw ignore it.
The main purpose of designated URL param is to filter as close as reasonably possible to avoid false positives.
danielhardman (Mon, 15 Apr 2019 16:03:50 GMT):
@TelegramSam I agree that the secondary check is necessary--but its existence doesn't make me comfortable about relaxing the precision matching requirement. While it will not be a problem for an agent if it ends up rejecting a URI with a false match on our query parameter, wouldn't it be a problem for the user who clicked on that URI and expected Chrome to open?
BTW, all the docs I'm finding about registering custom URI handlers on Android and iOS assume that the customization comes in the scheme portion of the URI, NOT in a query string. Do you have any links where we can read about registering a URI handler based just on a query string param?
TelegramSam (Mon, 15 Apr 2019 18:20:25 GMT):
My practical knowledge on this topic is old. The Android detail is here: https://developer.android.com/guide/topics/manifest/data-element.html
With a better general overview of both platforms here:
https://medium.com/@ageitgey/everything-you-need-to-know-about-implementing-ios-and-android-mobile-deep-linking-f4348b265b49
TelegramSam (Mon, 15 Apr 2019 18:21:12 GMT):
A scheme handler feels like a much better bet, but we'd loose the boostrapping capability of a new user hitting a website.
helengarneau (Tue, 16 Apr 2019 16:52:20 GMT):
Has joined the channel.
mboyd (Wed, 17 Apr 2019 18:10:19 GMT):
Hi all, I'm trying to run the python reference agent demo on my raspberry pi. I've cross compiled the sdk for my pi's ARMv8 architecture, and moved the `libindy.so` file over to the pi.
How do I set the target path for the reference agent to find the binary?
I tried to link it with the LD_LIBRARY_PATH environment variable, but it doesn't seem to work. Here's the error:
```
_load_cdll: Can't load libindy: libindy.so: cannot open shared object file: No such file or directory
libindy.so: cannot open shared object file: No such file or directory
```
Any help would be appreciated!
mboyd (Wed, 17 Apr 2019 18:10:19 GMT):
Hi all, I'm trying to run the python reference agent demo on my raspberry pi. I've cross compiled the sdk to run on the ARMv8 machine, and moved the `libindy.so` file over to the pi.
How do I set the target path for the reference agent to find the binary? I tried to link it with the LD_LIBRARY_PATH environment variable, but it doesn't seem to work. Here's the error:
```
_load_cdll: Can't load libindy: libindy.so: cannot open shared object file: No such file or directory
libindy.so: cannot open shared object file: No such file or directory
```
Any help would be appreciated!
mboyd (Wed, 17 Apr 2019 18:10:19 GMT):
Hi all, I'm trying to run the python reference agent demo on my raspberry pi. I've cross compiled the sdk for its ARMv8 architecture, and moved the `libindy.so` file over to the pi.
How do I set the target path for the reference agent to find the binary?
I tried to link it with the LD_LIBRARY_PATH environment variable, but it doesn't seem to work. Here's the error:
```
_load_cdll: Can't load libindy: libindy.so: cannot open shared object file: No such file or directory
libindy.so: cannot open shared object file: No such file or directory
```
Any help would be appreciated!
swcurran (Wed, 17 Apr 2019 18:17:15 GMT):
Indy Agent Call in 45 minutes.
Please join us for a rousing conversation about all things Indy Agent.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/856588081
Agenda: https://wiki.hyperledger.org/display/indy/2019-04-17+Agent+Call
swcurran (Wed, 17 Apr 2019 18:17:15 GMT):
Indy Agent Call in 43 minutes.
Please join us for a rousing conversation about all things Indy Agent.
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/856588081
Agenda: https://wiki.hyperledger.org/display/indy/2019-04-17+Agent+Call
mboyd (Wed, 17 Apr 2019 18:17:40 GMT):
(I'm running Raspian... for now...)
sklump (Wed, 17 Apr 2019 18:24:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=mb37NnnEs8d8cuSw4) Naïve guess: export LD_LIBRARY_PATH if you haven't - exporting makes it available to subprocesses.
Broader solution: copy it to `/usr/lib/libindy.so` if there is such a thing on the platform.
sklump (Wed, 17 Apr 2019 18:24:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=mb37NnnEs8d8cuSw4) Naïve guess: export LD_LIBRARY_PATH if you haven't - exporting makes it available to subprocesses.
Broader solution: copy it to `/usr/lib/libindy.so` if there is such a thing on the platform.
sklump (Wed, 17 Apr 2019 18:33:26 GMT):
Also possible: `sudo ldconfig -v`
mboyd (Wed, 17 Apr 2019 18:37:29 GMT):
thank you, I tried the copy
mboyd (Wed, 17 Apr 2019 18:42:32 GMT):
Thank you for the suggestions! I tried all of these with no luck. I'll keep playing around with it though
danielhardman (Thu, 18 Apr 2019 03:54:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=mb37NnnEs8d8cuSw4) @mboyd @mboyd Have you consulted with @saholman ? I know he's been doing work on raspberry pi with libindy lately...
lucafra (Thu, 18 Apr 2019 12:14:33 GMT):
Has joined the channel.
rangak (Thu, 18 Apr 2019 23:11:37 GMT):
Has joined the channel.
TejasKotha (Fri, 19 Apr 2019 17:28:16 GMT):
Has joined the channel.
danielhardman (Fri, 19 Apr 2019 20:31:22 GMT):
I have raised a new HIPE proposal about Message Trust Contexts. https://github.com/hyperledger/indy-hipe/pull/120
Oskar_van_Deventer (Sun, 21 Apr 2019 06:23:21 GMT):
Has joined the channel.
Oskar_van_Deventer (Sun, 21 Apr 2019 06:25:33 GMT):
I just added this pull request (https://github.com/hyperledger/indy-hipe/pull/127). The Hipe on the Connection Protocol (0031) is rather parsimonious on the trust-building step. This pull request proposes to upgrade that step to a formal step. It also provides some examples of risks associated with the connection, and possible exchanges of proofs to reduce these risks.
pioneer (Mon, 22 Apr 2019 06:33:37 GMT):
Has joined the channel.
rchristman (Mon, 22 Apr 2019 16:01:45 GMT):
When will the recording of last week's agent working group call be posted?
mwherman2000 (Tue, 23 Apr 2019 09:52:50 GMT):
@swcurran @tplooker @danielhardman Traditionally, _Pure P2P_ is exactly that: direct peer-to-peer _discovery and communications_. One of the alternatives is _mediated peer-to-peer communications_. I think the latter best characterizes what I know of the Indy A2A communications model. Groove Workspace is/was one of the best examples of both. Groove supported pure peer-to-peer collaboration when the parties were discoverable on the same LAN segment (using UDP broadcasts). Groove also supported (secure encrypted, cross-firewall, inter-organization) mediated peer-to-peer collaboration using Internet-hosted or internally-hosted Groove Relay Servers: https://support.microsoft.com/en-us/help/939806/how-groove-2007-and-sharepoint-2010-use-groove-servers
mwherman2000 (Tue, 23 Apr 2019 09:52:50 GMT):
@swcurran @tplooker @danielhardman Traditionally, _Pure P2P_ is exactly that: direct peer-to-peer _discovery and communications_. One of the alternatives is _mediated peer-to-peer communications_. I think the latter best characterizes what I know of the Indy A2A communications model. Groove Workspace is/was one of the best examples of both. Groove supported pure peer-to-peer collaboration when the parties were discoverable on the same LAN segment (using UDP broadcasts). Groove also supported (secure encrypted, cross-firewall, inter-organization) mediated peer-to-peer collaboration using Internet-hosted or internally-hosted Groove Relay Servers: https://support.microsoft.com/en-us/help/939806/how-groove-2007-and-sharepoint-2010-use-groove-servers
mwherman2000 (Tue, 23 Apr 2019 09:52:50 GMT):
@swcurran @tplooker @danielhardman Traditionally, _Pure P2P_ is exactly that: direct peer-to-peer _discovery and communications_. One of the alternatives is _mediated peer-to-peer communications_. I think the latter best characterizes what I know of the Indy A2A communications model. Groove Workspace is/was one of the best examples of both. Groove supported pure peer-to-peer collaboration when the parties were discoverable on the same LAN segment (using UDP broadcasts). Groove also supported (secure encrypted, cross-firewall, inter-organization) mediated peer-to-peer collaboration using Internet-hosted or internally-hosted Groove Relay Servers: https://support.microsoft.com/en-us/help/939806/how-groove-2007-and-sharepoint-2010-use-groove-servers
Here's a good 3 minute overview of what Groove Workspace is/was: https://www.youtube.com/watch?v=lOAY0fOfNNc
mwherman2000 (Tue, 23 Apr 2019 10:07:01 GMT):
Here's a link to the detailed technical reference for the Groove procotols: https://docs.microsoft.com/en-us/openspecs/office_protocols/ms-grvprot/3d17ffe1-11a4-4eb5-bc4e-72764c444be1
mwherman2000 (Tue, 23 Apr 2019 10:07:28 GMT):
Clipboard - April 23, 2019 6:07 AM
mwherman2000 (Tue, 23 Apr 2019 10:09:53 GMT):
Clipboard - April 23, 2019 6:09 AM
mwherman2000 (Tue, 23 Apr 2019 10:16:03 GMT):
Lastly (maybe), I hope everyone has had a chance to look at this 1 minute video of what true decentralization and truly decentralized agents really looks like: https://www.linkedin.com/feed/update/urn:li:activity:6526373058616262656/
mwherman2000 (Tue, 23 Apr 2019 12:33:34 GMT):
Clipboard - April 23, 2019 8:33 AM
mwherman2000 (Tue, 23 Apr 2019 12:44:22 GMT):
Core P2P networking support in Windows: https://docs.microsoft.com/en-us/dotnet/api/system.net.peertopeer?view=netframework-4.8#remarks
rrishmawi (Tue, 23 Apr 2019 12:52:43 GMT):
Has joined the channel.
tomislav (Tue, 23 Apr 2019 14:18:08 GMT):
Interesting! It seems it's available for all platforms, not just Windows, since it's also part of NET Core - https://docs.microsoft.com/en-us/dotnet/api/system.net.peertopeer?view=netcore-2.2#remarks
kdenhartog (Tue, 23 Apr 2019 16:21:17 GMT):
Thanks @mwherman2000 I'll see what they do to handle MITM issues for cert validation.
kdenhartog (Tue, 23 Apr 2019 16:22:49 GMT):
With regards to the P2P discussion, we also support both mediated P2P (when using mobile devices and non-static IP addresses) and direct P2P (which causes privacy concerns because of traffic analysis)
kdenhartog (Tue, 23 Apr 2019 18:22:35 GMT):
Hey I was just thinking about this. Would it be possible (definitely astronaut architecting here) for an agent to send the message family handler code to a receiver in a verified, secure way?
swcurran (Tue, 23 Apr 2019 18:50:45 GMT):
You mean like Solidity? :scream:
andrew.whitehead (Tue, 23 Apr 2019 19:00:29 GMT):
GitHub link via basicmessage?
kdenhartog (Tue, 23 Apr 2019 19:02:46 GMT):
yeah, I guess being able to download a smartcontract would be useful. I wasn't sure of a way to do it, so any ideas would be fun.
TelegramSam (Tue, 23 Apr 2019 21:36:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=enSZc4cZRvahDxn3J) @rchristman Uploading now. Sorry this took so long.
TelegramSam (Tue, 23 Apr 2019 21:39:17 GMT):
Last Week's Agent Call recording posted: https://wiki.hyperledger.org/display/indy/2019-04-17+Agent+Call
TelegramSam (Tue, 23 Apr 2019 21:39:26 GMT):
@rchristman ^
rchristman (Wed, 24 Apr 2019 15:42:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=Py86ZRz5FqtvjuQoe) @mwherman2000 This LinkedIn link isn't available.
sklump (Wed, 24 Apr 2019 15:44:30 GMT):
Nice Lichtenstein flag interposition for `:li:`. Moment of zen.
rchristman (Wed, 24 Apr 2019 21:36:58 GMT):
When is the Hyperledger Aires call? On the Agent Working group call, I heard tomorrow at 8AM Mountain but I don't see it on the hyperledger public meeting calendar. Is the meeting public?
mwherman2000 (Wed, 24 Apr 2019 21:42:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=LFkoqG2CJKqcaHv3o) @rchristman Blame Lichtenstein ;-)
mwherman2000 (Wed, 24 Apr 2019 21:42:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=LFkoqG2CJKqcaHv3o) @rchristman Blame Lichtenstein ;-) `https://www.linkedin.com/feed/update/urn:li:activity:6526373058616262656/`
mwherman2000 (Wed, 24 Apr 2019 21:42:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=LFkoqG2CJKqcaHv3o) @rchristman Blame Lichtenstein ;-) `https://www.linkedin.com/feed/update/urn:li:activity:6526373058616262656/` ...I guess you'll have to copy and paste.
swcurran (Wed, 24 Apr 2019 22:00:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=kfaWqKABQkS5ke7JX) @rchristman The call is the Hyperledger TSC - Technical Steering Committee - Call where they will discuss the Aries project proposal.
The calender is here - https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings
That specific call is tomorrow (April 25th) at 2PM GMT which is 10AM Eastern / 7AM Pacific.
atomeel (Fri, 26 Apr 2019 10:34:16 GMT):
Has joined the channel.
mwherman2000 (Fri, 26 Apr 2019 15:32:15 GMT):
@swcurran Is this a recurring weekly meeting?
swcurran (Fri, 26 Apr 2019 15:33:01 GMT):
Yes - it's the meeting of the elected technical leads of Hyperledger.
raj_shekhar (Mon, 29 Apr 2019 08:04:45 GMT):
Has joined the channel.
esplinr (Wed, 01 May 2019 14:44:57 GMT):
Did we decide to cancel the Indy Agent call today in deference to IIW?
I think we did, and it doesn't show up on the Hyperledger calendar, but we didn't note it in meeting minutes from last week so I want to confirm.
swcurran (Wed, 01 May 2019 15:05:31 GMT):
Yes - it is cancelled and that's why it's not in the calendar. Cool if you could add it to the notes. Oh, and wish you were here.
esplinr (Wed, 01 May 2019 15:08:07 GMT):
Thanks for confirming @swcurran .
esplinr (Wed, 01 May 2019 15:08:32 GMT):
Yes, I'm sad to miss this round of IIW. Hopefully I can muscle my way onto the list for October.
troyronda (Thu, 02 May 2019 14:22:35 GMT):
I am excited about the potential of the Aries project to accelerate the development of a common framework for ledger-anchored digital identity. I thought it would be great to share with you some of our next open steps. We would also like to contribute components to the larger Hyperledger community. Here is a link to a document providing an introduction (related to both Fabric and Aries): https://docs.google.com/document/d/1ENMO-S7i0ef09IRx5teE-eJbRMFsaKSXEdatcufvjPM
nage (Fri, 03 May 2019 01:38:06 GMT):
#aries is now available for initial project coordination
andrew.whitehead (Fri, 03 May 2019 06:17:07 GMT):
@nage I think the channel has limited access
helengarneau (Fri, 03 May 2019 16:40:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-agent?msg=k55OFKMyzRBMJiaopb) FYI- HL Marketing will do a formal announcement next week. May be helpful to stay quiet until they get the organized press around it. Thanks!
drummondreed (Sun, 05 May 2019 23:51:58 GMT):
@helengarneau Thanks for the heads up. Please do post any links to formal announcements both here and in the new #aries channel.
tplooker (Mon, 06 May 2019 03:26:24 GMT):
The Mattr team is pleased to announce the open sourcing of osma - an open source mobile agent built on top of AgentFramework (https://github.com/streetcred-id/agent-framework), this project is still in development but we hope it will be of great community value to accelerate the development of mobile agents. Check it out at https://github.com/mattrglobal/osma and get in touch if you have any queries!
atomeel (Mon, 06 May 2019 07:00:09 GMT):
@tplooker Is the osma project targeting iOS or Android? I pulled the source to take a look and couldn't get the release configuration to build yet: I tested on Android ARM64 phone + x86 AVD and iPhone actual device + simulator, and so far it only worked on the iPhone simulator on debug configuration after manually linking the pre-built libs from the agent-framework repo, not sure if this is normal or not? (noob to Xamarin/C#, so very likely to be my problem :smile: )
tomislav (Mon, 06 May 2019 16:18:23 GMT):
@atomeel It's Xamarin Forms targeting both iOS and Android. Generally, Release mobile configurations are used in distribution pipelines tied to distribution signing artifacts. Local deployments should run fine in Debug configuration.
sklump (Mon, 06 May 2019 16:30:34 GMT):
Has left the channel.
tplooker (Mon, 06 May 2019 19:31:55 GMT):
@atomeel so you have got iOS but not android working? In regards to the libraries, did you call git lfs pull when you cloned it? As the libs folder in each platform project should have the binaries?
tomislav (Mon, 06 May 2019 19:36:43 GMT):
@tplooker There are some missing libs in the repo, inadvertently removed when moving things. There's a PR pending the fixes this.
tplooker (Mon, 06 May 2019 19:44:28 GMT):
@tomislav thanks! Will review soon
TelegramSam (Tue, 07 May 2019 17:39:44 GMT):
Indy Agent Call Tomorrow! We will be reporting on IIW and discussing Aries. Please come with thoughts to share about IIW if you attended.
https://wiki.hyperledger.org/display/indy/2019-05-08+Agent+Call
ianco (Tue, 07 May 2019 22:54:37 GMT):
I'm getting some errors building the Android version, running on a Mac using Visual Studio Community if that matters:
1. Can't find AgentFrameWork.Core >= 4.0.0-preview.365
2. ConnectionsViewModel.cs(47,47): Error CS0308: The non-generic method 'MessageUtils.DecodeMessageFromUrlFormat(string)' cannot be used with type arguments (CS0308) (Osma.Mobile.App)
tplooker (Tue, 07 May 2019 22:55:52 GMT):
@ianco is this with the current head of master?
tplooker (Tue, 07 May 2019 23:11:44 GMT):
@ianco can you try pulling the head of master now? I believe this was due to some environments not dealing with the dependency when it is transient, I have now made this explicit for the Osma.Mobile.App project
ianco (Wed, 08 May 2019 00:07:47 GMT):
I'll give it a try now
ianco (Wed, 08 May 2019 00:07:50 GMT):
thanks
ianco (Wed, 08 May 2019 00:10:31 GMT):
The compile error is fixed but I still can't find AgentFrameWork.Core >= 4.0.0-preview.365
ianco (Wed, 08 May 2019 00:10:46 GMT):
nuget configuration? maybe I'm not pointing to the right repo?
tplooker (Wed, 08 May 2019 00:12:29 GMT):
@ianco the preview packages build to this feed https://www.myget.org/feed/agent-framework/package/nuget/AgentFramework.Core
ianco (Wed, 08 May 2019 00:12:55 GMT):
ok thanks
tplooker (Wed, 08 May 2019 00:13:05 GMT):
You should see that there is a local nuget package configuration next to the solution that adds this as another package feed https://github.com/mattrglobal/osma/blob/master/src/nuget.config
ianco (Wed, 08 May 2019 00:13:45 GMT):
I'll try it on windows, it's possibly an issue with the mac community version
ianco (Wed, 08 May 2019 00:13:54 GMT):
... of Visual Studio
tplooker (Wed, 08 May 2019 00:14:34 GMT):
Try adding a custom package feed with the following URL https://www.myget.org/F/agent-framework/api/v3/index.json
tplooker (Wed, 08 May 2019 00:14:55 GMT):
If it does not already exist
ianco (Wed, 08 May 2019 00:16:24 GMT):
ok I think I managed to add it ... it was listed as a prerelease package so I had to explicitely pick it
ianco (Wed, 08 May 2019 00:17:24 GMT):
rebuilding now ...
tplooker (Wed, 08 May 2019 00:17:36 GMT):
Yeap also is it asking for 4.0.0-preview.365 or 635
ianco (Wed, 08 May 2019 00:22:58 GMT):
Build is working but when I try to deploy (local nexus emulator) I get "cannot determine abi of native library libs/armeabi/libindy.so"
tplooker (Wed, 08 May 2019 00:23:48 GMT):
Cool you also need to call `git lfs pull` before you build as the indy binaries are stored using git fls
ianco (Wed, 08 May 2019 00:23:58 GMT):
ok
ianco (Wed, 08 May 2019 00:23:59 GMT):
thanks
tplooker (Wed, 08 May 2019 00:24:39 GMT):
I have written about it in here https://github.com/mattrglobal/osma/blob/master/docs/development.md however I should probably put a reference to this issue in the root readme
ianco (Wed, 08 May 2019 00:26:10 GMT):
ok installing ...
ianco (Wed, 08 May 2019 00:35:08 GMT):
Built and deployed, but it won't run unfortunately :-(
ianco (Wed, 08 May 2019 00:35:23 GMT):
Tried on my emulator (nexus) and also on my physical device
tplooker (Wed, 08 May 2019 00:35:36 GMT):
Does the app crash?
ianco (Wed, 08 May 2019 00:35:37 GMT):
It just stops right away ...
ianco (Wed, 08 May 2019 00:35:39 GMT):
yes
tplooker (Wed, 08 May 2019 00:35:51 GMT):
Any reported error in the output?
ianco (Wed, 08 May 2019 00:36:12 GMT):
No it just says "Unfortunately, Osma has stopped"
tplooker (Wed, 08 May 2019 00:36:17 GMT):
Lets take this to private chat
ianco (Wed, 08 May 2019 00:36:20 GMT):
k
jcabdu (Wed, 08 May 2019 09:22:18 GMT):
Has joined the channel.
TelegramSam (Wed, 08 May 2019 14:52:07 GMT):
Also, Rocketchat just got threads. :thumbsup:
ianco (Wed, 08 May 2019 15:52:50 GMT):
FYI for anyone trying to build the Osma app:
- make sure you install git lfs (see https://github.com/mattrglobal/osma/blob/master/docs/development.md)
- disable mono shared libraries (under project options | Android build)
dbluhm (Wed, 08 May 2019 17:59:45 GMT):
Oh dang
tplooker (Wed, 08 May 2019 18:11:22 GMT):
I will update the readme soon ^ to make this clearer
swcurran (Wed, 08 May 2019 18:41:09 GMT):
Threads on rocketchat seem to suck, just like on slack :-(
dbluhm (Wed, 08 May 2019 19:01:32 GMT):
Final Indy Agent call happening now!
dbluhm (Wed, 08 May 2019 19:01:32 GMT):
Indy Agent call happening now!
dbluhm (Wed, 08 May 2019 19:02:23 GMT):
Feel free to join us:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/856588081
Meeting Agenda and Notes: https://wiki.hyperledger.org/display/indy/Indy+Agent+Working+Group
Or iPhone one-tap :
US: +16699006833,,856588081# or +16465588656,,856588081#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656
Meeting ID: 856 588 081
International numbers available: https://zoom.us/u/akZ4IVIpQ
mwherman2000 (Thu, 09 May 2019 14:54:17 GMT):
Is an Indy Agent "formally" expected to have a UI component? ...e.g. either a GUI or web UI? ...is the the boundary of an Agent limited to it being a mid-tier server exposing a set of services? ...e.g. comms, wallet, etc. ....asking for a friend ;-)
mwherman2000 (Thu, 09 May 2019 14:54:17 GMT):
Is an Indy Agent "formally" expected to have a UI component? ...e.g. either a GUI or web UI? ...or, is the the boundary of an Agent limited to it being a mid-tier server exposing a set of services? ...e.g. comms, wallet, etc. ....asking for a friend ;-)
TelegramSam (Thu, 09 May 2019 14:59:49 GMT):
Agents can be headless, or have an interface. There are places for both.
TelegramSam (Thu, 09 May 2019 15:03:05 GMT):
I expect that many headless agents will be compatible with a UI agent used for remote admin functions.
mwherman2000 (Thu, 09 May 2019 15:18:09 GMT):
I'm thinking something grander ...an Indy Agent o/s...
mwherman2000 (Thu, 09 May 2019 15:20:24 GMT):
Some notes here on Twitter: https://twitter.com/mwherman2000/status/1125713557574778883
mwherman2000 (Thu, 09 May 2019 15:20:24 GMT):
Some notes can be found here on Twitter: https://twitter.com/mwherman2000/status/1125713557574778883
mwherman2000 (Thu, 09 May 2019 15:23:08 GMT):
Clipboard - May 9, 2019 11:20 AM
TelegramSam (Thu, 09 May 2019 16:59:33 GMT):
Call recordings posted from yesterday. The recordings include several hours of post meeting conversation about the Peer DID Method. https://wiki.hyperledger.org/display/indy/2019-05-08+Agent+Call
daidoji (Thu, 09 May 2019 17:50:22 GMT):
Listening just now, was it resolved where the fraud group would be coordinating?
daidoji (Thu, 09 May 2019 17:50:26 GMT):
I'd be interested in contributing
daidoji (Thu, 09 May 2019 17:50:31 GMT):
or at least lurking
TelegramSam (Thu, 09 May 2019 19:02:32 GMT):
@danielhardman is the ringleader there.
TelegramSam (Thu, 09 May 2019 19:02:55 GMT):
and I know your involvement would be appreciated. @daidoji
danielhardman (Fri, 10 May 2019 00:59:53 GMT):
@daidoji Please DM me your email address, and I'll add you into the thread.
mwherman2000 (Fri, 10 May 2019 01:41:20 GMT):
FYI: https://twitter.com/mwherman2000/status/1126625831323938816
drummondreed (Fri, 10 May 2019 05:07:37 GMT):
Love 'em and hate 'em. But I have learned to love 'em more than I hate 'em.
pknowles (Fri, 10 May 2019 05:30:03 GMT):
Hot off the press: Google is looking to add Electronic ID support so developers can build mobile apps that can be securely used as an ID. Discuss. https://venturebeat.com/2019/05/09/google-is-bringing-electronic-ids-to-android/
iamtxena (Fri, 10 May 2019 07:15:59 GMT):
Has joined the channel.
SteveMagennis (Fri, 10 May 2019 13:22:08 GMT):
Has joined the channel.
mhailstone (Fri, 10 May 2019 15:13:50 GMT):
:point_up: SSI in the OS?! ;) Module extensions and decentralized apps (dApps) might be a key feature going forward for agents.
mhailstone (Fri, 10 May 2019 15:13:50 GMT):
:point_up: SSI in the OS?! ;) Module extensions and decentralized apps (dApps) might be a key feature going forward for agents. @TelegramSam
TelegramSam (Fri, 10 May 2019 17:02:01 GMT):
They can help a deep conversation not clog the channel.
mhailstone (Fri, 10 May 2019 17:05:30 GMT):
If Microsoft Windows, OSX, and Chrome OS are all based on linux, all we need to do is get SSI in the linux kernel and we're set, right? :D
https://www.zdnet.com/article/all-chromebooks-will-also-be-linux-laptops-going-forward/
https://www.theverge.com/2019/5/6/18534687/microsoft-windows-10-linux-kernel-feature
SteveMagennis (Fri, 10 May 2019 22:24:14 GMT):
Looks like the first 'killer use case' for DIDs may begin in the UK on July 15, ...sigh.
tomislav (Mon, 13 May 2019 17:07:46 GMT):
Interesting. I'm curious if they will consider the option of using verifiable creds designs for this. For the record, I think this law is ridiculous, sex demonization needs to stop, and access to information must not be restricted.
TelegramSam (Tue, 14 May 2019 14:30:09 GMT):
Tomorrow's call link and info posted in #aries channel. Same time, new name.
vindard (Tue, 14 May 2019 20:58:32 GMT):
Has joined the channel.
knagware9 (Wed, 15 May 2019 07:38:11 GMT):
Has joined the channel.
MeSSeRz (Thu, 16 May 2019 09:34:46 GMT):
Has joined the channel.
pleerock (Thu, 16 May 2019 09:34:51 GMT):
Has joined the channel.
pleerock (Thu, 16 May 2019 09:34:52 GMT):
Hey Guys! Can anyone give me a link to a git repository with working android agent sample?
kdenhartog (Thu, 16 May 2019 10:42:14 GMT):
@pleerock here's one https://github.com/mattrglobal/osma
pleerock (Thu, 16 May 2019 10:49:46 GMT):
@kdenhartog Xamarin? cmon what about standard java/kotlin everybody uses?
kdenhartog (Thu, 16 May 2019 10:50:35 GMT):
I don't know of any OS native apps. If you find one I'd love to know about it.
kdenhartog (Thu, 16 May 2019 10:50:35 GMT):
I don't know of any OSS native apps. If you find one I'd love to know about it.
kdenhartog (Thu, 16 May 2019 10:50:35 GMT):
I don't know of any OSS native agent apps. If you find one I'd love to know about it.
pleerock (Thu, 16 May 2019 10:59:38 GMT):
Sad. Maybe somebody else know?
TelegramSam (Thu, 16 May 2019 12:47:45 GMT):
@pleerock I'm unaware of any open source native android agent apps.
Zohaib_Sohail (Thu, 16 May 2019 13:03:33 GMT):
{ IndyError: CommonInvalidState
at Object.callback (/home/zohaib/indy-education/LFS171x/indy-material/nodejs-test/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)
name: 'IndyError',
message: 'CommonInvalidState',
indyCode: 112,
indyName: 'CommonInvalidState' }
Zohaib_Sohail (Thu, 16 May 2019 13:03:45 GMT):
Any help with the error above?
Zohaib_Sohail (Thu, 16 May 2019 13:04:36 GMT):
i am trying to run agent code simply on node without docker-composer or containers?
swcurran (Thu, 16 May 2019 15:35:28 GMT):
@Zohaib_Sohail - if you are trying to go beyond running the node example - suggest that you go to the https://github.com/hyperledger/indy-agent repo, nodejs folder. The education repo you are using is a snapshot of that repo taken for the edX course - a snapshot so it stays stable. The nodejs implementation in the indy-agent repo has evolved a little from there.
Not certain it will solve your problem, but it's a better starter location if you are going to dig deeper into the nodejs agent.
swcurran (Thu, 16 May 2019 15:39:18 GMT):
FYI - note that nodejs agent is not in active development right now. If you know python - take a look at the python folder in the indy-agent repo. It's in active development.
There is also a second python agent in active development, and one in .NET/C# if those are of interest.
axel (Thu, 16 May 2019 16:42:54 GMT):
hi everyone, on the call Sean mentioned the European Identity and Cloud conference as being next week
axel (Thu, 16 May 2019 16:43:25 GMT):
but according to the website I'm finding (https://www.kuppingercole.com/events/eic2019) it seems it's happening right now (14 - 17 May)
axel (Thu, 16 May 2019 16:43:37 GMT):
am I getting this wrong?
dbluhm (Thu, 16 May 2019 18:11:10 GMT):
Announcing significant updates to the Agent Test Suite that will significantly improve the experience during testing; more details in the notes on the PR (https://github.com/hyperledger/indy-agent/pull/116) and in the Test Suite README (https://github.com/hyperledger/indy-agent/tree/master/test_suite).
@lovesh has also contributed tests for some of the "unhappy" paths through the connection protocol and tests for the `~thread` and `~timing` decorators.
dbluhm (Thu, 16 May 2019 18:11:10 GMT):
Announcing significant updates to the Agent Test Suite that will greatly improve the experience during testing; more details in the notes on the PR (https://github.com/hyperledger/indy-agent/pull/116) and in the Test Suite README (https://github.com/hyperledger/indy-agent/tree/master/test_suite).
@lovesh has also contributed tests for some of the "unhappy" paths through the connection protocol and tests for the `~thread` and `~timing` decorators.
circlespainter (Sat, 18 May 2019 07:43:16 GMT):
Has joined the channel.
DarionHernandez (Tue, 21 May 2019 23:34:44 GMT):
Has joined the channel.
ilya1w (Wed, 22 May 2019 03:53:44 GMT):
Has joined the channel.
Liam-Tait (Wed, 22 May 2019 06:18:31 GMT):
Has joined the channel.
jucah (Wed, 22 May 2019 17:04:30 GMT):
Has joined the channel.
danielhardman (Thu, 23 May 2019 17:24:34 GMT):
ALL:
The Peer DID Method Spec is maturing nicely, thanks to thoughtful improvements from many--especially Oskar van Deventer and Christian Lundkvist. We still have more to do, though.
You can help in the following two ways:
1. Please review this PR and express an opinion about whether it should be accepted: https://github.com/openssi/peer-did-method-spec/pull/32
This PR would change the way a peer DID's numeric basis is generated. Instead of generating from the initial public key, it would use a sha256 hash of the initial version of the DID Doc, which means the initial DID Doc could have any number of keys, and that it wouldn't be vital to rotate the one and only initial key value immediately after being used to generate the DID.
2. Please read at least section 5 of Oskar's doc here: https://docs.google.com/document/d/1SgKvuG7u0r5UkaDRnnkQmnarVylCx5VF5y0eIyV-I6Y/edit. Perhaps we can discuss some of the questions he raises in our next Aries call.
danielhardman (Thu, 23 May 2019 19:16:52 GMT):
Socializing a possible convention: I'd like to suggest that *protocols be named by a verb, not a noun*. For example, we would have the "issue credential" protocol, not the "credential issuance" protocol; "connect" instead of "connection".
My reasoning: You can do lots of things with a noun. With the noun "connection", for example, I could "build" it, "destroy" it, "maintain" it, etc. By naming protocols after a noun, I think we're creating an inherent fuzziness that would go away if we named them with a verb or verb phrase.
shenoy (Mon, 27 May 2019 15:27:42 GMT):
Has joined the channel.
nicola.attico (Mon, 27 May 2019 17:29:52 GMT):
Has joined the channel.
josh.graber (Wed, 29 May 2019 12:47:52 GMT):
Has joined the channel.
RodrigoMedeiros (Wed, 29 May 2019 17:10:43 GMT):
Has joined the channel.
SeanBohan (Wed, 29 May 2019 17:49:44 GMT):
Has joined the channel.
Alexi (Wed, 29 May 2019 18:31:54 GMT):
I was wondering if there was someone here form the bcgov team that could help me with using indy-catalyst (or anyone else who is familiar with the project). I got the agent to run per these instructions (https://github.com/bcgov/indy-catalyst/tree/master/agent) But there is a lack of documentation on how to work with the agent post set up, e.g. what calls can be made and what to pass with those calls. Appreciate the help!
swcurran (Wed, 29 May 2019 18:39:00 GMT):
We can help. DM me to start and I'll connect you wil the right person on the team. If you are just getting started with it and want to run it locally to see it running, I suggest you use this - https://github.com/bcgov/greenlight/blob/master/docker/VONQuickStartGuide.md. That's the production version.
indycatalyst that you are working with is still in progress and will soon replace the current production version, bringing a well-designed agent, a more scalable credential registry and an indy-agent HIPE/Aries RFC basis for interoperability.
swcurran (Wed, 29 May 2019 18:39:00 GMT):
We can help. DM me to start and I'll connect you wil the right person on the team. If you are just getting started with it and want to run it locally to see it running, I suggest you use this - https://github.com/bcgov/greenlight/blob/master/docker/VONQuickStartGuide.md. That's the production version.
indycatalyst that you are working with is still in progress and will soon replace the current production version, bringing a well-designed agent, a more scalable credential registry and an indy-agent HIPE/Aries RFC basis for interoperability. If you are building towards production, we'll want to help you get going on this version.
ptab-pawan (Thu, 30 May 2019 20:28:20 GMT):
Has joined the channel.
paliwalg (Fri, 31 May 2019 08:23:33 GMT):
Has joined the channel.
ibrahimel (Tue, 04 Jun 2019 08:52:02 GMT):
Has joined the channel.
DougKing (Tue, 04 Jun 2019 14:21:18 GMT):
Has joined the channel.
ptab-pawan (Wed, 05 Jun 2019 03:04:47 GMT):
enalibvcx
rfu2k (Wed, 05 Jun 2019 21:56:09 GMT):
Has joined the channel.
rfu2k (Wed, 05 Jun 2019 21:56:10 GMT):
@TelegramSam hi there, this is probably silly to ask, when you said " I'm unaware of any open source native android agent apps." I assume the same also for iOS? Just wanted to double check :) like @kdenhartog and @pleerock above I'd be very keen to see an open source native example to learn from. (Also I hope a React Native example using indy may turn up someday for similar reasons :) )
rfu2k (Wed, 05 Jun 2019 21:56:10 GMT):
@TelegramSam hi there, this is probably silly to ask, when you said " I'm unaware of any open source native android agent apps." I assume the same also for iOS? Just wanted to double check :) like @kdenhartog and @pleerock above I'd be very keen to see an open source native example, so i can learn from. (Also I hope a React Native example using indy may turn up someday for similar reasons :) )
rfu2k (Wed, 05 Jun 2019 21:56:10 GMT):
@TelegramSam hi there, this is probably silly to ask, when you said " I'm unaware of any open source native android agent apps." I assume the same also for iOS? Just wanted to double check :) like @kdenhartog and @pleerock above I'd be very keen to see an open source native mobile example, so i can learn from. (Also I hope a React Native example using indy may turn up someday for similar reasons :) )
kdenhartog (Wed, 05 Jun 2019 22:35:25 GMT):
I'm not aware of an OS iOS app, but there is one by streetcred (@tomislav ) which is available on the Apple store I believe
kdenhartog (Wed, 05 Jun 2019 22:35:25 GMT):
I'm not aware of an OS iOS app, but there is one by streetcred @tomislav which is available on the Apple store I believe
swcurran (Thu, 06 Jun 2019 02:03:03 GMT):
OSMA is an open source Android and iOS mobile agent app.
swcurran (Thu, 06 Jun 2019 02:07:54 GMT):
Streetcred is in testflight, not the full app store
tplooker (Thu, 06 Jun 2019 02:18:07 GMT):
@rfu2k please checkout https://github.com/mattrglobal/osma
rfu2k (Thu, 06 Jun 2019 10:15:35 GMT):
thanks so much for the OSMA suggestion, I am looking at it and hope to learn what I can. As @pleerock mentioned above, I see it is a Xamarin project built in C# using a dependency on streetcred AgentFramework project, which itself is an abstraction on top of Indy SDK. I never heard of Xamarin before seeing this so atleast I've learned that so far :upside_down:
If anyone discovers something closer to Java native mobile app using the indy sdk they'll be showered by virtual warm wishes and praise by noobs like me trying to get a head start on learning all this stuff :thumbsup: :smile: The closest thing I found searching around might be https://github.com/AxelNennker/DroidLibIndy but I haven't looked at it in any detail, atleast seems to show the setup of a new Android Studio project...
rfu2k (Thu, 06 Jun 2019 10:15:35 GMT):
thanks so much for the OSMA suggestion, I am looking at it and hope to learn what I can. As @pleerock mentioned above, I see it is a Xamarin project built in C# using a dependency on streetcred AgentFramework project, which itself is an abstraction on top of Indy SDK. I never heard of Xamarin before seeing this so atleast I've learned that so far :upside_down:
If anyone discovers something closer to Java native mobile app using the indy sdk they'll be showered by virtual warm wishes and praise by noobs like me trying to get a head start on learning all this stuff :thumbsup: :smile: The closest thing I found searching around might be https://github.com/AxelNennker/DroidLibIndy but I haven't looked at it in any detail, atleast seems to show the setup of a Android Studio project...
kdenhartog (Thu, 06 Jun 2019 17:04:11 GMT):
@rfu2k my understanding is there's a few people interested in a react native implementation. There's one that is hard to build called the connector-app built with react native.
It's found here: https://github.com/sovrin-foundation/connector-app
As @tplooker and @swcurran pointed out theres OSMA which is not native, but is open source.
This may be another interesting project worth looking at which appears to be a native app and open source: https://github.com/Quintor/StudyBitsWallet
The best place to reference them is normally here, but it didn't have @AxelNennker listed: https://github.com/hyperledger/indy-agent
mwherman2000 (Fri, 07 Jun 2019 11:13:34 GMT):
I'm back ...I've been busy with calving season and winning back on old girlfriend. 🙂
pradeepjain (Sat, 08 Jun 2019 19:07:33 GMT):
Has joined the channel.
pradeepjain (Sat, 08 Jun 2019 19:07:36 GMT):
Hi All, I very new to Indy-Agent. Here I saw the getting started use case of Alice to get the Transcript from Faber university and got the job in Acme corporation based on the transcript and submit the employment proof credential to Thrift bank to get done the lone approval. This complete use case having only one piece of code without any indy- Agent implementation. If this use case working without Indy-Agent then what is the use of Indy-agent for this or any other cases which includes the IoT devices as well. Please let me know what is the exact use of indy-Agent and advantages to have indy-agent. Thanks in Advance.
pradeepjain (Sat, 08 Jun 2019 19:07:36 GMT):
Hi All, I am very new to Indy-Agent. Here I saw the getting started use case of Alice to get the Transcript from Faber university and got the job in Acme corporation based on the transcript and submit the employment proof credential to Thrift bank to get done the lone approval. This complete use case having only one piece of code without any indy- Agent implementation. If this use case working without Indy-Agent then what is the use of Indy-agent for this or any other cases which includes the IoT devices as well. Please let me know what is the exact use of indy-Agent and advantages to have indy-agent. Thanks in Advance.
mboyd (Sat, 08 Jun 2019 21:03:18 GMT):
Hi @pradeepjain,
The reason that the [getting started code](https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/getting-started.ipynb) is only in one script is to simply demonstrate the range of API calls that different entities can make to the indy SDK in order to create and exchange credentials. The code acts as if Alice, Faber College, Acme corp, and Thrift bank are all storing their wallets on a single device.
This simplification eliminates the complexity that arises when credentials are exchanged across a variety of different uses cases, operating systems, devices, transport protocols, and privacy needs. The real world uses of Indy become very complicated when thinking about all of these layers.
The Indy-Agent and [Hyperledger Aries](https://wiki.hyperledger.org/display/ARIES/Hyperledger+Aries) project provides the necessary cryptographic wallet infrastructure and a common set of protocols to enable blockchain-rooted, peer to peer interactions in the real world. This includes use cases like the Alice demo, but is meant to expand to many use cases even including IoT devices. It's pretty exciting stuff, and we're happy to have you here building with us.
Let us know if you have any other questions! Thanks
pradeepjain (Sun, 09 Jun 2019 18:02:52 GMT):
Hi
pradeepjain (Sun, 09 Jun 2019 18:03:47 GMT):
Hi michaeldboyd,
pradeepjain (Sun, 09 Jun 2019 18:24:11 GMT):
Hi michaeldboyd
Thanks for reply and useful information. So what I understood we need to use Indy-agent for peer to peer interactions in the real world and If we want to include the IoT devices into similar type of use cases for digital identities of devices or anything. Also I found an indy-agent for IoT devices https://github.com/evernym/connectathon-agent Can I use this agent for IoT devices or you want to suggest something different. Thanks
pradeepjain (Sun, 09 Jun 2019 18:24:11 GMT):
Hi michaeldboyd
Thanks for reply and useful information. So what I understood we need to use Indy-agent for peer to peer interactions in the real world and If we want to include the IoT devices into similar type of use cases for digital identities of devices or anything. Also I found an indy-agent for IoT devices https://github.com/evernym/connectathon-agent Can I use this agent for IoT devices or you want to suggest something different. Also How Hyperledger-Aries will be helpful for IoT devices. Thanks
mboyd (Sun, 09 Jun 2019 19:13:39 GMT):
that would be a good start. Follow along here to learn more about the aries developments. once it progresses a bit further, it will likely be what you're want to use for IoT agents
haniavis (Tue, 11 Jun 2019 19:16:52 GMT):
Hi all,
haniavis (Tue, 11 Jun 2019 19:16:52 GMT):
Hi all, I was learning for some time now Indy project and now I am at the point to start implementing an Indy application on top of a private Indy's ledger, to provide Decentralized Identities. But now there is the Aries project where they provide interoperable agent among others. Which is the way forward? Should I jump to Aries and keep Indy just for the pool of nodes and the ledger?
esplinr (Tue, 11 Jun 2019 23:48:27 GMT):
See my response in #aries
sukalpomitra (Wed, 12 Jun 2019 03:27:03 GMT):
Has joined the channel.
zzx02 (Fri, 14 Jun 2019 06:00:50 GMT):
Has joined the channel.
Unni_1994 (Mon, 17 Jun 2019 12:48:08 GMT):
Has joined the channel.
Unni_1994 (Mon, 17 Jun 2019 12:57:13 GMT):
While I am running this command
make docker-start PORT=8094
I am getting an error
`docker run -it -p $PORT:$PORT -e PORT=$PORT --name indy-agent_$PORT indy-agent
Traceback (most recent call last):
File "indy-agent.py", line 20, in
yutopyan (Tue, 18 Jun 2019 14:39:19 GMT):
Has joined the channel.
carlojb01 (Wed, 19 Jun 2019 17:23:41 GMT):
Has joined the channel.
carlojb01 (Wed, 19 Jun 2019 17:23:45 GMT):
Hey guys - I've been exploring the indy-sdk implementation in nodejs. When I run npm i --save indy-sdk the following error is thrown: LINK : fatal error LNK1181: cannot open input file '.lib' ... I've also run into issues when installing libindy on Windows 10 (so I do not have it installed right now, maybe thats what is causing the error?). Everything runs successfully with Docker though.
Environment Specs:
OS: Windows 10 (x64)
Libindy Installed: No
Node Version: 10.15
dbluhm (Wed, 19 Jun 2019 17:52:19 GMT):
@carlojb01 #indy-sdk is probably the correct channel for your question :slight_smile: If you're willing to, it would also be very helpful if you opened the question on Stack Overflow then linked to your question on #indy-sdk so the answer becomes discoverable by others in the future.
dbluhm (Wed, 19 Jun 2019 17:53:56 GMT):
Looks like recent changes to the python reference agent may have broken the docker setup... I'll take a look at it. Thanks for reporting and sorry for the late response
carlojb01 (Wed, 19 Jun 2019 18:00:00 GMT):
Will Do! Thanks!
danielhardman (Wed, 19 Jun 2019 19:40:41 GMT):
For those that are wondering about the relationship between Indy and Aries, here's one attempt at an answer: https://github.com/hyperledger/aries/blob/master/README.md#relationship-to-hyperledger-indy
Unni_1994 (Thu, 20 Jun 2019 12:39:31 GMT):
Thanks
esplinr (Thu, 20 Jun 2019 20:56:08 GMT):
@rjones Can you set the "Announcement" for this channel? I suggest: "Indy Agents are being implemented as part of Aries. Join us in #aries for discussion."
rjones (Thu, 20 Jun 2019 20:56:10 GMT):
Has joined the channel.
rjones (Thu, 20 Jun 2019 22:04:44 GMT):
esplinr
rjones (Thu, 20 Jun 2019 22:04:55 GMT):
@esplinr go for it :)
esplinr (Thu, 20 Jun 2019 22:07:32 GMT):
Development discussion and support for reference implementations of Agents on top of Hyperledger Indy.
esplinr (Thu, 20 Jun 2019 22:07:32 GMT):
Indy Agents are being implemented as part of Aries. Join us in #aries for discussion.
esplinr (Thu, 20 Jun 2019 22:09:03 GMT):
Thank you @rjones !
rjones (Thu, 20 Jun 2019 22:09:54 GMT):
I think you could mark the channel read-only as well, if it's truly dead
rjones (Thu, 20 Jun 2019 22:10:18 GMT):
or at least I can
esplinr (Thu, 20 Jun 2019 22:11:02 GMT):
I suggest we wait a bit first.
esplinr (Thu, 20 Jun 2019 22:11:29 GMT):
Until after people have migrated to Aries agents.
rjones (Thu, 20 Jun 2019 22:11:36 GMT):
sure, just let me know. It isn't fatal if you leave it read-write
esplinr (Thu, 20 Jun 2019 22:11:44 GMT):
Thanks.
esplinr (Thu, 20 Jun 2019 22:12:03 GMT):
There will continue to be Indy agents in the wild probably for the rest of this year.
FarhanShafiq (Fri, 21 Jun 2019 12:29:42 GMT):
Has joined the channel.
wadeking98 (Tue, 25 Jun 2019 20:51:34 GMT):
Has joined the channel.
davology (Wed, 26 Jun 2019 09:11:34 GMT):
Has joined the channel.
swcurran (Wed, 26 Jun 2019 16:19:50 GMT):
FYI - BC Gov just posted a new Code With Us bounty about integrating an Aries agent as an IdP with Red Hat's Keycloak (and other) OpenID Connect IAM - https://www.bcdevexchange.org/opportunities/cwu/opp-create-a-red-hat-keycloak-identity-provider--idp--capable-of-processing-verifiable-credentials-using-decentralized-identity-technology-created-by-bc-gov-to-authorize-access-to-a-bc-government-digital-service-
MarcoPasotti (Wed, 26 Jun 2019 16:30:55 GMT):
Has joined the channel.
uNmAnNeR (Fri, 28 Jun 2019 12:25:44 GMT):
Has joined the channel.
uNmAnNeR (Fri, 28 Jun 2019 12:25:52 GMT):
Hello everyone! My question is about indy-agent. I wondering if there single protocol for indy-agent, or there are many different implementations of it (described https://github.com/hyperledger/indy-agent#known-agent-implementations). For instance https://github.com/evernym/connectathon-agent/ has different message format then indy-agent. So is there some standard way to communicate between indy actors which is supported by majority? Or indy-agent implementation is just an example how it can be done? Is indy-agent a production solution? And is it still under development/supported?
danielhardman (Fri, 28 Jun 2019 13:53:33 GMT):
At a low level, there is a standard way to communicate between indy agents which is supported by *all* of them. It is called "DID Communication" or DIDComm. It is documented here: https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0005-didcomm.
At a higher level, each agent has to choose what transports it is going to support. Most of the ones built so far support http; a few have implemented DIDComm on top of smtp or other transports.
But just like two things that talk http can only talk if they understand one another's web service interfaces, so two agents can only get work done together if they both speak the same protocols. You can think of protocols as web service APIs: you have one protocol for connecting, and it involves several different message exchanges (API calls); another protocol for exchanging credentials (again, several different message exchanges or APIs), and so forth.
Protocols are described here: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0003-protocols/README.md
As far as the indy-agent codebase: This codebase is getting less attention right now. You may be better off looking at some sample agents in Aries: aries-cloudagent-python (which is being used to build production solutions), aries-staticagent-python, etc.
swcurran (Fri, 28 Jun 2019 14:12:49 GMT):
Another answer given on the #indy channel.
uNmAnNeR (Fri, 28 Jun 2019 14:14:20 GMT):
thanks in advance
uNmAnNeR (Fri, 28 Jun 2019 14:14:20 GMT):
Until now we are implementing only client->server connections, when client (mobile phone) is always initiates all types of interactions. Now we'd like to implement something like push notifications using Firebase. As far as i understand indy-agent is early implementation of communication btw agents via http. ACA-PY goes the same way, but applies some common concepts described in rfcs (w3c). Am i right?
So there is still no Firebase push notifications, right?
uNmAnNeR (Fri, 28 Jun 2019 14:14:20 GMT):
So there is still no Firebase push implementation
swcurran (Mon, 01 Jul 2019 05:55:08 GMT):
FYI - as part of our Aries Cloud Agent Python work, we've taken a crack at going from "0 to coding" applications with Aries. Check it out - I'd love to get your feedback - https://github.com/bcgov/aries-cloudagent-python/blob/master/docs/GettingStartedAriesDev/README.md
uNmAnNeR (Tue, 02 Jul 2019 13:41:12 GMT):
Until now we are implementing only client->server connections, when client (mobile phone) is always initiates all types of interactions. Now we'd like to implement something like push notifications using Firebase. As far as i understand indy-agent is early implementation of communication btw agents via http. ACA-PY goes the same way, but applies some common concepts described in rfcs. Am i right?
uNmAnNeR (Tue, 02 Jul 2019 13:41:12 GMT):
Until now we are implementing only client->server connections, when client (mobile phone) is always initiates all types of interactions. Now we'd like to implement something like push notifications using Firebase. As far as i understand indy-agent is early implementation of communication btw agents via http. ACA-PY goes the same way, but applies some common concepts described in rfcs (w3c). Am i right?
uNmAnNeR (Tue, 02 Jul 2019 13:42:30 GMT):
So there is still no Firebase push implementation.
uNmAnNeR (Tue, 02 Jul 2019 13:56:05 GMT):
May be i misunderstood agent conception. Let me describe it by example, please correct me if i wrong.
Alice knows agent uri and sends REQUEST message. Agent saves dids pair and respond with did/verkey. Alice also stores pair. Then Bob appears. There would be 2 cases. 1) Bob also knows agent url and goes same way as Alice. 2) Alice invites Bob (INVITE message), then agent sends REQUEST to Bob, and then Bob replies with RESPONSE. Then Alice is able to send messages to Bob via agent, because agent has pair did/endpoint. Messages could be any type and for i don't get why indy-agent or ACA-PY is implementing more types because for me it seems that agent has to just forward messages. I think I missed something at that point or may be even before.
uNmAnNeR (Tue, 02 Jul 2019 13:56:05 GMT):
May be i misunderstood agent conception. Let me describe it by example, please correct me if i'm wrong.
Alice knows agent uri and sends REQUEST message. Agent saves dids pair with endpoint and respond with did/verkey. Alice also stores pair. Then Bob appears. There would be 2 cases. 1) Bob also knows agent url and goes same way as Alice. 2) Alice invites Bob (INVITE message), then agent sends REQUEST to Bob, and then Bob replies with RESPONSE. Then Alice is able to send messages to Bob via agent, because agent has Bobs pair did/endpoint. Messages could be any type and for i don't get why indy-agent or ACA-PY is implementing more types because for me it seems that agent has to just forward messages. I think I missed something at that point or may be even before.
uNmAnNeR (Tue, 02 Jul 2019 13:56:05 GMT):
May be i misunderstood agent conception. Let me describe it by example, please correct me if i'm wrong.
Alice knows agent uri and sends REQUEST message. Agent saves dids pair with endpoint and respond with did/verkey. Alice also stores pair. Then Bob appears. There would be 2 cases. 1) Bob also knows agent url and goes same way as Alice. 2) Alice invites Bob (INVITE message), then agent sends REQUEST to Bob, and then Bob replies with RESPONSE. Then Alice is able to send messages to Bob via agent, because agent has Bobs pair did/endpoint. Messages could be any type and i don't get why indy-agent or ACA-PY is implementing more types because for me it seems that agent has to just forward messages. I think I missed something at that point or may be even before.
swcurran (Tue, 02 Jul 2019 14:33:38 GMT):
Re: notifications. For a mobile agent, the request response model (client-server) for messaging and mobile platform ntofications seem to be sufficient. The Firebase-type notifications, tell the person - "hey, there's a message" and the person triggers to client request to the server (the cloud agent). You can see that in action with the StreetCred agent in the IIW Book demo.
swcurran (Tue, 02 Jul 2019 14:36:13 GMT):
Not quite sure of your case 1, but case 2 seems right. ACA-Py supports more messages because you can build a full edge agent (equivalent to mobile) with it for enterprises (as an example). We are using ACA-Py agents to issue, hold and proof verifiable credentials in an enterprise (gov't) context.
sheru (Tue, 02 Jul 2019 14:42:23 GMT):
Has joined the channel.
sheru (Tue, 02 Jul 2019 14:42:25 GMT):
hi
uNmAnNeR (Wed, 03 Jul 2019 06:50:59 GMT):
@swcurran thanks! can't find "StreetCred agent in the IIW Book", could you please share link
esplinr (Wed, 03 Jul 2019 15:03:03 GMT):
Page 112:
file:///home/richard/Downloads/IIWXXVIII_Book_of_Proceedings_2019A.pdf
jljordan_bcgov (Wed, 03 Jul 2019 15:34:01 GMT):
http://iiw.vonx.io @uNmAnNeR
jljordan_bcgov (Wed, 03 Jul 2019 15:34:26 GMT):
should this channel be deprecated in favour of #aries channel?
esplinr (Wed, 03 Jul 2019 16:30:14 GMT):
When we discussed it last time, we felt that Indy Agents would continue to exist for some time, until Aries development had progressed enough. So I added the announcement at the top of the channel and left it open.
esplinr (Wed, 03 Jul 2019 16:30:37 GMT):
Perhaps the time to close the channel has come.
swcurran (Wed, 03 Jul 2019 17:38:28 GMT):
No 0 to coding in Aries document set - check here: https://github.com/hyperledger/aries-cloudagent-python/blob/master/docs/GettingStartedAriesDev/README.md
uNmAnNeR (Thu, 04 Jul 2019 08:57:59 GMT):
@swcurran thanks
s.weidenbach (Thu, 04 Jul 2019 18:48:28 GMT):
Has joined the channel.
drummondreed (Mon, 08 Jul 2019 06:46:36 GMT):
I'm agreeing with @jljordan_bcgov that I think we've provided long enough for the transition. But you're closer to it, Richard. What do you think?
Hangyu (Mon, 08 Jul 2019 07:39:27 GMT):
Has joined the channel.
xfreeman (Mon, 08 Jul 2019 13:19:47 GMT):
Has joined the channel.
rjones (Tue, 09 Jul 2019 17:02:39 GMT):
Has left the channel.
ravip (Tue, 09 Jul 2019 23:30:16 GMT):
Has joined the channel.
ravip (Tue, 09 Jul 2019 23:30:16 GMT):
Hello everyone, so I am learning about the concepts of wallets in indy and had some questions. I hope I could get some input from the folks here or a direction to proceed. I apologize if I have not used the correct technical vocabulary to ask the question, I am still learning.
ravip (Tue, 09 Jul 2019 23:30:31 GMT):
This is one of the questions: Can you and should you store IPFS links to PII images in user's indy wallet?
dbluhm (Wed, 10 Jul 2019 14:25:14 GMT):
@ravip this channel has been mostly superseded by the Aries project and questions about agents and/or aries should be directed to #aries. Your specific question will likely find a better audience in #indy or #indy-sdk. I suggest asking your question there :slight_smile:
ravip (Wed, 10 Jul 2019 14:26:04 GMT):
Thank you @dbluhm for getting back to me.
mattatkiva (Wed, 10 Jul 2019 18:40:29 GMT):
Has joined the channel.
mattatkiva (Wed, 10 Jul 2019 18:40:50 GMT):
Has left the channel.
iamtxena (Wed, 10 Jul 2019 18:59:40 GMT):
Has left the channel.
troyronda (Wed, 10 Jul 2019 19:42:53 GMT):
Has left the channel.
uNmAnNeR (Thu, 11 Jul 2019 06:46:33 GMT):
@danielhardman @swcurran Hello! I am trying to understand the conception of mediators, bacause we need to implement push notifications on mobile. I've read rfc, but still have some questions. First is how mediator resolves recepient address from 'to' field? I guess it should find connection by 'to' verkey, then check corresponding DIDDoc and get serviceEndpoint. Is this correct?
And the last question. Sending firebase message requires some user-token, so as i understand it should be placed in serviceEndpoint. Right? But no ideas about format of it. Please clear this moment.
Also may be you can point to some explanation of how to establish connections between two mobile phones through cloud agent. It probably already done in IIW-book demo, but i could not find any resources. Thanks!
drummondreed (Thu, 11 Jul 2019 06:53:31 GMT):
@ravip and @dbluhm Actually, I think the #aries channel is the most appropriate for those questions now, as most Indy agent discussions have moved there.
esplinr (Thu, 11 Jul 2019 14:26:44 GMT):
I have the rights to delete the channel, but not to archive it. @rjones can you archive this channel?
rjones (Thu, 11 Jul 2019 14:26:44 GMT):
Has joined the channel.
rjones (Thu, 11 Jul 2019 14:27:41 GMT):
esplinr
rjones (Thu, 11 Jul 2019 14:27:55 GMT):
Has left the channel.
AmanAgrawal (Sun, 28 Jul 2019 11:00:23 GMT):
Has joined the channel.
AmanAgrawal (Sun, 28 Jul 2019 11:01:26 GMT):
Has left the channel.
bsuichies (Mon, 29 Jul 2019 09:04:24 GMT):
Has left the channel.
DougKing (Wed, 31 Jul 2019 21:43:48 GMT):
Has left the channel.
uNmAnNeR (Fri, 02 Aug 2019 12:55:40 GMT):
Has left the channel.
daidoji (Mon, 26 Aug 2019 03:26:18 GMT):
Has left the channel.
aaronr (Mon, 09 Sep 2019 18:59:47 GMT):
Has left the channel.
magicindustries (Mon, 28 Oct 2019 09:37:46 GMT):
Has left the channel.
bshambaugh (Sun, 29 Mar 2020 02:33:43 GMT):
Has joined the channel.
aguel (Fri, 29 May 2020 08:55:18 GMT):
Has left the channel.
MrWoodyz (Thu, 02 Jul 2020 03:35:26 GMT):
Has joined the channel.
tangelo1 (Fri, 10 Jul 2020 20:33:18 GMT):
Has joined the channel.
AlexanderHoughton (Wed, 19 Aug 2020 22:50:33 GMT):
Has joined the channel.
larabisch (Wed, 02 Sep 2020 16:21:35 GMT):
Has joined the channel.
GianlucaPinto (Thu, 24 Sep 2020 13:40:46 GMT):
Has joined the channel.
GianlucaPinto (Thu, 24 Sep 2020 13:41:19 GMT):
Has left the channel.
ankita.p17 (Mon, 12 Oct 2020 08:36:10 GMT):
Has joined the channel.
braduf (Thu, 15 Oct 2020 22:42:04 GMT):
Has joined the channel.
kei32bit (Fri, 13 Nov 2020 01:13:16 GMT):
Has joined the channel.
dishan (Wed, 02 Dec 2020 01:14:01 GMT):
Has joined the channel.
Alexandru-MihailAdam (Mon, 07 Dec 2020 16:06:09 GMT):
Has joined the channel.
Alexandru-MihailAdam (Mon, 07 Dec 2020 16:06:15 GMT):
Has left the channel.
ArturPhilipp (Thu, 10 Dec 2020 12:15:51 GMT):
Has joined the channel.
gagepoulson (Wed, 06 Jan 2021 15:35:05 GMT):
Has joined the channel.
karthiksamaganam (Mon, 01 Feb 2021 14:44:27 GMT):
Has joined the channel.
da3v21 (Tue, 23 Feb 2021 10:24:07 GMT):
Has joined the channel.
LukaszSawicki (Mon, 26 Apr 2021 23:38:35 GMT):
Has joined the channel.
gaberasturi (Fri, 02 Jul 2021 11:16:30 GMT):
Has joined the channel.
ankitkamra (Wed, 09 Feb 2022 04:41:18 GMT):
Has joined the channel.
tdiesler (Wed, 23 Feb 2022 10:35:57 GMT):
Has joined the channel.
rjones (Wed, 23 Mar 2022 17:25:34 GMT):
rjones (Wed, 23 Mar 2022 17:25:34 GMT):
rjones (Wed, 23 Mar 2022 17:25:34 GMT):
