Meeting minutes
Agenda Review, Introductions
decentralgabe: 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?
Controller Document
decentralgabe: we've talked about this document before
… it's at the VC WG
… we look forward to collaborating with them
APAC Call Announcement
decentralgabe: minutes are available from last week. They're approved since no objections.
<decentralgabe> Thursday 5-6 pm US Pacific Time
<decentralgabe> - Thursday 8-9 pm US Eastern Time
<decentralgabe> - Friday 0200-0300 Central European Time
<decentralgabe> - Friday 8-9 am Hong Kong
decentralgabe: we've settled on a Thursday/Friday call
… first Thursday in each month
… hope you can make it
… and we'll send out notifications
TPAC Topic Announcement
decentralgabe: the calendar is already updated
<decentralgabe> w3c/
decentralgabe: 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
DID Core update vs. new @context Discussion
<decentralgabe> w3c/
decentralgabe: 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: 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.
w3c/did-core#859
decentralgabe: this is the new issue for it. manu, could I assign you?
manu: yes
… I'd like to hear from ivan
ivan: 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: 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: I'm undecided at this moment.
… the nature of the additions seem to make doing this overkill
… so I think we can postpone
<decentralgabe> w3c/
decentralgabe: 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: 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: 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> Well, not really :)
ivan: here we are moving toward unifying them
<manu> (or rather, no, we're not doing that)
<manu> The split is (what goes in a VC vs. what goes in a controller doc)
ivan: it's doable, but I'm not keen on the inconsistency
manu: 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
Media Types
<decentralgabe> https://
decentralgabe: we have two media types
<decentralgabe> https://
decentralgabe: 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: 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
decentralgabe: 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: we could use the profiles
manu: 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
bigbluehat: 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
anything, other than a few processing specialities around HTTP Headers that JSOn-LD spec provides.
<Zakim> JoeAndrieu, you wanted to support `applicaiton/did`
bigbluehat: 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.
JoeAndrieu: I wanted to support `application/did`
… what we are standardizing is what goes over the wire
<Zakim> manu, you wanted to note that media types are jumping the shark a bit.
JoeAndrieu: having a media type seems appropriate
manu: 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
Moving DID Resolution
decentralgabe: thanks. please contribute to the media types issue
<decentralgabe> w3c/
decentralgabe: this one is about moving content
… there are 3 different sections
manu: no concerns. this is a good thing to do
… +1 to the PRs.
<JoeAndrieu> +1 These are good
decentralgabe: great.
DID Core/Resolution Issue Processing
decentralgabe: 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
decentralgabe: k. we have 5 open PRs
… on did-core
Fix improperly URI Encoded values in DID parameters w3c/did-core#813
decentralgabe: this one was opened in 2022
manu: there's discussione between TallTed and dlongley
TallTed: I don't think there is any more disagreement
… the gist is don't encode things that don't need to be encoded
manu: 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?
TallTed: I'll have to take a look
… the big one is a # that appears
… is that part of the URL?
… or a delinator?
manu: 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
decentralgabe: thank you both
Fix serviceEndpoints maps link w3c/did-core#851
decentralgabe: manu mentioned it couldn't be addressed earlier due to recharter, but now it looks done
… so can we close it?
manu: 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
decentralgabe: one day we may have those robots here, but not yet
w3c/did-core#852 Use publicKeyMultibase instead of publicKeyBase58 field in all examples
decentralgabe: this PR has been opened since March
manu: 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> +1 to Manu
manu: any objections?
decentralgabe: 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: it's an example, so I think we can clear that
… I'll finish it up
w3c/did-core#856 Fix JSON formatting for DID document
decentralgabe: this one is a month old and has approvals
manu: I can merge it
w3c/did-core#858
decentralgabe: there are no reviews yet
… please take a look and review it
decentralgabe: 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!