<trackbot> Date: 10 September 2014

<inserted> scribenick: wseltzer

Welcome, Introductions to W3C and Workshop Goals

Harry: Welcome, thanks to Virginie for chairing
... Thanks to Microsoft for hosting, Tyfone and Google for sponsoring!
... A W3C workshop aims to set the basis for open standards
... W3C is a global consortium
... Royalty-free patent policy creates a common foundation for innovation on the Web
... We welcome opportunities to work with other standards organizations through liaisions
... W3C works by consensus
... We've been thinking for a long time about security and identity
... Started with "Identity in the Browser" workshop a few years ago, from which we chartered WebCrypto WG
... Now looking at where we can help develop the platform further

Virginie: WebCrypto has been discussing the Crypto API, and beginning to discuss next steps
... crypto is a well-developed science, the challenge is bringing it to the Open Web Platform
... we're here to learn, share, and then reach conclusions tomorrow afternoon

-> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule Agenda

<JeffH> I can help with this first session

[Virginie introduces irc, scribing]

Virginie: Over to our sponsors

<JeffH> virginnie or you might want to emphasize the IRC facet of this meeting

Tony_Nadalin: Welcome to Microsoft

Dirk_Balfanz: Google is here because we're interested in secure authentication

Siva_Narendra: Tyfone is a 10-year-old security company
... if we all do the right thing in the next couple of days, we can bring about an inflection point for hardware-based security in web standards
... We believe in the separation of church and state. We all have our views, but W3C is a neutral place for discussion.

<tarcieri> woo backchannel

<inserted> scribenick: JeffH

wseltzer advertizes this public backchannel and note taking confab

Peter Cataneo is up

iCattaneo

from Intercede

<rbarnes> is that what the "i" stands for?

:)

<Pea> Ok

<wseltzer> Peter_Cattaneo: We should make sure that existing credentials will work in the new environment

asks question "will whatever we do wrt 'identities' online work "with" existing meatspace and online creds ?

<Pea> where is the paper tape.

<solar> hello irc

<sep_of_church_state> yeah....and floppy disk?

<solar> it’s been a while

<virginie> Note : communication on this workshop on social media can with #cryptonext hashtag

Peter_Cattaneo: notes there's a large deployed base and the need for "credential lifecycle management"

<sep_of_church_state> 60 billion IDs

<sep_of_church_state> Just plastic is 30 billion

<rbarnes> http://upload.wikimedia.org/wikipedia/en/thumb/7/73/Billions_and_Billions.jpg/150px-Billions_and_Billions.jpg

Peter_Cattaneo: emerging issues: user-managed/self-asserted 'identity' -- emerging standards -- privacy issues

key engagement points for W3C effort(s) to consider: enable usage of existing identities;

scribe: support multiple cred stores
... enable both closed and open sysstems
... suitable for common use cases; optionally include cred mgmt

<sep_of_church_state> Nice intro from Peter!

<wseltzer> rbarnes's slides

Richard Barnes -- Mozilla -- possibilities for hardware tokens in the web

<sep_of_church_state> Richard talking from Web API perspective....what are we trying to do here...as functions.

richard_barnes: passwords suck

<tarcieri> acceleration-- identity++

<tarcieri> Persona :(

<sep_of_church_state> Point solutions are Bazillions...and BAD!

<sep_of_church_state> Point solutions are Bazillions...BAD and creates barrier to entry / implementation...

<wseltzer> rbarnes: good design pattern, build a box to encapsulate functions we need

<wseltzer> ... then implementations plug in underneath

<wseltzer> ... e.g. WebRTC

<sep_of_church_state> and PKCS11

<sep_of_church_state> Lets not discuss SIM API, Smartcard API or FIDO API...it is NOT useful....think about how to find a box for baseline for the web

<bhill2> respecting Richard's caveats about not being experts in these technologies, FIDO APIs are functional APIs, not implementation-bound

+1

<sep_of_church_state> -1

<sep_of_church_state> Dirk speaking with Google and FIDO hats...

<martin_paljak> rbarnes: the message was right. although plumbing is neeed, functionality is what needs to be implemented.

Dirk_Balfanz: Device-Centric Authentication and WebCrypto

<rbarnes> i should have also mentioned: ther web is much more dangerous than typical token deployment environments. there are are a bunch of privacy risks that come up when you ponder exposing long-lived credentials to the web. IIRC FIDO has some good concepts in this domain, might be a good starting point.

<wseltzer> Dirk: user authenticates to the device, make it the responsibility of the device to do something better than passwords

<harry> what's the right level of abstraction is the tricky question

<sep_of_church_state> the right level is something that will be branding independent....and point solution independent

Dirk_Balfanz: notes separa tion of 'user verification' and subsequent device-bound crypto authn foils phishing

<rbarnes> yubikey™

Dirk_Balfanz: gives demo of FIDO U2F login

<sep_of_church_state> FIDO(TM)

Dirk_Balfanz: shows snippet of client-side webapp JS code effecting the U2F login

<sep_of_church_state> should be neither hopefully

<harry> we are trying to bring these communities and others together

Dirk_Balfanz: notes wishlist for client-side JS api needs to effect this stuff

<sep_of_church_state> right...we should take smart card, sim card, tee, tpm, fido...and put a box on top of all of them

<martin_paljak> it is weird that they are mentioned separately, sim cards usually are smart cards...

<harry> dirk's likst 1) keys origin bound but outside browser 2) adds info to-be-signed data 3) bound to local authentication 4) attestation 5) key discovery of local authentication mechanisms

<harry> Again, the trick is finding right information flow and right level of abstraction

<rbarnes> sep_of_church_state: http://imgur.com/1ZAvBzd

<harry> we'll want to allow innovation both on hardware/middleware layers but they need to be able to communicate to webapps

<bhill2> sep_of_church_state: FIDO UAF already is a box on top of smart card, sim, tee, tpm, etc, as well as many types of local verification ceremony

<martin_paljak> bhill2: last time i checked there was no concept of certificates though ?

<sep_of_church_state> bhill2: yes, but has a trademark and certification...

<rbarnes> martin_paljak: seems like an optimization. provide cert alongside sig/pubkey

<sep_of_church_state> pvt key pub key certs....without pki ...is well know...why a trademark?

Dirk_Balfanz: what's not on wishlist
... 1) an "authn" API 2) a way to talk to UA re user accounts 3) a new UI that the UA needs to show

<sep_of_church_state> Dirk: Did a neat demo

<harry> Not on Dirk's list - authentication API, making user choose account, etc.

<AdrianC> Agree that drawing UI should be left to the Web application. However, it could be useful to define guidelines to help users understand what they are doing.

<martin_paljak> at some stage you want "a bit more trusted" UI, meaning that there are elements of the UI that are not possible to change by the web application.

<martin_paljak> i fished PIN codes with simple javascript.popup("enter pin") once for a demo. worked.

is sep_of_church_state Mr Siva Narendra ?

<sep_of_church_state> Yes JeffH

<nvdbleek> rssagent, pointer

dirkb queries rbarnes wrt 'what is a point soln' ?

<tarcieri> martin_paljak: "powerbox"

<inserted> Dirk: How do we identify "point solutions" to avoid?

rbarnes: what is the function we're trying to achieve? thinks there's several of the examples he cited are examples, and wants to craft a layer above them that generalizes them; thinks dirk's wishlist is headed in that way, and PeterC's usecases are applicable, wants to find the meeting point of all that stuff

Siva if we just state reqs, then we can "put them in the box"

<wseltzer> s/???/Siva_Narendra/

<Axel_> Does it make sense to have irc on the screen instead of the hotel list?

HannesT: thinks jury is still out wrt webRTCs approach/success
... generalizing isn't going to be that easy

<sep_of_church_state> Jury is out all authentication mechanisms

<karenlu> q

rbarnes: wrt new creds and existing deployed base -- thinks backwards compat is a question

<solar> yes - why don’t we put irc on the screen

<martin_paljak> another risk is over-generalization.

<solar> nice

<martin_paljak> something that many existing standards do - leave too many things "open for vendor choices"

PeterC: an example wrt bkwards soln, is to take one of those things in the deployed base and go thru exercise of putting them into the new world and see how it works
... eg Karen Wu may talk about some of this; existing smartcard apis need some work....

<solar> good work

<sep_of_church_state> we should abstract away from smartcard or any other low level API

rbarnes: the fido api, other api are 'useful' in sense we can learn from them to pull stuff into a more general API

<sep_of_church_state> JeffH: Agreed, as long as we don't name a well understood concept with a trademark

<sep_of_church_state> It should be like SSL or TLS...

<sep_of_church_state> ...from a naming of the "box"

<Nadalin> and then we have general APIs that are so general they are useless

Philip Hoyer: crypto solutions are good when they work, but when they fail they are spectacular --- forcing a pattern of protocols that focuses on the client side is dangerous -- need to find something where we can innovate end-to=end

<bhill2> sep_of_church_state: trademark relates mostly to attestation of devices that relying parties really want, but is optional at a protcol sense

