<wseltzer> [adjourned]

<wseltzer> thanks to our hosts, sponsors, speakers, moderators, scribes, participants! See you tomorrow.

<wseltzer> trackbot, end teleconf

<trackbot> Date: 11 September 2014

<martin_paljak> is there a list of participants somewhere ?

Welcome, day 2

<wseltzer> Virginie: Thanks to our sponsors for a good dinner

<wseltzer> ... Note that draft minutes are now linked from the agenda page

<wseltzer> ... Overview of agenda: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule

<wseltzer> ... Afternoon objective: what do we need to do in the next two years, and how will we do it?

<wseltzer> ... e.g. rechartering existing WebCrypto group or chartering new group

Hardware Tokens

<KarenOD> ok

<wseltzer> scribenick: KarenOD

* "want" is a strong word...

<wseltzer> Why W3C needs to Remain Neutral and Endorse ‘Brand-free’ Hardware Security by Siva Narendra (Tyfone)

Siva: Why W3C needs to remain neutral
... security about more than multifactor, about decentralizing ID vaidation and key storage
... smart card chips: proven, scalable, low cost, form factor agnostic, lots of money spent on infrastructure and certification
... Myths include smart card chips are old, are proprietary (web browser interfaces to smart card are and that needs to be fixed)
... already a functioning solution in use

<martin_paljak> +1 for using OpenSC ;)

Siva: solution works on both mac and pc (see Siva for demo)
... list of benefits to both the smart card industry and the entire community

Herve Sibert: GlobalPlatform technology for the web

scribe: GlobalPlatform is the standard for managing applications on secure chip technology
... one of the main focuses is mobile

<colin_g> hi

scribe: architecture description (see diagram on slides)
... coverage by GlobalPlatform specifications
... interface to GlobalPlatform technologies (TEE, SE) - open mobile API by simalliance
... proposal to W3C: consider transport and service layers from GP work
... identification of service levels of SE/TEE
... suggestions on how to work together (open-source group in GP or W3C group with GP members), liaisons to synchronize roadmaps

Bruno Javary: Secure element access from the web browser

<Herve_SIMalliance> by writting, your accent is better !

scribe: history of Oberthur Technologies in this space

<tarcieri> virginie: I'd be interested in seeing "decrypting a message" listed under the use cases here: https://www.w3.org/2012/webcrypto/wiki/Workshop_webcryptonext

<tarcieri> at least up for a yes/no vote anyway ;)

<virginie> to tarcieri : done ! :)

<tarcieri> thank you! :)

scribe: position summary: enable access for every single user to trusted services, best candidate is the web browser

<virginie> note that anyone can edit the page, it is supposed to be collaborative, but I am happy to include suggestions

<JeffH> (http://opoto.github.io/secure­-element/) from the oberthur position paper 404s

<tarcieri> virginie: I can't log in :|

scribe: topics to be considered: authentication, access to crypto operations, low level acces to secure element/hw token

<virginie> to tarcieri : oups, will check later access rights ...

<JeffH> are slide decks posted as yet?

<harry> we'll do that ASAP, but we're still missing a few :)

scribe: ... middleware good for local use but not for online use

<virginie> to jeffH : wseltzer and harry will take care of it, action noted

scribe: browser extension there but has issues

<colin_g> "access to crypto" - briefly discussed in the presentation currently underway (oberthur technologies) - how are the limitations on access addressed (e.g., due to limitations on web access around the world, sparse or nonexistent web access, or spotty cell service)

<Herve_SIMalliance> OMAPI has been already implemented in more than 200 Android NFC smartphones

scribe: mobile APIs are proprietary, some promising technologies, middleware and web browser extensions don't work in mobile environment

<Herve_SIMalliance> OMAPI is IP free and royaltee free, a Open Source implementation is also available

<Herve_SIMalliance> Seek for Android

scribe: PIV card use case (US Govt), decryption/signing must be local, can't be used on devices "on the go", needs specific hardware for phone/tablet

<colin_g> Possible background study reference info (Pew study) http://www.pewinternet.org/three-technology-revolutions/

scribe: position: W3C standardization of JavaScript API for browser access to Smart Card
... secure element API: complete and well documented, solution combines validation by the user and specific access control mechanism

<Anders_R> The SE API doesn't have any links to WebCrypto

scribe: action plan list (see slides)

Natasha Rooney:

scribe: GSMA is a global mobile association
... GSMA personal data program: mobile connect
... not something that we want to necessariy be standardized but we want it to be a supported use case

<colin_g> Possibly the opoto.github.io/secure-element thing that 404'd can be accessed directly on github at https://github.com/opoto/secure-element

scribe: anonymous login, secondary authentication, validated login, identity validation, mobile signature, attribute brokerage
... want to make sure this is secure and respects user's privacy

<colin_g> also links to seek for android at https://github.com/opoto/secure-element

<colin_g> https://code.google.com/p/seek-for-android/

scribe: sim applet running on device uses SIM as a hardware token
... SIM applet security benefits: attacker needs to have the device, user is alerted to attempts to access account, limited number of parties can r/w to sim
... SIM disadvantages: applets needs to be preprovisioned, work ongoing to do over the air provisioning
... Future work: secure storage, secure processing, standardising cryptograph support on hardware tokens, assuring security prior to issueing a token

<pea_> what is the business model and who would the trusted party be in this model. The MNO?

scribe: SIM is not the only solution, hw token is something that needs to be investigated,

<martin_paljak> it depends. with certificates it would be a CA

scribe: we would like for users and developers to make use of this on the web

<martin_paljak> in US it would probably be the network, yeah...

<Herve_SIMalliance> I think so, MNO will be an ID provider

Karen Lu: Enhancing Web Application Security with Secure Hardware Tokens

scribe: secure hardware tokens have secure microprocessor, memory and crypto engine

<pea_> If the MNO would allow the consumer to load any certificate they woudl desire on the SIM then that would be excellent solution for connected devices like Phones.

scribe: providing security in many domains
... no standard for using secure hardware tokens in web applications
... current proprietary solutions bridge the gap
... including authentication, signature, and encryption
... many proprietary non-interoperable solutions exist
... need a standard for how web applications communicate and use secure hardware tokens
... question is where do we build the bridge (three possible levels of APIs)
... low level for communication and basic access (APDUs)
... middle level API for crypto and secure storage
... high level API for security services (authentication, payment, token management)
... how to control access to the hw token
... user controls access or token control access
... leverage secure element API

<colin_g> :-)

Brad Hill: My understanding is the applications that go into these have to be approved by the gateway or the carrier

scribe: don't have an open environment to choose the application that we want...

<Ullrich> GP has a discussion on "user centric" management of secure elements.

<martin_paljak> Ullrich: link ?

scribe: not sure we gain much by developing a standard API that provides access to locked down services

Siva: your inference is correct, whoever takes control of owning the security would want to take control of who has access,
... identities will continue to be diverse, liabilities will continue to be diverse...
... difficult to converge them

Natasha: mobile is just another option for an identity provider

<Ullrich> http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf

<pea_> How does one get in teh list to ask a question or make a point.

Brad: these are things I can use to replace authentication for high value, high monetary type services, need to consider which bank and which phone work together
... i don't see this as compelling for the W3C, you want the W3C to support a particular pay to play business model

<pea_> The question at hand is in an anonymious world who is the relying party willing to trust

KarenLu: there are different levels of services

Brad: I should get to choose which bank and which health care provider I use and not Apple or Samsung

KarenLu: there will be more and more high value applications

<pea_> The other question who "controls" the container that the Cerdentials will be stored

<pea_> in

KarenLu: another aspect of your question is access control, can put trust outside of secure trust element,
... two models (trusted operating system, FIDO model)

<pea_> First we must define the Business requirements then we can figure out the technology to address and serve that requirement

Siva: point about walled garden is true, this is really a liability game, if you want control you get liability and deals get made,

<Herve_SIMalliance> http://www.simalliance.org/en/handset/handset_marketing/

Siva: not having common standards is actually perpetuating the walled garden problem

AdrianC: do you think it would make sense to have a common way to exchange APDUs

<pea_> The other question is the portability of these credentails across the multiple machines we use to access the services we desire.

Harve: We are at a point that it is possible to do what you are suggesting, some would really like the low layers

<Ullrich> Business model considerations: today the issuer pays for the secure element and wants a return on the invest, consumer centric does not have such an issuer.

Bruno: agree with you on the low level needs, and the fact that the time is right to do it

KarenLu: there has to be some way that we can make a compromise between the hardware community and the web developers
... need candid discussions on advantages/disadvantages in W3C to discuss and choose which layers to work on

tarcieri: interested in case where you provision your own keys on devices, currently use GPG, would like to do that via a web browser
... how do you handle these types of provisioning questions
... how do you expose encryption to users

<martin_paljak> tarcieri: I think there's a gap between "user keys" vs "service keys". The FIDO thing is more about "service owned keys"

Siva: from a standardization perspective, can expose the encryption, abstraction layer needs to be there,

<Anders_R> Are there any concrete proposal on how to bridge security elements and WebCrypto?

<virginie> message to pea : who are u, raise your hand to gte the mic :)

<virginie> message to pea : thanks !

Harve: there are different ways to consider the TEE, the market is not mature enough

<bhill2> I don't understand this liability thing. There are hundreds of thousands of businesses doing transactions on the open web today without any liability asisgnment.

<bhill2> Businesses figure it out.

<Martin_> @Anders: http://opoto.github.io/secure-element/ - relatively low-level as far as I can tell

Bruno: we currently know how to use the secure token to address specific use cases,

<solar> lots of businesses use google authenticator for 2nd factor authentication. Google assumes no liability. it still works.

<Ullrich> Banks, for example , do have liability

<solar> SMS OTP - carriers don’t assume liability

<bhill2> The issue here is rent extraction by device manufacturers and mobile carriers from people who want to deliver applications to users

<solar> it works

<bhill2> +1 to solar

<pea_> Degrees of Trust create different levels of liability

KarenLu: we have proprietary solutions for encryption,

<wseltzer> bhill2, it might be different ways of looking at the problem: assignment of rents through liability rules or fees

<Anders_R> @Martin: I don't see any links between http://opoto.github.io/secure-element/ and WebCrypto

<pea_> Exactly although rent may not be the right word.

<HannesTschofenig> The liability aspect is of concern only for a certain type of applications (such as financial transactions) but the attempt to lower the number of passwords on the Internet is much broader effort that also deals with many websites that have no liability challenges today.

<solar> extortion?

<virginie> note that the page listing the questions/use cases/semantic problems we raise is maintained here : https://www.w3.org/2012/webcrypto/wiki/Workshop_webcryptonext (#justsaying)

<colin_g> @Anders_R see https://github.com/opoto/secure-element

<Ullrich> Even MNOs suffer under fraud: if an MTAN fraud happens the CISO of the affected MNO will have to explain that to the affected user, law enforcement agencies, assurances and whatever

<Martin_> @Anders: OK misunderstood - you meant ways of utilizing existing WebCrypto w. secure element. Haven't seen any proposals. Maybe the key discovery API could be implemented in a way that would allow that. And the key disc. API could be extended to make it actually useful

KarenLu: we need to consider where to standardarize first

<bhill2> http://en.wikipedia.org/wiki/Rent-seeking

<solar> yes, but they don’t assume financial responsibility

<pea_> Renting space to story credentials that establish trust is the challenge many business have with some of the models under the table

<colin_g> what about trust / trusted / centrralized, vs. trustless systems, js.

<tarcieri> martin_paljak: yeah, I was talking about something more like a PGP key where you want to publicize the public key

<AxelNennker> Mozilla is currently implementing a Secure Element API https://bugzilla.mozilla.org/show_bug.cgi?id=879861 #T-Labs

Peter_Cattaneo: how do we get back to one the key reasons of doing this, if you define the box right, you can address security requirements and certification correctly

Siva: box in the browser should be at as high a level as possible

<bhill2> it's not about that pea_, it's about allowing user choice and permission-less innovation vs. having to pay carriers or device mfrs to access their users and exclude your competitors

