Meeting minutes
Agenda Review
Wip: Agenda review, quick 10 minutes on DID Core issues, then similar for DID Resolution, then last half of call on DID Rubric.
Wip: Any additions to the agenda?
manu: Two things 1) context URL for DID Core v1.1, and 2) what's happening in DID Methods.
Wip: Update on DID Methods?
DID Method Standardization
manu: The DIF DID methods Working Group is meeting regulary, yesterday there was discussion about parallelizing the W3C Charter drafting, and method proposals
manu: That group is discussing ways forward around different categories of methods, such as web-based, ephermeral, ledger-based, decentralized
manu: A W3C charter doesn't have to pick specific methods yet, it could also say it will standardize methods from certain sets
manu: The charter could pick some specific methods, and leave others open to incubation for a while longer
<Zakim> JoeAndrieu, you wanted to say I think the chartering should be specific to methods
manu: Question to Ivan if a Charter could be structured like that
Wip: Where can we continue this discussion if it doesn't happen in this call?
JoeAndrieu: I think it's weird to charter a group that could implement arbitrary DID Methods. I'd much prefer one WG per DID Method. I know there is a longer discussion here, but wanted to get that in the minutes.
JoeAndrieu: It seems to me that Charters should be about specific methods such as did:key, etc.
pchampin: Regarding putting work items as provisional depending on incubation, it's been done in Linked Storage WG (was Solid WG), this part is definitely feasible.
pchampin: As for specifying which DID Methods, I hear Joe's comment, but my understanding was something like: X, Y, and Z properties chosen among -- it's not a wildcard, the specification, the scope of the charter could be broader than specific DID Methods.
DIF DID Methods WG: decentralized-identity/
Wip: If the group thinks we could have a viable discussion in this group, I'm happy to schedule that later.
manu: I think we would be very specific, e.g. for web-based methods, we would pick one out of the proposals that currently exist, or a combination of those. So it wouldn't be a complete wildcard.
<JoeAndrieu> +1 for types of method instead of names (web based v did:web)
manu: I understand JoeAndrieu's opinion that the WG should be focused on one method, however, it's a long process to get WGs started, so we're trying to find a middle ground between "only one method per WG" and being completely open-ended.
manu: A future rechartering could add or modify more
<JoeAndrieu> That sounds better, although I'd still like independent WGs
manu: We don't want to overload the staff or chairs, or split the community too much
ivan: I'm not sure Manu refers to for VCWG charter?
manu: The conditional normative on the previous charter.
ivan: Oh, right, not open ended, we specified some conditional normative specifications. Ok, that can work.
ivan: For strategy discussion, apart from that, I don't see any reason why the group can't propose that text for chartering and PA will carry that chartering process in WG.
pchampin: That's done, then, I started it. :) w3c/
Wip: Maybe let's move on, we can schedule something in a future call, maybe conversation should happen in DIF call?
DID Core Issue Processing
manu: There are implementers that want to get the v1.1rc1 DID context resolving, can we help in some way?
Wip: Any other comments there, seems like we should do that?
manu: No new issues on did-core that need attention, same set of issues still that are open
DID Resolution Issue Processing
markus_sabadello: two issues that I'd like to point out.
w3c/did-resolution#121
markus_sabadello: This is a meta issue, summarize conclusions -- enhancements, links to seven other issues, for all of them, discussion around DID Resolution specification itself -- new parameters, resolution options, proposed enhancements, trying to summarize that here. That would take care of 7 open issues, specific enhancements, specific topics have to go somewhere, but an attempt to close discussion around some of these topics we've discussed in last
few meetings.
markus_sabadello: Please take a look, we can create PRs or move things to extensions.
Wip: I appreciate you putting this together, get issues closed; can we just close issue when all actions have been done?
<Wip> w3c/
Wip: Manu, you said these actions are fine, my memory of issue 40 is that you thought that should go in resolution.
<ivan> +1 to joe!
manu: I'm non-blocking on that... I have a preference, but not blocking preference. Fine to do whatever the group wants.
JoeAndrieu: We need to be specific about DID Core vs. DID Resolution (we need to not use those interchangeably) -- we're talking about DID Resolution.
w3c/did-resolution#118
markus_sabadello: for issue 40, I might have misstated the desire, will look into it.
markus_sabadello: This next one is around HTTP endpoint, OpenAPI definition, Ivan wondered if it should be normative or informative -- currently not in our repository, in DIF repository, but interesting question. Should OpenAPI be in our WG and should it be normative/informative.
manu: We have included an OpenAPI spec in the VC-API, but it's informative. There is an experimental Respec plugin that can render OpenAPI specs.
manu: The .oas files are informative. But in the Respec file, we "transclude" certain part of the OAS files, and that becomes normative in the specification.
manu: It's a hybrid, but it helps to avoid mistakes in the .oas files
manu: If there is ever a bug in the .oas files, the spec is normative.
https://
manu: In this example, the requests and responses come from the .oas files directly
manu: We could follow that same path here.
manu: Or we say the spec is normative and .oas is informative, but then the question is what happens if they are inconsistent
Wip: Do we need the OpenAPI spec at all?
Wip: we're just defining the resolve function, right?
markus_sabadello: Yes, the OAS for DID Resolution only has one endpoint, but there are quite some logic embedded in that related to content type and accept headers and returning just the DID Document, or DID Resolution result, all metadata stuff; we'd have to try it out.
manu: We want to make things easier for developers, having OAS files is useful.
<pchampin> +1 to make the developers life easier
ivan: Is it an option to have an OAS file that is normative -- is it stable/referenceable from W3C's point of view?
manu: The OAS spec is stable, so we can cite it.
ivan: I'm talking about the specific OAS files themselves, if they're in TR, can we just use those?
ivan: Is it an option at all? I don't see a problem keeping it out of the document, but in same repo, which is in /TR -- that's fine, it's ok.
Wip: ok, sounds good, let's move on -- figure out how to integrate.
DID Rubric
Wip: What are the things we need to be aware of in DID Rubric?
JoeAndrieu: Yes, people here are mostly aware of this work, will try to go through base understanding stuff quickly.
JoeAndrieu: We started rubric to be able to figure out what we meant by "decentralization" and provide ability to compare DID Methods. We have 36 criteria, broken into 7 different categories, all have examples, unfortunately most examples come from 6 methods.
JoeAndrieu: Tried to get more people to submit more stuff, but been slow going.
JoeAndrieu: For criteria, we have stuff like name, id, question/answer... question, possible responses, examples... it's a bit out of date.
JoeAndrieu: This is what we'd have at DIDevaluations.com -- have criteria, relevant criteria, assessments are single assessment.
JoeAndrieu: We found that we needed to -- often same question needed to be asked at three different layers -- spec, network, and registry.
JoeAndrieu: Governance decisions, who gets to decide spec, network governance, for example bitcoin is a totally different network architecture than DNS-based domains.
JoeAndrieu: Questions around governance, that's typically not in the spec, sometimes have to go over/under -- challenging, sometimes hard to understand questions if you don't have examples.
JoeAndrieu: When we got to specific examples, giving did:peer a B, but did:git gets an A -- better understand what question is and iterate -- hard to get contributions, don't know how to improve that, hard to maintain, but clear that collaborative evaluations improve criteria.
JoeAndrieu: Most criteria is young, would like to improve it. What's next? We need registry rules (if we become W3C Registry), I want to JSON-ify the rendering layer (right now, HTML, but we should move to HTML), add criteria from DID Traits and didevaluations.com.
JoeAndrieu: We went through, looked at did:v1, did:btcr -- but when we got to did:web, some questions didn't make sense. Integrity in did:web vs. consensus.
JoeAndrieu: We have DID Traits over at DIF -- those fit right in, going to propose resolution to add those. Good source of data, can we fold it into the Rubric?
JoeAndrieu: Wrt. registry rules, first pass at 5 registry rules -- scope and purpose, fields and contraints, change policy, change method, and who is custodian of registry?
JoeAndrieu: That is out of W3C Registry Process.
JoeAndrieu: Scope and purpose: to maintain a curated set of criterial useful for evaluating the apropriateness of any DID method for any use case.
JoeAndrieu: JSONify things, fulls chema, working data model, main thing missing is controller and authentication, same oversight in DID Method registry... add a criteria, need to figure out who controls that, getting updates, etc. Change policy, anyone should be able to propose new critera, unique aspect, two example assessments.
JoeAndrieu: Github style change policy, raise issues, raise comments for friendly amendment, you can fork criteria. Editor's would evaluate, iterate from proposed criteria, word change that improves, but if criteria exists that's not aligned, fine -- fork/tweak, slightly different nuance... as long as Editor thinks nuance is valid, feels like it's an effective set. Modest set of useful criteria, not exhaustive.
JoeAndrieu: Don't want thousands of criteria, can't even handle 100 and have it be useful with current framing. Change method, send PR to repo, correct JSON files, validate that, public discussion on PR, acceptance/rejection by editor's.
JoeAndrieu: Custodian, DID WG assigns editors, if it is not chartered, fall back to CCG, then W3C team... initial editors Joe Andrieu and Ryan Grant.
JoeAndrieu: DID Traits, woul dlike to include, straightforwrad mapping... here are some resolutions we could try here today.
JoeAndrieu: With DID Methods, don't know, but here, I'd like to make a commitment to it. Another resolution, appoint two Editors, give Editor authority for registry rules -- those rules are what AC Reviews and votes on, registry rules feel like charter for registry. Ivan or PA, speak to how that works, please put yourself on queue.
JoeAndrieu: Let's make HTML page JSON-driven, want to make sure that's right thing to do... two imports, let's get those in.
Wip: What do people think?
manu: I think the name "Traits" might resonate more with developers than "Rubric", but that's just a minor comment
JoeAndrieu: I think changing the name is fair game, I like the name because I suggested it :) -- but that's just me... DID Traits might run into confusion at DIF.
manu: Yes, good point wrt. confusion.
markus_sabadello: Yes, good to see suggestion on how this could relate, how this could be imported, a lot of people are asking about the difference. My answer is usually the Rubric has been about decentralization, but covered other aspects, and DID Traits is more about concrete technical functionality, but it is also expanding/overlap -- good idea to have some sort of plan on how to align those.
markus_sabadello: One big difference in DID Traits is, every trait only has boolean value, whereas that's not true for Rubric.
markus_sabadello: It's great to think about this and have some suggestion on how to align those.
Wip: Concerned about time, let's try to run proposal to unstick... first two proposals?
<JoeAndrieu> PROPOSAL: Transform the DID Method Rubric to a W3C registry
<Wip> +1
<JennieM> +1
<TallTed> +1
<JoeAndrieu> +1
<markus_sabadello> +1
<manu> +1
<pchampin> +1
<ivan> +1
<bigbluehat> +1
manu: +1
<dmitriz> +1
RESOLUTION: Transform the DID Method Rubric to a W3C registry
<JoeAndrieu> PROPOSAL: Appoint Joe Andrieu and Ryan Grant initial editors of proposed Registry Rules and the new registry itself
<TallTed> +1
manu: +1
<pchampin> +1
<JennieM> +1
<JoeAndrieu> +1
<Wip> +1
<ivan> +1
<markus_sabadello> +1
<dmitriz> +1
RESOLUTION: Appoint Joe Andrieu and Ryan Grant initial editors of proposed Registry Rules and the new registry itself
<Wip> w3c/
Wip: Joe, we've passed two of these, do we need to do anything to that repo to turn it into a registry, is that where the rules are defined?
JoeAndrieu: For continuity reasons, we probably want the new registry to be in that repo -- looking to Ivan/PA to see if that makes sense. Should we set it up as a new repo?
ivan: I don't see any reason to change the repo.
pchampin: We can update repo to be a registry, no reason to change repos.
JoeAndrieu: That sounds good, I'll work on a branch and put rules in there, restructure it -- need to put in more detail. Will work insitu on separate and merge branch when needed.
Wip: Separate page on rules for registry that we render or ...
<pchampin> yes, same document
JoeAndrieu: Rules would be in same page as registry -- same document.
Wip: Looking forward to seeing that move forward.
Wip: Next week, DID Rubric discussion!