14:46:23 <RRSAgent> RRSAgent has joined #did
14:46:27 <RRSAgent> logging to https://www.w3.org/2024/07/18-did-irc
14:46:38 <burn> rrsagent, draft minutes
14:46:39 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/18-did-minutes.html burn
14:46:42 <burn> rrsagent, make logs public
14:49:08 <burn> Meeting: Decentralized Identifier Working Group
14:49:11 <burn> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/0014.html
14:49:18 <burn> Chair: Dan Burnett
14:49:33 <tminard> tminard has joined #did
14:52:41 <burn> present+
14:57:31 <ivan> present+
14:58:31 <burn> burn has joined #did
14:59:12 <ivan> regrets+ pchampin
14:59:57 <ChristopherA> ChristopherA has joined #did
15:00:14 <ChristopherA> present+
15:00:54 <tminard> present+
15:01:08 <bigbluehat> bigbluehat has joined #did
15:01:42 <bigbluehat> present+
15:01:46 <bigbluehat> scribe+
15:01:48 <burn> Topic: Agenda Review, Introductions
15:02:06 <ChristopherA> Summertime!
15:02:28 <manu> present+
15:02:52 <KevinDean> KevinDean has joined #did
15:02:53 <Wip> Wip has joined #did
15:02:56 <Wip> present+
15:02:57 <KevinDean> present+
15:03:07 <JoeAndrieu> JoeAndrieu has joined #did
15:03:15 <ChristopherA> q+
15:03:17 <bigbluehat> burn: is there anyone here who has not introduced themselves in an earlier call?
15:03:23 <burn> ack ChristopherA
15:03:37 <bigbluehat> ChristopherA: technically, I haven't introduced myself for this revised group
15:03:43 <andres> andres has joined #did
15:03:49 <ivan> present+ andres
15:03:51 <danpape> danpape has joined #did
15:03:55 <bigbluehat> ... I'm founder and chairman of the ____ group
15:04:00 <ivan> present+ danpape
15:04:01 <bigbluehat> ... and co-authored many specs.
15:04:10 <JoeAndrieu> present+
15:04:11 <ivan> present+ TallTed
15:04:12 <bigbluehat> ... I currently run Blockchain Commons
15:04:20 <bigbluehat> ... focusing on "layer zero" of the stack
15:04:37 <bigbluehat> ... trying to get more higher reviewed code in Rust.
15:04:52 <manu> s/____ group/Rebooting the Web of Trust group/
15:05:12 <ivan> present+ dlehn
15:05:20 <bigbluehat> burn: I have a special announcement about the special topic call
15:05:33 <bigbluehat> ... is there anything else that needs adding to the agenda?
15:05:37 <ivan> present+ KevinDean
15:05:55 <burn> Topic: Special topic call: Time announcement
15:05:59 <andres> present+
15:06:01 <bigbluehat> ... even if you have something to propose, we'll likely put it on a future call to keep things focused
15:06:09 <bigbluehat> ... so, the special topic call time
15:06:24 <bigbluehat> ... we look for a time that can accommodate the most people possible.
15:06:34 <bigbluehat> ... especially editors for the docs being discussed
15:07:07 <bigbluehat> ... The special topic call will be Wednesdays: 8am ET
15:07:25 <bigbluehat> s/8am ET/7am PT
15:07:33 <ChristopherA> 0700 PDT until November
15:07:33 <bigbluehat> ... 10am ET
15:07:40 <smccown> smccown has joined #did
15:07:49 <smccown> present+
15:07:58 <bigbluehat> ... I'd like to ask that we keep that day and time reserved for these calls
15:08:04 <bigbluehat> ... we'll use them as needed
15:08:06 <burn> q?
15:08:09 <bigbluehat> ... any questions?
15:08:10 <TallTed> q+
15:08:16 <burn> ack TallTed
15:08:27 <bigbluehat> TallTed: please add these to the W3C Calendar
15:08:40 <bigbluehat> burn: can we schedule them, they will be
15:08:45 <JennieM> JennieM has joined #did
15:08:48 <bigbluehat> TallTed: could you put the pending ones in?
15:08:58 <bigbluehat> ... that way I'll keep it blocked out just in case
15:08:59 <ChristopherA> (For me, not only it is really early PDT, but also conflicts with IETF CBOR meeting)
15:09:13 <JennieM> present+
15:09:17 <bigbluehat> burn: sorry for the conflicts with other groups
15:09:22 <burn> Topic: DID Registries
15:09:33 <bigbluehat> burn: main topic is DID Registries
15:09:42 <burn> https://lists.w3.org/Archives/Public/public-did-wg/2024Jul/att-0016/2024_DID_Specification_Registries_v1.1_Roadmap.pdf
15:09:44 <ChristopherA> https://github.com/w3c/did-spec-registries/issues/565
15:09:57 <burn> https://github.com/w3c/did-spec-registries/
15:10:06 <bigbluehat> ... Manu will be giving the above presentation
15:10:16 <bigbluehat> ... and then we'll open up the floor to discussion
15:10:30 <bigbluehat> manu: this one should be shorter than last time
15:10:45 <bigbluehat> ... DID specification registries is something we're chartered to build
15:10:58 <bigbluehat> ... I'll go over what it is by way of reminder
15:11:04 <bigbluehat> ... then point to what we need to discuss
15:11:21 <bigbluehat> ... The DID Spec Registries are official registries for the DID ecosystem
15:11:51 <bigbluehat> ... including: the registration process, the list of DID methods, property names and values, service types, etc.
15:12:06 <bigbluehat> ... There are several formats that we support--which should be kept in mind
15:12:16 <bigbluehat> ... we also have metadata for DID URLs
15:12:20 <ChristopherA> q+ Where would items like support for SSH keys signatures be added? Isn't that another document? Are there "other" registries that DID spec uses?
15:12:23 <bigbluehat> ... as well as resolution
15:12:26 <ChristopherA> q+ to Where would items like support for SSH keys signatures be added? Isn't that another document? Are there "other" registries that DID spec uses?
15:12:35 <bigbluehat> ... They contain quite a bit of material
15:12:50 <bigbluehat> ... The registration process gets asked about often
15:12:58 <bigbluehat> ... it does exist and we do follow it
15:13:05 <ChristopherA> I can wait.
15:13:13 <bigbluehat> burn: let's keep going and hold questions until the end
15:13:31 <bigbluehat> manu: we have a registration process, we follow it. We could change it...it's a bit long in the tooth
15:13:40 <bigbluehat> ... we could modify, update, or remove some parts
15:13:45 <bigbluehat> ... there are 11 maintainers
15:13:58 <bigbluehat> ... we organized that group less than a year ago
15:14:15 <bun> bun has joined #did
15:14:16 <bigbluehat> ... our previous maintainers dropped out, I was the only one left, so we needed more editors
15:14:34 <bigbluehat> ... Thankfully, people stepped forward to participate
15:14:55 <bigbluehat> ... we asked for volunteers, we got some, we onboarded them
15:15:04 <bigbluehat> ... we had no objections to the volunteers
15:15:22 <bigbluehat> ... some are participants in the group, others are from the wider community who just care about DIDs.
15:15:38 <bigbluehat> ... I continue to be the one to do the final merge after reviews are done.
15:16:03 <bigbluehat> ... the reason we're behind is because I'm behind. The volunteers have been great, very communicative.
15:16:21 <bigbluehat> ... We're very lucky to have this many participants.
15:16:46 <bigbluehat> ... The 190+ DID methods can feel great to some and terrible to others
15:16:58 <bigbluehat> ... there are proposals for doing some cleanup
15:17:11 <bigbluehat> ... it's not a free for all--even if it can look like it from such a long list
15:17:18 <bigbluehat> ... they've all met the minimum criteria
15:17:31 <ivan> q+
15:17:44 <bigbluehat> manu: Let's look through the DID Spec Registries note
15:17:55 <bigbluehat> ... Labeling needs improving
15:18:06 <bigbluehat> ... Property names includes several defined terms
15:18:27 <bigbluehat> ... `linkedResource` is something other people added, so that's working for the community to extend
15:18:31 <ivan> q-
15:18:44 <bigbluehat> ... Verification Methods is being handled elsewhere, so that may come out
15:19:09 <bigbluehat> ... we have several properties related to Verification Method that we should also discuss
15:19:23 <bigbluehat> ... There's also a Service Properties section we should reconsider
15:19:46 <bigbluehat> ... There's another set of Verification Method types which also need reconsideration--some of it is ancient
15:19:58 <bigbluehat> ... and there are new values to add if Verification Methods stay in
15:20:22 <bigbluehat> ... Service Types is a growing list
15:20:43 <bigbluehat> ... Representation types will need discussion. Currently it's JSON, JSON-LD, and CBOR.
15:21:16 <bigbluehat> ... We also now have a DID Resolution spec, so we may want to refactor the DID Resolution Metadata contained in this registry spec.
15:21:26 <bigbluehat> s/registry spec./registry note.
15:21:54 <bigbluehat> ... DID Document Metadata comes back from the resolver, or it's something the resolver can report back to the user.
15:22:18 <bigbluehat> ... There are also parameters such as `hl` (hashlink), `service`, `relativeRef`, etc.
15:22:29 <bigbluehat> ... and DID Methods
15:23:01 <bigbluehat> ... That list references the Registry and Contact info...however some of these are so old we don't have contact information for them
15:23:16 <bigbluehat> ... Despite the size of the list, very few have had registration time issues.
15:23:45 <bigbluehat> manu: we can continue to garden this group note
15:23:54 <bigbluehat> ... we could also consider making it a W3C specification
15:24:12 <bigbluehat> ... and do we want to align things more closely with other groups, such as the VCWG?
15:24:21 <bigbluehat> ... and do we add/remove categories
15:24:38 <bigbluehat> ... there's also interest in raising the bar a bit for DID methods
15:24:58 <bigbluehat> ... the registration process generally works, but we can discuss if we want to add/remove requirements
15:25:07 <bigbluehat> ... anyone's welcome to file issues
15:25:26 <ivan> regrets+ Kim
15:25:28 <bigbluehat> ... there are currently 40 open issues...some of which are very old
15:25:45 <bigbluehat> ... processing these would be a good place to start now that we have a WG to do that work
15:25:55 <bigbluehat> ... we also have pending registrations
15:26:16 <bigbluehat> ... some of them are nearly a year old and need to be merged
15:26:19 <bigbluehat> ... that's the summary
15:26:58 <bigbluehat> burn: admin content: bigbluehat is scribing today. Someday, it will be your turn.
15:27:04 <bigbluehat> ... don't panic. it's not hard.
15:27:13 <bigbluehat> ... watch what the scribe does
15:27:19 <bigbluehat> ... capture the essence of the conversation
15:27:37 <bigbluehat> ... it's very important and I personally have referenced minutes from over 3 years ago
15:27:48 <bigbluehat> ... it's very valuable to return to these logs
15:28:06 <bigbluehat> burn: DID spec registries is currently pretty much an open discussion
15:28:17 <bigbluehat> ... the chairs are keen to understand what folks want to focus on
15:28:25 <burn> ack ChristopherA
15:28:25 <Zakim> ChristopherA, you wanted to Where would items like support for SSH keys signatures be added? Isn't that another document? Are there "other" registries that DID spec uses?
15:28:29 <bigbluehat> ... especially as we get close to TPAC in September
15:28:40 <bigbluehat> ChristopherA: there's basically 3 maybe 4 things
15:28:53 <bigbluehat> ... I'd like to be able to list SSH keys--which is an IETF standard
15:29:00 <bigbluehat> ... it's not always clear how to add those
15:29:12 <bigbluehat> ... same is probably also true for some existing optional items
15:29:38 <bigbluehat> ... I'm also concerned that if this gets tangled with the VC Controller Document, there might be some interesting challenges
15:29:50 <bigbluehat> ... the big politically hard one is the DID list itself
15:30:28 <bigbluehat> ... my suggestion is put a column to state status, put everyone in "provisional", and give people time to validate that they're still around, interested, and able
15:30:28 <manu> q+ to note where SSH keys could go, speak to "Where does Controller Document go?", support ChristopherA's proposal for T
15:30:54 <burn> ack manu
15:30:54 <Zakim> manu, you wanted to note where SSH keys could go, speak to "Where does Controller Document go?", support ChristopherA's proposal for T
15:30:55 <manu> q+ to timeouts.
15:30:57 <bigbluehat> ... there is also a JSON-LD context out there. I don't plan to use that, but other people need it, so do we maintain that? what else is out there like that which we also need to maintain?
15:31:00 <manu> q-
15:31:10 <bigbluehat> manu: couple responses
15:31:27 <bigbluehat> ... SSH keys could go in key types possibly
15:31:43 <bigbluehat> ChristopherA: so, that list isn't up-to-date. What's the status?
15:32:02 <bigbluehat> manu: I agree. It comes down to who's maintaining that content--it's as up-to-date as they keep it
15:32:10 <JoeAndrieu> q+ to talk about process and uniqueness of DID Method names
15:32:13 <bigbluehat> ... the SSH keys could have a place in that section though
15:32:40 <bigbluehat> ... the Controller Document could be put into the purview of this group. Chartering challenges, though, put it into the VCWG
15:32:50 <bigbluehat> ... but I think moving it now would cause a lot of churn
15:32:54 <bigbluehat> ... with not much reward
15:33:15 <bigbluehat> ... maybe eventually, but given the heavy overlap, I think it can stay in VCWG until a later rechartering date
15:33:20 <bigbluehat> ... concerning timeouts
15:34:00 <bigbluehat> ... We could put in a registration date and submitters could need to keep bumping their registration or robots would remove expired ones
15:34:07 <bigbluehat> ... creating a sort of natural timeout
15:34:23 <burn> ack JoeAndrieu
15:34:23 <Zakim> JoeAndrieu, you wanted to talk about process and uniqueness of DID Method names
15:34:35 <bigbluehat> JoeAndrieu: there are two big rocks we need to request
15:34:44 <bigbluehat> ... abandonment and squatting
15:34:53 <bigbluehat> ... we also talked about test suites
15:35:07 <bigbluehat> ... and a complete proposal for some of these ideas from manu
15:35:20 <bigbluehat> ... the real gorilla, though, is name ownership
15:35:38 <bigbluehat> ... the DID spec doesn't actually require that the name exist singularly in the registry
15:35:45 <manu> q+ ChristopherA
15:35:47 <ChristopherA> q+
15:35:48 <manu> q+ manu
15:35:49 <bigbluehat> ... and that's a tricky problem to solve now
15:35:56 <burn> ack ChristopherA
15:36:13 <bigbluehat> ChristopherA: so, there was a forth question about other documents such as the JSON-LD context
15:36:24 <bigbluehat> ... is that part of the registry? are there other docs like that?
15:36:26 <burn> ack manu
15:36:30 <bigbluehat> ... also what are our refactoring limitations
15:36:40 <bigbluehat> manu: the JSON-LD context is maintained by the WG
15:36:47 <bigbluehat> ... it is not part of the registry per se
15:36:58 <bigbluehat> ... however, there are contexts associated with each property
15:37:22 <bigbluehat> ... so, previously, we'd decided that registrants needed to provide vocabularies and contexts with their registration
15:37:31 <bigbluehat> ... that was part of keeping the goal of decentralization
15:37:55 <bigbluehat> ... In the past that took a great deal of discussion time, so I'd rather not reopen that can of worms
15:38:15 <bigbluehat> ... there was also a question in the Zoom chat about the controller document
15:38:59 <bigbluehat> ... The VCWG's controller document was asked for by a subset of participants who did not want to use DIDs, but did want to use the Controller Document approach but with other URLs.
15:39:17 <bigbluehat> ... The Controller Document spec could layer into the future DID spec changes
15:39:29 <bigbluehat> ... The question of what goes into the registry is a big rock indeed
15:39:37 <bigbluehat> ... and one we should try to address
15:40:02 <bigbluehat> ... There are people now passive aggressively suggesting that we have a registry is proof that it's not decentralized at all
15:40:26 <bigbluehat> ... there's a more real concern that these registries were not meant to inhibit innovation
15:40:40 <bigbluehat> ... which is why the naming conflicts are allowed...though discouraged
15:41:00 <burn> q+
15:41:01 <bigbluehat> ... At this point, there are many things in here worked on by others, and we include them here by design
15:41:07 <burn> ack burn
15:41:08 <bigbluehat> ... but that's concerning to some folks
15:41:21 <bigbluehat> burn: I haven't been able to follow things closely
15:41:35 <bigbluehat> ... but if we look at a W3C registry, there may be more than one regestries
15:41:42 <bigbluehat> ... this document includes several registries
15:41:46 <ChristopherA> q+ to point people to https://github.com/w3c/did-spec-registries/issues/565
15:41:46 <JoeAndrieu> +1 for splitting the current registry into multiple resources
15:41:48 <bigbluehat> s/regestries/registries
15:41:58 <burn> ack ChristopherA
15:41:58 <Zakim> ChristopherA, you wanted to point people to https://github.com/w3c/did-spec-registries/issues/565
15:42:13 <bigbluehat> ChristopherA: I wanted to point people to the spec registries issue
15:42:28 <bigbluehat> ... my response there is more about the DID method name portion
15:42:40 <bigbluehat> ... but I was really hoping there'd be more ideas on that topic
15:43:01 <bigbluehat> ... there are lots of these suggestions
15:43:17 <bigbluehat> ... whatever your particular "thing" is, it'd be helpful to learn more about them
15:43:25 <bigbluehat> qL
15:43:31 <burn> q+ bigbluehat
15:43:35 <bigbluehat> s/qL//
15:43:46 <bigbluehat> ... that issue is currently the best place to chat
15:43:47 <burn> ack bigbluehat
15:43:53 <manu> scribe+
15:44:13 <manu> bigbluehat: We should pull that issue apart into multiple topics, there's a growing list, cramming into that one issue might be difficult.
15:44:25 <manu> q+
15:44:32 <burn> ack manu
15:44:45 <bigbluehat> manu: +1 to bigbluehat's suggestion
15:45:16 <bigbluehat> ... we need to make a decision on if we're keeping Verification Methods in the DID Registry or moving it to the VC Spec Registry
15:45:32 <bigbluehat> ... it's arguable it should be in neither place...but in a Data Integrity Registry
15:45:39 <bigbluehat> ... that one sticks out like a sore thumb
15:45:44 <bigbluehat> ... DID resolution is another one
15:45:51 <bigbluehat> ... there are arguments for and against
15:45:59 <JoeAndrieu> q+ to talk to separation and W3C process
15:46:19 <bigbluehat> ... we might want a DID methods reg, DID resolutions, and potentially a Data Integrity registry
15:46:27 <bigbluehat> ... that should give clearer lines around this document
15:46:42 <ChristopherA> q+
15:46:43 <bigbluehat> ... concerning Joe's suggestion to rename it to a "directory"
15:47:23 <bigbluehat> ... I didn't originally think it was needed, but the ongoing sniping about the "centralization" that the word "registry" applies to some
15:47:31 <bigbluehat> ... using "directory" may clear the air
15:47:36 <burn> q+
15:47:51 <bigbluehat> ... it's useful to have this, but maybe there's a way to alleviate that concern
15:48:00 <bigbluehat> ... I do have concerns about multiple documents
15:48:07 <ChristopherA> +1 to a single GitHub repo
15:48:09 <bigbluehat> ... but we could make that work with a single repo, perhaps
15:48:15 <bigbluehat> +1 to single repo
15:48:37 <bigbluehat> ... I'm still on the fence about the W3C registry process. I think it should be one, but we need a way to signal this is not a police file
15:48:58 <ivan> q+
15:49:01 <bigbluehat> ... It's documentation to help implementers. We can say that in the doc and that should make it clearer.
15:49:02 <burn> ack JoeAndrieu
15:49:02 <Zakim> JoeAndrieu, you wanted to talk to separation and W3C process
15:49:18 <bigbluehat> JoeAndrieu: +1 to pretty much everything Manu said
15:49:20 <bigbluehat> ... I still like "directory"
15:49:32 <bigbluehat> ... but I do think we should use the W3C registry process
15:49:43 <bigbluehat> ... to be part of how that works and gets on its feet
15:49:53 <bigbluehat> ... I do think multiple registries would be helpful
15:50:02 <burn> ack ChristopherA
15:50:03 <manu> +1 to what JoeAndrieu said.
15:50:15 <burn> zakim, close the queue
15:50:15 <Zakim> ok, burn, the speaker queue is closed
15:50:28 <bigbluehat> ChristopherA: I've been calling these "provisional"
15:50:40 <bigbluehat> ... simply reserving the space
15:50:48 <bigbluehat> ... maybe call that one the directory
15:51:12 <bigbluehat> ... but then have a separate one that says "here is a registry of methods that pass some tests around the DID resolution spec"
15:51:23 <bigbluehat> ... we can say you can still work with whatever
15:51:51 <bigbluehat> ... but the onramp would be through the "provisional" spec (what we have now) and then into this test-based registry
15:52:01 <bigbluehat> ... then other groups could have their own registries
15:52:15 <bigbluehat> ... but to keep that entirely independent of the directory
15:52:16 <burn> ack burn
15:52:21 <manu> Note that we do have status info for each entry: https://github.com/w3c/did-spec-registries/blob/main/tooling/did-method-registry-entry.yml#L15-L21
15:52:34 <bigbluehat> burn: there are different kinds of registries
15:52:41 <bigbluehat> ... some are first come; first served
15:52:44 <manu> We don't have "provisional", but we do have "registered" (which means the same thing)... we also have "withdrawn" and "deprecated".
15:52:49 <bigbluehat> ... others require review
15:53:01 <burn> ack ivan
15:53:23 <bigbluehat> ivan: we need to understand what the W3C registry gives us
15:53:27 <burn> zakim, open the queue
15:53:27 <Zakim> ok, burn, the speaker queue is open
15:53:40 <bigbluehat> ... I can't say much about its value other than it comes with the W3C stamp on it
15:53:52 <bigbluehat> ... the registry policy has to be voted on by the AC
15:53:58 <bigbluehat> ... is this helpful or not?
15:54:04 <bigbluehat> ... we should discuss
15:54:14 <manu> q+
15:54:19 <burn> ack manu
15:54:20 <bigbluehat> ... but I don't take using the W3C process as a "given"
15:54:34 <bigbluehat> manu: a few things we may already have consensus around
15:54:41 <burn> zakim, close the queue
15:54:41 <Zakim> ok, burn, the speaker queue is closed
15:54:45 <bigbluehat> ... splitting the registry into multiple docs
15:55:00 <bigbluehat> ... we do need to discuss whether to use the W3C process
15:55:18 <bigbluehat> ... deciding that may help with other concerns like the word "provisional"
15:55:28 <bigbluehat> ... many are easy search and replace
15:55:36 <bigbluehat> ... we just need to confirm consensus
15:55:48 <bigbluehat> ... we can put timeouts on the registrations easily
15:56:10 <bigbluehat> ... and if we go with the W3C registration process, it'll just be more process--so we should discuss
15:56:23 <burn> Topic: Up Next: DID Resolution
15:56:24 <bigbluehat> burn: this is just the beginning
15:56:32 <bigbluehat> ... please feel free to file more issues
15:56:45 <bigbluehat> ... Markus is going to be presenting more background next week
15:57:00 <bigbluehat> ... This is the beginning, not the end. Please contribute.
15:57:00 <burn> zakim, open the queue
15:57:00 <Zakim> ok, burn, the speaker queue is open
15:57:09 <bigbluehat> ... any final questions?
15:57:29 <bigbluehat> burn: ok. Thank you manu for presenting and bigbluehat for scribing
15:57:29 <ivan> rrsagent, draft minutes
15:57:30 <RRSAgent> I have made the request to generate https://www.w3.org/2024/07/18-did-minutes.html ivan
15:57:48 <bigbluehat> ... look forward to speaking with you all again soon!
15:58:08 <bigbluehat> burn: my pleasure. :)
15:58:28 <ivan> zakim, end meting
15:58:28 <Zakim> I don't understand 'end meting', ivan
15:58:43 <ivan> zakim, stop meting
15:58:43 <Zakim> I don't understand 'stop meting', ivan
15:58:51 <ivan> rrsagent, bye
15:58:51 <RRSAgent> I see no action items