Decentralized Identifier Working Group — Minutes

Date: 2024-08-08

Attendees

Present: Will Abramson, Ivan Herman, Gabe Cohen, Kevin Dean, Joe Andrieu, Markus Sabadello, Ted Thibodeau Jr., Jennie Meier, Christopher Allen, Benjamin Young

Regrets:

Guests:

Chair: Will Abramson

Scribe(s): Joe Andrieu, Manu Sporny

1. Agenda Review, Introductions.

2. Special Topic Call Summary.

Gabe Cohen: https://lists.w3.org/Archives/Public/public-did-wg/2024Aug/0002.html.

Gabe Cohen: reporting on the special topic call, especially scribing.
… . did not get to consensus on the Abstract Data model, but lots of good discussion.
… notes cover more detail.

See github issue did-core#855.

Gabe Cohen: we can discuss this topic more on future calls.

Manu Sporny: thanks for the summary. About note taking, it’s typically a bad idea not to scribe meetings.
… It creates bad situations where it seems like there’s a cabal talking about something, that later shows up at the main meeting.
… and people in the main meeting don’t have a way to understand the conversation that actually happened.
… As a global standards group, there are legal consequences to these conversations.
… e.g., if a patent was mentioned, that would go unrecorded and create IP issues.
… sometimes there are behaviors, such as CPC violations also get undocumented.
… I know you get that, Gabe, but I wanted to underscore for the rest of us the reason this is important.

Will Abramson: good points, we agree to scribe going forward.

Gabe Cohen: Dan’s notion was that a casual conversation might be good.

Manu Sporny: anyone can meet anywhere, yes, but when it is official W3C process, which means every decision we make is defensible and scribed.
… DB would probably stop participating if the group were to stop scribing.

Ted Thibodeau Jr.: along similar lines, I have been having problems with conversations and decisions that are handle in chair calls or editor calls that don’t involve the general group.
… . that’s problematic because its presented fait accompli.
… e.g., yesterday Ivan thought the scribing notice was sent to the list, but it actually wasn’t. It was sent to editors list.

Ivan Herman: +1 to Ted, I realized later that it was in a direct email.

Will Abramson: good points, tallted.

Manu Sporny: Yes, completely agree ^ – this has been a problem at W3C (and IETF) in the past and we need to do better.

Will Abramson: next week: no special topic call.
… Our goal is to announce at least by the Thursday before.
… Let us know if you have any topics for a future special topic call.

3. DID Resolution Big Rocks.

