Meeting minutes
Agenda Review
Special Topic Call
wip: first announcement is about the special topic call for next Wed 21-May, special topic call focusing on the path and DID urls issue...
wip: we will have talk from Alex Tweedale about DID linked resources....
manu: Folks probably are already aware but the VC Data model and associated specs are now official W3C recommendations\
<manu> Official W3C Announcement is here: https://
manu: relevant for this group since the CID spec is now official... now that work is done we could discuss potentially moving that into this group....
<TallTed> fwiw, regrets for me for 5/21 and 5/22
manu: all data integrity is now official, so it also faciliates our work to build on top of them
<denkeni> @me: Congrats! And I’ve shared with our internal team earlier 🎉
manu: good news that the standards are now official....
wip: question around CID spec.... are we thinking of integrating now or wait until 1.0 ready?
manu: from a personal preference probably the sooner the better....
manu: there is some editorial work to do.... from this group it would also require a re-charter....
manu: probably we could coordinate the re-charting process....
wip: me and Otto should probably discuss this with Pierre....
TPAC Call for WG F2F Time
<Zakim> manu, you wanted to agree with the proposal.
wip: Alexandra has emailed us regarding the logistics for it.... My impression is we only need one day, and we would to avoid conflicting with did methods wg and others?
manu: yes agree... we probably want folks to not miss out on the did methods wg....
manu: trying to talk about the right order of the sessions, perhaps did methods wg first, and then the did wg later....
wip: everyone agree with this so I can email Alexandra back?
Horizontal Review
<Wip> w3c/
wip: As you know this is a high priority for us.... I have also submitted a few issues to the did resolution repo....
<Wip> w3c/
wip: any updates or things we want to discuss about this?
<manu> w3c/
manu: I did start with the horizontal review on 855.... TAG is already done with their part....
manu: they reviewed and there was some questions and then they specified they are satisfied....
manu: unfortunately the PING and Security review docs I am not able to retrieve from the last time....
manu: lesson learned is that it is to best put these docs in an issue tracker so we don't loose them....
manu: I used some AI to generate the explainer....
manu: the TAG noted that the explainer was AI generated.... they mainly looked on things that had changed....
manu: in the end they gave their ok....
manu: open question as to why the TAG required all this explainer....
manu: we can take a similar approach for the did resolution spec... probably using an LLM should be fine for the explainer....
wip: markus any thoughts on the horizontal review?
markus_sabadello: I haven't looked at it yet, but it sounds like a good idea... wondering when the right time is considering we still have plenty of open issues?
manu: it is probably ok to create it now....
wip: ok...
Relative DID URLs
w3c/did#880
wip: issue openned by Fabio Pinheiro...
wip: I am not sure if the spec needs changes...
markus_sabadello: I think we did address some of this in the did-resoultion spec, with the de-ferencing and others....
markus_sabadello: the did-resolution spec should reference the section where relative did urls are mentioned in did-core....
manu: yes agree.... one thing we could in did-core is to point to the part of the did-resolution spec that points to relative did urls
wip: ok....
DID Resolution PR Processing
<Wip> https://
wip: we have 4 open PRs... would be great to have additional reviews...
w3c/did-resolution#142
wip: this one is about adding examples and diagrams....
markus_sabadello: yes, I think this can be merged... but not sure if we need more reviews...
wip: yes I think it could be merged... maybe we give it one more week before merging?
w3c/did-resolution#143
wip: more diagrams.... I had commented on the heading titles... perhaps we can be more descriptive....
markus_sabadello: yes, I agree wondering if they should be headings or not....
wip: yes because the figure already describes the diagram....
<manu> +1 to not using headings and use figure anchors to link instead
wip: ok...
w3c/did-resolution#146
wip: I raised to migrate from error codes to problem details....
wip: it is large change, would appreciate reviews....
wip: errors are now moved into the resolution spec....
wip: there are errors that were already in the spec such as invalid public key and others....
wip: but I am not sure if those errors are still valid....
wip: they seem related to the time we did not use multikey...
manu: yes I think we should keep them in there....
manu: we want to keep them even if not every resolver throws this errors....
markus_sabadello: yeah I agree with Manu, we also had other suggestions....
markus_sabadello: certain error codes could be supported by some resolvers and not others.....
markus_sabadello: some of the error codes are specified in the algorithms...
wip: ok yes.... I was also not sure about the https binding....
wip: I should probably include some of the new error codes in there too...
markus_sabadello: yes if we add new error codes then we should include them in the https bindings.... it should also be fine if multiple errors map to the same https status codes....
wip: yes would appreciate a review.....
markus_sabadello: yes for example http status code 400 can map to several of the errors...
manu: yes I did find one thing that needs to be changed.... you have specified the security vocabulary.... we probably need some of these concepts into the did vocab....
manu: no need to wait until the vocab section is all defined...
manu: we would just need to request Ivan to create some new singleton properties...
w3c/did-resolution#147
wip: raised by Otto regarding remote contexts....
wip: also about caching....
<Wip> This is the issue - w3c/
markus_sabadello: Yeah I think the caching was mainly about the did document caching....
markus_sabadello: maybe we call it something else....
wip: where can we fit it then?
markus_sabadello: in security considerations but make its own entry...
ottomorac: agree with title of JSON-LD Context Integrity?
manu: yes I think it sounds good...
<manu> This is what we say about context integrity in the VC spec: https://
manu: want to make sure it aligns with VC spec wording as well...
manu: you may want to take a look at this....
manu: wondering if we should change the name of the caching property.... Dave Longley may have opinions on this....
manu: we should also probably mention that is an attack vector to turn off the cache....
manu: actually I will open a new issue about the caching...
Should we use JSON or JSON-LD for the resolution spec?
<Wip> w3c/
wip: wonder where we are on this...
manu: I think consensus was to use JSON for the responses....
manu: unusure about the resolution vocabulary part...
markus_sabadello: Yes i think I remember that was the agreement...
<Zakim> manu, you wanted to have an opinion about suffixes.
markus_sabadello: think the error codes should have any bearing on it...
manu: yes for the media type we should use a + sign
manu: plus signs create complexity....
manu: we should probably avoid those
manu: regarding the error codes having any bearing.... for now suggest we just put the error codes in the did vocab...
wip: any takers?
markus_sabadello: yes I will take it...
DID Resolution Issue Processing
w3c/did-resolution#22
Signing validation is not defined. #22
wip: the comment from markus is probably valid as a general summary..
markus_sabadello: yes we can still address this to add some comments....
markus_sabadello: this is also related to trust in resolution and how to check if the results from resolvers are valid.....
markus_sabadello: this will require a PR to add some language in the section about architectures or some other place.... this probably also related to Christopher Allens comments ....
w3c/did-resolution#18
<Wip> w3c/
Clarify the role of the DID Resolution spec relative to other DID specs #18
and
Is DID Resolution a layer defined on top of the DID layers? #17
smcown: not sure about the issues or request that Mike is making...
markus_sabadello: Yes I think it may be just a couple of small changes in the intro sections...
smcown: ok let me take a look for the next meeting....
manu: yes we should probably address this...
smcown: ok
wip: can probably close it one PR for both issues...
w3c/did-resolution#43
Handling DID resolution after a fork #43
wip: we labelled this a security.... how does a did method spec identify the VDR...
manu: feels like it is language that depends on the specific did mehtod... since it seems to address forks....
manu: we may not want to generalize forks....
markus_sabadello: yes agree, seems like the concept of networks, some did methods do not have that....
markus_sabadello: if at some point multiple did methods care about forks, some parameters or extensions could be added later...
Up Next: Test Suite
wip: we would like to talk about that next time.... have a great weekend!
<Wip> 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/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/