<HannesTschofenig> Axel, didn't Richard tell yesterday that Mozilla will get rid of these point solutions?

Siva: if we can get that right, then we can work our way down through the other levels of abstraction
... need to keep the abstraction level higher initially

<HannesTschofenig> Brad, I would also say that it is about how much complexity would be added to a new crypto API when supporting these use cases that may not matter much for the broader Web ecosystem/Internet.

<Anders_R> Question: can end-to-end security be abstracted? IMO it can't

<pea_> bhill2 agree there are transactions or events that have trust requirements that do not need the security of hardware.

<Anders_R> FIDO/U2F is defined to the bit-level. for a reason

<bhill2> hannes, it doesn't matter how broad the markets are, it matters whether there is user choice and competition

<HadiNahari> Hard to imagine that a solution/proposal could succeed without having an accompanying open && free implementation (for cases where no liability is provided/requested.)

<AxelNennker> @Hannes, no sure what rlbarnes said. Mozilla and T-Labs are implementing the Secure Element API + Management API for NFC use-cases. First step is reader-mode, next card emulation mode which we need for payment applications

Bruno: Havre: if you take a higher level abstraction then you will need to have a one size fits all solution which may be very difficult

<bhill2> even if you were to hypothetically allow only banking, I should still get to choose my bank and my phone and my mobile service independently

<martin_paljak> bhill2: that sucks, that for "most people" you don't have competition in terms of who you pay taxes to.

<pea_> We need a solution that supports different levels of trust

Natasha: with my W3C hat, there are a number of high level APIs but also some very low level APIs

<HannesTschofenig> Axel: The issue matters since SIM manufactures here claim that they have no way anymore to get their functionality working because the browsers dropped support for all the features and you are telling me that new implementation work is ongoing to add functionality

Natasha: think we really need to keep it simple, there are alot of use cases here that I'm concerned about us focusing on all of them

<colin_g> user choice is key, end to end is always subject to some kind of attack, a major challenge will always be if you are looking at decentralized, trustless systems, how to you make them lightweight and tiny. That which is heavy and complex and difficult is not usable / easily implementable.

<Detlef> +q

Siva: there are clearly multiple layers, the question is who is responsible for the various layers
... the question is where do we start?

Bruno: all the responsibility is not to the browser developers

<HadiNahari> Browser cannot (and IMNSHO should not) provide all levels of trust: it should provide a common and standardized platform for "any" level of trust

<HadiNahari> then it's the responsibility of "trust providers" (underwriter of the assertions) to implement and stand behind the different levels of trust atop the said-common platform

<Anders_R> smart cards are used with multiple server providers, that departs from SOP. How do you intend to bridge/cope with that?

<virginie> to hadinahari : can u make your point on the mic ?

<HadiNahari> virginie: yes

<Martin_> The problem is that the lower layers are actually well-defined in many different variants (PKCS #11, APDU protocols etc.). But how to tie that to the higher-level (WebCrypto)?

Natsha: back to provisioning topic, there are lots of other bodies working on the lower layer aspects, don't want to cause conflicts

Philip: challenge: on one level we have a need for a very secure level of security (high dollar transactions or govt services) and at the other end we have a need for a much lower level (like buying a dog license)
... one end i see hardware and at the other end I don't need hardware
... need diversity between these requirements, how do we get through that business conversation so that technologists can get on with it

KarenLu: there is a need for different levels of assurance
... also different levels of convenience

<Martin_> Maybe the diff. security requirements could be accomodated, by having the browser implement a software-based secure element (essentially an emulator). So the API itself could target both a real hw secure element and a software element.

KarenLu: banks and health care providers are going to have their own risk models that will address these levels

<Martin_> software element could be implemented either just in-process in browser or maybe in a separate process or even in TEE for higher security

<tarcieri> Martin_: can use host card emulation

KarenLu: can have different levels of assurance within a single interaction with a specific provider

<engelke> +1 to Martin_

<HadiNahari> +1 to Martin_

<tarcieri> and yeah, +1 to Martin_ ;)

<Martin_> tarcieri: I'm thinking more about that the API and functions presented to the web app should be the same in either case. It would be possible to implement mechanisms to ascertain you were talking to a hw-based secure element vs a software one (assuming the sec. elements are shipped with manufacture-issued certificates like the "Endosrement Key" in the TPM)

<Martin_> *Endorsement

<martin_paljak> so, Mozilla has had it for ages (NSS with PKCS#11 support and PKCS#11 softtoken). Yet mozilla is retiring the (useless) pkcs11 interface.

<JeffH_> see HOBA.IE for example of software-based SE (key gen & key mgmt) + web authn

Natasha: in GSMA MobileConnect we have four levels of assurance, how to go about that level of implemention would not be the job of standardization

<tarcieri> Martin_: it'd be nice if it integrated with the OS's cryptographic services (e.g. Protected Storage on Windows, Keychain on OS X)

Natasha: if you open the API up to developers then there is some risk involved, currently only carries can access the SIM, depending on where you live you may or may not trust your carrier

<Martin_> tarcieri: Yup, agree!

Natasha: has to be simple but it must also do its job properly and not expose too much risk

<martin_paljak> tarcieri: actually, I would say that maybe not. they all suck (keychain on osx is horrible from hardware token POV)

<martin_paljak> Maybe the web as a platform with a browser as its manifest.

<tarcieri> martin_paljak: we're talking about a soft replacement for a hardware token here

<tarcieri> I like hardware tokens too ;)

<martin_paljak> should think big and bypass the operating system.

Hannes: what doo i have to do today if I am a web site provider and I want to provide access to the sim

<tarcieri> martin_paljak: why?

<martin_paljak> and forget the legacy (incl pc/sc and crypto services that are "old")

Natasha: same as any corporate / operator based API

<tarcieri> martin_paljak: OS cryptographic services are already going to abstract access to e.g. TPMs

<martin_paljak> and make "web-centric" adapter API (what cng/keychain basically is)

Natasha: there will probably be some financial aspect of that as well...

<martin_paljak> well, why have "NTF" that is fat32++ if we could have XFS ?

<martin_paljak> *NTFS

Hannes: presumably I would need to remove the username/pw from my site and figure out which providers my customers are using

<tarcieri> martin_paljak: I'm not sure we're talking about the same thing here...

<tarcieri> martin_paljak: the browser should provide a high level API... that can talk to hardware tokens, or software alternatives

<Martin_> @martin: Would agree that NTFS is just "FAT32++", it's actually a great FS. But it is besides the point ;)

Hannes: that is something that GSMA is working on as a product, users would have to be a subscriber to one of the operators providing the product, this is an implementation not a standard

<tarcieri> if you bypass the OS services, then the browser needs to talk directly to the host TPM

<bhill2> and, hannes, hope that your business is not one where the carrier has signed an exclusive deal or wants to compete with you

<Martin_> meant, would disagree NTFS is just FAT32++ ;)

<Peter_Cattaneo> http://gsmamobileconnect.com/ - uses OpenID Connect

Siva: there are two extremes: Sim in mobile environment (already distributed) or FIDO (not distributed)

<HadiNahari> There are free alternatives to paid TEE solutions

Siva: having an independent secure element that is agnostic to all these solution is possible, and no one here knows which one will win
... from a W3C perspective we shouldn't care

Hannes: lesson from the oauth work, some of the management things that we didn't understand later cased vendor lock in
... there is a standards piece that is missing

<Martin_> How about a GlobalPlatform-like API... like WebCrypto functions: InstallApplet(), SelectApplet(), InvokeApplet() where the applets would be JavaCard-applets (or similar). Security would be enforced as follows: The applet when called would get the "identity" of the calling JS code (i.e. hash of the code in the anonoymous closure or something like that) and could make its own trust decision. Note the browser would be "trusted" to send correct hash.

<martin_paljak> Martin_: JavaCard == Oracle. prepare to pay money after a strange lawsuit

<Martin_> Of course individual applets could add their own extra security protocols (based on signed commands or whatever)

<HadiNahari> Martin_: the GP model might work, but the business and ecosystem facets of GP model should be taken into account as well.

<Martin_> OK - then something like JavaCard that isn't JavaCard. I think Microsoft has .NET smartcards as well. Could be another minimal VM-like tech

(missed exchange on walled gardens and FIDO between Siva and Brad Hill - someone feel free to chime in)

<Martin_> NHadiNahari: In this case the installation of applets etc. should be open to all. The user might get some pop-up etc. since there's also space/resource issues.

<Ullrich> You have to discuss with Oracle to create a JavaCard OS. Different situation for applets ianal, of course

<HadiNahari> +1 on Martin_

Bruno: for egov cases we can't require all users to instll software

<Martin_> but in practice, regarding GP - has anyone ever seen a system where the user could "dynamically" install applets on their smartcard (as I think was the original model envisaged)? In practice, it seems to be about "one applet per smartcard" i.e. one card for banking, one for gas station etc.

<martin_paljak> actually, these days you can get a variety of GP compatible JavaCard-s with different price/feature properties really easily

<martin_paljak> it was not like this 10 years ago.

<Martin_> of course wouldn't have to be the same outcome for a new standard but shows standardization and openness is important!

<Anders_R> why install applets, most people only needs keys. the JS is the applications

<Peter_Cattaneo> Any smart card-based authentication can be used in a in SIM card; prorpietary or standardized. e.g. PIV authentication following NIST FIPS 201 has been implemented.

KarenLu: to Hannes' question on how the SIM is used, there is an ETSI standard that addresses how this would work
... basically PKI based, make authn request using the sender

<bhill2> sorry, this feels like partitioning the market in order for carriers / handset providers to seek rents from the most valuable / vulnerable players

<Martin_> Anders: true - but some type of access control to the keys and management thereof. Especially if you want the module to produce a proof (for e.g. the banking backend)that key is in hw. But if a good abstraction for these needs can be found, maybe "applets" will be unnecessary.

KarenLu: regarding GSMA MobileConnect, it is a framework for the mobile providers to act as an Identity provider under the OpenID connect

<solar> agreed - I can load an app on an iphone for free

<solar> why should I have to pay to store my keys securely

<bhill2> W3C is a subscriber to Open Stand and its principles

<bhill2> http://open-stand.org/about-us/principles/

<bhill2> One of those is permissionless innovation:

<bhill2> http://open-stand.org/permissionless-innovation-impacting-the-future-of-the-internet/

<bhill2> These secure element proposals just don't meet that bar.

<virginie> The open mobile API by SIMAlliance is available under : http://www.simalliance.org/en/all_resources/technical_resources/

<HannesTschofenig> Btw, whenever someone uses the term **trust** please add <who> trusts <whom> to do <what>. The <what> part is important since blind trust is typically pretty meaningless.

<martin_paljak> HannesTschofenig: yeah, trust means different things to different people in different contexrts

<solar> I trust that there will be muffins and fresh coffee at break-time

<tarcieri> cookies don't follow the same origin policy, FWIW :(

adam: need to discuss origin control

(scribe failure here...)

<harry> Quick note, there's nothing against Secure Element proposals or any other non-Web enrollment schemes as long as its a choice of the origin to use such as scheme.

<tarcieri> but +1 to the point of cross-origin questions

<harry> in terms of OpenStand and as long as the layer of abstraction necessary to access these elements

<bhill2> The access control specs for the Secure Element proposal are completely divorced from the reality of web applications

<bhill2> http://opoto.github.io/secure-element/#access-control-img

KarenLu: address origin in our submission paper

<harry> is done in royalty-free. We do understand there are patents on lower-levels in hardware, etc.

<harry> So we don't want to force any particular lower-level hardware based approach.

<bhill2> harry, I'm not talking about patents

<pea_> We seem to be dancing around the question of ownership and control of the container. SIM, SmartCard, TPM, TEE all have an owner who wants to earn money for their investment in the credentials. Then there is a need to have this permissionless set of credentials. Now the word origin is added to the conversations. We end up with words like Trust, Assertion, Liability, Distribution, Origin, Rent, Portability, attestation.

<harry> Then what are you talking about?

<bhill2> I'm talking about the fact that we have exactly nobody who proposes to implement this in a way that allows permissionless or user-driven access to these APIs

