Meeting minutes
ottomorac: welcome everyone
… we'll look at the update on DID Core
… the DID path PR
… and a few issues raised by someone at Mozilla
… and then we can wrap with 15 minutes or so about threat modeling
… anything else?
Agenda Review, Introductions (5 min)
ottomorac: the CR update
manu: I made some changes to the status of the document section
… and I could use some feedback
… we didn't point to a test suite link, but now we do
… we warn implementers as class 1-3 might result in changes to the spec
… we clearly highlight what we need in order to exit CR
… for statements that are machine testable, there must be ___ implementations
<ottomorac> For CR criteria:
<ottomorac> there should be a test suite for DiD 1.1 (it's the case but not explicit).
manu: we've heard that we'll need 2 producers and 2 consumers
<ottomorac> we'd like to see a dependency between DiD 1.1 and DiD Resolution, ie DiD 1.1 shouldn't move beyond CR if DiD Resolution isn't able to do the same as well.
<ottomorac> conforming implementation is defined using conforming producer and conforming consumer. At least, we'd like to see two consumers interoperating with one producer and two producers interoperating with one consumer.
manu: which is different than the typical "2 implementers"
… these are complaints from previous iterations and so I think the goal is to avoid that this time
… additionally there's pressure to make sure DID Resolution exits at the same time as DIDv1.1
… which raises the bar a bit
… there's also some boundary setting language about formats and resolution
… but there have been no new comments on it--positive or negative
… so I plan to merge it after the call
… prepping the doc for publication
… and PLH has approved it once his concerns have been addressed--which they are now
ottomorac: so the two specs are kinda joined at the hip now, correct
manu: yes, and that's new
pchampin: did you see that PLH +1'd the transition issue?
… you can count him as approving the other PR also
… so we're good to go
manu: excellent. I'll let you know when it's done
<pchampin> w3c/
<pchampin> w3c/
DID Core Candidate Rec Update \[1\] (5 min)
DID Path PR - Final Call \[2\] (10 min)
<ottomorac> w3c/
ottomorac: next topic
… we are mostly done on this one, I think
swcurran: I had a great conversation with JoeAndrieu yesterday
… I think we agree on the state of it
… but language clarification would help
… JoeAndrieu would like me to go through it one more time
… and I think he was going to take a look at it also
… our disagreements that remain seem separate from this PR at this point
… so I plan to do one last pass to clean up anything that remains awkward or unclear
… and thanks to TallTed for his help also
DID Resolution Privacy Review \[3\] (10 min)
<JoeAndrieu> +1 to Stephen's report out
w3c/did-resolution#294
<ottomorac> HTTP Bindings could be more tightly specified #294
ottomorac: there are some suggested improvements hese
Wip: are we using http headers?
Manu: I think he is saying we are vague about what layer we are trying to target....
Manu: so he is basically saying we are not clarifying caching and which headers are ok....
Manu: Also regarding the client and resolver trust relationship....
Manu: He wants more clarity that
Manu: He is also asking about browser apis vs just pure http.... it sounds like you guys are using pure http... and then we need to clarify what changes we might make before raising PR
JoeA: We are not using HTTP headers in a meaningful way, we are only using https so we need to put some detail around that
bigbluehat: In the context of a privacy review he does want more detail about referer....
bigbluehat: I dont think he wants the whole expansion of http headers, perhaps a paragraph or two could suffice...
bigbluehat: In the context of a privacy review, he's looking for specific callouts that "void the warranty" on privacy -- origin cookies, things of that nature -- it is in the context of a privacy review. I don't think he's looking for a full expansion, and how we treat each one, perhaps something on privacy conscious clients and things that might explore those things.
Wip: anyone want to take this on?
… we have maybe 4 weeks
… so it'd be great to have someone tackle it
bigbluehat: I'll do it
ottomorac: thanks!
w3c/did-resolution#293
ottomorac: we have another one from the same reviewer
Tracking of resolutions and dereferences by downstream entities from the resolver
<Zakim> JoeAndrieu, you wanted to say we it's likely out of scope
JoeAndrieu: I appreciate the concern raised, but I think because of our security model that this is out of scope
… essentially, the trust is in the resolver
… I do think we need to be more clear about that
… otherwise, I don't know how to address this one
<TallTed> s/trust the resolver/rely on the resolver to keep secret information secret/
<TallTed> `trust` is a terrible word to use
Wip: my first read left me feeling like he's thinking primarily of Web-based resolvers
… and this is privacy focused review again
TallTed: trust is a terrible word
… relying on the resolver to keep secret information secret would be better
<TallTed> s|s/trust the resolver/|<TallTed> instead of "trust the resolver",
manu: I need to look through again because I'd though we'd added stuff about OHTTP, etc.
… I do agree we should write more in the privacy concern section
… he mentions mentioning techniques
… and OHTTP would be one
… one our specs does do that...maybe VC Data Model?
Wip: we do say steps can be taken to obfuscate requests
manu: yeah, but we don't spell it out and point to options
… which I think is what he wants
<manu> https://
manu: here it is
<manu> We say this: "Verifiers SHOULD cache the retrieved status list and SHOULD use proxies or other mechanisms, such as Oblivious HTTP, that hide retrieval behavior from the issuer."
manu: we could say something like this in the DID Resolution privacy section
… I think that's what he's after
JoeAndrieu: I agree we could improve the language
… but I'm not sure caching should be there
… it's not really part of our architecture
… I think we should add that, again, one shouldn't ask a resolver for a DID unless there's some trust in what the resolver may do with that DID
… I'm honestly not sure how the obfuscation helps
bigbluehat: the question is who are you being private from?
bigbluehat: http will only mask so much...
bigbluehat: as Joe said we need to clarify what level of trust is expected
ottomorac: so, maybe we're clarifying what level of trust is being expected?
JoeAndrieu: TallTed's right. We should avoid saying trust
… it is more about reliance
… the protocol may need you to talk to a central server
… as sad as that makes me, it's possible
… and that may leak PII
… and the fact that the resolver can do all that stuff is just part of the pioneering part of this ecosystem
ottomorac: and I guess the concern here is that the resolver may not work on behalf of the user?
JoeAndrieu: it's just like browser choice
manu: so, the reviewer is coming from a browser vendor
… and browsers do try to mask certain requests through things like caching
… to really know something, you do have to GET the newest thing
… but what if you do it 10 seconds later?
… one thing that caching does do is mask how many requests are being made which can help obfuscate usage patterns
… OHTTP can help by masking who's asking
… that plus caching can be helpful for further obfuscation
… so I don't think it's quite the same as choosing a browser
… I do think there are places where this stuff matters
<Zakim> JoeAndrieu, you wanted to say caching is a thing that people will do. We don't have a secure way to do that.
JoeAndrieu: if we're talking about making OHTTP optional, I think that's fine
… making it mandatory would be a mistake
… I think encouraging caching would also be a mistake
… because it's not actually resolution
<KevinDean> What to cache and for how long is a business decision based on the use case.
JoeAndrieu: and if we encouraged that, we'd be doing a disservice to the client
DID Resolution Test Suite \[4\] (10 min)
<manu> hmm, "stay silent on caching" feels like sticking our heads in the sand -- people will do it, fine to warn, but think it's a mistake to not talk about it as a privacy concern.
ottomorac: k. I want us to move on. Let's let this on simmer
Wip: I'm taking the lead on the test suite
<Wip> https://
Wip: there is an open PR on this repo which has a pretty solid base
… not sure who's implementing, but I'd love to hear from folks who are
… I've implemented resolution locally
… but it's not live
… so not sure how we want to do that
… if you have a library, just plug it in locally
… there are some tests that are still unstable
… but many of these feel complete
manu: glad to see we have 2 implementations!
… this PR looks good to me
… I'd say we make this the new base
… and I don't think the WG really needs to give it a deep review yet
manu: on the local implementation vs remote, when we do what we did for did-core we already paid the price for longterm....
manu: some people just want to up a simplified docker instance and try to call it a resolver...
manu: I don;t want us to put it in the effort and then people abandon those resolvers...
manu: I would rather help you out
Wip: yes thats fine, what I meant is i DO have an https wrapper...
Wip: last thing, swcurran do you have a resolver implementation?
swcurran: I think so, but let me take a look at what you did
swcurran: the DID webvh meeting is soon. I need to do a bit more work
DID Resolution Threat Modelling Update \[5\] (15 min)
ottomorac: so, JoeAndrieu I think you've been tackling these
JoeAndrieu: we've made some adjustments to the diagrams
… one thing to share is that I went over this with swcurran
… mostly to focus on the path PR
… some of this was tangled up in resolution vs. dereferencing
… these clarifications should allow me to clean some stuff up this weekend
… I've walked through the diagram with various methods, etc.
… and each time I've gone through it, it's gotten "richer"
… the goal here is that each component in the diagram is shared across each of the flow diagrams
… so, for example, when one is offline, there are fewer components, etc.
… as I think through this for my personal situation, I'm the client admin for example
… but in a larger organization, that may be a completely different person in a different part of the organization
… swcurran is hopefully going to do this one for webvh
… I'm hopeful that these diagrams will give us things to point at when reviewing methods
… like my disdain for DNS in did:webvh presents as a particular threat in the modeling
… so we can point at those and discuss them more accurately and narrowly in future
… there is more work to do here on extensibility
… and think about where those introduce threats
… for example, when we get into DID Core and start talking about verification methods
JoeAndrieu: swcurran and I are setup to do regular meetings
… I could talk through some of these threats now, if we want
manu: this might derail us... All of this made good sense, JoeAndrieu
… however, I am concerned about other people being able to do this same sort of work being done here
… is there a way to productionize this work, basically
ottomorac: are we saying other spec writers?
manu: all of them
… we don't want a bottleneck here
… for example, we don't all have access to the diagramming tool
… so could we use Mermaid?
… we don't have to solve any of this right now, but I do want to highlight the concern
JoeAndrieu: the threat modeling guide actually already speaks to this
… it's not tool or even diagramming approach specific
… the output just needs to be accessible
… I think the threat modeling is the solution, not the creator of the problem
… software developers don't really have training in any of this
… and we've been abdicating to SING...and they are eternally backlogged
… so the hope is that training all of us in threat modeling will alleviate that a bit
manu: sorry, that wasn't what I was trying to convey
… mostly, I'm after "where's the respec for threat modeling" sort of questions
JoeAndrieu: just ask. We have plans for these things
… we're trying to JSON-ify these things
… and WGs can model threat models in JSON
… and then a respec plugin will render them
… we do have a threat modeling spec in respec
… it's not JSON-ified yet
manu: thank you. that's actually what I was looking for
ottomorac: specifically on some of there charts
… are you expecting everyone to make these?
… like at least DID Method authors?
JoeAndrieu: yes. that's the goal
… really anyone could do a threat model
… we state this in the guide
<ottomorac> zakim close the queue
JoeAndrieu: we have a weird thing with the high extensibility of DID methods
… but we expect that people will use this as foundations in their own work
… for example, we don't say anything about key management
… but the hope is that each group would express how they're doing it via a threat model
ottomorac: k. let's come back in a few weeks
JoeAndrieu: sounds good!
ottomorac: thanks everyone