Meeting minutes
We have a visitor joining the call today: Om Goeckermann
Agenda Review, Introductions (5 min)
Wip: We'll talk about DID Path PR, we have some issues that need a bit of discussion (DID URL query normalization), inconsistent use of resolution, any other suggestions/changes.
manu: We should also talk about DID v1.1 CR
manu: The publication has happened. Thanks to PA for pushing it through the process. Our strategy for the test suite is to take all the DID Docs run them through the test suite
… upgrade them to the 1.1 context and rerun the tests. We have not done full JSON-LD processing on them -- still need to do that and then done.
… We still need to integrate in the CID spec in the context. Since the context is non-normative, OK to change, but need to make the changes and need to run the test after the changes.
… Don't want to get implementors to test until then, but they can do that after -- a few weeks. But we're in good shape.
… need to have DID Resolution ready to move to the next stage. Update the context for the DID Resolution context and rerun the tests. That will get past some of the exit criteria.
<pchampin> https://
pchampin: W3C has already published and requested implementor feedback now.
wip: Manu are you doing the context/testing work?
manu: Yes, though I might need some help from PA. Need to get DID Resolution context stabilized. Need to do all of this as soon as possible since we are in CR.
DID Path PR \[1\] (15 min)
<Wip> w3c/
Wip: There are two things identified in the group.
swcurran: I went through all comments, I have a presentation to go through all changes.
<Wip> https://
swcurran: Looking at PR 260
swcurran: Should there be a MUST on handling of query parameters, service types, what does a DID URL Dereferencer have to handle those things?
<smcown> +1 for Joe's comments ... handling of "things" should be a "should"
JoeAndrieu: I do think this should not be a MUST -- but if it is present, it must be defined in this way -- we have DID Methods out there that don't use PathService and if we make this a MUST, we'll just have non-conforming methods.
manu: +1 on what Joe said.
swcurran: Ok, will do that... change it to a SHOULD.
swcurran: Next item -- unknown parameters, not mentioned in the defined algorithm. Other parameters that come up -- what do we do about it?
swcurran: I do think it's something for the group, but not for this PR.
<Zakim> JoeAndrieu, you wanted to say it's more than just SHOULD
JoeAndrieu: Agree that we shouldn't deal w/ this in the PR.
JoeAndrieu: on previous item -- SHOULD process PathService, but if implemented, MUST follow rules in this spec... something to that effect.
Wip: Yes, you SHOULD support PathService, but if you do support it, you MUST implement it in the way that it's in the spec.
manu: +1 on the previous item
… On this item. I agree its not in scope. We can raise an issue. However, one option is not to say anything about unkown parameters
… Lets raise an issue and have a more detailed conversation
swcurran: I think there might be an issue already for this.
swcurran: This is about ReSpec, use bullet list -- I get numbers... instead of bullets.
swcurran: I added a style, stuck it into styles where other styles are defined, is that ok?
TallTed: If we can write up that bug in ReSpec, I have no problem writing a style like this.
TallTed: Is there a bug in the markup?
swcurran: All things I tried, always incremented the numbers.
swcurran: There are other places where we're using algorithm, where it would make more sense to not have numbers... apply the relative ref with these inputs, we try to use bullets but end up with numbers. I'd do this in a few more places, happy to have others figure it out. What do we do with this PR?
TallTed: I'd do that for now, turn it into a fresh issue.
<JoeAndrieu> +1 to finding the bug
manu: It's not a ReSpec bug, it's just a CSS bug, we should fix it. We can fix it later, we can raise an issue to remember to fix it -- it'll be editorial.
<ivan> +1 to manu
swcurran: I'm going to revert
<Zakim> pchampin, you wanted to volunteer to investigate the CSS
manu: Nah, let's keep the right markup and fix CSS later.
pchampin: Leave it and I can look into it to see what's wrong with the CSS.
swcurran: I'll remove the styles that I put in and will remove the class on the unordered list that I have.
<JoeAndrieu> +1 if we remove, we lose backwards compat
swcurran: Finalize fallback to DID Method for path handling if there's no PathService -- in text right now, Markus seems to be good with it....
<JoeAndrieu> +1 to keep (not +1 to remove)
swcurran: Joe had a comment about basePath attribute -- how do we figure out how path is handled -- I don't think it works with out that and I don't think it needs to. we already have fallback mechanisms on how paths can be handled.
<Zakim> JoeAndrieu, you wanted to this section is did-resolution specific, not PathService
JoeAndrieu: This section isn't in the PathService algorithm description, other algorithms shouldn't be required to do this, just PathService.
swcurran: How can I do that?
JoeAndrieu: Part of this document talks about resolution, we shouldn't put it there... we should put it in path handling.
swcurran: I don't agree with that characterization, but perhaps you can help
<Zakim> manu, you wanted to raise tracking issue?
manu: Was this language there already?
swcurran: no it wasnt
manu: Can we put in an issue marker saying we need to figure out where to put this language and raise an issue against it
… Then we can deal with it in a future issue
JoeAndrieu: I would rather we didnt
… Rushing it into review right now is not helped
manu: Can we just raise an issue and deal w/ it in another PR.
JoeAndrieu: This is structural to the whole PR. Where we have things that are path service specific, we need to fix that
JoeAndrieu: We need to fix this in one fell swoop.
Wip: Joe, I think what you're suggesting, a refactoring so this functionality happens in PathService.
JoeAndrieu: Yes, I'll commit to that.
swcurran: I'll make the other changes.
Add rules for DID URL query normalization \[2\] (10 min)
swcurran: That's everything.
Wip: Can anyone take this issue on?
manu: They just want us to talk about the things you should pay attention to if you are doing DID URL query normalization
… e.g. pecent encoding, duplicate params, relative paths, canonicalization rules
swcurran: I can give it a shot, what does c14n by DID Method mean?
manu: On canonicalization by DID method, I think what they are presuming is the the DID method itself can have its own query normalization and canonicalization rules
… e.g. if you see foo:bar, delete it from the URL
… This is possible, even if its not recommended
… We could also say as a WG that you should not have special canonicalization rules
… in your DID method. But people will probably ignore us
… We should tell implementers to look out for that stuff
swcurran: Ok, I'll give it a shot.
Tracking of resolutions and dereferences by downstream entities from the resolver \[3\] (10 min)
Wip: This is the last privacy issue we need to resolve.
Wip: We didn't come to a concrete decision last week.
Wip: If you resolve a did:web locally, you have to call out to another system, there are concerns around that -- maybe we just add some privacy considerations? Clients can take steps to obfuscate... wondering if it should be a SHOULD.
<Zakim> JoeAndrieu, you wanted to say maybe we recommend methods have a threat model
JoeAndrieu: Maybe we recommend for DID Methods to have threat models -- each DID Method should be evaluated for threats unique to it -- DID Methods SHOULD provide a threat model, but good idea to explain architectures.
JoeAndrieu: I think he's trying to get to what would be exposed in that threat model, that might be one way to respond.
manu: Yes, I like that suggestion
Wip: I like the suggestion
Wip: Do we talk about these items in DID Core? or CID?
Wip: He doesn't want implementers to not notice sharp parts -- use of DIDs vs Resolution
manu: Do we point to the DID spec for privacy considerations
Wip: yep
manu: I think we should just cross reference with the privacy considerations in DID and CID spec that speak to the concerns raised
… It may be that we dont have this written anywhere
… We have the chaining working. Resolution to DID to CID
… Lets map his concerns to these sections
Wip: Ok, I can take this on, then. I also like Joe's suggestion of pointing to a threat model.
Wip: Can we add privacy considerations to DID Core?
manu: Yes
… Question to JoeAndrieu about threat model. All specs are required to have security and privacy considerations. When security and privacy do reviews they refer to both
JoeAndrieu: In our approach, we do like the threat model to include any kind of threat -- we didn't want to restrict it to a particular category -- like human rights violations are a particular type of threat. We have no really resolved through PING if that's how they want privacy included -- don't know if it would meet their needs, where we may shift expectations for privacy considerations section.
<Zakim> JoeAndrieu, you wanted to reference section error
manu: +1 to that Joe, thats fine. The idea that you have all your threats in one section, security and privacy. I hope SING is moving in that direction. Otherwise it will be awkward to follow
… This is a privacy review, so pointing them to the threat model might confuse the reviewer. It would be good to get his feedback on using the threat model for privacy analysis
… When we say all threats, security and privacy is in scope. HUman rights violations, What about market competition
… Trying to figure out the boundary
JoeAndrieu: There is a necessary decision made by threat modeller that is in the mode of a story teller that has particular locus of attention. When we're modelling threats of CSS, most people are not going to entangle semiconductor considerations into that model (legit threat, hardware focused threat model, but probably not in scope for the way CSS speaks to it).
JoeAndrieu: Two things are a result of that -- each threat model has a locus of attention, and they can put component in to talk about it -- TPM module not in diagram, don't need to talk about it. I think it's appropriate to have a multiplicity of threat models, same diagram, privacy threats from security threats -- so maybe that's how we can address complexity.
Wip: Maybe we raise this with Ben, maybe Joe is best person to do that... talk about threat model and how it might help privacy.
Wip: See if he gets a response from Ben --
JoeAndrieu: Yes, I can look into that.
JoeAndrieu: Just created an issue -- our references is not working on Github Pages, added an issue for that.
<Zakim> JoeAndrieu, you wanted to mention multiplicity of threat models.
Inconsistent use of resolution \[4\] (15 min)
Wip: Maybe provide an update on issue 226 -- consistent use of resolution, how is threat modelling going, how is it going w/ this issue.
JoeAndrieu: I added some of the language that has come from the DID Resolution threat model, where I formally talked through things in context of this diagram. Diagram isn't in there, labels might be confusing, but ignore that for now. Shared with a few folks, seems like accurate representation based on some external reviews -- would love to get some feedback. One good meeting w/ Steve McCown that added some things to diagram, profile of at least three
different methods... did:key, did:btcr, did:webvh to see if it aligns. Pull that in, wrt. 226, I hope that next weekend pulls in draft and make pass.
Wip: That would be good progress. I looked at text now, sentence that says DID Parameters turn into resolution options and passed into DID URL when it is resolved... doesn't resolution take in DID vs. DID URL?
JoeAndrieu: Yes, that's an error in the current spec... if resolver doesn't have full DID URL, it might not receive calling parameters, no reason to cut off path / query parts -- shouldn't get rid of path and query parts.
Wip: So, changes?
JoeAndrieu: Why wouldn't we pass on full URL
manu: +1 to passing on full URL
Wip: This sounds like we defined two separate APIs, this is going to collapse into one?
JoeAndrieu: No, it isn't.
JoeAndrieu: swcurran talk about how it could be one thing, but I believe it's two different things. We don't talk about the separation well, and one of the consequences are that we have algorithms in places we shouldn't have those things.
JoeAndrieu: Dereferencing a particular resource may not be resolvable to a particular URL... for example, a DID Ordinal, which doesn't exist at a URL.
Wip: Yes, this all sounds fine -- this will help make spec more clear -- concerned that test suite ramifications aren't that terrible... we'll see.
JoeAndrieu: I hope to have a draft this weekend.
Wip: Any other comments before we close?
Wip: We are pushing to have all of this stuff ready for CR by end of this month.