<harry> Yes, but not every waebsite will want "user-driven" access with registration/enrollment inbound in Web.

<vkata> Does that even make sense? I don’t want permissionless access to my government ID

<harry> Consumer facing websites with openeded users will.

<harry> But then govt. and many other high-security websites will want out-of-web enrollment.

<harry> That's fine - see no reason why both types of authenticators can't be supported

<adam_> Follow up wold have been, can we use existing cross origin sharing security for cross origin secure element senarios

<bhill2> it's a different thing to have access control associated with a credential as far as where that credential can be used

<HannesTschofenig> "I don’t want permissionless access to my government ID" --> This statement makes no sense to me

<harry> I don't understand that lats statement bhill2.

<tarcieri> adam_: like CORS? what origin does a credential belong to? what origin does my GPG key belong to?

<harry> In fact, it seems like having enrollment out-of-band from the Web actually is just one thing we don't have to think about in W3C.

<bhill2> if I have a government ID, maybe it has some internal access control that defines who it will release assertions to

<bhill2> what is being talked about here are not any kind of objective criteria for access

Martin: doing everything from scratch isn't sensible

<tarcieri> NIST curves--

<bhill2> this are pure pay-to-play APIs

<tarcieri> CFRG is standardizing Curve25519

Bruno: the solution that we provide must have backward compatibility with what is in the field...

<harry> Yes, and if some website wants to use an authenticator like a govtnmernt ID that has some internal access control, that's fine.

<bhill2> the determiner of what will work and who can use it is who pays the mobile operator or handset manufacturer

<harry> That's the user's choice to use that eID and the website's choice to use it.

<harry> Seems orthogonal to the spec.

<wseltzer> bhill2, we shouldn't discount the places people are willing to pay for different models

<harry> from the Web-level.

<bhill2> with no guarantee of open access or competition

<HannesTschofenig> CFRG is analysing different curves and may make a suggestion for a single curve or for multiple curves for use in the IETF.

<Martin_> NIST curves have not been shown to be insecure or indeed any way in which they could be insecure (unlike ec_dual_drbg where it was quickly discovered the parameters could have been generated in a way that would allow for a trap door)

<tarcieri> HannesTschofenig: sure

KarenLu: there are many contries that have deployed smart card based citizen IDs

<tarcieri> Martin_: have you seen BADA55?

<harry> There's a huge debate over NIST curves going on in CFRG and WebCrypto WG.

<bhill2> but Open Stand does talk about enabling competition and open access

<tarcieri> Martin_: the NSA could've tweaked any of the curve parameters

<wseltzer> sure, and free isn't the only model of competitive access

<pea_> When we speak of "Permissionless access" who is the relying party relying on?

<harry> Current state of play is Microsoft is pushing NUMS, Trevor Perrin working on 25519, and Google's Ryan Sleevi blocking the MS proposal to put a non-NIST curve in the main spec.

<adam_> tarcieri: I think what uses your GPG is your choice, I’m wondering if there’s a way for issued keys to default be enumerable by a sensible origin

<harry> We'll hopefully get a compromise shortly.

Harve: we cannot behave as if nothing has been developed and deployed thus far, we need to build components of the queues

<harry> bhill2, you are reading far too much into OpenStand.

<vkata> I don

<bhill2> right, but none of the proposed implementers here have made any guarantees of open access

<Martin_> tarcieri: Yes but no one has shown a "tweaking algorithm" in which the generator of the curve params. can make them insecure - unlike the case of ec_dual_drbg where this was quickly discovered and the only question was if the parameters had been generated this way (they had)

<harry> It would probably be anti-competitive to prevent people from using custom access control schemes in particular authenticators.

<HannesTschofenig> There is a lot of critique regarding the NIST curves in terms of security (i.e., the choice of the parameters) but also regarding the performance. If you compare it with the Curve25519 then Curve25519 is much, much faster with the same level of security.

<bhill2> competitively priced exclusive access is rent-seeking that is hostile to user choice

<tarcieri> harry: last I checked, NUMS curves were still slower for ECDHE use case

Kathy: What would you like to see from the Web Services API that would enable hardware tokens

KarenLu: something that eliminates proprietary solutions

<JeffH_> please no ECC curve dogfight here

<tarcieri> heh k ;)

Bruno: to be able access hardware tokens from web applications

<Martin_> Hannes: They could be better, but there's a difference between being "not optimal" for everybody's use, vs having a backdoor meaning that the generator of the parameters have a distinct advantage

<Martin_> ;)

<harry> bhill2, different sites will have different takes on access.

<martin_paljak> JeffH_: the point is no dogfight about curves but just a call for common sense

<vkata> I don’t seen the disagreement then? I don’t think anyone wants to exclude an open API, but if access to the underlying provider (e.g. gov’t ID) can be restricted out-of-band, then the permission to use it may or may not be free as in beer/speech/[insert favourite cause here]. However, if the underlying provider charges money, and the website doesn’t want to pay, as long as they can use a free/better provider, all requirements are fulfilled, no?

Harve: be able to access the hardware through APIs, leave it to service providers to define what is in their boxes

<harry> It would be frankly just as silly to ask Finland's eID health care services to use "user-centric access" rather than their own PKI eID scheme

<HannesTschofenig> Martin: not sure what you mean. I have done some performance measurements of the Curve25519 curve on ARM hardware and they the curve is super fast. The NIST curves are slower. I let others to judge the security of those.

<harry> as it would be to ask Paypal to use US govt-authorized CAC/PIV cards.

<colin_g> @HannesTschofenig +1 Hannes - the notion of denying some sort of 'permissionless access' doesn't make much sense. but what people seem to fear is that information that is particular to them may be used against them or to obtain resources that are particular to them in some way. This is not necessarily unique to identity but may be oriented about things which have to do with all sorts of things: finances, id, any cryptographically certifiable thing

<harry> We need to support both kinds of use-cases

Siva: don't want to make the browsers a walled garden

<harry> I think that's fairly obvious and has nothing to do with OpenStand.

NAtasha: there should a discovery element of a hardware token that you can do something with

<harry> Most websites will *not* use strictly controlled smartcard eID systems

<harry> but some important ones will.

<Martin_> Hannes: It was claimed above the NIST curves were insecure. Just pointing out that's not the case (at least not according to "public" knowledge).

<colin_g> @harry smart property as example

<harry> Most websites real need to kill password using an open scheme that allows Web-based enrollment.

<harry> W3C should support both user-facing websites with open-ended users and sites with high requirements. We don't want to at W3C to legislate any particular trustmodel.

<harry> Those are site-specific.

<HannesTschofenig> Martin: I also do not know of any information that the NIST curves are insecure. I have only seen the talks that it is easy to implement them in a way that the implementation is insecure

<tarcieri> Martin_: it has been demonstrated that any of the curve parameters could've been tweaked, and there's no justification for the seeds that were chosen

<tarcieri> Martin_: unlike the NUMS curves, the NIST curves are defined by constants that are very much not of a "nothing up my sleeve" nature

<bhill2> harry, I'm talking about whether Samsung or Verizon allows the customers of any bank to install that bank's trusted applet on the phone, or only the banks that have paid Verizon

<Martin_> tarcieri: True there's no justification, but haven't seen demonstration they could have been tweaked. Please send ref. then we can discuss later :)

<harry> If that's how the origin works, I don't see how we can say "no, you can't do that"

Detlef: wants to address the question of layers and what the API should look like, how do we want to implement the stack, will it be open source

<bhill2> I totally expect that credentials might be locked to a particular applet

<tarcieri> Martin_: I think the burden of proof is on the NSA/NIST as to why their curves should be trusted

<wseltzer> bhill2, see EME?

<harry> Just like we can't allow Finland eID sites to be accessed by random people who self-enroll :)

<bhill2> sure

<harry> We just have to allow agility on trust models

Detlef: how do we want to implement the open web stack

<harry> I agree that most normal websites will need U2F/UAF style enrollment

<Nadalin> Come on folks, please state what is wrong with the current WebCrypto APIs? what addtional features are needed? What usecase would these changes enable ?

<harry> there's just different trust models for different sites/services.

Siva: it needs to be the highest level possible that is common across the various existing standards/solutions, independent of the implementation

<bhill2> but we should not be giving support to a model that is about gatekeeping of access to strong authentication technologies behind a pay-to-play model controlled by oligolopies

<bhill2> everyone needs trustworthy technology

<harry> I think people will vote with their feet here.

Siva: where the line is drawn is left to the web browser development community

<tarcieri> Nadalin: I need to look at what normative recommendations have been made about algorithms. Last I checked there wasn't any, but apparently that's changed

<harry> For example, some people may trust their eID card more than a Google Yubikey in Europe

<martin_paljak> harry: as a representative of a country (sort of) I'd expect this not to happen.

<harry> in the USA it will likely be reverse

<tarcieri> JSON Web Encryption is also standardizing algorithms, so it's curious that WebCrypto is trying to standardize them independently :|

<bhill2> still not what this is about

<martin_paljak> harry: in fact, people from other countries use their feet to get into european e-services via estonian living permit, to get the eID

<harry> We have different levelfs

<harry> of algorithm authentication

<Anders_R> @Nadalin: there's nothing wrong with the API, it is the ability to use other keys that's the problem

<harry> JOSE does ciphersuites

<harry> WebCrypto allows a much lower-level of parameter choice

<harry> just to be clear,that's why there's the difference.

<colin_g> smartcard chips and NFC are part of smart property implementation in bitcoin, some details here https://en.bitcoin.it/wiki/Smart_Property

<tarcieri> harry: ok

<harry> We tried to co-ordinate but JOSE didn't want to go to the level of detail WebCrypto allowed

<tarcieri> harry: that's reasonable

<tarcieri> haha, I see

<harry> and WebCrypto didn't want to restrict in the way JOSE did.

<harry> Both approaches are quite sensible.

<harry> A "high-level" version of WebCrypto shold probably use JOSE ciphersuites

<harry> I expect someone to polyfill that soon :)

<Nadalin> @Anders then that is a problem with the current APIs as they can't get a key other than software keys, so that chnage would enable hardware key storage

<JeffH_> seems to me it's the case, for better or worse, the "mobile" world is under the control (esp. in the USA) of the MNOs and they can control access to essentially any features (hdwr or sfwr) in the handset (much to my personal dismay)

<tarcieri> that would be nice, especially since they're all INDCCA3

<Anders_R> The bridge between smart cards and WebCrypto which I have pestered mailing lists about remains to be defined

<Martin_> Anders: +1

<bhill2> for me the issue is whether my mobile operator gets to choose which bank I can use, or which health insurance company I can use, based on which pays them the most money, instead of my getting to choose based on who gives me the best service

<virginie> to wseltzer : do not panic, but, looks like minutes are empty ...

<bhill2> the analogy is to network neutrality

<Nadalin> Local Key Discovery is missing from the current web crypto APIs, this should be optional as there will need to be a way to import keys as we have today in the APIs

Detlef: is someone planning to implement the webcrypto API?

Natsha: it depends on your audience

<virginie> Annoucement : there is a queue, guy, and by the way, it is closed...

Harry: it has been implemented already (version 1)

<Anders_R> @Nadalin, this audience is not talking about optional features...

<Anders_R> it's should be in the core

Siva: part of the objective of this group is to define what extensions are possible

<harry> there will be no new core features in version 1.

Natasha: there will be different offerings and tht is ok

<Anders_R> of course not

<harry> We could also put authentication in a different API

<virginie> to detlef : impelmentations details of web crypto are availble here https://www.w3.org/2012/webcrypto/wiki/Main_Page#First_implementations

<tarcieri> harry: that would probably make a lot of sense

<HadiNahari> queue mgmt sucks 8-)

Brian: i'm microsoft research, not Internet Explorer, we have alot of interest in that

<Martin_> As for who would implement the spec... speaking for a national ID impl here: We would expect to implement the application-level (i.e. JS code in the webapp) and optionally an applet or similar in a SE to support our requirements. We would expect the code that would go from the browser and bring the commands down to the hw (SE, TPM, TEE etc.) would be part of browser, OS etc. and not for us to do.

