Meeting minutes
Agenda Review, Introductions (5 min)
ottomorac: today we have one issue we want to pick up again
… mainly wanting to hear from Marcus
… we also have some issues related to the TAG review
… we've also got some PR processing on DID resolution
… and if time, there are some other issues we can look at
… given we haven't met in awhile, does anyone have other items?
… k. onward
DID URL Derefencing and Fragments: The role of a DID Resolver (5 min)
<ottomorac> w3c/
<ottomorac> Previous discussion about where DID Resolution ends, but also talk about dereferencing that a client could do.
ottomorac: there was a previous discussion where Steven was mentioning where DID Resolution ends
… and what dereferencing would mean for a client
… we also had a pending item around whether Marcus could give us some insights
… but he'd need to be added as an invited expert...and we'll need PA for that
swcurran: I think it comes down to a couple things
… a) fragments is post-dereferencing
… there's a good bit in the spec about that, but it should likely be kept out of it
… other than to say, the client will use it to find the relevant DID doc
… b) I'd been making the assumption that once a path was found that it would be resolved
… which it actually may not...
… once I got into it, I found you could return an array of service endpionts
… that the endpoints would be treated as an API definition
… and you could use what you needed from that array
… but with the path, we're talking about referencing something more specific
… and singular, and I assumed it would return the resource not only it's path
… but I think we only need to return the path
… Marcus' remaining objective seems to be around when the query parameters are applied
… on the initial request? or on the subsequent resource path
manu: I agree that's where we are
… I think we mainly need to see some PRs
swcurran: I'd assume that a DID resolver would "know" which query params would apply to the resolution process
<ottomorac> last comment from Markus is this: w3c/
<ottomorac> (in case people are wandering)
swcurran: and that could leave other query params to be applied to the resulting path
… but Marcus stated that (very reasonably) would be very confusing
… because you could get anything passed in as a query param and how do you know when and where to apply it?
… his suggestion was to encode ones intended for the DID into another parameter
… to make it clear which ones apply at which step
… and make it explicit which ones apply post-resolution
manu: no objection if we go that route
… an alternative might be that the resolver just uses what it knows and leaves the rest
… but I agree there's no way to know which will be used where
… the upside is that we can avoid the weird encoding thing
… the hard thing is that it's hard to know where and when the query params would be applied
… whereas with the encoded approach the resolvers could be more explicit about what they accept
<Zakim> JoeAndrieu, you wanted to say I think the resolver does know, if it handles the method. So the resolver gets everything. As @manu said.
manu: vs. never knowing what will be used when/where
JoeAndrieu: so...I see it differently
… my understanding is that the parameters stay with it throughout
… and that they continue to cascade down to other requests
… it's true the caller may not know
bigbluehat: CMS and Login flows often do this type of parameter double encoding
bigbluehat: a "destination" or "intention" parameter is added in these types of flows
bigbluehat: it doesn't look pretty but its clear about how it works
bigbluehat: we need to be clear about parameter naming to avoid issues
manu: I'm coming around to Marcus's approach which I thing bigbluehat just said he supports
… the double encoded parameter
… JoeAndrieu you touched on my concern at the end of what you said
… I'm concerned about a resolver silently passing things down that it doesn't know
… and would prefer the resolver complaining up front if/when it doesn't know what the parameter means
<Zakim> JoeAndrieu, you wanted to oppose encoding everything
manu: coupled with the encoded parameter passing, I think we have a nice clean approach
JoeAndrieu: so...this is a radically breaking change
… and I think it's a bad idea
… right now we have resolution params
… and I'm not seeing a security concern strong enough to break how we do things now
swcurran: so, one thing might be to only do that encoding approach when a path is provided
… another would be that the resolver would return the path + whatever params remain
… so the resolver handles what it knows and puts the rest on the path
… I don't think we'd want it to be rejected on params it didn't know
manu: we don't yet have a rec, so I think breaking changes are OK at this point
… it is a security concern to not throw an error if it's just going to silently ignore params
… do we have other implementations besides the universal resolver?
… we have other implementations, but not ones that use this feature
bigbluehat: if these are query parameters that go along with the path, would we just not encode them with the path?
<Zakim> JoeAndrieu, you wanted to say if there are features that MUST be supported, then they must be supported. Everything else is a extensibility point. and there are implementations
JoeAndrieu: yeah, I think this would have ramifications on DID Core and stuff in the wild
… unless that feature is required
… if it's not, then it's a point of extensibility
… or if it's part of some extension about dereferencing
… like version ID could be required...I don't think it is right now
… and I think there are issues if your resolver is being forced to make decisions about things it doesn't yet know about
Wip: I do see the issues around version ID when the used in situations where the resolver doesn't know
… the conversation is great, but I am concerned about the time
… maybe a special call on this one?
… because we're on a bit of a time crunch for the group in general
… ottomorac not sure what you want to do, but I'd suggest we move on and arrange a special topic call for this one
ottomorac: swcurran and manu can have the last word, and then can arrange a special call
swcurran: the reason they're split is that there are two different resolution steps
… so, maybe we encode the resource ones and not the resolution ones
… and that should avoid concerns that JoeAndrieu raised
manu: all of this is optional per the spec--I just checked
… I'll leave it that I think it's a security issue and am really concerned about this
… I won't stand in the way, but I think it's risky when versions are or are not checked for
swcurran: what I was trying to do, was to define requirements be defined
manu: they're not right now
swcurran: yeah, the proposal is that we define them to fix that
… and then we allow a space for arbitrary parameters
… I don't think we can say we don't have them
… HTTP allows this, you can pass in whatever but the server decides
manu: I'll note I'll work through this more, but I'll likely oppose it
… swcurran is suggesting we add requirements
… JoeAndrieu's opposing it
… so there seems to be miscommunication
ottomorac: swcurran can you bring a suggestion?
<smccown> IMO, all versions should be checked. If versions operate slightly differently, then Manu is correct that unforeseen security problems could arise.
swcurran: happy to, but I think manu is talking about something else
manu: agreed
swcurran: yeah...I think there are a few different conversations here
… I'll write up what I'm proposing on that PR
TAG DID Resolution Issues \[2\] (10 min)
ottomorac: we have a few items that have been assigned
JennieM: I'll get a PR in for mine today
ottomorac: there's one for me also
… which is relating to exporting terms which I'll resolve soon
<ottomorac> w3c/
ottomorac: JoeAndrieu if you could help us out with 228, that'd be great
Wip: I think the reason we have this on the agenda is to confirm things are happening
… if you can't do them, please let us know
… we mainly just want to get them resolved so we can move onto the next stage
… these are the last remaining issues
ottomorac: any concern from folks? feel free to raise it now
DID Resolution PR Processing \[3\] (20 min)
ottomorac: k. moving on
… we have several PRs waiting to be merged
<ottomorac> PRs to be merged:
<ottomorac> w3c/
<ottomorac> w3c/
<ottomorac> w3c/
ottomorac: unless anyone opposes, this is what we plan to merge
… unless there are any oppositions
… they'll be merged soon
… there are some others we'd like to deep dive into a bit more
manu: I think 262 is also ready to go
… and Wip I think you're correct on 268 about trailing spaces
Wip: maybe that is true, but I did have a look at that history
… and tried to find the commits that put them back in
manu: I'm confused as well because that should have taken those out
… but the file diff still has them
… it's tangling merges up a good bit
ottomorac: I'll check my settings
I posted a link to the editor config that you could use
so that you don't have to deal with that on the local editor
<ottomorac> sutopic: w3c/
<ottomorac> Define generic datetime format for DID resolution and use throughout spec #248
ottomorac: defining a generic date/time format for did resolution
Wip: I'd appreciate some review on this
… I have referenced the VCDM
… and this is an I18N issue
… but this is a pretty significant addition, so I'd like some review
manu: this looks good at a high level
… I'm concerned about sub-second stuff
… the VCDM has normalization stuff
manu: mainly I was concerned we were changing stuff from VCDM
Wip: maybe you can take a look, but I don't think we are
ottomorac: reviews appreciated
w3c/did-resolution#255
ottomorac: this one also from Wip
… adds an intro section to the privacy and security section
… and dmitriz reacted to it, but one more review here would be helpful
Wip: I'd really like to see more PR reviews happening
… I really don't want to merge PRs without reviews
… thanks dmitriz for approving this
… but from just one person, is that sufficient? it just happened yesterday
manu: I think the purely editorial stuff can be merged right away by editors--per process
… substantive changes need 2+ positive reviews
… and we just have to nag folks...
… and ideally, the person who raised the PRs should push for review
… mainly, I think we've lost track of who's in charge of the spec now with Marcus gone
… maybe the Chairs should?
… dmitriz are you lead editor on the spec now?
dmitriz: correct, but I'm unclear on the politeness
manu: 2 reviews after 7 days for normative
… if they're editorial, it's completely up to you
… for the case where we don't have 2 reviews after 7 days, then we have to push on calls
… I'll also know that CODEOWNERS is incorrect
… it's pinging the wrong people
… I'm happy to fix all that stuff, but I can't currently because I don't have permissions
… like adding `.editorconfig`, fixing CODEOWNERS, etc.
Wip: happy to add you
pchampin: I should likely be the one doing that
… so, just to summarize...
… updating CODEOWNERS to match reality
… anything else?
manu: I could fix the trailing whitespace
<TallTed> see https://
manu: write privileges would do the trick
ottomorac: I agree
Wip: I agree
w3c/did-resolution#257
ottomorac: any comments?
JoeAndrieu: the direction we were trying to go was to model how HTTP headers work
… and we mention that anything must be able to be translated into the DID media type
… so, my first scan was incorrect
… so, this actually looks fine
Wip: just to JoeAndrieu , I think there's a separate PR about HTTP semantics
JoeAndrieu: yeah, it was the MUST...but it's at a different layer than that text
w3c/did-resolution#215
ottomorac: for this one, I'm a bit confused
… this person also opened a PR
… per Marcus' request
… but then I think we lost it with Marcus exiting the group
… manu approved it. dmitriz approved it
dmitriz: ...there's an IPR flag
… that seems to be the blocker
ottomorac: so the person needs to sign something?
pchampin: if it's a non-substantial contribution, the PR can be marked in the bot UI as non-substantial
… if it is substantial, then this person needs to sign something
… chairs should have that privilege, or I can do it
… but I'd defer to the group
Wip: they seem non-substantial
manu: yes, they're non-substantive
… they're also in full agreement with the suggestions of the group
Wip: now to figure out how to do it. :)
ottomorac: k. 9 minutes left
… Wip any particular issue left?
… we've discussed most of the others
… and most have a PR or are ready for PR
… the message at this point, is please be reviewing PRs!
manu: this is a question for PA
… the DID 1.1 spec was published as a CR, but I'm still not seeing it on the website
… does the CR displace the TR?
… or does that only happen when we go to rec?
pchampin: I'm sorry I didn't check, so I don't know exactly where we should be
… CR does update TR
… I can look into that
… it's still marked as a Working Draft
manu: it looks like it stopped updating in September
… but we need to get the 1.1 URL reflecting that it's at CR
pchampin: it's likely just me missing some buttons at some point
… but I'll get to it soon!
manu: thanks
pchampin: manu when was it that there was a resolution
manu: it was right before or right after TPAC
w3c/did-resolution#265
Wip: I wanted to go back to the PRs, actually
Wip: this one needs a review
… it's about errors
… I've removed a bunch
… but how do we handle where errors defined in the spec weren't used anywhere
… I've added sections to use them
… but I do need reviews
… and we can discuss it if/as needed on a future call
… it is a relatively substantial change
ottomorac: yeah, reviews are really the main thing
… if there are no other concerns, we'll see you next week!
… thanks all
<ottomorac> 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/