02 Nov 2011

See also: IRC log


npdoty, aleecia


<npdoty> scribenick: npdoty


hhalpin: recap what's happened
... interest in identity
... from a workshop, saw most interest in common JS cryptography api
... shocking amount of consensus that a minimal API would be useful
... less consensus on covering identity topics as well
... wouldn't this work be better in webappsec? they said no thanks
... one charter with separate groups for identity and cryptography

<ddahl> Web Cryptography charter http://www.w3.org/wiki/IdentityCharter

fjh: is the scope appropriate?

<ddahl> http://www.w3.org/wiki/IdentityCharter#Web_Cryptography_Working_Group_Charter

@@: do you have enough people to do both? if the interest is mostly in cryptography, why not just do that?

<ddahl> http://www.w3.org/2011/identity-ws/report.html

MarkWatson_Netflix: the problem space for cryptography is much more defined than the identity space; identity feels like there are a number of different proposals
... split off the cryptography API now as something to get done now
... suggest a separate cryptography working group

SteveH_: are these the same people anyway?

Virginie_Gemalto: crypto is much larger than identity, and so should be separate

tlr: does the room know the exact content of the identity work?

<fjh> +1 to tlr, please clarify identity portion of charter

tlr: agreement to starting work on cryptography and key issues, a tractable set of problems

[ Identity Jokes ]

hhalpin: we had a workshop on identity where half the people were also involved in cryptography
... if the client had some ability to sign things, then the client could sign things which would benefit the existing identity frameworks

<ddahl> https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest

hhalpin: Mozilla would like it for BrowserID, for example
... feeling like the identity API might be a thin layer on top of the cryptography primitives
... concern expressed that some problems were quite hard (like key storage), having use cases is important

<ddahl> DOMCrypt API draft: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

hhalpin: identity systems work by transmitting claims, and proving that the claims came from an IDP, proof done through some kind of signatures

stpeter: the identity piece is a customer of the crypto api, but not the only customer

rigo: have you taken into account that identity is one of the privileges of the king?

[no one understands at all]

<aleecia> Um. What?

rigo: goes to the fundamentals of a nation state

adrianba: not an expert, but the charter is very browser centric, a JavaScript API could work very well beyond just the browser -- widget, nodejs, other environments

<Josh_Soref> [ Josh_Soref: The charter visibly is heavily scoped to a Browser ]

adrianba: regarding specificity, not clear to me which use cases we're addressing or how we would know we were done

<Josh_Soref> [ Josh_Soref: The charter is visibly vague on use cases: "Use cases include identity on the web and advanced protocols between web applications. " ]

<ddahl> use cases page for DOMCrypt (needs updating): https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

<stpeter> Jan Lindquist

Jan: content protection would be one important use case

<michaelhanson> JOSE WG charter is http://www.ietf.org/dyn/wg/charter/jose-charter

hhalpin: because there was less representation of content providers at the workshop we didn't go into as much on that, but those would be good additional use cases

<SteveH__> 05process issue: did we want to timebox the charter discussion to 30 mins?

hhalpin: use cases would be a deliverable of the group itself

adrianba: my general concern about W3C charters is that the work isn't specific enough, which makes it hard to know if it's valuable enough to participate

<SteveH__> 05

<Zakim> Josh_Soref, you wanted to mention http://www.w3.org/2011/11/02-identity-minutes.html which was an earlier breakout

<Josh_Soref> There was a previous breakout http://www.w3.org/2011/11/02-identity-minutes.html on identity

<inserted> tlr: that was an unfortunate scheduling item, a number of us here could not be there and we asked them not to do it

we'll go through the q and then tlr will ask a straw poll and potentially split out of the room

dsinger: too much about browsers and users and needs to be written in more abstract terms (echo adrianba)

mark: device identity is an important part, which is also important for content protection
... out-of-band distributed keys as a core use case

tlr: summary, crypto API inspired by domcrypt which has significant interest but needs a crisp, clear and bounded scope
... does anyone have a specific identity-related API with support from beyond themselves?

<Josh_Soref> +1

tlr: have another identity workshop in half a year

<inserted> [ there was no one who stepped forward to claim a spec with support from another party ]

hhalpin: one month to iterate the crypto api, then ship it to AC review

<fjh> +1 to scoping carefully and tlr

hhalpin: please help clarify these use cases

stpeter: and encourage more people to get involved here

tlr: who is interested in finding time today to write more on the charter? (outside right now)

dsinger: need an activity area for privacy/security/identity as a cohesive set of problems


Yukata: many people agree that the auth is broken
... hard for users to check when entering their password that they weren't redirected that they aren't being phished
... limited usage beyond Basic HTTP Auth
... TLS has client authentication, but also only limited auth
... form authentication is widely used but has lots of problems
... a better HTTP authentication is required
... passwords the simplest to understand
... but other authentication means are necessary (need expert help)
... What should we solve? What is the scope?
... finding people who are interested in helping

IETF draft available, would appreciate input


