See also: IRC log
<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
http-auth@ietf.org
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]
draft-oiwa-http-*
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
http://www.w3.org/2011/07/privacy-ig-charter
<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
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]