W3C

- DRAFT -

SV_MEETING_TITLE

24 Jan 2013

See also: IRC log

Attendees

Present
+358.504.87aaaa, +1.613.947.aabb, bblfish, +1.509.375.aacc, tara, fjh, estephan, JC, npdoty, TallTed, Frank_Dawson_yrlesru
Regrets
Chair
SV_MEETING_CHAIR
Scribe
npdoty

Contents


<JC> Npdoty: We are performing reviews informally though we have talked about different documents

I was starting to collect resources around Privacy Considerations on the wiki here: http://www.w3.org/wiki/Privacy/Privacy_Considerations

(that list is too short, apologies, I need to dump more links here)

<scribe> scribenick: npdoty

fjh: took away some concrete suggestions
... in particular, note a security consideration around combining light/proximity with other information

<fjh> Three points: 1. thank for reviewing these specs and for taking DAP as a first case

fjh: but then some other comments went beyond what I thought was in scope for these APIs themselves

<fjh> 2 concrete take away, possibly add privacy consideration on risk when information combined from various APIs

<fjh> 3. noted PING discussion went further beyond the DAP context of the spec, in future call for review may need to include some system context

hannes: some comments that don't give useful to the author of a specification; how could we take this into account beyond stopping work?

<fjh> 4. not sure I received any other take aways

no one was surprised about the event synchronization privacy leak? and here I thought I was being original ;)

fjh: appreciate the time and effort; started with smaller and more isolated specifications
... other specs would be richer down the line

<JC> Tara: You had the proximity spec as well?

<JC> Yrlesru: Yes, and I basically had the same comments for it

<JC> ... the process was valuable for getting feedback and improving the review process

<JC> Npdoty: There is a chance for gleaning information from light sensors, but not with high, med, low settings

<JC> Tara: Henry will cover his outstanding item

npdoty: we learned or noted rather generalized advice regarding device apis that refer to background sensors

<JC> fjh: Should a formal response of the reviews be sent?

<JC> Tara: An informal response is fine. We would like to see the final response.

I think Erin had actually written up a pretty detailed or formal version

<JC> Henry: I chair web ID incubator group

<JC> ... identity is an important part of privacy

<JC> ... I am interested in feedback from PING

<JC> ... something is private or public

<JC> There is a difference between public and publicized

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/Main_Page

<JC> ... we have created a few specs, see URLs

<bblfish> https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html

<bblfish> http://www.w3.org/2005/Incubator/webid/spec/

<JC> ... we have an authentication spec for authenticating over TLS with WebID

<JC> ... also an interoperability spec, but only a beginning

<bblfish> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability

<yrlesru> Justin Brookman and Thomas Roessler say hello from CPDP.

<JC> ... there are many ways to do authentication and they can be separated for different agents

<JC> ... ID and password is not good enough

<tara> Hullo back to them!

<JC> ... for a globally distributed social web creating new accounts is too tedious

<JC> ... this has created centralized authentication services, which cause privacy problems

<JC> ... we want distributed, decentralized social webs to have privacy

<JC> ... otherwise the biggest players will control all of the data over millions of users

<JC> ... this may be counterintuitive in this space

<JC> ... we would like to have specs to cover the privacy side

<JC> Tara: So you would like the group to address privacy considerations, which includes identity considerations

<JC> Henry: We are working on identity which has privacy considerations

<bblfish> http://www.w3.org/2005/Incubator/webid/spec/#publishing-the-webid-profile-document

<JC> ... we haven't yet put this into the simple spec, but it is in the SSL spec

<JC> ... you can control access to sensitive information with access control

<JC> ... without access control you cannot get the larger elements of privacy

<JC> Npdoty: A lot of concerns have been expressed about lack of anonymity on the web.

<JC> ... identity is important for authentication so we know who are friends are.

<JC> ... I can see that there is a lot of identity work and could be like the sensor review where the responses are similar

<JC> ... we should think about how we can condense the work or provide general responses

<JC> Hannes: identity on the web is not new

<JC> ... it should be possible to reuse previous work

<JC> ... it not so much the protocol, but the deployment in the way companies use the technology

<JC> ... OpenID is a distributed system, but most companies want to own the identity.

<JC> ... so I don't see how you avoid the tendency for systems to want to own it in deployment.

<JC> Henry: The business model is difficult. Some want to get greedy and can become too big.

BrowserID that I mentioned, is documented as a spec here: https://github.com/mozilla/id-specs/blob/prod/browserid/index.md

(the basis of the project for Mozilla Persona)

<JC> ... there are always players that want to work with other orgs and the current systems are orthogonal to each other

Hannes mentioned OpenID: http://openid.net/

<JC> ... in the WebID spec there is no need for a login button. We do it without need for redirect

<JC> Tallted: Privacy concerns here are multiple and challenging. This group can provide guidance

