<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: @@
<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!
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.
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?
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.
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.
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...
Tara: I'm available for most of September.
christine: 13th?
... Going once, going twice - September 13th is the next call,
usual time.
<weiler> Here's the link: https://www.article19.org/resources/privacy-and-consent-in-the-age-of-browsers-the-question-of-webrtc
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]