3.1. (issue did-resolution#80)

See github issue did-resolution#80.

Markus Sabadello: can I talk about some PRs before that?

See github issue did-core#857.

Will Abramson: yep.

Markus Sabadello: this issue is about moving all the context related to did resolution to the did resolution spec.
… the idea is to make everything related to resolution is in one place.
… I opened two pull requests that go together. One on did core and one on did resolution.

Markus Sabadello: https://github.com/w3c/did-core/pull/858 and https://github.com/w3c/did-resolution/pull/84.

Markus Sabadello: it would be great if that could be reviewed.

Manu Sporny: +1 to support PR.

Will Abramson: so we give it a week for any comments. then we’ll get that merged in.

Markus Sabadello: there is one related question about metadata.
… we have did document metadata and did resolution metadata, such as when was the doc created/updated, etc.
… with these PRs, this is moving over as the metadata is about resolution.
… but I thought maybe its worth asking about.

Manu Sporny: +1 to support that. any metadata feels like it goes in the resolution spec.

3.2. (issue did-resolution#80)

See github issue did-resolution#80.

Will Abramson: markus_sabadello I’ll let you pick the next issue.

Markus Sabadello: there are a couple to see if we have a general direction to proceed.
… (four topics).
… These are the most prominent sections.
… If we’re agreed, then we can proceed to other issues.
… I’ll quickly summarize if that would help.
… first one #80 is about DID resolution and did dereferencing algorithms.
… so far in the spec we have defined resolution and reference as abstract functions.
… we said “here’s a resolve function, inputs & outputs) but not how they are processed.
… we have not specified how to process certain query string parameters or how to dereference a path if there is one.
… or how to process meta-data from the functions.
… So there’s a section that defines a more concrete algorithm for resolving and dereferencing.
… I’d like to get feedback about if this is the right direction.
… if we agree it is, then good. this is one of the key areas we have to address.

3.3. (issue did-resolution#81)

See github issue did-resolution#81.

Markus Sabadello: On to #81 is about architecture.
… That has to do with how do you communicate with a resolver. Is it a local library? A remote service?
… how does the client talk to a resolver, and how does the resolver process a request.
… maybe resolvers redirecting to others.
… and topics about how you trust a resolver. do you run it yourself?
… . do you use someone else’s. if so, how do you check the result?
… Things like that.
… it would be good to get high level feedback.
… for example, if there are people who think resolution should be a strict client-server protocol.

Will Abramson: as I hear you talking through that, I’m wondering how much might be in implementation guide instead of in spec.

Manu Sporny: I think it is important to highlight that there are multiple architectures.
… I was kind of ambivalent to that until you mention client/server.
… to which I’m like “NO.” not client server.
… We’re in a situation now where we do need to clearly delineate the architecture.
… there is a difference between local only and remote at a minimum.

Joe Andrieu: This client server question – it’s going to be vital to have mandatory to implement HTTPS API – I think that’s how we get cross-site/cross-method interop. If each Method HAS to expose common endpoint, we’ll have interop between methods, if we have customized architecture but no mandatory to implement, we won’t achieve interop goals.

Christopher Allen: I have questions about how much we need to talk about trust models in this document.
… I think there’s a minimum that we should clarify.
… the first resolver you just have to trust.
… maybe because it’s on your local machine.
… we should be careful other than locking that down, other than you have to trust that first one, but if that one then calls others, that’s another layer of trust.

Will Abramson: markus we’ll give you last word on this before we move on.

Manu Sporny: I think most methods would implement the http api, maybe doesn’t need to be MTI (mandatory to implement).
… I’m concerned about “cross method interop” and I don’t think I know what that means. for a future discussion.

Markus Sabadello: relating to trust models.
… totally agree. there’s some discussion in this section.
… e.g., running your own bitcoin node versus remotely querying.
… What Joe said about mandatory http endpoint: yeah, maybe. a counter example.
… these are the things that would go into that secton.
… more discussion on the github would be appreciated.

3.4. (issue did-resolution#82)

See github issue did-resolution#82.

Markus Sabadello: this is about having a concrete serialization / representation of the result of resolution funciton and entity reference function.
… we had these defined in an abstract way, but we have not defined every presentation or serialization of that.
… defines a JSON_LD model where you have did document and metadata in the same document.
… this is related to the abstract data model, so not so simple, but I’m curious if anyone in the group doesn’t like this idea.

3.5. (issue did-resolution#83)

See github issue did-resolution#83.

Markus Sabadello: this is about https interface.
… how to implement the abstract resolution over https.
… it defines how the abstract endpoints are satisfied by the http endpoints, how to contsruct URLs and headers, etc.
… If you resolve a DID that is deactivated, then how is that returned over an HTTPs binding? Some say there should be an HTTP error code.
… others say it’s not an error if it is deactivated. so return 200 with appropriate metadata.
… I’m looking for initial feedback. Is this one of the things we should be doing? An http interface?
… separately we can discuss if it should be mandatory.

Manu Sporny: +1.
… the theme here is “do we want to talk about abstract stuff” in the space, then do we want to provide concrete instances of those abstract concepts.
… are people going to kick up a fuss about an http API. I think we should do it.
… we were “too abstract” before.
… We’re doing this to ensure that interoperability is demonstrable.

Joe Andrieu: The way you presented it, Manu, you made it seem like we keep abstract notions in new spec w/ concrete thing. I think we need to move beyond abstract – take what we defined as abstract and define that into concrete endpoint.

Manu Sporny: I was saying lets keep both of them for now. maybe they merge in the future.
… it may help us think about it abstractly, then make all interop testing about concrete things.
… in theory we should be able to separate those two notions.
… that is what got us in trouble with the abstract data model.
… but some people like that.

Stephan: back to mandatory to implement, do you mean to define the API or an actual service endpoint.

Joe Andrieu: I definitely just mean the API.
… Some decentralized services cannot be resolved to a specific URI – there is no URI for a bitcoin node, but you can provide a piece of software that can expose itself on an IP or domain and interact w/ that resolver. Not an actual service endpoint, I agree, that would be a point of centralization. I’d just like to see an API.

Will Abramson: moving on.

4. DID Core Big Rocks.

Manu Sporny: these are just big rock concepts that don’t necessarily have much to do with each other.
… just general decisions we need to make.

4.1. (issue did-core#857)

See github issue did-core#857.

Manu Sporny: first one is do we want to move did resolution from did core to did resolution. we said yes to that today. done.
… unless folks want to speak up.
… pausing a beat.

4.2. (issue did-core#850)

See github issue did-core#850.

Manu Sporny: going a bit out of order.
… 850 is just updating JSONWebKey examples.
… did:core contains outdated examples. I’d like to update them.
… small snag, v1 context doesn’t contain the JSONWebKey type.
… I’d recommend another context in the example, since the example is not normative.
… So first question do we want to update from the 2020 stuff to the latest?

4.3. (issue did-core#854)

See github issue did-core#854.

Manu Sporny: Hearing no objection, moving to next item.
… 854 is about normative referencing the controller document specification.
… . folks in VCWG didn’t want to use DIDs, but did want to use DID documents.
… so we created this separate document that is generalized. Any URL can be used, https is what most from that community wnat.
… what we could do in did core is, instead of duplicating text, we can refer to the controller document, with annotation about where you use DID documents in a controller document.

Ivan Herman: See VC Version of the controller document.

Manu Sporny: we think the controller document will be a REC before we are done in our group.
… suggestion: start referencing the normative controller document.

Will Abramson: if we did this, what would be left in did:core?.

Manu Sporny: quite a bit still.
… did syntax, introduction, example, design goals, architecture, identifier, data model, and core properties of identifiers remain.

Joe Andrieu: would remove verification relationships and methods.

Manu Sporny: services might also be moved.
… we would leave representations in here. We’d keep Methods in the main document. Maybe 70% of considerations are in the controller doc.
… so it would shrink quite a bit, but there’s still plenty left.

Christopher Allen: part of me likes the simplification and I have a reservation that, in the VC group, are we moving toward looking down to JSON-LD with the latest ieration.
… by doing this is that totally out of our control?
… other than the loss of control… I kinda like the idea.

Manu Sporny: not locked to JSON-LD.

Christopher Allen: Oh, is there a cbor version of it being discussed there?

Christopher Allen: (ideally dCBOR).

Manu Sporny: as far as control. it really should be in this group, but for historical reasons it was created in response to needs from the VCWG.
… we may want to reimagine how we do data-integrity development and did development in the future.
… that would need a rechartering, which we don’t want to do now.
… I don’t see a particular risk with the VCWG making negative decisions.

Will Abramson: what is the scope of this group take ownership of that work?

Markus Sabadello: I think it’s a great idea to just reference the controller document.
… I’m already getting questions about what’s the difference?
… Concern that if we keep it separate, then we diverge with conflicting language.

Christopher Allen: at some point there was discussion about a CBOR version or other representations. Did that continue?

Gabe Cohen: https://www.w3.org/TR/did-cbor-representation/.

Gabe Cohen: its in our charter to have a plain CBOR representation.
… I’m not aware of any efforts, but that would be cool.
… I’d prefer the item be in this group, but rechartering seems painful.
… It may be confusing to go across multiple documents from different groups.
… any way we can reduce that burden would help.

Christopher Allen: a deterministic CBOR (an IETF internet-draft subset of CBOR that addresses determinism issues of CBOR) is of interest to me. Just don’t have time to submit to another group.

Ivan Herman: Rechartering is never painless. We should avoid that.

Christopher Allen: If there are others interested, let me know.

Ivan Herman: one more aspect toward referrijng to the VC document. We define a bunch of terms in did document, but they are all defined, formally in the VC document. They are all in the security vocabulary.
… the controller document must be controlled by the working group that takes care of the relevant vocabulary.
… that is in favor of keeping that in the VCWG.
… As far as I can see the DID part only adds one or two terms, like services, which are not in the security vocabulary.

Manu Sporny: we do have a CBOR-LD that will compress all the terms and keys. You get a fairly tight compression.
… I don’t recommend we pick that up. We are working on a charter for a separate WG.
… Second: specifications keep landing in weird places. They make sense at the time of chartering, but over time they really want ot be somehwere else.
… things end up taking their life of their own.
… we should think about the right place for these to go.
… VCs in VCWG, etc., adjusting that (charters) is painful, but we can do it as we naturally recharter into the future.

Gabe Cohen: +1 to imagining the ‘ideal state’ even if not possible today.

Will Abramson: continuing next week!