eg sees in FIDO a lot of innovation on client side

dirk: ACKs your point, but sees a danger in being too general and we are going to need to carefully balance

<harry> Dirk: To build frameworks to build building blocks to build solutions :)

<bhill2> dirk doesn't want to build frameworks to build building blocks to plug into solutions

<bhill2> … dangers in being too general

virginnie: notes we need to prioritize use cases we want to solve in order to figure this all out

dirk: wants to make passwords less of a useful target to the bad guy

if they still are used, they should be relegated to 'local use'

<sep_of_church_state> dirk: software keys better than passwords....hardware keys are even better

wants to employ crypto to make all this happen; server side need efficient signature verification; the hard part is on the client side to mint keys per server; even software keys are better than "passwords"

PeterC: one success story in this area is that everyone in US government has a govt ID card w/secure element and it works for windows login out of box

<tarcieri> this sounds like SunRay circa 1999 ;)

<harry> CAC/PIV cards I assume

<sep_of_church_state> PeterC: Govt smart card PIV is a good example of

PeterC: wants web logon to work that smoothly....

<solar> software keys on a seperate device (out-of-band) is almost on par with hardware based key storage on the same device

<tarcieri> solar: except you can remove an external hardware token when it's not in use

rbarnes: notes dirk's use of crypto, thus why we're putting effort into web crypto; also have to pay attention to the privacy side of this and not make it worse;

<tarcieri> you can also use an external hardware token with multiple devices

<harry> Mozilla is out of business of implementation-specific token support... quite interesting

<sep_of_church_state> rbarnes: tyring to move mozilla away to more standards based framework that is general than smart cards

rbarnes: also need impl-specific considerations, in firefox, have support for some sorts of smartcards, but want to make that more uniform and support more kinds of tokens

<wseltzer> Bruno Jarvary, Oberthur

<solar> tarcieri: example: when signing in to gmail from desktop, send authentication request to phone (where software key resides) and ask user if they want to allow access to that key by that specific machine

<FaSo> as password can be weak beacuse people takes simple password easy to remember, or wirte pwd on a postit and leave it under the desk, wom people might leave a smartcard inside their laptop all the time

<solar> concept of “out of band” display vs “secure display” is also an interesting one

Bruno: asks dirk about the JS api he was using in the demo and code snippet

<Axel_> Mozilla and Telekom Innovation Laboratories are implementing Secure Element API that @rlbarnes mentioned. https://bugzilla.mozilla.org/show_bug.cgi?id=879861

<tarcieri> FaSo: that's why requiring a button press is nice

dirk: the api was provided by a browser extension, so sorta cheated
... ultimately want a baked-in api that has a simply "sign this please" api --- not much different from what the extension does

<tarcieri> solar: another use case is I don't want to put the secrets for the second factor on my phone, but still have a hardware token that works both with a desktop/laptop (via e.g. USB) and with a phone (via e.g. NFC)

<sep_of_church_state> karenlu: smartcard authentication is local...and whatever solution is should [ideally] be applicable to existing IDs and we should define the box that way....

<solar> tarcieri: that’s a good point, but without a display on the hardware authenticator it severly limits the financial services usecases

<solar> and I believe they will be the ones driving this pretty hard

<sep_of_church_state> karenlu: challenges that while we should build a box...is fido a box or a service....JeffH you might be able to comment

<solar> nice!

<sep_of_church_state> karenlu: is a box small and generic or box very specific?

karen wu: gemalto: believes whatever soln arrived at needs to work with the deployed smartcards in the field, need to define the "box" thing, however if authn is a function, then you can plugin different authn means,so that satisfies the box metaphor, and the challenge will be to generalize the box, thinks her paper is in similar vein to rbarne's box notion -- the box can be very general, or more specific eg authn-specific -- plus we need to define something

scribe: browser vendors will support

karenwu: agrees ? is impt, but other things that are impt -- eg standalone signature and encryption -- and so we want to build a box that also supports those use cases

<Herve_SIMalliance> question/remark

<martin_paljak> I think we need to make clear if we want an API (most probably plumbing to the box) or a new set of protocols.

<sep_of_church_state> rbarnes: what we standardize is something 100s of millions of web sites will use....so it would need abstraction [to be at a higher level]

rbarnes: so our objective here is to define an API for the web, feels it is going to be an abstract api and wont be defined in terms of APDUs -- thinks fido stuff is a good start

<wseltzer> Jonas Andersson (Fingerprints)

<Pea> For me the question first is who is the trusted authority then what level of security do they require in order to secure the digital credentials they might be willing to provide

<Ullrich> Scope is unclear to me eg transactions need UI

<solar> agreed

<sep_of_church_state> Jonas: in response to rbarnes: we should also consider billions of users when thinking of standards (or box)

jonas anderson: fingerprint cards: looking to make a box that faces millions of websites, but the userfacing side will face billions of users -- working on ways to allow users to choose how they wish to identify themselves -- not all of us will be carrying BLE cards or Swedish ID cards -- need approp mechs that will be as easy to use for everyone as username/pswds

<wseltzer> note http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

peterc: agrees

<sep_of_church_state> peterc: agrees with caution?

rbarnes: going to need to have a plausible interaction story

<schuki> +1

<sep_of_church_state> +1

bhill: paypal w3c fido: but personal hat on: need to separate "identity" from "authentication" -- need to allow for authn without strong identification -- eg support authn'd anonymity -- need to create apis that do not mandate linkability

Detlef Hühnlein (ECSEC): we need to sparate using deployed ID cards from privacy issuess

scribe: german ID cards are priv-friendly

<adam_> brad, services are already choosing to mandate linkability eg through only working via logon with facebook

scribe: we all agree it will be good to get rid of pswds

<wseltzer> Detlef Hühnlein (ECSEC)

<bhill2> even a government id card with privacy friendly technology

<bhill2> is still not controlled by the user

<bhill2> they are often property of and can be revoked by the government

scribe: deployed things include smartcards, TPMs, etc

<solar> u-prove making a comeback?

scribe: we will need to support them

<bhill2> a user's participation in online communities should not be controlled in that way by their government identity

<martin_paljak> bhill2: government issues the identity (say, a certificate), yet the user controls the card.

peterc: notes that the privacy reqs are important and should be prioritized

<bhill2> but government can revoke the card

peterc: using id w/govt entity is different -- and should it be possible to use that ID with non-govt entities?

<martin_paljak> JeffH: of course. in Estonia there is one identity, one card, and you can use it wherever you want. Private or public sector or your home.

rbarnes: speaking from browser perspective problem is figuring out which websites ought to be able to leverage that ID card?

<wseltzer> Sean Michael Wykes, Nascent

sean michael: wrt the "box" proposal -- likes the local user authn leading to device authn -- but has use cases for signing docs -- and also authn'g transactions

scribe: who will supply the "box" ?
... already have too many diff apis and drivers to interface with specific security devices

,,,,also ask about the attestation notions dirk mentioned

<Martin> Good point about digital signatures - and also makes me think of Dirk's comment that the browser shouldn't have any special UI etc. and everything should be provided by the application. If the signing screens are provided by the application it makes it difficult for the user to be certain that what is getting signed is what they are seeing on the screen (since the application could go on and sign something different from what was shown).

<tarcieri> Martin: the browser should at least ask you if the site can have access to hardware tokens using its native chrome / "butterbar"

dirk: thinks that's a good point re 'box' -- have to carefully figure it out

<sep_of_church_state> personal comment: why can't box be what pkcs does and what fido does....and abstract it without either of the names

<engelke> Martin: both sides of the transaction should be able to specify a minimum level of out-of-band user consent to be enforced when signing.

<Martin> Solving this would require either the browser to be able to generate a trusted signing UI (that would always show what would ultimately be signed) or some sort of plug-in architecture where the user could install trusted signing extensions (which would provide the signing UI). Or maybe the identity of the application (or at least the modules that generate the signing UI) can be included under the signature (this would be forced by the user agent)

dirk: wrt attestation: in enterprise use case want to be sure the employees authn with the issued authenticators/tokens
... wrt privacy-friently attenstation -- hard problem

<Martin> tarcieri: Strongly agree :)

dirk: looking at google and consumer offerings, we'd be happy if you just not use pswds and not worry about the attestation

<tarcieri> things like pin entry should probably be handled natively by the browser too

<martin_paljak> with an approach similar to secure element /apdu level API it is not enough, as you have no idea what gets pumped to the device from an almost arbitrary website.

dirk: have a risk engine on backend

<tarcieri> lest a malicious script steals your pin

<solar> yeah - that’s back to the different device / out of band question

<Martin> engelke: I don't see how the user could specify the level since how can they be guarenteed that the out-of-band process takes place afterwards? It makes more sense the receiver of the signature defines the policy of what needs to be met before they consider it a valid signature. After all, they are the one running the risk.

<solar> easy to steal pins on one device

