Meeting minutes
Agenda
Wip: Today we will talk about TPAC, DID Path URL, Horizontal Review for DID Resolution... and some DID Resolution PRs
TPAC Attendance
<Wip> TPAC attendance spreadsheet https://
Wip: I put together a spreadsheet, we are about a month away...
Wip: Please let us know in this spreadsheet if you will be coming, please fill out the form.. We will only do one day, 1-Nov
Manu: Historically we combine agenda and spreadsheet into a single doc, maybe we can add another sheet in there?
Wip: Yes I can do that...
Wip: I will also send this by email to the group
DID URL Path Special Topic debrief
Wip: we had a productive call on the DID URL Path discussion, we decided that we are going to use the service array and have up to 3 different types...
<Zakim> manu, you wanted to agenda+ DID Method Extensions for a short bit to provide an update AFTER -- DID URL Path discussion.
Wip: The consensus was we need some standard mechanism defined by the did-resolution without breaking things like did linked resources and other similar legacy items... the idea is to have some convergence...
<Zakim> manu, you wanted to agenda+ DID Method Extensions for a short bit to provide an update AFTER -- DID URL Path discussion.
Wip: Swcurran agreed to do an initial PR with some suggestions...
Manu: Yes agree, can we also discuss did method extensions later?
Otto: we will have another call?
Wip: Not sure yet, to be decided.... unfortunately the did:cheqd team was not present and we would like to have their input and we will need to reach out to them
DID Method Extensions
<swcurran> 1 year backlog, actually,
Manu: Regarding the did methods, we had a large backlog of registration requests, we discussed how to handle this, since we need at least 2 reviews...
Manu: some proposals were put forward that we should shut it down... Over the weekened myself and Swcurran were able to clear the backlog....
Manu: I think the process can work as long as few of us share the load, and not have a single person doing reviews...
Swcurran: Wanted to say that one of the PRs perhaps scared away some of the other reviewers...
Manu: Yes we need to deal with that PR... it was disruptive to the process. The maintainers need to make a decision on it.
Wip: Yes the WG can decide here, agreed.
<ottomorac> +1
<manu> +1 to discussing the PR in the next WG call.
Horizontal Review Update
Wip: Just a status update, over the weekend we had the security and privacy review added by smccown, great thanks! ....
<Wip> w3c/
<Wip> w3c/
Wip: there was a response from security that is asking us to do some Treath Modeling
Manu: Yes that was my interpretation as well, I reached out to Simone to talk about it, he indicated he wanted a Threat Model. However I indicated we may not have time in this WG....
Manu: I think there is value to Threat Modeling, but not sure if folks have enough bandwidth for it at the moment...
Manu: Simone is suggesting perhaps as fallback, we might suggest some security considerations from an RFC that implementers could be required to respond to...
Manu: We need to make a decision here.... perhaps we discuss here and then reach out to Simone to try to agree on something...
Wip: Yes, also would be good to get JoeA's perspective on this one...
<Wip> w3c/
Wip: Also for the TAG we are now ready
Wip: I am not sure if it makes sense or not to have this "Design Goals and Rationale" section...
ottomorac: I'm trying to emulate other specs out there that had this explanation. There's always a relationship to other specs section. It need not be done this way, just seemed it was the sensible thing to do.
ottomorac: We're pressed for time, I'm open to moving us forward in whatever way works.
Wip: Yes, just concerned that the text from the other PRs doesn't fully address the Design Goals aspect...
Manu: We have this in other WGs, but not normally used for Horizontal Review....
Manu: I think we do need a "Design Goals and Rationale" section, the current content doesn't fully address it, but it is subset of what the TAG requires...
Manu: the PR seems useful, we need to figure out how incorporate it...
Manu: we might even retitle it to "Ecosystem Review" even....
Wip: Yes we can re-title and then add a separate issue to formally require design goals and rationale....
ottomorac: How explicit do we need to be about the text being for the TAG?
Wip: Or it could be called "Ecosystem Overview"
Manu: Yes, we don't need to write this for the TAG directly currently, maybe change the title...
Manu: The TAG wants just clarity on the usefulness of the spec
ottomorac: Ok, maybe ecosystem overview for now, change the title, then we can improve in future.
<Wip> w3c/
<Wip> w3c/
Wip: yes we can just change the title, and open a separate issue to add "Design Goals and Rationale".....
Wip: also please review these other PRs reviewed, I am keen to get this to the TAG
DID Resolution Test Suite
<Wip> https://
Wip: The progress is going ok, I currently have tests for section 4.
Wip: Would appreciate someone looking at it and giving feedback...
Wip: Currently we only have the DID Universal Resolver in there, we need other DID Resolvers....
Wip: I also need some feedback from Markus on a few items... Also the DIF Universal Resolver is not checking for ASCII strings, which is another concern...
Manu: Yes +1 on having a call to do a second pass at this. Thank you Will for the help here.... Digital Bazaar will submit a resolver in the future.
Manu: Just the fact that it works with a single resolver is the most difficult part....
markus_sabadello: yes thanks Will, getting this initial step done is the hardest...
now lets add more tests and more implementations.
Wip: Would it be better for me to submit a PR to get some reviews on other test cases?
Manu: Yes
DID Resolution PR Processing
Wip: we have 10 open PRs at the moment...
w3c/did-resolution#182
Make https binding mandatory #182
Wip: Yes the conformance classes needed to be added...
Wip: I thought we are adding a new conformance class remote DID resolver. This is a conforming DID resolver (existing conformance class) that implements HTTPS binding the resolve API. Makes me think we might need a remote DID URL dereferencer class also though.
markus_sabadello: Yes... in the spec we define local binding and remote binding...
maybe the conformance classes can directly reference those 2 terms...
Manu: Maybe we have a base "conformance class" and another "remote resolver" conformance class....
Examples of conformance classes: https://
Manu: The language I was expecting would be a little closer to what the VCALM spec is doing, by directly indicating which sections of the spec the class needs to align too...
Manu: perhaps we layer it using this base conformance class... and then the other
Wip: Yes I think we can just have "conforming did resolver" which includes the local... and then have the additional "remote resolver" class...
Manu: Yes agree with that....
So "remote resolver" would just be a class that also implements https binding...
markus_sabadello: Yes but https binding is not the only remote binding...
Manu: Then a conforming did-resolver is the one that implements section 11.1, or we just define a conforming "https did resolver"....
Wip: Do we also need 2 classes to for the DID URL de-referencer....
Manu: Perhaps not....
Manu: So let's keep base conformance class and add a single conformance class for "https did resolver"
w3c/did-resolution#204
Wip: any thoughts on this PR?
Wip: The goal from swcurran was to address that potential loop....
Manu: Yes I think this is ready to go...
markus_sabadello: I think it's fine, but perhaps needs to be moved to another section...
w3c/did-resolution#206
Wip: Yes so general call to the group we need to have at least 2 reviews...
<Wip> https://
Wip: This is simple PR just to address the issue.... any reactions?
Manu: This is RFC language, so need to clarify the SHOULD....
Manu: Perhaps just need to address the suggestion sentence, we need to be careful about how implementers would interpret, it might even be good for the "security considerations"
DID Resolution Issue Processing
Wip: We have 35 open issues, 11 have PRs, others are TAG related, and others are threat model related....
Manu: We need to identify which others are ready for PR.... by being clear what the PR should say and classifying the level of effort
Wip: Yes we need to decide which issues really need processing... I feel like most issues have been discussed at least once...
Wip: There are about 10 or so issues that really need discussion... again appreciate help with the PRs...
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment already there: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/