Meeting minutes
ottomorac: Today's agenda is we summarize the last Special Topic call, then we look at DID Core and DID Resolution PRs and issues
DID Rubric & Traits Special Topic Summary
ivan: By the time we have the next call, the whole suite of VC specs will be published as Recommendations. There will also be a press release. This also includes the CID spec on which we will have a normative dependency in the new DID Core spec.
ivan: Seven documents in one go! Just to show the amount of work that is behind it. Two of them are very big.
DID Rubric & Traits Special Topic Summary
ottomorac: Summary of Special Topic Call on 30-Apr: Agreed to have DID traits and DID Rubric combine. We continue the traits work at DIF, push to get 1.0 approval at the DIF Steering Committee. And in the meantime, start working on incorporation into the Rubric. The target for the 1.0 spec of DID traits is the middle of June. Minutes here:
https://
manu: Was there any discussion about integrating any of the DID Traits work into the DID Extensions Registry?
ottomorac: Yes there was a discussion on that. We need to figure out what that will look like. DID Traits are boolean, Rubric are more open-ended. But we did discuss this.
ivan: Administrative question.. Does it mean the Rubric document becomes a joint work between the two groups, with joint copyright or any formalism? Or will the DIF group simply release the document to this WG? I just want to make sure this is done cleanly.
ivan: My conversation was that it would be okay to donate or graduate this to W3C, and that there would be a process for that.
manu: I think you are right, the process would be that DIF would finalize the spec at DIF, publish the work, and then an agreement to allow W3C to re-use the content to incorporate it into one of our documents. We need to collaborate with DIF on the required paperwork.
manu: I don't think it will take a lot of work.
ivan: Fine, as long as everyone agrees and it's done properly.
<manu> yes, agreed -- it will be done according to process.
DID Core Issue Processing
<ottomorac> https://
Horizontal Review for DID v1.1 #885
<ottomorac> w3c/
manu: We discussed that we need to do horizontal reviews for DID Resolution and also new version of DID Core.
manu: Sharing my screen..
manu: For horizontal review, we need a few things. One is Explainer document, to explain what we do on a high level. We had created one six years ago that is fine, but probably needed an update.
manu: I created a new Explainer document, using ChatGPT's new research mode, based on the spec.
manu: I did go through the document and hand-edited every line and paragraph.
manu: One interesting thing was that the LLM did a really good job. This is "research mode". ChatGPT crunches for 45 min. It did a good job summarizing the sections, based on our latest specification.
manu: The Explainer is done. I suggest we try this for DID Resolution as well, unless the editors want to do it manually.
manu: I raised Horizontal Review with the Internationalization group, so there is an issue now on their tracker. It mentions that we're not changing much compared to what they reviewed before. We'd like a response before TPAC.
manu: The other review that was raised is for Accessibility.
manu: And I raised the TAG Design Review
manu: Haven't raised PING Review and Security Review yet.
manu: We don't have access to that Google doc anymore, need to find out who owns that Google doc and can give access.
manu: I'll wait a week or two to see if someone has access to that document, otherwise we'll recreate them from scratch.
ottomorac: Good job manu
821 - Ambiguity regarding PATH and DID URLs
manu: I'm wondering if we should ask TAG if they want an Explainer document, or if an Introduction section in the spe is sufficient. We can ask them are you sure this is the right process.
manu: It's extra work for the editors that could be used to process other things.
<ivan> +1
manu: This would be an opportunity to bring up that there might be a better way to do it.
821 - Ambiguity regarding PATH and DID URLs
<ottomorac> w3c/
ottomorac: This was discussed a few times, there was consensus in the group that this deserves a special topic call.
ivan: I remember there was a lot of discussion in the 1.0 work
ivan: I don't know how many DID methods exist now, is this a feature that is really used?
ivan: If it is not, we might think about simply removing it or deprecating.
manu: I don't think it's used broadly, but it's being used.
manu: I don't know if it's really pressing. I do think we wanted symmetry with how this works in HTTPS. I think it deserves a special topic call.
manu: We discussed having DIDs that point to e.g. pictures or writing or anything, and you wanted DIDs to refer to any of those things.
manu: We should probably try to have the discussion what's the right thing to do here.
markus: yes I dont know remember exactly what the issue was... there are did methods that use a path component... did methods that are web based mostly.....
AlexTweeddale: We have written a spec called DID Linked Resources, which defines how to use a DID as a directory, and have files associated through path or query patterns. We use this e.g. for schemas and trust registrires.
AlexTweeddale: Each file can be signed with the same key materials as in the "verificationMethod" sections
<ivan> thanks for that feedback indeed
manu: Great, +1 to that, this gives us something concrete to talk about. Let's have a special topic call. A number of us know this exists, so it would be useful to hear about details.
manu: We should discuss if the group agrees with this approach, and if there are any concerns or conflicts with specs.
AlexTweeddale: It would be a good time to have a call on this topic.
ottomorac: How about 21st May?
AlexTweeddale: No objections.
manu: +1
markus_sabadello: +1
884 - DID needs a proper vocabulary specification
<ottomorac> w3c/
ottomorac: We need a vocabulary for the DID spec, we are currently kind of borrowing it from the CID spec. The issue is connected to 137 which discusses if we should JSON or JSON-LD for DID resolution. Probably a vocab is required for both. Then Ivan generated a sample vocab file.
ivan: I will have to see with manu how exactly we put it in the repository. The rest I presume is the same as we did over there. These are things that can be done easily.
ivan: There was a discussion that we had on the DID Resolution side. It seems we have converged to the opinion that the DID Resolution can work without JSON-LD.
ivan: If DID Resolution does not use JSON-LD, then there are less dependencies.
ivan: This is w3c/
manu: ivan what you're saying we need to record the decision if DID Resolution will use JSON-LD or not.
manu: Then the only thing we need to discuss is the DID vocabulary.
manu: My recollection is that last time we talked about it, there were 1 or 2 terms we needed to define (service, serviceEndpoint)
ivan: That's right
manu: This makes it easier. We need a vocabulary and it will have these two terms in it. You and I can put this together.
Markus: Yes I have questions did resolution and JSON-LD.... but after this discussion I am fine that we dont need JSON LD resolution...
markus: when we say vocab, which are we talking about?
manu: markus_sabadello We would be generating a human-readable document that is the vocabulary, and it will have machine-readable equivalent to it. We would generate a JSON-LD file. We have done this before for VC data model, Bitstring status list, etc.
manu: We are having a discussion about requiring JSON-LD in DID resolution. Thank you markus_sabadello for the update on your opinion
manu: I'd like to ask if we want to make it optional. Every time we have the discussion, we want to make two communities happy about it. If we don't create a DID Resolution context, it would mean you couldn't use JSON-LD at all.
manu: So we could still give people the option to do JSON-LD processing. The downside is it would be a significant amount of work for us
manu: The strongest argument I see is to be able to sign a response, i.e. a trusted response.
manu: Counterargument is that you could still use signed responses using JCS
markus: Yes... I would be fine with either solution... making it optional also makes sense....
markus: I would maybe also add that we have seen some innovation when it comes to metadata and things that are added for did resolution metadata, such as the did linked resources mentioned earlier in this call by tweeddalex
ivan: Let's not get into a long philosophical debate.
ivan: Your argument that you could sign it, you also countered the same argument.
ivan: The reason why someone uses JSON-LD is because you want to take that piece of data, and you want to combine it with data from elsewhere, for a "greater purpose". You can pull together vocabularies from different places.
ivan: When we come to complex verifiable credentials, using JSON-LD for VCs makes a lot of sense. That's where JSON-LD is useful.
ivan: As long as it's a closed thing which is used in a focused way - which I think is the case with DID Resolution - then I don't see any reason why JSON-LD is useful.
ivan: Do we intend to mix DID Resolution Responses with other data? If the response is no, then I don't see any argument for using JSON-LD. Even using it optionally blurs the picture for me.
manu: I agree with that line of reasoning. To offer something that makes this easier, we can also start with a JSON-only approach and always add JSON-LD later.
manu: Adding extensions would be done in a "JSON-friendly" way.
<ivan> +1 to Manu on later
manu: We can start with no vocabulary or context for DID Resolution. And we can always add it later.
markus: yes fine with that.. would like to see some guidance on the media type....
manu: Would suggest application/did-resolution
manu: We have experienced that using + es can be complicated
manu: This will require a PR to make the change
844 - How to Understand the DID Identification
<ottomorac> w3c/
ottomorac: Language determined to be vague and no response since we discussed in December. Should we close it?
<manu> +1 to mark it pending close
<markus_sabadello> +1
DID Resolution PR Processing
<ottomorac> w3c/
<ottomorac> Migrate errors to use problem details #146
markus: yes its a pulll request from Will to update the error handling...
markus: I think the PR is good and I am happy with it... I made some small suggestions...
markus: also agree with alignment with CID spec....
DID Resolution Issue Processing
Disallow JSON-LD remote context retrieval #53EditNew issue
ottomorac: Should be a straightforward one? Remove retrieval should be a normative statement
markus_sabadello: This needs to be assigned to someone.
ottomorac: I can take this, as my first issue
markus_sabadello: This would be great!
ottomorac: We'll be in touch regarding the Special Topic call
ottomorac: Any other comments?
ottomorac: Thank you!
m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/