Hadi: I don't want to see everyone representing their own business cases that creates a lot of complexity... it would be best for the browser if there was a free and open way to take advantage of the hardware

<HannesTschofenig> Brian, various companies involved in the ecosystem will ask themselves what their incentives (and disincentives) are in providing certain functionality and other business models. If you have ever participated in standardization efforts you will most likely agree with me.

<bhill2> +10000000

<tarcieri> +10000000 too ;)

<martin_paljak> complexity is bad, of course.

<rbarnes> Martin_: it's not impossible to have an APDU-level API, e.g., http://www.w3.org/wiki/images/6/6f/SysApp_-_Secure_Element_API_-_intro.pdf the trouble is how you access-control it

<JeffH_> ditto wrt Hadi

Natasha: GSMA is talking to W3C, we are committed to creating something open for W3C

<tarcieri> hahaha :)

<JeffH_> @virginie -- Hadi essentially built on what Brad was saying

<bhill2> customers pay for devices with secure capabilities, services are willing to do the work to create secure clients, or go through a RAND certification process

<HannesTschofenig> Brian, just to add on my last statement: Just think about Apple who has just launched a payment API might need to think about spending resources in implementing functionality into their phone to allow operators to compete with them in the payment environment.

<bhill2> but services are not willing to pay middlemen for *access* to our customers

<virginie> @JeffH yes, but from a device maker perspective, it is more innovative :)

<bhill2> and customers do not want to have our choice dictated by rent-seeking by our carriers

Siva: there is no other forum that we are involved in that could be as neutral as this one

<rbarnes> HannesTschofenig: Apple is usually not a good example in any standards discussion :)

<JeffH_> My observation above was that no matter what we (w3c, bwsr impls, etc) do here -- the MNOs have ultimate control over what's delivered to the users (in many but not all markets) -- the latter is a legal/regulatory problem, not technological

<tarcieri> HannesTschofenig: Apple largely used industry standards already implemented throughout Europe and in Google Wallet

<Martin_> rbarnes: Absolutely agree about the main issue being access control

<virginie> Note that open source TEE is developed in Linaro, available here : https://wiki.linaro.org/WorkingGroups/Security

<HannesTschofenig> Richard: I wantd to pick an example of a company not in the room. One does not need to study economics to see that the incentives may not be super well aligned.

Harve: tradeoff between openness and liability

<vkata> HannesTschofenig: I thought the whole point of browsers is to allow a level playing field. So if a browser vendor happens to implement something that can also be made on top of a browser, of course they would have to spend resources enabling people to compete with them.

<bhill2> Would any implementers make a RAND pledge for access to a Secure Element?

<Phil_Hoyer> @JeffH_ please en to a hardware toejn via NFCnote that SE does not equal UICC SE API would also allow embedded or ev

<rbarnes> Martin_: if we can come up with an access control story, i think there's some cool possibilities. e.g., using JS as a dynamic adaptation layer between APDUs/SE-specifics and a standard interface

<bhill2> Doesn't even have to be RAND-Z, just RAND>

<Martin_> rbarnes: +1

<rbarnes> Martin_: cool, let's go build something ;)

<bhill2> http://en.wikipedia.org/wiki/Reasonable_and_non-discriminatory_licensing

<harry> In terms of DRM, is the underlying access to the DRM hardware being shipped with Google, Microsoft, and Mozilla's backing RAND?

<harry> I believe just the EME level is royalty-free

<rbarnes> harry: that was exactly why i brought it up as prior art

<harry> I believe the same thing would be the case with any authenticator work around hardware.

<virginie> to wseltzer : thanks for fixing the minutes :)

KarenLu: ideally we will have a nice interface to hardware tokens

<harry> We would not want to "bind" the authenticator in *any* non-neutral way to any hardware, as that hardware may not be RF.

<Martin_> if the API ends up being sufficiently open and useful, devices that don't implement it will be at a disadvantage since they won't support various applications. So manufacturers will eventually be forced to hook their SE's etc. up to the WebCrypto API (i.e. the upcoming version)

<harry> That's why level of abstraction is needed.

Hadi: standards are necessary but not sufficient, you also need free open source software, not everyone needs liability,

<HannesTschofenig> @vkata: "I thought the whole point of browsers is to allow a level playing field." --> Very much like mobile operators have been interested in creating a level playing field.

<colin_g> I realize there are lots of perspectives on this but I don't support DRM - it's 'defective by design.' There are various browsers that don't / won't support DRM going forward, _some_ of them are shown here https://wiki.debian.org/WebBrowsers

<public_screen> [break]

<HannesTschofenig> I like workshops with a lot of discussions. This certainly is one of those...

<vkata> HannesTschofenig: I don’t understand the point. Is the implication that there’s a mandatory barrier of entry other than vim?

<Martin_> colin_g: Many types of DRM are defective by design. I still think DRM, when considered broader than "protection of video etc.", but I think that there are other use cases

<Martin_> I meant to say: Many types of DRM are defective by design. I still think DRM, when considered broader than "protection of video etc.", has interesting use cases. And they can be realized based on open standards

<Martin_> consider trusted execution technology, and similar

<colin_g> They certainly can be realized basedon open standards, but it seems wrong to me to require them in many common technologies, browsers, etc., and not give users a choice

<tarcieri> https://twitter.com/sleevi_/status/510132960549298177

<tarcieri> sleevi +1 for splitting AuthN from everything else in WebCrypto ;)

<inserted> scribenick: wseltzer

New Security Features for the Web

Web Cryptography & utilizing ARM TrustZone based TEE (Trusted Execution environment) for authentication, cryptography and beyond by Ilhan Gurel (Trustonic)

Ilhan_Gurel: Why use a TEE?
... isolation between secure and insecure at the hardware level
... handle secure data without revealing it to rich OS
... Different use cases from Secure Element.
... e.g. trusted UI
... use cases: DRM, trusted UI, authentication
... Trusted UI: secure interrupts, touch-screen interaction
... secure credential storage
... crypto and key management
... e.g Android KitKat Keymaster
... Trustonic: ARM TrustZone based TEE solutions
... Solution W3C chooses should: be based on standard JS APIs and/or HTML tags
... have abstraction layer for low-level inmpementations allowing usage of TEE/SE
... allowe webapps to choose and use TEE/SE

Giri_Mandyam: Qualcomm Innovation Ctr., Multifactor Authentication based on User Contextual Data and the Mobile Web
... web ecosystem moving beyond username/password;
... Device APIs provide contextual data, e.g. media capture and streams, geolocation
... gUM, audio fingerprinting from capture stream
... PSAP (public safety answering point) needs unspoofable location info
... need secure means for reconfiguring authenticator
... Geofencing use case:

<colin_g> Multifactor Authentication... (Conceptually) Can 'Facets,' Such as Distributed Public Keys Operating as Shared Partial Identities, Function as one of many Facets or Factors in Certain Authentication Frameworks? http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_12.txt

Giri_Mandyam: gathering items in a store, then automatically paying on geofence breach (leaving the store)
... or dispatch and delivery

<HannesTschofenig> The figure was missing the absolute values of power consumption

Giri_Mandyam: Contextual data has a place alongside multifactor auth
... contextual auth must be non-spoofable and trustworthy for web service providers.

Mike_Jones: (selfissued) Microsoft, The Increasing Importance of Proof-of-Possession to the Web
... Many initiatives to use proof-of-posession in web protocols
... unstealable cookies, passwordless login, proof of eligibility, etc.

<virginie> Annoucement : the wiki capturing the workshop questions/area to explore is available under https://www.w3.org/Security/wiki/IG/webcryptonext_workshop (accessible by W3C members)

Mike_Jones: e.g, TLS channel binding
... OAuth PoP work
... PoP for login
... Proving eligibility to participate
... e.g. Netflix watching

<colin_g> Platform-held key vs. user-held key (key held / owned on computer or other device)

Mike_Jones: we will need js support for using platform keys to enable js apps to participate
... WebCrypto specs will need to enable use of platform and device PoP keys for JS apps to participate in PoP world

Vladimir: Ericsson, Cloud Service Privacy in a Pervasive Monitoring Landscape
... How do we secure not only authentication of the user, but data?

<colin_g> The costs of data everywhere... encrypted vs. unencrypted, metadata everywhere, MITM, endpoint attacks, more

Vladimir: WebCrypto relies on the origin server being trustworthy
... that's not enough
... need to protect against service provider, data breahes, and government demands
... protect keys and data from the hosting app
... e.g. cloud storage needs privacy in the cloud, on host and client sides
... need: secure file input/download where cleartext is not accessible by the webapp js runtime
... HTML forms, need secure forms, e.g. Google's end-to-end chrome extension

<tarcieri> this talk reminds me of my blog post ;) http://tonyarcieri.com/whats-wrong-with-webcrypto

Vladimir: Need to protect in such a way that service provider can access neither keys nor data.

Jonas_Andersson: Fingerprint Cards, Enhancing privacy in token based electronic identity schemes
... We make fingerprint sensors for mobile phones
... working to expose API through Global Platform, integrate in TEE
... A number of mobile phone OEMs have integrated fingerprints
... Most of the apps available are local unlock
... But Samsung-Paypal, Apple Pay, showing possibilities of generic identity token
... We think mobile phone is most attractive identity token. Security, TEEs, Secure Elements
... paid for by the end-user, so distribution is managed

<rbarnes> always nice when somebody else pays

Jonas_Andersson: biometrics
... Privacy. major barrier to use of mobile as identity token
... "identity is a positive thing" basis of trust, relationship

<colin_g> identity vs. anonymity

<tarcieri> privacy++ anonymity++

Jonas_Andersson: privacy is EU-defined as control of identity
... a major point of privacy is security in identity allocation

<rbarnes> nice that the fingerprint guy is leading with privacy

Jonas_Andersson: when you talk about biometry, everyone worries about privacy
... We have a limited supply of biometrics
... we can't disown our fingers
... biometries aren't secret. but users are in best position to display them conveniently
... EU: privacy in biometry comes from the system, training officials, oversight

<colin_g> we all decide how to identify ourselves or how not to do so, or whether and how we will disclose which sort of identity we have opted to choose for ourselves assuming we have chosen one

Jonas_Andersson: we can turn this into a problem for technology

<virginie> paper detailing view from Jonas is here : http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_4.pdf

Jonas_Andersson: We have to define standards on security, guiding users to make reasonable choices among objects

<virginie> a scribe is expected, any volunteer ?

<bhill2> scribenick: bhill2

<virginie> floor to question ...

colin: question regarding biometrics on tokens owned and controlled by user for local verification, believe there are still privacy issues - at moment you assume that e.g. using a token based eID scheme

… regardless of biometric integration, you are deciding that the type of identity is required of the user

… no choice whether or not use that for authentication at a variety of services

… but that is obviously a privacy issue because of a diminishment of choice

… minimal ability to opt out or choose from a range of authN options

jonas: may have slipped in text that what concerned me was privacy issues regarding use of biometry

… if biometry is only in a secure environment controlled by the user, there is no privacy issue for that data

… but how the authentication is used, there are obviously implications, and in some situations, e.g. with governments, to some extent with banks, we give up much privacy and control of our identities

… and modalities of authentication

… always a trade off, using a stable identity with a service conveys benefits I may choose

… solution with cryptographic token, so long as it is not your id card or passport remains a powerful system

… token could be privacy invading, but you could have multiple ones to make it difficult to trace

mikeJones: if when you use a biometric you are unlocking a platform key, esp. if specific to the party you are sending it to, no privacy issue on the wire
... taking a poll

… for web to participate in proof-of-possession, we have to expose apis to let web apps use securely held keys in platform or hardware

… who believes this proposition?

… to employ the key

most of room raises hands

richard barnes does not believe this premise

richard_barnes: we can do something important if we only get proof of possession, but no need to arbitrarily use key in any other way

mikeJones: if we don't do that in rechartering, we have wasted the effort

virginie: which API or feature you think a browser should implement to answer your request?

<pea_> IF we agree to the premise that we wish to allow the use of "Secret" keys to contrinute to a cryptographic function. Then do we agree that the use of that key needs to occur in a secure environment?

