Decentralized Identifier Working Group — Minutes

Date: 2024-07-25

See also the Agenda and the IRC Log

Attendees

Present: Pierre-Antoine Champin, Ivan Herman, Gabe Cohen, Markus Sabadello, andres, Christopher Allen, Manu Sporny, Joe Andrieu, Kevin Dean, Jennie Meier, Benjamin Young

Regrets:

Guests:

Chair: Will Abramson

Scribe(s): Ivan Herman

Content:

Will Abramson: rsagent, draft minutes.

1. Agenda Review, Introductions.

Will Abramson: anyone new today?
…
…
…

2. Announcement: APAC Meeting Time Poll.

Gabe Cohen: https://doodle.com/meeting/participate/id/aK5MXoRd.

Will Abramson: APAC meeting time poll.
… see link about.
… we try to close the poll 5pm Wed.

Will Abramson: https://doodle.com/meeting/participate/id/aK5MXoRd.

3. Announcement: First Special Topic Call 7th August.

Will Abramson: 1st special topic call 7 august.
… topic will be about abstract data model.

See github issue did-core#855.

Will Abramson: we give it 2 weeks.
… we ask people to reach out to chairs friday next week.
… some people do not understand the trade-off of choosing or not choosing.
… if you have sg to share or an opinion have a presentation.
… any comments?

4. DID Resolution.

Will Abramson: hand over to markus.

Markus Sabadello: (slides will be available).

Christopher Allen: my quetion is more of a process/politics question. We were clearly requested that we need to do more formalized did resolution.
… That raises the question what part of this normative (to answer their concerns) and what are the things that might create problems.
… eg I am interested by selective disclosure, but I do not know what can be normative, what can not.
… I try to understand the dimensions to get this through.

Will Abramson: we should plug things into issues.

Manu Sporny: thanks Markus. I think the question you highlighted are the right ones.
… in did core things were put there because that was the only place, we should move them now to the resolution spec.

Will Abramson: +1.

Manu Sporny: what do you need to process the issues, you are the best person to prioritize them.
… we should put lot of focus on resolution 3:1 compared to DID Core.
… are you planning to prioritize?

Markus Sabadello: I am happy to hear that we want to move things from core to resolution, it will simplify lots of things.
… what would help me is to solve the abstract data model question, that would simplify the resolution process.
… i need feedbacks from the wg on the questions.
… one thing would be bad if we spend a year on easy topics (eg, error code) and then somebody says that the structure is bad…
… getting feedbacks on the high level structure would be important.

Joe Andrieu: +1 to move resolution out of core.

Gabe Cohen: +1 to http interface.

Joe Andrieu: a quesiton I like to add is to have a mandatory http interface, but we if we want to answer the concerns we should say that a bona fide method should have an http interface.
… on the abstract data model: we cannot test that, but having a datatype that we can test would be better.

Will Abramson: we want indeed to move the big rocks.
… we have to decide what we want to put time into.

Manu Sporny: lots of agreement with what ChristopherA and JoeAndrieu said.
… we have to talk about test suites as well, to address criticisms.
… having an http based test suite will be useful.
… if we do that we can point to a concrete api.
… we already have a test suite for did, but it is not adequate.
… we may want to spend time a did ‘linter’.
… it is not difficult but would be useful.

Christopher Allen: Is a did “linter” really a controller document “linter”?

Manu Sporny: it would give the community a usefule tool.
… it would be easy to do.
… maybe a resolution sofware could include it.
… +1 to Joe, we need an http api, it woul help us to test suites.
… Ideally, we should have a test suite in about 6 months.

Christopher Allen: which of these things (the misc page on the presentation) would put us at risk at the end.
… i try to get a feel to see which are risky.

Markus Sabadello: you mean list (page 9)? I do not think any of these are critical.
… the big ones are the arch designs and the bindings; these are minor issues.
… we can also use the registry to add error codes, for example.
… we can use extension, not in the spec itself.
… i see these as less risky.
… we also did a linter project, will share that as well.

Markus Sabadello: DID Resolution test suite: https://github.com/w3c-ccg/did-resolution-test-suite.

Markus Sabadello: DID Lint / Validator: https://didlint.ownyourdata.eu/.

Manu Sporny: on the risks, I agree with markus, I do not think there is any risk, we can put anything in it that does not exceed the charter.
… per the core, with the changes may be risky.
… eg, we may point to the credential doc and that may be risky, but it will be out there earlier.
… the abstract data model removal may be a bigger risky, but that is not testable, so it is more problemantic, and if there are other represenations (cbor, yaml, etc), we may get.
… unfriendly comments. But we can re-write so that other data formats should be possible to do that. But if we pick a serialziation in the core model, that can lead to objections either without or outside the group.

Christopher Allen: I am still concerned, I do not know what they former objector’s opposition to the resolution (eg, get this in the browser), that means an internal API which is not http.

Ivan Herman: I am a bit confused.

Christopher Allen: I prefer to the abstract data model in the core and the resolution should be very specific, it can do tight conformance in json, or http.
… the did core 1.1 will not say that you MUST use did resolution.
… some may different model for selective disclosure, for example,.
… the did resolution is zero constraint and help the did core documen where it is not precise enough.

Manu Sporny: the concerns raised during the previous specs; if we can demonstrate that we have interoperability better than before, I do not think it matters whether it is resolution or not.
… they were starting to “ just show use at least one interoperable method”.
… we have that already.
… then there was a request you referred to some method that are really decentrilized, not like, eg, did:web.
… there are couple of layers, and each organizations asked different things.
… but if we get back the same did document from different software, for example, we would prove interoperability.
… we do not standardize specific did methos.
… that should address the initial formal objections, and we are in a stronger position now.

Christopher Allen: I’d like to add to a future agenda, if how much we have to define for “trust in did resolution”/”authentication”/”encryption”/”sd”.

Will Abramson: I suggest adding an issue ChristopherA.

Markus Sabadello: thanks for bringing all this up, i agree with this deliverable will prove the requirements the community has, the http binding will help further.
… at the last tpac tehre were also a number of ideas.
… eg, supported methods by a resolver can be discoverable.

Joe Andrieu: +1 to support redirection / discovery of other resolvers.

Will Abramson: thanks for this presentation.

5. Next Up: DID Method Registries.

Will Abramson: remind you to get the issues in.

See github issue did-spec-registries#568.

Will Abramson: next week we will discuss registry again and that issue ^ on how to split up the registry.
… thanks everyone.