Meeting minutes
Agenda Review, Introductions
decentralgabe: agenda is a process announcement, TPAC, did-core and did-resolution issue and pr processing
DID WG Process Announcement
wip: we will announce pending close issues for the week in the agenda. after the thursday call (either APAC/regular), those issues will be able to be closed
… every week you will have a chance to challenge a pending close issue. unless you have concerns
TPAC Preparation
decentralgabe: any concerns? Hearing none, moving on
https://
decentralgabe: This is the link to our TPAC slides. Please add your slides by this Friday if possible
… We have discussed COVID policy as chairs. Masking is optional, but not required. Let us know if there are any concerns
wip: please add yourself to the attendance sheet. and get slides in by Friday.
DID Core Issue/PR Processing
decentralgabe: Editors have any issues / PRs that need attention?
w3c/did-core#852
manu: This one is waiting on merge conflict resolution
… We might have to do a more complete fix with this one. Or pull the PR in and make the fix later
decentralgabe: I noticed you tagged the author. If manu you can take it over that would be great
manu: Sure, I can take it over.
ivan: Why do you think it is aclass 2 change? I think it is a class 3
… using public key multibase effects implementations
manu: It effects the examples, this is non-normative
ivan: Okay, yep its a class 2
manu: There is a separate issue that discusses upgrading to publicKeyMultibase
https://
w3c/did-core#863 application/did+ld+json should be revisited
manu: Strategy to discuss the big rocks first. Class 3, then 2 then 1
… 863 is about the media type. In did-core we said application/did+ld+json
… open question what the media type should be. Cannot have did+ld+json
… some implementors want to use json serialization others jsonld
… Looking at potentially 2 media types
… we could try application/did as the media type
… with the new controller document which supports context injection. We can parse as json if it doesnt have a json if it does have a @context you can parse as jsonld
… if you want to parse as jsonld but it doesn't have a context you can inject one
<ivan> Controller document context injection section
manu: Strongly suggesting we just do application/did to keep it simple
… Need to be clear we are not allowing two different processing models
… thoughts concerns about application/did
<bigbluehat> +1 to `application/did`
<dmitriz> my vote would be for application/did+json. To enable the eventual (and inevitable?) application/did+cbor
markus_sabadello: What does this mean for the abstract data model, if the controller document allows context injection
<Zakim> manu, you wanted to go into polyglot response if it becomes an issue.
manu: Still have the abstract data model. You would still be able to use JSON. Or you can use jsonld. Fundamentally these are interpretted the same. The meaning is the same
markus_sabadello: I want to do this. Seems like we don't need the different representations anymore.
dmitriz: In JSON vs JSONLD we loose track of other things like CBOR and YAML. My vote is for application/did+json
… implementations need to know how to parse the document
ivan: Understand dmitriz opinion. But, the VCWG has decided to use application/vc for verifiable credentials
<Zakim> manu, you wanted to note that we could have CBOR in the future. and to ask if it's "application/json", then what do we do for JSON-LD?
manu: Not closed the door on CBOR or YAML. Could have did+cbor or did+yaml. But what do we do about jsonld. We could say application/did is jsonld
… Or we would have to get a new suffix through the jsonld working group
… Markus, the reason we would have different representations is to support CBOR and YAML
… One more option, for JSONLD DID documents jsonld/we could use application/ld+json/jsonld
decentralgabe: encourage people to consider discussion on an issue
decentralgabe: time for one or two more
w3c/did-core#842 Request for Guidance on Normalization Rules Enforcement
manu: This is someone asking what the normalization rules are for URLs
… Letting implementors decide what level of normalization they support
… A response is the normalization rules for URLs is clear and exists in the WHATWG
… We would need to check these apply cleanly to DID URLs
… We could say we are using the WHATWG normalization rules
… Others state on the issue that people in the field are normalizing in different ways. Very few specs say anything about this.
dmitriz: What is URL normalization?
<manu> These are the URL serialization rules in WHAT WG URL spec: https://
manu: This is about percent encoding. Having dots in the URL path. There is a concept called URL serialization
… See the link above
… apply a series of rules to get to a normalized URL
… problem is DIDs don't have hosts. So we need to analyze this more deeply
… This group needs to see if these rules negatively impact DIDs
… If they don't we should normatively state the WHATWG are the normalization rules we follow
markus_sabadello: Not looked at this in detail. But in the context of DID URL dereferencing. If we also have a path, query string on DID URLs in the same way as on http URLs. Then my intuition is we should use the WHATWG rules
<manu> https://
manu: This is the location in the spec the issue is concerned with.
<dmitriz> we COULD sidestep the normalization of service endpoints issue. and require fully qualified URLs
<dmitriz> or not say anything about it.
<dmitriz> (which would mean removing the normalization requirement)
manu: Web browsers URL normalization rules are different from the RFC3936 rules
… options are 1) remove it and not say anything about normalization. 2) Leave it as is and people have to do it, knowing the libraries they will likely use will do something different. 3) Or state that we use the WHATWG rules used by web browsers
… I don't have a strong feeling about the direction
ivan: removing the text is a problem for interoperability. We should not consider this
… I would see what is implemented in various programming environments
… As far as I know all of these use the WHATWG rules
<manu> +1 to what ivan said.
manu: I agree with ivan, lets look at the libraries and see what they do
… We should also generalize the spec text to say that any URLs should be normalized
… We will have to see what happens in specific DID URLs
… Unfortunately there are no tests/examples that show the differences between normalization rules
… We would also need our own tests against some fairly advanced DID URLs
decentralgabe: Lets continue this at TPAC
DID Resolution PR 88 / 89
Simplify dereferencing of the DID fragment based on the media type
Wip: I put this on the agenda. We talked about it last week. Should the primary resource be the DID Document? it says 'first you get the DID Document in resolution, then primary resource...'
<swcurran> +1 to WIP about primary document
markus_sabadello: agree, lets not have a big discussion about the naming of primary and secondary resource. I have been using the terms as introduced in original rfc3936
… PR 88 is an attempt to remove language related to processing the fragment. This depends on the media type
… Currently the text is specific to a JSONLD document. The intent of the PR is to simplify and remove this part
… regarding the discussion of primary and secondary resource lets have a special topic about it. It effects a lot of things
manu: Fine with 88 being merged. Agree there was confusion with primary and secondary resource. I also found the current spec text clear on that
… not blocking 88
decentralgabe: We will plan on a special topic call for 88 and 80 around this resource discussion
DID Resolution Issue/PR Processing
decentralgabe: Any specific PRs / Issues to discuss
w3c/did-resolution#49 Issue#48 fix Capitalization fix for DID spec
<markus_sabadello> https://
markus_sabadello: Closing the above issues after this call.
<markus_sabadello> w3c/
markus_sabadello: A couple of other issues I would like to mark pending close
… issue 29 about the term DID resolver being defined correctly
… I think this is addressed in the spec
<manu> +1 to closing this one
<Wip> +1 to closing
<markus_sabadello> w3c/
markus_sabadello: Also issue 30 that can be marked pending close. It is about dereferencing and whose responsibility it is
… The spec also addresses this
<manu> +1 to closing this one as well
markus_sabadello: I marked a couple of issues as good first issues. COntributions welcome.
https://
markus_sabadello: These issues are about the relationship between DID core and DID resolution
… It would be good to clarify this relationship in the spec with a couple of sentences
<manu> +1 to explaining relationships
good first issues -- https://github.com/w3c/did-resolution/issues/17, w3c/did-resolution#18
markus_sabadello: Explaining that DID resolution happens against DID core etc
… Anyone want to write about this?
decentralgabe: Be great to get these issues assigned
<smccown> I'm happy to write some text for 17 & 18
decentralgabe: Thanks for volunteering smccown
markus_sabadello: Quite a few issues are labelled enhancement to the did-resolution spec
… Important to figure out the fundamentals and get common understanding across the WG
… Would rather focus on these big fundamental topics
<manu> +1 to focus on big issues first
Kim: Did you mention the first DID method Wg
… We want to do a DID Method Wg kick off before TPAC
… This is an ad hoc meeting to settle some of the details for how the group will function
… I have more information here: https://
ivan: For the minutes, this is not a W3C Working Group
Kim: This is a DIF working group that includes a sharing agreement with the W3C. There is some followup work happening at TPAC to launch a W3C WG focused on DID Methods
… Idea would be to hand over work from the DIF Wg to the W3C Wg eventually
decentralgabe: There is a meeting on this at TPAC on the DID Method standardization
… Thanks all, see you next week at TPAC