sorry missed that....

mikeJones: need to use keys not held by browser

giridhar: take advantage of all device apis, trust moving in both directions - trusted origin, what is that?

jonas: means to authenticate to out-of-band factor

Ilhan: handle keypair generation, sign, etc. should be possible to extend this to use, e.g. TEE

<pea_> Let me also add storage of that those secret keys be stored in a secure peice of hardware

apologies, I missed scribing vladimir's response - can anyone backfill?

siva: concerned about biometrics being lost, it will happen. in case of geofencing, I don't have a choice and device will do it.

… reducing power makes it more likely that it will be ubiquitous

<harry> if your biometrics are lost, you can always cut your fingers off :)

jonas: you can look at levels of security achievable for biometrics stored in a e.g. lost device

<siva> can i borrow yours? :)

… can put in secure element, encrypt it, use templates that don't store full images, irreversible templates

… you should select devices you consider to be secure, also remote wipe

<Ullrich> Probability of guessing and faking biometrics depends on biometric trait and configuration

… we can establish with certifications to what level data is secure and public can make sure it meets expectations

<pea_> I assume the "found" Device remians capable of Authenticating the individual / Owner who lost the device at the crime scene.

ilhan: in TEE biometrics can be encrypted before storage, or put data in special partition

siva: where are keys stored?

ilhan: can do key derivation, wrapping and unwrapping

giridhar: for geofencing, there are agreements e.g. between operators and delivery people

vladimir: not as concerned about specific storage of biometrics so long as it is possible to provision and make use of keys

… yes I might lose a picture of my face or fingerprints, but if i lose device, there is other data on it and my prints are probably on it

… we want to enable storage mechanisms to evolve, not the question

<colin_g> basically: there are serious privacy concerns to any proposal that removes user choice (e.g.: biometrics as authentication requirement, "realname" as authentication requirement, anything as "requirement." Anything which deprives user of choice is a serious privacy concern amongst others.

mikeJones: most people only use 3-5 passwords

… ability to phish and leverage that is what we're primarily combating

… use appropriate measures for biometric and lost device risk, but existing risks are low hanging

wseltzer: vladimir laid out a component that is missing from most web security discussions, what are the steps to take?

<JeffH_> +1 to Mike

vladimir: might be an entire group that could look at that over years to determine how to do this

… sprouts of proposals mentioned in the document

<tarcieri> http://css.csail.mit.edu/mylar/mylar.pdf <--- one approach to building E2E encrypted web applications

… to they make sense, can we treat data in the browser as privileged data for the user but not exposed otherwise

wseltzer: how do we use TEEs and secure elements in open systems? balance user control and access to their device with security

ilhan: giving key vaults as example
... default is software impl, can be replaced by hardware

… server may want to find and use specific hardware modules

mikeJones: you don't get privacy for free you get privacy if you put it in by design

… fingerprints are global identifiers but if you use them to release use of keys that are specific to a particular directed interaction, on the wire you haven't created a correlation handle

siva: question for mike. what is next from a webcrypto api perspective should we start thinking about in extending leverage of keys?

mikejones: agree in next few hours on new charter language for new work, probably very short

… goal of new chartered work is enable use of keys not held in browser from the browser

… then get best thinking on how to do that in simple and general way so it is usable and gets used

<virginie> chair reminds that no objection is authorized until we reach the afternoon discussion :)

vladimir: no objection. keys are beautiful and great, but the keys will be absolutely unusable if there is no good way to communicate which key I am using and why

<tarcieri> +1

<rbarnes> generic key access is one of many use cases that people in this room have

giridhar: geofencing as authenticator, existing api doesn't cut it, we should go beyond keys for authenticating users

<virginie> note : use case has been captured under https://www.w3.org/Security/wiki/IG/webcryptonext_workshop

<engelke> +1

ilhan: agree goes beyond keys

<colin_g> Let the user decide

karenlu: there are many options beyond keys but need to start somewhere

<HannesTschofenig> I am curious whether there is interest in geofencing?

<rbarnes> HannesTschofenig: +1 not relevant to this discussion

giridhar: being overly focused on what can be stored in a discrete piece of hardware is too discrete

Peter_Cattaneo: in real world where people use keys there is usually an associated policy

<HannesTschofenig> Policy is a scary term since it is so generic

… want to extend policies to include whole world of sensors like geofencing

<Nadalin> fq+

… not only crypto but policy associated with crypto

<pea_> I woudl think Policy is simply the governance of the use of something

ilhan: if we generate or import key we can add metadata

… quite easily, if apis exist to pass this information to the hardware

mikeJones: I'm an advocate for claims-based identity

… make decisions about interactions based on claims

… on example might be where are you, what time is it, who said you are an account holder at google?

… in terms of scoping what we would do, we can enable people to use crypto to make authoritative statements

ilhan: may fully utilize power of cup in key environment, e.g. to speed up advanced operations

<tarcieri> PCLMULQDQ FTW ;)

<JeffH_> "cup" ?

mikeJones: state an assumption - how do keys relate to biometric factors? my assumption is you use these factors to give permission to use the key

… also I believe that all of that permission to use a key work is out of scope for what webcrypto wants to do

… there is work that platform vendors may do and other places we need to work on

<virginie> to tarcieri : hum... what do you mean exactly ?

… how do we easily enable choosing the right key with right biometric

<tarcieri> virginie: that was re: exposing fast hardware instructions for cryptography

… so phishing app can't misrepresent what keys it is using

<tarcieri> it's a CPU instruction that can be used to accelerate GCM

vladimir: we all agree on beyond passwords, identity is an assertion, replacing passwords is loaded but also effectively replacing username

<JeffH_> the "other places" might be other W3C WGs or other SDOs

rbarnes: keys is an easy way to understand how it fits into webcrypto, but am concerned after this discussion

<JeffH_> need to remember that "the browser" is "a platform"

… there are lots of tokens out there that won't provide you that access

… raise hand if you have token that can't sign / encrypt arbitrary data

… semantic level of webcrypto api is "sign these octets"

<harry> hehe "box"

<harry> rbarnes brought up that term

<Anders_R> i think a "bridge" is what we need rather than an a "box"

<tarcieri> heh

nadalin: agree that keys are important but lots of devices can't handle just key usage

… not sure how many people have read current set of webapis and can tell me what is wrong that won't enable their use cases?

… need concrete examples to understand how to change them

… we can augment, but not change core set, must be somewhat compatible with what we've already put out there

<colin_g> http://www.w3.org/TR/WebCryptoAPI/

vladimir: you didn't consider protected from application itself?

nadalin: not in scope of crypto apis?

<HannesTschofenig> This sounds a bit like DRM to me

vladimir: if you are to have secured data, I need to get key to decrypt data

<virginie> reminds that the workshop is about webcrypto, yes, but is not limited to

harry: this workshop can produce requests to other groups outside of webcrypto

… e.g. geofencing out to appropriate WG

… have a hold up on 2 levels

… crypto key level, what level of abstraction do we want on authentication

… everything is in scope for the workshop, if not for any particular WG

jeffH_ is ready for food

<colin_g> @JeffH +1

<JeffH_> ja

mikeJones: happy to have unanimous agreement on something to do

vladimir: important to protect data

giridhar: take recommendations to other WGs, happy to get new use cases endorsed as a chair

jonas: we covered the biometric area, I think it's a useful view to have conditions on use of keys and verification as one condition

ilhan: if we enable better management of keys and periphals we enable better security

<tarcieri> bhill2: fight the good fight for simple authn during the rechartering! :)

<colin_g> read my paper! it is fun http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_12.txt

Next Steps on Chartering

<inserted> scribenick: wseltzer

Etherpad, http://etherpad.mit.edu/p/webcrypto

Israel_Hilerio: Algorithm discovery API
... use case, evaluate user-agent capabilities before execution
... in order to secure complete process, you need to know all the algorithms will be available
... avoid the weird patterns of creating temp keys just to validate algo support