<JC> ... for users and spec builders

<JC> ... WebID is like a membership card.

<JC> ... a simple example. In Star Wars universe I want other rebels to know I'm a rebel, but not imperial guard

<JC> ... same if I am an imperial guard

<JC> ... I want to express my identity and conceal by choice.

<JC> ... I may not know all rules as I start and will need to figure it out as I go

<JC> ... people sometimes don't understand that rules are needed at start

<JC> ... if people know the rules up front the may be okay with that

<JC> ... but they may want to know what happens to their data once it is captured

<yrlesru> So, JC is talking about need to know data flow diagram of the use cases, so to know control point for privacy safeguarding controls?

<JC> ... everyone has a user base and wants to become an identity provider

<JC> Henry: It can be tied to a government ID system

<yrlesru> ... And threats at points of control for privacy data lifecycle (collect, use, store, transfer, delete)?

<JC> Hannes: If it is the same can't we use the same identitly system

<yrlesru> Hannes not on IRC.

<JC> Henry: I don't want to have a debate about which is the best system

<yrlesru> He is in a sauna in Helsinki.

<JC> ... because we are using linked systems and protocols tied to the web

<JC> ... we can build distributed systems quite easily

<bblfish> http://bblfish.net/

<JC> ... I have videos about the philosophy of the social web

<JC> ... the WebID differentiates the URL from the identity

<JC> ... we can work with OpenID and that is what the page is about

<JC> ... we need lots of thinking about how these things interoperate well

<JC> Tara: We should take this to the mailing list and encourage people to provide feedback you would like to see

<JC> Henry: I will propose to working group to work on privacy section and we can progress from there

sounds good.

<JC> Tara: Next item - privacy impact checklist or impact assessment from Frank

<JC> ... we need to get these documents started

<JC> ... not a formal process but things people should consider when writing specs

<JC> ... do you have progress on this

<JC> yrlesru: I have had an opportunity to present the idea at several venues

<JC> ... I don't have a draft, but there is previous material

<JC> ... there is a draft 6 of privacy considerations

<JC> ... here at CPDP there were comments similar from W3C feedback

<JC> ... I'm looking for guidance from those on this call on what engineers want on privacy guidance

<JC> Tara: Does anyone on call want to respond?

<JC> Npdoty: I like the point on moving to something more systematic

<JC> ... the checklist got added from the ad hoc review

<yrlesru> Here in CPDP we are hearing about what EU funded research and policy makers are saying needs to be done in a privacy impact assessment.

<JC> ... as the reviews occurred we came up with questions for the next review

<yrlesru> They say the assessment should consist of:

<yrlesru> - Include stakeholders (here the people defining spec),

<JC> ... that match IETF experience with privacy considerations

<JC> Hannes: The generic questions that we saw are in the privacy considerations draft

https://datatracker.ietf.org/doc/draft-iab-privacy-considerations/

<JC> ... there are lots of things that repeat, though there are slight nuances

<JC> ... the point is to make people think about the questions

<yrlesru> - Data flow analysis so you understand the data flowing between trusted control points and external interactors, classification of data so that personal data identified and which of that PD is "identifiable", "linkable", "observable",

<JC> ... we need to make the assessment again and again

<yrlesru> - Then understand where threats are against identified privacy principles,

<yrlesru> - Mitigation of threats,

<JC> Tara: Nick fingerprining?

<yrlesru> YES, Kiitos Tara, will take comments to mailing list...

<JC> Npdoty: We should move this to next call.

<yrlesru> - Lastly, mitigation to threats.

<JC> ... One thing that was mentioned was that the TAG provides high-level architecture guidance for the group

<JC> ... they had some advice on fingerprinting

<JC> ... I will look at the work and see how it can be combined.

<JC> Tara: 21 or 28 for next call?

February 21 or February 28

no conflict on either day for me

<fjh> i could be 30 min late on 21st

<JC> ... next call on February 28

<fjh> thanks

<JC> ... thanks to everyone!

<bblfish> thansk

<yrlesru> Thx!

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/01/24 18:02:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Yrlesru/fjh/
Succeeded: s/Herny/Hannes/
Found ScribeNick: npdoty
Inferring Scribes: npdoty

WARNING: No "Topic:" lines found.

Default Present: +358.504.87aaaa, +1.613.947.aabb, bblfish, +1.509.375.aacc, tara, fjh, estephan, JC, npdoty, TallTed, Frank_Dawson_yrlesru
Present: +358.504.87aaaa +1.613.947.aabb bblfish +1.509.375.aacc tara fjh estephan JC npdoty TallTed Frank_Dawson_yrlesru

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


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

Got date from IRC log name: 24 Jan 2013
Guessing minutes URL: http://www.w3.org/2013/01/24-privacy-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


[End of scribe.perl diagnostic output]