Decentralized Identifier Working Group — Minutes

Date: 2024-08-15

See also the Agenda and the IRC Log

Attendees

Present: Gabe Cohen, Ivan Herman, Will Abramson, Ted Thibodeau Jr., Benjamin Young, Kevin Dean, andres, Manu Sporny

Regrets:

Guests:

Chair: Gabe Cohen

Scribe(s): Benjamin Young, Manu Sporny

Content:

• 1. Agenda Review, Introductions.
• 2. Controller Document.
• 3. APAC Call Announcement.
• 4. TPAC Topic Announcement.
• 5. DID Core update vs. new @context Discussion.
  • 5.1. (issue did-core#859)
• 6. Media Types.
• 7. Moving DID Resolution.
• 8. DID Core/Resolution Issue Processing.
  • 8.1. Fix improperly URI Encoded values in DID parameters https://github.com/w3c/did-core/pull/813.
  • 8.2. Fix serviceEndpoints maps link https://github.com/w3c/did-core/pull/851.
  • 8.3. https://github.com/w3c/did-core/pull/852 Use publicKeyMultibase instead of publicKeyBase58 field in all examples.
  • 8.4. https://github.com/w3c/did-core/pull/856 Fix JSON formatting for DID document.
  • 8.5. (pr did-core#858)

1. Agenda Review, Introductions.

Gabe Cohen: agenda review.
… we’ll talk about the controller document.
… no special topic call next week as we do not have a topic yet.
… if you have one, please let us know on the mailing list.
… also we’ll talk TPAC and doc organizing.
… and issue processing toward the end.
… anything else?

2. Controller Document.

Gabe Cohen: we’ve talked about this document before.
… it’s at the VC WG.
… we look forward to collaborating with them.

3. APAC Call Announcement.

Gabe Cohen: minutes are available from last week. They’re approved since no objections.

Gabe Cohen: Thursday 5-6 pm US Pacific Time.

Gabe Cohen: - Thursday 8-9 pm US Eastern Time.

Gabe Cohen: - Friday 0200-0300 Central European Time.

Gabe Cohen: - Friday 8-9 am Hong Kong.

Gabe Cohen: we’ve settled on a Thursday/Friday call.
… first Thursday in each month.
… hope you can make it.
… and we’ll send out notifications.

4. TPAC Topic Announcement.

Gabe Cohen: the calendar is already updated.

See github issue did-wg#57.

Gabe Cohen: TPAC will be here before you know it.
… please add to that issue if you have presentations you’d like to make.
… even if you just have idea you’d like to see presented, please share.
… We’re scheduled on Monday and Tuesday.
… we plan to do a group dinner Monday evening.
… if we have a sponsor, it can be a more formal thing.
… but even without one, we’ll find a place to meet up and pay for our own meals.

5. DID Core update vs. new @context Discussion.

See github issue did-core#850.

Gabe Cohen: one issue that’s come up so far…
… there are some terms that we’d like to update.
… so do we make a new context to be used instead? add an additional context? or amend the existing one?

Manu Sporny: amending the current context is possible if a bit fraught.
… we’ve been trying to follow a best practice of only amending contexts for security vulnerabilities.
… this situation is not a security issue…just establishing new terms from the Controller Document from the VC WG.
… we can do this in a non-disruptive way.
… by publishing a v1.1 context.
… it’s arguable if this is a new feature or not.
… we do specify a v1 context in the spec.
… we would be updating the text to say in future the v1.1 context would be used.
… we can do this in a way where everything stays the same–use v1–but if you want the new terms, use the v1.1 context.
… if we really wanted to, we could keep all the old stuff in the v1.1 context, so less would need to be changed to upgrade to using it.
… I do think this would be a good idea.
… we need to see if anyone would object if we did this as a MAY in the spec.
… lastly, if we don’t do this now…it’ll be another 2 years to get these terms into the core context, which seems too long.

5.1. (issue did-core#859)

See github issue did-core#859.

Gabe Cohen: this is the new issue for it. manu, could I assign you?

Manu Sporny: yes.
… I’d like to hear from ivan.

Ivan Herman: mainly, I just want to understand…
… the did core context is very small and simple.
… most of them already match the Controller Document.
… what are the additional terms?
… if we’re adding terms to the DID spec, we may have other problems.

Manu Sporny: right. Specifically, we’re talking about….
… the main thing these are used for is listing key material.
… when we put the spec together, there was just JSON Web Key 2020.
… we’ve decided to drop the date off the term.
… we’d also switched to using a more consistent format with multikey.
… we could make these changes and keep all the old stuff there.
… or we could decide to use v1.1 and not bring over the old terms forcing upgrades to the new terms.
… there are good arguments either way.
… I’d lean toward it being a clean break.
… asking people to move to the new key formats.
… since it’s a MAY, then no one needs to upgrade if they don’t want to.
… that was the thinking. Mostly around key formats.

Ivan Herman: I’m undecided at this moment.
… the nature of the additions seem to make doing this overkill.
… so I think we can postpone.

See github issue did-resolution#78.

Gabe Cohen: there is a slightly related issue.
… some context issues related to the move.
… we need to make sure those are available.
… it may be premature now, but still making a strategy would be best.

Manu Sporny: one of the things that we’re concerned about are production rollouts that we’re doing.
… we’d like to use the new key formats.
… and we’re concerned about being stuck with the old key formats.
… we can fold the new ones in by using other contexts.
… but ideally, we’d like to use a v1.1 context.
… so…that doesn’t really help make the decision since we have options either way.
… but perhaps that explains the importance of the topic for us.

Ivan Herman: if I take the union of DID and VC WGs, then we may be inconsistent.
… in the VC WG there are separate context files.
… and they are not in the DI context files.

Manu Sporny: Well, not really :).

Ivan Herman: here we are moving toward unifying them.

Manu Sporny: (or rather, no, we’re not doing that).

Manu Sporny: The split is (what goes in a VC vs. what goes in a controller doc).

Ivan Herman: it’s doable, but I’m not keen on the inconsistency.

Manu Sporny: the dividing line seems to be what goes in a controller doc.
… those are public keys and controller services.
… I think we have a controller document context.
… in VCs, we have similar terms for proof’s.
… that may be changing with confidence method.
… Main question is around expectations that differ between what would go into a VC vs. a Controller Document.
… hopefully that helps explains why things are split up that way.

6. Media Types.

Gabe Cohen: https://www.w3.org/TR/did-core/#iana-considerations.

Gabe Cohen: we have two media types.

Gabe Cohen: https://github.com/w3c/did-core/issues/838, https://github.com/w3c/did-core/issues/849.

Gabe Cohen: there are issues around when those are unknown.
… question is do we want to make adjustments.
… are we comfortable with how things are today?

Manu Sporny: this sort of comes in from the VC WG conversations.
… we were going to use multiple suffixes.
… but at the end of the day there was no consensus at IETF.
… and now they don’t want multiple suffixes at all.
… and they made the decisions, so that is over.
… which means we can only have single suffixes.
… which then forces everyone else to fix a base subtype.
… currently, we wanted did+json and did+ld+json.
… we could do did-ld+json, but we can’t.
… we got bad advice.
… so we’d have to get the JSON-LD WG to register a ld-json type.
… and all of this will likely be many months of conversations.
… so…we will likely have the same conversations around JSON vs. JSON-LD at the media type level.
… or we need the JSON-LD WG to change their media type.

Gabe Cohen: chair hat off.
… if there is no concrete core representation, could we have just did?
… or do we have to have several media types that include did?

Ivan Herman: we could use the profiles.

Manu Sporny: that’s a third option via parameterized media types.
… implementers get it wrong.
… but in general, they mostly get ignored.
… we can have a media type with a suffix.
… application/did+json or application/did+json-ld-something.
… we can talk to the JSON-LD WG to discuss about a new structured suffix.
… we would then not have to register application/did.
… but that would drive us into the weeds of the abstract data model discussion.

Benjamin Young: As Chair of the JSON-LD WG, we are re-chartering, it’s something we could pick up, because the current media type is so widely deployed, there might not be interest in coming up w/ a structured syntax, and because most JSON-LD is served w/ application/json – there is a lot of discussion we could have around what the media type value is in practice, especially in distinction between JSON and JSON-LD, the media type really doesn’t provide.

Manu Sporny: anything, other than a few processing specialities around HTTP Headers that JSOn-LD spec provides.

Benjamin Young: In terms on what could be done w/ the body, nothing is really different wrt. media types – Media Types seem to be jumping the shark, we shouldn’t depend on them too much.

Joe Andrieu: I wanted to support application/did.
… what we are standardizing is what goes over the wire.
… having a media type seems appropriate.

Manu Sporny: the amount of stuff in media types is ongoing.
… there are arguments that people will do things based on media types.
… but people mostly don’t depend on them in practice.
… even when we’re clear, folks mostly just use application/json.
… JSON-LD processors don’t care.
… the application/ld+json media type doesn’t tell a processor much more than that.
… and since implementers continue to get things wrong, there’s nearly always a fallback mechanism to decide what to do with the payload.
… typically there’s introspection of some kind.
… it is a bit of a mountain out of a mole hill.
… we could pick application/did and be done with it.
… most implementations will use JSON Schema.
… and things that want @context will reject it or act on the document as if it were there.
… we will need some language around the handling.
… we could get to a base media type that’s JSON.
… and go from there.

7. Moving DID Resolution.

Gabe Cohen: thanks. please contribute to the media types issue.

See github issue did-core#857.

Gabe Cohen: this one is about moving content.
… there are 3 different sections.

Manu Sporny: no concerns. this is a good thing to do.
… +1 to the PRs.

Joe Andrieu: +1 These are good.

Gabe Cohen: great.

8. DID Core/Resolution Issue Processing.

Gabe Cohen: last up is issue processing.
… if you have an issue you want to speak to, let me know.
… otherwise, we’ll just work through what’s open.
… k. we have 5 open PRs.
… on did-core.

8.1. Fix improperly URI Encoded values in DID parameters https://github.com/w3c/did-core/pull/813.

Gabe Cohen: this one was opened in 2022.

Manu Sporny: there’s discussione between TallTed and dlongley.

Ted Thibodeau Jr.: I don’t think there is any more disagreement.
… the gist is don’t encode things that don’t need to be encoded.

Manu Sporny: agreed. that means the PR needs to change.
… just looking at the PR…
… TallTed could you suggest what doesn’t need to be encoded here?

Ted Thibodeau Jr.: I’ll have to take a look.
… the big one is a # that appears.
… is that part of the URL?
… or a delinator?

Manu Sporny: it’s part of the URL.
… that bit would get tacked onto the end of the URL.
… I know what you want here, so let’s try to work it out on the PR.
… change requests would be ideal.
… thanks TallTed.

Gabe Cohen: thank you both.

Gabe Cohen: .

8.2. Fix serviceEndpoints maps link https://github.com/w3c/did-core/pull/851.

Gabe Cohen: manu mentioned it couldn’t be addressed earlier due to recharter, but now it looks done.
… so can we close it?

Manu Sporny: yes. just waiting on a response on the PR.
… we fixed the core spec. The change was fine in concept, just in the wrong place.
… don’t close it yet because ivan’s robots will be sad.
… oh, nevermind…the bots are elsewhere.

Gabe Cohen: one day we may have those robots here, but not yet.

8.3. https://github.com/w3c/did-core/pull/852 Use publicKeyMultibase instead of publicKeyBase58 field in all examples.

Gabe Cohen: this PR has been opened since March.

Manu Sporny: this has to do with v1.1…maybe.
… this is related to these new terms.
… we could pull in a new context and fix it immediately.
… and I think we should just do that.
… to upgrade to multibase in that way.

Ivan Herman: +1 to Manu.

Manu Sporny: any objections?

Gabe Cohen: seeing no one on the queue, manu maybe you can take over the PR?
… the author may not be able to continue due to IPR?

Manu Sporny: it’s an example, so I think we can clear that.
… I’ll finish it up.

8.4. https://github.com/w3c/did-core/pull/856 Fix JSON formatting for DID document.

Gabe Cohen: this one is a month old and has approvals.

Manu Sporny: I can merge it.

8.5. (pr did-core#858)

See github pull request did-core#858.

Gabe Cohen: there are no reviews yet.
… please take a look and review it.
… that concludes our agenda.
… join the queue if you have more to say.
… k. hearing nothing. thank you for the progress.
… next time, we will continue processing issues and prs.
… please also join the TPAC conversaion.
… have a good week!