[slide: Scenario #1]

[slide: Scenario #2]

[slide: Proposal]

israelh: proposal, create a synchronous API that checks if a list of algos are supported
... return true if all supported, else fail on first unsupported

engelke: Is there a reason to provide a list, rather than asking "what's supported"?

israelh: reduce fingerprinting risk

Phil_Hoyer: you can re-run the query to fingerprint

israelh: it reduces the risk

harry: Now, we're going to discuss chartering

<virginie> thanks israel for the contribution

harry: first, let's get sum-ups from browser vendors. What have you heard, what might you do?

Dirk_Balfanz: I'm not on the chrome team
... there are a few things we're not going to do on the web
... raw sockets
... very low-level access to smartcard seems in that category
... APDU-level access
... very difficult to write to.
... for example, how would I write the google login page with a low-level api
... don't want to introduce a huge web tracker
... Box proposal: high-level API, e.g. "sign this", browser hands to the box implementation
... in chrome, extensions have access e.g. to USB
... but, how does that not turn into driver hell?
... how do we put things into the box?
... Support for existing stuff?
... Existing solutions that don't use the web aren't necessarily broken
... but it's a different model, how do we support it on the web
... how to distinguuish which have privacy, access control models
... minimalist option, hardware-bound keys, outside the browser, origin-scoped, tied to some auth
... hard enough to make that work
... is card there or not, how do we do attestation, etc.

<inserted> scribenick: Karen

Scibe: Karen

Dirk: this is what we were thinking on ; what can we minimally do

…let's do hardware keys, not in browser

…and let's tie them to some sort of authentication

…hard to figure out how to make that work

…if we scope to that level, we will have our hands full

…strong authentication; killing passwords, maybe some encryption; but no identity API, no tax ID number

<wseltzer> s/Scribenick: Karen

…I guess you cannot do…if I understand banking…cann't do how that works

…maybe be move to a federation model, such as with bankings

…no, bigger piece would be the box model

…could give us what we want but would be harder

…how to prevent global tracking mechanisms; prevent driver hell

…my recommendation is unless someone can calm me down about the box

…minimalist approach; do keys, origin-bound

…and see where we are next year

<bhill2> +1 to Dirk

Richard: I have a lot in common

…starting with keys perspective

…obvious place to start; but not sure it's as simple as you think

…if cards are not built to support this interface, you still need an adaptation layer

…that's what I've gotten last few days

…if we are going to support…diversification

…general API

…also need a lower level fine grained API that is tightly controlled

…JS can access the API

…some model of authorization; whole story to figure out

…I think that is something…setting up a sandbox

…is something we need can figure out the access model

…we have high level API bin

…and bin for low-level APIs

…to help bridge the technicalities up to the higher level

…and need for some access control story to knit these things together

…and the browser needs to figure out how to load

…and discover code you need

…and make sure it's right code and authorize that

…If I were in charter discussion, those are the high-level bins

<Rob_Philpott> can we display the IRC?

Brian: I will take a slightly contrarian POV

…what I heard as being interesting

…is the multiple origin problem

…we have model where JS assumes...

…if folks use keys from multiple sites, you have to fix that problem

…multiple tokens and multiple sites

…second point is a secure channel between the browser and secure client

…and whether adding isolation boundaries

…or issuing @ to driver

…whatever it is, it is those two problems to figure out

…a secure channel to token

…and have it figure out who is allowed to talk to it

…two fundamental security problems

…security policy on who gets access to what

…the reason I have a little trouble with low-level access to tokens is that @ have already done that

…I don't know how many people want to do that again

…wonder if way to think about it

…is a lower level interface layer

…and an interface between existing OS and interface

…everything has in one form or another

…and do that translation

…I don't want to make every smart card manuf to redisclose what their smart cards do

…i still have to control how to expose that

…still focus on the interface

…that does not work for everything

…works for OS

<nvdbleek> brian: thank you for acknowledging the importance of muliple origin access to keys

…now talking about IoT devices that might not have that

…that would be a way to get some of the heavy lifting done

Phil: I think the general approah

…I agree with

…also suggest we think about other use cases to support

…access to key and pin

…rendering of that

…is the browser, or the signed JS in the sandbox creates the GUI

.,..maybe another bridge layer that's more dynamic

…I think there was an open smartcard

…some cards are already written in JS fashion

<nvdbleek> shouldn’t we listen to Israelh’s view?

…agree there is a pain point for middleware cos

scribe: but general approach is correct one

<HannesTschofenig> I agree that we should hear from Israel if he is from the browser team

Siva: Take some of middleware each hardware vendor builds

…making money in the hardware

….make another separate WG in W3C

…if this box is high level enough and various other boxes

…that may take all of our proprietary efforts and verticals

…and take more details

…and put complexity somewhere else; have abstraction layer

<israelh> Happy to share IE's point of view.

Richard: higher level are going to be more challenging to design

<harry> boxes inside boxes

…at lower level is card talking to itself

…the capabilities of cards dictate that

…higher level, people will need to cooperate and compromise on the funcationality

…and look at putting under common umbrellas

Brad: with my hat as WebApps Security chair at W3C

…we have heard about install base of token systems

…but also install base is the web itself

…we should do a 'Hippocratic Oath" approach of first do no harm

…first not do any harm to existing privacy that billions of web users rely on

…early in career learned that formal models don't always match up

…collide six billion cards with four billion web users, there would be a lot of carnage

<Martin_> I think he might have meant 'hippocratic oath' ;)

Dirk: I am not proposing to say do harm to the web

…here is something we have to figure out to do is right

…But worried that we will argue over these open questions for a long time rather than get stuff done

…I am not seriously proposing this

…but let's say we approve the FIDO specs

<JeffH_> maybe it was webocratic?

…then device manufacturers know what to do…build FIDO compliant devices

…don't want to just argue about stuff

Richard: Would be radically simpler to say get rid of old devices

…and new ones can point to web

…another alternative is to address these legacy devices

…either de novo and throw away the past

…or have some new story

…I would be interested in thoughts from the room

<bhill2> I'm not suggesting we *have* to abandon existing systems

…do we create a whole new API built from the start

<Detlef> +q

…not sure which would get results faster

<bhill2> just that a guiding principal in how we integrate them should be that we not harm the existing web security and privacy model

Israeth: Web Crypto spec seems to be at mature enough point

…really see start to release it without flag or pre-fixing

…we are mature enough at that point

…I do see from our side, how do we align; what mobile plan

…in terms of support

…things we are currently working on

…from the future

…one of things we are looking at

…is to enable some of the @ scenarios

…that is one thing to look at for a plug-in free web

…investigating how do we enable that

…from programming model, high level API

…means that we let the OS manage the devices and have UA abstract those devices

…create that middle layer responsible to be managed by the OS

…have it abstracted; whether keys or certificates

…not saying high-level abstraction from WebCrypto API

…but certainly would not want it going into details of managing the devices

…delicate role of UA, OS and role of end user

…we see in some of our discussions the end-user playing a role

…see a relaxing of restrictions for usage of their @ or keys

…how simple can we make it

…so the end user really understands what they are doing; friendly names, usage patterns

…Those are some things to be addressed; and from browser side

…pass to VJ to talk about platform side

VJB: I am in violent agreement with what Dirk and Richard said

…sounds like we are struggling with low-level and high-level

…the way I think about it

…suppose I could wave the magic wand and give you both low and highlevel

…what would you want?

…I would want the highest level possible

<virginie> note to attendees : vgb is from Microsoft too, regular participant to web crypto WG

…I would prefer approach high-level approach

…and like others have said

…somewhere along the way we will reach some understanding of how much legacy needs to be supported vs how much to sacrifice

…having been in the Web Crypto discussions, there is a lot of infrastructure

…at least some of it will need to migrate in a diff form in cloud

…to support

scribe: open

…I'm in favor of starting with the more abstract and then reaching into the finer details as needed

Phil: In terms of doing the new things

…if the main goal is to get rid of passwords, let's not understand the policies out there

…reasons of why certain design choices were made that don't support the protocol but still being a good authenticator

…need to leverage some of those communities; need to do the use case analysis

…some may have a five-year lifetime; a bit difficult to throw away

Colin: I wanted to touch upon the privacy issues brought up by a prior speaker

…Google, MS, Mozilla, have different privacy policies

…curious in talking about the Web Crypto, and maybe it's a bit out of scope

…curious if in context of Web Crypto discussions, someone talked about privacy

…are there aspects of the discussions we can have here today

…that could be baked into some of the protocol level things

…within context of discussions here today and your browser developments

…I know that's a general question

…but it's a question for you, ok?

Brian: thinking about things like anonymous credential technology

…and anonymous attestation, there are cryptographic technologies that allow you to do @

…systems being deployed in trials

…in EU and US

…this group could choose to take that work on

scribe: whether that is appropriate now or later, that is something we can discuss

…If we should implement, that is question I am also asking

…if between tokens, that is a separate story; we could learn from TKM space

…W3C has long history in this space

…Wendy is hiding

…a colleague is co-author of P3P spec; advise us to keep policy aspect out of it

Colin: part of my question is to see if there are things the three of you could collaborate on

…is that a possibility?

Brian: those specs are under OSP; those specs are available

…no one excepts gov'ts want to do it

…I wish more folks would use anonymous technology

<wseltzer> +1 to that wish

…not for blockage issue; just have not seen uptake

<JeffH_> https://research.microsoft.com/en-us/projects/u-prove/

…users willing to sell privacy at a discount

…not sure if that is something this group wants to take on

Dirk: I'll take a slightly different point of view

…within realm of question

…we have been calling access control

…have something on card; identifies me, maybe tax ID

…question is who gets access to that stuff

…that is the privacy issue

<harry> notes open-ended question time is over, we are going to move to chartering phase now

…and Brad speaks out

scribe: he is worried that these things will leak all over the web and break the web as we know it

…I think we agree that some reasonable access control mechanism is needed

…but the detail of what it should look like

…make the key, don't use the key

…there are other mechanisms

…the question to tackle around the box model

scribe: and abstract notion of the box

…what is the more concrete something in the middle that we can all agree upon

…and I have not heard anything over last two days that we can agree upon

Richard: not first time we are exposing something to the web

…it's not baked into spec

…we make permissions for the API

…give some guidance for the nature of the permissions being presented

…whatever identifiers

<siva> +1 for richard

…whatever is simplest

…and what is exposed for origin

scribe: general principle, when possible, that is the simplest model

…anything else requires user access model

Bruno: How is it different

…in web to access, to ask user

…versus web site or geolocation to access these credentials

…let the user get the choice

…to be in the private mode or in the mode where he can expose his identity

…my second question

Richard: that is what I was meaning to say

…we can take a lot of what we have learned about expressing sensitive things

…and apply that

…we'll have to choose

…like web cams

…this is identity I want to present

…there are lessons to be learned

Bruno: I have questions for Dirk

…how is eID compatible?

scribe: and the German ID card

Dirk: what I meant by that is who gets access to the stuff on the card

…answer is whoever put the info onto the card gets access

…If I understand the German system, you can issue certificates

…and then have access to more or less info than what is on the car

d

…more powerful system but different to what is on the web

Sam, Google: eID and BSI

…we talked to them quite a bit

…we talked about authentication stuff

…very basic high level notion

…you have anonymous ID.....

…it's hard for user

…you need a smart card reader to plug in

…we have gone to other extreme

…if you attach a device to a web site

…and you can reverify the same device later

…we have been talking to them continuously

…and the arguments for it

…if these protocols take off

…there might be a card that you could use as an anonymous consumer or gov't ID

…have to have minimum notion; but it does not do that

…we do keep talking with EID all the time

Dirk: First part of your question, what is wrong with asking the user

…moderate the access to the card is better way to say

…that might be reasonable

…but reminds me of the UI we have in TLS client, PCKS11

…which was not a screaming success

…how do you explain to the user that they are about to give up their identity to another web site that they have not pre-existing relationship with

…it's far from a resolved question to ask user to say yes or no

Brad: what if it's an iFrame

…how does user know

<wseltzer> embedded contexts

…these prompts makes it difficult to user to understand

israelh: contexts are challenging

…site was not able to achieve what it was trying to communicate to the user

scribe: we hvea a responsibility to make things clear; but there is some context needed

Siva: if we could start from scratch and make smart cards smarter

…and use FIDO

scribe: and give them out to 8 million users

…it's really not the hardware vendors who will decide; let's make them and give it away

…it's who is willing to spend the money

…if we can make the current world work with the web that is ideal

<wseltzer> siva: Who is willing to buy and distribute

…if you want to start and scratch, tell me how that will work

Dirk: starting from scratch is one way of putting it

<bhill2> if you build it, they will come

…another way to look at it is where to begin with something new; what is the next step

Detlef: I would like to comment on the same issue

<bhill2> at the rate retailers are getting breached, we'll have to replace 8 billion credit cards by the middle of next year anyway

…I think the development with respect to browsers is different from development from large trust infrastructures and deployed smart cards for example

…you cannot change today and ship in next four weeks

…the lifecycles are considerably longer

…it's not possible to disregard legacy

…what you create today will be legacy in a few years

…if we introduce something today which is not supposed to break something, it needs to address the legacy

…we need to look back a little bit and be flexible enough to look into the future and allow the next migration schedule

Richard: Is HTTP legacy?

<bhill2> things move fast - my business cards are older than all of my credit cards

…it's right level of abstraction to meet additional use cases

…but not a conceptual reimaging

…perhaps we can hit

…but hard to hit that sweet spot

…not impossible to hit the new things that will last and be achievable

Brian: They are not legacy, it's the current technology we deploy every day

…how many German ID cards get issued every day

<siva> Or how many EMV cards!!!! In the billions!

…saying our procedures are all legacy before we deliver them…we live with technology you deploy for a long time

…that is fine

…I'll be upset if my old USB memory stick that's 256 MB stops working

…we'll use the cryptographic tokens we have because we still value them

…different from webcams

<siva> +1 for Brian

…keys have value

…if you give access to web site that shouldn't

…if web cam, sees my messy desk

scribe: but if it has value, I care about that and have to be more careful

…probably why pop-up dialogues have not worked

…the .Net framework ten years ago

…there is security policy in place and either you do it or not

<Detlef> +q

…there was no dynamic user invovelment

…tossed out the dancing hippos

…this is a hard problem

…cryptographic material that has value

Phil: Based on what I see and hear in the room, we have to think about all the parties' willing ness to work on this

…don't be too scare…interfacing on various tokens

…we are willing to bring that to the party

…to Brad's concern, we are not exposing them, they are already out there

<vgb> @Detlef: I don't think we are or should be talking about "kill the bad legacy stuff". Instead we're saying - we have a legacy world which supports things that can be risky on the open web. Can we identify the least risky things in that set, quantify and mitigate the risk, and agree to make progress on those things one by one?

…guys building those stacks are not at all versed in this

…you put out the ID, you got his ID

…concept that something is being put out in the open; we are already doing that

…need a better way, or at least common way, and not kick the can down the road

<siva> +1 for Phil

.Harry: any final responses

…good final Q&A

Harry: I was trying to explain

…if you are new to W3C

Wendy: thank you panel

Harry: At W3C what typically happens

…is we host a workshop and enough of our members say we should do something in a space for standardizations

…if workshop is clear we move to standards track

…if incoherent, we often move to a community group

…show of hands……

…for yes we can standardize?

[show of hands - quite a few]

…in the workshop we try to figure out

…what it is we should standardize; what is the consensus

…we had a big workshop a few years ago in Mountain View about identity in the browser

…and we discovered we needed an API for crypto functions in the browser

…that was a total surprise, but it ended up working out

…in this exercise we are going to do that

…show of hands

…and after this workshop is over

…we could probably use the web payments IG

…we often set up an existing or set up a new mailing list

…to help in the chartering process

…we're going to show off what some of these things look like

…then we'll get to the chartering bit

…when we start a working group, here is web crypto WG

…we want to get to a high-level common understanding for a charter

Wendy: W3C processes and procedures

…an advisory committee member approves charters for W3C to do new work

…that is important to companies and their lawyers and the IP commitments that you are asked to make

…RF IP is important aspect of W3C standards

…as a member you make an RF commitment for relevant patents on the work

…so we need to put the scope of work into a charter

…and before we put the charter to the membership, we try to figure out what goes into the charter

…Working Groups produce recommendations

…Interest Groups do requirements and use cases

…we also have Business Groups

…Here is the Web Crypto WG

…we have WebApps, SysApps and other groups to which we can send work

…and we just sent out today to the W3C membership the Web Payments Interest Group charter

…if approved, we'll look at the payments on the web challenges

…perhaps some of this work, and synergy between the questions we are discussing here and the payments focus

…looking at secure authentication

…other modes of work, we can do liaisons with other groups doing work

…we also sometimes bring in work through member submissions

<virginie> example of IG for payment : http://www.w3.org/2014/04/payments/webpayments_charter.html

…if you have work that you believe is a good start for API work, a member or group of members can submit to W3C with the recommendation to start from here to get something moving

…We had that situation with Open Social

…we took that and moved it into a Social WG

Harry: I'll give a few exmaples

…if you are a W3C member, you can submit work

<JeffH_> the webpaymentws IG is not a good example of a healthy functional IG

…here is the Open Social member submission

….If you are a W3C member, we can show you how to do it

<wseltzer> "We're from the web, and we're here to help."

…At end of this workshop, we will submit a report that will likely look like this

…here is the messy white board from that workshop

…it's a pretty good technique

<virginie> example of identity workshop result http://www.w3.org/2011/identity-ws/report.html

…This is web payments workhops; call for participation will be out shortly

…here is the W3C home page

…and here is what a charter looks like

…Charter tells us who the chair is, Virginie in case of the Web Crypto WG

…everything is basically public; we have schedule, team support, scope, what we are delivering, and a timeine

…and related people we should talk to

…It will take some time

…somewhere between one and six months

…try to get some understanding in the next 40 minutes

…I am going to write some things I have heard…actually Wendy can you write?

…what levels of abstraction; the 'box' problem; what kind, where do we want it

…a call for a simple developer facing API

MikeJones: Can you explain?

Harry: UAF, what Dirk showed is not based on low-level, but pretty high level

…FIDO U2F

…different levels of maturity, not quite RF

…a fairly high level of abstraction

…you can imagine that could be useful

…and you would like WebCrypto as it exists today to extend it

…heard we would like…algorithm discovery

…key discovery, we kind of do

…Mike brought it up

…key discovery spec

…we might want a key discovery; keys are also on devices, which brings us to device discovery

…keys if you are calling

…what other things do you think people think

…BigNum

…certificate metadata; that is clear

…way to access metadata

…anything else that is clear that you can imagine us standardize

Charles: key storage

Harry: persistence outside of

@: keys…[not hearing]

<JeffH_> GimmeSomeOfDemKeys()

Martin: some kind of separation between web site owned keys

…and every kind of device or existing smart card device where user has different keys

<israelh> +1

Dirk: A way to fold in origins into the signature that the key producers that is not under the control of the application

…add context by user agent

Harry: or an example

Siva: I think it would be useful to have a Litmus test, once we define charter, what kind of use cases should it support in an ideal world

…is it simple manner of identification

…meaning for payment applications like what Apple has done

…would it apply to web

…some test use cases we can list that we can ideally support

…amount of work we do to make that happen depends upon how exhaustive the list is

KarenLu: I am going to mention an obvious point

…in current Web crypto charter, the hardware token is out of scope

…so we need to make this explicit

Dirk: a way to say that usage of key should be tied to local auth gesture

Philip: Why or is that optional?

…I understand the request, but I think this should be an option

Dirk: yes, we are putting up what options we would like to see

Wendy: Scope sets limit of things we can consider

…none is deemed madatory to use

Detlef: should be aligned to access control model, might be extension of current model

…such that it's possible to control which web app sees which tokens

<engelke> +1 use something like CORS model for key access

…@ maybe too restrictive and CORS might not be sufficient

Juan: certificate metadata

…provenance, attestation

Harry: Are we missing anything that is really big that we may want to standardize

Colin: anonymous credential tech discussion; different aspects of payments; hardware tokens

…I'm going to throw out an interest of mine

…peer to peer distributed or payment technology

Harry: anyone else

Davit: I think this might be too detailed, but the ability to generate specially crafted

…current web crypto defines sign function

…which generates

….ability to generate some specially crafted signatures would be nice to have

…we have call it attested signature

Peter: I would suggest

…since one of goals is to bring hardware tokens in scope, that we identify some of them explicitly

…there should be a work item to go maintain a list so we know what we are working against

…a list

…if TE people want to propose stuff

Detlef: would need to be a temporary list

…strongly recommend a mechanism that would support arbitrary tokens

Siva; Maybe representatiion

Peter; current hints of what people want to be looking at

KarenLu: Origines

s/origins

Sean: If we are talking hardware tokens, we are talking middleware as part of the box

…does deployment come into this? How can I deploy middleware?

Harry: middleware is out of scope

@: should be some guidelines or best practices regarding middleware

Harry: Guidelines are fine

Natasha: Interaction with other standards bodies that have interaction with the lower stuff?

Harry: We will have a list of liaisons

…groups will get notified

…anything else?

…goal is not to make list bigger but smaller; but really look at what's missing; what could be standardized from a tech level

…Next do some hand showing

….W3C has an open, multi-stakeholder process

…if you would like to see this happen and don't have cycles to contribute, don't raise your hand

<rbarnes> https://en.wikipedia.org/wiki/Occupy_movement_hand_signals

…we'll do that round first

<virginie> gym exercice for all ....

scribe: the we will reflect on the results of that

…we'll keep the work items out of this phase

…There are two distinct kinds of APIs; high vs low level

…let's do high level first

…Simple, two-factor API

<solar> especially apt: http://www.ibiblio.org/hhalpin/harry-small.jpg

…around an authenticator; do people like that idea?

…no one likes that idea?

…use U2F as an example; higher level traction

…is that what people think we should standardize next

Colin: what is the alternative

israelh: Does not imply we would take concepts

…similar to web crypto and support those?

Harry: We'll go to web crypto next; we are asking higher level first

Dirk: trying to understand question

…are we trying to understand API for two factor systems and nothing else?

Harry: not nec nothing else, but do we want a higher level abstraction web crypto API

…low level is generate, retrieve keys

…make a simple API

…you could fill with right level bits

<virginie> explanation : if you raise your hands, basically, it means you are ready to give effort/workload/contribution to that topic

@: These words are red herring

…many people in this room have been saying it makes sense to have a higher level API

…next step i show to stage it

…ask a question about…authentication in that space

…that might be a better question to ask than U2F which is very narrow question to ask

Harry: How many people we should have a higher level API, higher than the current web crypto spec?

…let me count, and keep hands up

<virginie> question :is authentication a high level api ?

[Harry counts]

Harry: this is a very high level PI

[about 14]

<israelh> +1

…Now we'll go down to the lower level and particular features in order, which are completely arbitrary

….Discovery

[hands: 14]

…Key Discovery

<israelh> -1 on the high level PI and +1 on discovery

[hands: 25+]

…really popular

…somewhat vaguely stated

…Device Discovery

Harry: right now you cannot discover keys at all

Siva: there may be several devices with multiple keys that need to be discovered

Harry: I know it's a bit fuzzy

…maybe generate a key; crypto function on device; a bit different from key discovery

[hands: 10]

<colin_g> how about tiny numbers

Harry: Certificate metadata
... having some of that baked into API

[jhands: 8]

Harry: putting hardware tokesn from out of scope into the charter

[30+]

…Attestation of provenance

[hands: 20]

…Discovery mechanism..with poss extension of CORS

[hands: ]

…Persistent key storage

[hands: 12]

…User owned keys separate from origin owned keys

[hands: 14]

…multi-origin support in some large sense

[hands: 16+]

…System key discovery…operating level system keys not necessarily in hardware token

[hands: @]

…Origins of signatures

[hands: 13]

<vkata> Bake in context information into signatures, such as origin

…Local user authentication gesture; binding with key usage

[hands: 27]

…Anonymous credntials

[hands: 8-9]

…We'll need to take a break shortly and then discuss the results of these polls

…Seems like there is moderate support

…and high support in green

…most popular is putting hardware tokens in scope

…that's a no-brainer

Mike: Make a clarifying comment

…point out that you cannot do that without key discovery on the hardware tokens

Philip: and you cannot do that without device discovery

Harry: getting a feeling for directions

…some feeling that CORS and device, key discovery are related and popular

…and having that bound to signatures is popular

…and attestation

…also popular

…then a bunch of things that are semi-popular

…High-level API; algorithm discovery

…BigNum....well

…put up for debate

…multi-origin support is moderately popular

…access control model

…variation of signature context; subtext

…moderately popular

…11 and above

…I would say that what we might want to do

…I don't want to end here, but take a break soon

…we should discuss these things in some detail

…The low-level is a no-brainer, even though there are details here

…Ask if there are any real objections, or clarifying comments

Mike: the local authentication gesture, in order to enable the use of the key

…is not something that there is an APi for at all; platform functionality, so may not be in scope

bhill2: be comfortable with verification

Detlef: I don't agree

…if we understand verification of a concept, there may be more complexitiy

…local user authentication; maybe a PIN or biometrics is just one part of a more sophisticated protocol

…we should understand authentication as a generic concept

…then user authentication is one special case

…if we understand authentication generically

Juan: gain access to key, seems in scope …for a trusted key entry

@: need a pass

…allow interactions by UA

…we don't expect those

Juan: yes, but we do give guidance

<virginie> reminder to people talking : give your name for the scribe :)

