rjones (Fri, 04 Sep 2020 20:57:40 GMT):
swcurran
rjones (Fri, 04 Sep 2020 20:58:02 GMT):
User User_1 added by rjones.
rjones (Fri, 04 Sep 2020 21:04:33 GMT):
Welcome 🙏
swcurran (Fri, 04 Sep 2020 21:15:17 GMT):
Thanks! :thanks:
rjones (Fri, 04 Sep 2020 22:12:52 GMT):
https://github.com/hyperledger/indy-did-method all yours!
rjones (Sat, 05 Sep 2020 02:26:14 GMT):
Has left the channel.
Xand (Tue, 15 Sep 2020 15:32:54 GMT):
Has joined the channel.
ajayjadhav (Tue, 15 Sep 2020 15:44:26 GMT):
Has joined the channel.
SuperSeiyan (Thu, 17 Sep 2020 14:08:02 GMT):
Has joined the channel.
GianlucaPinto (Thu, 24 Sep 2020 13:41:31 GMT):
Has joined the channel.
GianlucaPinto (Thu, 24 Sep 2020 13:41:32 GMT):
hi all, how can i do for get the timestamp of a credentials ? thanks
sheru (Thu, 24 Sep 2020 15:24:09 GMT):
Has joined the channel.
kdenhartog (Sun, 04 Oct 2020 21:31:48 GMT):
I'd suggest moving that question to #indy-sdk which is the designated channel for questions like this.
braduf (Thu, 15 Oct 2020 22:43:46 GMT):
Has joined the channel.
gnarula (Tue, 20 Oct 2020 08:54:10 GMT):
Has joined the channel.
gnarula (Wed, 21 Oct 2020 14:09:23 GMT):
can someone share the link to the indy did method documentation draft please?
Xand (Wed, 21 Oct 2020 14:19:45 GMT):
I think it's in the confluence project somewhere; did you set up a login? It's free
swcurran (Wed, 21 Oct 2020 15:38:42 GMT):
The current doc is here: https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw
I'm hoping to have a session at the IIW Conference tomorrow on this so I'm hoping it will evolve a bit this week.
peacekeeper (Wed, 21 Oct 2020 15:48:28 GMT):
+1, an IIW session about did:indy would be great
gnarula (Thu, 22 Oct 2020 12:56:31 GMT):
Thanks! Sorry I couldn't make it to IIW but I'm interested in discussions around this, specially about the versioning bit. Is there a call/meeting with the indy method on the agenda? I'd love to participate!
andrew.whitehead (Thu, 22 Oct 2020 20:03:29 GMT):
Re: the DID-URL method, I've suggested that a few times for resolving existing ledger objects (schemas, cred defs, revocation entries) but always received push back. I think it's the logical method for those transactions, but I also am leaning toward supporting any future ledger objects as DID documents
mickra (Thu, 22 Oct 2020 21:26:01 GMT):
Has joined the channel.
swcurran (Tue, 27 Oct 2020 17:45:09 GMT):
FYI - We plan on having weekly `did:indy` Method Specification Drafting meetings on a weekly basis. I propose that the meetings be held at 7AM Pacific Time on Tuesdays, which is the hour before the bi-weekly Indy Contributors call.
Request: Please let me know in replies if you plan on participating, and if so, if the time is OK with you, or what times would you prefer?
Thanks!
swcurran (Tue, 27 Oct 2020 17:46:18 GMT):
DIDIndySpecathonNotes - IIWXXXI.pdf
Xand (Tue, 27 Oct 2020 18:07:59 GMT):
Works for me, happy to coordinate or moderate when/if needed
paul.bastian (Wed, 28 Oct 2020 13:14:20 GMT):
Has joined the channel.
paul.bastian (Wed, 28 Oct 2020 13:16:32 GMT):
hey this is Paul and Micha, we tried to participate this time but the europe time in the confluence page didn't account fo europe wintertime shifting, so we missed it by an hour, planning to attend next week then..
swcurran (Wed, 28 Oct 2020 13:30:23 GMT):
Awesome -- thanks. Sorry for the calendar mixup. Calendars are really hard... :-)
swcurran (Thu, 29 Oct 2020 22:02:58 GMT):
FYI - the first of a (hopefully short-lived) series of meetings about defining the *Indy DID Method Spec* has been scheduled for this coming Tuesday at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-03
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Drafting+the+Indy+DID+Method+Specification
On the agenda this week is getting started and a discussion on the contents of the
swcurran (Thu, 29 Oct 2020 22:02:58 GMT):
FYI - the first of a (hopefully short-lived) series of meetings about defining the *Indy DID Method Spec* has been scheduled for this coming Tuesday November 3 at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-03
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Drafting+the+Indy+DID+Method+Specification
On the agenda this week is getting started and a discussion on the contents of the
robdaa (Sat, 31 Oct 2020 18:10:46 GMT):
Has joined the channel.
peacekeeper (Tue, 03 Nov 2020 19:31:34 GMT):
All, I'm sorry I missed the call today, I was planning to join but was occupied with preparations for the ongoing W3C DID WG F2F meeting this week..
swcurran (Tue, 03 Nov 2020 21:29:23 GMT):
We had a good first meeting today looking at what to put into the `network` segment of the did:indy identifier. We did not settle on a last one, but came up with 5 ideas, and the attributes enabled b each -- discoverability, human-friendly, conciseness, verifiability, dependencies.
swcurran (Tue, 03 Nov 2020 21:29:26 GMT):
Clipboard - November 3, 2020 1:29 PM
swcurran (Tue, 03 Nov 2020 21:30:09 GMT):
The approaches:
- Hash (543F4) – unrecognizable, verifiable with the ledger, short, non-discoverable/requires a registry
- Domain Name (example.com) – recognizable, discoverable, not tied to the ledger, dependent on DNS
- Arbitrary Name (SovrinStaging) - recognizable, non-discoverable/requires a registry, not tied to the ledger
- Combination of hash and domain name (this is what TrustBloc does)Â
- Combination of arbitrary name and hash
mickra (Tue, 03 Nov 2020 22:02:35 GMT):
My addition to the question _"What advantages (in terms of security) do we get when adding a truncated hash of the genesis file to the did?"_
First of all, we have to define the attack model.
One possible attack is the impersonation of a DID controller. This could be achieved by fooling the DID resolver to process a faked DID Document which includes keys under the attacker's control.
So let's look at the proposal to bind a DID to a specific ledger by adding a truncated hash (5 characters) of the genesis file to it. Does this proposal prevents the attack? I don't think so.
A five character base58 encoded string has an entropy of log2(58^5)=29.28 bits what is not sufficient for resistance to second preimages. An attacker could easily create his own ledger instance containing a faked DID document with a genesis file that leads to the same truncated hash (see example below).
So in my opinion, the hash approach has no advantage over an arbitrary network identifier because we have to trust the source of the genesis file anyway.
I think to counteract the impersonation attack, it is much more important to *require the DID to be self-certifying* (see swcurran's comment in the draft).
Link to example attack: https://hackmd.io/@jVpySwTeR5KNaa4M-h9bdg/BykGlUktP
swcurran (Tue, 03 Nov 2020 22:23:17 GMT):
I'm not an expert on this but...
The hash is the first five characters of a SHA256 hash of the file. As well, the file is contains the first n transactions on the Domain Ledger.
They could fork the ledger, but I don't think that is easily done. From my assessment, a fork of an Indy network can only be done with the cooperation of the base ledger nodes -- e.g. a "friendly fork".
The hash doesn't give you the location of the pool genesis file, and so there still has to be a separate mechanism for that. The attacker has to have a way to get you to use their version of that file.
swcurran (Tue, 03 Nov 2020 22:24:58 GMT):
@kdenhartog -- what was the motivation in using the hash prefix initially? Was it just a way to have a unique ID per network, or was it to add an integrity check on the network being pointed to, or both? I'm guessing both, but wanted to be sure.
mickra (Tue, 03 Nov 2020 23:15:11 GMT):
@swcurran In my opinion you don't have to make a friendly fork. You could just make your own ledger with the same truncated hash (what is very easy).
As you mentioned, the tricky part is to make the resolver to use your version of that file. However, this is also true when we use an arbitrary name instead of the hash.
@kdenhartog So why use the hash at all? I asked the same question at the call? In my opinion it strongly depends on the expected number of future indy networks. I just wanted to make clear here that with this truncated hash we have no strong integrity check.
swcurran (Tue, 03 Nov 2020 23:18:15 GMT):
The reason for using the hash is so that clients can check it. Against the ledger. Assuming that is common practice, getting a 5-character hash prefix that matches a series of transactions with signatures is (I think) effectively impossible.
swcurran (Tue, 03 Nov 2020 23:18:15 GMT):
The reason for using the hash is so that clients can check it, e.g. against the transaction on the ledger. Assuming that is common practice, getting a 5-character hash prefix that matches a series of transactions with signatures is (I think) effectively impossible.
swcurran (Tue, 03 Nov 2020 23:18:15 GMT):
The reason for using the hash is so that clients can check it, e.g. against the transaction on the ledger. Assuming that is common practice to verify the ledger, getting a 5-character hash prefix that matches a series of transactions with signatures is (I think) effectively impossible.
swcurran (Tue, 03 Nov 2020 23:18:15 GMT):
The reason for using the hash is so that clients can check it, e.g. against the transaction on the ledger. Assuming that is common practice to verify the ledger, getting a 5-character hash prefix that matches a series of valid ledger transactions with signatures is (I think) effectively impossible.
mickra (Wed, 04 Nov 2020 07:36:08 GMT):
It is not impossible if the attacker controls all keys of his fake ledger. Btw genesis transactions do not have any signatures..
paul.bastian (Wed, 04 Nov 2020 10:11:41 GMT):
I try to explain it again, otherwise we need to postpone this discussion to next week's call.
Imagine you are connecting to a DID on a new ledger that you havent been to, then on some other way thats offtopic to the hash discussion you need to enable discovery and therefore you can resolve a did. imagine I can fool you to connect to my hidden fake indy pool then your 5 character hash will not save you at all, because i will make up a genesis file easily that will also match this 5 character hash. that means the hash doesnt serve any cryptographically secure integrity check. If you want the integrity then you need to use all 32bytes of the SHA256
paul.bastian (Wed, 04 Nov 2020 10:12:18 GMT):
However all of this neglects the most import topic - discoverability
paul.bastian (Wed, 04 Nov 2020 10:12:34 GMT):
this is what we should focus on
Xand (Wed, 04 Nov 2020 12:11:26 GMT):
Could there be a fusion between the domain and arbitrary approaches wherein the names that do resolve through DNS are as such reserved, and then the other not-yet-discovered names are found by gossip from the discovered ones?
kdenhartog (Fri, 06 Nov 2020 00:11:34 GMT):
A key part that I don't see mentioned in there is the namespace governance. With something like a hash which is randomly generated in a way that allows for enough entropy to support many networks we don't need to consider how to govern the sub network namespace such that indy DIDs remain globally resolvable and sufficiently decentralized. However, if we opt to rely on a registry or DNS then we're effectively creating a hierarchical namespace that needs to be appropriately governed and can handle instances such as who decides which network is did:indy:sovrin
kdenhartog (Fri, 06 Nov 2020 00:11:34 GMT):
A key part that I don't see mentioned in there is the namespace governance. With something like a hash which is randomly generated in a way that allows for enough entropy to support many networks we don't need to consider how to govern the sub network namespace such that indy DIDs remain globally resolvable and sufficiently decentralized. However, if we opt to rely on a registry or DNS then we're effectively creating a hierarchical namespace that needs to be appropriately governed and can handle instances such as who decides which network is `did:indy:sovrin`
kdenhartog (Fri, 06 Nov 2020 00:14:36 GMT):
The reason for supporting the hash was in-order to handle globally decentralized namespace in a way that doesn't need to be governed. Essentially I'm trying to not go the path of creating an ICANN for Indy ledgers.
kdenhartog (Fri, 06 Nov 2020 00:17:28 GMT):
The goal wasn't really focused on pre-image integrity resistance because I recognized that if we do end up close to 2^29.28 (536870912) networks that we can extend the name space with more characters. If we're concerned about that then we can also enlarge the number of characters now.
kdenhartog (Fri, 06 Nov 2020 00:22:38 GMT):
I think you raise a good point though that if we make the network genesis txn file (or some other pre image to the hash) cross anchored to many networks than this pre-image attack could potentially cause non-determinism during DID resolution.
E.g. if resolver 1 finds network 1 ("aaaaa") on network 2 and resolver 2 finds network 3 (also "aaaaa") on network 4, then resolving did:indy:aaaaa:123 could end up returning different did documents depending on if resolver 1 or resolver 2 is used.
domwoe (Fri, 06 Nov 2020 09:57:04 GMT):
Has joined the channel.
mickra (Fri, 06 Nov 2020 10:05:00 GMT):
Many thanks for clarifying the motivation. During the discussion, I just always had the feeling that the hash approach always implies: "It brings security/verifiability to the ledger/DID resolution, since it uses a cryptographic hash". So I wanted to make you aware that this is not automatically the case.
swcurran (Fri, 06 Nov 2020 15:59:04 GMT):
Sorry -- my fault as I really hadn't dug into the issue of why.
:disappointed:
paul.bastian (Fri, 06 Nov 2020 16:04:21 GMT):
ok I get the point now. The core question is: how many networks do we expect? The hash still doesn't give discoverability and therefore resolvability. The more I think about it, i like the gossip/crossref idea..
swcurran (Fri, 06 Nov 2020 16:23:41 GMT):
The use cases for networks are around national infrastructure and global organizations. So if we assume a maximum case of every nation and a handful of global networks, we're talking in the hundreds. So I'd say the max we should assume is 1000 (on order of magnitude higher than expected).
swcurran (Fri, 06 Nov 2020 16:25:12 GMT):
The consensus at the Indy Interop-athon was that we should go with configuration for now for discoverability, and don't do anything to prevent a gossip approach later.
ultimo2020 (Sat, 07 Nov 2020 20:32:27 GMT):
Has joined the channel.
ultimo2020 (Sat, 07 Nov 2020 20:50:52 GMT):
Greetings everyone. I am catching up. Great discussions by the way.
ultimo2020 (Sat, 07 Nov 2020 20:51:43 GMT):
Was there maybe any discussion or work on KERI and offloading some key rotates and state management from the ledger?
ultimo2020 (Sat, 07 Nov 2020 21:10:10 GMT):
Sorry guys if I have missed the meeting.
I have a small question. Has there been any test-athlon in resolution of other networks, for an example ETH ssi ecosystem or other? As I understood the one of the goals (which is great) is the interoperability between ssi networks and ecosystems?
swcurran (Sun, 08 Nov 2020 19:30:56 GMT):
There is a suggestion of making the DID method "KERI-friendly" as a future placeholder, but there have not been any discussions about how that capability would be used. Basically, allow in the ledger specific ID portion to have a prefix that in future could be used for a KERI identifier. E.g. "did:indy:
swcurran (Sun, 08 Nov 2020 19:30:56 GMT):
There is a suggestion of making the DID method "KERI-friendly" as a future placeholder, but there have not been any discussions about how that capability would be used. Basically, allow in the ledger specific ID portion to have a prefix that in future could be used for a KERI identifier. E.g. "`did:indy:
swcurran (Sun, 08 Nov 2020 19:32:53 GMT):
Next meeting: scheduled for this coming Tuesday November 3 at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-10
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Drafting+the+Indy+DID+Method+Specification
On the agenda this week is continuing the discussion on the
swcurran (Sun, 08 Nov 2020 19:32:53 GMT):
Next meeting: scheduled for this coming Tuesday November 10 at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-10
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Drafting+the+Indy+DID+Method+Specification
On the agenda this week is continuing the discussion on the
swcurran (Sun, 08 Nov 2020 19:32:53 GMT):
Next meeting: scheduled for this coming Tuesday November 10 at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-10
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week is continuing the discussion on the
andrew.whitehead (Sun, 08 Nov 2020 20:17:05 GMT):
Nov 3?
Xand (Sun, 08 Nov 2020 22:17:22 GMT):
11/10*
kdenhartog (Sun, 08 Nov 2020 23:07:16 GMT):
All good, I'm glad I caught this discussion on going and was able to provide my motivations for it. I still think there's good questions to consider about pre-image collisions, but so far my thinking is that's solved by resolver implementers while we're still doing the config approach and if we start working on cross referencing we'll consider the impact of a pre-image attack then. In my mind, there's nothing that prevents us from having a variable length network string so we can extend it later to increase entropy.
swcurran (Mon, 09 Nov 2020 15:01:34 GMT):
**Editted to say Nov. 10.
swcurran (Mon, 09 Nov 2020 15:01:34 GMT):
**Edited to say Nov. 10.
ultimo2020 (Mon, 09 Nov 2020 17:22:22 GMT):
Thanks @swcurran for the Infos, I seem that I cannot open the agenda link
ultimo2020 (Mon, 09 Nov 2020 17:24:18 GMT):
Thanks @swcurran. Do you mean by Interop, like between Indy like Sovrin, BCgov and many other to come? Or also interoperability between other ecosystems like Bitcoin and ETH
swcurran (Mon, 09 Nov 2020 18:47:01 GMT):
The proper page for the DID Indy Meetings is: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
Corrected above. Never change the name of a web page :-)
swcurran (Mon, 09 Nov 2020 18:47:21 GMT):
Here is the right one: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
swcurran (Mon, 09 Nov 2020 18:48:28 GMT):
Starting with Interop between Indy instances -- Sovrin, Sovrin Staging, BCovrin Test, FIndy, IDUnion and so on.
That should also lead to resolution interop as well.
swcurran (Mon, 09 Nov 2020 18:48:28 GMT):
Starting with Interop between Indy instances -- Sovrin, Sovrin Staging, BCovrin Test, FIndy, IDUnion and so on.
That should also lead to resolution interop as well, beyond Indy.
But initial focus is Indy.
ultimo2020 (Mon, 09 Nov 2020 18:53:26 GMT):
Thanks a lot, will take a look into it
swcurran (Tue, 10 Nov 2020 21:43:41 GMT):
The results of today's `did:indy` specification meeting and the recording are posted. The main result is that we will use "arbitrary names" for the
swcurran (Tue, 10 Nov 2020 23:24:22 GMT):
@kdenhartog ^^ FYI about the hash vs. arbitrary name.
andrew.whitehead (Tue, 10 Nov 2020 23:51:46 GMT):
Looking at the DID core spec, the network identifier can include these characters: `ALPHA / DIGIT / "." / "-" / "_"`. I don't mind the look of `did:indy:sovrin.staging:12345`
andrew.whitehead (Tue, 10 Nov 2020 23:52:31 GMT):
(or `staging.sovrin` if you want to use DNS ordering)
paul.bastian (Wed, 11 Nov 2020 09:13:38 GMT):
If you define the subnets as part of the method-specific-id then the format above is legit though
andrew.whitehead (Wed, 11 Nov 2020 16:49:31 GMT):
It's an allowed format. I'm not sure if the 'subsidiary ledger ID' is required though and it would be good to have a consistent number of components
kei32bit (Fri, 13 Nov 2020 01:13:40 GMT):
Has joined the channel.
kdenhartog (Mon, 16 Nov 2020 01:55:18 GMT):
What’s the plan to govern the namespace then? From the sounds of it this is effectively recreating DNS.
kdenhartog (Mon, 16 Nov 2020 02:00:30 GMT):
Also this won’t scale to a cross network gossiping type system because you’ll need a global namespace in order to support that. This solution opts to forgo the “decentralized” property needed to make that happen instead preferring the human friendliness property as described in Zooko’s triangle.
kdenhartog (Mon, 16 Nov 2020 02:00:30 GMT):
Also this won’t scale to a cross network gossiping type system because you’ll need a decentralized, global namespace in order to support that. This solution opts to forgo the “decentralized” property needed to make that happen instead preferring the human friendliness property as described in Zooko’s triangle.
swcurran (Mon, 16 Nov 2020 02:43:46 GMT):
At this point, there is no plan to govern the namespace. Don't pick the same name as others :-), don't accept duplicate names. Same as don't generate a hash prefix same as others, don't accept the same hash as has already been seen.
I don't understand the gossip comment as that is about discovery, which is a separate issue from namespacing.
swcurran (Mon, 16 Nov 2020 02:44:53 GMT):
Note that the "person friendly" name was deemed acceptable given the expected number of networks -- in the low 100s, max 1000.
kdenhartog (Mon, 16 Nov 2020 10:13:21 GMT):
They'll have an impact on each other eventually when you're trying to cross anchor networks for discovery later if the namespaces have a collision. This will lead to not deterministic resolution, but from the sounds of it people are alright with that and willing to solve that problem a different day.
paul.bastian (Mon, 16 Nov 2020 22:05:12 GMT):
reasons in my opinion:
1. motivation to pick namespace collisions are not high, 2. chances for namespace collisions are not to be expected due to the expected numbers, 3. we should forbid selfdeclared DID ids and only allow selfcertyfing, generated DID ids that form a cryptographic barrier in case of an attacker collision, 4. hash solution does not solve the this either, 5. nobody wants DNS
swcurran (Mon, 16 Nov 2020 23:33:34 GMT):
Great summation, Paul. Thanks.
swcurran (Tue, 17 Nov 2020 01:05:33 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday November 17 at 7AM Pacific / 15:00 UTC.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-17
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week is naming for related ledgers (e.g. dev/test/staging), finding the ledger given a DID, and (if there is time) the ramifications to Indy of version-id and version-time resolution query parameters.
Please join in and help with this collaborative effort.
kdenhartog (Tue, 17 Nov 2020 10:00:29 GMT):
1 if an attacker squats on a name space then that won’t remain true. That’s premised on the assumption that all actors are benevolent within the space.
2 again has nothing to do with honest actors. They’ll easily work out how to avoid name space collision through implicit governance of the Indy sub namespace. It’s malicious actors who will cause the problems.
3 agree but this doesn’t have anything to do with network identification and resolution
4 if a cryptographic hash is used and not overly truncated it would. This is what pre-image resistance is about
5 Then it would be wise of us to not create a human friendly network identifier because DNS has the architectural constraints on it due to their namespace also opting to use human friendly identifiers and being globally unique.
From the sounds of it though, people are convinced this is what they want so that’s the direction the method will go. I’m just trying to do my due diligence by calling out the tradeoffs that I’m seeing that don’t seem like they’re being considered from the discussions in seeing. If people are aware and still willing to accept the tradeoffs that’s fine because I raised the concern at least.
kdenhartog (Tue, 17 Nov 2020 10:00:29 GMT):
1 if an attacker squats on a name space then that won’t remain true. That’s premised on the assumption that all actors are benevolent within the space.
2 again has nothing to do with honest actors. They’ll easily work out how to avoid name space collision through implicit governance of the Indy sub namespace. It’s malicious actors who will cause the problems.
3 agree but this doesn’t have anything to do with network identification and resolution
4 if a cryptographic hash is used and not overly truncated it would. This is what pre-image resistance is about
5 Then it would be wise of us to not create a human friendly network identifier because DNS has the architectural constraints on it due to their namespace also opting to use human friendly identifiers and being globally unique.
From the sounds of it though, people are convinced this is what they want so that’s the direction the method will go. I’m just trying to do my due diligence by calling out the tradeoffs that I’m seeing that don’t seem like they’re being considered from the discussions I’m seeing. If people are aware and still willing to accept the tradeoffs that’s fine because I raised the concern at least.
paul.bastian (Tue, 17 Nov 2020 16:12:32 GMT):
We could shift every 2nd week for a later time to enable Kyle to participate? 7:00am Auckland is 6:00pm Berlin?
swcurran (Tue, 17 Nov 2020 16:22:31 GMT):
Good discussions today -- thanks all! We reviewed last week's decisions (and kept them), talked about subnamespacing (added them), reserving a space for KERI (added that too) and talked about how to find the ledger of a DID, and made progress. Next week, we'll start with a summary from Daniel about how a gossiped "my networks knows about your network" scheme might work practically, so we can decide to include it as a formal capability, or whether it will remain as an informal future direction.
swcurran (Tue, 17 Nov 2020 16:24:42 GMT):
The recording has been posted to the agenda page: https://wiki.hyperledger.org/display/indy/2020-11-17+Indy+DID+Method+Specification+Call
danielhardman (Tue, 17 Nov 2020 18:56:06 GMT):
Has joined the channel.
danielhardman (Tue, 17 Nov 2020 18:56:07 GMT):
Here are slides for the cross-registration idea, to be discussed at the next meeting: https://j.mp/36Zi7ij
kdenhartog (Thu, 19 Nov 2020 01:21:44 GMT):
Regarding this discussion, @swcurran and I messaged back and forth and confirmed that everyone is aware of the tradeoffs and is willing to accept them. In this case, I'm good to move forward with the arbitrary names approach and am not here to stand in the way, but rather just provide advice and options now that we've decided to go this route.
kdenhartog (Thu, 19 Nov 2020 01:28:31 GMT):
@danielhardman I just gave a loook through your slides and looks good. Something that I didn't see mentioned on there yet was what happens if a network name identifier is already registered to a network. In the Config files this is going to be a bit easier because I'd expect the config will just not merge a PR that has this issue. For the Manual Cross-Registration this seems like it will hold in the majority of cases, but the one edge case I'd expect would be if lets say I'm did:indy:sov and I cross register to did:indy:findy and it accepts the registration, but then also try to cross register to did:indy:xyz and did:indy:sov has already been registered that points to a separate network. In this case should we allow the removal of did:indy:sov from did:indy:findy such that we can create a new namespace that won't conflict?
kdenhartog (Thu, 19 Nov 2020 01:28:31 GMT):
@danielhardman I just gave a loook through your slides and looks good. Something that I didn't see mentioned on there yet was what happens if a network name identifier is already registered to a network. In the Config files this is going to be a bit easier because I'd expect the config will just not merge a PR that has this issue. For the Manual Cross-Registration this seems like it will hold in the majority of cases, but the one edge case I'd expect would be if lets say I'm `did:indy:sov` and I cross register to `did:indy:findy` and it accepts the registration, but then also try to cross register to `did:indy:xyz` and `did:indy:sov` has already been registered that points to a separate network so it rejects the Manual Cross Registration. In this case should we allow the removal of `did:indy:sov` from `did:indy:findy` such that we can create a new namespace that won't conflict?
swcurran (Thu, 19 Nov 2020 15:00:38 GMT):
@kdenhartog AFAIK, the plan is that a adding a "network" entry to a ledger (containing pointers to other networks) is done by a trusted DID of the ledger. So `did:indy:findy` does not register on `did:indy:sov`, but rather `did:indy:findy` is added as a network by (likely) a Trustee on `did:indy:sov` based on a human request, according to the governance framework of `did:indy:sov`.
That will work for the next several years and other mechanisms may be added in the future that enable scaling. But because we are talking a small number of networks (100s), we don't need the scaling -- at least not yet.
paul.bastian (Thu, 19 Nov 2020 16:12:00 GMT):
its more of a human-like trust network. trustees know each other and mutually cross-register their networks
paul.bastian (Thu, 19 Nov 2020 16:12:49 GMT):
additionally this can be published at DIF/ToIP/Github
paul.bastian (Thu, 19 Nov 2020 16:14:04 GMT):
software implementers gonna pick their favorite combination and use static and/or dynamic approaches individually
paul.bastian (Thu, 19 Nov 2020 16:14:29 GMT):
we offer a suite of possibilities as a non-normative section in the DID method
peacekeeper (Thu, 19 Nov 2020 23:41:30 GMT):
One question is what will the "DID on network A that identifies network B" will look like... Hash of the genesis file of network B?
peacekeeper (Thu, 19 Nov 2020 23:42:34 GMT):
Also note this paper by @drummondreed about DID Namespace Records: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/did-namespace-records.md
drummondreed (Thu, 19 Nov 2020 23:42:34 GMT):
Has joined the channel.
swcurran (Fri, 20 Nov 2020 00:36:00 GMT):
Interesting. @drummondreed -- glad to have you join us.
swcurran (Fri, 20 Nov 2020 00:36:39 GMT):
As presented, that tells us about other networks, but doesn't provide discovery information -- how you actually connect with the other network.
drummondreed (Fri, 20 Nov 2020 00:37:57 GMT):
The idea is that the DID document representing the other network either directly contains that connection info or points to it via a service endpoint type that we define in the Indy DID method.
drummondreed (Fri, 20 Nov 2020 00:38:20 GMT):
In the paper those DID documents are called "DID namespace documents".
drummondreed (Fri, 20 Nov 2020 00:38:55 GMT):
They are just standard DID documents with additional properties defined for discovery, description, and cross-verification of DID networks.
swcurran (Fri, 20 Nov 2020 00:43:53 GMT):
Not quite sure what the levels of indirection are. Do the examples show what is in the "namespace documents" or are they DIDs that resolve to DIDDocs that contain the discovery info?
How many turtles?
drummondreed (Fri, 20 Nov 2020 00:47:10 GMT):
You got it. The DIDs resolve to DID documents that contain the discovery info.
swcurran (Fri, 20 Nov 2020 00:49:26 GMT):
OK...but how do you resolve those DIDs...? Anyway -- Daniel has a presentation that can facilitate the discussion next week.
paul.bastian (Fri, 20 Nov 2020 14:30:58 GMT):
Good slides so far, I would put in a success/fail endstate for the flow chart
paul.bastian (Fri, 20 Nov 2020 14:32:56 GMT):
for failed resolution/and successfully resolved DID doc
swcurran (Tue, 24 Nov 2020 00:53:36 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday November 24 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-11-24
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week is finding a ledger given it's name. A config file is needed to find one network, but can we use that network to find others, and others, and others, and others...
Please join in and help with this collaborative effort.
kukgini (Tue, 24 Nov 2020 10:13:21 GMT):
Has joined the channel.
swcurran (Thu, 26 Nov 2020 01:06:29 GMT):
Hi all -- I've written what I think is a summary of the discussion about cross-registering networks on ledgers -- it's at the bottom of the page linked below. Please review before the next meeting so that we can (relatively) quickly review the summary and address the noted decisions to be made:
https://wiki.hyperledger.org/display/indy/2020-11-24+Indy+DID+Method+Specification+Call
Comments and ideas are welcome here in this channel.
peacekeeper (Mon, 30 Nov 2020 22:40:40 GMT):
I'm not convinced it's a good idea that DID creation always requires TWO operations (NYM and "diddoc" ATTRIB). I feel like it should still be possible to create a DID with a NYM only (and optional "diddoc" ATTRIB).
swcurran (Mon, 30 Nov 2020 23:39:13 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 1 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-01
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week is a review of last week's discussion aiming towards some decisions, and we'll get started on DIDs / DIDDocs and NYMs / ATTRIBs
Please join in and help with this collaborative effort.
dishan (Wed, 02 Dec 2020 01:14:15 GMT):
Has joined the channel.
swcurran (Mon, 07 Dec 2020 19:11:54 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 8 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-08
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Review: Discovery of networks - Given a DID, how to find it's network via gossiped ledger data
* Second pass: Handling DIDs / DIDDocs using NYMs / ATTRIBs
* Getting updates made to the hackmd.io document.
Please join in and help with this collaborative effort.
brian.richter (Mon, 07 Dec 2020 23:23:29 GMT):
Has joined the channel.
peacekeeper (Tue, 08 Dec 2020 08:59:50 GMT):
I'm sorry I won't be able to join today - it's a public holiday here and also my nephew's birthday..
peacekeeper (Tue, 08 Dec 2020 09:02:08 GMT):
Just want to say again that I believe a NYM alone without an ATTRIB should also be considered a complete DID that can be resolved to a DID document which simply has the NYM's verkey in it. ATTRIB with a DID document can optionally be done too. I think that was the direction we were heading in anyway on the last call...
swcurran (Tue, 08 Dec 2020 14:54:20 GMT):
NP -- enjoy the day (and evening!). Yes, that's a must!
BrianRichter (Tue, 08 Dec 2020 15:06:31 GMT):
Has joined the channel.
swcurran (Tue, 08 Dec 2020 21:07:03 GMT):
Hi All -- good discussion today on the DID Indy Method Specification call. We talked over an approach from Drummond on how to use some special DIDs ("DID Namespace Directory" and "DID Namespace Registration" DIDs) to register and discover cross-registered Indy networks. Very cool!
Highly recommend checking out the notes here: https://wiki.hyperledger.org/display/indy/2020-12-08+Indy+DID+Method+Specification+Call
ArturPhilipp (Thu, 10 Dec 2020 12:15:11 GMT):
Has joined the channel.
swcurran (Mon, 14 Dec 2020 21:07:24 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 8 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-08
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* NYMs/ATTRIBs and DIDs/DIDDocs
* Unresolved question about Indy Network Discovery
swcurran (Mon, 14 Dec 2020 21:07:24 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 8 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-08
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* NYMs/ATTRIBs and DIDs/DIDDocs
* Unresolved question about Indy Network Discovery
Please join in and help with this collaborative effort.
swcurran (Mon, 14 Dec 2020 21:07:24 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 15 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-15
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* NYMs/ATTRIBs and DIDs/DIDDocs
* Unresolved question about Indy Network Discovery
Please join in and help with this collaborative effort.
swcurran (Mon, 14 Dec 2020 21:08:12 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday December 15 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2020-12-15
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* NYMs/ATTRIBs and DIDs/DIDDocs
* Unresolved question about Indy Network Discovery
Please join in and help with this collaborative effort.
peacekeeper (Tue, 15 Dec 2020 13:41:25 GMT):
Hey I experimented a bit with version-time and version-id using a concrete example DID on Sovrin MainNet: https://docs.google.com/presentation/d/1GeNGueKuhGKXP4T7fGIxOENnZvfEsQywISlgTAgs1vA/
peacekeeper (Tue, 15 Dec 2020 13:41:33 GMT):
If you like I can quickly present this today
swcurran (Tue, 15 Dec 2020 14:24:26 GMT):
That would be great -- thanks. Added to the agenda.
swcurran (Tue, 15 Dec 2020 20:16:49 GMT):
Excellent meeting today that covered off a few issues. The notes for the meeting have noted what we agreed upon:
- a Hyperledger repo that network operators can use to post config files for their network
- The need to continue to resolve NYMs with no ATTRIBs and NYMs with just endpoint ATTRIBs -- thanks for @peacekeeper for the demo!
- That we will have a transformation from NYMs+ATTRIBs to produce a DIDDoc for resolution
- That we will favour a did:key style DIDDoc from NYMs with no ATTRIBs and NYMs with just endpoint ATTRIBs
Next meeting, Paul will facilitate a discussion about extending that last point to more than just "endpoint ATTRIBs" that moves away from the original idea in the hackmd.io document about the ATTRIB containing (more or less) the entire DIDDoc.
Meetings are cancelled the next two weeks -- Dec. 22 and Dec. 29.
Next meeting will be Jan. 5 at the regular time.
If you are looking for things to do, updating the hackmd.io document to reflect what we have agreed up on (documented in the the meeting agenda from today) would be a lot of fun to do!
Thanks!
swcurran (Tue, 22 Dec 2020 05:25:00 GMT):
Hey folks -- a reminder that there is no meeting tomorrow, Dec. 22, 2020. Have a great holiday break!
drummondreed (Tue, 22 Dec 2020 05:25:54 GMT):
Stephen, thanks for the reminder!!! You just saved me an hours sleep! And coming into Christmas, that's a huge present indeed!!
drummondreed (Tue, 22 Dec 2020 05:26:30 GMT):
I am working on the DND/DNR spec draft, BTW. When will be the next meeting. Jan 5?
peacekeeper (Tue, 22 Dec 2020 14:40:36 GMT):
Thanks for the reminder, I would have joined :) Have a nice break, and I look forward to the next meeting.
swcurran (Mon, 04 Jan 2021 16:12:15 GMT):
did:indy Method Spec -- Next meeting: scheduled for this coming Tuesday January 5 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-01-05
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Discussion (led by Paul Bastian) about transforming NYM and ATTRIB data into a DIDDoc. What goes into the ATTRIB and how does it manifest in the DIDDoc?
Please join in and help with this collaborative effort.
swcurran (Sat, 09 Jan 2021 00:15:07 GMT):
Hey folks -- I took a pass at updating the HackMD document to reflect what we have discussed to this point. If you have a chance, please go in and clean it up. Feel free to simply fix things that need fixing, and add questions/comments if relevant. It includes all except the discovery approaches we've talked about.
swcurran (Sat, 09 Jan 2021 00:15:59 GMT):
Also, there are a full set of appendices that need to be added -- each ATTRIB type and it's corresponding transformation. Assuming we want to include that in the specification :-)
danielhardman (Sun, 10 Jan 2021 02:13:11 GMT):
I have generally been in favor of Paul's approach where we compose a DID doc from multiple attribs. However, I want to mention a concern that I have, which is that it could be possible to get in an invalid state (e.g., remove a key, then try to add a key, but now there are no keys that can authorize the add). This is because we can't atomically make multiple changes. The right way to solve this would be to submit multiple ATTRIB transactions at the same time. That would be an Indy Node change. Should we pursue that?
swcurran (Mon, 11 Jan 2021 15:24:49 GMT):
General answer -- I think that what we change in Indy Node will depend on what effort the community is willing to put into it. Features such as what you reference are desirable but not required, and so whether it is implemented or not is up to the community.
swcurran (Mon, 11 Jan 2021 15:27:33 GMT):
Specific answer -- I think we should consider the scope of ATTRIBs. For example, if you publish an "authorization_key" entry, does that add to the existing ones or replace the existing ones? If the latter, then the problem that you reference doesn't come up. Same for "service_endpoint". Do we collect all the service_endpoint ATTRIBs and put them in an array, or get only the last one and require it have all the array entries that are current?
swcurran (Tue, 12 Jan 2021 14:59:49 GMT):
did:indy Method Spec -- Next meeting: scheduled for NOW Tuesday January 12 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-01-12
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Details on ATTRIB transformations to DIDDocs
Please join in and help with this collaborative effort.
swcurran (Tue, 12 Jan 2021 17:13:16 GMT):
@all A small crowd but a very good discussion on the meeting about how to manage NYMs and ATTRIBs and a possible path for managing the two together in a powerful way. Please review the notes here: https://wiki.hyperledger.org/display/indy/2021-01-12+Indy+DID+Method+Specification+Call
@peacekeeper -- there is a request that I put in for you about how the concept of a controller (the entity/entities that can update a DID/DIDDoc) in the DID Core spec. works. If we were to expand the concepts in the Indy NYM to (for example) include multiple verkeys and perhaps an "N of M" requirement, what would we do to align with the core DID spec?
swcurran (Tue, 12 Jan 2021 17:13:16 GMT):
@all A small crowd but a very good discussion at today's meeting about how to manage NYMs and ATTRIBs and a possible path for managing the two together in a powerful way. Please review the notes here: https://wiki.hyperledger.org/display/indy/2021-01-12+Indy+DID+Method+Specification+Call
@peacekeeper -- there is a request that I put in for you about how the concept of a controller (the entity/entities that can update a DID/DIDDoc) in the DID Core spec. works. If we were to expand the concepts in the Indy NYM to (for example) include multiple verkeys and perhaps an "N of M" requirement, what would we do to align with the core DID spec?
peacekeeper (Wed, 13 Jan 2021 12:03:19 GMT):
@swcurran Thanks, I saw this mention. Sorry I wasn't able to join yesterday :( My quick reaction is:
- I don't think the Indy rules should change to use the contents of the DID document, this feels like a big change, and there would be a some strange circular dependency. The DID document is constructed from NYM+ATTRIB, and at the same time the DID document is used for authorizing those writes.
- But this doesn't mean that we can't change the rules e.g. to extend NYM to allow more complex controller concepts. E.g. I could absolutely imagine expanding NYM to specify multiple verification keys, and for authorizating writes you would need a N of M signature. These rules would be added to the Indy code, and they can also be "rendered" in the resolved DID document that is constructed from the NYM. It would be interesting to try to model that on an upcoming call.
- @drummondreed has an open PR on DID Core that will add an appendix about "Multiple DID Controllers": https://github.com/w3c/did-core/pull/460
peacekeeper (Wed, 13 Jan 2021 12:03:19 GMT):
@swcurran Thanks, I saw this mention. Sorry I wasn't able to join yesterday :( My quick reaction is:
- I don't think the Indy rules should change to use the contents of the DID document, this feels like a big change, and there would be a some strange circular dependency. The DID document is constructed from NYM+ATTRIB, and at the same time the DID document is used for authorizing those writes.
- But this doesn't mean that we can't change the rules e.g. to extend NYM to allow more complex controller concepts. E.g. I could absolutely imagine expanding NYM to specify multiple verification keys, and for authorizing writes you would need a N of M signature. These rules would be added to the Indy code, and they can also be "rendered" in the resolved DID document that is constructed from the NYM. It would be interesting to try to model that on an upcoming call.
- @drummondreed has an open PR on DID Core that will add an appendix about "Multiple DID Controllers": https://github.com/w3c/did-core/pull/460
peacekeeper (Wed, 13 Jan 2021 12:03:19 GMT):
@swcurran Thanks, I saw this mention. Sorry I wasn't able to join yesterday :( My quick reaction is:
- I don't think the Indy rules should change to use the contents of the DID document, this feels like a big change, and there would be a strange circular dependency. The DID document is constructed from NYM+ATTRIB, and at the same time the DID document is used for authorizing those writes.
- But this doesn't mean that we can't change the rules e.g. to extend NYM to allow more complex controller concepts. E.g. I could absolutely imagine expanding NYM to specify multiple verification keys, and for authorizing writes you would need a N of M signature. These rules would be added to the Indy code, and they can also be "rendered" in the resolved DID document that is constructed from the NYM. It would be interesting to try to model that on an upcoming call.
- @drummondreed has an open PR on DID Core that will add an appendix about "Multiple DID Controllers": https://github.com/w3c/did-core/pull/460
peacekeeper (Wed, 13 Jan 2021 12:03:19 GMT):
@swcurran Thanks, I saw this mention. Sorry I wasn't able to join yesterday :( My quick reaction is:
- I don't think the Indy rules should change to use the contents of the DID document, this feels like a big change, and there would be a strange circular dependency. The DID document is constructed from NYM+ATTRIB, and at the same time the DID document would be used for authorizing those writes.
- But this doesn't mean that we can't change the rules e.g. to extend NYM to allow more complex controller concepts. E.g. I could absolutely imagine expanding NYM to specify multiple verification keys, and for authorizing writes you would need a N of M signature. These rules would be added to the Indy code, and they can also be "rendered" in the resolved DID document that is constructed from the NYM. It would be interesting to try to model that on an upcoming call.
- @drummondreed has an open PR on DID Core that will add an appendix about "Multiple DID Controllers": https://github.com/w3c/did-core/pull/460
kdenhartog (Thu, 14 Jan 2021 04:46:57 GMT):
Just a note, based on how the controller property is defined, _The value of the controller property MUST be a string or an ordered set of strings that conform to the rules in Section § 3.1 DID Syntax._ We wouldn't be able to specify in the DID Document the threshold of number of signatures needed by the controller I believe if we go with a programatic multisig solution. We would need to modify the normative statement to allow the controller property to be an INFRA MAP (JSON object) to do this, but I can't think of a reason where a DID Document would need to include this info. (It only needs to be included in the underlying txn data that Indy stores and uses to verify updates later on). Additionally, we could easily solve this as well using an extension property that would just need to be defined and registered.
Tl;DR I think there may be a data representation problem if we want to use the DID Document to express the N of M threshold using only core properties. However, I'm not certain we need that and if it so happens that it is needed this can be solved with a DID Spec Registries extension property.
kdenhartog (Thu, 14 Jan 2021 04:46:57 GMT):
Just a note, based on how the controller property is defined, _The value of the controller property MUST be a string or an ordered set of strings that conform to the rules in Section § 3.1 DID Syntax._ We wouldn't be able to specify in the DID Document the threshold of number of signatures needed by the controller I believe if we go with a programatic multisig solution. I can't think of a reason where a DID Document would need to include this info. (It only needs to be included in the underlying txn data that Indy stores and uses to verify updates later on). Also this assumes that we want to levarage the controller property to handle this. Even so, we could easily solve this (it's probably the better path to handle this at this point in the spec process) as well using an extension property that would just need to be defined and registered.
Tl;DR I think there may be a data representation problem if we want to use the DID Document to express the N of M threshold using only core properties. However, I'm not certain we need that and if it so happens that it is needed this can be solved with a DID Spec Registries extension property.
danielhardman (Thu, 14 Jan 2021 17:26:41 GMT):
@kdenhartog : You are not wrong about the verbiage, but I think you are drawing a conclusion that is unnecessary. Section 5.2 of the spec says what a DID controller is. It then says that a DID doc MAY have a `controller` property; if it does, the property must conform to the rules you articulated.
The escape hatch here is that we don't have to use the `controller` property to express control of the DID document. If control is not expressible using a simple construct, we can invent a fancy one. That is allowed by the spec.
kdenhartog (Thu, 14 Jan 2021 22:09:00 GMT):
Yup agree with that assessment, rereading my original post, it sounds a bit more dire than I actually intended.
swcurran (Tue, 19 Jan 2021 03:17:19 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday January 19 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-01-19
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Details on ATTRIB transformations to DIDDocs
Please join in and help with this collaborative effort.
paul.bastian (Tue, 19 Jan 2021 11:39:06 GMT):
I think I might need to skip todays meeting :/
swcurran (Tue, 19 Jan 2021 14:39:25 GMT):
Hmmm...Drummond as well.
swcurran (Mon, 25 Jan 2021 16:23:02 GMT):
Three thoughts for today:
1. No one showed up for the meeting last week. What do we want to do -- keep going as is, change the meeting time, stop the effort?
2. I think we should consider defining the DIDDoc going forward as a full, single ATTRIB that has the NYM information injected in a standard way. Handling of a "no ATTRIB NYM" is still required, as is an "endpoint only ATTRIB" for backwards compatibility. We can leave open in the future extending NYM handling.
3. We should start to talk about other Indy objects (Schema, Claim Def) as DIDs, where the object is the subject and resource. What does that look like as a standard DID? Can we put these objects on non-Indy ledgers?
Let me know what you want to do about the meeting tomorrow. @paul.bastian @danielhardman @peacekeeper @drummondreed @ArturPhilipp
The first item isn't for you @kdenhartog , since the meeting time is no fun for you, but interested in any thoughts you have on the 2 and 3 items.
drummondreed (Mon, 25 Jan 2021 16:47:50 GMT):
@swcurran Unfortunately the huge rush to digital vaccination credentials has forced me to attend another meeting in that time slot, and that meeting is likely to last at least another month. However since I don't think the DND/DNR cross-registration work is part of a V1 release (we've agreed it would be a separate spec anyway), I'm not essential to getting the V1 spec done. I am still willing to contribute to the spec as that's helpful, but I think it's the rest of the names in your group that need to be driving it.
kdenhartog (Mon, 25 Jan 2021 22:35:06 GMT):
> I think we should consider defining the DIDDoc going forward as a full, single ATTRIB that has the NYM information injected in a standard way.
This remains my preference as well in order to reduce number of transactions and keep a single instance of an indy ledger more scalable. I agree that keeping backwards compatibility should remain required as well.
> What does that look like as a standard DID?
We'd want to register all of the properties in the did spec registry and then the DID Document would effectively be the object with an additional id property that is a DID.
>Can we put these objects on non-Indy ledgers?
Theoretically yes, but it will be up to the other methods/implementations to actually support this. As an example, you could use did:schema / did:web as is to do this, but getting sidetree to support it would be far more difficult because of the expectation that the DID Document data is strongly typed and you'd have to work with the sidetree group to support the new properties. Some implementations would likely be easier to use than others. E.g. Orie's implementation does a good job of making the data model extensible. The ION reference implementation wanted to strongly type and put limitations on the properties in order to keep storage limits within reason at scale, so it may be more difficult for that.
kdenhartog (Mon, 25 Jan 2021 22:35:06 GMT):
> I think we should consider defining the DIDDoc going forward as a full, single ATTRIB that has the NYM information injected in a standard way.
This remains my preference as well in order to reduce number of transactions and keep a single instance of an indy ledger more scalable. We can obviously still horizontally scale as needed, but thinking vertical scaling will remain important in the future and keeping the number of transactions down is beneficial. Going back to one of the original points @tomislav brought up in the google doc as well, we'll want to consider how the integration will occur between the nym key and references to it in the attrib txn. With that in mind I agree that keeping backwards compatibility should remain required still.
> What does that look like as a standard DID?
We'd want to register all of the properties in the did spec registry and then the DID Document would effectively be the object with an additional id property that is a DID.
>Can we put these objects on non-Indy ledgers?
Theoretically yes, but it will be up to the other methods/implementations to actually support this. As an example, you could use did:schema / did:web as is to do this, but getting sidetree to support it would be far more difficult because of the expectation that the DID Document data is strongly typed and you'd have to work with the sidetree group to support the new properties. Some implementations would likely be easier to use than others. E.g. Orie's implementation does a good job of making the data model extensible. The ION reference implementation wanted to strongly type and put limitations on the properties in order to keep storage limits within reason at scale, so it may be more difficult for that.
swcurran (Tue, 26 Jan 2021 00:36:56 GMT):
@kdenhartog -- your statement appears to be different from what (I/we understood) you proposed earlier. AFAIK, the original proposal was that the ATTRIB would contain the entire DIDDoc. What we are proposing is that the NYM be injected into the DIDDoc. That way there is never an inconsistency between the NYM/ATTRIB combination and the DIDDoc. Either the NYM or the ATTRIB can be updated and the resulting DIDDoc is valid.
We're proposing a ledger component that assembles the DIDDoc from the NYM and ATTRIB components -- e.g. a new "getDIDDoc" endpoint/transaction.
In recent discussions, we've talked about having multiple ATTRIBs combine (if present) with the NYM to produce the DIDDoc, and what I'm suggesting above is that just the NYM and one ATTRIB combine to create the DIDDoc at any point in (ledger) time.
paul.bastian (Tue, 26 Jan 2021 14:32:13 GMT):
I'm partiocipating again today
paul.bastian (Tue, 26 Jan 2021 14:32:13 GMT):
I'm partiocipating again today, last weeks cancellation was an exception
paul.bastian (Tue, 26 Jan 2021 14:52:16 GMT):
I don't think that my proposal is actually completely contrary. If you want to put in eveything in one ATTRIB you can still use the "proprietary" ATTRIB and not use the specified ATTRIBs. that might be easier but might be worse later on. still everyone has a decision
kdenhartog (Tue, 26 Jan 2021 23:36:55 GMT):
Ahh I didn't understand you guys were proposing that again. I don't want to go that direction for the reason we discussed originally here unless it's addressed with the assembling aspects handle by the nodes. https://docs.google.com/document/d/1PE1KQHf41zlHbLm27UbgzJ7t7m2xr09JnjZWFT2ApwE/edit?disco=AAAAGtMcf_0
>We're proposing a ledger component that assembles the DIDDoc from the NYM and ATTRIB components
I'd prefer not handling it this way given it changes the read/write dynamics of the network which will impact vertical scaling of the ledger. I recognise that's not been a shared opinion with most others opting to prefer horizontal scaling (more networks). With this in mind, I think that if we can address the concerns in the google doc by handling this in the ledger component then I'd be alright with handling it this way.
>In recent discussions, we've talked about having multiple ATTRIBs combine (if present) with the NYM to produce the DIDDoc, and what I'm suggesting above is that just the NYM and one ATTRIB combine to create the DIDDoc at any point in (ledger) time.
This makes sense as a good in between to me. Would you mind if we setup a special time for me to join the topic call for this sometime in the next week? Getting on a call to sort this all out would probably be the easiest way to handle it. I'd be fine just jumping on a call with you @swcurran to explain where I'm at and leave it to you to continue it going forward as well.
swcurran (Wed, 27 Jan 2021 15:21:04 GMT):
@kdenhartog -- we think the issue you reference in the Google Doc is addressed because the ledger will construct and return the DIDDoc in a single transaction, and the NYM information will always be injected into the ATTRIB information to derive the controller of the DIDDoc. The ATTRIB must not supply the information that will come from the NYM.
Regards scaling -- today, the "Get Revocation Interval" transaction assembles data from a (possibly large) set of ledger entries, so it's not without precedent.
The question we raised at the call is whether the impact on the ledger would be larger if the DIDDoc was produced from the NYM plus 0 or 1 ATTRIB, where the ATTRIB is the full DIDDoc (minus the NYM component, of course) which would be quite large, or the NYM+0 to N ATTRIBS each containing minimal data that all combine to produce the DIDDoc.
dbluhm (Fri, 29 Jan 2021 17:44:11 GMT):
Has joined the channel.
swcurran (Mon, 01 Feb 2021 16:56:10 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-02
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* More discussion on ATTRIB vs. ATTRIBs
Please join in and help with this collaborative effort.
swcurran (Mon, 01 Feb 2021 16:56:10 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-02
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* More discussion on ATTRIB vs. ATTRIBs
* keyAgreement
* Recommendations in spec. for future work
* Ledger objects as DIDs -- schema, claim_def, etc.
Please join in and help with this collaborative effort.
paul.bastian (Mon, 01 Feb 2021 21:38:58 GMT):
I propose for next meeting we write down an comparison between ATTRIB vs ATTRIBs to formalize discussion and clarify things. list of things to compare could start with: principles and design goals for Indy, architecture goals, impact on overall transactions, impact on average read transactions, impact on average write transactions, code complexity, code effort, impact on ledger size, future compatiblity, benefits and assumptions like expected variety of used diddoc features in the future
paul.bastian (Mon, 01 Feb 2021 21:39:22 GMT):
anyone has some thoughts on what to compare, please add it here and we can have a discussion
swcurran (Mon, 01 Feb 2021 22:08:56 GMT):
My opinion is that one ATTRIB is better than N because:
- simpler design, and simpler for DID writers to understand e.g. "A NYM will generate this
swcurran (Mon, 01 Feb 2021 22:08:56 GMT):
My opinion is that one ATTRIB is better than N because:
- simpler design, and simpler for DID writers to understand e.g. "A NYM will generate this
dbluhm (Tue, 02 Feb 2021 14:31:14 GMT):
I have a conflicting meeting so I won't be able to attend the meeting today but I wanted to say that we're paying attention to these efforts and we appreciate the time and thought that's already gone into this discussion. We've been asking ourselves a lot of the same questions that you've already addressed.
paul.bastian (Tue, 02 Feb 2021 16:05:53 GMT):
So we had a good meeting and settled the issue, this is the wrapup from hyperledger confluence:
1. Agree on the NYM + 1 ATTRIB solution due to given motivation:
- NYM shall comprise of all security-relevant data, ATTRIB is for user → therefore ATTRIB can contain all the diddoc information that is not relevant to the security of the DID, the ledger must not need care too much
- Indy resources
- DIDdoc content might change too often in the near future and changing the Indy DID Method often might be too much trouble
- It needs to be communicated that the DIDdoc is the users responsilbity and the ledger only gives limited guarantees!
2. draft ideas:
- in the first version: verkey is the only verificationMethod, therefore ATTRIB shall not use verificationMethod (for simplicity)
- NYM generates context, id, verificationMethod
- ATTRIB shall not have id or verificationMethod
- contexts are merged with ATTRIB
- everything else from ATTRIB should be merged
3. ability to update the DID should be taken ONLY from NYM, not the DIDdoc
- verkey as mandatory in NYM
- more verkeys and/or n of m scheme could be added to NYM as optional in the future
- controller inside NYM that references another Indy DID
https://docs.google.com/presentation/d/1v9lnozcngR8xFGsVYd2qtrPvNdA1LLEw2XZObnAUhzU
4. in the future we will need other signature schemes
- NIST curves are not preferred
-post-quantum security will get relevant therefore this needs to be done anyway
5. in the future our verificationMethod might define a "type" referenced in the DID registries and we would include a context, this might become necessary when more complicated rules get put into NYM
swcurran (Tue, 02 Feb 2021 18:37:05 GMT):
@paul.bastian -- regards the W3C CCG Mailing list (here: https://lists.w3.org/Archives/Public/public-credentials/) and the specific discussion about Claim Defs (starts here: https://lists.w3.org/Archives/Public/public-credentials/2021Feb/0010.html).
RazaDen (Wed, 03 Feb 2021 19:55:55 GMT):
Has joined the channel.
shaangill025 (Wed, 03 Feb 2021 20:00:45 GMT):
Has joined the channel.
shaanjot.gill (Wed, 03 Feb 2021 20:12:08 GMT):
Has joined the channel.
etaleo (Mon, 08 Feb 2021 09:03:59 GMT):
Has joined the channel.
enroll7 (Mon, 08 Feb 2021 09:04:47 GMT):
Has joined the channel.
etaleo (Mon, 08 Feb 2021 09:33:54 GMT):
There is a universal resolver interface for DIDs - is there an equivalent universal interface for resolving Verifiable Credential Schemas / Cred Defs?
swcurran (Tue, 09 Feb 2021 02:52:28 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-02
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Proposal in hackmd doc on the format for DIDDoc ATTRIB and processing
Please join in and help with this collaborative effort.
swcurran (Tue, 09 Feb 2021 02:53:26 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 9 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Proposal in hackmd doc on the format for DIDDoc ATTRIB and processing
* Starting discussion about other ledger objects as DIDs.
Please join in and help with this collaborative effort.
paul.bastian (Tue, 09 Feb 2021 16:14:57 GMT):
This weeks discussion got a little stuck on two topics:
See hackmd document: https://hackmd.io/2IKUPROnRXW57Lmal_SGaQ?both
Format of the ATTRIB document (`@context`, nymKeyAgreement, content)
Process for adding ATTRIB
Handling of existing "endpoint" ATTRIB
is boolean variable a slippery slope?
shall the diddoc ATTRIB only include raw DID json that is to be merged?
disussion on nymKeyAgreement
pro: you can rotate verkey and automatically rotate the X25519 key without touching the ATTRIB, rotating takes 1 less write transaction, saves some bytes on the ledger
contra: less generic solution, special case for special signature mechanism, unlikely design to use same privatekey for NYM protection and KeyAgreement,
GET_DIDDOC request might be too troublesome as we cannot provide the indy state proof for client validation right now
rebuilding indy to include assembled diddoc might take some time
easier solution right now is the universal resolver driver concept → client requests NYM + ATTRIB and uses reference implementation to assemble the DID doc
Please provide thoughts on these topics
swcurran (Tue, 09 Feb 2021 21:54:30 GMT):
Question for @peacekeeper @danielhardman @brentzundel @drummondreed and others interested.
@paul.bastian references (above) the question about having in the DIDDoc ATTRIB an optional flag "nymKeyAgreement". Here is the rational for it and against it, in a little more detail than above:
If that flag is set in the DIDDoc ATTRIB, the NYM ED25519 verkey would be used to derive an X25519 key and a key agreement item would be added into the returned DIDDoc. That gives us three options:
- For those that don't need a key agreement key -- don't set the flag, don't include it in the "content" for the DIDDoc..
- For those that want single purpose keys -- don't set the flag and explicitly put a key agreement section into the DIDDoc with a different key.
- For those that want a key agreement key and are OK with using the verkey, set the flag. An added benefit is that when they update the NYM to rotate the verkey, the DIDDoc key agreement key would automagically also be updated.
The question is whether we want to make it easy to use the derived NYM verkey as the key agreement key or not?
- Is it a bad practice such that we want to discourage that, and push the user to have a separate key agreement key?
- Is it a sufficiently common practice that we want to provide an optional mechanism to enable that?
Opinions? It's not that big an issue, but we just wanted to get some others weighing in on the issue.
brentzundel (Tue, 09 Feb 2021 21:54:30 GMT):
Has joined the channel.
swcurran (Tue, 09 Feb 2021 22:02:43 GMT):
For next week, Sergey is going to talk about how state proofs are created in responding to ledger reads. If we have a "GET_DIDDOC" transaction, is there a way to get a state proof against some or all of the returned results? Related questions:
- would it be good to have the ledger return the two needed ledger objects, with state proofs, and leave it to the client to assemble the DIDDoc?
- Should the client do the querying to guarantee getting the right two objects and do the assembly? How would it trust the ledger to find the right version of the object?
- How does the existing "revocation interval" transaction work? It collects multiple ledger objects and returns a consolidated result.
Interesting stuff. See you next week...
RazaDen (Tue, 09 Feb 2021 22:43:48 GMT):
If I may add an additional comment here. Sergey mentioned that in the Sovrin mainnet, new transactions are posted every 30 minutes or so (by stewards? don't remember exactly) so that when a client does a read on the ledger, he can query a single peer and get a state proof response that is "recent". I don't know for other people in the group, but to me the semantics and docs I have read are not clear on this. Couple of questions from the top of my head:
- This periodic process of stewards posting transactions on the ledger needs to be somehow "programmed" by people who deploy their own indy ledger instance (?). I assume that to be the case.
- In which of the available indy ledgers do we need to do this? I am pretty sure in Sovrin they do it in the Config ledger. Does that cover the reads on the other ledgers as well? Not sure if Merkle Patricia proofs of all ledgers converge to the same root.
- Does the indy sdk actually make this "freshness" check? Is this configurable? For instance, if a state proof is older than 2, 10 or how many minutes, what happens?
drummondreed (Wed, 10 Feb 2021 08:17:16 GMT):
@swcurran and @paul.bastian I continue to have my conflict on this time slot on Tuesdays and it continues to bum me to miss these meetings. I will try to catch up soon. I do need to get a simple Hyperledger Indy HIPE posted soon for the DID `resource` parameter that we want to add to the DID Spec Registries.
danielhardman (Wed, 10 Feb 2021 15:49:40 GMT):
I don't have a strong opinion about the nymKeyAgreement flag; I can see both the pros and the cons, and I think the summary I heard sounds fair; whichever way that goes seems fine to me.
danielhardman (Wed, 10 Feb 2021 15:50:17 GMT):
The question about state proofs is intriguing; I'm curious to hear where an expert like Sergey ends up.
paul.bastian (Thu, 11 Feb 2021 13:30:14 GMT):
@danielhardman we had Sergey on the call last time and he brought up the topic
paul.bastian (Thu, 11 Feb 2021 13:31:34 GMT):
@swcurran I'm ok to switch the timeslot if that serves moire people. however please not too late for european times
paul.bastian (Thu, 11 Feb 2021 13:37:26 GMT):
you have two options for verify your read transaction:
A-query F+1 nodes, therefore you can be sure but it requires a lot of traffic.
B-query 1 node and rely mon the BLS-multisignature that signs the root hash of the particia merkle tree aka state proof, this state proof covers every transaction on the ledger and is multisinged by all nodes with a timestamp in regular intervals, therefore you also have freshness. this stateproof however only affects NYMs and ATTRIBs and not an newly assembled DIDdoc by the ledger. therefore you would need to regularly assemble all the DIDdocs and include them in the state proof
swcurran (Thu, 11 Feb 2021 20:46:30 GMT):
So a state proof is a point in time proof about the transactions on the ledger.
How does that translate into saying the data that I received for a transaction is valid? Is it that there is a proof with the result of calling the read that the returned result is a transaction that is part of the tree?
paul.bastian (Fri, 12 Feb 2021 08:50:37 GMT):
the (hash of) transaction is a leaf in the tree, the ledger can provide all the other hashes that let you go the path to the root, the root hash is multisigned by all the nodes with a fresh timestamp. that way you can can proof the validity of that transaction. how I understood sergey, the cumulative state of NYM and ATTRIB can be proven by this mechanism as is, but the assembled DIDdoc is something new that would need to be included in (a seperate?) patricia merkle tree
RazaDen (Fri, 12 Feb 2021 11:04:50 GMT):
If we assemble the DIDDoc on the client side by composing NYM and ATTRIB, then we don't need a new type of ledger transaction. The benefits of introducing a new type of ledger transaction are not so clear to me, quite frankly I see more issues than benefits. The semantics regarding the freshness if state proofs are a very crucial topic and further clarifications are warranted. First you need an external stimulus to frequently (how much?) update the state of the ledger so that state proofs are "fresh". This is what Stewards do in the Sovrin mainnet to my understanding every 30 minutes. Next, how does the indy-sdk currently handle this issue of "freshness" of state proofs? Is this 30 minute interval hardcoded in? Is it configurable? State proofs are secure in practice if all these details are fleshed out and specified in detail, otherwise the safest approach is to go with f+1 matching replies to a query.
RazaDen (Fri, 12 Feb 2021 11:04:50 GMT):
If we assemble the DIDDoc on the client side by composing NYM and ATTRIB, then we don't need a new type of ledger transaction. The benefits of introducing a new type of ledger transaction are not so clear to me, quite frankly I see more issues than benefits. The semantics regarding the freshness of state proofs are a very crucial topic and further clarifications are warranted. First you need an external stimulus to frequently (how much?) update the state of the ledger so that state proofs are "fresh". This is what Stewards do in the Sovrin mainnet to my understanding every 30 minutes. Next, how does the indy-sdk currently handle this issue of "freshness" of state proofs? Is this 30 minute interval hardcoded in? Is it configurable? State proofs are secure in practice if all these details are fleshed out and specified in detail, otherwise the safest approach is to go with f+1 matching replies to a query.
RazaDen (Fri, 12 Feb 2021 11:04:50 GMT):
If we assemble the DIDDoc on the client side by composing NYM and ATTRIB, then we don't need a new type of ledger transaction. The benefits of introducing a new type of ledger transaction are not so clear to me, quite frankly I see more issues than benefits. The semantics regarding the freshness of state proofs are a very crucial topic and further clarifications are warranted. First you need an external stimulus to frequently (how often?) update the state of the ledger so that state proofs are "fresh". This is what Stewards do in the Sovrin mainnet to my understanding every 30 minutes. Next, how does the indy-sdk currently handle this issue of "freshness" of state proofs? Is this 30 minute interval hardcoded in? Is it configurable? State proofs are secure in practice if all these details are fleshed out and specified in detail, otherwise the safest approach is to go with f+1 matching replies to a query.
swcurran (Fri, 12 Feb 2021 17:56:11 GMT):
So when you do a read transactions and get the state proof back, you get the multi-signed root hash and the path the transaction of interest, so you can validate the leaf's contribution to the root hash.
So to get the same validity for "GET_DIDDOC", we would have have the data for both contributor leaves. Is that right?
RazaDen (Sat, 13 Feb 2021 09:39:09 GMT):
On your first point, yes roughly that's how state proofs work. Of course, the nitty gritty details depend on how you organize the storage of peers or the ledger as a whole. To give you an example, Ethereum has multiple Merkle-Patricia tries: 1) the transaction/blockchain trie, 2) the "state" trie, which contains the key-value stores of all deployed smart contracts and can be used for appropriate "smart contract state proofs" and, 3) the "receipt" trie, which is basically where they store the result of transaction executions. I believe that Indy has only one Merkle Patricia trie per sub-ledger, however this is not really clear.
To your second point, the most straightforward way to currently implement the "GET_DIDDOC" operation would be to construct a state proof that contains the most fresh "NYM" and "ATTRIB" of a specific DID, so pretty much what you mentioned yes. Whether we have one path in the tree for the NYM and a separate path for the ATTRIB, or if we unify them in a single sub-tree proof, that's just a minor detail, as long as they both refer to the *same* and *most fresh* root hash.
The discussion about the semantics of *freshness* and how they are enforced/configured (if at all) has to be clearly fleshed out.
JamesEbert (Mon, 15 Feb 2021 19:41:46 GMT):
Has joined the channel.
swcurran (Mon, 15 Feb 2021 20:05:54 GMT):
@sergey.khoroshavin -- are you able to make the Indy DID Method call tomorrow/Tuesday @ 7AM Pacific / 15:00 UTC / 16:00 CET. Per our call last week, hoping you can go over the state proofs on Indy, and the best approach to a client getting the DIDDoc, the pair of transactions or both, and how that relates to the state proof.
I notice the reference here (https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#get_revoc_reg_delta) to state proofs and the responsibility of the client for a similar "multi-ledger objects" consolidation transaction on Indy. Basically, it says "the client is responsible for checking the returned consolidated returned", which is completely impractical for the use case.
sergey.khoroshavin (Mon, 15 Feb 2021 20:05:54 GMT):
Has joined the channel.
swcurran (Mon, 15 Feb 2021 20:20:02 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 16 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-16
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Proposal in hackmd doc on the format for DIDDoc ATTRIB and processing
* Starting discussion about other ledger objects as DIDs.
Please join in and help with this collaborative effort.
swcurran (Mon, 15 Feb 2021 20:20:56 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 16 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-16
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Can we do the GET_DIDDOC transaction?
* ATTRIB DIDDoc raw data format
* How to represent Indy Ledger Objects as DIDs?
Please join in and help with this collaborative effort.
drummondreed (Mon, 15 Feb 2021 20:24:36 GMT):
@swcurran I am able to come to tomorrow's meeting! My conflicting meeting is cancelled for tomorrow. And it looks like good timing as I can address your third agenda item ("How to represent Indy Ledger Objects as DIDs?"). We need an Indy HIPE created quickly in order to get the "resource" parameter listed in the DID Spec Registries. I will strive to have the necessary content ready.
drummondreed (Mon, 15 Feb 2021 20:24:36 GMT):
@swcurran Good news! I am able to come to tomorrow's meeting. My other conflicting meeting is cancelled for tomorrow. And it looks like good timing as I can address your third agenda item ("How to represent Indy Ledger Objects as DIDs?"). We need an Indy HIPE created quickly in order to get the "resource" parameter listed in the DID Spec Registries. I will strive to have the necessary content ready.
swcurran (Mon, 15 Feb 2021 20:25:21 GMT):
Awesome -- that would be great. Thanks, Drummond.
danielhardman (Mon, 15 Feb 2021 22:29:04 GMT):
I can probably come to part of tomorrow's meeting. It looks like I have a meeting right before (that sometimes bleeds over a bit), and a meeting at the 30-min mark as well (that sometimes gets cancelled). So I'll try to come for what I can. Looking forward to reading Drummond's HIPE content.
drummondreed (Wed, 17 Feb 2021 03:47:41 GMT):
@danielhardman et al: even though we didn't get to it on today's call, please do review this very short spec for the DID "resource" parameter. It's very simple and straightforward because it only defines the parameter to add to a DID to request that it return a digital resource directly from a verifiable data registry. The harder part (though hopefully also relatively straightforward) is how the DID method specification will specify that an Indy ledger returns the requested digital resource—which can be absolutely any file that the VDR can return (schema, cred def, revocation registry, etc.)
drummondreed (Wed, 17 Feb 2021 03:48:02 GMT):
Here's the link to the Google doc: https://docs.google.com/document/d/1f99z4Bf8F-DA8EbkNjInVQv2ncJGPwF_Dp7I7Mfyhqs/edit?usp=sharing
danielhardman (Wed, 17 Feb 2021 21:14:41 GMT):
Left some comments/suggestions. Looks good.
Tanvi (Sat, 20 Feb 2021 14:34:39 GMT):
Has joined the channel.
swcurran (Mon, 22 Feb 2021 15:18:09 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 23 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-23
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Revisiting/Finalizing points from last two meetings (state proofs, agreement keys, DIDDoc content)
- Resolving ledger objects as DIDs?
swcurran (Mon, 22 Feb 2021 16:33:51 GMT):
Hey Folks, I'm writing up in the hackmd document what we discussed last week, and I really wonder if it would not be easier to add a new item to the NYM data structure that is the planned ATTRIB, so that we can eliminate the work in both finding the right combination of transactions, trusting the ledger to return the right combination, and handling multiple state proofs. If we add an optional data item to the NYM transaction, all the DIDDoc data is in one place. There is still an assembly task, but the effort is lighter: For example:
e.g we add `diddocContent` to the `data` structure:
``` json
"data": {
"ver": 1,
"dest":"GEzcdDLhCpGCYRHW82kjHd",
"verkey":"~HmUWn928bnFT6Ephf65YXv",
"role":101,
"diddocContent" : { ... }
},
```
swcurran (Mon, 22 Feb 2021 16:33:51 GMT):
Hey Folks, I'm writing up in the hackmd document what we discussed last week, and I really wonder if it would not be easier to add a new item to the NYM data structure that is the planned ATTRIB, so that we can eliminate the work in both finding the right combination of transactions, trusting the ledger to return the right combination, and handling multiple state proofs. If we add an optional data item to the NYM transaction, all the DIDDoc data is in one place. There is still an assembly task, but the effort is lighter: For example:
e.g we add `diddocContent` to the `data` structure:
``` json
"data": {
"ver": 1,
"dest":"GEzcdDLhCpGCYRHW82kjHd",
"verkey":"~HmUWn928bnFT6Ephf65YXv",
"role":101,
"diddocContent" : { ... }
},
```
swcurran (Mon, 22 Feb 2021 16:36:17 GMT):
With that, there is just one transaction returned to get a DIDDoc and we're only extending existing functionality.
The only caveat I see is that we might would have to handle the existing "endpoint" handling that is in common use.
swcurran (Tue, 23 Feb 2021 16:28:55 GMT):
@sergey.khoroshavin --- when you are back, love to hear your thoughts on this idea ^^^. How does this compare in effort to, for example, a new read transaction (GET_DIDDOC) that finds and returns two related documents with two state proofs?
Thanks
swcurran (Tue, 23 Feb 2021 18:40:39 GMT):
FYI -- Andrew did some code checking. The state proof signature on a NYM is the id+role+verkey vs. on the whole transaction so it wouldn't work out of the box. This would have to change to include the additional field, which in turn would probably introduce some canonicalization issues (or not....).
thomas_kim (Wed, 24 Feb 2021 05:01:17 GMT):
Has joined the channel.
paul.bastian (Thu, 25 Feb 2021 16:37:41 GMT):
one question came to my mind reading the DID-Core spec. Shall we limit the serialisiation formats in the DID Indy method to JSON/JSON-LD to guarantee better interoperability?
swcurran (Tue, 02 Mar 2021 02:11:07 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday February 23 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-23
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- NYM update
- Serialization Formats
- Other ledger objects as DIDs
swcurran (Tue, 02 Mar 2021 02:11:07 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-02-23
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- NYM update
- Serialization Formats
- Other ledger objects as DIDs
swcurran (Tue, 02 Mar 2021 02:11:07 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-03
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- NYM update
- Serialization Formats
- Other ledger objects as DIDs
swcurran (Tue, 02 Mar 2021 02:11:07 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 2 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-02
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- NYM update
- Serialization Formats
- Other ledger objects as DIDs
swcurran (Wed, 03 Mar 2021 00:17:29 GMT):
@drummondreed @brentzundel -- we'd like to understand more about your "resource" DID resolution query parameter and how it relates to the discussion about referencing non-DID/NYM ledger objects on Indy. Do you have a time that we could meet on that? We'd like to do it on a morning so that our European participants can make it. Can you propose some times?
swcurran (Wed, 03 Mar 2021 00:39:30 GMT):
All -- at our meeting today, the folks present were happy with approaches, but want to confirm a couple of decisions with others that couldn't make it -- @kdenhartog @peacekeeper @danielhardman @sergey.khoroshavin @esplinr @andrew.whitehead
- We suggest adding extra DIDDoc data in an optional field in the NYM (`"diddocContent"`) itself, and to not use ATTRIBs at all in the assembly of a DIDDoc associated with a NYM.
- We think that DIDDoc assembly for reads should be done by the client, not by the ledger so as to not affect the handling of the state proof coming back for the NYM ledger object.
- We think that the ledger should check for a valid DIDDoc on NYM write, which means the ledger will be doing some assembly and verification.
- This is a security tradeoff -- a risk of a vulnerability in the assembly code affecting the nodes of the ledger vs. not writing an invalid DIDDoc to the ledger.
- Of the three DIDDoc representations in the DID Core spec, we plan to only support JSON-LD. Does that make sense?
- We suggest dropping the idea of a flag to include the derived key agreement key in the DIDDoc and instead requiring the writer derive and insert the key themselves if they want to.
Feedback on these issues would be greatly appreciated.
swcurran (Wed, 03 Mar 2021 00:39:30 GMT):
All -- at our meeting today, the folks present were happy with approaches, but want to confirm a couple of decisions with others that couldn't make it -- @kdenhartog @peacekeeper @danielhardman @sergey.khoroshavin @esplinr @andrew.whitehead
- We suggest adding extra DIDDoc data in an optional field in the NYM (`"diddocContent"`) itself, and to not use ATTRIBs at all in the assembly of a DIDDoc associated with a NYM.
- We think that DIDDoc assembly for reads should be done by the client, not by the ledger so as to not affect the handling of the state proof coming back for the NYM ledger object.
- We think that the ledger should check for a valid DIDDoc on NYM write, which means the ledger will be doing some assembly and verification.
> - This is a security tradeoff -- a risk of a vulnerability in the assembly code affecting the nodes of the ledger vs. not writing an invalid DIDDoc to the ledger.
- Of the three DIDDoc representations in the DID Core spec, we plan to only support JSON-LD. Does that make sense?
- We suggest dropping the idea of a flag to include the derived key agreement key in the DIDDoc and instead requiring the writer derive and insert the key themselves if they want to.
Feedback on these issues would be greatly appreciated.
esplinr (Wed, 03 Mar 2021 00:39:31 GMT):
Has joined the channel.
swcurran (Wed, 03 Mar 2021 00:42:01 GMT):
I'm going to go ahead and update the HackMD document to reflect those changes -- especially the eliminate of an talk of using ATTRIBs. Obviously we can undo those changes if the feedback is that those are bad ideas.
kdenhartog (Wed, 03 Mar 2021 01:21:30 GMT):
>We suggest adding extra DIDDoc data in an optional field in the NYM ("diddocContent") itself, and to not use ATTRIBs at all in the assembly of a DIDDoc associated with a NYM.
I'm good with this approach. Biggest reason I didn't consider this approach originally was because we couldn't commit to modifying Indy Ledger to make that work. If others are willing to do it, I'd be in favor of it.
>We think that DIDDoc assembly for reads should be done by the client, not by the ledger so as to not affect the handling of the state proof coming back for the NYM ledger object.
I'm also happy with this but for other reasons. It will help focus the validator processing time on writes rather than reads which will be beneficial for scale.
>We think that the ledger should check for a valid DIDDoc on NYM write, which means the ledger will be doing some assembly and verification.
This would be wise to be compliant with resolution consumption (and ultimately production later when it's emitting it to the client). It's a good way to prevent random JSON from ending up on there as well. Are you thinking these will be JSON compliant data or JSON-LD compliant? I'm thinking it will be harder to support extensions with JSON (we'll have to make an update each time we want to allow a new extension property I think), but not unreasonable.
> Of the three DIDDoc representations in the DID Core spec, we plan to only support JSON-LD. Does that make sense?
This answers my last question. I'm definitely in favor of this as it will help in processing extensions as well.
> We suggest dropping the idea of a flag to include the derived key agreement key in the DIDDoc and instead requiring the writer derive and insert the key themselves if they want to.
Agree with this as well. It will hopefully lead to better practices around separating keys as well and avoid security vulnerabilities (like with RSA reusing a private key with DH / old signature algorithm in a way that is known to reveal the private key)
kdenhartog (Wed, 03 Mar 2021 01:21:40 GMT):
TL;DR I'm on board with it all
andrew.whitehead (Wed, 03 Mar 2021 01:24:23 GMT):
I agree with all of that as well, barring implementation issues.
> - We think that the ledger should check for a valid DIDDoc on NYM write, which means the ledger will be doing some assembly and verification.
Is assembly actually necessary to check the schema of the submitted document?
kdenhartog (Wed, 03 Mar 2021 01:25:09 GMT):
Shouldn't be if you're using JSON-LD properly
kdenhartog (Wed, 03 Mar 2021 01:27:44 GMT):
You should be able to just feed it into a JSON-LD expand then store then recall compact and store the result of that
kdenhartog (Wed, 03 Mar 2021 01:28:05 GMT):
This should drop all the unlisted properties and verify the jsonld is all properly formatted
kdenhartog (Wed, 03 Mar 2021 01:29:27 GMT):
Considerations should be taken around documentLoaders though. They can use a remote resolution of unknown contexts but for security reasons I'd suggest disabling remote resolution and then updating a local context document loader to support the new contexts registered as extensions
kdenhartog (Wed, 03 Mar 2021 01:30:06 GMT):
This prevents semantic term overriding if the terms aren't protected properly in the context
george.aristy (Wed, 03 Mar 2021 20:07:38 GMT):
Has joined the channel.
paul.bastian (Fri, 05 Mar 2021 14:01:22 GMT):
my little concern with checking snytax&semantic of the "didDocContent", that parsing is difficult (even with JSON), error-prone and has often been a door for vulnerabilities. as the ledger is the source of trust, it is very vulnerable and if there is a bug, that leads to RCE, all nodes are affected, as everyone is running the same software. I know we are already parsing all the transactions, but parsing the known is safer than parsing arbitrary data. If there is any validation of the "didDocContent" it must be very careful are limited
paul.bastian (Fri, 05 Mar 2021 14:02:15 GMT):
also I'm not able to attend next weeks meeting as I have conflict on that tuesday @swcurran
danielhardman (Mon, 08 Mar 2021 16:34:00 GMT):
I'm okay with most of this.
I don't feel comfortable with JSON-LD DID docs only, though. The case for JSON-LD in credentials is a good one, but I think the case for JSON-LD in DID docs is NOT NEARLY as good. I would like to talk about that more. However, I can't show up to one of these meetings to talk about it; I have a conflict with this meeting block every single week. Any chance we could discuss in an Indy implementers call or something?
swcurran (Mon, 08 Mar 2021 16:37:53 GMT):
I assume you would propose JSON as the representation?
danielhardman (Mon, 08 Mar 2021 16:38:02 GMT):
yes
swcurran (Mon, 08 Mar 2021 16:38:14 GMT):
Didn't think CBOR :-).
swcurran (Mon, 08 Mar 2021 16:39:25 GMT):
Interesting -- I thought that would be pretty uncontroversial. We need to find a new time for the meeting. I guess we'll try a doodle. I haven't ever done that, but will try it.
swcurran (Mon, 08 Mar 2021 16:41:01 GMT):
Plan tomorrow if for Dan G and I to work on getting the current doc into SpecUp in the did-indy-method repo, so we transition to github.
danielhardman (Mon, 08 Mar 2021 16:41:22 GMT):
I'm not dead set against JSON-LD. I could totally go that way, so this is not me putting up a stink about something I'm opposed to. But I would like to enumerate the pros and cons and make sure everybody buys off on the tradeoffs. I don't think it's obvious at all.
swcurran (Mon, 08 Mar 2021 16:41:56 GMT):
Then, hopefully we will have a new time next week. I've also asked @drummondreed and @brentzundel to prepare a talk about resources and how we plan to access other Indy objects on the ledger at a time that they can make.
swcurran (Tue, 09 Mar 2021 02:09:59 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 9 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-09
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
swcurran (Tue, 09 Mar 2021 02:09:59 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 9 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-09
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Working session to move the HackMD to SpecUp and into the https://github.com/hyperledger/indy-did-method repo
swcurran (Tue, 09 Mar 2021 19:56:57 GMT):
At today's meeting, @sergey.khoroshavin was there and confirmed that the approach of adding an item (`diddocContent`) to the NYM is a reasonable approach. So that's a lock, as are all but the JSON vs. JSON-LD representations of DIDDocs resolved from Indy.
Dan and I worked on the spec-up repo and are close to having a starting point.
swcurran (Tue, 09 Mar 2021 19:59:06 GMT):
What would everyone think of having the meeting one hour earlier on Tuesday's -- 6AM Pacific instead of 7AM. I know that would be rough on Drummond and I. Anyone else on the west coast? Would that work for others?
Would that allow @drummondreed @danielhardman and others that can't make it now be able to attend. I think we are almost done with the work, as there is not that much spec work to be done.
danielhardman (Wed, 10 Mar 2021 07:32:21 GMT):
I start work at 6 am Mountain time (5 am Pacific) each Tuesday and am consumed for several hours before I come up for air. So that time slot would not work for me. Maybe it would be simpler for me to try to write up my thoughts on this topic and share them in that form, instead of being hard to work with, schedule-wise.
HighBrow (Sun, 14 Mar 2021 08:18:15 GMT):
Has joined the channel.
swcurran (Sun, 14 Mar 2021 21:58:37 GMT):
I took a pass at getting the HackMD document to included all that we've talked about so far. Please take a look when you can. We still don't have namespaced IDs for non-NYMs, and I think the DND/DNR parts may not be included.
swcurran (Sun, 14 Mar 2021 22:02:01 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 16 at 7AM Pacific / 14:00 UTC / 15:00 CET. *Note the time change in Europe!*
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-16
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Accessing "resources" via DID resolution - Drummond
* Serialization formats - use JSON?
* A "close to finished" DID Method Specification?
swcurran (Sun, 14 Mar 2021 22:03:21 GMT):
Note that @drummondreed will be able to make this meeting, so we will be talking about the plan to reference `resources` that are on the ledger.
If @danielhardman can make it, we'll also talk about his thought about using JSON, not JSON-LD representations of DIDDocs.
drummondreed (Mon, 15 Mar 2021 07:20:19 GMT):
@swcurran @brentzundel @paul.bastian @danielhardman et al: I finally finished a new rev on the DID Resource Parameter spec that now includes a lot more info from the email thread we had. It is still in the same Google doc: https://docs.google.com/document/d/1f99z4Bf8F-DA8EbkNjInVQv2ncJGPwF_Dp7I7Mfyhqs/edit?usp=sharing
drummondreed (Mon, 15 Mar 2021 07:21:22 GMT):
Please do review/comment as you have time. I plan to attend tomorrow's meeting (provided it is still at 7AM Pacific DAYLIGHT Time, i.e., our new U.S. time setting) and look forward to reviewing it then.
danielhardman (Wed, 17 Mar 2021 00:50:52 GMT):
All: I apologize for not being able to talk about my JSON-vs-JSON-LD concern in our meeting. I have a standing conflict that prevents my attendance. Here's a google doc that captures my thinking. I am not so emotionally or intellectually caught up in my own perspective here that I will balk if I am out-voted, but I would appreciate knowing that a thoughtful discussion about it occurred before a decision was made. https://docs.google.com/document/d/1Zcc3IluY23-cycamUQrBQbWN3FHEWOV5bVUdZn6a2zQ/edit?usp=sharing.
I'll be curious to hear what you decide, and I promise I'll be cheerful either way.
rome-sandra (Wed, 17 Mar 2021 10:15:03 GMT):
Has joined the channel.
swcurran (Mon, 22 Mar 2021 18:53:44 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 16 at 7AM Pacific / 14:00 UTC / 15:00 CET. Note the time change in Europe!
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-16
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Identifiers with naming for non-NYM ledger objects - ideas for moving this forward
- Serialization formats - use JSON?
- If there is time: A "close to finished" DID Method Specification?
swcurran (Mon, 22 Mar 2021 18:53:44 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 23 at 7AM Pacific / 14:00 UTC / 15:00 CET. Last week of the NA/Europe time change weirdness.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-23
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Identifiers with naming for non-NYM ledger objects - ideas for moving this forward
- Serialization formats - use JSON?
- If there is time: A "close to finished" DID Method Specification?
paul.bastian (Tue, 23 Mar 2021 15:09:07 GMT):
sry I forgot the damn time shift this week :(
kdenhartog (Wed, 24 Mar 2021 05:15:42 GMT):
@danielhardman that's a pretty good argument for using JSON over JSON-LD in my opinion. I still lean towards using JSON LD because I've gotten used to using JSON-LD tooling now and like the extensiblity option it presents. With that in mind, I think there's strong merit to saying we're going to do things the JSON only way. The first one that I didn't see mentioned is the diversity of implementation. As Orie points out in the linked comment everyone is using JSON-LD and many of them are accidently being successful. I don't think that will always be the case as we extend did documents more though, so having the ability to extend using the registries and setting good patterns will be useful in my opinion. There was no reason to add all the abstraction gymnastics that we did with the ADM if no one actually uses it.
Second having a large community who is doing JSON only DIDs will be beneficial for catching interop issues early between the different data models. If there's one thing I've learned over the time I've been involved it's that we all intend to get to an interoperable SSI world, but we often times get caught up on the details which make us take a bit longer. By having two camps that are doing things different ways, but still working towards interoperability sooner we'll end up with better more robust software faster in my opinion.
This is all to say, I tend to lean towards the JSON only route for the Indy DID method for the reasons above plus everything Daniel said and am happy to help navigate the hurdles we'll likely encounter along the way such as properly using the registry to handle extensibility in JSON. I'm sure the same can be said for others in the community as well.
swcurran (Wed, 24 Mar 2021 14:05:51 GMT):
We had an interesting meeting talking through the ways to get namespacing into IDs for Schema and Claim Def.
swcurran (Wed, 24 Mar 2021 14:05:57 GMT):
Write up coming soon.
danielhardman (Wed, 24 Mar 2021 16:38:41 GMT):
I would like to clarify something, just to test for a common mental model.
I am NOT advocating that did:indy preclude JSON-LD DID documents. Rather, I am advocating that did:indy express no opinion whatsoever about JSON-LD. If someone wants to put a JSON-LD DID document into an indy ledger, they should be able to do so -- but the ledger should not be running JSON-LD validation logic to guarantee correctness. And if someone gets a DID document out of an Indy ledger and wants to interpet it as JSON-LD (e.g., because it contains a "@context" property at the root), that should be *totally fine*.
The opposite approach would be to announce that all DID docs on an Indy ledger MUST be JSON-LD, and to enforce that. This would mean that people attempting to use ordinary JSON would have to learn to comply, and that we'd have to have JSON-LD support in the ledger codebase.
My position is based on a desire to support a least common denominator approach that is more inclusive, NOT on a desire to make things harder for people wanting to use JSON-LD. And it is based on the observation that all JSON-LD is valid JSON, but not all valid JSON is JSON-LD. Therefore, having the ledger expect/enforce valid JSON is the most flexible (and the least work).
andrew.whitehead (Wed, 24 Mar 2021 18:25:02 GMT):
It might be reasonable to enforce that IF the DID document has a `@context` property, it references the `https://www.w3.org/ns/did/v1` context first (or only), so that the known properties have their expected meanings
kdenhartog (Mon, 29 Mar 2021 07:35:10 GMT):
I’ll give a read over the JSON-LD consumer rules to see if we can make that work. I like that idea, but I’m not sure how I’d expect edge cases to be handled for it. I’m curious how @peacekeeper would feel about that as well.
swcurran (Mon, 29 Mar 2021 16:45:09 GMT):
Folks -- working through the references to SCHEMA and CLAIM_DEF objects. I've confirmed that on the ledger and in an indy/aries client, the referenced objects are as I have documented in the hackmd document. As such, applying the restrictions that I assumed, namespacing a SCHEMA is easy (change NYM-ID to DID) and a some of the CLAIM_DEF issue is the same. However, within a CLAIM_DEF ID is the SeqNo of the SCHEMA. Since the SCHEMA may be on a different ledger, I propose that the CLAIM_DEF ID be changed from having a just the SeqNo to having either:
- the SeqNo if the same ledger as the CLAIM_DEF
-
swcurran (Mon, 29 Mar 2021 16:45:09 GMT):
Folks -- working through the references to SCHEMA and CLAIM_DEF objects. I've confirmed that on the ledger and in an indy/aries client, the referenced objects are as I have documented in the hackmd document. As such, applying the restrictions that I assumed, namespacing a SCHEMA is easy (change NYM-ID to DID) and a some of the CLAIM_DEF issue is the same. However, within a CLAIM_DEF ID is the SeqNo of the SCHEMA. Since the SCHEMA may be on a different ledger, I propose that the CLAIM_DEF ID be changed from having a just the SeqNo to having either:
- the SeqNo if the same ledger as the CLAIM_DEF
-
swcurran (Mon, 29 Mar 2021 16:45:09 GMT):
Folks -- working through the references to SCHEMA and CLAIM_DEF objects. I've confirmed that on the ledger and in an indy/aries client, the referenced objects are as I have documented in the hackmd document. As such, applying the restrictions that I assumed, namespacing a SCHEMA is easy (change NYM-ID to DID). The same change to a CLAIM_DEF ID solves some of the issues. However, within a CLAIM_DEF ID is the SeqNo of the SCHEMA. Since the SCHEMA may be on a different ledger, I propose that the CLAIM_DEF ID be changed from having a just the SeqNo to having either:
- the SeqNo if the same ledger as the CLAIM_DEF, or
- `
andrew.whitehead (Mon, 29 Mar 2021 17:05:07 GMT):
Schemas are immutable, so they can be identified by a single sequence number, but a NYM can be updated. `did:indy:
andrew.whitehead (Mon, 29 Mar 2021 17:05:07 GMT):
Schemas are immutable, so they can be identified by a single sequence number, but a NYM can be updated. `did:indy:
andrew.whitehead (Mon, 29 Mar 2021 17:05:07 GMT):
Schemas are immutable, so they can be identified by a single sequence number, but a NYM can be updated. `did:indy:
andrew.whitehead (Mon, 29 Mar 2021 17:09:30 GMT):
I suppose `did:indy:
swcurran (Mon, 29 Mar 2021 17:52:45 GMT):
Agreed on the sequence number approaches for NYMs. My rational for general support is that if we have to embed the SCHEMA ID into the CLAIM_DEF ID, the easiest way is to use the a SeqNo form and to generally support it.
swcurran (Mon, 29 Mar 2021 17:52:45 GMT):
Agreed on the sequence number approaches for NYMs. My rational for general support is that if we have to embed the SCHEMA ID into the CLAIM_DEF ID, the easiest way is to use the a SeqNo form and if we are doing that, we might as well support it generally.
andrew.whitehead (Mon, 29 Mar 2021 17:54:37 GMT):
Yes for sure, that's why I suggested the second format because `?versionId=` won't work in that context. Anything parsing the IDs will need updating anyway
andrew.whitehead (Mon, 29 Mar 2021 17:55:36 GMT):
I'd much rather have both the seqno and the ID together than just the seqno
andrew.whitehead (Mon, 29 Mar 2021 17:57:23 GMT):
It would make revocation registry IDs a bit ridiculously long
swcurran (Mon, 29 Mar 2021 17:58:23 GMT):
We are assuming that a revocation registry MUST be on the same ledger as the CLAIM_DEF and hence, we don't plan on making any changes to those.
Thoughts about that?
andrew.whitehead (Mon, 29 Mar 2021 18:01:18 GMT):
I think changes will be required anyway because the syntax currently supports a qualified DID there
andrew.whitehead (Mon, 29 Mar 2021 18:02:01 GMT):
I'm okay with that restriction though
swcurran (Tue, 30 Mar 2021 02:50:40 GMT):
did:indy Method Spec -- Next meeting: scheduled for Tuesday March 30 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-03-30
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Identifiers with naming for non-NYM ledger objects
- Serialization formats - use JSON?
swcurran (Tue, 06 Apr 2021 13:49:32 GMT):
Last Minute Meeting Announcement:
did:indy Method Spec -- Next meeting: scheduled for Tuesday April 6 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-04-06
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Identifiers with naming for non-NYM ledger objects
- Serialization formats - use JSON?
echsecutor (Wed, 07 Apr 2021 12:05:46 GMT):
Has joined the channel.
kdenhartog (Thu, 08 Apr 2021 07:44:54 GMT):
To confirm is this only for the class of ledger object identifiers like the schema/claim def/rev objects?
kdenhartog (Thu, 08 Apr 2021 07:58:10 GMT):
Also follow up does the sequence number get generated only by the node and after successful confirmation to the nodes?
This could make for some odd aspects around signing these objects.
The main one I'm thinking about is if the revocation object is structured as a VC like what RevocationList2020 does. In that case, if the ID property of the VC is generated only after successful addition of the id then I'm not sure how the signing of it would occur by the NYM who anchored it to the ledger because they can't sign over the ID until they know it, but they don't know it until it's successfully anchored.
This could be resolved by having the generation of the method specific identifier being generated by the submitter rather than by the node on successful submission. And of course there's the secondary discussion about changing the data model that would need to be considered.
The two alternatives I see are to
1. not standardize the revocation object data model around a VC which is advantageous because then no code needs to change, but has the tradeoff of the data model being different for a variety of different ecosystems. This is how things are today.
2. transform the revocation data model on indy today to a standard VC data model and build some sort of link data proof scheme that has standardized processing logic that a verifier can use to verify the revocation data matches the original signed object on the ledger which is provided in the proof object. This has the benefit of moving towards a common data model without needing changes to the ledger, but has the tradeoff in that it needs to basically include the entire signed ledger object in the proof of the VC.
Have you thought anything about this part of the problem yet?
swcurran (Thu, 08 Apr 2021 14:52:25 GMT):
We've not contemplated changing the revocation mechanism as yet. The RL-2020 schema as is no good for a ZKP-based VC system, so it's not a target. The idea of using a VC is a viable way to manage the revocation data.
The sequence number address is seen as an additional resolution mechanism to get at the raw transaction data vs. a DIDDoc.
Per the latest meeting, we're thinking of altering the identifiers so as to not embed identifiers in identifiers. Instead, we would use DID path-ing as an approach to identifying objects.
swcurran (Fri, 09 Apr 2021 23:41:45 GMT):
Folks -- something to think about. Talking to @andrew.whitehead and realized that a NYM controller adding the "didDocContent" element must be able to add new entries into the VerificationMethod array to do things like add a BLS can as an issuer of BBS+ VCs. Thus, the bit we have about merging the `@context` entries from the `didDocContent` must also cover the other parts of the NYM-generated DIDDoc.
>
Andrew proposed an idea that instead of merging the `didDocContent` into the NYM-generated DIDDoc, that instead we require that the `didDocContent` must be a complete DIDDoc and that we check it for the inclusion of the NYM in the Verification Method. So instead of
- generate the template using the NYM data
- add in the `didDocContent`
- check for a valid JSON and DIDDoc
We instead:
- use the `didDocContent` as the DIDDoc
- check the NYM verification method is in the DIDDoc
- check for valid JSON and DIDDoc.
Thoughts about that idea -- @paul.bastian @danielhardman @vinomaster @kdenhartog ?
swcurran (Fri, 09 Apr 2021 23:41:45 GMT):
Folks -- something to think about. Talking to @andrew.whitehead and realized that a NYM controller adding the "didDocContent" element must be able to add new entries into the VerificationMethod array to do things like add a BLS so the controller can be an issuer of BBS+ VCs. Thus, the bit we have about merging the `@context` entries from the `didDocContent` must also cover the other parts of the NYM-generated DIDDoc.
>
Andrew proposed an idea that instead of merging the `didDocContent` into the NYM-generated DIDDoc, that instead we require that the `didDocContent` must be a complete DIDDoc and that we check it for the inclusion of the NYM in the Verification Method. So instead of
- generate the template using the NYM data
- add in the `didDocContent`
- check for a valid JSON and DIDDoc
We instead:
- use the `didDocContent` as the DIDDoc
- check the NYM verification method is in the DIDDoc
- check for valid JSON and DIDDoc.
Thoughts about that idea -- @paul.bastian @danielhardman @vinomaster @kdenhartog ?
swcurran (Fri, 09 Apr 2021 23:41:45 GMT):
Folks -- something to think about. Talking to @andrew.whitehead and realized that a NYM controller adding the "didDocContent" element must be able to add new entries into the VerificationMethod array to do things like add a BLS so the controller can be an issuer of BBS+ VCs. Thus, the bit we have about merging the `@context` entries from the `didDocContent` must also cover the other parts of the NYM-generated DIDDoc.
>
Andrew proposed an idea that instead of merging the `didDocContent` into the NYM-generated DIDDoc, that instead we require that the `didDocContent` must be a complete DIDDoc and that we check it for the inclusion of the NYM in the Verification Method. So instead of
- generate the template using the NYM data
- add in the `didDocContent` if present
- check for a valid JSON and DIDDoc
We instead:
- use the `didDocContent` as the DIDDoc (if not present, use the NYM content and generate the minimal DIDDoc)
- check the NYM verification method is in the DIDDoc
- check for valid JSON and DIDDoc.
Thoughts about that idea -- @paul.bastian @danielhardman @vinomaster @kdenhartog ?
vinomaster (Fri, 09 Apr 2021 23:41:45 GMT):
Has joined the channel.
drummondreed (Sun, 11 Apr 2021 00:02:23 GMT):
That makes sense to me.
andrew.whitehead (Sun, 11 Apr 2021 00:11:12 GMT):
I suppose the downside is more processing required by the ledger nodes. Also since DID docs are fairly free-form there should probably be a standard way for the network operators to 'evict' a NYM with PII or copyrighted data or whatever in it. Maybe that's already possible by just writing a new NYM transaction.
hcsatish (Mon, 12 Apr 2021 07:05:14 GMT):
Has joined the channel.
danielhardman (Mon, 12 Apr 2021 17:11:50 GMT):
I think this is reasonable.
swcurran (Tue, 13 Apr 2021 02:06:45 GMT):
Last Minute Meeting Announcement:
did:indy Method Spec -- Next meeting: scheduled for Tuesday April 13 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-04-13
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Merge DIDDoc from NYM+diddocContent or diddocContent only
- Identifiers with naming for non-NYM ledger objects
- Serialization formats - use JSON?
- IIW Presentation
swcurran (Tue, 13 Apr 2021 02:06:45 GMT):
Tomorrow Meeting:
did:indy Method Spec -- Next meeting: scheduled for Tuesday April 13 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-04-13
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Merge DIDDoc from NYM+diddocContent or diddocContent only
- Identifiers with naming for non-NYM ledger objects
- Serialization formats - use JSON?
- IIW Presentation
swcurran (Tue, 13 Apr 2021 02:06:45 GMT):
Next Meeting:
did:indy Method Spec -- Next meeting: scheduled for Tuesday April 13 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-04-13
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Merge DIDDoc from NYM+diddocContent or diddocContent only
- Identifiers with naming for non-NYM ledger objects
- Serialization formats - use JSON?
- IIW Presentation
esplinr (Thu, 15 Apr 2021 21:02:31 GMT):
Is there a draft Indy HIPE that explains the plan for the new Indy DID Method? That would help me understand the progress the group is making.
swcurran (Thu, 15 Apr 2021 22:28:23 GMT):
No. We have the new Indy DID method pretty much complete (combined hackmd document and the most recent meeting notes). I'll be updating the hackmd document this weekend in prep for an IIW session on this. In that I will try to summarize the list of things to be done in Indy
From there, we'll be formalizing the spec in the indy-did-method repo and putting in a HIPE and GitHub issues as we try to round up some devs to work on this.
esplinr (Thu, 15 Apr 2021 22:35:21 GMT):
Thanks. I'm really keen to see the HIPE so that I can figure out how best to help.
swcurran (Thu, 15 Apr 2021 22:42:53 GMT):
Not sure what you expect would be different, but I'll let you know when it is there.
esplinr (Thu, 15 Apr 2021 22:52:27 GMT):
I haven't been in the meetings, so I just want to confirm that my understanding matches the formal plan. Thank you.
kdenhartog (Mon, 19 Apr 2021 03:19:17 GMT):
I think that makes sense but one to double check on one thing.
For these two,
- check the NYM verification method is in the DIDDoc
- check for valid JSON and DIDDoc.
What happens if those checks fail?
kdenhartog (Mon, 19 Apr 2021 03:21:24 GMT):
For check the NYM verification method is in the DID Document we could default back to minimal did document or we could drop the usage. I'm not sure which is better though.
For checking for valid JSON and DID Document are we thinking we'll do this up front (like we considered with json-ld)
Also since I mentioned JSON-LD, did we decide to go the route of JSON only/allowing `@context` but not being concerned with what to do if that value is invalid?
swcurran (Mon, 19 Apr 2021 14:42:55 GMT):
The checks are made on write. If the checks fail, the transaction is rejected.
At this point, we have not had the interested parties at the meetings to discuss the JSON vs. JSON-LD discussion. My thought is that we can leave it to the NYM writer to decide, using the following process. The base template generates a DIDDoc without the `@context`, which is the only bit of JSON-LD in the template. If the `diddocContent` is present and has an `@context`, the DID Core context is added to the array. If not, the format is left as JSON. Would that be OK?
swcurran (Mon, 19 Apr 2021 14:43:48 GMT):
Regards the checks for a valid DIDDoc. My thought is to make that an "implementation detail" and have the developers that do the work propose the approach.
kdenhartog (Tue, 20 Apr 2021 17:11:23 GMT):
I think that's alright, but we should get @peacekeeper opinion on how this aligns with production conformance rules. I think it's heading in the right direction, but we may want to make some slight modifications.
kdenhartog (Tue, 20 Apr 2021 17:12:45 GMT):
For example what I'm thinking is it may make sense to say if and `@context` is included then the ledger will perform a check it's valid JSON-LD so that it can produce valid did documents. If not included it will be presumed the DID Document is JSON only.
kdenhartog (Tue, 20 Apr 2021 20:22:13 GMT):
regarding registration of a genesis txn file to the indy-did-networks repo is we should make sure there's authorised updaters when a person files a registration for a new network and only those people can provide updates to that network. This is to make explicit who is responsible for the network. Often time we implicitly know someone is associated and allow them to update things related to what they work, but it's probably best to make them explicit for this type of thing.
kdenhartog (Tue, 20 Apr 2021 20:22:13 GMT):
regarding registration of a genesis txn file to the indy-did-networks repo we should make sure there's authorised updaters when a person files a registration for a new network and only those people can provide updates to that network. This is to make explicit who is responsible for the network. Often time we implicitly know someone is associated with a project or network and allow them to update things related to what they work, but it's probably best to make them explicit for this type of thing even for the simplicity of knowing who to contact if something goes wrong. I'd think a github handle is good enough, but an optional email would be good as well.
kdenhartog (Tue, 20 Apr 2021 21:20:48 GMT):
Related to indy-did-networks we may want to allow a resolver to be published rather than a genesis txn file and then other resolvers can proxy out to a different resolver which connects to the actual nodes. This would be useful when the network is private but there's a publicly available resolver.
swcurran (Mon, 26 Apr 2021 17:51:26 GMT):
@danielhardman -- can you comment on the idea above about allowing the DID controller decide if the DIDDoc is JSON or JSON-LD? Would that satisfy your concerns about what to use?
danielhardman (Mon, 26 Apr 2021 17:55:03 GMT):
It depends on whether the ledger enforces what the DID controller says. If the ledger has to enforce it, then the ledger gets a dependency on JSON-LD, and most of my concerns remain. If the ledger lets a DID controller assert whether the doc is JSON-LD or not, but makes no attempt to understand what that distinction means, then yes, most of my concerns are resolved.
swcurran (Mon, 26 Apr 2021 18:07:35 GMT):
I think we could leave that to the implementation. In the spec. we would like to indicate that some verification of the DIDDoc does is done prior to writing the NYM to the ledger. That it be valid JSON is relatively easy. That it is a valid DIDDoc is harder. I think it best to work with the devs to iteratively decide what could/should be done, including differences (if any) when the DIDDoc is JSON or JSON-LD.
Is that reasonable, or should we be able to answer that now?
swcurran (Mon, 26 Apr 2021 18:14:36 GMT):
Another community question for those that can't make the meetings (e.g. @danielhardman @drummondreed ) -- I'd like to remove any references to KERI and DND/DNR to a "futures" section and that we not address it in this first implementation of the Indy DID Method. Any objections?
danielhardman (Mon, 26 Apr 2021 18:48:42 GMT):
The only thing we wanted to do with KERI was reserve a subset of the namespace for future work there (that is, a KERI DID that uses an Indy ledger as a witness lives at did:indy:keri...). As long as there's a statement somewhere that prevents people from making such future work impossible, I'm cheerful.
danielhardman (Mon, 26 Apr 2021 18:48:42 GMT):
The only thing we wanted to do with KERI was reserve a subset of the namespace for future work there (that is, a KERI DID that uses an Indy ledger as a witness lives at did: indy: keri...). As long as there's a statement somewhere that prevents people from making such future work impossible, I'm cheerful.
danielhardman (Mon, 26 Apr 2021 18:52:16 GMT):
>I think we could leave that to the implementation. In the spec. we would like to indicate that some verification of the DIDDoc does is done prior to writing the NYM to the ledger. That it be valid JSON is relatively easy. That it is a valid DIDDoc is harder. I think it best to work with the devs to iteratively decide what could/should be done, including differences (if any) when the DIDDoc is JSON or JSON-LD. Is that reasonable, or should we be able to answer that now?
As long as the spec doesn't require a conformant impl of did:indy to validate JSON-LD, and as long as anyone can install a did:indy impl without incurring a dependency on JSON-LD libraries that have questionable security characteristics, I am cheerful. But if implementers decide that the ledger should be validating JSON-LD, I will express my strong dissatisfaction with the direction of the impl. I don't believe ledgers should be in the JSON-LD business, but that they SHOULD allow code above the ledger level to use JSON-LD without needing to know any of the details.
andrew.whitehead (Mon, 26 Apr 2021 18:55:37 GMT):
I agree. If we require full JSON-LD validation then either there would have to be a whitelist of supported contexts, which is probably unworkable, or the nodes would be required to fetch contexts on demand, which is bad for security and performance.
swcurran (Mon, 26 Apr 2021 18:59:19 GMT):
@here -- I cannot make the meeting tomorrow morning. @paul.bastian @vinomaster @sergey.khoroshavin @peacekeeper -- heads up. I've doing some work on the hackmd document, but will not be able to attend the meeting.
AFAIK -- of framing the spec is pretty much complete -- now it is down to formalizing the document and getting a backlog of development work to be done. And getting that work done.
swcurran (Mon, 26 Apr 2021 21:18:55 GMT):
So you are saying, no JSON-LD verification of the resulting DIDDoc, and I'm assuming that really also means no actual DIDDoc verification at all.
>
That implies that the only content verification is that the basis of the document be a valid DIDDoc derived from the NYM values and that valid JSON be found in the `diddocContent` item. Other than that, anything goes, up to the controller, correct?
swcurran (Mon, 26 Apr 2021 21:20:49 GMT):
I had thought that Indy NYMs were self-certifying, but I have recently heard that is a convention in the indy-sdk, but not required by the Indy ledger. In the `did:indy` method, I had put in "self-certifying" and no one has objected. Are we going to add self-certifying to the "create" operation for a NYM?
andrew.whitehead (Mon, 26 Apr 2021 21:44:12 GMT):
Hmm, I suppose it's only self-certifying until you rotate the verkey. Even in indy-sdk you can override the DID at creation time
swcurran (Mon, 26 Apr 2021 21:59:52 GMT):
It still self-certifying, because there is a chain of events back to creation.
swcurran (Mon, 26 Apr 2021 22:58:04 GMT):
This would mean if you did rotate the key in the indy-sdk before creating it on the ledger, it would be rejected because there is no connection between the key and identifier.
paul.bastian (Tue, 27 Apr 2021 15:59:33 GMT):
exactly my thoughts, you can trace back the self-certifyingness to the initial NYM transaction
paul.bastian (Tue, 27 Apr 2021 16:00:17 GMT):
it general it feels way more comfortable and prevents DIDs with human-readable strings to a good amount, that beneficial from GDPR and phishing standpoint
paul.bastian (Tue, 27 Apr 2021 16:01:02 GMT):
sry I couldn't make it either, I'm joining back in next week
danielhardman (Fri, 30 Apr 2021 17:00:42 GMT):
Strong +1 to requiring self-certifying. Doesn't prevent key rotation as long as there's an audit trail of evolution that maps back to a DID value derived from initial key.
swcurran (Fri, 30 Apr 2021 19:52:04 GMT):
Mime-type experts. When an Indy object is returned, should there be a mime-type associated with it? For example: would this be appropriate?
`application/json+indy+nym`? Or perhaps just `application/json`?
swcurran (Fri, 30 Apr 2021 19:52:04 GMT):
Mime-type experts. When an Indy object is returned, should there be a mime-type associated with it? For example: would this be appropriate? `application/json+indy+nym`? Or perhaps just `application/json`?
swcurran (Mon, 03 May 2021 18:44:58 GMT):
Next Meeting:
did:indy Method Spec -- Next meeting: scheduled for Tuesday May 4 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-05-04
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
- Summary and review of close-to-done Spec.
- Serialization formats - use JSON?
- To Do's going forward
dcspinho (Wed, 05 May 2021 23:35:06 GMT):
Has joined the channel.
swcurran (Sun, 09 May 2021 20:50:45 GMT):
I've done another pass of the `did:indy` hackmd document --
Also set up an agenda for another meeting this week to cover this questions and help wanted:
- Help Wanted: Wording of the "namespace" section, with primary and secondary components.
- Question: Current verkey change does NOT require signature of a new verkey. Should it?
- Question: Will it be easy/possible to do "versionTime" query for a DID?
- Question: Should a "versionId" query require the seqNo be for a NYM, or should it search back on ledger for value of NYM at that time – same as "versionTime"?
- Question: The new Claim Def DID URL does NOT include the ID of the Schema. That means that you can't have the same named Claim Def using two different Schema. Is that a problem?
- Nice to have: Analysis of Sovrin MainNet and Sovrin StagingNet to see how many instances of that exist.
- Question: DID URL Handling for Rev Reg Entries
- Does not use a straight, request object/return object as with other objects. Instead, may use the RevRegDelta Txn.
- Good idea?
- Help Wanted: Security Considerations sections
- Help Wanted: Privacy Considerations sections
Hope folks can make it on Tuesday -- 7AM PT.
swcurran (Sun, 09 May 2021 20:50:45 GMT):
I've done another pass of the `did:indy` hackmd document --
Also set up an agenda for another meeting this week to cover this questions and help wanted:
```
- Help Wanted: Wording of the "namespace" section, with primary and secondary components.
- Question: Current verkey change does NOT require signature of a new verkey. Should it?
- Question: Will it be easy/possible to do "versionTime" query for a DID?
- Question: Should a "versionId" query require the seqNo be for a NYM, or should it search back on ledger for value of NYM at that time – same as "versionTime"?
- Question: The new Claim Def DID URL does NOT include the ID of the Schema. That means that you can't have the same named Claim Def using two different Schema. Is that a problem?
- Nice to have: Analysis of Sovrin MainNet and Sovrin StagingNet to see how many instances of that exist.
- Question: DID URL Handling for Rev Reg Entries
- Does not use a straight, request object/return object as with other objects. Instead, may use the RevRegDelta Txn.
- Good idea?
- Help Wanted: Security Considerations sections
- Help Wanted: Privacy Considerations sections
```
Hope folks can make it on Tuesday -- 7AM PT.
swcurran (Sun, 09 May 2021 20:50:45 GMT):
I've done another pass of the `did:indy` hackmd document -- https://hackmd.io/2IKUPROnRXW57Lmal_SGaQ?both
Also set up an agenda for another meeting this week to cover this questions and help wanted:
```
- Help Wanted: Wording of the "namespace" section, with primary and secondary components.
- Question: Current verkey change does NOT require signature of a new verkey. Should it?
- Question: Will it be easy/possible to do "versionTime" query for a DID?
- Question: Should a "versionId" query require the seqNo be for a NYM, or should it search back on ledger for value of NYM at that time – same as "versionTime"?
- Question: The new Claim Def DID URL does NOT include the ID of the Schema. That means that you can't have the same named Claim Def using two different Schema. Is that a problem?
- Nice to have: Analysis of Sovrin MainNet and Sovrin StagingNet to see how many instances of that exist.
- Question: DID URL Handling for Rev Reg Entries
- Does not use a straight, request object/return object as with other objects. Instead, may use the RevRegDelta Txn.
- Good idea?
- Help Wanted: Security Considerations sections
- Help Wanted: Privacy Considerations sections
```
Hope folks can make it on Tuesday -- 7AM PT.
kdenhartog (Mon, 10 May 2021 02:44:33 GMT):
Do we need the initial google document that we used to start the did:indy discussion? We're migrating from google docs to o365 and I don't want anyone to lose access to it if they still reference it. If you do still need access to it, ping me and I can share a link to the new verision.
swcurran (Tue, 11 May 2021 03:04:20 GMT):
We're using a hackmd.io document. We're not looking at any google doc, so we're fine.
swcurran (Tue, 11 May 2021 03:05:35 GMT):
Next Meeting:
did:indy Method Spec -- Next meeting: scheduled for Tuesday May 4 at 7AM Pacific / 15:00 UTC / 16:00 CET.
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-05-11
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
Information about this meeting series is here: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification
On the agenda this week:
* Questions from another pass through the spec.
* Help wanted on the Security and Privacy consideration sections.
swcurran (Tue, 11 May 2021 23:47:56 GMT):
Question for the from the DID Indy Method call today. Current plan is to allow a Claim Def on one ledger to reference a Schema on another ledger. That leaves open the possibility that credentials become unusable because the ledger on which the Schema resides "disappears". We came up with some elaborate ways to handle this, but of course the easiest thing to do is as little as possible. Here are the options that we see:
1. Do not support the referencing of a schema on another ledger in a claim def, so the potential problem can not happen.
2. Support the referencing of a schema on another ledger in a claim def, but warn implementers of the risk of doing that.
3. Provide some sort of safety net by (for example) putting into the Claim Def a copy of the schema transaction and state proof from the other ledger, so that the client always has the schema if needed.
Obviously, the last approach requires extra work.
Opinions welcome on what to do for this first instance of the DID Method specification.
@danielhardman @vinomaster @paul.bastian @ArturPhilipp @sergey.khoroshavin @drummondreed @brentzundel
swcurran (Tue, 11 May 2021 23:58:21 GMT):
Second question from today. We want self-certifying DIDs, so will be adding the enforcement of the algorithm that the Indy SDK uses to derive the DID from the verkey by the ledger in creating a DID.
Question: When rotating the key for an existing DID, should the ledger require that the transaction be signed by the "before" key AND the "after" key, or just the "before" key?
Is that necessary/helpful from a security perspective?
swcurran (Tue, 11 May 2021 23:58:21 GMT):
Second question from today. We want self-certifying DIDs, so will be adding the enforcement by the ledger of the algorithm that the Indy SDK uses to derive the DID from the verkey in writing a new DID.
Question: When rotating the key for an existing DID, should the ledger require that the transaction be signed by the "before" key AND the "after" key, or just the "before" key?
Is that necessary/helpful from a security perspective?
swcurran (Tue, 11 May 2021 23:58:21 GMT):
Second question from today. We want self-certifying DIDs, so will be adding the enforcement by the ledger of the algorithm that the Indy SDK uses to derive the DID from the verkey in writing a new DID.
Question: When rotating the key for an existing DID, should the ledger require that the transaction be signed by the "before" key AND the "after" key, or just the "before" key?
Is that necessary/helpful from a security perspective? Currently, it is just the "before" key.
danielhardman (Fri, 14 May 2021 16:35:00 GMT):
Signing with the "after" key requires that the private key be "taken out" of its secure location and actually used. If it's stored in a secure element, maybe that's no big deal -- but if it's stored in software, this constitutes a change of location that may make it easier to observe in a side channel attack or similar. Thus, I think there's a case to be made for the assertion that NOT signing with the after key is actually more secure. However, I am not asserting this case strongly; I'm just parroting some theory that I heard Sam Smith talk about in his KERI design. Maybe we should ask Sam to articulate it; I'm sure he'd do better than I just did.
My own opinion is that it's probably secure enough with just one signature, but that if we do another, I won't protest.
andrew.whitehead (Fri, 14 May 2021 16:39:57 GMT):
Is the question whether it's still a 'certified' DID?
andrew.whitehead (Fri, 14 May 2021 16:39:57 GMT):
Is the question whether it's still a 'certified' DID? I think we'd have to look at what exactly is proven in the initial transaction and in the key rotation
andrew.whitehead (Fri, 14 May 2021 16:42:15 GMT):
For example the initial transaction is written by a steward, who doesn't submit proof that the DID owner possesses the verkey, but that party won't be able to use the DID for anything useful (presumably) if they don't. Although if the initial transaction contained a DID document with alternative key agreement keys, then they could still send authenticated messages
andrew.whitehead (Fri, 14 May 2021 16:42:15 GMT):
For example the initial transaction is written by a steward, who doesn't submit proof that the DID owner possesses the signing key, but that party won't be able to use the DID for anything useful (presumably) if they don't. Although if the initial transaction contained a DID document with alternative key agreement keys, then they could still send authenticated messages
andrew.whitehead (Fri, 14 May 2021 16:44:26 GMT):
I also wonder if there's a chance of impersonation given that there are plans to resolve things across multiple ledgers
danielhardman (Fri, 14 May 2021 16:52:24 GMT):
>Is the question whether it's still a 'certified' DID?
I don't think so. A self-certifying identifier means that it has an unbroken chain of custody, and we'd have that even if there's no signature from the 'after' key. It's the 'before' key that matters.
esplinr (Fri, 14 May 2021 22:28:04 GMT):
Options 1 and 2 both seem adequate for our purposes. If we later find we need option 3, we can address it in a future enchancement.
swcurran (Fri, 14 May 2021 23:01:56 GMT):
Do you have a preference for 1 or 2?
swcurran (Mon, 17 May 2021 15:02:19 GMT):
Hey folks -- I'm not able to make the meeting tomorrow, so I'm cancelling the meeting. If anyone wants to host, please let me know and I'll give you the host key.
Great if you could spend the time on updating the Hack MD document -- especially the Security and Privacy Considerations -- nudge, nudge @paul.bastian :-)
https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw
kukgini (Tue, 18 May 2021 08:42:46 GMT):
Has left the channel.
nserrao (Tue, 18 May 2021 17:54:50 GMT):
Has joined the channel.
danielhardman (Fri, 21 May 2021 16:01:41 GMT):
I prefer option 2. Let programmers do stuff rather than get in their way. However, this is only possible because I'm imagining the cross-ledger reference to be a DID. If the reference is some other type of URI, then I strongly prefer option 1, as I worry it wold introduce some complexities we don't want to deal with right now.
swcurran (Fri, 21 May 2021 16:05:38 GMT):
Daniel -- the only cross referencing that is possible in the Indy model is the Schema from Claim Def.
A DID is on the ledger it is on. No contraversy there.
Any other Indy ledger object MUST be on the ledger of the DID that creates it, as the Indy writing rules require that -- permissions to create objects.
By definition that means that the CLAIM_DEF, REV_REG objects MUST be on the ledger of the Issuer.
The only other case is can a CLAIM_DEF reference the SCHEMA on a different ledger. So that's the only case we are worried about.
swcurran (Fri, 21 May 2021 16:05:38 GMT):
Daniel -- the only cross referencing that is possible in the Indy model is the Schema from Claim Def.
A DID is on the ledger it is on. No contraversy there.
Any other Indy ledger object MUST be on the ledger of the DID that creates it, as the Indy writing rules require that -- permissions to create objects.
By definition that means that the CLAIM_DEF, REV_REG objects MUST be on the ledger of the Issuer.
The only other case is can a CLAIM_DEF reference the SCHEMA on a different ledger? So that's the only case we are worried about.
swcurran (Fri, 21 May 2021 16:07:06 GMT):
We'd like to support that, but we could preclude it to avoid the problem of credentials becoming useless because the ledger on which the schema resides goes away.
swcurran (Fri, 21 May 2021 16:07:32 GMT):
Of course, if the ledger on which the Issuer DID and CLAIM_DEF go away, the credential is useless as well.
swcurran (Fri, 21 May 2021 16:07:32 GMT):
Of course, if the ledger on which the Issuer DID and CLAIM_DEF go away, the credential is non-verifiable as well.
danielhardman (Fri, 21 May 2021 16:10:10 GMT):
Thanks for the background. I think option 2 is fine. The warning should contemplate not just a reference from something like Sovrin to something like Bedrock, but also references from mainnets to testnets (noting that resetting state on testnets is a real possibility). So it's not just the ledger vanishing that matters, but also the ledger being reset.
jkrstic (Sat, 22 May 2021 18:10:45 GMT):
Has joined the channel.
esplinr (Tue, 25 May 2021 02:04:22 GMT):
I also agree with 2.
swcurran (Tue, 25 May 2021 02:06:17 GMT):
FYI - the meeting tomorrow is cancelled -- no work has been done. If you were planning on attending, great if you could move the spec forward -- review it, respond to the questions ^^ in this channel. Thanks!
ArturPhilipp (Tue, 25 May 2021 10:08:35 GMT):
Hi @swcurran , I added some rudimentary glossary for indy specific terms like (NYM (vs DID), SCHEMA, CLAIM_DEF) and so on. The Idea was to give a basic understanding to the reader of the spec at the very beginning but I struggle with the level of details we should provide. I would attend the meeting. If someone would like to review the new parts together with me, feel free. :)
swcurran (Mon, 31 May 2021 21:17:04 GMT):
Hi Folks, I've not made any progress on did:indy this past week, and will not be able to make the meeting tomorrow. I will be up early for a meeting so will see messages on this if anyone wants to hold the meeting and grab the host key.
We're pushing to have wallets (holders) and verifier agents to implement a "check multiple ledgers" as a stop gap for network of networks. Here is the ticket that is currently being worked for ACA-Py -- https://github.com/hyperledger/aries-cloudagent-python/issues/1189. While that means we're OK for dealing with objects on multiple ledgers, it does nothing for the DIDDoc support that is needed.
paul.bastian (Tue, 01 Jun 2021 13:33:08 GMT):
I was on holidays last week and couldn't do anything either, I'm up for cancelling as well
kdenhartog (Fri, 04 Jun 2021 01:59:04 GMT):
:thumbsup: I think I have ownership of that hackmd document as well. That will be unaffected. It's connected to my github account
swcurran (Mon, 07 Jun 2021 19:43:48 GMT):
Tomorrow's Indy DID Method Specification Meeting has been cancelled for Hyperledger Global Forum.
swcurran (Mon, 14 Jun 2021 23:27:15 GMT):
Hey folks -- I'll be there for the Indy DID Method call, if anyone else can make it. We can talk about where we are, and see if we can find a way to make progress on the spec and implementation. It's been awhile...
Current Spec: https://hackmd.io/@icZC4epNSnqBbYE0hJYseA/S1eUS2BQw
Calendar information for the event is here: https://lists.hyperledger.org/g/indy/viewevent?repeatid=32661&eventid=955634&calstart=2021-06-14
Zoom Info: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
paul.bastian (Tue, 15 Jun 2021 14:20:57 GMT):
I have a conflict today :/
swcurran (Tue, 15 Jun 2021 14:22:36 GMT):
No worries...I showed up late and the room was empty. Apologizes if anyone did show up...
swcurran (Mon, 21 Jun 2021 20:24:57 GMT):
Anyone interested in meeting tomorrow morning? I had an interesting discussion with the KERI folks and have a proposal for what a KERI did:indy would look like. I wouldn't mind discussing it.
swcurran (Mon, 21 Jun 2021 22:29:39 GMT):
FYI - I'm going to be chatting with at least Phil Feairheller about how to use Indy for resolving DID that are based on KERI identifiers. We've been chatting today and I wrote this up for those that are interested:
https://docs.google.com/document/d/1GYQtjxnPDtkJ-U0TWHACZ_QVnrCEDvQirZRiPcEzMjc/edit?usp=sharing
swcurran (Mon, 21 Jun 2021 22:29:39 GMT):
FYI - I'm going to be chatting with at least Phil Feairheller about how to use Indy for resolving DID that are based on KERI identifiers. We've been chatting today and I wrote this up on the topic for those that are interested:
https://docs.google.com/document/d/1GYQtjxnPDtkJ-U0TWHACZ_QVnrCEDvQirZRiPcEzMjc/edit?usp=sharing
c2bo (Tue, 22 Jun 2021 12:09:12 GMT):
Has joined the channel.
MichaelSchaefer (Tue, 22 Jun 2021 12:09:14 GMT):
Has joined the channel.
swcurran (Mon, 28 Jun 2021 17:16:41 GMT):
FYI -- no meeting tomorrow unless I hear of some topics to cover.
I've updated the KERI Identifiers document (link above ^^^) to cover the use of an Indy instance as a set of KERI Witnesses. The idea is that a "quick'n'dirty" implementation can be done with just ATTRIB objects, and that a better implementation can be done by modifying the definition of a NYM object.
Also propose that we added to Indy (generally, not just for KERI), the idea of a pre-rotation key, so that a DID can be recovered even if the current private key for the DID is compromised.
gaberasturi (Fri, 02 Jul 2021 11:20:36 GMT):
Has joined the channel.
swcurran (Tue, 06 Jul 2021 06:40:34 GMT):
No updates that I'm aware of this week, so cancelling the meeting, again.
domwoe (Tue, 06 Jul 2021 09:10:16 GMT):
Can we help to move this forward?
swcurran (Tue, 06 Jul 2021 10:01:31 GMT):
Definitely! We got very close, but ran out of steam (and participation). We'll be talking a bit about this on the Indy Contributors call if you can make it today -- 5PM Central Europe Time.
swcurran (Mon, 19 Jul 2021 18:05:51 GMT):
I'm flying tomorrow and so will not be on this call -- assume it is cancelled. We really need to get going on this...
l-wegner (Wed, 04 Aug 2021 15:28:55 GMT):
Has joined the channel.
etschelp (Mon, 09 Aug 2021 07:29:37 GMT):
Has joined the channel.
genaris (Thu, 02 Sep 2021 00:55:37 GMT):
Has joined the channel.
sunchiye (Fri, 03 Sep 2021 02:21:38 GMT):
Has joined the channel.
timbl (Tue, 07 Sep 2021 13:36:23 GMT):
Has joined the channel.
swcurran (Fri, 10 Sep 2021 00:15:28 GMT):
Hey Folks — the DID Indy spec. has been moved from it’s HackMD home into a Hyperledger repo — https://github.com/hyperledger/indy-did-method and is now being published here - https://hyperledger.github.io/indy-did-method/
We’re using SpecUp for managing the spec. and an updated ReadMe on how to contribute is coming Real Soon Now. It appears we have some interest in getting going on implementing the spec.
swcurran (Fri, 24 Sep 2021 17:39:34 GMT):
Hey folks --- the Indy Contributors call is - Tuesday Sept. 28 at 8AM Pacific, 5PM CET
Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-08-28+Indy+Contributors+Call
Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09
We'll be talking about:
- Status of indy-node CI/CD and the Ubuntu upgrade
- Indy DID Method – An overview of the spec, why it is important, and getting started on the work
We're seeing more interest in the Indy DID method, which will make it much easier to access multiple Indy networks from an Aries Agent, and enable support for things like BBS+ Verifiable Credentials. Join us to see what's happening with this new DID Method.
For a preview of the Indy DID Method, check out: https://hyperledger.github.io/indy-did-method/
swcurran (Wed, 22 Dec 2021 19:13:37 GMT):
BC Gov has posted a funded "Code With Us" Challenge for individuals/teams interested in updating Hyperledger Indy to support the new `did:indy` DID Method, specified [here](https://hyperledger.github.io/indy-did-method/). The opportunity and response guidelines are [posted here](https://digital.gov.bc.ca/marketplace/opportunities/code-with-us/e3dd1605-cc1d-4c30-a9ee-245940bccd0d). The total funding for the challenge is $70,000CDN and is divided into 4 phases. The first 3 phases require the use of Python working on the [Indy Node](https://github.com/hyperledger/indy-node) and [Indy Plenum](https://github.com/hyperledger/indy-plenum) repos, while the 4th phase requires Rust development in the [Indy VDR](https://github.com/hyperledger/indy-vdr) repo. Those responding may choose to apply for only the Python work, only the Rust work or both.
Questions can be asked here or on the website hosting the opportunity.
Applications for the challenge will be accepted up to January 10, 2022. and the work is expected to begin shortly after that date, with completion expected by March 31, 2022.
paul.bastian (Mon, 10 Jan 2022 17:49:56 GMT):
@swcurran I wrote the section on security consideration: https://github.com/hyperledger/indy-did-method/pull/28 .I Hope thats enough :P
swcurran (Mon, 10 Jan 2022 18:09:13 GMT):
Awesome stuff -- thanks. I'll take a look hopefully before end of day. Thanks, Paul.
paul.bastian (Wed, 19 Jan 2022 16:05:03 GMT):
@swcurran Does it make sense to reestablish the call at some point?
paul.bastian (Wed, 19 Jan 2022 16:07:20 GMT):
I have build a did:indy resolver mvp that takes NYM and contructs the minimal did document: https://github.com/IDunion/indy-did-resolver
paul.bastian (Wed, 19 Jan 2022 16:18:06 GMT):
Also the did:indy method is close to make it to W3C DID Registry
paul.bastian (Wed, 19 Jan 2022 16:18:09 GMT):
https://github.com/w3c/did-spec-registries/pull/393
kdenhartog (Fri, 21 Jan 2022 22:10:39 GMT):
I just read through the indy method yesterday and I'll say you all who helped to put this together into a full method document did a great job at it. Thanks for taking the time to bring that all the way to completion because it turned out a lot better than man of the other ones I'm seeing these days.
kdenhartog (Fri, 21 Jan 2022 22:10:39 GMT):
I just read through the indy method yesterday and I'll say you all who helped to put this together into a full method document did a great job at it. Thanks for taking the time to bring that all the way to completion because it turned out a lot better than many of the other ones I'm seeing these days.
swcurran (Fri, 21 Jan 2022 23:42:15 GMT):
Good stuff -- the folks at Bosch converted it into the spec. The did-indy-method WG did the thinking. I agree it's looking good.
swcurran (Fri, 21 Jan 2022 23:42:33 GMT):
@paul.bastian -- agree that we should restart the meetings.
CharHowland (Tue, 01 Feb 2022 17:00:56 GMT):
Has joined the channel.
Rizary (Sat, 05 Feb 2022 03:27:59 GMT):
Has joined the channel.
swcurran (Mon, 07 Feb 2022 20:34:36 GMT):
The indy:DID method meeting is ON for tomorrow / Tuesday Feb. 8, 2022 (despite the email message that I sent out accidentally...)
Start time is Tuesday at 7:30 Pacific / 16:30 CET.
Zoom Room is: https://zoom.us/j/99220079317?pwd=OHk0U05ITnBkSmZ0aXlIQzFDYWg3UT09
Meeting Link: https://wiki.hyperledger.org/display/indy/2022-02-08%3A+Indy+DID+Method+Specification+Call
Agenda for tomorrow is:
- Meeting Cadence – weekly for 30 or 60 minutes
- Open PRs and Issues
- Update from the implementation team - FYI @TelegramSam @dbluhm
- Interesting questions leftover from the last meeting we held, way, way back when...
All are welcome!
TelegramSam (Mon, 07 Feb 2022 20:34:36 GMT):
Has joined the channel.
rjones (Sat, 12 Feb 2022 21:59:57 GMT):
Has joined the channel.
rjones (Sat, 12 Feb 2022 21:59:57 GMT):
[Please move to Discord](https://discord.com/channels/905194001349627914/905205711850594336)
rjones (Sat, 12 Feb 2022 21:59:57 GMT):
[Please get an account on the Hyperledger discord](https://discord.gg), then [join Indy](https://discord.com/channels/905194001349627914/905205711850594336)
rjones (Sun, 13 Feb 2022 01:34:58 GMT):
Has left the channel.
rjones (Wed, 23 Mar 2022 17:25:39 GMT):
rjones (Wed, 23 Mar 2022 17:25:39 GMT):
rjones (Wed, 23 Mar 2022 17:25:39 GMT):