karen_wu: priv is impt -- in past few years have tried various approaches -- have ways to have 'personas' for diff service providers -- eg separate work from personal persona -- another thing is priv-enhancing credentials, aka anonymous creds -- diff crypto from pki -- can create a cred token on device, then SP can verify it is a certified cred, and only reveal what is necessary [selective disclosure]
... the cred issuer doesn't know wehre you used creds

<Martin> martin_paljak: True - in that case I'm thinking maybe the user could autneticate the installation of a trusted JavaScript module that would hook into the WebCrypto API and implement it using it's low-level knowledge of the hardware. The user would approve the installation of this module using some browser UI (which would display the signer etc. of the module) before it would be installed. Solves some problems; creates others!

karen_wu: mitigates IDP knowing who you've interacted with
... so a req is that the API should support these sortts of priv-friendly creds

peterc: most of the exisitng creds out there don't requre attestation (attstn) -- so your card has priv key, and in closed system they already know about the ID and key out-of-band
... attstn comes in when you have an open system

<solar> but it allows RP’s to pick and choose only authenticators they “like”

<bhill2> what rbarnes is describing for attestation is pretty much exactly how FIDO works…

rbarnes: attstn is bound up in the type of token./card you have --- and maybe a metadata service is needed so RPs/SPs can look up properties of the authenticators wielded with themn

dirk: when say attstn was meaning only a part of that complete loop

virginie: so we need to define attestation!

<bal> I'll be talking about anonymous credentials a bit in the next session (my team owns the U-Prove anonymous credential system). We have a U-Prove JavaScript client running today on top of our JavaScript WebCrypto library, but it does require access to BigNum underlying mathematical operations not exposed by WebCrypto today.

<solar> agreed

<solar> i need a muffin

perterc: is noting that RPs will need to discern between hardware-based authenticators and software-based authenticators (which is a use case for attstn)

martin_paljak: have a national smartcard in estonia, user use the cards online on the web -- cares about the software "in the box" -- right now have to supply sfwr to the users --

<sep_of_church_state> +1

<Martin> +1 !!!

martin_paljak: example of smartcards in windows, or eg fido -- likes them -- but we need to allow for a range of authenticators --
... just needs an API

<virginie> we will add Herve pierre in the speaker queue as his q+ was not registered

,,,wrt OSI, which layer are we creating the APIs? is it appropriate?

scribe: if we think we have lots existing systems, maybe we should look at why things didn't get adoption -- will just wrapping it in JS make it work or not?

virginie: we do have some requirements that have been expressed in the prior discussion (enumerates them)

<wseltzer> virginie: user choice, service provider choice, privacy, form-factor choice, enable innovation

siva: why don't we say wrt "the box", there's a few things that actually work, webrtc pkcs#11 fido -- lets start there and..
... ask what's common and see if we can distill them down to something common? start there?

<virginie> virginie : a box, taking into account user choice, service provider choice, being privacy respectfull

<tarcieri> don't forget encryption! ;)

rbarnes: bhill's notion of separating authn and identity might be useful in this context

<virginie> virginie : ... a box allowing user anoicesd service provider ch

<virginie> virginie : ... a box allowing user and service provider choices

<virginie> virginie : ... a box usable for different form factors and credentials type

bhill: wrt priv preserv stuff -- in past, having identifiying technologies is default, and user must manage the priv stuff ---
... thinks we should invert that and have priv-protecting be the default and then user must do extra stuff to reveal themselves to RPs/SPs

<virginie> virginie : ... a box allowing operations to happen in server or client

<sep_of_church_state> peterc: fact: born in berkeley....fiction: works for a smartcard company!

<virginie> virginie : ... a box leaving space for innovation and usable by millions of websites and billions of users