…as to what is appropriate and inappropriate

juan: So would be optional…what is supported?

…seems to be a distinction

…what user authentication should take

<virginie> oups... s/@/israel

israelh: My point is if you say user interaction

Israel: That is not an API like what Mike was saying earlier

…implying leakage of info into the web page

Dirk: I am not saying a call to the API to enter fingerprint

…when you create a key…hey browser make me a key

<rbarnes> point of order: it is not appropriate to discuss charter text today. there is not any consensus on the problem to be solved.

…then you use the key the call to use that key is like call that does not require the user gesture

<engelke> +1 Dirk

…does that make sense?

…answer is yes and no

…same sign call

…but say that particular to sign something and it triggers something

Harry: we have a lot of hands up

…quick question

…we will close queue now

…Colin, Detlef and KarenLu

…then take a coffee break

…how many people want to stay for the chartering process?

…If you don't want to stay, you are free to go

…we'll use a mailing list

…to continue to discuss and clarify after the break

Siva: Who is on the mailing list?

…is it the WG?

<virginie> discussion can happen on the web security IG here : http://lists.w3.org/Archives/Public/public-web-security/

Harry: Everyone will get an email with the name of the WG mailing list and you can join the list

ColinG: clarification to add

…I wanted to suggest on BigNum that we add some points of clarification

…one the discussion of anonymous credentials that you had suggested

…and another one may be the effects of metadata within context of metadata

Detlef: I would like ask Dirk

…to clarify this issue

…if you generate a key, will certain access control conditions

…a question of policy

…is it being treated generically

<public_screen> We'll notify the attendees list where discussions of chartering will occur.

…it's very easy

…standardized in ISO 17860

Dirk: I don't like the words "arbitralily complex"

KarenLu: question related to level of assurance

Harry: let's return in 15-20 minutes

Note: the show of hand result is now captured under https://www.w3.org/Security/wiki/IG/webcryptonext_workshop

harry: there will be further discussion on the mailing list http://lists.w3.org/Archives/Public/public-web-security/

<colin_g> yay

harry: the discussion of the charter will be done here, and anyone can join

wseltzer: we have your email address, but just in case, if you have any doubt, please send it to harry and/or wselter

harry: we should clarify what people means with respect to technical feature
... queue is open to questions

please note that the show of hand has been captured on the wiki https://www.w3.org/Security/wiki/IG/webcryptonext_workshop

harry: we need to clarify some of the features

wseltzer: there will be a mail follow up, please read the minutes
... and we will have a review of the charter, for the next level of details
... eg what does it mean to have hardware token in scope ? what precise definition, what we can do with hardware token ?
... what we mean by discovery ....
... what sort of permission request to we need to get their agreeemnt, how do expose this to user/browser/services
... are there any holes missing ?
... are there any question we missed ?
... any process of W3C quetsion ?

