Meeting minutes
<Wip> https://
Agenda Review, Introductions (5 min)
wip: Just a few issues, but complicated. Resolution/dereference, DID URL Path Handling.
<Zakim> manu, you wanted to provide heads up on some DID issues and one PR.
wip: As chair concerned about the timeline -- Charter ends at end of April. Can get an extension, but would like to have DID Resolution in CR by end of April.
DID Core
manu: Some issues are on DID Core.
w3c/did#923
<manu> modify from something like `https://
manu: It was noted that you don't have categories for errors for DID Resolution. They were added, but a slight change is needed.
… Have to stay consistent with what we have done in the past with other specs. Please review -- ready to merge.
wip: Are you adding or removing the /.
manu: no trailing slash.
ivan: +1. Adminstrative -- don't know the person that did the PR? Seems to be an outsider -- all good but have to be careful on the handling of the IP for the PR. Need to declare that the PR is non-substantive, so extra step needed.
pachampin: Can you confirm it is non-substantive. Marked as non-substantive.
manu: There are some other issues that are questions and discussions and they have been responded to. An interesting one from Joe about query parameters. Will want to process these in a future call.
ivan: Back to the Errors PR. If DID moved to 1.1 do we have to worry about moving the vocab version?
manu: We can think about it and discuss at a future meeting.
manu: We don't want to version the URLs. The vocab we don't version, but we do lock it to a serialization of the vocab doc.
Drop HTTP binding for DID URL Dereferencing? \[1\] (10 min)
dmitri: Confirm -- terms no version, vocab, context versions.
<Wip> w3c/
JoeAndrieu: Looking at the language without changing the concepts. It requires returning a context stream, meaning you can't do it locally. The dereferencer handles the
… resource streaming. But if we had no endpoints just the algorithm and just saying here is what is returned. Then you have an easier thing to implement in different ways.
… It made sense at the time -- making it an HTTP bindings seemed like a good idea, but it makes things complicated.
<Zakim> manu, you wanted to support dropping it (we can add again later)
wip: Markus implementation does return resources.
manu: We're nearing the end of the charter, so we should drop this. Just define the algorithms. Does that open to objections that we don't have an implementation.
manu: If we cut all of that out, it can be added later, and doesn't break anything.
manu: Have you consider how we would test the algorithms?
JoeAndrieu: Tricky. The display is based on the mime-type which is hard to test. Defering the presentation rules to the mime-type. Hard to test.
manu: Return the document without processing the fragment and leave that to the target.
… if we don't know how to test the algorithms and so we should remove the algorithms.
wip: Removing seems nice given our timeline.
<Zakim> JoeAndrieu, you wanted to say not purge
wip: Do we remove the entire dereferencing section?
manu: no
<Zakim> manu, you wanted to note this is how we got in trouble for DID Core v1.0 :) -- but I won't stand in the way.
JoeAndrieu: We shouldn't remove it, we should just not refer to it as an HTTP binding.
manu: Sounds fine. But this is what raised objections with DID Core 1.0. We'll define a normative spec and not have a way to test it.
wip: Could test the dereferencing algorithms but using the resolution and have a separate dereferencer.
JoeAndrieu: The test suite can implement dereferencing algorithm. I think the objection was different and so would be less likely to be an issue.
<Zakim> manu, you wanted to note I don't know how to test/implement that.
ivan: Don't know the details, but the idea is to have an automated test suite that works the same for all parts of the spec. But not necessary to do it that way. Could have a human element in the test suite. There are other examples of that. There are ways to work around this and a human assessment in the middle -- that's the way there is.
manu: Big -1 on the human part. Pass once, change things, don't rerun. Can be done automatically.
manu: Bad spec writing.
<Zakim> JoeAndrieu, you wanted to say our job isn't to monitor compliance
JoeAndrieu: I think we can test this. Testing is not the software. We need to show that the spec can be executed. I think we can test that. Here is how you do it.
<manu> the test suite is only one implementation -- what's the other implementation?
<ottomorac> :-)
<manu> swcurran: Frustrating to be scribing right now, agree with Joe that we can test it. We should remove HTTP bindings and just say: This is what gets returned.
wip: Need to move on, but we need different implementations.
Inconsistent use of Resolution Update \[2\] (15 min)
<Wip> w3c/
wip: On the agenda for next week, need a concrete proposal.
JoeAndrieu: Comes from Jeffrey's review. Is there a small change to address the concern or is it much bigger.
JoeAndrieu: Best way to help is engage in the issue. It is not a short fix, and I will have a PR ready for next week.
<Wip> https://
wip: Are any of the 7 issues assigned to you encapsulated in the work you are doing on this?
… several seem to be,
JoeAndrieu: "query parameters" is not. We don't define DID parameters. DID Core does define a query parameter as a single value, vs. key pairs. Our definition in DID Core doesn't have that nuance.
manu: Put comment in the issue. RFC 3986 doesn't define key=value, WhatWG URL spec DOES define that clearly and what to do and all that. It is very clearly defined there.
… +1 that it is an issue.
<Wip> w3c/
wip: We have an issue to switch to WhatWG URL spec.
JoeAndrieu: We depend on something we don't define. We agree we should do it as in WhatWG, but we don't define it. Not solved today -- better to rely on spec.
<Wip> w3c/
JoeAndrieu: Query Normailization PR 301 might deal with this.
<bigbluehat> > However, as query components are often used to carry identifying information in the form of "key=value" pairs and one frequently used value is a reference to another URI, it is sometimes better for usability to avoid percent-encoding those characters.
manu: 301 does help for the issue raised. If we do use WhatWG URL in DID Resolution and not in DID Core we are making them incompatible. Major surgery in DID Core to switch to WhatWG URL spec to make sure everything is aligned. +1 to refering to what others have done.
<JoeAndrieu> +1 to starting shift to partial whatwg.
pachampin: We don't have to change to WhatWG URL -- we could just change the query parameter part to eliminate this issue?
<Wip> w3c/
<Zakim> manu, you wanted to note parsing rules for WHATWG URL are diffrent than URI
manu: That would be nice pchampin, but there are gnarly details and it would be difficult to get them aligned right.
DID Path PR \[3\] (25 min)
w3c/did-resolution#260
swcurran: Joe raised a number of objections to the latest PR... some I agree with, some I disagree. Last week we talked about a creating a concrete proposal for PathService out of algorithm and into PathService -- Joe didn't have time to do that, so I did that. Changed algorithm to include non-service objects and then remove the "how a path match is done" from the core algorithm to object definition.
swcurran: DID Linked Resources and Linked Resources both do the same approach, so does longest match, same algorithm as PathService, so neutralize wording to say "winning one" is the one that has the longest match. How matching is done is deferred to the object that you're looking at.
swcurran: I hope that helps w/ the backwards compatability issue. Remaining issues are:
swcurran: the post-retrieval verifiability attributes that DLR and LR includes (would like to make that easily extensible)... requires every resource to be in the DID Doc... not every resource needs to be in DID Document.
swcurran: next one is "what does dereferencing do?" -- DID URL Dereferencing returns a resource... some DID Methods there is no other place than the VDR where the resource exists (no URL for it).
JoeAndrieu: Thanks for the productive engagement, there are those two things left to figure out -- data integrity check, embed resource within resource itself.
JoeAndrieu: There are many reasons to link from onchain record to resource, wanted to be as flexible as possible, there are resources (like Bitcoin ordinals, data is on chain), the only URL we have for that resource would be a DID that is designed to get a resource back out -- somehow, algorithm has to return the resource. Steven and I are starting to align -- my concern is timeframe to tease out additional features.
Wip: I also have concerns about time frame.
manu: I don't know how to best help here
manu: can we remove some of these decisions to make things easier?
manu: We may not need to standardize some aspects necessarily
manu: we should try to get to a got enough 1.0 version. I understand both sides, and it seems we need to address this now
Wip: There is one option where this becomes an extension -- why is it not ok to be an extension?
Wip: There is one option where this could become an extension. Would that be bad?
<Zakim> JoeAndrieu, you wanted to me its about not elevating one approach over another
Wip: There are pieces and threads you have to follow... it's complicated.
JoeAndrieu: the challenge with the choices we have... we could do the path service as an extension...
JoeAndrieu: The two choices we have after we've distilled -- we could do PathService as an extension, that doesn't address issue 150 about multiple properties in DID Document in unpredictable way -- if multiple properties - we can clarify what risk is and PathService could be an extension (lesser option).
JoeAndrieu: Better goal, Manu, Stephen, and I, want to try to figure this out -- how do we do this so there aren't conflicts.
<swcurran> +1 to Joe's comment.
manu: ok great to hear....
manu: we could make it an extension, but it's not great
manu: where is the conflict however?
manu: the suggestion is we have is not super clean, but these proposals should work
swcurran: my challenge with that is, I don't know how to put that. the wording makes it kind of weird. And waters down the usefulness of the change.
swcurran: My challenge with that approach was that I don't know where to put that -- ignore rest if you want to ... that was my problem as I looked at it (yes, we could do that) -- I think it greatly waters down for reasons that aren't good -- would rather see it done better.
swcurran: It is challenging bieng caught between Joe's idea and Markus' idea.
<Zakim> JoeAndrieu, you wanted to the missing piece is moving forward
Wip: Hearing there is will to do the work, problem is time.
JoeAndrieu: I don't know if there is a way for a spec to say they're a path algorithm -- fits into path part -- we don't want properties that implement path algorithm by modifying properties. Right now, anyone can add property tomorrow -- so we're early days on features. We have extensibility point that is uncontrolled, how do we resolve that w/o elevating any one approach.
manu: ok. That is just a matter of us trying to find the right language for the spec....
manu: when an implementation knows either of these path algorithms, it should be aware of the choice it is making
<JoeAndrieu> +1 to error
manu: or if you have a conflict, then it should be aware of that potential issue
Wip: should we have a special topic call?
Wip: We could have a special topic call, but don't want to put more time on calendars if it doesn't help.
swcurran: You should take a look at latest wording, maybe it's there... what I tried to do, Joe pushed back a bit, if there is a path handling mechanism, it should be included in the check. If there is a LR, DLR, or PS, it should be considered... if there are multiple used, then it errors... that's what should be there today.
manu: if that's there, it addresses the problem. :)
Wip: Let's continue to try to work on this.
YAY!!!
ottomorac: We will have a different Zoom link for next week, we will test transcription service -- just a heads up -- use a different zoom link... parallel IRC transcription channel.