peterc: believes the non-standard priv-preserving crypto is going to be tough to employ.... (eg Chaum's crypto)

+q

:(

rbarnes: maybe not that hard?

perterc: but you use all that cool crypto and then put your IP addr on the packets you send.....

wseltz: it's no accident that W3C's Technology & Society domain has both security and privacy considerations. I also pointed out the "priority of constituencies": user interests first, then developers and implementers. -- another item wrt attestation....
... how do we do all this in "open" systems -- open to dvlprs and users -- how to strike right balance?

sean: wrt atesstation -- wrt internet banking use case -- man in browser attack
... evil JS injected into browser -- the whole of the stack needs to be trusted, or if there's bad stuff in the stack, it can't do anything --
... eg for a bank transfer -- what if the numbers can be changed by malware before it's signed?

<solar> Secure display or out of band display

<solar> that’s what you need

<tarcieri> or a powerbox in the browser

<solar> trusted UI is only required if it’s on the same device

<martin_paljak> define "powerbox" ?

<solar> if it’s on a different channel you’re significantly reducing the risk

<solar> which is why FFIEC has accepted it

dirk: calls this transaction authorization (authz) -- the more general case of xaction authz is tough cuz need trusted UI (is hard...) --

<tarcieri> martin_paljak: http://c2.com/cgi/wiki?PowerBox

dirk: we've thought about it in FIDO context....
... also, we don't need to solve the Man in browser prob in this context

<tarcieri> martin_paljak: a UI provided by the browser which makes it difficult for web content to impersonate

[[ we are over time ]

<solar> without solving MITB it’ll be difficult to garner FI support

<Martin_> is q closed?

<tarcieri> martin_paljak: e.g. something that pops up over the browser chrome

<virginie> to martin, yes queue is closed

peterc: observes that pushing things down into hardware tokens helps mitigate such anattack...
... notes that such a hard-token might have a trusted UI associated with it

<martin_paljak> tarcieri: oh, ok. that's what we implement currently with plugins, yeah.

<Ullrich> FIDO UAF does transactions and nerds a UI

<wseltzer> Our goal is to develop a list of tasks and priorities, certainly not to solve them all at once

rbarnes: notes that there's protections out there for much of these threats -- not job of web crypto api to address them
... eg webapps ought to take advantage of things like content sec policy (CSP) to help mitigate script injection attacks

<tarcieri> can we trust the browser? Let's ask Douglas Crockford ;) https://d23f6h5jpj26xu.cloudfront.net/hvcrmeegvjrczw_small.jpg

<harry> I think the perhaps they are talking about browser code being compromised, like NSA's attack on Firefox to get around Tor :)

<harry> Anyways, re Doug Crockford's point, please see the point about getting the user to install trusted updates properly:

<martin_paljak> Jsut a small comment, that banking examples are not appropriate, as banks introduce hardware not so that users would trust it more but to mitigate risks and losses.

<solar> correct - in other words: to make it more secure

<solar> which is an interest shared by both banks and users imho

<harry> In browser, right now all code does of course have a trusted "Trent" in form of origin

<harry> more separation between that and some user-controlled private key material is probably a good thing

<tarcieri> "interest shared by both banks and users imho" <--- when you can trust the browser in Douglas Crockford's perspective, because the user and content provider's interests are aligned

<harry> however, the Web has proven to be much easier at delivering code to users than many other mediums

<harry> most 0days are in plug-in

<harry> "interest shared by both SERVERS and users imho"

Phil_Hoyer: need to figure out some way to be able to tell whether the user intended to perform the action....

<martin_paljak> well, I'd say that right now we have JS-OpenSSL. Now we need something like JS-PKCS#11 to satisfy existing token owners ;)

<solar> yes - authentication with context

<harry> But in general, getting users to install and update client code is difficult. See package manager issues: http://theupdateframework.com/

<harry> Getting off the Web is not a magic solution.

<wseltzer> Herve Pierre, SIM Alliance

<tarcieri> harry: <3 TUF

<harry> https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf

<martin_paljak> harry: if you need to talk to "unknown" local hardware, you need to have code running on local machine. Either "bundled" or specifically installed.

<solar> but what about software authenticators?

<solar> should we call that “software secure elements"?

Herve (?) w/sim alliance: when we say SIM card or smartcard -- at core they are similar, but have diff form factor, plus SIM card is linked to biz partner by definition -- thus we should use the term "secure element"

<tarcieri> solar: no, that's more like HCE

virginie: so we have set up the outline/scope of our discussions....

<wseltzer> [break, return in 30 minutes]

virginie: and we're in the specific context of the next steps for web crypto api and how we can evolve it

<bhill2> scribenick bhill2

<public_screen> scribenick: bhill2

Extending the Existing W3C Web Cryptography API

at mic: Brian LaMacchia, Microsoft research

slide deck title: BigNums, BigNums, BigNums

<tarcieri> Brian "I hate Montgomery curves" LaMacchia ;)

will denote Brian as "bal"

bal: slide 1, announcing v1.2 release of MSR JS Crypto LIbrary

… MSR's impl of the Web Cryptography API, polygill-ready, x-browser compatible

… now under Apache 2.0 license

… next slide: Why WEbCrypto needs BigNums

… using 16 bit to simulate large field math is really slow

… important for tech like U-Prove to be able to do arbitrary bignum operations in the browser

… anonymous voting schemes, new elliptic curves and associated arithmetic

<rbarnes> i'm still not clear on why this isn't a TC39 thing

<rbarnes> oh, here we go

… more esoteric crypto and more performant impl of standard need bignum finite field and ecc operation primitives exposed to clients in the browser

… why this belongs in the browser API and not in core JS

… not all JS clients need WebCrypto, but all WebCrypto needs this math

<harry> note that was discussed in the WG earlier and MS had a very detailed proposal, but the WG decided at the time that ECMAScript was way forward.

<tarcieri> it's pretty interesting that there's one pure JS bignum implementation that virtually every JS implementation of RSA is built on now (well, except for MS's lib)

… should be carried with the part of the platform where it is necessary - which is all WebCrypto impls, but not necessarily all ECMAScript impls

<harry> However, that being said, the demand for this seems like its increasing and ECMA has not made any progress i think on this front.

next at mic: Kelsey Cairns, Washington State University

anybody know Kelsey's irc handle?

<tarcieri> cryptographic bignums have concerns that general bignums don't, like sidechannel resistance

deck title: W3C WebCrypto Analysis

KelseyC: internship project to analyze version 1 of WebCrypto API

… don't care what it looks like as long as it is not causing me danger

… formalize API and analyze model with respect to key safety, plus practical concerns

… using model checkers to search all combinations of API calls

… goal is to test properties of keys, extractable keys, usages, basic message passing

… assume attacker has access to API - e.g. injected code, malicious server

<martin_paljak> similar to pkcs11 works.

… testing origin safety is out of scope

… Questions we asked: can key be extracted from client, can usages be changed, what security properties hold for messages, what threats apply to use cases?

… can't say that malicious code will never happen, what *can* we say about our use cases?

… our model found that unextractable keys are good

… usages are only enforced for unextractrable keys, otherwise can export / re-import with new usages

… what about sending wrapped keys

… from client to server, found more integrity attacks

… most use cases were vulnerable to at least one of the attacks we found

<virginie> For the ones who never read the Web Crypto API, you can read it here http://www.w3.org/TR/WebCryptoAPI/ :)

… e.g. if client wants to send new key to server, attacker can export a key, replace the wrapping key; unwrap the key in the client, or polyfill the wrap operation to no-op and force key to be sent in clear

<harry> Note that this work is on *current* WebCrypto spec, not future spec.

… other things: review of included algorithms, key storage, polyfills, client-trusts-server security model

<harry> It's more or less the same techniques Graham Steel used against PKCS #11: http://xor.cx/data/CryptoTokenAttacks.pdf

… no key storage is of concern to us, most of room, concluded it will take a lot of thought and must be done well for the application

… polyfills made it to easy to replace subtleCrypto functions

… re: security model, lots of people want user to have some control / security properties

… but web app model is inherently remote code execution by server

<wseltzer> for the transcript, that was "if you're doing remote code execution [shrug]"

<tarcieri> JS == RCE as a feature! :D

<virginie> as a note, speaking about web crypto API algorithms review made by Keisley and Graham, the report is availbale here : http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/

demo of webcrypto extension in chrome that shows generate, inspect, import and use keys to do encrypt operations

<harry> This is what she is drying to demo:

<harry> https://github.com/cryptosense/w3c-crypto-inspector

<harry> http://cryptosense.com/webcrypto-api-tracer/

<harry> blog post above ^

KelseyC: general user population won't find crypto details about keys useful, but I would really really like to have them available

<martin_paljak> harry: it is derived from the cryptosense pkcs11 prober?

next up: Nick Van den Bleeken (Inventive Designers)

<harry> It's the same general idea, I think re-coded to deal with JS

<harry> Graham could answer details: http://www.lsv.ens-cachan.fr/~steel/

cultural question from scribe - should it be NickV or NickB?

nvdbleek: two things are certain, death and taxes

… one of first uses of eID online was a tax application

… login lets you choose a certificate to use, enter pin, then you can do your taxes

<rbarnes> agreeing is good, right?

… no digital signature has been generated for this

… other use cases, invoices, contracts, insurance agreements do require a signature

… my eID has a certified key allows me to sign documents legally

… to do that I need my eID, an extension or java plugin to access the smart card (in browser)

… currently browsers don't like Java anymore and block it for good reasons

slide demo of the experience

… I got to the end, but doubt my mother would

nvdbleeck: trying to find solution that doesn't require extension or plugin

… found webcrypto API

… can do sign, but where do keys come from?

… all examples use keys generated in browser

… key discovery API uses named, origin-specific, pre-provisioned keys

… we want eID to be available on all websites

… our keys aren't pre-provisioned, user should insert card at start of operation

… don't want to give name for all eIDs

… to enable our use case we only need certificate-based discovery

examples of code showing selectX509Certificate() API

gold bar on top to prompt user for use of keys

select key as done for TLS client certificate

nvdbleeck: good to go without using any extensions or plugins

<tarcieri> ugh popup for pin entry :|

… doesn't limit access to just smart cards but any certificate in system key store potentially

… believe will make it easier to get access to secure hardware

<martin_paljak> yap, +1

<wseltzer> Sangrae_Cho, ETRI

next at mike: Sangrae Cho, Authentication Research Team, ETRI

SangraeCho: talk today will be introduction of Korean online banking use case as it relates to certificates

… five authorized certificate authorities operating currently, issuing over 30 million certificates to 20 million people and legal entities

<martin_paljak> nvdbleek: +1. Same story told with nice pictures. I assume the UI pictures were mockups?

… used for online banking, stock trading

… but certificate is issued and managed and used in an ActiveX control

… because most browsers in Korea were IE in the past

… certain issues and problems related to ActiveX

… users also need to install ActiveX controls or programs for certificate management, keyboard protection, personal firewall and anti-virus, and web secure channel

<tarcieri> ActiveX o_O

… issues are that it only works for IE, weak against malicious program attacks, user inconvenience and not mobile friendly

… try to use JS for a web-based digital certificate service

<virginie> as a note, W3C web crypto WG has provisionned a wiki page listing the wishes expressed by members for next feature, see https://www.w3.org/2012/webcrypto/wiki/WG_Future_Work

… use webcrypto API, HTML5 for storage and communication, and CMP for cert issuing and PKCS7 for digital signature implemented on top of these layers in JavaScript

… will be launched for service in October

… issues for storage. In Korea, private key and certificate should be stored in secure, hardware-based solutions

… last year developed TouchSign using smart card with NFC (slide shows it working with a smartphone)

… can access bank on desktop, login with smartphone with card issued by bank and use digital signature to transfer money between accounts

… also trying to provide more convenient solutions with FIDO for a password-less or more flexible authentication

<nvdbleek> tarcieri: A pin is the way to authenticate your operations on BeID , you don’t want to provide access of the PIN to the WebApp. And it is the middleware that provides the UI. If the hardware token supports other authentication ways (e.g. fingerprint) this would be sufficiant too offcourse.

… digital certificate can be issued to the authenticator device for attestation

<tarcieri> nvdbleek: yes, that's all true, however a popup like that can be spoofed by a web page to steal the pin

… trying to use technologies for hands-free payments at stores (slide shows bluetooth beacon-based service)

… requirements are storage management for WebCrypto.Next, standard API for hardware tokens, standard API for communications such as NFC, Bluetooth

<virginie> Please note that NFC API is under development in W3C here : http://www.w3.org/TR/nfc/

<nvdbleek> tarcieri: it should be made visible to the end user that it is a “trusted UI”

next at mic: Philip Hoyer (HID Global)

<martin_paljak> don't forget pinpad readers.

Phil_Hoyer: lots of examples where we are sort of speaking about the same thing

… important that user experience in security is good

<tarcieri> nvdbleek: yes, it needs to pop up over the browser chrome so that's clear

… some smart card efforts so far have hampered that

<nvdbleek> martin_paljak: that is true, the only downside is that with the ones I have the belgian middleware doesn’t uses the keypad :(

<scribe> … new proximity technologies out there, NFC and Bt specifically

<tarcieri> nice @ NFC

… can communicate w/o needing to be plugged in

<martin_paljak> nvdbleek: yeah. that's the problem of the middleware...

<nvdbleek> martin_paljak: but that should be the way to go, use the most secure way to autheneticate to the card

<virginie> One should note about trusted UI that WebAppSec chaired by bhill2 has written some interesting guidelines http://www.w3.org/TR/UISecurity/

… seems oxymoronic that speaking to a bank halfway around the world requires an applet to talk to a smartcard

… user wants contactless presentation of credential or have credential on separate device

… going to be many different devices and credentials that expose security / crypto to another device

<nvdbleek> virginie: thanks, will have a look at it

<tarcieri> virginie: nice

… browser should be able to discover, communicate with and use them

… proposes a proximity API in two layers

… no APDU support yet for NFC API, no BLE support yet

… higher level API allowing discovery / connection to list known proximity devices independent of transport

… retrieval of security capabilities

<martin_paljak> nvdbleek: we use readers in Estonia that are usable only through the physical pinpad. thus you *have* to use it

… connection API to talk to devices

… APIs I'm proposing could use low-level APIs

<rbarnes> this discussion of transaction authorization makes me uncomfortable. big rat-hole. better to have cards for a focused purpose (identity) that can delegate to application-specific keys, and handle authorization at the app level

… but higher level APIs can also e.g. remember devices seen before and represent them to the user for re-connection

… in quest to get rid of passwords, contactless proximity offers one of best and most convenient use cases

… enable browsers to leverage them for security through layered APIs will enable new generation of convenient and secure applications

… feel this proposal is ideally aligned and builds on initial work of WebCrypto API charter

<nvdbleek> martin_paljak: if we only had those… only this has the disatvantage that all users need to buy an external reader, as build in readers won’t work

<martin_paljak> tarcieri: I hope that something shall be arranged here so that I could implement a POC plugin for android browser and estonian id card, yes ;)

<virginie> questions...

<tarcieri> martin_paljak: nice

<harry> http://www.w3.org/2011/11/webcryptography-charter.html

<harry> ^ the current W3C web crypto charter

<harry> the goal of workshop will be to write a new charter for either this WG or another.

<public_screen> [questions?]

hhalpin: webcrypto API is currently in Last Call

… have had extensive comment period, unlikely to see large changes at this point

<rbarnes> firefox has implemented it as well :)

… can and will recharter group, how this API relates to larger world of use cases is what we are here to figure out

… have momentum, but still have some very hard problems in WebCrypto group

<virginie> Implementations of web crypto API information can be fund under https://www.w3.org/2012/webcrypto/wiki/Main_Page#First_implementations

… can imagine a 1.1 API, working together on a broader basis with other topics raised here

<harry> ah didn't know it actually shipped yet rbarnes! thanks!

<harry> Any links?

nvdbleek asks sangrae about discovering devices

sangrae: we use banking or credit card with standard smart card APIs

kelsey: Am I only one here who can't keep track of car keys, wallet?

… only thing I can keep track of in my life is my laptop

<tarcieri> kelsey should get a Yubikey Nano ;)

… my friends even can't find their phone

… can't ignore what users are going to do

siva: question for Kelsey - are you suggesting storing keys on server, centralizing trust more on server?

kelsey: our analysis assumed operations would happen client-side, looking at what could happen

… as far as server malware, not going to say how prevalent or not, but if you have a compromised server and client thinks it trusts it, you can get malicious code to run on client easily that way

siva: is solution then to put keys on sever side?

kelsey: trying not to propose solutions, could put it on server side or make sure whatever key storage on client side is designed to be safe against compromise

bal: whare should the key live? usually on client, try to protect platform

… pretty sure that Google's E2E solution keeps keys on server and bootstraps it into client based on password authentication

… for certificates, what is policy statement for making them available to different origins

<tarcieri> such a problem too :(

<tarcieri> client cert UX is extermely confusing already. now add hardware tokens...

hannes: looked at formal verification of protocols, interesting although I have some skepticism because it relies on lots of assumptions

… advantage it to understand why certain pieces are there and what falls apart if you remove them

… has code been published and is it available for people to play with? e.g. to model extensions to base model

kelsey: haven't published, but b/c lazy not secret, come talk to me

hannes: question about multiple origins and certificate usages in terms of scoping

… concepts of authentication conflate and grow from 2 -party to 3- or multiple party solution with identity providers, SSO, etc.

… makes whole story complicated quite quickly. unfortunate but in most cases unavoidable

… challenge to avoid dragging security and privacy problems along, past experiences shows we can't just push that onto the user with dialogs

bhill2 +1 to hannes' last comment re: security UI

<tarcieri> +1000 from me ;)

Phil_Hoyer: we are honing in on the use cases we want, avoiding bad user experience in use cases we care about

… will always be different categories of credentials out there

… belgian card is simple, german card has more privacy capabilities

… doubt we will agree on one single API or approach to satisfy all constituencies

… these credentials are costly to issue and have little use

<virginie> Note that Israel from Microsoft also advocated for dynamicity in the web crypto API next phase, motivated by algorithm discovery, see http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_31.txt

nvdbleek: not just about belgian ID card, but any kind of hardware device for signing

keiji: japan digital ID card is optional

… majority of people don't use it because they have to install java plugin

… clear expectation with API to make it possible without any kind of plugin

Phil_Hoyer: lots of communities across world, many will not have an ID card to be read. how do we solve identity or better authN mechanism for them?

hannes: wonder whether one underlying problem isn't broken software update model

… couple of years ago, challenge was updating software on desktop PC, now we want to fix browser plugin problem, or how do we get browser to implement APIS

… with smartphone is a bit different, people are more used to installing specific applications for hardware tokens, may make some issues less complicated from deployment part of view

… is bluetooth easier to roll out vs. browser and desktop environments?

Phil_Hoyer: with any new technology, when added to tools used everyday then interactions will be different between devices

<Martin_> But can installed apps hook into the browsers on mobile phones and provide their services to web applications etc? Not AFAIK.

<martin_paljak> Martin_: android intents ?

… but you can do very nice things, like auto-lock when leaving with device on your keychain

<martin_paljak> but that's platform specifci

… normal office worker vs. doctor in hospital - different use cases, some demand contactless like a clean room

… have to think about what if battery is dead

<Martin_> I think it would be good with a browser-independent plug-in architecture. Something like signed plug-ins written in JS. So the smartcard drivers etc. could be written and deployed like that. WebCrypto could built on that.

Jeff_Hodges: some active participants in WebCrypto here, yes?

… this session is about extending the API

… but there is a layering in these papers, bal's is very low level, others are very high level

… bignum thing seems like a no-brainer to me?

hhalpin: came up pretty early in lifecycle of API from Microsoft, sent a detailed draft proposal

… was discussed on list and F2F

… did not reach consensus (publicly minuted as such) in so far as at the time I believe Google felt it was below the security boundary they felt comfortable exposing to browsers

… in general two types of proposals that were pushed out of scope or not accepted in v1: low level and high level

… have come up since beginning of WG and been extensively discussed

… good time now to look back and think what we could have done differently

JeffH: you need bignum underneath current API?

bal: yes, to do many of the algorithms

<rbarnes> would like to respond on this point

JeffH: bignums are lower level, only needed if you were going to use it to add in algorithms?

bal: if you want to do an RSA operation that isn't specifically an encrypt/decrypt

… my group came to this wanting to dive down a layer beneath wrapped sign, encrypt

… e.g. doing U-Prove blinded operations can't be expressed in terms of these

bal: we exported out our implementation but if you inherited someone else's you might have less access

<rbarnes> i want to jump in

jeffh: as I recall, there has been a layering argument that is a major issue here and ought to be on list for considering rechartering

… are we still talking one API or a layer cake? already today three layers discussed

<harry> I think W3C is OK with different APIs and even different layers.

… also Phil's thing - other APIs that arguable aren't WebCrypto like connection APIs

… to attract right kind of people, need right label on where work gets done

<rbarnes> a veritable mille-feuille of API layers

<tarcieri> current API conflates layers, also :( @ algorithms being non-normative

<harry> Note algorithms for browser profiles have been decided by WG to be normative, but will be decided after interop testing rather than before. Seems logical to me.

Phil_Hoyer: agrees, is making the case that these APIs are needed from other groups

<tarcieri> harry: I must've missed that

hhalpin: intense discussion on mailing list early on about layering. consensus so far is to reveal a pretty decent set of primitivess, not being too judgemental

… not trying to build a "developer-proof" API, but algorithm was as low as we wanted to go

… what is "developer-friendly" is contentious

… we put these papers in same group because they were not in same layer as current API, must layer up or down

<rbarnes> totally disagree, harry -- the cert mgmt stuff is layering

<Martin_> why not just make an optional API spec for the primitives (BigNum etc)? Then applications can polyfill on browsers that don't support it. With this approach at least you get a standard way of accessing a native BigNum impl on the browsers where this is available, without putting a burden on everyone for implementing it

… or cannot build on top without adding new kinds of things not in original spec, as e.g. certificates

… main barrier has not be theological, but lack of drafts, people working on them and consensus from implementers

<martin_paljak> OSI defines some. and they can be violated

siva: how many in audience are in hardware business?

… most of us are software

<martin_paljak> (layers)

… would be nice to build new platform, protocol, hardware

… distribution cost of hardware is high, backward compatibility is critical if we are to leverage it

… 30 billion plastic cards out there, don't imagine existing web properties shipping a billion new cards to their users

<HannesTschofenig> Regarding the cost of hardware there is Webinar given by a co-worker (from ARM) that may be relevant: http://www.tschofenig.priv.at/wp/?p=1036

Phil_Hoyer: yes. for new cases ability to talk between devices is good - can put credentials on just a few platforms that can be talked to by others

… maybe Google will put U2F on gear , etc as a personal device?

siva: who will pay?

Phil_Hoyer: don't underestimate cost of brand damage?

<Zakim> wseltzer, you wanted to comment on usability

wseltzer: point was about what we present to the user

… we don't have a usability session in agenda, will mention as one point of consideration

… in keeping with giving the user priority we need to think about how to make these systems for the user, treating the user as a sensible intelligent person but who is not an expert

… in any of these pieces of technology and is trying to get their tasks done

… how do we let them manage their security and privacy is a question we need to face

… regarding layering questions: lots of different WGs at W3C and opptys to charter new ones

… our aim is to be modular where that helps and bring participants together where that helps to get the work done

… WebCrypto has a community including implementers and active interest in extending it

… suggestions, the more concrete the better, should be brought into group for version 1.1

… and rest of workshop will look more broadly what will go into 1.1, 2.0, other W3C WGs and even other organizations we can coordinate with on behalf of the web

<martin_paljak> +1 to the speakers chair!

Phil_Hoyer: would be good to have a quick win for certain constituencies to show use of APIs, I think that win is to use existing credentials and smart cards out there

virginie: thank you for great ideas

… WG is not only a machine, is also a human group

… at time there were lots of new ideas, group was not mature and confident enough of reaching v1 of API

… created issues to accepting proposals like bignum and certificates

… maybe now is a better time to revisit

… asking each of panelists: you came with specific use cases you want

… how are your use cases related to the problem of killing the password?

… what is the functional aspect you want to add to the box we have been discussing this morning?

sangrae: we need to have some place to securely store and manage private keys and certificates

… we do not think html5 local storage is secure enough for keys

<rbarnes> Nadalin: could we turn down the AC? freezing in the back here.

… also in Korea there is consensus to store keys in hardware tokens

… so need APIs to hardware tokens

Phil_Hoyer: regarding killing passwords - history has several attempts, all had one or two hurdles to adoption

… ability or proposal to leverage different devices to store credentials and keys and allow use of that for identifications in web applications will finally bring down some of those hurdles and allow a more natural migration away from passwrods

… we issue 10s of millions of cards every year, if we can use these or put a credential vault on a phone that can be used

<martin_paljak> why not look at Java KeyStore interface, which is quite often used and also has well known issues.

… we've already paid for these but can't use them

nvdbeek: want to sign documents using a key singed by a CA, not bound to a particular domain, especially but not limited to smart cards

bal: not any one single feature is magically going to make passwords go away

… we've tried at MSFT, but took 15 years of investment to work today in a well-maintained corporate environment

<Anders_R> the number question IMO is if WebCrypto key access should be extended to multiple domains or

<Anders_R> not

… attempts to make user understand cryptographic concepts have failed for 15-20 years.. users will just click

<rbarnes> Anders_R: that is emphatically not a question. that already exists. postMessage FTW

… requests are to expose underlying features but in the browser.

… e.g. ASN.1 stuff which isn't there or exposed in a non-intuitive way

… this is a layering issue because it requires ecosystem

… I want lower layer things to I can play with ideas that enable new use caases

… at a higher layer it is about how to manage this information and make it available

<FaSo> Question: as a final user would you be happy if the HW token stops working and you have to wait one week before someone delivers you a new one?

karenlu_: replacing password is important but should not be the only thing

… practically we should consider the level of assurance

… regarding user experience and existing cards, real world experience with solutions we've developed

… for using smartcards with webapps for authn, signatures, etc.

… a country where all citizens have id card, they find out that citizens are not really using the smart cards

… list of reasons: one is that it is difficult to choose the certificate

… user is confused by dialogs in certificate chooser

<martin_paljak> tsl tõenäoliselt ?

… is not portable between browsers

<martin_paljak> TSL probably ? A smart card *is* portable.

<rbarnes> TLS?

… we have provided an identity management solution with level of assurance depending on the service you have

… can just login with username/password for less sensitive service, need to use smartcard for high value

… authentication is important but how important?

… malware wait on computer or phone to access post-authentication

… we would like a solution to help with authentication but also secure online transactions

nvdbeek: incentivizing use of smart cards can be about making better applications than with paper, e.g. as tax example I showed

detlef: can we hear more with respect to mechanisms for discovery? did you consider what is in FIDO for example, are they sufficient?

Phil_Hoyer: I think there needs to be that alignment, when I said discovery it goes beyond because of unconnected nature

… webapp should be able to know what security capable devices are in vicinity with binding, including already used ones

… security device may have separate keys for different uses

… see if it has some form of display

jeff_hodges: FIDO intents to promulgate specs into other standards groups such as W3C when IPR dance is done there

… please take a look at the specs there

hhalpin: what is connection of limitations of first version and hardware tokens?

… kelsey's work shows crypto api is great but still subject to polyfill attacks and key storage

… hardware tokens may be able to help solve some but not all of these concerns

… also facebook issues, how to do code signing?

… still, you have to trust web security model, how do we address holes there

… we will return to that later

rbarnes: signing is a secondary use case after authentication

… for folks interested, would you consider it a failure to have a layering between identity and signing layer

… where an identity could be associated with a key that is not bound to the identity

nvdbeek: performing bindings like that are not considered legally binding by european law: only the key on the certificate has legal status

martin_paljak: takes a long time for user communities to change their values, so can't get opinions until after 7-10 years

… issue of certificate selection is removed if you use a card, concept is not new to people

… should not try to create out of nothing new authentication metasystem out of nothing

<Martin_> +1

… but adjust so existing systems can be fulfilled with webcrypto APIs

<rbarnes> i'm pretty doubtful that these "use the card as an HSM" cases are going to be tractable

Phil_Hoyer: chip and pin and contactless is something users are experienced with

<Martin_> rbarnes: Because? :)

tony arcieri from square

tarcieri: if you try to cover lots of things, from authentication, signing, encryption, channel binding

… trying to put all this into a single package, it fails to be usable by average user

… how do we balance usability concerns for something like just the general authentication case which must be simple for average user

… (e.g. html keygen tag failed horribly to replace passwords)

<rbarnes> Martin_: just making an HSM isn't that hard superficially, you just copy/paste the existing API. but then you have to deal with when the HSM is available. and i've never heard a scalable story fortransaction authz

<rbarnes> Martin_: lots of complexity for not a ton of incremental benefit

… hardware tokens help with some of that, but how we make that seamless enough to actually get widespread adoption while still having all fancy things financial services users want?

<martin_paljak> what I wanted to add is that first "clone" working things (like real life processes) then tweak them once elements that can be "digitized" have been identified.

Phil_Hoyer: ability to create an authentication context with different data. if we can extend that through the web api with something like a proof of possession

… maybe not one thing, but can create a risk assessment of the overall situation

tarcieri: thinking like fido deck, push button, you're authenticated

<Martin_> @rbarnes: HSM's basically only solves the problem of not being able to clone the token and ensures the user must "present" it for it to be used. But it can still be abused in many other ways. I don't think accessibility etc. is in practice a problem (thinking of smartcards etc). Backup schemes need to be in place when used for encryption

… how do we get to that level and prevent fancier features from making it less seamless than that

<rbarnes> Martin_: i feel likey ou're making my point for me :)

… how do we layer these different things for ordinary vs. power users?

bal: reasonable to partition these things

… want enough metadata on keys for system, user agent, browser to make an intelligent decision

… so doesn't have to ask user to choose among 50 keys, but to have some context

… today policy and usage information is in x.509

Brad Hill notes as not-scribe that this is a problem that comes with 3-party key systems

in a 2 party system with targeted credentials it is much less of a problem

because the service knows which keys registered with it are for what users implicitly and can ask the user for the exact appropriate one

only if you have to rely on a key issued by an identity provider or other third party does this become a problem

<public_screen> [lunch time; we resume at 2pm local time]

Authentication

<wseltzer> bhill2: Brad Hill, representing FIDO Alliance

<wseltzer> ... technologies to replace username/password

<virginie> dear all, we are looking for a scribe... any volunteer ?

<wseltzer> ... lessons learned: users and services want keys that are hardware-bound or difficult to steal

<wseltzer> ... but users want unlinkability

<wseltzer> ... ceremony, associate user with key, before using the key

<wseltzer> ... once they've gone through the costly key-generation ceremony, users want to use everywhere

<wseltzer> ... Services have many facets (different presentations, different browser environments, apps, etc.)

<wseltzer> ... facets may be unknown to one another

<wseltzer> ... Just solving for the browser is not enough.

<wseltzer> ... but, also need to help users protect themselves, can't just regenerate an actual fingerprint.

<wseltzer> ... Key reference monitor, living outside the browser. "FIDO Client"

<wseltzer> .... Pieces: key-scoping mechanism (AppID), scope-authorization mech (trusted facte list), platform specific reference monitor (FiIDOClient)

<wseltzer> ... set of platform-apprpriate APISs to access ref montor functions from Web apps, etc.

<wseltzer> ... APIs, where W3C can help

<wseltzer> ... FIDO has 4: discovery, registration, authentication, deregistration

<wseltzer> ... https://fidoalliance.org/specifications/download

<wseltzer> Detlef: Towards harmonizing ISO24727 FIDO and Web Crypto API

<siva> i can scribe....

<wseltzer> Detlef: charming part about FIDO, the authentication part is simple on the client side

<inserted> scribenick: siva

Detlef: discovery is about the client; FIDO protocol is fairly simple using request-response stnardard by iso 9798-3; simplicity is "great"; but we should think about we might make facilities for supporting addl auth protocols

<JeffH> siva is scribing ?

Detlef: ISO 24727 is an effort to standardize ID cards by NIST. Now this is all over the world. A few 100 million ID cards. Possibily bigger. Perhaps we use this existing infrasturcture. For e.g. many European countries have national ID cards.

Yes Jeff...I am

<JeffH> thx :)

Detlef: a serivce layer abstracts the various nuances of the national ID cards....so you are not relying on the APDU layer...ISO 24727 is a good abstraction layer.

<keiji> Detlef: Many European companies are introducing National ID cards. Introducing ISO/IEC 24727 Architecture and Protocols.

Detlef: At this layer of abstraction there is no difference between FIDO and ISO 24727....except for multiple request-response pairs and other auth protocols for more "sophisticated" EID tokens and protocols are more complex on purpose.

*Detlef

<JeffH> iso wants CHF198 for ISO 24727 spec :(

Detlef: recommends a set of fuctions for the service access layer based on ISO 24727-3...which includes discovery using a localhost interface...
... nuances including waitforchange such as proximity device is close to client or moves away are covered in this ISO 24727 discovery process
... what does this mean for webcrypto API ... on one hand FIDO and ISO 24727 is similar...but ISO is a ISO standard already and can handle arbitrary auth protocol.
... - we need to have a BOX where addl protocols in the future can plug in

JohnMattsson: talking about SIM card auth...and its importance in mobile phones
... everybody has a mobile phone...or soon will....and everybody will have internet connections....and mobile browsers...so we will need to auth in a mobile phone not PC!
... so web auth protocol need to work on mobile phones...the fact is that most mobile phones already have trusted token - the SIM card
... with LTE all mobile phones will have SIM cards
... GBA standarized 3GPP and uses existing SIM credentials...and derives new temp keys and temp identities...and can be easy to intergate to other protocols such as OAuth and OpenID...VoLTE uses GBA already.

<keiji> JohnMattsson: SIM card is a new web authentication solutions need to work with smart phones.

JohnMattsson: Browser supporting missing for SIM card...and should be considered...
... SIM cards are already used for other applications such as National ID, Mobile banking, and SMS 2nd factor auth.

Personal comments - SIMs do solve the hardware distribution problem even better than embedding...since access will be universal

<keiji> JohnMattsson - certificate can be installed on SIM card and used as eNational ID.

<rbarnes> to dirk's question earlier -- these are point solutions :)

wseltzer - got it!

<JeffH> wseltzer is a zakim jockey :)

