Meeting minutes
DID Method Charter Discussion
Wip: Welcome to the call today we will be mostly focused on DID Resolution..... but first lets talk about the DID Methods WG charter...
Manu: The last time we checked, the charter was ready to be sent out... wondering what is the status, and if we are ready to send this to members for voting? Just mindful TPAC is coming up...
Wip: I thought we were going to have day in TPAC for this?
<Wip> Can see the current meetings here: https://
pchampin: I was waiting on the green light from you all, we do need a horizontal review on the charter, I am happy to help facilitate that...
<Zakim> manu, you wanted to say "green light!" :)
pchampin: I think the idea is to try to have a meeting on this for TPAC, depending on if we get any objections or not
Manu: Yes green light, let's move forward.
JoeAndrieu: I do expect to formally object....
Manu: I understand Joe, I was hoping this could be avoided, but ok let's move forward with the process. We can have the council review and during TPAC we can decide how to handle it.
swcurran: Can we move this to IETF or some other way to expedite it?
Manu: Unfortunately no, we have to go through the process....
<Zakim> bigbluehat, you wanted to ask Joe what his alternative proposal is
bigbluehat: I want to hear a brief summary from Joe about what the objection is and what the suggested alternative would be....
JoeAndrieu: I have 2 positions, first one we should not have a single wg....
JoeAndrieu: Also did:web and its derivatives should take over the CID spec...
DID Resolution PRs
<Wip> https://
w3c/did-resolution#171
Wip: ok now to review the PRs...
Wip: I think this one is good to go, want to give folks one final chance to review...
markus_sabadello: yes I think this can be merged....
w3c/did-resolution#175
Wip: yes would appreciate reviews...
Wip: This one is for the Open API Definition
markus_sabadello: Yes this adds a few more details to the OpenAPI definition, especially metadata fields such as "created", "updated", and resolution options such as "versionId", "versionTime".
markus_sabadello: And this is a non-normative change...
w3c/did-resolution#176
Wip: This one changes the RFC referenced in the spec...
markus_sabadello: Yes it is the reference to the RFC for the HTTP semantics, so just updating those references.... the issue was originally opened by a W3C bot that detects obsolete RFCS...
w3c/did-resolution#178
Wip: This one improves the method architectures...
markus_sabadello: Yes would like to discuss this one together with 179...
markus_sabadello: This tackles the did method architectures discussion...
markus_sabadello: We are addressing some of the open issues regarding how to trust did resolution...
markus_sabadello: I hope the changes reflect a move in the right direction... it is important to note that these PRs add a proof property if the metadata and resolution sections...
markus_sabadello: so that these proofs can be verified by resolver...
Wip: would be great to get some reviews on this one...
JoeAndrieu: I had not seen a new type of class on line 175...
JoeAndrieu: I think its not clear if these are normative or not, "advisements"
Manu: typically "advisements" are strongly worded suggestions...
Manu: however this looks more like something that should be a note and not an "advisement"...
markus_sabadello: Thanks for clarifying, I did think about just making it a note.... however I felt they should a little more weight....
markus_sabadello: I am fine with making it a note if required...
Manu: Also wondering if these should be a security consideration since it talks about how to handle did resolution results...
Manu: since the validation of the proofs is a security concern...
Wip: Yes I agree...
markus_sabadello: Yes that sounds good, yes I did think that some of the contents should be part of the security considerations..
markus_sabadello: I will try to split this up...
Support numbers in metadata structure
<Wip> w3c/
Manu: Yes we discussed this in one of the data integrity calls, our decision was to recommend to this group that we allow numbers....
Manu: And then in the Data Integrity spec we would add a security consideration to manage the floating point consideration and how to manage certain types of numbers...
Manu: Secondly, I would like to potentially throw errors, JSON-LD silently handles errors... but this might be handled with a "safe mode" for JSON-LD such that errors are thrown for some types of numbers....
Manu: this should manage how certain numbers are serialized, devs need to be careful with this...
Wip: Yes we need to be clear on what aspects of this affect the DID resolution spec...
swcurran: One thing that I did not hear, was that the advise on how to stringfy these complex numbers...
manu: yes agree, we could also have that as an option, however this changes the input data in a way that the developer may not expect....
manu: This may cause certain issues, and we need to clarify those. This should be discussed in the verifiable credential wg...
Wip: ok seems like we have a direction but then how do we forward?
manu: the change in the did resolution spec should be small and just point to the Data Integrity spec....
swcurran: Yes but the did resolution spec should be changed to add support for numbers...
swcurran: This might make developers cranky...
Wip: Ok so sounds like a PR, any takers?
swcurran: I will give this a try
HTTP Post method binding
<Wip> w3c/
markus_sabadello: Yes to summarize, and the moment we have a GET binding option, but this has challenges related to the lenght (if you use a lot of resolution options), and secondly the resolution options could also be nested, resulting in complex params that are not clear how to manage...
markus_sabadello: So the idea was to use an option for POST
manu: Yes this is complex one, we could also indicated how to manage the nested stuff by adding some base64 encoding.... or we just keep it simple and limit how many options can be added in the GET call....
manu: The third option would be just to keep it very simple and limit it to just the did parameter with no additional options and force the usage of POST for everything else....
manu: I would think that for simplicity that perhaps drop GET and support POST only...
bigbluehat: I think the strongest use case for GET would be HTML and SVG resources referenced in a did
<Zakim> manu, you wanted to note that's not resolution, that's dereferencing.
<manu> This would be a useful thing to be able to do in time: <img src="did:foo:123456/bar/baz.png">
manu: this is an example of pointing to an image with a did that can jump to other resources...
manu: however I don't think we need GET for this particular feature...
<Zakim> manu, you wanted to note that we might not want them to work that way.
markus_sabadello: Is this related to the service and relative reference?
<manu> This would be a useful thing to be able to do in time: <img src="did:foo:123456:/bar/baz.png">
<manu> is equivalent to this: <img src="did:foo:123456?service=agent&relativeRef=/bar/baz.png">
manu: Yes, me and Markus have talked about this... this syntax would be effectively a relative ref...
<Zakim> bigbluehat, you wanted to ask about caching
manu: I think both would be the same.... and I think ben this should also work for caching hopefully...
bigbluehat: I think also about how the https resolvers would manage this...
manu: I was presumming that a DID resolver client would do the caching internally...
Wip: Yes this has been a good discusion.. not hearing any opposition to removing GET and supporting POST only...
manu: Question do the group, can we just do POST to keep it simple?
<swcurran> +1
markus_sabadello: the problem is that some production deployments currently use GET and it would break a few things
bigbluehat: I think we should support both...
<Zakim> manu, you wanted to note that just because you do optional features, doesn't mean you're non-conformant. and to note that bigbluehat's reason is convincing to me to have both.
manu: Yes I think that is a compelling reason, but there is complexity. However also just because you do optional features, doesn't mean you're non-conformant
manu: The question is one which one would be mandatory to implement?
<manu> yep, they need to do both :( -- which means that all those other resolvers are going to be non-conformant.
bigbluehat: I think the poster of the issue was originally focused on the long GET strings....
bigbluehat: we need to think about this carefully...
bigbluehat: the code requirements may not be extreme if the URLS are "neighbourly"
Wip: seems like we do have some direction... but then who can take on this work to define it?
Wip: Ok we can leave it here for now...
<pchampin> btw, regrets for next week from me