DID WG Topic Call on finishing the Security and Privacy Questionnaire — Minutes
See also the Agenda and the IRC Log
Present: Shigeya Suzuki, Adrian Gropper, Dave Longley, Markus Sabadello, Orie Steele, Daniel Burnett, Brent Zundel, Amy Guy, Manu Sporny, Dave Longley, ned, Justin Richer, Joe Andrieu
Chair: Daniel Burnett, Brent Zundel
Scribe(s): Manu Sporny, Amy Guy
Daniel Burnett: We are going to be working on the security/privacy questionnaire… this is a working session today.
See github issue #291.
Shigeya Suzuki: See also the working document.
Adrian Gropper: In last email to people involved, put in a proposed resolution for all issues – but this will time out - if we have a quorum, happy for anyone other than me to resolve issues as we go through them right now.
Orie Steele: I took a pass at it, hard for people to look at document - has a lot of stuff in it… let’s go through accepting changes – then make another pass on places we couldn’t make changes.
… We should highlight sticky issues remaining.
Adrian Gropper: I’ll do the clicking… should I share screen?
Orie Steele: yep
… Manu’s comment is fine for the first item.
… What does type mean? There is confusion around types of service endpoints and privacy implications about service endpoint type – we should have a section in spec about service types
… This is a sticky issue, let’s skip it.
… I’m objecting to bring biometrics into the spec at all, risky to discuss, not directly relevant to PKI, remove any mention of biometrics.
Shigeya Suzuki: +1 to remove
Manu Sporny: Removing biometrics from spec would be aligned with direction of group.
Adrian Gropper: Remove discussion of wallets?
Orie Steele: Yes, I think so.
Adrian Gropper: add “and accessible to an origin”?
Orie Steele: DID Documents don’t talk about “accessible to origin” –
Adrian Gropper: Private VDRs?
Joe Andrieu: Hmm, no, this isn’t about VDR… its about something else.
Orie Steele: How would origin know anything based on spec today? It wouldn’t, right?
Joe Andrieu: yes
Orie Steele: proposes rewording that scribe missed
Markus Sabadello: It could be about HTTP API, but it’s not, right?
Dave Longley: We don’t define any new fields for browsers like that.
Adrian Gropper: I’m going to reject my comment, then… going to accept what Joe is proposing.
Orie Steele: VDR configuration may be revealed through operation, but this could be volunteering unnecessary method specific information.
Manu Sporny: Let’s not put in stuff that doesn’t concern the spec…
Joe Andrieu: I would like to be clear about security/privacy risks of methods that are specific… would like to separate DID Core from DID Method specs.
Dave Longley: Someone implementing DID Method spec should have privacy/security considerations.
Orie Steele: A lot of comments i have would be easy to delete/dismiss if we could say something to the effect of what dlongley said.
… If you’re building a DID Method, you should do a security/privacy questionnaire for DID Method.
Joe Andrieu: Some version of second bullet point I’m editing – might want to move it up, make a general statement about DID Methods.
Orie Steele: That would address a number of my concerns.
… You can delete my 2.6 proposed changes, jandrieu will cover that.
Joe Andrieu: Ok, I think text is ready to go for 2.6
Orie Steele: The information revealed is vague… covered by paragraphs above.
Shigeya Suzuki: I think this is more clear, reworded it… section 2.7 rephrasing.
Dave Longley: This spec does not allow origins to access sensor data. This spec is a data model, no APIs for device access.
Manu Sporny: A lot of these questions are based on assuming that application is running browser… which doesn’t apply to us.
Dave Longley: Yes, a lot of this stuff falls under this category.
Orie Steele: Section 2.8 – security and privacy considerations section…
Dave Longley: I think we should delete the entirety of 2.8 - it does not reveal information to origin.
Adrian Gropper: Ok
Dave Longley: We should say this is a data model spec… there is no mechanism to deliver anything to an origin.
Daniel Burnett: Yes, we need to put more than “None” – we need to explain.
Manu Sporny: Group updates text in 2.8
Manu Sporny: Group moves on to 2.9
Orie Steele: We should probably do the same thing here.
Manu Sporny: Group working on 2.10
Manu Sporny: Updates 2.10 to note that this is a data model specification.
Orie Steele: looking at 2.12 – create/expose – don’t know if create is method-specific, I think it is?
… No, spec doesn’t create any identifiers?
Joe Andrieu: We should be explicit, identifier creation is domain of DID Methods.
Orie Steele: We should delete the examples, they invite confusion.
Daniel Burnett: This one, unlike the other ones… may seem like a cop out
Dave Longley: we may want to put examples back
… we expect DID Methods to create ids that could be expressed in data model.
Joe Andrieu: We should add – this spec doesn’t expose information to the web.
Manu Sporny: Group struggles with tooling
Manu Sporny: Group continues to word smith section 2.12 – jandrieu adding wording about not exposing identifiers.
Adrian Gropper: Does that look good?
Daniel Burnett: yes
Orie Steele: I’m not sure I interpreted context correctly… 3rd party contexts…
Dave Longley: We don’t have any interaction models… first and 3rd party context – first party is when you visit website by typing location into browser bar. 3rd party is embedded iframe… we don’t do anything w/ first or 3rd party contexts.
Orie Steele: Last paragraph invites confusion…
… would suggest deleting it in 2.13
all: More struggles with tooling
Adrian Gropper: moving on 2.14
Orie Steele: dlongley fixed it, accept his suggestion.
… 2.15 we might want to point out Method-specific sections as relevant.
Dave Longley: Does this capture both Orie and jandrieu’s concerns?
Manu Sporny: Group moves on to 2.16
Manu Sporny: Group makes changes to 2.16… moves on to 2.17 -
Orie Steele: This is DI DMethod specific…
Joe Andrieu: No, looking at 2.16.
… Our most authoritative feedback is about our technology not other people’s technology
Dave Longley: Should this spec have extension points, questions should be asked about those extension points.
Joe Andrieu: It should have asked about dependencies.
Orie Steele: Should we talk about registry and it’s potential danger to the spec? Drift? Highlighting a spec security issue?
Adrian Gropper: We definitely don’t want to hide that… central issue should be stated here.
Manu Sporny: the last time these questionnaires were discussed, 2.17 is a temperature check on whether the security and privacy folks are asking the right general questions, we may or may not want to say not all specs are about the browser and many questions asked are about the browser
… if you can go down the entire thing and say does not apply and we have a giant security and privacy section it’s an indication they’re not asking the right questions
Joe Andrieu: What they could have asked is “does this specification expose private information w/o reference to origin or browser.”
Manu Sporny: yep
Orie Steele: It’s still DID Method specific…
… Other sections in here wrt. correlation wrt. reuse.
Brent Zundel: See missing questions.
Orie Steele: origins don’t apply and DID Method specs are important.
Adrian Gropper: I’m not in favor of deleting things w/o other people on call… either we should make them sub bullets or involve the other people.
Orie Steele: I agree with you agropper, after reading through them again.
Joe Andrieu: I’d like to turn them into questions.
… How would we frame the question –
… We could turn public/protected networks into more general question.
Dave Longley: trying to ground this in a way that elicits people to put information in in a certain way.
… are you doing data model spec that let’s you express information in this way? How should you be careful about doing that/
Joe Andrieu: Any information could be expressed on public/protected network – is spec encouraging/enabling information – you should consider what your DID Method is publicly disclosing.
Orie Steele: There are DID Methods that don’t publicly disclose things, and there are DID Methods that do publicly disclose
… We don’t want to make the mistake of saying ALL DID Methods disclose stuff publicly.
Joe Andrieu: We should state public disclosure is a topic that DID Methods should discuss.
Dave Longley: The first thing is about calling it out.
Manu Sporny: Riveting discussion about quote styles.
Orie Steele: The PII question is captured in bullet point above in 2.17 – folks might want something more specific. Specification attributes might be considered PII?
Daniel Burnett: We have 7 minutes left, we’re only about 50% of the way through – this is a productive session, but we’ll need more time.
Adrian Gropper: Rubrics document might be useful here..
Orie Steele: There is a section on illegitimate use later on, which might be good. Revocation is a method-specific thing.
Adrian Gropper: We might want to say things about GDPR revocation…
Orie Steele: We may want to say something about immutability.
… Are there immutability data retention issues about data model spec…
… This addresses deletion and revocation more generally.
Joe Andrieu: I think they missed an opportunity to answer these questions…
Manu Sporny: They’ll ask us, usually…
Joe Andrieu: You could ask, have you had an external security review / formal security review?
Orie Steele: 3. Threat Models – each representation creates its own attack surface…
… Suggested changes, DID Method implementations are responsible for addressing own threat models.
Joe Andrieu: You shouldn’t resolve contexts in a production system…
Orie Steele: Wayne is making a method-specific threat model
Joe Andrieu: Not sure it’s method specific – really client that says it’s not resolvable…
Orie Steele: We should delete Wayne’s comment…
Joe Andrieu: Oh, I thought you were saying integrate it.
Orie Steele: No, we should speak to it though… about DID Methods.
Joe Andrieu: I like second bullet point.
… Explaining that it’s the DID Methods job to say something is good.
Brent Zundel: Hallmark of a good meeting is when we go over and no one has said anything. Thank you all, this was great progress.