Hannes: Widespread deployment necessary for replacing password.
... New technologies face the same problem. All stakeholders need to cooperate.
... Taking FIDO as an example. Pointing out one aspect of FIDO...it is not as simple as mentioned by Detlef...formal verification indicates FIDO meets critical need for security.
... Typically in W3C the objective is to identify building blocks so we can put things together instead of a point solution. Build point solutions on top of the building blocks.
... In the case of FIDO where discovery is needed or privacy mechnism as mentioned by Brad of PayPal could easily be the building blocks for FIDO and other authentication protocols. GBA is different the FIDO. But can we identify "abstract" functions that can supports privacy, security, simple, and support FIDO and all other authentication protocols
... Many stakeholders need to cooperate...in IETF's experience on paper in standards it might be easy...but in the real world a good experience for user is a completely difference thing.
... Abstract the hardware protocol such as BTLE, USB ... like FIDO
... Questions: why past efforts have failed (business model?), how to get all stakeholders involved, support innovation?, how to get good user experience end-to-end soln....

<virginie> +1 to abstraction exercice required :)

<JeffH> Landau, Susan, and Tyler Moore. "Economic tussles in federated identity management." First Monday 17.10 (2012).

Hannes: Privacy is important (mentions with the risk of kicking out!)

And that is 11.5 mins! :-)

