Meeting minutes
<KevinDean> https://
Agenda Review, Introductions
markus_sabadello: First topic is agenda review and introductions. we start with issues on core, then resolutions. Any updates or requests for agenda items?
manu: maybe a mention of did methods working group charter starting to be worked on.
drummond: Thanks markus for so late a call!
markus_sabadello: I'm chairing today as the real chairs couldn't make it. I'm editor of the resolution spec.
DID Methods WG Update
<denkeni> Is it the related information: w3c/
manu: There is a new did methods working (which this group shouldn't be talking too deeply on) There is a work at DIF for did methods, some of which may be moved to the W3C, which requires some process.
<manu> w3c/
<markus_sabadello> DID Methods WG at DIF: decentralized-identity/
manu: It is totally blank right now. It is the job of the DIF did method chairs (which includes markus). manu will work on helping with basic content. Pierre (w3c staff) have to make an announcement that this may turn into a wg. You get your first wave there (love/hate) to the charter chairs think that they are ready, then it goes forward to member
vote, where formal objections are upheld or overturned. We are are slowly turning that crank. It could be as fast as a few weeks.
Drummond: I didn't realize it was quite on that fast of a track.
manu: I mean it *could* be that fast, but I don't think so. That is not going to happen. Deliberation is required as to which did methods should move from DIF to W3C. Maybe April may, with vote June, and formal objects resolved by TPAC. Maybe start by September or Fall.
Drummond: That seems realistic. It would be strange if the request to create this (which came from objections before) ends up with objections.
markus_sabadello: That group is meeting bi-weekly, and is in the selection/criteria process.
ChristopherA: Wanted to know what major candidates were under consideration... looking for a few, broadness, or any kind of early things that would move from DIF to W3C?
markus_sabadello: Currently undecided, and from what different categories, how many, etc. That is all still happening in other group. No strong decisions.
DID Core
markus_sabadello: on did core, spend a few minutes.
w3c/did#877
markus_sabadello: I wanted to highlight a PR request merged, #877, which adds dependencies to the vc controller specification.
markus_sabadello: This makes the did document a profile, a version of the controller document.
manu: a couple of things. Remember, we as a group had a CID acronym in the VC group, we renamed DID and CID short names. That migration took a lot longer. But that has been done. The repository has been renamed.
manu: we have a fancy new URL scheme.
https://
manu: and this will take you to the in progress 1.1 spec.
… We are down to about 20 issues for the did spec, we really only have like three class-3 issues. The rest are largely editorial. Not much update there.
manu: we've got like 7 specs moving into global standards, which is taking a lot of time.
… We have some requests to remove CID as an acronym as other close communities are using it.
Drummond: The first I heard CID, but then I was educated it was used by IPFS, etc. so is a name collision. What is going to be used. Just call it controlled identifiers. Frankly. Markus like this name. It is a compromise.
Drummond: Does it basically standardize what we consider as did:web? All https based?
manu: Yes.
… Like every place you could use a DID before, you can now use https:. It is essential did:web but https:
… Its existence is questionable in my mind.
Drummond: There are some not just ignoring DIDs, now maybe fighting it.
markus_sabadello: summarize from a technical specification, it is fully backwards compatible with. No breaking change given this dependency.
… this is aligned with the discussion about the abstract data type, and the media types.
ChristopherA: How does this work as far as other signature types? Not so much methods? But there are other things like new signature types, new whatever, is that controlled by VC group, us, data integrity? Who decides what are the other things in the DID/controlled identifier spec when they get added to?
<drummond> +1 to Manu's suggestion.
manu: Yes, that is an excellent question. Now it is more confused than we want in future. The DID group has DID identifiers, the VC group has controller identifiers. I suggest that we ask the VC based controller identifiers move over to us.
… as far as who decides what signature and cryptography. open world, they can put it anywhere, it get adds to vc-extensions and we have did-extensions.
https://
https://
manu: for vc-extensions define secure extensions, but the did extensions point to multiple registries. This is where there duplication.
https://
manu: you can register things in two places. They both have lax registration rules. If it is exists, we will accept it. Unless it is harmful.
… we need to make some decisions about in vc maintainance about this in the future.
markus_sabadello: Any questions before we move on to next item?
DID Resolution
markus_sabadello: on did resolution we have 2 issues marked pending close.
<markus_sabadello> https://
markus_sabadello: they have been address, I don't think we have to talk about them, but just as a reminder.
<markus_sabadello> https://
<manu> +1 to close pending close issues :)
markus_sabadello: we also have two open pull requests, both have some comments and reviews already, but are relatively straight forward, and we don't need to talk about.
… please review them if you have time.
manu: I have a question around, a meta question. Some W3C specs use the infra structure. Have we made decision about using infra, or defining something else, for did resolution.
markus_sabadello: I'm not sure. We have been using infra.
… Are we using infra for did core.
… I think so.
manu: We are using it in some places, but not all. That is what I was wondering.
… if something isn't lining up with infra, it should. It will help with w3c reviewers.
markus_sabadello: We were definitely using it for the abstract data model, given json. Maybe with the change away fro ADM we don't need infra.
manu: we should still use it, infra has a direct mapping to json.
markus_sabadello: I want to share and get attention on one issue, before doing other issue processing.
w3c/did-resolution#121
markus_sabadello: any other issues in resolution we want to cover, otherwise, we like to point people to
… #121 has to do with proposed enhancements that we've discussion in the last few meetings.
… it is a summary of some proposed new functionality that can be realized with new parameters.
… this issue summaries them in a table pointing to other issues.
… give the last few calls, they should be added to the did resolution spec, others to did extensions.
… There are 7 issues linked here. As of now, my idea is that 2 would be in did resolution, and 5 moved to did extensions.
… I'd like people to take a look and discuss.
… Either comment on this issues, or one of the 7 issues.
manu: A plus one support. A great summary of conversations we've had.
<drummond> +2
ChristopherA: I discussed at our last F2F about DID endpoint options to allow them to be committed to in a DID document but not revealed... was there interest in that since last F2F?
ChristopherA: endpoint functionality has correlation risk, don't have requirements about not having too much in endpoint.
<drummond> Agreed that there can be correlation risk.
manu: there is some definitely some interest in that. The way that we have approached is to not list the did document publicly, and transfer only p2p pairwise.
… but if there is a use case for putting out there a committed value, we should document it.
… as you need to transmit out-of-band.
ChristopherA: There are a lot of different things that endpoints do, if you look at how BlueSky and Mastodon, you can move your endpoint around but you may not want to reveal that your backup is in a different place, but in a DoS situation, when you can't get to one you did reveal, you want to reveal what your backup was. There are situations where people point to specific things inside service endpoint, we don't say what can/can't be in an endpoint.
ChristopherA: That's why I've been interested in this particular problem.
<manu> +1 to interest in that particular use case/problem, it's worth trying to solve/address.
<markus_sabadello> w3c/
markus_sabadello: I think we still have one issue open, in general about about encryption and selective disclosure, etc.
… how I understand this, can parts of the did document can be selectively disclosed. Maybe we should make this a special topic.
<markus_sabadello> w3c/
markus_sabadello: but separate from that is an issue (that we closed) which was something like a proxy service endpoint, which is simple, but behind it has more.
… maybe we should not have closed that.
ChristopherA: This is an interest of mine, but not in position to tackle it alone -- if this is important to you, please chat with me.
markus_sabadello: maybe we can organize a special topic. I think it worthy of it.
<denkeni> +1 to special topic
<markus_sabadello> https://
w3c/did-resolution#45
markus_sabadello: Now we'll move on other did resolution issues. The most recently updated one is #45
… lets take a look at it.
manu: I suggest this is pending close.
ChristopherA: There is some history on it -- same problem dealing with -- what is the controller document, we were calling this CID before DID pre-RWOT #1 -- then DID Doc, DDOs, its archaic and not necessarily that the problem is solved -- controlled identifier document, what's the universe of things?
<manu> +1 to "get it out of the queue"
Drummond: I haven't seen DDO. It was a deja vu moment. This thing is ancient. Brings me back to standing at a blackboard in DC. I remember manu coming to me and saying "shouldn't this be did document". Build a momument to and get get it out of way.
markus_sabadello: I agree, but there are some cases were there are some intermediate documents that the resolver needs to do.
ChristopherA: For BTCR, we only did a partial document, we had partial DDOs.
markus_sabadello: I will check if there is some sentence we can add about the larger issue of intermedia documents.
w3c/did-resolution#92
markus_sabadello: there is an existing test suites, but have not decided what do to.
https://
manu: This is one of the things that is vital to this group, as google ways we have to have interop.
… we have this test suite, to show it worked between different support of did:key. We have the infrastructure for did method test suites. We would end up using what ever the did resolution.
… we would need to define some of the key tests. did:key being one of the easier to do.
… But I think there is a difference between the did resolution test suite, that tests all the normative comments, vs a test suite for a specific did method.
… I ask in the VC wg, for the data integrity, we didn't create a data integrity test suite, but instead did a base set of cryptography tests. We imported that into the specific ????.
… This allowed us to have concrete did method test suites where the did resolver was the first half. Like the resolve call.
… Do we just have concrete test suites? I'm not sure that we can do it, maybe it belongs in future did method group.
ChristopherA: A couple of things ... more in favor of the functional approach, but there was some language about "DID Resolver has to pass had to be HTTP endpoint or Docker container" -- reason it was written was objections because there are no ways to concretely test.
ChristopherA: I have concerns about locking us into HTTPS won't serve larger community -- for W3C, yes, if you are assuming did:web, or web-centric, but you can have other types of protocols used, on-device resolvers, inside/outside of trust zones, that whole thing of mandating it has to be HTTPS or Docker to pass rubbed me the wrong way. I would prefer to see something more like what Manu was talking about.
markus_sabadello: let me respond, we definitely want to if https binding should be mandatory. We want to make sure that did resolution can happen over multiple ways. Sometimes we talk over function calls, not over web at all. https binding is one example, but not only.
<drummond> +1 to making sure DID resolution is not locked into HTTPS. That's certainly one option, but there absolutely need to be other transport protocols. There will for sure be one using the ToIP Trust Spanning Protocol (TSP).
markus_sabadello: is there a difference between a did resolution test suite vs a did method test suite.
… it may be enough to have one or more did method suites that test did methods.
<markus_sabadello> w3c-ccg/
Drummond: I want to support what ChristopherA, and we are running in the same problem in trust over ip, where we need more than https, such as tsp.
… I can't weigh in on test suite issues. Please leave things open to other bindings.
<manu> +1 to not locking into HTTPS only
markus_sabadello: thanks everyone!