Yukata: proposal for HTTP Mutual Auth
... a much more secure password authentication
... server sends a challenge message to the client, so that the client can validate the server as well
... server uses a stored secret to authenticate itself to the client
... input names for username and password in the browser chrome itself

[demo of the protocol in use on a browser]


fjh: SHTTP may have tried to do something similar

<dsinger> https://www.rcis.aist.go.jp/special/MutualAuth/

yukata: easier to implement because compliant with existing HTTP auth [paraphrasing]

Jan: at what stage do you store the shared secret token?

<rvaneijk> Thank you David

dsinger: one of the reasons against using HTTP auth is that sites want to integrate it into their page rather than the user chrome
... discussion at the identity workshop about form labeling technologies in the user agent

dsr: but users can't generate good passwords
... fan of Mozilla to get the browser to generate the password

alex: vulnerability to man-in-the-middle during initial registration

yukata: issues with phishing on the first site


Privacy IG

<scribe> scribenick: aleecia

npdoty: not much time, send me feedback. AC review & approval for privacy interest group.

<fjh> see also http://www.w3.org/TR/2011/WD-app-privacy-bp-20110804/

… Additional topics and cross-WG privacy issues. Ex: P3P, Tracking protection WG. Others like fingerprinting, local storage, cross multiple WGs

…Would like an interest group to think about how W3C can do better across specs.

…could do guidelines, or locus of expertise. Often privacy takes legal and technical together.

…send out formal participant call as we work out chairs, ideally later this month

alex: Lot to be gained by a privacy layer across social media.

… Ex: bucket gender or age group for release, could have spec that's open and W3C controlled, makes more sense than each social media has their own untrusted

Frederick: privacy is a systemic issue, so hard for a single WG to deal with in isolation.. For web applications for example, issue include web applications control, date retention, reuse:that is out of most wg scope. Informed consent means what's being done with data and by whom

…don't think any single group could deal with it. This would be helpful, but not sure it's possible.

…supportive of increased awareness. Not sure how it would address technical

dsr: is privacy a horizontal group?

Frederick: would have to

Rigo: past AC meeting, security guys said "you don't get a free ride in security consulting." If the IG path, could lack the support needed. Only makes sense if we have commitment that several actors come together -- if you're a privacy advocate you are deeply annoying everyone else.

Peter: not enthusiastic about a group to review output of other groups. In favor of IG that develops best practices and processes that groups are advised to follow

…avoid CSS issue with privacy called out, "don't have to follow spec if you want to fix the privacy problem," instead let's fix the spec.

…MSFT would be involved

David: Group can come to IG for help, not the other way around, or it's an unbounded work load

…start with "this is how you write a privacy considerations section"

…make it better each year

Robert: two success criteria. Establish systematic process could be general for such a group. Within data protection world, privacy impact assessment gets to "select before you collect" and PbD.

…part of risk management approach in security, can apply here. Side effect: raise awareness. Main goal: systematic approach where privacy is quality criteria.

adrianba: agree in general.

…anything that makes it better is worth doing, low bar <laughter>

%%: identify new problems? Other solutions in other standards? If no solution, look for a way to find one.

…scope for the interest group

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2011/11/02 23:38:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s|Q?||
Succeeded: i|recap|Topic: Crypto
Succeeded: s/@@/hhalpin/
Succeeded: s/hhalpin/@@/
Succeeded: s/%%/SteveH_/
Succeeded: s/@@@/MarkWatson_Netflix/
Succeeded: s/<identity jokes>/[ Identity Jokes ]/
Succeeded: s/very cool//
Succeeded: i|go through the q|tlr: that was an unfortunate scheduling item, a number of us here could not be there and we asked them not to do it
Succeeded: i|one month|[ there was no one who stepped forward to claim a spec with support from another party ]
Succeeded: s/%%/alex/
Succeeded: s/%%/dsr/
Succeeded: s/doesn't work modularly in a system/is a systemic issue, so hard for a single WG to deal with in isolation./
Succeeded: s/Those who create JS or content/For web applications for example, issue include web applications control/
Succeeded: s/%%/adrianba/
Succeeded: s/ privacy is a little out of scope/that is out of most wg scope/
Found ScribeNick: npdoty
Found ScribeNick: aleecia
Inferring Scribes: npdoty, aleecia
Scribes: npdoty, aleecia
ScribeNicks: npdoty, aleecia

WARNING: No "Present: ... " found!
Possibly Present: David Frederick Jan Josh_Soref MarkWatson_Netflix Peter Rigo Robert SteveH_ SteveH__ Suresh Virginie_Gemalto adrianba aleecia alex ddahl dsinger dsr fjh hhalpin https inserted joined mark michaelhanson npdoty nwidell privacy rvaneijk schunter scribenick shepazu shunan__ stpeter tlr vgalindo yoiwa yukata
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

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

Got date from IRC log name: 02 Nov 2011
Guessing minutes URL: http://www.w3.org/2011/11/02-privacy-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]