<JeffH> http://uncommonculture.org/ojs/index.php/fm/article/view/4254/3340

Personal comment: Didn't feel like 11.54

*11.5 mins

<keiji> Wykes: Beyond Authentication

Sean: How to integrate h/w tokens to Webcrypto API...need token, token driver, standard (APDU, PKCS11, FIDO, trusted interface...?)
... Authentication means diff things to diff people - 4 entires based on context on one axis and security on the other (refer to paper on the details)
... Brazil example: Government ID - 9M certs; Employee ID cards - 15,000 employees; Banking - 5M cards, zero fraud with 5.6B USD/month

*zero online fraud using smart cards

Sean: MITB attacks are very sophisticated....a transaction signature method is used
... Going forward....there is lower browser support to applets...browsers re removing sandbox...so we need - a flexible web standards...that has a trusted UI and can we adapt HTML, CSS and Javascript

<keiji> Sean: We need flexible web-standard for security related functionality with a TRUSTED UI.

<tarcieri> +1

Sean: Proposes a new architecture...with webcrypto API with trusted UI...native authn...talking out of band (not through APP) comm to the token....
... a Box that does cyrpto secuirty services is needed outside of the webcrytp API
... Impl idea = Webworker + Frame + Signed JAR = a new tag = a standard way of appl vendors to do this!

<keiji> Sean: suggest to Combine best ideas from : webworker + <FRAME/> +Signed JAR -> new tag <trusted />

<rbarnes> a+

Brad: I have a lot of devices...how do I make sure a SIM soln will solve the problem?

<JeffH> ....as while preserving privacy

John: Need cooperation from mobile operators

Hannes: Less attractive for developers to use SIM cards for call use cases [maybe] misguded

*misguided

John: SIM tech is ideal...but business model is a challenge. But issue will exist for any secure element.

Hannes: A web developer if faced with such a challenge...might just want to do it using a trusted execution environment...or get an external token

John: A lot of web apps already use SIM through SMS one time password

Hannes: Disagrees SMS example will move to other uses such as email

<rbarnes> i need to step out, could someone proxy my question? regarding "trusted UI", (1) how is this better than HTTPS + Content Security Policy, (2) why does it require a hardware token and (3) why would we not do this for the rest of the web?

<rbarnes> i'll take my answer via the scribes :)

Brad: If we are bulding web API it will need to be of web scale not just for govt and banks...limited to a few

<tarcieri> OTPs sent over SMS are often replayable for a window of time, and SMS traffic can be sniffed

Hannes: The important aspect is to determine how we talk to the various hardware tokens...FIDO has an intermediate abstraction layer so that web app and web service provider doesnt need to know about the hardware transport layer

<JeffH> need to know

MikeJones: Question for Sean - in Brazil was smartcards for banking legislated

Sean: No. It is done by the bank giving local reader for users.
... Cost of couple of million readers @ $5 + already issued smart card for the transaction volume they have is justifiable
... There is a lot of resistane nevertheless since the user doesn't want to carry this reader....go after a different form factor...
... Question is how can user this hardware....

MikeJones; Supports that thought

<Ullrich> Banks are not liable if fraud happens with a secure tech

gmandyam_: what is the goal of GBA given FIDO arch?

given GBA requires lot of changes to browsers

John: GBA should be implemented with FIDO or something else as defined by W3C....

Hannes: FIDO and GBA don't align well with the IMA client

*IMS

Hannes: Believes that basically make use of GBA for web services...
... FIDO auth is local there is not over the air protocol like GBA

Detlef: FIDO is a great use if you assume there is nothing else out there...but there are lot of auth solns out there....so the question is how do we take advantage of it...so it can interoperate for all auth....

<JeffH> bhill: we need to ask why all that already-deployed stuff hasn't succeeded to replace username+pswd -- thinks it is because...

Brad: Existing solns have not been adopoted so far for web....so why support it

Hannes: how many legacy infrastucture do we want to support with shortened innovation cycles

<JeffH> ...a combo of not being 'easy' for users to wield, unbalanced requirements between RPs/issuers/users, privacy concerns, etc.....

Hannes: Maybe another try with FIDO instead of retro fitting with legacy infrasturcture
... lets move an build from scratch

Peter: Two things are getting mixed up. CryptoAPI is about Crypto protocol that can go in lots of places including SIM. But we are confusing ownership and control. It is completely independent of the auth algorithm.

Hannes: Business model is and will be a barrier...and therefore there are some caveats to that

Sean: We need to seperate centrally issued and user issued. In an open web arch can we exclude on and the other....but is that open?
... Some of the legacy stuff is working.
... Can we build into the web crytpo API both of these

Brad: Users are not good at managing security etc.
... Too many choices may not be user experience

<tarcieri> +1 to reducing user security decisions for the common case

Detlef: we do not have good integration for existing methods...so web use is not common...
... Build better interfaces to existing methods work...

Hannes: Disagreeing with Sean...Existing methods to not offer standard of user authn process....

virginie: question to Richard - trusted user interface...how is it better than what we already have