adrianC: to karen, if we want to bring back hardware token in the discussion, a starting point is the secure element api on github
... ... is that any other WG discussin it ?

KarenLu: it was discussed in sysapp wg, but it is unlikely they will follow up on it

adrianC: can we take it in there ?

KarenLu: i think it is prbably a low level API, but it could be a separate WG

siva: if we extend the access to se to be a box, we @@

harry: patent commitment are hard
... we dont like strtaing WG unless really necessary

<wseltzer> ACTION: wseltzer to review SysApps Secure Element discussion

<trackbot> Created ACTION-147 - Review sysapps secure element discussion [on Wendy Seltzer - due 2014-09-18].

<colin_g> Radiation

harry: we need to know why it died into sysapp wg, because it is bad design, badly writtent, an not be understood

<colin_g> Radiation will not cure app issues

harry: moving a feature from one wg to another may not be a good practise

bhill2: reminds that it is not a W3C secure api , it is a proporietray contribution
... and it is noot related to how the web work

axel: wg contributors told me that there is an API that arbitraty javascript shouod access to

<wseltzer> s/SysApps secure element/unoficcial secure element/

axel: on the other hand, mozilla FF will implement it, binded with NFC use case
... the impelmentation will be very similar to what gemalto has proposed in their API

<wseltzer> s/implementation/implementation in FirefoxOS/

axel: maybe it is not a good idea to expose it, but we should standardize smthg to avoid fragmented impelmentation
... it does not have to be in web crypto, but it has to exist

siva, : assuming this becomes a defined working group, it has to get built somewhere, in W3C, or somewhere else

siva: we see that hardware token is in scope
... W3C could decide it will be design here, or elsewhere

adrianC: question for bhill2, as vendor I am talking as having deployed stuff, and we are ready to standardize something, and give it to the web industry
... abd after we will see what the web industry will do it
... or we will have 20 impelmentations, and we will see if it is ok

bhill2: if it falls into the scope, i'll bring my ideas here

french scribe needs help....

martin: practical question , what are the next steps to progress ?
... from a organization point of view, there are a lots of dependency, so how do we proceed to manage the overlapping area
... we have a lots of plugins, and we would like to know when we will have to upgrade it
... we have right now resosurces that are spent to that, and we need to speed up the process
... what are the next steps ?

<bhill2> https://github.com/opoto/secure-element/issues/5

wseltzer: we have to work on forming consensus, iterating on the draft, call for impelmentation, do testing, making sure there independant implementations

<bhill2> this is a bug I opened against the spec in April

<bhill2> it was closed without really fixing it

wseltzer: our aim is to have a process that move quickly through those steps
... our goal is to draft a charter proposal in the next month or 6 weeks for discusson

wselzer: the next web crypto wg will be during the TPAC week on the 30th of oct

<harry> http://www.w3.org/2014/11/TPAC/

<harry> Note that you have to register

wselzer: the next web crypto wg will be during the TPAC week on the 30th of oct

detail about the TPAC weel http://www.w3.org/2014/11/TPAC/

harry: you need to register to TPAC, it is santa clara
... if you are W3C member, you register, if you are not W3C member, you can join as observer if the chair virginie galindo permits it

martin: me, as a non member I will be registring, what else can I do ?

wseltzer: the wg gets down to discussing the proposed recommendations, and conversation is lead by members
... so your company has to be member
... but we do our work in public in open comment
... we need to make sure that all comments are taken into acocunt, but also that the contributions are made under the patent free intellectual property policy

<harry> http://www.w3.org/20/

<harry> Oct 29th is 25th anniversary of the Web with Tim Berners-Lee

<harry> (i.e. inventor of Web and W3C Director/Founder)

siva: what process for getting something like the access to se in W3C ?
... what do we need to do ?

wseltzer: it is appropriate to bring that for consensus discussion, to see if there is an interest, bring the draft as a basis for further work

wseltzer: if the consensus is that it is a good starting point, then the editor willl take it on and improve it

wselzer: an editor will make changes, ask the WG to endorse changes, see if security or permission are compatible with the web security model

wseltzer: an editor has a write mode on the specification draft, ierate until the WG is happy

siva: which group do u refer to ?

wseltzer: a formed wg, meaning, with a charter
... the aprticpants will have to make consensus to adopt it, and the director will endorse it, with the help of his team, and gathering the entire membership opinion

note: process geeks can enjoy : http://www.w3.org/2014/Process-20140801/

siva: how do we make sure we had feedback from bhill2 for example

bhill2: I opened some bugs into the github proposal

wseltzer ; I have the action to check also that

dirk: is someone proposing to add that spec into the list of feature ?

siva: it is not even chartered, so no

wseltzer: I heard suggestion that it was a way to implement the integration of hardware token in the wg deliverable

harry: when we created the web crypto api, we had a contribution by mozilla, and in the end, the web crypto api as of today does not look like the intial input
... recommends that we have a large number of contributions
... belives that it is very bad to get the rejected work from another wg

disrk: but it seems that we have a discussion to bridge the hardware token with the secure element api

<harry> we need a post-mortem

siva: if the secure element api does not fall into the charter
... then this work can be done elsewhere
... once we define a charter, how can we integrate this contribution by the industry ?

karenLu: i can explain what happened with the sysapp wg
... sysapp was for the mobile aspects, mobile app to access native feature of the device, like camera or gps
... smart card came as a second feature
... gemalto developped it, and mapped it with the SIMAlliance open mobile api

karenLu ; the secure element api is quite similar, it is mapped with the web technology

<public_screen> issues with Secure Element API draft: https://github.com/opoto/secure-element/issues

KarenLu: I am looking at crypto aspects, and I understand it may not fit with the web app model
... the hardware part is what is the right security model to access this feature
... wjat can we access, what can we trust, the sceurity model was one of the key discussion

colin: what is the issue 5 related to sceure element raised by bradhill ?

<bhill2> https://github.com/opoto/secure-element/issues/9

colin: (scribe gets lost by the american accent)
... @@

<bhill2> I don't know that going through all of the issues with Secure Element API proposal is appropriate for this time

<bhill2> you can use GitHub to reply to or comment on issues

wseltzer: we are not going to enter into the details

detlef: we need to leverage on rpior art and pieces which is already there eg. pcsc and iso standards
... lets do not re-invent the wheel agian
... the access control is something we need to elaborate, it is in the middle of the sophisticated things to bring to the web, that is part of the challenge

siva: if we take it of from W3C and come back, the objective is to make sure we can give it again to W3C, or not (it may not belong to W3c in the end)

<Peter_Cattaneo> +q

<bhill2> I did not mean to say it doesn't belong, only that it so far has no official standing, and there are some issues to address.

wseltzer: one of the things interetsing in Interest Group is to identify what we have to do, what is already existing, things that need to be done elsewhere
... W3C gathers people woith expertise around wen web architecture, web api...

<siva> bhill2 ah. got it.

wseltzer: if you need that web expertise, it is a great place
... we dont want to rebuild things in a inconsustent way, we have to make sure the seb security model stays consistent

peter: ... comment : when looking at specific hardware token it might help if there are some open source solutions

<colin_g> Open Source Smartcard Development Platform http://www.openscdp.org/

peter: there is a nice candidate in estonia, there are other projects, contribution from gemalto/oberthur/tyfone there are the bad apsects of being proprietaries
... i would be happy to work on open source scenario

<colin_g> Open Source Smartcards Canada http://www.smartcardscanada.com/software/open_source.htm

peter: if there is no place for the secure element, how will the discovery gonna work ? what will it connect to ?

bhills: i did not say that there should have any sceure lemeent api

bhill2: i dont object to it, it is just a company contribution
... and a manifest does not control where code can come from at runtime

to bhill2 : please check my wording, not sure i got it :)

herve_SIMAlliance ; the simalliance is nota standardization body

herve_simalliance: we are calling for implementation, we target to have it impelmented, we are open to look at the different possibilities

herve-simalliance: reference the open mobile api, or liaise, or we give you the specification, we dont intend to retain the specification

herve_simAlliance: there is no objection on the principle to share it with W3C, I just need to check with the board

herve_SIMAlllaince: W3C has been identified as an important partner

wseltzer: thank you, we captured a lots of text, picture, and we need now to analyze it
... we have enough to work on the boxes, on the authentication aspects

<colin_g> massive plug for my paper http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_12.txt and personal project page http://abis.io :-)

<public_screen> virginie: Thank you all

<public_screen> ... we've learned a lot, on past challenges and future paths for progress

<public_screen> ... please continue the conversations, join us in working toward consensus

<public_screen> [adjourned. See you online.]

<martin_paljak> was fun!

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/Savi/Siva/
Succeeded: s/liability or/liability rules or/
Succeeded: s/indepent/independent/
Succeeded: s/brfeak/break/
Succeeded: i/New Security Features/scribenick: wseltzer
Succeeded: s/mkieJones/mikeJones/
Succeeded: s/card/vault/
WARNING: Bad s/// command: s/Scibe: Karen
Succeeded: s/Scibe: Karen/Scribenick: Karen/
Succeeded: s/voting/thinking/
Succeeded: s/do keys/do keys, origin-bound/
Succeeded: i/Etherpad/scribenick: wseltzer
Succeeded: i/Scibe/scribenick: Karen
Succeeded: s/a secure browser/a secure channel between the browser/
Succeeded: s/Peter/Phil/
Succeeded: s/@ card/smartcard/
Succeeded: s/Hypocratic/Hippocratic/
Succeeded: s/open questions/legacy devices/
Succeeded: s/maturing/mature enough/
Succeeded: s/web ID/eID/
Succeeded: s/we have/we have in TLS client, PCKS11/
Succeeded: s/@/israelh/
Succeeded: s/dot/.Net/
Succeeded: s/access/crypto functions in the browser/
Succeeded: s/@/MikeJohns/
Succeeded: s/UTF/U2F/
Succeeded: s/MikeJohns/MikeJones/
WARNING: Bad s/// command: s/origins
Succeeded: s/@/israelh/
Succeeded: s/13/14/
Succeeded: s/@/Philip/
Succeeded: s/@/bhill2/
Succeeded: s/@/juan/
Succeeded: s/@/israelh/
Found ScribeNick: KarenOD
Found ScribeNick: wseltzer
Found ScribeNick: bhill2
Found ScribeNick: wseltzer
Found ScribeNick: Karen
Inferring Scribes: KarenOD, wseltzer, bhill2, Karen
Scribes: KarenOD, wseltzer, bhill2, Karen
ScribeNicks: KarenOD, wseltzer, bhill2, Karen

WARNING: No "Present: ... " found!
Possibly Present: AdrianC Anders Anders_R Axel AxelNennker Brad Brian Bruno Cathy Chairs Charles ChrisW ColinG Davit Detlef Dirk Fab Giri_Mandyam Hadi HadiNahari Hannes HannesTschofenig Harry Harve Herve_SIMalliance Ilhan_Gurel Israel Israel_Hilerio Israeth JeffH JeffH_ John Jonas_Andersson Karen KarenLu KarenOD Karen_ Kathy Martin Martin_ Mike MikeJones Mike_Jones Mohamad NAtasha NHadiNahari Nadalin Nadalin_ Natsha Peter Peter_Cattaneo Phil Phil_Hoyer Philip Richard RobP Rob_philpott Scibe Sean Siva Ullrich VJB Wendy adam adam_ ale bal basically bfar bhill2 brunojav brunojav_ colin colin_g crypto davitb dirk_balfanz drogersuk engelke gentilkiwi giridhar gmandyam https ilhan ilhangurel inserted israelh joined jonas juan juan_lang keiji klc lifewsky martin_paljak mdwood mdwood_ monzillo nvdbleek pea_ public_screen rbarnes richard_barnes sangrae schuki scribenick selfissued shadow solar tarcieri trackbot vgb virginie vkata vladimir 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/
Found Date: 11 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/11-crypto-minutes.html
People with action items: