Privacy Interest Group Teleconference

09 Aug 2018


alex_ortizia, christine, dan_b, dave_l, jnovak, joe_a, manu_sporny, npdoty, shivan, tara, Matt_Stone, weiler, JoeAndrieu, dave_longley, adrian_gropper, Joe_Andrieu, burn
weiler, manu


<jnovak> Ah, nick already got me, thanks nick.

<weiler> scribenick: weiler

adrian: intro: CTO of Patient Privacy Rights non-profit. leading a project using self-sovereign stuff for heath records.

alex: building a self-soverign ID project called Life ID

claire: building a privacy-preserving identity verification network based on zero knowledge proofs.

dan: I have WebRTC background. recently joined Consensys - an Etherium blockchain company.

dave: CTO of Digital Bazaar.

david: @@

WoT outreach

Privacy considerations of Verifiable Credentials Data Model 1.0 (see details below) (guests from the Verifiable Claims WG)

<jnovak> Turns out my mic is broken, going to drop off and dial back in.

joe andrieu: cochair credentials CG and @2

manu: I'm a editor of this spec

matt_stone: cochair of VC WG. background in high-stakes testing (Pearson) and license mgmt.

nick: UC Berkeley.

<jnovak> I think that I fixed my audio

weiler: I'm a W3C team member.

shivan: Salesforce. chairing new privacy group in ietf.

tara: co-chair of PING. Google.

<npdoty> https://www.article19.org/

nick: Apple privacy team.
... thanks to VC group for joining us today.

christine: who's going to give the overview of the spec?

dan: Manu or Dave?

<manu> https://w3c.github.io/vc-data-model/

<manu> https://w3c.github.io/vc-data-model/#ecosystem-overview

manu: thanks to PING. See Figure 1.
... VC WG was chartered only to work on data model stuff. Another (future) aspect is re: protocol.
... WG is called Verifiable CLAIMS; model is Verifiable CREDENTIALS. using CREDENTIALS as the term now.
... way to assert attributes about yourself. analogue is digital drivers license. health ID card. in physical world pieces of plastic.
... no broadly deployed analogue on the web.
... can we give people a digital wallet?
... can we move this info around in a privacy-preserving manner? Can we bring things in the real world to the internet? e.g. not just anyone can reach into your wallet and look at your DL - you have to consent.
... want to support that sort of workflow.
... a Verifiable Credential is a digital doc with claims from 3rd parties or self.
... questions?

<AlexOZNOLabs> Manu, can you repost the diagram link please?

<dlongley> https://w3c.github.io/vc-data-model/#ecosystem-overview

<AlexOZNOLabs> Thx

christine: are you envisioning use case case where you can present attributes without revealing identity? e.g. proving age or student status?

manu: yes.
... there is a spectrum of privacy we're trying to support. different use cases with pseudonymity v. strong authentication.

jason: who are envisioned actors? doc describes individuals getting claims and providing it to a verifier... is scope an individual talking to a server? what about server to server? or server making claim to user?

manu: yes to all. this diagram puts holder in the middle - holder always has decision-making capability. in some current world today, holder is out of loop.
... this ecosystem may not PREVENT orgs from going around the holder.
... not on the diagram: the holder uses software (digital wallet) to manage credentials. don't always have to go to issuer to check things.
... in fact, we suggest not going back to issuer. we even have blockhain-based revocation lists.
... we try to make sure verifier does not 'phone home'.
... but this gets into protocol work, which is happening in the CG.
... wallet should not be able to see where you're using the credential. to protect privacy from the wallet provider.
... we discourage verifier from contacting issuer. we discourage digital wallet from knowing where creds are going.

jason: @@3

<manu> https://w3c.github.io/vc-data-model/#privacy-considerations

manu: identifier registry is important for privacy. section 10 is privacy considerations.
... includes mitigations.

<manu> https://w3c.github.io/vc-data-model/#ecosystem-overview

manu: we're trying to support a broad range of use cases: in education, health care. we have US govt, CA govt, ... different levels of pseudonyming v. strong identification
... extreme examples: "proof of age" without exposing anything else.
... some are using ZK proofs for this.
... others us pairwise pseudonymous identifiers. or bearer tokens.
... we never say "fully anonymous". ...because of tracking technologies in use. A determined attacker can always do things. other end of privacy spectrum:
... health care use cases, writing Rx'es for controlled substances.
... need to confirm current medical license of MD... that use case does not work without strong identity (per current regs) of MD.
... one of the things that affects that is identifier registry. ... a bearer token does not use one.
... pairwise identifier also does not use identifier registry.

<npdoty> weiler: mapping onto real-world systems can be difficult, in terms of adoption

<manu> weiler: This is off topic for privacy, when I've retrofitted privacy into existing systems, I've run into road blocks where I don't enforce what happens in the real world. I wonder if that will harm adoption?

npdoty: looking through privacy considerations: because there is an enormous set of use cases, and data model is agnostic to the use case, it's hard to evaluate how it will be used.
... because they're so different, it's hard to give strong privacy advice.

<Zakim> weiler, you wanted to ask about modeling of the real world. (off-topic)

<Zakim> npdoty, you wanted to ask about scope of identifiers

npdoty: has the group considered doing a narrower scope, so we could better evaluate and even give normative advice?

jason: i saw some of the same issues Nick was raising. I have editorial comments, not so much technical.
... as a first-time reader of the doc, it struck me that privacy consideration section is extensive. Model seems skewed toward fully-identifiable use case. I wonder if the bigger comment we can provide is to flip the defualt. e.g. use bearer tokens by default.
... it's hard, since we're looking at a data model v. something more narrowly scoped.

<Zakim> manu, you wanted to respond wrt. scope of verifiable credentials.

manu: i agree. it's been hard for us to narrow it down to one/few use cases because of the broad participation we've had.
... that's the reality of the WG. we were chartered to focus on educational-related. very few usages of bearer tokens in that ecosystem.
... one frustration we have: by and large, when someone asks for a credential, most have a unique identifier.
... most systems use unique identifiers.
... some tracking happens from serial numbers on paper currency.
... we want that to change.
... vast majority of orgs participating don't accept bearer tokens for their most serious use cases.
... buying age-restricted products.... might be okay, but regs are written to disallow bearer tokens in those cases.
... we're trying to create examples that support bearer tokens.
... uphill battle to get govt's and orgs to use those instead of identified ones.
... CA govt is interested in bearer tokens.
... vast majority of use cases require correlatable identifiers.
... either for regs or to work with internal systems.
... we understand this is troubling. but tech won't change these orgs overnight.
... how can we make PINGs task of reviewing this easier?

nick: it's hard because we're reviewing for the web...
... I'm not sure knowing where the requirement comes from (e.g. govt) helps the concern to go away.

manu: what could we call out better?

nick: maybe we can frame what is compatible w/ web privacy model and what is not?

manu: chairs?

christine: I like Nick's idea re: incompatibly v. web privacy model. understanding current reg. requirements - CA is already seeing a different way forward. it would be nice if this data model... tried to anticipate and even nudge change.
... I don't want to see the tech lock us into current, privacy-poor regs.

nick: we should discuss on mailing list. this is a longer drafting process.

christine: we'll work on this as a group. poke us if you hear nothing.
... thank you for coming to talk to us.

<npdoty> thanks all for that conversation / overview

<manu> Wonderful, thank you so much to the group for your time! So sorry we went over!

<dlongley> Thanks, everyone!

WebRTC privacy (Shivan)

shivan: talked at recent IETF. Christine, Alp Toker, and Shivan looked at how browsers leak private IP addrs.

<manu> scribenick: manu

<npdoty> Shivan: a previously raised issue on IP address leakage, but demo was able to show when consent affected which IP address was revealed

<weiler> ... Safari, if you dont' consent to camera/audio, does not share IP addr. Firefox & chrome will leak.

shivan: WebRTC is also used for other stuff, other than video chat.
... In a broadcast sense, this permission doesn't really make sense... I put together a blog post on Article 19.
... The blog post covers what different browsers are doing... Safari came up with a way of obfuscating the IP addresses before transmitting them.
... This is interesting because there is no IP address leakage happening in any case... WebRTC group in IETF has adopted the draft and will be working on that.

<jnovak> http://shivankaul.com/blog/2018/07/26/privacy-and-consent-in-the-age-of-browsers-the-question-of-webrtc.html

Shivan: Hopefully we won't need to ask the user for consent in such cases...

christine: Thank you Shivan, excellent blog post.
... Any questions?

<Zakim> burn, you wanted to ask if this group has looked at media privacy in WebRTC

burn: My question probably opens a can of worms - has this group looked at Media Privacy in WebRTC?
... That's one of the scary areas there... the idea here is that media is private between two individuals communicating, that is Javascript doesn't have access to media stream. Current version depends on identity mechanism that only one browser is planning to implement.

shivan: Is that something that Nick posted about earlier?

npdoty: Not sure.

burn: I was one of the editors of the WebRTC spec until recently, I have some familiarity with it. This will come up eventually.

shivan: That is helpful, thanks, will take a look.

<npdoty> maybe someone can share links about that on the mailing list and we can look in more detail?