Detlef: what we have is only available in microsoft platform. it is not available on all platforms.

<adam_> no

<tarcieri> hahaha

<tarcieri> cryptographic service provider =/= content security policy

<virginie> argh...

<tarcieri> see also: communicating sequential processes

<martin_paljak> trollmode: we need "trusted html" </trollmode>

<rbarnes> Content Security Policy -- limits script injection

<JeffH> bhill: doing anything other than PNG in a trusted display is a path to issues.....

Handing off scribing to JeffH (Thanks!)

<harry> scribenick: JeffH

hannes: an issue with getting new authn mechs deployed is the requirement for supporting plethora of existing deployed creds and mechs -- so maybe we shouldn't do that.....

detlof: the deployment prob is solved by the browser vendors -- if they step up this prob can be solved -- so what

s their agenda?

virginie: have heard..
... fido is applicable/interesting
... ?
... ? trusted UI ?

<harry> SIM cards are important

<harry> virginie: Trusted UI is a feature

<harry> virginie: government and banks needs are important

<virginie> virginie : we heard several people pushing their use cases and technology : fido, ebanking, governement, SIM based authentication

<harry> virginie: can we re-design FIDO to incorporate this?

<virginie> virginie : can we re-design FIDO to have all use cases being impelmented in FIDO ?

bhill: fido can address some of these use cases -- signing govt doc with approp key is a diff use case from everyday login to all the webapps people use -- so they can be orthogonal APIs -- keep the authn api simple, have others for eg the doc signing use case....

<virginie> sorry harry, wendy asked me to type my question

hannes: how do you support the ISO25747 in fido context?

detlof: have the ISO api on top, then have generic api that can support arbitrary authn mechs below -- so doing the ISO api on top of FIDO is possible, but not the other way around

sean: there's a danger to supporting two apis together -- if the lower layer is exposed in browser -- how do we control which app can wield a given key pair -- eg with pkcs#11 how do i keep some app from doing bad things to the keys?

detlof: the JS web app wouldn't have access to the lower levels

<Zakim> virginie, you wanted to proxy richard question regarding "trusted UI", (1) how is this better than HTTPS + Content Security Policy, (2) why does it require a hardware token and (3)

<virginie> To all attendees : I have provisioned a wiki page listing all questions we need to answer to move forward here : https://www.w3.org/2012/webcrypto/wiki/Workshop_webcryptonext

<virginie> Please do not hesitate to edit, and amend...

siva: it is clear existing impl hasn't really gotten into the web, however, the pkcs stuff isn't what we need for the way, if we say fido way and/or ISO is the right way,...
... we need options, deployed infrastruct is out there and working for their use cases, so why can't we do both ?

hannes: if it works in a priv preserving way....

<Martin> Regarding the question of why trusted UI is necessary... One important reason: Secure authentication even in case of man-in-the-browser (or even deeper system-level compromise).

bhill: you can split the market that way...

siva: buy i have 17 diff cards in my pocket, they work....

<virginie> hum... debate starts...

bhill: but for most users that sucks!
... our vision is very low, we just wanna replace username+pswd jn a priv preserving way everywhere it's used....keep it simple

siva: let market decide.....

bhill: we have a coalition of relying parties.....post snowden need to do uname+pswd replacement in priv-friendly manner

detlof: scenario of leveraging cors header to control allowing some origin access to discover the available authnrs on the user device....
... this is a small extension to the cors mech -- can use the same type of mech to enforce privacy -- its almost there....

harryh: regardless of what standards etc out there, we're building on v. heterogen market -- there'll always be deployed infrastruc need to have a story for...
... that said, from w3c perspec, thinks is more productive to scale down and concentrate on solving particular use cases on the web -- each panelist please remark..

bhill: need to get away from using uname+pswd -- all he cares about

detlof: need to have a discovery mech, otherwise can't use keys in useful way

hannes: need api to select ?

sean: need a way to replace pswds

phil_h: why things have failed -- costs, installation, etc -- we have oppty here to change things -- but can't throw away existing stuff 'until the replacement is "accepted" eg by the banks etc.

bhill: just arguing that "identities" should not be "credentials" -- eg keep the decoupled and separate use case spaces

<martin_paljak> that was a good one (previous line)

karen_lu: so suppose b of a supports fido, i use my u2f token to login, but then the banks move to emv cards -- so to get $ i pull out my card, but also had to use my u2f token to login -- another use case, i work for govt, have a PIV cards,...

<tarcieri> +1 on the encrypted messaging use case

karen_lu: and need to use it with u2f

bhill -- b of a can be smart and reimagine authn and identity attribs -- eg register mobile w/fingerprint sensor (fps) with b of a, then associate emv card with it, and then that's a one-time thing and b of a knows the binding between those two things

<tarcieri> WebCrypto should have *some way* to support OpenPGP applets on smart cards

<martin_paljak> tarcieri: keystore interface should work for openpgp or piv or estonian eid.

karen_lu: if i already have the piv card should be able to leverage it

<martin_paljak> or heck, plain fido tokens.

<tarcieri> martin_paljak: what about the PIN?

wseltzer: asks panel what we can (simply) add to web to make it better

bhill: simple authn and attestation (diff use cases)

<martin_paljak> tarcieri: same for openpgp applets or eid applets. same problem. including pinpad readers (no pin entry) etc.

hannes: be good to keep complexity low

<tarcieri> the browser needs to provide some sort of PIN entry UI to unlock the OpenPGP applet for message decryption

<rbarnes> because, as we know, browser vendors are lazy

sean: need an api for authn that can replace uname+pswd; at same time need to support legacy apps that use say smartcards; so until they can be updated to the new stuff, need to support them

<public_screen> [break for 30 min, return at 4:30 local]

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Meeting: Web Cryptography Working Group Teleconference/Meeting: Web Cryptography Next Steps Workshop/
Succeeded: s/chairign/chairing/
Succeeded: s/away/a way/
Succeeded: s/???/Siva/
FAILED: s/???/Siva_Narendra/
Succeeded: i/what is the function/Dirk: How do we identify "point solutions" to avoid?
Succeeded: s/??/US government/
Succeeded: s/???/Detlef Hühnlein (ECSEC)/
Succeeded: i/Harry: Welcome/scribenick: wseltzer
Succeeded: i/advertizes/scribenick: JeffH
Succeeded: s/pointed earlier in this irc log at w3c priv requirements/it's no accident that W3C's Technology & Society domain has both security and privacy considerations. I also pointed out the "priority of constituencies": user interests first, then developers and implementers./
Succeeded: s/???/Phil_Hoyer/
Succeeded: s/Extending/Extending the Existing W3C Web Cryptography API/
Succeeded: i/Welcome,/Topic: Welcome, Introductions to W3C and Workshop Goals
Succeeded: s/nvdbleeck/nvdbleek/
Succeeded: i/Detlef - /scribenick: siva
Succeeded: s/Detelf -/Detlef:/
Succeeded: s/Detlef -/Detlef:/g
Succeeded: s/JohnMattsson -/JohnMattsson:/g
Succeeded: s/need to card/need to know/
Succeeded: s/API/UI/
Found ScribeNick: wseltzer
Found ScribeNick: JeffH
Found ScribeNick: bhill2
Found ScribeNick: siva
Found ScribeNick: JeffH
Inferring Scribes: wseltzer, JeffH, bhill2, siva
Scribes: wseltzer, JeffH, bhill2, siva
ScribeNicks: wseltzer, JeffH, bhill2, siva

WARNING: No "Present: ... " found!
Possibly Present: AdrianC Anders_R Axel Axel_ Brad Brnocrist Bruno Brunojav Cathy ChrisW Detlef Detlef_Huehnlein Dirk FaSo HadiNahari Hannes HannesT HannesTschofenig Harry Herve_SIMalliance John JohnMattsson Jonas Karen KarenLu KarenOD KelseyC Martin MartinThiim Martin_ Martin__ MikeJones Nadalin Pea Peter PeterC Peter_Cattaneo Phil_Hoyer Rob_philpott Rob_philpott_ SamS Sam_Srinivas SangraeCho Sean SeanMichael SeanWykes Sean_ Siva_Narendra Tony_Nadalin Ullrich Wykes adam_ ale bal bal_ bascule bhill bhill2 bren2010 crypto detlof dirk_balfanz do drew drogersuk engelke for gmandyam_ harryh herve hhalpin https ilhangurel inserted jarrednicholls jeff_hodges jeffh joined karen_lu karen_wu karenlu_ karenwu keiji kelsey kodonog lifewsky lifewsky_ martin_paljak mdwood monz nexus not nvdbeek nvdbleeck nvdbleek of perterc phil_h public_screen rbarnes rest richard_barnes sangrae schuki scribenick selfissued sep_of_church_state siva solar soohyung tarcieri this tkeiji tkeiji_ trackbot trollmode virginie virginnie vkata we web why would wseltz wseltzer
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Agenda: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule
Found Date: 10 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/10-crypto-minutes.html
People with action items: