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.
- 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!