Review of updated Web Audio API privacy and security considerations - https://webaudio.github.io/web-audio-api/#priv-sec

christine: The Web Audio API group has updated their privacy considerations section.

<npdoty> I think it would be great to consider privacy/security on webrtc in more detail; I think a lot of the time/discussion went into IP address leakage just because that was an especially concrete topic

tara: I took a look at the privacy considerations section -- the team went off and went through TAG self-review questionnaire. They put it in questions to consider. Microphone permissions, fingerprinting surfaces around audio device hardware, clock skew, latency, and potential for being able to control sound activated devices (sounds outside human hearing)
... They have included all of these things in the questionnaire, and now they're coming back to ask if this looks good. They are preparing to transition to CR. They are asking for feedback to summary to be given back in September. In my view, they have done a pretty good job in high level summary. Would be good if we could have a look to talk about missing components.
... That is my take on it.

<jnovak> https://github.com/WebAudio/web-audio-api/issues/1715

christine: ok, let's get some feedback if we can before they go into CR.

jnovak: I already filed that issue above.

christine: I think it's odd that they've answered the question in the spec rather than writing something in the privacy considerations section. Looks like they just copied/pasted the questionnaire... seems odd, should look into it.

npdoty: I think it's a common model, but not good long term.

<jnovak> Maybe we can address how spec authors address the questionnaire in the "Update re contributing to the evolution of the Security and Privacy Questionnaire" agenda item?

christine: if it's published as a spec, it would be strange. TAG questionnaire is supposed to be living document.

Update re contributing to the evolution of the Security and Privacy Questionnaire - https://w3ctag.github.io/security-questionnaire/

christine: Sam and I spent some time at IETF looking at various draft privacy guidance documents we have. What we should do is pull out various useful material in drafts. We also realized that current version was hidden. We've fixed that.

<npdoty> +1, thanks for that

christine: Lukasz, who is now on the TAG, is keen to make the document better.
... I joined a call with the TAG a couple of weeks ago - we in the Privacy IG would be happy to help the TAG improve the document. What we've been asked to do is submit suggested text/editorial changes via PRs in Github.
... Perhaps we should tackle the questions one by one as a group. Come to consensus so they don't get inundated with 15 pull requests about the same issue.

Update re Mitigating Fingerprinting draft

christine: Also, we would like to get to a CfC to publish Mitigating Fingerprinting draft as a IG Note.
... I'd like to give nick and jason some time to talk about that if they'd like to.

nick: Is there someone in charge of driving the work on the questionaire forward?

christine: The person who has the lead in the TAG is Lucas, but all of the TAG members want to be able to make changes to the document. They'll get X number of PRs in a document. I think what they'd like to do is have a new draft ready by TPAC for discussion.
... I haven't done a good job to date - would like to be our shepherd, I should start that today... via discussion on email list. Here's the current text, what is missing, etc.
... If you'd like to volunteer to do that, Nick, I'd be happy.

npdoty: Sounds like a good approach, revised version by TPAC would be great.

jason: Are you envisioning that we'd go through each question via email or would a different process be better? Everyone looks at each question, we spend entirety of call addressing each one, one by one.
... Question by question approach makes a lot of sense... mailing list or should we do it on a call

<npdoty> we'd also want to generate potential additional questions, things that we've noticed coming up in other reviews, etc.

christine: We'll use a mix - some things are better on a list, some are better on a telecon. We shouldn't wait for a call... maybe we could do a special call?
... Oh, one last thing - Fingerprinting -- nick or jason?

jason: We have some new issues, I've been asking people for reviews...

christine: Next call...

next call

Tara: I'm available for most of September.

christine: 13th?
... Going once, going twice - September 13th is the next call, usual time.

Shivan's blog post

<weiler> Here's the link: https://www.article19.org/resources/privacy-and-consent-in-the-age-of-browsers-the-question-of-webrtc

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/08/09 17:09:41 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/narrow/narrower/
Succeeded: s/it/the concern/
Succeeded: s/jnovak: I think/npdoty: I think/
Succeeded: s/Lucas/Lukasz/
Succeeded: s/jason:/nick:/
Succeeded: s/this/the work on the questionaire/
Succeeded: s/Jason/nick/
Present: alex_ortizia christine dan_b dave_l jnovak joe_a manu_sporny npdoty shivan tara Matt_Stone weiler JoeAndrieu dave_longley adrian_gropper Joe_Andrieu burn
Found ScribeNick: weiler
Found ScribeNick: manu
Inferring Scribes: weiler, manu
Scribes: weiler, manu
ScribeNicks: weiler, manu

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 09 Aug 2018
People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]