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