Meeting minutes
pchampin: I was contacted by some people that have a pending PR on DID Extensions
… and I realize that there's a few pending PRs there; I completely appreciate that this is an additional burden and that this group has been concentrating on specs etc
… I just told them I'd bring it up on a call, just so it's on the radar
Wip: same (also had it brought to attention). It raises the challenge that this group does not have enough resources to manage that list / registry
… I replied that we had volunteers (who have gone quiet). I can't even do it, since I'm not on the list
… so the question is - what happens when the working group does not have the resources. and what happens when the WG is disbanded / expires
… also has to do with the perception that people have that being on that registry makes it a 'valid did method'
manu: yeah, it's always been a problem. it's usually me processing it, and I just dont' have time
… we have like 12 volunteers theoretically
… I mean, Will, if you want to be added to the list, we can certainly do that
… the only way we can make this work is if we have volunteers
… because it's a constant drumbeat of new did methods. and the challenge is the folks that don't do it right, so there's a lot of education and back-and-forth
… what we can do is -- whoever complains, we can focus on their one, etc
… that's usually how it works
… the other option is, maybe, something that an AI bot can help process? (judge on whether a PR meets the rules criteria)
… and another option is -- we just merge everything. which we did not like as a concept, before
… soo, I think we're just stuck with the registry. we don't want to drop it on the floor
… so this dragging out / slow processing is better than nothing
ottomorac: I'd also like to be added
pchampin: will's question about the registry after the WG lifetime -- this is a Notes document
… if it was an official W3C Registry, that'd be a different process
… so Notes wise, the W3C Team maintains it (which doesn't help)
… we have a precedent of a CG volunteering to maintain WG Notes after the WG expires
… so if we think that it might help, maybe we can have something similar here
… find a CG to volunteer to curate the DID Extensions / DID Registry
swcurran: just as a matter of interest -- is there a definition of the minimum amount of info necessary for a PR?
… I assume the main problem is that one PR that has like 20 methods
… has that one been dealt with?
… the others look like single DID methods that follow the intent / spirit of the registry
JoeAndrieu: I want to be a voice for getting rid of the registry entirely
… we had this problem from the beginning, and will continue to.
… we have consensus as a group that we should enforce conformance. but it's a pretty major burden
… identical DID methods (in a single PR) is within the rules
… we also agreed, and had some consensus, that we should make it an official W3C Registry
… so that's another option. (though we've failed at that)
… I want to put forward the question -- what do we think the registry is doing?
… the registry is not going to resolve security & privacy concerns. so then, what's it for
ottomorac: yeah, and maybe something self-service?
manu: for pchampin's comment -- who maintains the registry is just shuffling around the chairs on the deck of a sinking ship
… doesn't matter if it's CCG or W3C staff, still the same core issue of - work is not being done, reviewers are not reviewing
… and the issue is not necessarily with someone jamming 20 DID Methods in a single PR. the issue is more -- people are not reading/listening / doing the basic thing in PRs
… basically, people not paying attention. and having to review and re-review is really burdensome
… I don't want to get rid of the registry yet, but I'm open to what Joe is suggesting
… if there was some way to just list the methods without having a bad actor come in and DDOS the registry
… if we can figure that out, we could get to self-service
… I also don't want to spend time on this in the WG, we have way more important stuff to work on
<Zakim> JoeAndrieu, you wanted to say we don't know the number of DID methods
manu: also, I don't want to just come up with another plan that falls on the same people's lap
JoeAndrieu: manu, we will never know how many DID methods are there
manu: it's not a count, just that some people want there to be a list
JoeAndrieu: that's centralization though; why do _we_ want there to be a list?
… sometimes it's a monetization thing
… what's the value prop for us?
manu: I have lots of thoughts on this. but I don't this is a good use of WG time
JoeAndrieu: hey, if we get rid of the registry, then people won't have to send Pierre emails. it's like fly-paper ...
Wip: yeah, we could debate this, but probably not a good use of our time today
… maybe after horizontal review
ottomorac: I'll open an issue about this to keep it on our radar
Horizontal Review
<ottomorac> w3c/
Wip: I just want to have this on the calendar as a touchpoint - where are we with the review
<Wip> https://
Wip: I think we're in a good state, if you have a look at the PRs
… lets spend some time on that, and also talk about the SING (?) review
ottomorac: let's start with Manu's PR?
<ottomorac> w3c/
Wip: we just need some more reviews on these PRs
manu: yeah, not much to say about #199
… if TAG needs us to say more than that, they can tell us
<ottomorac> w3c/
manu: the PR would close 3 of our horiz rev issues
ottomorac: the other one is #187
… I used some AI summary to help answer that question
… mentioned the testing suite
… do people have any comments on this?
Wip: why don't we open this is a PR?
ottomorac: that section, the Relationship to Other Specs -- hasn't been merged into the main branch
… so I wasn't sure if I should branch off of Manu's PR
Wip: ah, so you think this is going to be a subsection to the Relationship to Other Specs section?
ottomorac: I was confused about Manu's PR
<ottomorac> - Add a "Design Goals and Rationale" 1.1 section before Conformance (this section will incorporate the changes required for issues 185, 187-189)- Add a "Relationship to Other Specifications" (New Appendix "C") (this section will incorporate changes required for issue 186)
ottomorac: I asked about doing these 2 sections. which was, Design Goals and Rationale
… and the Relationship one which would be an appendix under pr 186?
Wip: my recommendation is -- just put it in a PR wherever you think it goes. and we can reconcile it later
ottomorac: I'll open an PR, no prob
… anything else?
w3c/did-resolution#191
Wip: 191 - maybe I can ask Markus or Steve
… it's about filling out & addressing the Security & Privacy self-review
… this is the last review that we need to get in, then we can request horizontal reviews
… so, either Steve or Markus --
smccown: when is it due by?
WIp: soon as possible
smccown: ok, I'll work on it this afternoon
Wip: thanks
DID Resolution Test Suite
<ottomorac> w3c-ccg/
Wip: I am making some progress. is there anyone willing to volunteer to help?
… I don't think we need a full on special topic call. I just need someone to sit with me, look at the code, talk through it
… one of the issues I have at the moment is - in the Resolution spec -- a lot of the properties are optional
… and "If it is defined, it MUST be like this...". I don't know the best way to test that
… so, would be great to have another pair of eyes on this
<Wip> https://
Wip: also the DID Resolution Algorithm. a lot of it is -- you need visibility inside the resolver
… there's a lot of statements that are hard/impossible to test
… so, we don't need to discuss it on the call right now, but I need help
ottomorac: anyone have thoughts / volunteers?
markus_sabadello: wrt optional features -- isn't that something we also had to solve in other suites? VC-API etc?
… maybe put it into the config of the implementation, etc?
… the test suite should be able to test those things, conditionally, if supported in the impl config
WIp: maybe yeah
ottomorac: ok, let's just keep in mind, that we need somebody to help out here
DID Resolution Internationalization Issues
<ottomorac> https://
Define timestamp format carefully #203
<ottomorac> w3c/
ottomorac: this is about the timestamp format, etc...
… something about normalizing to UTC
WIp: I don't have many opinions on many of these i18n issues
… but we just need to address them for horiz review
… like, how do we even define the operation of normalizing to UTC?
<manu> https://
manu: we do have responses, like the one from VC DM, we should just point to that
… definitely not copy paste (it's too much text), but rerference
Wip: so we can just say 'as defined by VC DM'?
manu: danger here is pulling in a normative dependency on VC DM, which we don't want to do
… but there aren't normative statements in that section. so it wouldn't be a straight up dependency
… yeah, we should just point to this section
ottomorac: any volunteers?
WIp: I don't know if I want to do a PR, but I could write a comment -- do we have a section that you can reference, see what they say
… this seems like it has been solved by other specs
Use character reference notation and Unicode names for references to specific characters #202
<ottomorac> w3c/
ottomorac: seems a bit more editorial?
<pchampin> looks editorial to me
<manu> yep, editorial
ottomorac: if it's ok with you, I'll just assign it
… to Markus
relativeRef should prefer UTF-8 for percent encoding #201
ottomorac: next one is our dear friend Relative Ref
<ottomorac> w3c/
ottomorac: I don't know whether this is a discussion for next week (Weds)
… what do you think Will?
Wip: reading...
manu: Addison us usually right about this stuff. I think it's separate, unless we get rid of relativeRef, which I don't think we're likely to
… so, he's right that we should prefer UTF8 for percent encoding
Wip: the change we need to make is - somebody needs to make a PR stating that we prefer UTF8, yeah?
ottomorac: I can take that on, if it's just the clarification
manu: just to be clear, this is a MUST. if we want to help interop
… you MUST encode disallowed URL chars using UTF8
ottomorac: ok, so just make it a must statement
JoeAndrieu: we should make it clear that this is for ALL URL params, not just relativeRef
ottomorac: ok
<manu> +1 to what Joe said
DID parameters require ASCII-only #200
<ottomorac> w3c/
ottomorac: so, this is another one, discussing various parameters here
… requirement that the value be an ASCII string...
… some other references to an RFC
JoeAndrieu: this seems directly entangled in the other one. shouldn't it be UTF8 and not ASCII?
ottomorac: yeah...
manu: yeah, I agree with Joe -- the nuance here is -- we DID say ASCII on purpose originally
… but Addison is right unfortunately, we can't ignore that part of the world, non-US/Latin characters that billions people use, etc
… so yeah, it's entangled w UTF8, so we'll just have to clarify
… like, IF you have non-ASCII character, you MUST use UTF8 encoding. and percent-encode it to ASCII
Wip: (confirming he heard Manu correctly)
Wip: ok, so, somebody just needs to define that process somewhere
manu: yeah, we should just say - this is a statement around encoding/decoding parameters. All parameters need to go through this process
… you start w an input string, ensure it's encoded as UTF8, then you percent-encode THAT value to get to an encoded param
… to decode a parameter, you percent-decode it and arrive at a UTF8 string.
bigbluehat: yeah, there's a couple of RFCs related to this
… that have a fallback to ASCII / related functions
<ottomorac> a couple RFC's have some stuff about this https://
bigbluehat: and discussion of footguns
… encoding UTF8 URLs has been around for decades etc
ottomorac: ok, yeah, so that's connected to that other issue
… I'll try my hand at it
manu: I agree w bigbluehat that we need to reference an existing RFC, but specifically, we don't want to use Punycoding (that's for domain names only, not URL fragments)
<ottomorac> Ask Addison what should we ref for this
DID Resolution PR Processing
<ottomorac> https://
Security Consideration -- DID Resolver Clients should detect resolution cycles #204
<ottomorac> w3c/
<ottomorac> PR from Stephen Curran regarding the issue with the infinite loop DID resolution cycles.
swcurran: this isn't an issue for a DID Resolver, because it doesn't expand references, it just returns the DID Doc
… so this is for CLIENTS of a DID Resolver
… _that's_ where cycles can occur
… I did decide to put it in security consideration sections
… so, it's a short one - if you're a client of a resolver, and if you do repeated resolutions
… you may wind up in a cycle
… and should take steps to mitigate
<manu> I have no objections for it going into a security considerations section -- doesn't a DID Resolver do this, though?
manu: I thought we had some algorithm in the spec where the DID Resolver does it too?
swcurran: I didn't see one
manu: ok that's fine then
JoeAndrieu: I think there may be.. didn't we parametrize in the resolution request to de-reference it on the resolver level? that might run into this problem
<manu> My recollection is the same as Joe's
JoeAndrieu: otherwise, I agree with your analysis
… unless resolver has to do it, it's the client's problem
swcurran: I'll take another look
Define HTTP POST binding #196
<ottomorac> w3c/
ottomorac: Will has provided approval, but it would be great if other folks also reviewed
<Wip> w3c/
Wip: this isn't about this PR, but just briefly -
… maybe this 'no cache allowed' is a 'feature not supported'?
manu: wait, I'm confused
<Wip> w3c/
Wip: sorry, this is about PR 183
ottomorac: I think Will was saying that instead of having a 'No-cache disallowed' error, we make it more generic, use the 'feature not supported' error instead
manu: yeah, I think that would be fine
… as long as we have a description of what the missing feature is