00:12:54 <Karen> Karen has joined #crypto
00:19:16 <Karen> Karen has joined #crypto
00:22:25 <Karen_> Karen_ has joined #crypto
00:28:46 <harry> harry has joined #crypto
00:46:31 <vkata> vkata has joined #crypto
00:52:58 <Karen> Karen has joined #crypto
00:53:12 <adam_> adam_ has joined #crypto
00:56:34 <wseltzer> [adjourned]
00:56:42 <wseltzer> rrsagent, draft minutes
00:56:42 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html wseltzer
00:57:26 <wseltzer> thanks to our hosts, sponsors, speakers, moderators, scribes, participants! See you tomorrow.
00:57:31 <wseltzer> trackbot, end teleconf
00:57:31 <trackbot> Zakim, list attendees
00:57:31 <Zakim> sorry, trackbot, I don't know what conference this is
00:57:39 <trackbot> RRSAgent, please draft minutes
00:57:39 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html trackbot
00:57:40 <trackbot> RRSAgent, bye
00:57:40 <RRSAgent> I see no action items
14:58:22 <RRSAgent> RRSAgent has joined #crypto
14:58:22 <RRSAgent> logging to http://www.w3.org/2014/09/11-crypto-irc
14:58:24 <trackbot> RRSAgent, make logs public
14:58:24 <Zakim> Zakim has joined #crypto
14:58:26 <trackbot> Zakim, this will be CRYPT
14:58:26 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:58:27 <trackbot> Meeting: Web Cryptography Working Group Teleconference
14:58:27 <trackbot> Date: 11 September 2014
14:58:58 <public_screen> s/Meeting: Web Cryptography Working Group Teleconference/Meeting: Web Cryptography Next Steps Workshop/
14:59:06 <public_screen> Chairs: Virginie_Galindo, Harry Halpin
14:59:22 <public_screen> Agenda: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/
15:03:09 <nvdbleek> nvdbleek has joined #crypto
15:04:13 <Cathy> Cathy has joined #crypto
15:08:18 <ilhangurel> ilhangurel has joined #crypto
15:09:39 <adam_> adam_ has joined #crypto
15:15:25 <Herve_SIMalliance> Herve_SIMalliance has joined #crypto
15:23:46 <harry> harry has joined #crypto
15:26:45 <solar> solar has joined #crypto
15:34:03 <nvdbleek> nvdbleek has joined #crypto
15:37:54 <martin_paljak> is there a list of participants somewhere ?
15:39:18 <Ullrich> Ullrich has joined #crypto
15:39:43 <brunojav> brunojav has joined #crypto
15:46:18 <bhill2> bhill2 has joined #crypto
15:47:07 <Peter_Cattaneo> Peter_Cattaneo has joined #crypto
15:47:12 <wseltzer> Topic: Welcome, day 2
15:47:17 <Phil_Hoyer> Phil_Hoyer has joined #crypto
15:47:30 <wseltzer> Virginie: Thanks to our sponsors for a good dinner
15:47:41 <wseltzer> ... Note that draft minutes are now linked from the agenda page
15:47:55 <HadiNahari> HadiNahari has joined #crypto
15:47:58 <wseltzer> ... Overview of agenda: http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/#schedule
15:48:58 <karenlu> karenlu has joined #crypto
15:49:01 <wseltzer> ... Afternoon objective: what do we need to do in the next two years, and how will we do it?
15:49:24 <wseltzer> ... e.g. rechartering existing WebCrypto group or chartering new group
15:49:40 <engelke> engelke has joined #crypto
15:50:28 <KarenOD> KarenOD has joined #crypto
15:50:28 <wseltzer> Topic: Hardware Tokens
15:50:56 <KarenOD> ok
15:50:56 <vkata> vkata has joined #crypto
15:51:04 <AdrianC> AdrianC has joined #crypto
15:51:12 <wseltzer> scribenick: KarenOD
15:51:15 <KarenOD> * "want" is a strong word...
15:51:20 <bal> bal has joined #crypto
15:51:34 <wseltzer> Why W3C needs to Remain Neutral and Endorse ‘Brand-free’ Hardware Security by Siva Narendra (Tyfone)
15:51:37 <KarenOD> Savi: Why W3C needs to remain neutral
15:51:48 <wseltzer> s/Savi/Siva/
15:52:17 <JeffH> JeffH has joined #crypto
15:52:38 <KarenOD> ... security about more than multifactor, about decentralizing ID vaidation and key storage
15:54:19 <juan_lang> juan_lang has joined #crypto
15:54:19 <KarenOD> ... smart card chips: proven, scalable, low cost, form factor agnostic, lots of money spent on infrastructure and certification
15:56:48 <virginie> virginie has joined #crypto
15:56:58 <KarenOD> ... Myths include smart card chips are old, are proprietary (web browser interfaces to smart card are and that needs to be fixed)
15:57:43 <ChrisW> ChrisW has joined #crypto
15:58:03 <KarenOD> ... already a functioning solution in use
15:58:37 <martin_paljak> +1 for using OpenSC ;)
15:59:40 <KarenOD> ... solution works on both mac and pc (see Siva for demo)
16:00:00 <Rob_philpott> Rob_philpott has joined #crypto
16:00:47 <KarenOD> ... list of benefits to both the smart card industry and the entire community
16:01:00 <Karen> Karen has joined #crypto
16:01:49 <KarenOD> Herve Sibert: GlobalPlatform technology for the web
16:02:16 <nvdbleek> nvdbleek has joined #crypto
16:02:25 <KarenOD> ... GlobalPlatform is the standard for managing applications on secure chip technology
16:03:37 <KarenOD> ... one of the main focuses is mobile
16:04:22 <colin_g> colin_g has joined #crypto
16:04:28 <colin_g> hi
16:04:54 <Anders_R> Anders_R has joined #crypto
16:05:12 <KarenOD> ... architecture description (see diagram on slides)
16:05:45 <KarenOD> ... coverage by GlobalPlatform specifications
16:07:17 <KarenOD> ... interface to GlobalPlatform technologies (TEE, SE) - open mobile API by simalliance
16:09:02 <lifewsky> lifewsky has joined #crypto
16:09:24 <KarenOD> ... proposal to W3C: consider transport and service layers from GP work
16:09:32 <gmandyam> gmandyam has joined #crypto
16:10:54 <KarenOD> ... identification of service levels of SE/TEE
16:11:51 <KarenOD> ... suggestions on how to work together (open-source group in GP or W3C group with GP members), liaisons to synchronize roadmaps
16:13:05 <KarenOD> Bruno Javary: Secure element access from the web browser
16:13:47 <Herve_SIMalliance> by writting, your accent is better !
16:14:23 <KarenOD> ... history of Oberthur Technologies  in this space
16:14:34 <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
16:14:51 <tarcieri> at least up for a yes/no vote anyway ;)
16:15:34 <virginie> to tarcieri : done ! :)
16:15:38 <tarcieri> thank you! :)
16:16:09 <KarenOD> ... position summary: enable access for every single user to trusted services, best candidate is the web browser
16:16:14 <virginie> note that anyone can edit the page, it is supposed to be collaborative, but I am happy to include suggestions
16:16:17 <JeffH> (http://opoto.github.io/secure­-element/) from the oberthur position paper 404s
16:16:38 <tarcieri> virginie: I can't log in :|
16:16:40 <KarenOD> ... topics to be considered: authentication, access to crypto operations, low level acces to secure element/hw token
16:17:14 <Ullrich> Ullrich has joined #crypto
16:17:21 <virginie> to tarcieri : oups, will check later access rights ...
16:17:27 <JeffH> are slide decks posted as yet?
16:17:58 <harry> we'll do that ASAP, but we're still missing a few :)
16:17:58 <KarenOD> ... ... middleware good for local use but not for online use
16:18:19 <virginie> to jeffH : wseltzer and harry will take care of it, action noted
16:18:57 <KarenOD> ... browser extension there but has issues
16:19:06 <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)
16:19:40 <Herve_SIMalliance> OMAPI has been already implemented in more than 200 Android NFC smartphones
16:19:47 <KarenOD> ... mobile APIs are proprietary, some promising technologies, middleware and web browser extensions don't work in mobile environment
16:20:53 <Herve_SIMalliance> OMAPI is IP free and royaltee free, a Open Source implementation is also available
16:21:09 <Herve_SIMalliance> Seek for Android
16:21:34 <KarenOD> ... 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
16:21:58 <colin_g> Possible background study reference info (Pew study) http://www.pewinternet.org/three-technology-revolutions/
16:22:19 <KarenOD> ... position: W3C standardization of JavaScript API for browser access to Smart Card
16:23:09 <nvdbleek> nvdbleek has joined #crypto
16:23:39 <KarenOD> ... secure element API: complete and well documented, solution combines validation by the user and specific access control mechanism
16:24:04 <Anders_R> The SE API doesn't have any links to WebCrypto
16:24:31 <KarenOD> ... action plan list (see slides)
16:25:21 <KarenOD> Natasha Rooney:
16:25:53 <KarenOD> ... GSMA is a global mobile association
16:26:16 <KarenOD> ... GSMA personal data program: mobile connect
16:26:34 <KarenOD> ... not something that we want to necessariy be standardized but we want it to be a supported use case
16:26:39 <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
16:27:06 <KarenOD> ... anonymous login, secondary authentication, validated login, identity validation, mobile signature, attribute brokerage
16:27:26 <KarenOD> ... want to make sure this is secure and respects user's privacy
16:27:33 <colin_g> also links to seek for android at https://github.com/opoto/secure-element
16:27:46 <colin_g> https://code.google.com/p/seek-for-android/
16:27:55 <pea_> pea_ has joined #crypto
16:27:56 <Fab> Fab has joined #crypto
16:28:36 <KarenOD> ... sim applet running on device uses SIM as a hardware token
16:29:36 <KarenOD> ... 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
16:30:01 <KarenOD> ... SIM disadvantages: applets needs to be preprovisioned, work ongoing to do over the air provisioning
16:31:06 <KarenOD> ... Future work: secure storage, secure processing, standardising cryptograph support on hardware tokens, assuring security prior to issueing a token
16:31:24 <pea_> what is the business model and who would the trusted party be in this model. The MNO?
16:31:40 <KarenOD> ... SIM is not the only solution, hw token is something that needs to be investigated,
16:31:41 <martin_paljak> it depends. with certificates it would be a CA
16:31:51 <KarenOD> ... we would like for users and developers to make use of this on the web
16:31:57 <martin_paljak> in US it would probably be the network, yeah...
16:32:13 <Herve_SIMalliance> I think so, MNO will be an ID provider
16:32:27 <KarenOD> Karen Lu: Enhancing Web Application Security with Secure Hardware Tokens
16:32:50 <mdwood> mdwood has joined #crypto
16:33:22 <KarenOD> ... secure hardware tokens have secure microprocessor, memory and crypto engine
16:33:28 <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.
16:33:59 <KarenOD> ... providing security in many domains
16:34:36 <KarenOD> ... no standard for using secure hardware tokens in web applications
16:35:05 <KarenOD> ... current proprietary solutions bridge the gap
16:35:21 <KarenOD> ... including authentication, signature, and encryption
16:35:33 <ale> ale has joined #crypto
16:37:43 <KarenOD> ... many proprietary non-interoperable solutions exist
16:38:00 <KarenOD> ... need a standard for how web applications communicate and use secure hardware tokens
16:38:37 <KarenOD> ... question is where do we build the bridge (three possible levels of APIs)
16:38:54 <KarenOD> ... low level for communication and basic access (APDUs)
16:39:45 <KarenOD> ... middle level API for crypto and secure storage
16:40:42 <KarenOD> ... high level API for security services (authentication, payment, token management)
16:41:42 <KarenOD> ... how to control access to the hw token
16:42:09 <ale> ale has joined #crypto
16:42:17 <KarenOD> ... user controls access or token control access
16:42:28 <KarenOD> ... leverage secure element API
16:42:44 <virginie> q?
16:42:49 <bhill2> q+
16:42:58 <AdrianC> Q+
16:43:10 <colin_g> :-)
16:43:21 <wseltzer> ack bhill2
16:43:23 <wseltzer> ack bhill
16:43:30 <HannesTschofenig> HannesTschofenig has joined #crypto
16:43:44 <KarenOD> Brad Hill: My understanding is the applications that go into these have to be approved by the gateway or the carrier
16:44:19 <KarenOD> ... don't have an open environment to choose the application that we want...
16:44:44 <Ullrich> GP has a discussion on "user centric" management of secure elements.
16:44:54 <martin_paljak> Ullrich: link ?
16:45:05 <KarenOD> ... not sure we gain much by developing a standard API that provides access to locked down services
16:45:19 <tarcieri> q+
16:45:26 <Peter_Cattaneo> q+
16:45:40 <KarenOD> Siva: your inference is correct, whoever takes control of owning the security would want to take control of who has access,
16:46:06 <KarenOD> ... identities will continue to be diverse, liabilities will continue to be diverse...
16:46:17 <KarenOD> ... difficult to converge them
16:46:52 <KarenOD> Natasha: mobile is just another option for an identity provider
16:46:53 <Ullrich> http://www.globalplatform.org/documents/Consumer_Centric_Model_White_PaperMar2012.pdf
16:47:08 <pea_> How does one get in teh list to ask a question or make a point.
16:48:00 <wseltzer> q+ pea
16:48:14 <KarenOD> 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
16:48:42 <JeffH> q?
16:48:42 <wseltzer> q+ hannes
16:48:44 <KarenOD> ... i don't see this as compelling for the W3C, you want the W3C to support a particular pay to play business model
16:48:47 <pea_> The question at hand is in an anonymious world who is the relying party willing to trust
16:49:27 <Rob_philpott> Rob_philpott has joined #crypto
16:50:03 <Herve_SIMalliance> q+
16:50:06 <KarenOD> KarenLu: there are different levels of services
16:50:27 <KarenOD> Brad: I should get to choose which bank and which health care provider I use and not Apple or Samsung
16:50:42 <adam_> q+
16:50:50 <martin_paljak> q+
16:51:08 <KarenOD> KarenLu: there will be more and more high value applications
16:51:30 <pea_> The other question who "controls" the container that the Cerdentials will be stored
16:51:39 <pea_> in
16:51:51 <Nadalin> Nadalin has joined #crypto
16:52:01 <KarenOD> ... another aspect of your question is access control, can put trust outside of secure trust element,
16:52:31 <KarenOD> ... two models (trusted operating system, FIDO model)
16:53:04 <pea_> First we must define the Business requirements then we can figure out the technology to address and serve that requirement
16:53:13 <KarenOD> Siva: point about walled garden is true, this is really a liability game, if you want control you get liability and deals get made,
16:53:37 <wseltzer> ack next
16:53:37 <virginie> q?
16:53:38 <Herve_SIMalliance> http://www.simalliance.org/en/handset/handset_marketing/
16:53:49 <KarenOD> ... not having common standards is actually perpetuating the walled garden problem
16:54:22 <KarenOD> AdrianC: do you think it would make sense to have a common way to exchange APDUs
16:54:42 <pea_> The other question is the portability of these credentails across the multiple machines we use to access the services we desire.
16:55:41 <KarenOD> Harve: We are at a point that it is possible to do what you are suggesting, some would really like the low layers
16:55:52 <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.
16:56:42 <KarenOD> Bruno: agree with you on the low level needs, and the fact that the time is right to do it
16:56:46 <RobP> RobP has joined #crypto
16:56:55 <nvdbleek> nvdbleek has joined #crypto
16:56:56 <Rob_philpott> Rob_philpott has left #crypto
16:57:25 <KarenOD> KarenLu: there has to be some way that we can make a compromise between the hardware community and the web developers
16:58:06 <mdwood_> mdwood_ has joined #crypto
16:58:07 <KarenOD> ... need candid discussions on advantages/disadvantages in W3C to discuss and choose which layers to work on
16:58:12 <wseltzer> ack next
16:59:05 <KarenOD> tarcieri: interested in case where you provision your own keys on devices, currently use GPG, would like to do that via a web browser
16:59:15 <KarenOD> ... how do you handle these types of provisioning questions
16:59:30 <KarenOD> ... how do you expose encryption to users
16:59:39 <keiji> keiji has joined #crypto
17:00:03 <martin_paljak> tarcieri: I think there's a gap between "user keys" vs "service keys". The FIDO thing is more about "service owned keys"
17:00:23 <Cathy> q+
17:01:03 <sangrae> sangrae has joined #crypto
17:01:13 <KarenOD> Siva: from a standardization perspective, can expose the encryption, abstraction layer needs to be there,
17:01:26 <Anders_R> Are there any concrete proposal on how to bridge security elements and WebCrypto?
17:02:00 <virginie> message to pea : who are u, raise your hand to gte the mic :)
17:02:02 <virginie> q?
17:02:26 <virginie> message to pea : thanks !
17:02:28 <KarenOD> Harve: there are different ways to consider the TEE, the market is not mature enough
17:02:29 <Martin_> Martin_ has joined #crypto
17:02:59 <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.
17:03:03 <bhill2> Businesses figure it out.
17:03:07 <Martin_> @Anders: http://opoto.github.io/secure-element/ - relatively low-level as far as I can tell
17:03:22 <RobP> RobP has left #crypto
17:03:23 <KarenOD> Bruno: we currently know how to use the secure token to address specific use cases,
17:03:40 <solar> lots of businesses use google authenticator for 2nd factor authentication. Google assumes no liability. it still works.
17:03:47 <Ullrich> Banks, for example , do have liability
17:04:04 <solar> SMS OTP - carriers don’t assume liability
17:04:05 <bhill2> The issue here is rent extraction by device manufacturers and mobile carriers from people who want to deliver applications to users
17:04:07 <solar> it works
17:04:08 <monzillo> monzillo has joined #crypto
17:04:31 <bhill2> +1 to solar
17:04:32 <pea_> Degrees of Trust create different levels of liability
17:04:42 <KarenOD> KarenLu: we have proprietary solutions for encryption,
17:04:57 <wseltzer> bhill2, it might be different ways of looking at the problem: assignment of rents through liability or fees
17:05:17 <wseltzer> s/liability or/liability rules or/
17:05:22 <Anders_R> @Martin: I don't see any links between http://opoto.github.io/secure-element/  and WebCrypto
17:05:42 <pea_> Exactly although rent may not be the right word.
17:06:08 <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.
17:06:12 <solar> extortion?
17:06:21 <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)
17:06:21 <colin_g> @Anders_R see https://github.com/opoto/secure-element
17:06:28 <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
17:06:43 <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
17:06:45 <KarenOD> KarenLu: we need to consider where to standardarize first
17:06:47 <bhill2> http://en.wikipedia.org/wiki/Rent-seeking
17:06:51 <wseltzer> ack next
17:06:56 <solar> yes, but they don’t assume financial responsibility
17:06:56 <pea_> Renting space to story credentials that establish trust is the challenge many business have with some of the models under the table
17:07:09 <colin_g> what about trust / trusted / centrralized, vs. trustless systems, js.
17:07:23 <tarcieri> martin_paljak: yeah, I was talking about something more like a PGP key where you want to publicize the public key
17:07:45 <AxelNennker> AxelNennker has joined #crypto
17:08:15 <AxelNennker> Mozilla is currently implementing a Secure Element API https://bugzilla.mozilla.org/show_bug.cgi?id=879861 #T-Labs
17:08:34 <KarenOD> 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
17:08:50 <KarenOD> Siva: box in the browser should be at as high a level as possible
17:09:00 <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
17:09:03 <HannesTschofenig> Axel, didn't Richard tell yesterday that Mozilla will get rid of these point solutions?
17:09:24 <KarenOD> ... if we can get that right, then we can work our way down through the other levels of abstraction
17:09:46 <HadiNahari> HadiNahari has joined #crypto
17:09:51 <KarenOD> ... need to keep the abstraction level higher initially
17:10:09 <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.
17:10:10 <Anders_R> Question: can end-to-end security be abstracted?  IMO it can't
17:10:32 <pea_> bhill2 agree there are transactions or events that have trust requirements that do not need the security of hardware.
17:10:40 <Anders_R> FIDO/U2F is defined to the bit-level.  for a reason
17:10:58 <bhill2> hannes, it doesn't matter how broad the markets are, it matters whether there is user choice and competition
17:11:11 <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.)
17:11:16 <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
17:11:24 <KarenOD> 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
17:11:34 <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
17:11:41 <martin_paljak> bhill2: that sucks, that for "most people" you don't have competition in terms of who you pay taxes to.
17:11:43 <pea_> We need a solution that supports different levels of trust
17:11:46 <Rob_Philpott> Rob_Philpott has joined #crypto
17:12:06 <dirk_balfanz> dirk_balfanz has joined #crypto
17:12:09 <KarenOD> Natasha: with my W3C hat, there are a number of high level APIs but also some very low level APIs
17:12:25 <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
17:12:32 <KarenOD> ... 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
17:12:33 <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.
17:12:45 <Detlef> Detlef has joined #crypto
17:12:52 <Detlef> +q
17:12:53 <KarenOD> Siva: there are clearly multiple layers, the question is who is responsible for the various layers
17:13:04 <KarenOD> ... the question is where do we start?
17:13:36 <KarenOD> Bruno: all the responsibility is not to the browser developers
17:14:46 <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
17:15:32 <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
17:15:37 <Anders_R> smart cards are used with multiple server providers, that departs from SOP.  How do you intend to bridge/cope with that?
17:15:51 <virginie> to hadinahari : can u make your point on the mic ?
17:16:07 <HadiNahari> virginie: yes
17:16:09 <HadiNahari> q+
17:16:38 <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)?
17:16:40 <KarenOD> Natsha: back to provisioning topic, there are lots of other bodies working on the lower layer aspects, don't want to cause conflicts
17:16:57 <wseltzer> ack next
17:17:10 <JeffH_> JeffH_ has joined #crypto
17:17:56 <JeffH_> q?
17:18:07 <KarenOD> 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)
17:18:32 <KarenOD> ... one end i see hardware and at the other end I don't need hardware
17:18:58 <KarenOD> ... need diversity between these requirements, how do we get through that business conversation so that technologists can get on with it
17:19:29 <KarenOD> KarenLu: there is a need for different levels of assurance
17:19:44 <KarenOD> ... also different levels of convenience
17:20:35 <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.
17:20:57 <KarenOD> ... banks and health care providers are going to have their own risk models that will address these levels
17:21:06 <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
17:21:11 <tarcieri> Martin_: can use host card emulation
17:21:23 <KarenOD> ... can have different levels of assurance within a single interaction with a specific provider
17:21:38 <engelke> +1 to Martin_
17:21:59 <HadiNahari> +1 to Martin_
17:22:08 <tarcieri> and yeah, +1 to Martin_ ;)
17:22:43 <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)
17:22:48 <Martin_> *Endorsement
17:23:01 <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.
17:23:02 <JeffH_> see HOBA.IE for example of software-based SE (key gen & key mgmt) + web authn
17:23:17 <KarenOD> 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
17:24:25 <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)
17:24:29 <KarenOD> ... 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
17:24:39 <Martin_> tarcieri: Yup, agree!
17:24:54 <KarenOD> ... has to be simple but it must also do its job properly and not expose too much risk
17:24:55 <wseltzer> ack next
17:24:59 <martin_paljak> tarcieri: actually, I would say that maybe not. they all suck (keychain on osx is horrible from hardware token POV)
17:25:04 <wseltzer> zakim, close queue
17:25:04 <Zakim> ok, wseltzer, the speaker queue is closed
17:25:15 <martin_paljak> Maybe the web as a platform with a browser as  its manifest.
17:25:16 <tarcieri> martin_paljak: we're talking about a soft replacement for a hardware token here
17:25:22 <tarcieri> I like hardware tokens too ;)
17:25:29 <martin_paljak> should think big and bypass the operating system.
17:25:33 <KarenOD> Hannes: what doo i have to do today if I am a web site provider and I want to provide access to the sim
17:25:43 <tarcieri> martin_paljak: why?
17:25:46 <martin_paljak> and forget the legacy (incl pc/sc and crypto services that are "old")
17:25:55 <KarenOD> Natasha: same as any corporate / operator based API
17:26:02 <tarcieri> martin_paljak: OS cryptographic services are already going to abstract access to e.g. TPMs
17:26:03 <martin_paljak> and make "web-centric" adapter API (what cng/keychain basically is)
17:26:18 <KarenOD> ... there will probably be some financial aspect of that as well...
17:26:36 <martin_paljak> well, why have "NTF" that is fat32++ if we could have XFS ?
17:26:43 <martin_paljak> *NTFS
17:26:51 <KarenOD> Hannes: presumably I would need to remove the username/pw from my site and figure out which providers my customers are using
17:27:09 <tarcieri> martin_paljak: I'm not sure we're talking about the same thing here...
17:27:25 <tarcieri> martin_paljak: the browser should provide a high level API... that can talk to hardware tokens, or software alternatives
17:27:33 <Martin_> @martin: Would agree that NTFS is just "FAT32++", it's actually a great FS. But it is besides the point ;)
17:27:39 <KarenOD> ... 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
17:27:42 <tarcieri> if you bypass the OS services, then the browser needs to talk directly to the host TPM
17:27:44 <bhill2> and, hannes, hope that your business is not one where the carrier has signed an exclusive deal or wants to compete with you
17:27:51 <Martin_> meant, would disagree NTFS is just FAT32++ ;)
17:27:57 <Peter_Cattaneo> http://gsmamobileconnect.com/ - uses OpenID Connect
17:28:25 <KarenOD> Siva: there are two extremes: Sim in mobile environment (already distributed) or FIDO (not distributed)
17:28:44 <HadiNahari> There are free alternatives to paid TEE solutions
17:28:48 <KarenOD> ... having an indepent secure element that is agnostic to all these solution is possible, and no one here knows which one will win
17:29:10 <KarenOD> ... from a W3C perspective we shouldn't care
17:29:36 <KarenOD> s/indepent/independent
17:30:00 <virginie> q?
17:30:11 <KarenOD> Hannes: lesson from the oauth work, some of the management things that we didn't understand later cased vendor lock in
17:30:22 <KarenOD> ... there is a standards piece that is missing
17:30:38 <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.
17:31:02 <martin_paljak> Martin_: JavaCard == Oracle. prepare to pay money after a strange lawsuit
17:31:06 <Martin_> Of course individual applets could add their own extra security protocols (based on signed commands or whatever)
17:31:27 <HadiNahari> Martin_: the GP model might work, but the business and ecosystem facets of GP model should be taken into account as well.
17:31:35 <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
17:32:21 <KarenOD> (missed exchange on walled gardens and FIDO between Siva and Brad Hill - someone feel free to chime in)
17:32:31 <wseltzer> ack next
17:32:36 <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.
17:32:53 <Ullrich> You have to discuss with Oracle to create a JavaCard OS. Different situation for applets ianal, of course
17:33:02 <HadiNahari> +1 on Martin_
17:33:23 <KarenOD> Bruno: for egov cases we can't require all users to instll software
17:33:26 <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.
17:33:29 <martin_paljak> actually, these days you can get a variety of GP compatible JavaCard-s with different price/feature properties really easily
17:33:34 <martin_paljak> it was not like this 10 years ago.
17:33:50 <Martin_> of course wouldn't have to be the same outcome for a new standard but shows standardization and openness is important!
17:33:50 <Anders_R> why install applets, most people only needs keys.  the JS is the applications
17:34:00 <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.
17:34:00 <nvdbleek> nvdbleek has joined #crypto
17:34:45 <KarenOD> KarenLu: to Hannes' question on how the SIM is used, there is an ETSI standard that addresses how this would work
17:35:07 <KarenOD> ... basically PKI based, make authn request using the sender
17:35:19 <bhill2> sorry, this feels like partitioning the market in order for carriers / handset providers to seek rents from the most valuable / vulnerable players
17:35:32 <Phil_Hoyer> q+
17:35:40 <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.
17:35:50 <KarenOD> ... regarding GSMA MobileConnect, it is a framework for the mobile providers to act as an Identity provider under the OpenID connect
17:35:50 <solar> agreed - I can load an app on an iphone for free
17:35:59 <solar> why should I have to pay to store my keys securely
17:36:52 <wseltzer> q?
17:38:13 <rbarnes> rbarnes has joined #crypto
17:38:42 <bhill2> W3C is a subscriber to Open Stand and its principles
17:38:43 <bhill2> http://open-stand.org/about-us/principles/
17:39:01 <bhill2> One of those is permissionless innovation:
17:39:02 <bhill2> http://open-stand.org/permissionless-innovation-impacting-the-future-of-the-internet/
17:39:21 <bhill2> These secure element proposals just don't meet that bar.
17:39:32 <virginie> The open mobile API by SIMAlliance is available under : http://www.simalliance.org/en/all_resources/technical_resources/
17:40:18 <virginie> q?
17:40:25 <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.
17:40:51 <martin_paljak> HannesTschofenig: yeah, trust means different things to different people in different contexrts
17:42:13 <wseltzer> ack next
17:42:32 <solar> I trust that there will be muffins and fresh coffee at break-time
17:42:45 <tarcieri> cookies don't follow the same origin policy, FWIW :(
17:43:10 <KarenOD> adam: need to discuss origin control
17:43:14 <KarenOD> (scribe failure here...)
17:43:19 <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.
17:43:25 <tarcieri> but +1 to the point of cross-origin questions
17:43:37 <harry> in terms of OpenStand and as long as the layer of abstraction necessary to access these elements
17:43:41 <bhill2> The access control specs for the Secure Element proposal are completely divorced from the reality of web applications
17:43:42 <bhill2> http://opoto.github.io/secure-element/#access-control-img
17:43:51 <KarenOD> KarenLu: address origin in our submission paper
17:44:00 <harry> is done in royalty-free. We do understand there are patents on lower-levels in hardware, etc.
17:44:10 <harry> So we don't want to force any particular lower-level hardware based approach.
17:44:13 <bhill2> harry, I'm not talking about patents
17:44:25 <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.
17:44:26 <harry> Then what are you talking about?
17:44:46 <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
17:45:09 <harry> Yes, but not every waebsite will want "user-driven" access with registration/enrollment inbound in Web.
17:45:13 <vkata> Does that even make sense? I don’t want permissionless access to my government ID
17:45:16 <wseltzer> ack next
17:45:17 <harry> Consumer facing websites with openeded users will.
17:45:32 <harry> But then govt. and many other high-security websites will want out-of-web enrollment.
17:45:47 <harry> That's fine - see no reason why both types of authenticators can't be supported
17:45:54 <adam_> Follow up wold have been, can we use existing cross origin sharing security for cross origin secure element senarios
17:45:59 <bhill2> it's a different thing to have access control associated with a credential as far as where that credential can be used
17:46:16 <HannesTschofenig> "I don’t want permissionless access to my government ID"  --> This statement makes no sense to me
17:46:29 <harry> I don't understand that lats statement bhill2.
17:46:33 <tarcieri> adam_: like CORS? what origin does a credential belong to? what origin does my GPG key belong to?
17:46:55 <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.
17:47:00 <bhill2> if I have a government ID, maybe it has some internal access control that defines who it will release assertions to
17:47:13 <bhill2> what is being talked about here are not any kind of objective criteria for access
17:47:14 <KarenOD> Martin: doing everything from scratch isn't sensible
17:47:16 <virginie> q?
17:47:17 <tarcieri> NIST curves--
17:47:22 <bhill2> this are pure pay-to-play APIs
17:47:32 <tarcieri> CFRG is standardizing Curve25519
17:47:43 <KarenOD> Bruno: the solution that we provide must have backward compatibility with what is in the field...
17:47:46 <harry> Yes, and if some website wants to use an authenticator like a govtnmernt ID  that has some internal access control, that's fine.
17:47:56 <bhill2> the determiner of what will work and who can use it is who pays the mobile operator or handset manufacturer
17:47:59 <harry> That's the user's choice to use that eID and the website's choice to use it.
17:48:03 <harry> Seems orthogonal to the spec.
17:48:06 <wseltzer> bhill2, we shouldn't discount the places people are willing to pay for different models
17:48:07 <harry> from the Web-level.
17:48:09 <bhill2> with no guarantee of open access or competition
17:48:11 <HannesTschofenig> CFRG is analysing different curves and may make a suggestion for a single curve or for multiple curves for use in the IETF.
17:48:17 <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)
17:48:21 <tarcieri> HannesTschofenig: sure
17:48:30 <KarenOD> KarenLu: there are many contries that have deployed smart card based citizen IDs
17:48:31 <tarcieri> Martin_: have you seen BADA55?
17:48:32 <harry> There's a huge debate over NIST curves going on in CFRG and WebCrypto WG.
17:48:43 <bhill2> but Open Stand does talk about enabling competition and open access
17:48:45 <tarcieri> Martin_: the NSA could've tweaked any of the curve parameters
17:49:06 <wseltzer> sure, and free isn't the only model of competitive access
17:49:12 <pea_> When we speak of  "Permissionless access" who is the relying party relying on?
17:49:12 <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.
17:49:20 <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
17:49:23 <wseltzer> ack next
17:49:23 <harry> We'll hopefully get a compromise shortly.
17:49:24 <KarenOD> Harve: we cannot behave as if nothing has been developed and deployed thus far, we need to build components of the queues
17:49:30 <harry> bhill2, you are reading far too much into OpenStand.
17:49:33 <vkata> I don
17:49:36 <bhill2> right, but none of the proposed implementers here have made any guarantees of open access
17:49:50 <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)
17:49:51 <harry> It would probably be anti-competitive to prevent people from using custom access control schemes in particular authenticators.
17:49:55 <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.
17:49:58 <bhill2> competitively priced exclusive access is rent-seeking that is hostile to user choice
17:49:59 <tarcieri> harry: last I checked, NUMS curves were still slower for ECDHE use case
17:50:00 <KarenOD> Kathy: What would you like to see from the Web Services API that would enable hardware tokens
17:50:00 <Karen> q?
17:50:19 <KarenOD> KarenLu: something that eliminates proprietary solutions
17:50:32 <JeffH_> please no ECC curve dogfight here
17:50:39 <tarcieri> heh k ;)
17:50:47 <KarenOD> Bruno: to be able access hardware tokens from web applications
17:50:59 <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
17:51:06 <Martin_> ;)
17:51:27 <harry> bhill2, different sites will have different takes on access.
17:51:34 <martin_paljak> JeffH_: the point is no dogfight about curves but just a call for common sense
17:51:37 <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?
17:51:56 <KarenOD> Harve: be able to access the hardware through APIs, leave it to service providers to define what is in their boxes
17:51:58 <virginie> q?
17:52:02 <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
17:52:02 <virginie> q+
17:52:08 <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.
17:52:15 <harry> as it would be to ask Paypal to use US govt-authorized CAC/PIV cards.
17:52:19 <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
17:52:20 <harry> We need to support both kinds of use-cases
17:52:23 <KarenOD> Siva: don't want to make the browsers a walled garden
17:52:33 <harry> I think that's fairly obvious and has nothing to do with OpenStand.
17:52:45 <KarenOD> NAtasha: there should a discovery element of a hardware token that you can do something with
17:52:53 <harry> Most websites will *not* use strictly controlled smartcard eID systems
17:52:58 <harry> but some important ones will.
17:53:06 <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).
17:53:09 <colin_g> @harry smart property as example
17:53:16 <harry> Most websites real need to kill password using an open scheme that allows Web-based enrollment.
17:53:24 <wseltzer> ack next
17:53:43 <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.
17:53:48 <harry> Those are site-specific.
17:53:55 <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
17:53:56 <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
17:54:17 <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
17:54:19 <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
17:54:34 <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 :)
17:54:38 <harry> If that's how the origin works, I don't see how we can say "no, you can't do that"
17:54:39 <KarenOD> 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
17:54:40 <bhill2> I totally expect that credentials might be locked to a particular applet
17:54:54 <tarcieri> Martin_: I think the burden of proof is on the NSA/NIST as to why their curves should be trusted
17:55:00 <wseltzer> bhill2, see EME?
17:55:04 <harry> Just like we can't allow Finland eID sites to be accessed by random people who self-enroll :)
17:55:15 <bhill2> sure
17:55:23 <harry> We just have to allow agility on trust models
17:55:32 <KarenOD> ... how do we want to implement the open web stack
17:55:37 <harry> I agree that most normal websites will need U2F/UAF style enrollment
17:55:44 <Cathy> q?
17:55:55 <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 ?
17:55:56 <harry> there's just different trust models for different sites/services.
17:56:00 <KarenOD> Siva: it needs to be the highest level possible that is common across the various existing standards/solutions, independent of the implementation
17:56:07 <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
17:56:33 <bhill2> everyone needs trustworthy technology
17:56:39 <harry> I think people will vote with their feet here.
17:56:43 <KarenOD> ... where the line is drawn is left to the web browser development community
17:56:45 <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
17:56:51 <harry> For example, some people may trust their eID card more than a Google Yubikey in Europe
17:56:57 <martin_paljak> harry: as a representative of a country (sort of) I'd expect this not to happen.
17:56:58 <harry> in the USA it will likely be reverse
17:57:07 <tarcieri> JSON Web Encryption is also standardizing algorithms, so it's curious that WebCrypto is trying to standardize them independently :|
17:57:12 <bhill2> still not what this is about
17:57:16 <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
17:57:22 <harry> We have different levelfs
17:57:31 <harry> of algorithm authentication
17:57:32 <Anders_R> @Nadalin: there's nothing wrong with the API, it is the ability to use other keys that's the problem
17:57:36 <harry> JOSE does ciphersuites
17:57:43 <harry> WebCrypto allows a much lower-level of parameter choice
17:57:53 <harry> just to be clear,that's why there's the difference.
17:58:00 <colin_g> smartcard chips and NFC are part of smart property implementation in bitcoin, some details here https://en.bitcoin.it/wiki/Smart_Property
17:58:07 <tarcieri> harry: ok
17:58:08 <harry> We tried to co-ordinate but JOSE didn't want to go to the level of detail WebCrypto allowed
17:58:11 <tarcieri> harry: that's reasonable
17:58:13 <tarcieri> haha, I see
17:58:23 <harry> and WebCrypto didn't want to restrict in the way JOSE did.
17:58:26 <harry> Both approaches are quite sensible.
17:58:39 <harry> A "high-level" version of WebCrypto shold probably use JOSE ciphersuites
17:58:50 <harry> I expect someone to polyfill that soon :)
17:58:54 <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
17:58:55 <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)
17:58:56 <tarcieri> that would be nice, especially since they're all INDCCA3
17:58:57 <Ullrich> Ullrich has joined #crypto
17:59:10 <virginie> zakim, can you generate minutes ?
17:59:10 <Zakim> I don't understand your question, virginie.
17:59:20 <wseltzer> rrsagent, make minutes
17:59:20 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html wseltzer
17:59:43 <Anders_R> The bridge between smart cards and WebCrypto which I have pestered mailing lists about remains to be defined
17:59:43 <wseltzer> ack next
18:00:01 <Martin_> Anders: +1
18:00:23 <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
18:00:27 <virginie> to wseltzer : do not panic, but, looks like minutes are empty ...
18:00:28 <bhill2> the analogy is to network neutrality
18:00:37 <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
18:00:56 <KarenOD> Detlef: is someone planning to implement the webcrypto API?
18:01:14 <KarenOD> Natsha: it depends on your audience
18:01:21 <virginie> Annoucement : there is a queue, guy, and by the way, it is closed...
18:01:24 <KarenOD> Harry: it has been implemented already (version 1)
18:01:59 <Anders_R> @Nadalin, this audience is not talking about optional features...
18:02:16 <Anders_R> it's should be in the core
18:02:19 <KarenOD> Siva: part of the objective of this group is to define what extensions are possible
18:02:27 <harry> there will be no new core features in version 1.
18:02:33 <KarenOD> Natasha: there will be different offerings and tht is ok
18:02:39 <Anders_R> of course not
18:02:40 <harry> We could also put authentication in a different API
18:02:54 <virginie> to detlef : impelmentations details of web crypto are availble here https://www.w3.org/2012/webcrypto/wiki/Main_Page#First_implementations
18:03:05 <tarcieri> harry: that would probably make a lot of sense
18:03:50 <HadiNahari> queue mgmt sucks 8-)
18:04:21 <KarenOD> Brian: i'm microsoft research, not Internet Explorer, we have alot of interest in that
18:04:31 <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.
18:06:21 <KarenOD> 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
18:06:52 <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.
18:06:52 <bhill2> +10000000
18:07:00 <tarcieri> +10000000 too ;)
18:07:28 <martin_paljak> complexity is bad, of course.
18:07:46 <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
18:07:49 <JeffH_> ditto wrt Hadi
18:08:11 <KarenOD> Natasha: GSMA is talking to W3C, we are committed to creating something open for W3C
18:08:11 <tarcieri> hahaha :)
18:08:17 <JeffH_> @virginie -- Hadi essentially built on what Brad was saying
18:08:22 <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
18:08:23 <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.
18:08:41 <bhill2> but services are not willing to pay middlemen for *access* to our customers
18:08:48 <virginie> @JeffH yes, but from a device maker perspective, it is more innovative :)
18:09:03 <bhill2> and customers do not want to have our choice dictated by rent-seeking by our carriers
18:09:04 <KarenOD> Siva: there is no other forum that we are involved in that could be as neutral as this one
18:09:10 <rbarnes> HannesTschofenig: Apple is usually not a good example in any standards discussion :)
18:09:35 <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
18:09:45 <tarcieri> HannesTschofenig: Apple largely used industry standards already implemented throughout Europe and in Google Wallet
18:09:55 <Martin_> rbarnes: Absolutely agree about the main issue being access control
18:10:14 <virginie> Note that open source TEE is developed in Linaro, available here : https://wiki.linaro.org/WorkingGroups/Security
18:10:21 <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.
18:10:22 <KarenOD> Harve: tradeoff between openness and liability
18:10:26 <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.
18:10:32 <bhill2> Would any implementers make a RAND pledge for access to a Secure Element?
18:10:47 <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
18:10:52 <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
18:10:55 <bhill2> Doesn't even have to be RAND-Z, just RAND>
18:11:07 <Martin_> rbarnes: +1
18:11:22 <rbarnes> Martin_: cool, let's go build something ;)
18:11:26 <drogersuk> drogersuk has joined #crypto
18:11:26 <bhill2> http://en.wikipedia.org/wiki/Reasonable_and_non-discriminatory_licensing
18:11:29 <harry> In terms of DRM, is the underlying access to the DRM hardware being shipped with Google, Microsoft, and Mozilla's backing RAND?
18:11:42 <harry> I believe just the EME level is royalty-free
18:11:57 <rbarnes> harry: that was exactly why i brought it up as prior art
18:12:04 <harry> I believe the same thing would be the case with any authenticator work around hardware.
18:12:07 <virginie> to wseltzer : thanks for fixing the minutes :)
18:12:33 <KarenOD> KarenLu: ideally we will have a nice interface to hardware tokens
18:12:50 <harry> We would not want to "bind" the authenticator in *any* non-neutral way to any hardware, as that hardware may not be RF.
18:12:51 <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)
18:12:58 <harry> That's why level of abstraction is needed.
18:13:12 <KarenOD> Hadi: standards are necessary but not sufficient, you also need free open source software, not everyone needs liability,
18:13:13 <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.
18:13:34 <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
18:14:02 <public_screen> [brfeak]
18:14:08 <HannesTschofenig> I like workshops with a lot of discussions. This certainly is one of those...
18:14:09 <public_screen> s/brfeak/break/
18:14:32 <vkata> HannesTschofenig: I don’t understand the point. Is the implication that there’s a mandatory barrier of entry other than vim?
18:15:19 <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
18:15:55 <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
18:16:16 <Martin_> consider trusted execution technology, and similar
18:17:01 <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
18:32:12 <nvdbleek> nvdbleek has joined #crypto
18:36:25 <tarcieri> https://twitter.com/sleevi_/status/510132960549298177
18:36:46 <tarcieri> sleevi +1 for splitting AuthN from everything else in WebCrypto ;)
18:39:44 <HadiNahari> HadiNahari has joined #crypto
18:39:55 <brunojav> brunojav has joined #crypto
18:40:27 <Ullrich> Ullrich has joined #crypto
18:41:04 <KarenOD> KarenOD has joined #crypto
18:41:05 <wseltzer> Topic: New Security Features for the Web
18:41:08 <Phil_Hoyer> Phil_Hoyer has joined #crypto
18:41:14 <wseltzer> Web Cryptography & utilizing ARM TrustZone based TEE (Trusted Execution environment) for authentication, cryptography and beyond by Ilhan Gurel (Trustonic)
18:41:17 <rbarnes> rbarnes has joined #crypto
18:41:37 <karenlu> karenlu has joined #crypto
18:41:46 <wseltzer> Ilhan_Gurel: Why use a TEE?
18:42:33 <wseltzer> ... isolation between secure and insecure at the hardware level
18:42:48 <bhill2> bhill2 has joined #crypto
18:42:50 <klc> klc has joined #crypto
18:43:03 <klc> klc has left #crypto
18:44:06 <wseltzer> ... handle secure data without revealing it to rich OS
18:44:34 <wseltzer> ... Different use cases from Secure Element.
18:44:51 <wseltzer> ... e.g. trusted UI
18:44:55 <colin_g> colin_g has joined #crypto
18:45:36 <mdwood> mdwood has joined #crypto
18:45:54 <wseltzer> ... use cases: DRM, trusted UI, authentication
18:46:35 <wseltzer> ... Trusted UI: secure interrupts, touch-screen interaction
18:47:11 <wseltzer> ... secure credential storage
18:47:50 <wseltzer> ... crypto and key management
18:48:10 <wseltzer> i/New Security Features/scribenick: wseltzer
18:48:28 <wseltzer> rrsagent, make minutes
18:48:28 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html wseltzer
18:48:55 <wseltzer> ... e.g Android KitKat Keymaster
18:49:18 <gentilkiwi> gentilkiwi has joined #crypto
18:49:22 <wseltzer> ... Trustonic: ARM TrustZone based TEE solutions
18:50:06 <wseltzer> ... Solution W3C chooses should: be based on standard JS APIs and/or HTML tags
18:50:19 <wseltzer> ... have abstraction layer for low-level inmpementations allowing usage of TEE/SE
18:50:25 <wseltzer> ... allowe webapps to choose and use TEE/SE
18:51:28 <wseltzer> Giri_Mandyam: Qualcomm Innovation Ctr., Multifactor Authentication based on User Contextual Data and the Mobile Web
18:52:31 <wseltzer> ... web ecosystem moving beyond username/password;
18:53:00 <wseltzer> ... Device APIs provide contextual data, e.g. media capture and streams, geolocation
18:53:21 <wseltzer> ... gUM, audio fingerprinting from capture stream
18:54:15 <wseltzer> ... PSAP (public safety answering point) needs unspoofable location info
18:54:21 <virginie> virginie has joined #crypto
18:54:28 <karenlu> karenlu has joined #crypto
18:54:34 <wseltzer> ... need secure means for reconfiguring authenticator
18:54:43 <wseltzer> ... Geofencing use case:
18:55:08 <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
18:55:26 <wseltzer> ... gathering items in a store, then automatically paying on geofence breach (leaving the store)
18:55:32 <wseltzer> ... or dispatch and delivery
18:57:29 <HannesTschofenig> The figure was missing the absolute values of power consumption
18:57:32 <wseltzer> ... Contextual data has a place alongside multifactor auth
18:57:56 <wseltzer> ... contextual auth must be non-spoofable and trustworthy for web service providers.
18:58:30 <wseltzer> Mike_Jones: (selfissued) Microsoft, The Increasing Importance of Proof-of-Possession to the Web
18:59:37 <wseltzer> ... Many initiatives to use proof-of-posession in web protocols
18:59:57 <wseltzer> ... unstealable cookies, passwordless login, proof of eligibility, etc.
19:00:55 <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)
19:01:01 <wseltzer> ... e.g, TLS channel binding
19:01:50 <wseltzer> ... OAuth PoP work
19:03:19 <wseltzer> ... PoP for login
19:03:30 <wseltzer> ... Proving eligibility to participate
19:04:04 <wseltzer> ... e.g. Netflix watching
19:04:10 <colin_g> Platform-held key vs. user-held key (key held / owned on computer or other device)
19:04:32 <wseltzer> ... we will need js support for using platform keys to enable js apps to participate
19:05:20 <wseltzer> ... WebCrypto specs will need to enable use of platform and device PoP keys for JS apps to participate in PoP world
19:05:26 <mdwood_> mdwood_ has joined #crypto
19:06:08 <wseltzer> Vladimir: Ericsson, Cloud Service Privacy in a Pervasive Monitoring Landscape
19:07:27 <wseltzer> ... How do we secure not only authentication of the user, but data?
19:07:30 <colin_g> The costs of data everywhere... encrypted vs. unencrypted, metadata everywhere, MITM, endpoint attacks, more
19:07:37 <wseltzer> ... WebCrypto relies on the origin server being trustworthy
19:08:13 <wseltzer> ... that's not enough
19:08:29 <wseltzer> ... need to protect against service provider, data breahes, and government demands
19:08:43 <wseltzer> ... protect keys and data from the hosting app
19:09:12 <wseltzer> ... e.g. cloud storage needs privacy in the cloud, on host and client sides
19:09:30 <wseltzer> ... need: secure file input/download where cleartext is not accessible by the webapp js runtime
19:10:19 <wseltzer> ... HTML forms, need secure forms, e.g. Google's end-to-end chrome extension
19:10:45 <tarcieri> this talk reminds me of my blog post ;) http://tonyarcieri.com/whats-wrong-with-webcrypto
19:10:46 <wseltzer> ... Need to protect in such a way that service provider can access neither keys nor data.
19:11:23 <Cathy> Cathy has joined #crypto
19:11:23 <wseltzer> Jonas_Andersson: Fingerprint Cards, Enhancing privacy in token based electronic identity schemes
19:11:41 <wseltzer> ... We make fingerprint sensors for mobile phones
19:11:55 <wseltzer> ... working to expose API through Global Platform, integrate in TEE
19:12:08 <wseltzer> ... A number of mobile phone OEMs have integrated fingerprints
19:12:17 <bal> bal has joined #crypto
19:12:28 <wseltzer> ... Most of the apps available are local unlock
19:12:55 <wseltzer> ... But Samsung-Paypal, Apple Pay, showing possibilities of generic identity token
19:13:21 <wseltzer> ... We think mobile phone is most attractive identity token. Security, TEEs, Secure Elements
19:13:35 <wseltzer> ... paid for by the end-user, so distribution is managed
19:13:45 <rbarnes> always nice when somebody else pays
19:13:57 <wseltzer> ... biometrics
19:14:25 <wseltzer> ... Privacy. major barrier to use of mobile as identity token
19:14:39 <wseltzer> ... "identity is a positive thing" basis of trust, relationship
19:14:50 <colin_g> identity vs. anonymity
19:15:02 <tarcieri> privacy++ anonymity++
19:15:14 <wseltzer> ... privacy is EU-defined as control of identity
19:15:29 <wseltzer> ... a major point of privacy is security in identity allocation
19:15:48 <rbarnes> nice that the fingerprint guy is leading with privacy
19:16:09 <wseltzer> ... when you talk about biometry, everyone worries about privacy
19:16:15 <wseltzer> ... We have a limited supply of biometrics
19:16:22 <wseltzer> ... we can't disown our fingers
19:17:29 <wseltzer> ... biometries aren't secret.  but users are in best position to display them conveniently
19:17:51 <wseltzer> ... EU: privacy in biometry comes from the system, training officials, oversight
19:17:54 <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
19:18:09 <wseltzer> ... we can turn this into a problem for technology
19:18:18 <virginie> paper detailing view from Jonas is here : http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_4.pdf
19:19:32 <wseltzer> ... We have to define standards on security, guiding users to make reasonable choices among objects
19:20:06 <virginie> a scribe is expected, any volunteer ?
19:20:09 <siva> siva has joined #crypto
19:20:12 <rbarnes> rbarnes has joined #crypto
19:20:33 <bhill2> scribenick: bhill2
19:20:53 <virginie> q?
19:21:01 <wseltzer> zakim, open queue
19:21:01 <Zakim> ok, wseltzer, the speaker queue is open
19:21:02 <virginie> floor to question ...
19:21:09 <klc> klc has joined #crypto
19:21:19 <dirk_balfanz> dirk_balfanz has joined #crypto
19:21:47 <shadow> shadow has joined #crypto
19:22:17 <bhill2> 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
19:22:45 <bhill2> … regardless of biometric integration, you are deciding that the type of identity is required of the user
19:22:56 <bhill2> … no choice whether or not use that for authentication at a variety of services
19:23:05 <bhill2> … but that is obviously a privacy issue because of a diminishment of choice
19:23:15 <davitb> davitb has joined #crypto
19:23:19 <virginie> q+
19:23:26 <bhill2> … minimal ability to opt out or choose from a range of authN options
19:24:15 <bhill2> jonas: may have slipped in text that what concerned me was privacy issues regarding use of biometry
19:24:38 <bhill2> … if biometry is only in a secure environment controlled by the user, there is no privacy issue for that data
19:24:47 <siva> q+
19:25:11 <bhill2> … 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
19:25:27 <bhill2> … and modalities of authentication
19:25:57 <bhill2> … always a trade off, using a stable identity with a service conveys benefits I may choose
19:26:17 <bhill2> … solution with cryptographic token, so long as it is not your id card or passport remains a powerful system
19:26:31 <bhill2> … token could be privacy invading, but you could have multiple ones to make it difficult to trace
19:26:59 <bhill2> 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
19:27:13 <bhill2> mikeJones: taking a poll
19:27:47 <bhill2> … 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
19:27:55 <bhill2> … who believes this proposition?
19:28:14 <bhill2> … to employ the key
19:28:18 <bhill2> most of room raises hands
19:28:27 <bhill2> richard barnes does not believe this premise
19:29:12 <bhill2> 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
19:29:29 <siva> q?
19:29:43 <Mohamad> Mohamad has joined #crypto
19:29:51 <bhill2> mkieJones: if we don't do that in rechartering, we have wasted the effort
19:29:52 <wseltzer> q?
19:29:56 <wseltzer> ack next
19:29:58 <bhill2> s/mkieJones/mikeJones
19:30:10 <public_screen> q?
19:30:39 <wseltzer> q+ to ask about PoP in an open system
19:30:46 <bhill2> virginie: which API or feature you think a browser should implement to answer your request?
19:31:08 <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?
19:31:25 <bhill2> sorry missed that....
19:31:40 <bhill2> mikeJones: need to use keys not held by browser
19:31:51 <wseltzer> q-
19:32:10 <bhill2> giridhar: take advantage of all device apis, trust moving in both directions - trusted origin, what is that?
19:32:33 <bhill2> jonas: means to authenticate to out-of-band factor
19:32:58 <bhill2> Ilhan: handle keypair generation, sign, etc. should be possible to extend this to use, e.g. TEE
19:33:05 <wseltzer> ack next
19:33:23 <pea_> Let me also add storage of that those secret keys be stored in a secure peice of hardware
19:33:24 <bhill2> apologies, I missed scribing vladimir's response  - can anyone backfill?
19:33:51 <wseltzer> q+
19:34:00 <bhill2> siva: concerned about biometrics being lost, it will happen.  in case of geofencing, I don't have a choice and device will do it.
19:34:10 <bhill2> … reducing power makes it more likely that it will be ubiquitous
19:34:13 <harry> if your biometrics are lost, you can always cut your fingers off :)
19:34:20 <bal> bal has joined #crypto
19:34:41 <bhill2> jonas: you can look at levels of security achievable for biometrics stored in a e.g. lost device
19:34:44 <siva> can i borrow yours? :)
19:35:00 <bhill2> … can put in secure element, encrypt it, use templates that don't store full images, irreversible templates
19:35:50 <bhill2> … you should select devices you consider to be secure, also remote wipe
19:36:05 <Ullrich> Probability of guessing and faking biometrics depends on biometric trait and configuration
19:36:19 <bhill2> … we can establish with certifications to what level data is secure and public can make sure it meets expectations
19:36:48 <pea_> I assume the "found" Device remians capable of Authenticating the individual / Owner who lost the device at the crime scene.
19:36:58 <bhill2> ilhan: in TEE biometrics can be encrypted before storage, or put data in special partition
19:37:34 <bhill2> siva: where are keys stored?
19:37:43 <bhill2> ilhan: can do key derivation, wrapping and unwrapping
19:39:02 <bhill2> giridhar: for geofencing, there are agreements e.g. between operators and delivery people
19:39:10 <public_screen> q?
19:39:23 <bhill2> vladimir: not as concerned about specific storage of biometrics so long as it is possible to provision and make use of keys
19:39:44 <bhill2> … 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
19:39:57 <bhill2> … we want to enable storage mechanisms to evolve, not the question
19:40:10 <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.
19:40:32 <bhill2> mikeJones: most people only use 3-5 passwords
19:40:49 <bhill2> … ability to phish and leverage that is what we're primarily combating
19:41:08 <bhill2> … use appropriate measures for biometric and lost device risk, but existing risks are low hanging
19:41:26 <bhill2> wseltzer: vladimir laid out a component that is missing from most web security discussions, what are the steps to take?
19:41:31 <JeffH_> +1 to Mike
19:41:45 <bhill2> vladimir: might be an entire group that could look at that over years to determine how to do this
19:41:45 <rbarnes> rbarnes has joined #crypto
19:41:53 <bhill2> … sprouts of proposals mentioned in the document
19:42:08 <tarcieri> http://css.csail.mit.edu/mylar/mylar.pdf <--- one approach to building E2E encrypted web applications
19:42:13 <bhill2> … to they make sense, can we treat data in the browser as privileged data for the user but not exposed otherwise
19:42:17 <virginie> q?
19:42:28 <bhill2> ack wseltzer
19:42:53 <siva> q?
19:42:57 <siva> q+
19:43:04 <bhill2> wseltzer: how do we use TEEs and secure elements in open systems?  balance user control and access to their device with security
19:43:18 <bhill2> ilhan: giving key cards as example
19:43:34 <bhill2> s/card/vault/
19:43:47 <bhill2> .. default is software impl, can be replaced by hardware
19:44:06 <bhill2> … server may want to find and use specific hardware modules
19:44:21 <virginie> q?
19:44:41 <bhill2> mikeJones: you don't get privacy for free you get privacy if you put it in by design
19:45:04 <bhill2> … 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
19:45:26 <bhill2> ack siva
19:46:04 <bhill2> siva: question for mike.   what is next from a webcrypto api perspective should we start thinking about in extending leverage of keys?
19:46:18 <bhill2> mikejones: agree in next few hours on new charter language for new work, probably very short
19:46:29 <bhill2> … goal of new chartered work is enable use of keys not held in browser from the browser
19:46:44 <bhill2> … then get best thinking on how to do that in simple and general way so it is usable and gets used
19:46:53 <John> John has joined #crypto
19:47:21 <virginie> chair reminds that no objection is authorized until we reach the afternoon discussion :)
19:47:23 <bhill2> 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
19:47:24 <tarcieri> +1
19:47:36 <rbarnes> generic key access is one of many use cases that people in this room have
19:47:59 <bhill2> giridhar: geofencing as authenticator, existing api doesn't cut it, we should go beyond keys for authenticating users
19:48:03 <virginie> note : use case has been captured under https://www.w3.org/Security/wiki/IG/webcryptonext_workshop
19:48:06 <engelke> +1
19:48:15 <bhill2> ilhan: agree goes beyond keys
19:48:16 <Peter_Cattaneo> q+
19:48:17 <colin_g> Let the user decide
19:48:29 <rbarnes> q+
19:48:49 <bhill2> karenlu: there are many options beyond keys but need to start somewhere
19:49:03 <HannesTschofenig> I am curious whether there is interest in geofencing?
19:49:14 <rbarnes> HannesTschofenig: +1 not relevant to this discussion
19:49:19 <bhill2> giridhar: being overly focused on what can be stored in a discrete piece of hardware is too discrete
19:49:32 <virginie> q?
19:49:36 <bhill2> ack next
19:49:58 <bhill2> Peter_Cattaneo: in real world where people use keys there is usually an associated policy
19:50:43 <HannesTschofenig> Policy is a scary term since it is so generic
19:50:50 <bhill2> … want to extend policies to include whole world of sensors like geofencing
19:51:00 <Nadalin> fq+
19:51:05 <Nadalin> q+
19:51:20 <bhill2> … not only crypto but policy associated with crypto
19:51:41 <pea_> I woudl think Policy is simply the governance of the use of something
19:51:43 <bhill2> ilhan: if we generate or import key we can add metadata
19:52:04 <bhill2> … quite easily, if apis exist to pass this information to the hardware
19:52:31 <bhill2> mikeJones: I'm an advocate for claims-based identity
19:52:43 <bhill2> … make decisions about interactions based on claims
19:53:00 <bhill2> … on example might be where are you, what time is it, who said you are an account holder at google?
19:53:30 <bhill2> … in terms of scoping what we would do, we can enable people to use crypto to make authoritative statements
19:53:54 <harry> q+
19:54:37 <bhill2> ilhan: may fully utilize power of cup in key environment, e.g. to speed up advanced operations
19:54:48 <tarcieri> PCLMULQDQ FTW ;)
19:55:01 <JeffH_> "cup" ?
19:55:11 <bhill2> 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
19:55:24 <bhill2> … also I believe that all of that permission to use a key work is out of scope for what webcrypto wants to do
19:55:35 <bhill2> … there is work that platform vendors may do and other places we need to work on
19:55:42 <virginie> to tarcieri : hum... what do you mean exactly ?
19:55:46 <bhill2> … how do we easily enable choosing the right key with right biometric
19:56:00 <JeffH_> q+
19:56:03 <tarcieri> virginie: that was re: exposing fast hardware instructions for cryptography
19:56:11 <bhill2> … so phishing app can't misrepresent what keys it is using
19:56:20 <tarcieri> it's a CPU instruction that can be used to accelerate GCM
19:56:48 <bhill2> vladimir: we all agree on beyond passwords, identity is an assertion, replacing passwords is loaded but also effectively replacing username
19:56:52 <bhill2> ack next
19:57:04 <harry> q?
19:57:08 <JeffH_> the "other places" might be other W3C WGs or other SDOs
19:57:24 <bhill2> rbarnes: keys is an easy way to understand how it fits into webcrypto, but am concerned after this discussion
19:57:29 <JeffH_> need to remember that "the browser" is "a platform"
19:57:31 <bhill2> … there are lots of tokens out there that won't provide you that access
19:57:45 <bhill2> … raise hand if you have token that can't sign / encrypt arbitrary data
19:58:05 <bhill2> … semantic level of webcrypto api is "sign these octets"
19:58:47 <harry> hehe "box"
19:58:58 <harry> rbarnes brought up that term
19:59:12 <wseltzer> zakim, close queue
19:59:12 <Zakim> ok, wseltzer, the speaker queue is closed
19:59:18 <wseltzer> q?
19:59:49 <siva> q+
19:59:52 <Anders_R> i think a "bridge" is what we need rather than an a "box"
20:00:01 <tarcieri> heh
20:00:03 <bhill2> ack next
20:00:31 <bhill2> nadalin: agree that keys are important but lots of devices can't handle just key usage
20:00:46 <bhill2> … 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?
20:00:58 <bhill2> … need concrete examples to understand how to change them
20:01:12 <bhill2> … we can augment, but not change core set, must be somewhat compatible with what we've already put out there
20:01:14 <colin_g> http://www.w3.org/TR/WebCryptoAPI/
20:01:29 <bhill2> vladimir: you didn't consider protected from application itself?
20:01:40 <bhill2> nadalin: not in scope of crypto apis?
20:02:41 <HannesTschofenig> This sounds a bit like DRM to me
20:02:43 <bhill2> vladimir: if you are to have secured data, I need to get key to decrypt data
20:02:45 <virginie> reminds that the workshop is about webcrypto, yes, but is not limited to
20:02:55 <bhill2> ack next
20:03:13 <bhill2> harry: this workshop can produce requests to other groups outside of webcrypto
20:03:31 <bhill2> … e.g. geofencing out to appropriate WG
20:03:39 <bhill2> … have a hold up on 2 levels
20:03:54 <bhill2> … crypto key level, what level of abstraction do we want on authentication
20:05:12 <bhill2> … everything is in scope for the workshop, if not for any particular WG
20:05:19 <HadiNahari> HadiNahari has joined #crypto
20:05:44 <bhill2> ack next
20:05:52 <bhill2> jeffH_ is ready for food
20:06:10 <colin_g> @JeffH +1
20:06:18 <JeffH_> ja
20:06:20 <bhill2> mikeJones: happy to have unanimous agreement on something to do
20:06:33 <bhill2> vladimir: important to protect data
20:06:54 <bhill2> giridhar: take recommendations to other WGs, happy to get new use cases endorsed as a chair
20:07:19 <bhill2> 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
20:07:49 <bhill2> ilhan: if we enable better management of keys and periphals we enable better security
20:08:17 <tarcieri> bhill2: fight the good fight for simple authn during the rechartering! :)
20:08:20 <colin_g> read my paper! it is fun http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/papers/webcrypto2014_submission_12.txt
20:09:11 <Mohamad> Mohamad has joined #crypto
20:10:10 <virginie> RRSAgent, generate the minutes please
20:10:10 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html virginie
20:25:55 <bfar> bfar has joined #crypto
20:34:23 <adam_> adam_ has joined #crypto
20:40:54 <Karen> Karen has joined #crypto
20:58:18 <israelh> israelh has joined #Crypto
21:03:22 <wseltzer> Topic: Next Steps on Chartering
21:03:34 <wseltzer> Etherpad, http://etherpad.mit.edu/p/webcrypto
21:05:32 <wseltzer> Israel_Hilerio: Algorithm discovery API
21:05:44 <virginie> virginie has joined #crypto
21:06:42 <wseltzer> ... use case, evaluate user-agent capabilities before execution
21:06:57 <Anders_R> Anders_R has joined #crypto
21:07:01 <wseltzer> ... in order to secure complete process, you need to know all the algorithms will be available
21:07:06 <rbarnes> rbarnes has joined #crypto
21:07:22 <wseltzer> ... avoid the weird patterns of creating temp keys just to validate algo support
21:07:47 <HadiNahari> HadiNahari has joined #crypto
21:07:49 <wseltzer> [slide: Scenario #1]
21:07:50 <Cathy> Cathy has joined #crypto
21:09:31 <wseltzer> [slide: Scenario #2]
21:09:51 <Herve_SIMalliance> Herve_SIMalliance has joined #crypto
21:10:24 <wseltzer> [slide: Proposal]
21:10:53 <wseltzer> israelh: proposal, create a synchronous API that checks if a list of algos are supported
21:11:46 <wseltzer> ... return true if all supported, else fail on first unsupported
21:11:49 <vgb> vgb has joined #crypto
21:11:54 <wseltzer> zakim, open queue
21:11:54 <Zakim> ok, wseltzer, the speaker queue is open
21:11:59 <wseltzer> q?
21:12:06 <engelke> q+
21:12:29 <wseltzer> ack engelke
21:12:49 <wseltzer> engelke: Is there a reason to provide a list, rather than asking "what's supported"?
21:12:49 <rbarnes> q+
21:12:54 <davitb> davitb has joined #crypto
21:12:57 <rbarnes> q-
21:13:11 <wseltzer> israelh: reduce fingerprinting risk
21:13:25 <wseltzer> Phil_Hoyer: you can re-run the query to fingerprint
21:13:36 <AxelNennker> AxelNennker has joined #crypto
21:13:42 <wseltzer> israelh: it reduces the risk
21:14:04 <virginie> q?
21:14:34 <wseltzer> harry: Now, we're going to discuss chartering
21:14:43 <virginie> thanks israel for the contribution
21:15:18 <wseltzer> ... first, let's get sum-ups from browser vendors. What have you heard, what might you do?
21:16:15 <wseltzer> Dirk_Balfanz: I'm not on the chrome team
21:16:34 <karenlu> karenlu has joined #crypto
21:17:15 <lifewsky> lifewsky has joined #crypto
21:17:34 <wseltzer> ... there are a few things we're not going to do on the web
21:17:38 <wseltzer> ... raw sockets
21:17:48 <wseltzer> ... very low-level access to smartcard seems in that category
21:17:53 <wseltzer> ... APDU-level access
21:18:13 <wseltzer> ... very difficult to write to.
21:18:23 <Ullrich> Ullrich has joined #crypto
21:18:32 <wseltzer> ... for example, how would I write the google login page with a low-level api
21:18:34 <Sangrae> Sangrae has joined #crypto
21:18:40 <wseltzer> ... don't want to introduce a huge web tracker
21:19:10 <wseltzer> ... Box proposal: high-level API, e.g. "sign this", browser hands to the box implementation
21:19:25 <wseltzer> ... in chrome, extensions have access e.g. to USB
21:19:38 <wseltzer> ... but, how does that not turn into driver hell?
21:19:44 <wseltzer> ... how do we put things into the box?
21:19:56 <wseltzer> ... Support for existing stuff?
21:20:16 <wseltzer> ... Existing solutions that don't use the web aren't necessarily broken
21:20:29 <wseltzer> ... but it's a different model, how do we support it on the web
21:20:48 <wseltzer> ... how to distinguuish which have privacy, access control models
21:21:04 <Karen> Karen has joined #crypto
21:21:44 <wseltzer> ... minimalist option, hardware-bound keys, outside the browser, origin-scoped, tied to some auth
21:21:47 <Nadalin_> Nadalin_ has joined #crypto
21:21:56 <wseltzer> ... hard enough to make that work
21:22:06 <wseltzer> ... is card there or not, how do we do attestation, etc.
21:22:10 <Karen> Scibe: Karen
21:22:10 <Karen> Dirk: this is what we were voting on ; what can we minimally do
21:22:10 <Karen> …let's do hardware keys, not in browser
21:22:10 <Karen> …and let's tie them to some sort of authentication
21:22:10 <Karen> …hard to figure out how to make that work
21:22:11 <Karen> …if we scope to that level, we will have our hands full
21:22:26 <Karen> …strong authentication; killing passwords, maybe some encryption; but no identity API, no tax ID number
21:22:29 <harry> harry has joined #crypto
21:22:30 <wseltzer> s/Scibe: Karen
21:22:40 <wseltzer> s/Scibe: Karen/Scribenick: Karen/
21:22:40 <Karen> …I guess you cannot do…if I understand banking…cann't do how that works
21:22:50 <wseltzer> s/voting/thinking/
21:22:51 <Karen> …maybe be move to a federation model, such as with bankings
21:23:01 <Karen> …no, bigger piece would be the box model
21:23:08 <Karen> …could give us what we want but would be harder
21:23:19 <Karen> …how to prevent global tracking mechanisms; prevent driver hell
21:23:32 <Karen> …my recommendation is unless someone can calm me down about the box
21:23:38 <Karen> …minimalist approach; do keys
21:23:46 <Karen> …and see where we are next year
21:23:55 <bhill2> +1 to Dirk
21:23:56 <wseltzer> s/do keys/do keys, origin-bound/
21:23:56 <Karen> Richard: I have a lot in common
21:24:06 <Karen> …starting with keys perspective
21:24:19 <Karen> …obvious place to start; but not sure it's as simple as you think
21:24:31 <Karen> …if cards are not built to support this interface, you still need an adaptation layer
21:24:36 <Karen> …that's what I've gotten last few days
21:24:49 <Karen> …if we are going to support…diversification
21:24:53 <Karen> …general API
21:25:09 <Karen> …also need a lower level fine grained API that is tightly controlled
21:25:11 <wseltzer> rrsagent, make minutes
21:25:11 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html wseltzer
21:25:13 <Karen> …JS can access the API
21:25:21 <Karen> …some model of authorization; whole story to figure out
21:25:28 <Karen> …I think that is something…setting up a sandbox
21:25:45 <Karen> …is something we need can figure out the access model
21:25:50 <Karen> …we have high level API bin
21:25:54 <Karen> …and bin for low-level APIs
21:26:02 <Karen> …to help bridge the technicalities up to the higher level
21:26:08 <wseltzer> i/Etherpad/scribenick: wseltzer
21:26:14 <Karen> …and need for some access control story to knit these things together
21:26:22 <Karen> …and the browser needs to figure out how to load
21:26:25 <Karen> …and discover code you need
21:26:33 <Karen> …and make sure it's right code and authorize that
21:26:44 <Karen> …If I were in charter discussion, those are the high-level bins
21:26:45 <Rob_Philpott> can we display the IRC?
21:26:49 <wseltzer> i/Scibe/scribenick: Karen
21:26:52 <wseltzer> rrsagent, make minutes
21:26:52 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html wseltzer
21:26:53 <Karen> Brian: I will take a slightly contrarian POV
21:27:02 <Karen> …what I heard as being interesting
21:27:08 <Karen> …is the multiple origin problem
21:27:13 <Karen> …we have model where JS assumes...
21:27:25 <Karen> …if folks use keys from multiple sites, you have to fix that problem
21:27:33 <Karen> …multiple tokens and multiple sites
21:27:43 <Karen> …second point is a secure browser and secure client
21:27:51 <Karen> …and whether adding isolation boundaries
21:27:55 <Karen> …or issuing @ to driver
21:28:03 <Karen> …whatever it is, it is those two problems to figure out
21:28:09 <Karen> …a secure channel to token
21:28:13 <wseltzer> s/a secure browser/a secure channel between the browser/
21:28:16 <Karen> …and have it figure out who is allowed to talk to it
21:28:21 <Karen> …two fundamental security problems
21:28:28 <Karen> …security policy on who gets access to what
21:28:45 <Karen> …the reason I have a little trouble with low-level access to tokens is that @ have already done that
21:28:51 <Karen> …I don't know how many people want to do that again
21:28:57 <Karen> …wonder if way to think about it
21:29:02 <Karen> …is a lower level interface layer
21:29:10 <Karen> …and an interface between existing OS and interface
21:29:15 <Karen> …everything has in one form or another
21:29:19 <Karen> …and do that translation
21:29:32 <Karen> …I don't want to make every smart card manuf to redisclose what their smart cards do
21:29:38 <Karen> …i still have to control how to expose that
21:29:41 <Karen> …still focus on the interface
21:29:47 <Karen> …that does not work for everything
21:29:50 <Karen> …works for OS
21:29:57 <nvdbleek> brian: thank you for acknowledging the importance of muliple origin  access to keys
21:29:58 <Karen> …now talking about IoT devices that might not have that
21:30:06 <Karen> …that would be a way to get some of the heavy lifting done
21:30:09 <bhill2> q+
21:30:14 <wseltzer> ack Phil_Hoyer
21:30:19 <Karen> Peter: I think the general approah
21:30:22 <Karen> …I agree with
21:30:31 <Karen> …also suggest we think about other use cases to support
21:30:33 <wseltzer> s/Peter/Phil/
21:30:34 <Karen> …access to key and pin
21:30:38 <Karen> …rendering of that
21:30:51 <Karen> …is the browser, or the signed JS in the sandbox creates the GUI
21:30:58 <Karen> .,..maybe another bridge layer that's more dynamic
21:31:05 <Karen> …I think there was an open @ card
21:31:12 <HadiNahari> HadiNahari has joined #crypto
21:31:13 <Karen> …some cards are already written in JS fashion
21:31:13 <wseltzer> s/@ card/smartcard/
21:31:18 <nvdbleek> shouldn’t we listen to Israelh’s view?
21:31:33 <Karen> …agree there is a pain point for middleware cos
21:31:35 <virginie> q?
21:31:38 <Karen> ..but general approach is correct one
21:31:41 <wseltzer> ack Siva
21:31:50 <HannesTschofenig> I agree that we should hear from Israel if he is from the browser team
21:31:50 <Karen> Siva: Take some of middleware each hardware vendor builds
21:31:55 <Karen> …making money in the hardware
21:32:02 <Karen> ….make another separate WG in W3C
21:32:13 <Karen> …if this box is high level enough and various other boxes
21:32:28 <Karen> …that may take all of our proprietary efforts and verticals
21:32:35 <Karen> …and take more details
21:32:57 <Karen> …and put complexity somewhere else; have abstraction layer
21:33:00 <israelh> Happy to share IE's point of view.
21:33:08 <Karen> Richard: higher level are going to be more challenging to design
21:33:11 <harry> boxes inside boxes
21:33:14 <Karen> …at lower level is card talking to itself
21:33:23 <Karen> …the capabilities of cards dictate that
21:33:35 <Karen> …higher level, people will need to cooperate and compromise on the funcationality
21:33:39 <vgb> vgb has joined #crypto
21:33:42 <Karen> …and look at putting under common umbrellas
21:33:56 <wseltzer> ack bhill2
21:34:00 <Karen> Brad: with my hat as WebApps Security chair at W3C
21:34:02 <wseltzer> ack bhill
21:34:09 <wseltzer> q+ israelh
21:34:11 <Karen> …we have heard about install base of token systems
21:34:18 <Karen> …but also install base is the web itself
21:34:32 <Karen> …we should do a 'Hypocratic Oath" approach of first do no harm
21:34:46 <Karen> …first not do any harm to existing privacy that billions of web users rely on
21:35:00 <Karen> …early in career learned that formal models don't always match up
21:35:17 <colin_g> colin_g has joined #crypto
21:35:18 <Karen> …collide six billion cards with four billion web users, there would be a lot of carnage
21:35:23 <Martin_> I think he might have meant 'hippocratic oath'  ;)
21:35:28 <Karen> Dirk: I am not proposing to say do harm to the web
21:35:36 <wseltzer> s/Hypocratic/Hippocratic/
21:35:36 <colin_g> q+
21:35:37 <Karen> …here is something we have to figure out to do is right
21:35:50 <Karen> …But worried that we will argue over these open questions for a long time rather than get stuff done
21:35:56 <Karen> …I am not seriously proposing this
21:36:02 <Karen> …but let's say we approve the FIDO specs
21:36:02 <JeffH_> maybe it was webocratic?
21:36:08 <Rob_Philpott> Rob_Philpott has joined #crypto
21:36:18 <brunojav> q+
21:36:20 <Karen> …then device manufacturers know what to do…build FIDO compliant devices
21:36:26 <Karen> …don't want to just argue about stuff
21:36:26 <wseltzer> q+ siva
21:36:39 <Karen> Richard: Would be radically simpler to say get rid of old devices
21:36:49 <Karen> …and new ones can point to web
21:36:58 <Karen> …another alternative is to address these open questions
21:37:06 <Karen> …either de novo and throw away the past
21:37:09 <Karen> …or have some new story
21:37:16 <Karen> …I would be interested in thoughts from the room
21:37:17 <wseltzer> s/open questions/legacy devices/
21:37:22 <bhill2> I'm not suggesting we *have* to abandon existing systems
21:37:24 <Detlef> Detlef has joined #crypto
21:37:26 <Karen> …do we create a whole new API built from the start
21:37:28 <Detlef> +q
21:37:37 <Karen> …not sure which would get results faster
21:37:37 <virginie> q+ Phil_Hoyer
21:37:40 <wseltzer> ack israelh
21:37:46 <bhill2> just that a guiding principal in how we integrate them should be that we not harm the existing web security and privacy model
21:37:50 <Karen> Israeth: Web Crypto spec seems to be at maturing point
21:38:02 <Karen> …really see start to release it without flag or pre-fixing
21:38:06 <Karen> …we are mature enough at that point
21:38:16 <wseltzer> s/maturing/mature enough/
21:38:17 <Karen> …I do see from our side, how do we align; what mobile plan
21:38:21 <Karen> …in terms of support
21:38:26 <Karen> …things we are currently working on
21:38:28 <Karen> …from the future
21:38:33 <Karen> …one of things we are looking at
21:38:41 <Karen> …is to enable some of the @ scenarios
21:38:56 <Karen> …that is one thing to look at for a plug-in free web
21:39:03 <Karen> …investigating how do we enable that
21:39:11 <Karen> …from programming model, high level API
21:39:25 <Karen> …means that we let the OS manage the devices and have UA abstract those devices
21:39:34 <Karen> …create that middle layer responsible to be managed by the OS
21:39:42 <Karen> …have it abstracted; whether keys or certificates
21:39:52 <Karen> …not saying high-level abstraction from WebCrypto API
21:40:03 <Karen> …but certainly would not want it going into details of managing the devices
21:40:12 <Karen> …delicate role of UA, OS and role of end user
21:40:25 <Karen> …we see in some of our discussions the end-user playing a role
21:40:39 <Karen> …see a relaxing of restrictions for usage of their @ or keys
21:40:43 <Karen> …how simple can we make it
21:40:59 <Karen> …so the end user really understands what they are doing; friendly names, usage patterns
21:41:07 <Karen> …Those are some things to be addressed; and from browser side
21:41:14 <Karen> …pass to VJ to talk about platform side
21:41:37 <Karen> VJB: I am in violent agreement with what Dirk and Richard said
21:41:46 <Karen> …sounds like we are struggling with low-level and high-level
21:41:50 <Karen> …the way I think about it
21:42:02 <Karen> …suppose I could wave the magic wand and give you both low and highlevel
21:42:05 <Karen> …what would you want?
21:42:13 <Karen> …I would want the highest level possible
21:42:21 <virginie> note to attendees :  vgb is from Microsoft too, regular participant to web crypto WG
21:42:22 <Karen> …I would prefer approach high-level approach
21:42:25 <Karen> …and like others have said
21:42:46 <Karen> …somewhere along the way we will reach some understanding of how much legacy needs to be supported vs how much to sacrifice
21:43:00 <Karen> …having been in the Web Crypto discussions, there is a lot of infrastructure
21:43:11 <Karen> …at least some of it will need to migrate in a diff form in cloud
21:43:13 <Karen> …to support
21:43:16 <Karen> ...open
21:43:25 <wseltzer> q?
21:43:30 <Karen> …I'm in favor of starting with the more abstract and then reaching into the finer details as needed
21:43:43 <Karen> Phil: In terms of doing the new things
21:43:54 <Karen> …if the main goal is to get rid of passwords, let's not understand the policies out there
21:44:14 <Karen> …reasons of why certain design choices were made that don't support the protocol but still being a good authenticator
21:44:24 <Karen> …need to leverage some of those communities; need to do the use case analysis
21:44:43 <Karen> …some may have a five-year lifetime; a bit difficult to throw away
21:44:52 <wseltzer> ack colin_g
21:44:54 <Karen> Colin: I wanted to touch upon the privacy issues brought up by a prior speaker
21:45:06 <Karen> …Google, MS, Mozilla, have different privacy policies
21:45:17 <Karen> …curious in talking about the Web Crypto, and maybe it's a bit out of scope
21:45:33 <Karen> …curious if in context of Web Crypto discussions, someone talked about privacy
21:45:42 <Karen> …are there aspects of the discussions we can have here today
21:45:51 <Karen> …that could be baked into some of the protocol level things
21:46:00 <Karen> …within context of discussions here today and your browser developments
21:46:05 <Karen> …I know that's a general question
21:46:10 <Karen> …but it's a question for you, ok?
21:46:24 <harry> q+
21:46:27 <Karen> Brian: thinking about things like anonymous credential technology
21:46:41 <Karen> …and anonymous attestation, there are cryptographic technologies that allow you to do @
21:46:49 <Karen> …systems being deployed in trials
21:47:01 <Karen> …in EU and US
21:47:07 <Karen> …this group could choose to take that work on
21:47:19 <Karen> ..whether that is appropriate now or later, that is something we can discuss
21:47:30 <Karen> …If we should implement, that is question I am also asking
21:47:42 <Karen> …if between tokens, that is a separate story; we could learn from TKM space
21:47:49 <Karen> …W3C has long history in this space
21:47:55 <Karen> …Wendy is hiding
21:48:10 <Karen> …a colleague is co-author of P3P spec; advise us to keep policy aspect out of it
21:48:27 <Karen> Colin: part of my question is to see if there are things the three of you could collaborate on
21:48:30 <Karen> …is that a possibility?
21:48:41 <Karen> Brian: those specs are under OSP; those specs are available
21:48:47 <Karen> …no one excepts gov'ts want to do it
21:49:03 <Karen> …I wish more folks would use anonymous technology
21:49:04 <wseltzer> +1 to that wish
21:49:13 <Karen> …not for blockage issue; just have not seen uptake
21:49:18 <JeffH_> https://research.microsoft.com/en-us/projects/u-prove/
21:49:21 <Karen> …users willing to sell privacy at a discount
21:49:28 <Karen> …not sure if that is something this group wants to take on
21:49:42 <virginie> q?
21:49:48 <Karen> Dirk: I'll take a slightly different point of view
21:49:50 <wseltzer> zakim, close queue
21:49:50 <Zakim> ok, wseltzer, the speaker queue is closed
21:49:54 <Karen> …within realm of question
21:49:59 <Karen> …we have been calling access control
21:50:03 <selfissued> selfissued has joined #crypto
21:50:09 <Karen> …have something on card; identifies me, maybe tax ID
21:50:16 <Karen> …question is who gets access to that stuff
21:50:19 <Karen> …that is the privacy issue
21:50:21 <harry> notes open-ended question time is over, we are going to move to chartering phase now
21:50:22 <Karen> …and Brad speaks out
21:50:39 <Karen> ..he is worried that these things will leak all over the web and break the web as we know it
21:50:52 <Karen> …I think we agree that some reasonable access control mechanism is needed
21:50:59 <Karen> …but the detail of what it should look like
21:51:04 <Karen> …make the key, don't use the key
21:51:09 <Karen> …there are other mechanisms
21:51:16 <Karen> …the question to tackle around the box model
21:51:21 <Karen> ..and abstract notion of the box
21:51:33 <Karen> …what is the more concrete something in the middle that we can all agree upon
21:51:42 <Karen> …and I have not heard anything over last two days that we can agree upon
21:51:53 <Karen> Richard: not first time we are exposing something to the web
21:52:00 <Karen> …it's not baked into spec
21:52:05 <Karen> …we make permissions for the API
21:52:19 <siva> siva has joined #crypto
21:52:22 <Karen> …give some guidance for the nature of the permissions being presented
21:52:26 <Karen> …whatever identifiers
21:52:26 <siva> +1 for richard
21:52:29 <John> John has joined #crypto
21:52:29 <Karen> …whatever is simplest
21:52:34 <Karen> …and what is exposed for origin
21:52:45 <Karen> ..general principle, when possible, that is the simplest model
21:52:55 <Karen> …anything else requires user access model
21:52:55 <wseltzer> ack next
21:53:01 <Karen> Bruno: How is it different
21:53:08 <Karen> …in web to access, to ask user
21:53:17 <Karen> …versus web site or geolocation to access these credentials
21:53:23 <Karen> …let the user get the choice
21:53:33 <Karen> …to be in the private mode or in the mode where he can expose his identity
21:53:36 <Karen> …my second question
21:53:43 <Karen> Richard: that is what I was meaning to say
21:53:53 <Karen> …we can take a lot of what we have learned about expressing sensitive things
21:53:55 <Karen> …and apply that
21:53:59 <Karen> …we'll have to choose
21:54:01 <Karen> …like web cams
21:54:04 <Ullrich> Ullrich has joined #crypto
21:54:06 <Karen> …this is identity I want to present
21:54:13 <Karen> …there are lessons to be learned
21:54:22 <Karen> Bruno: I have questions for Dirk
21:54:27 <Karen> …how is web ID compatible?
21:54:33 <Karen> ..and the German ID card
21:54:44 <Karen> Dirk: what I meant by that is who gets access to the stuff on the card
21:54:53 <Karen> …answer is whoever put the info onto the card gets access
21:55:00 <wseltzer> s/web ID/eID/
21:55:03 <Karen> …If I understand the German system, you can issue certificates
21:55:11 <Karen> …and then have access to more or less info than what is on the car
21:55:12 <Karen> d
21:55:24 <Karen> …more powerful system but different to what is on the web
21:55:33 <Karen> Sam, Google: eID and BSI
21:55:37 <Karen> …we talked to them quite a bit
21:55:43 <Karen> …we talked about authentication stuff
21:55:51 <Karen> …very basic high level notion
21:56:13 <Karen> …you have anonymous ID.....
21:56:17 <Karen> …it's hard for user
21:56:23 <Karen> …you need a smart card reader to plug in
21:56:28 <Karen> …we have gone to other extreme
21:56:33 <Karen> …if you attach a device to a web site
21:56:40 <Karen> …and you can reverify the same device later
21:56:49 <Karen> …we have been talking to them continuously
21:56:53 <Karen> …and the arguments for it
21:56:59 <Karen> …if these protocols take off
21:57:16 <Karen> …there might be a card that you could use as an anonymous consumer or gov't ID
21:57:24 <Karen> …have to have minimum notion; but it does not do that
21:57:36 <Karen> …we do keep talking with EID all the time
21:57:48 <public_screen> q?
21:57:48 <Karen> Dirk: First part of your question, what is wrong with asking the user
21:57:58 <Karen> …moderate the access to the card is better way to say
21:58:03 <Karen> …that might be reasonable
21:58:08 <Karen> …but reminds me of the UI we have
21:58:18 <Karen> …which was not a screaming success
21:58:32 <wseltzer> s/we have/we have in TLS client, PCKS11/
21:58:39 <Karen> …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
21:58:44 <public_screen> ack siva
21:58:49 <Karen> …it's far from a resolved question to ask user to say yes or no
21:58:55 <Karen> Brad: what if it's an iFrame
21:59:01 <Karen> …how does user know
21:59:03 <wseltzer> embedded contexts
21:59:09 <Karen> …these prompts makes it difficult to user to understand
21:59:16 <Karen> @: contexts are challenging
21:59:25 <Karen> …site was not able to achieve what it was trying to communicate to the user
21:59:42 <virginie> s/@/israelh
21:59:46 <Karen> ..we hvea a responsibility to make things clear; but there is some context needed
21:59:49 <wseltzer> ack siva
21:59:59 <Karen> Siva: if we could start from scratch and make smart cards smarter
22:00:01 <Karen> …and use FIDO
22:00:07 <Karen> ..and give them out to 8 million users
22:00:27 <Karen> …it's really not the hardware vendors who will decide; let's make them and give it away
22:00:32 <Karen> …it's who is willing to spend the money
22:00:41 <Karen> …if we can make the current world work with the web that is ideal
22:00:42 <wseltzer> siva: Who is willing to buy and distribute
22:00:53 <Karen> …if you want to start and scratch, tell me how that will work
22:01:06 <Karen> Dirk: starting from scratch is one way of putting it
22:01:13 <wseltzer> q?
22:01:21 <bhill2> if you build it, they will come
22:01:24 <Karen> …another way to look at it is where to begin with something new; what is the next step
22:01:39 <Karen> Detlef: I would like to comment on the same issue
22:02:05 <bhill2> at the rate retailers are getting breached, we'll have to replace 8 billion credit cards by the middle of next year anyway
22:02:08 <Karen> …I think the development with respect to browsers is different from development from large trust infrastructures and deployed smart cards for example
22:02:15 <Karen> …you cannot change today and ship in next four weeks
22:02:21 <Karen> …the lifecycles are considerably longer
22:02:26 <Karen> …it's not possible to disregard legacy
22:02:33 <Karen> …what you create today will be legacy in a few years
22:02:52 <Karen> …if we introduce something today which is not supposed to break something, it needs to address the legacy
22:03:07 <Karen> …we need to look back a little bit and be flexible enough to look into the future and allow the next migration schedule
22:03:14 <Karen> Richard: Is HTTP legacy?
22:03:24 <bhill2> things move fast - my business cards are older than all of my credit cards
22:03:25 <Karen> …it's right level of abstraction to meet additional use cases
22:03:30 <harry> q?
22:03:33 <Karen> …but not a conceptual reimaging
22:03:33 <harry> ack Detlef
22:03:36 <Karen> …perhaps we can hit
22:03:44 <Karen> …but hard to hit that sweet spot
22:03:56 <Karen> …not impossible to hit the new things that will last and be achievable
22:04:12 <Karen> Brian: They are not legacy, it's the current technology we deploy every day
22:04:20 <Karen> …how many German ID cards get issued every day
22:04:30 <siva> Or how many EMV cards!!!! In the billions!
22:04:48 <Karen> …saying our procedures are all legacy before we deliver them…we live with technology you deploy for a long time
22:04:55 <Karen> …that is fine
22:05:09 <Karen> …I'll be upset if my old USB memory stick that's 256 MB stops working
22:05:20 <Karen> …we'll use the cryptographic tokens we have because we still value them
22:05:24 <Karen> …different from webcams
22:05:25 <siva> +1 for Brian
22:05:27 <Karen> …keys have value
22:05:35 <Karen> …if you give access to web site that shouldn't
22:05:41 <Karen> …if web cam, sees my messy desk
22:05:50 <Karen> ..but if it has value, I care about that and have to be more careful
22:05:58 <Karen> …probably why pop-up dialogues have not worked
22:06:04 <Karen> …the dot framework ten years ago
22:06:13 <Karen> …there is security policy in place and either you do it or not
22:06:14 <wseltzer> s/dot/.Net/
22:06:17 <Detlef> +q
22:06:19 <Karen> …there was no dynamic user invovelment
22:06:25 <Karen> …tossed out the dancing hippos
22:06:30 <Karen> …this is a hard problem
22:06:39 <Karen> …cryptographic material that has value
22:06:43 <wseltzer> ack next
22:07:01 <Karen> 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
22:07:11 <Karen> …don't be too scare…interfacing on various tokens
22:07:16 <Karen> …we are willing to bring that to the party
22:07:25 <Karen> …to Brad's concern, we are not exposing them, they are already out there
22:07:34 <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?
22:07:35 <Karen> …guys building those stacks are not at all versed in this
22:07:40 <Karen> …you put out the ID, you got his ID
22:07:51 <Karen> …concept that something is being put out in the open; we are already doing that
22:08:05 <Karen> …need a better way, or at least common way, and not kick the can down the road
22:08:07 <siva> +1 for Phil
22:08:11 <Karen> .Harry: any final responses
22:08:18 <Karen> …good final Q&A
22:08:24 <Karen> Harry: I was trying to explain
22:08:31 <Karen> …if you are new to W3C
22:08:39 <Karen> Wendy: thank you panel
22:08:46 <Karen> Harry: At W3C what typically happens
22:09:03 <Karen> …is we host a workshop and enough of our members say we should do something in a space for standardizations
22:09:12 <Karen> …if workshop is clear we move to standards track
22:09:22 <Karen> …if incoherent, we often move to a community group
22:09:28 <Karen> …show of hands……
22:09:31 <rbarnes> rbarnes has joined #crypto
22:09:44 <Karen> …for yes we can standardize?
22:09:51 <Karen> [show of hands - quite a few]
22:09:57 <Karen> …in the workshop we try to figure out
22:10:06 <Karen> …what it is we should standardize; what is the consensus
22:10:21 <Karen> …we had a big workshop a few years ago in Mountain View about identity in the browser
22:10:31 <Karen> …and we discovered we needed an API for access
22:10:39 <Karen> …that was a total surprise, but it ended up working out
22:10:52 <wseltzer> s/access/crypto functions in the browser/
22:10:54 <Karen> …in this exercise we are going to do that
22:10:57 <Karen> …show of hands
22:11:02 <Karen> …and after this workshop is over
22:11:08 <wseltzer> zakim, reopen queue
22:11:08 <Zakim> ok, wseltzer, the speaker queue is open
22:11:12 <Karen> …we could probably use the web payments IG
22:11:21 <Karen> …we often set up an existing or set up a new mailing list
22:11:26 <Karen> …to help in the chartering process
22:11:33 <Karen> …we're going to show off what some of these things look like
22:11:42 <Karen> …then we'll get to the chartering bit
22:11:53 <Karen> …when we start a working group, here is web crypto WG
22:12:15 <Karen> …we want to get to a high-level common understanding for a charter
22:12:28 <Karen> Wendy: W3C processes and procedures
22:12:41 <Karen> …an advisory committee member approves charters for W3C to do new work
22:12:55 <Karen> …that is important to companies and their lawyers and the IP commitments that you are asked to make
22:13:05 <Karen> …RF IP is important aspect of W3C standards
22:13:27 <Karen> …as a member you make an RF commitment for relevant patents on the work
22:13:35 <Karen> …so we need to put the scope of work into a charter
22:13:48 <Karen> …and before we put the charter to the membership, we try to figure out what goes into the charter
22:13:57 <Karen> …Working Groups produce recommendations
22:14:11 <Karen> …Interest Groups do requirements and use cases
22:14:17 <Karen> …we also have Business Groups
22:14:26 <Karen> …Here is the Web Crypto WG
22:14:39 <Karen> …we have WebApps, SysApps and other groups to which we can send work
22:14:53 <Karen> …and we just sent out today to the W3C membership the Web Payments Interest Group charter
22:15:04 <Karen> …if approved, we'll look at the payments on the web challenges
22:15:19 <Karen> …perhaps some of this work, and synergy between the questions we are discussing here and the payments focus
22:15:30 <Karen> …looking at secure authentication
22:15:38 <Karen> …other modes of work, we can do liaisons with other groups doing work
22:15:48 <Karen> …we also sometimes bring in work through member submissions
22:16:04 <virginie> example of IG for payment : http://www.w3.org/2014/04/payments/webpayments_charter.html
22:16:10 <Karen> …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
22:16:16 <Karen> …We had that situation with Open Social
22:16:24 <Karen> …we took that and moved it into a Social WG
22:16:28 <Karen> Harry: I'll give a few exmaples
22:16:35 <Karen> …if you are a W3C member, you can submit work
22:16:35 <JeffH_> the webpaymentws IG is not a good example of a healthy functional IG
22:16:44 <Karen> …here is the Open Social member submission
22:16:53 <Karen> ….If you are a W3C member, we can show you how to do it
22:17:00 <wseltzer> "We're from the web, and we're here to help."
22:17:06 <Karen> …At end of this workshop, we will submit a report that will likely look like this
22:17:15 <Karen> …here is the messy white board from that workshop
22:17:22 <Karen> …it's a pretty good technique
22:17:33 <virginie> example  of identity workshop result http://www.w3.org/2011/identity-ws/report.html
22:17:36 <Karen> …This is web payments workhops; call for participation will be out shortly
22:17:40 <Karen> …here is the W3C home page
22:17:45 <Karen> …and here is what a charter looks like
22:18:00 <Karen> …Charter tells us who the chair is, Virginie in case of the Web Crypto WG
22:18:21 <Karen> …everything is basically public; we have schedule, team support, scope, what we are delivering, and a timeine
22:18:30 <Karen> …and related people we should talk to
22:18:34 <Karen> …It will take some time
22:18:41 <Karen> …somewhere between one and six months
22:18:52 <Karen> …try to get some understanding in the next 40 minutes
22:19:08 <Karen> …I am going to write some things I have heard…actually Wendy can you write?
22:19:23 <Karen> …what levels of abstraction; the 'box' problem; what kind, where do we want it
22:19:36 <Karen> …a call for a simple developer facing API
22:19:41 <Karen> @: Can you explain?
22:19:54 <virginie> s/@/MikeJohns
22:19:57 <Karen> Harry: UAF, what Dirk showed is not based on low-level, but pretty high level
22:20:00 <Karen> …FIDO UTF
22:20:08 <Karen> …different levels of maturity, not quite RF
22:20:15 <Karen> …a fairly high level of abstraction
22:20:18 <brunojav_> brunojav_ has joined #crypto
22:20:20 <Karen> …you can imagine that could be useful
22:20:22 <rbarnes> s/UTF/U2F/
22:20:31 <Karen> …and you would like WebCrypto as it exists today to extend it
22:20:41 <Karen> …heard we would like…algorithm discovery
22:20:45 <rbarnes> s/MikeJohns/MikeJones/
22:20:47 <Karen> …key discovery, we kind of do
22:20:51 <Karen> …Mike brought it up
22:20:54 <Karen> …key discovery spec
22:21:11 <Karen> …we might want a key discovery; keys are also on devices, which brings us to device discovery
22:21:17 <Karen> …keys if you are calling
22:21:25 <Karen> …what other things do you think people think
22:21:39 <Karen> …BigNum
22:21:48 <Karen> …certificate metadata; that is clear
22:21:52 <Karen> …way to access metadata
22:22:01 <Karen> …anything else that is clear that you can imagine us standardize
22:22:09 <Karen> Charles: key storage
22:22:11 <mdwood> mdwood has joined #crypto
22:22:16 <Karen> Harry: persistence outside of
22:22:31 <Karen> @: keys…[not hearing]
22:22:48 <JeffH_> GimmeSomeOfDemKeys()
22:22:59 <Karen> Martin: some kind of separation between web site owned keys
22:23:14 <Karen> …and every kind of device or existing smart card device where user has different keys
22:23:24 <israelh> +1
22:23:47 <Karen> Dirk: A way to fold in origins into the signature that the key producers that is not under the control of the application
22:23:59 <Karen> …add context by user agent
22:24:03 <Karen> Harry: or an example
22:24:31 <Karen> 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
22:24:39 <Karen> …is it simple manner of identification
22:24:47 <Karen> …meaning for payment applications like what Apple has done
22:24:50 <Karen> …would it apply to web
22:24:59 <Karen> …some test use cases we can list that we can ideally support
22:25:13 <Karen> …amount of work we do to make that happen depends upon how exhaustive the list is
22:25:25 <Karen> KarenLu: I am going to mention an obvious point
22:25:47 <Karen> …in current Web crypto charter, the hardware token is out of scope
22:25:52 <Karen> …so we need to make this explicit
22:26:11 <Karen> Dirk: a way to say that usage of key should be tied to local auth gesture
22:26:18 <Karen> Philip: Why or is that optional?
22:26:30 <Karen> …I understand the request, but I think this should be an option
22:26:41 <Karen> Dirk: yes, we are putting up what options we would like to see
22:26:50 <Karen> Wendy: Scope sets limit of things we can consider
22:26:58 <Karen> …none is deemed madatory to use
22:27:12 <Karen> Detlef: should be aligned to access control model, might be extension of current model
22:27:24 <Karen> …such that it's possible to control which web app sees which tokens
22:27:29 <engelke> +1 use something like CORS model for key access
22:27:43 <Karen> …@ maybe too restrictive and CORS might not be sufficient
22:27:53 <Karen> Juan: certificate metadata
22:27:59 <Karen> …provenance, attestation
22:28:20 <Karen> Harry: Are we missing anything that is really big that we may want to standardize
22:28:44 <Karen> Colin: anonymous credential tech discussion; different aspects of payments; hardware tokens
22:28:45 <harry> q?
22:28:51 <Karen> …I'm going to throw out an interest of mine
22:28:52 <harry> ack  harry
22:29:01 <Karen> …peer to peer distributed or payment technology
22:29:04 <Karen> Harry: anyone else
22:29:23 <Karen> Davit: I think this might be too detailed, but the ability to generate specially crafted
22:29:32 <Karen> …current web crypto defines sign function
22:29:38 <Karen> …which generates
22:29:51 <Karen> ….ability to generate some specially crafted signatures would be nice to have
22:30:03 <Karen> …we have call it attested signature
22:30:16 <Karen> Peter: I would suggest
22:30:38 <Karen> …since one of goals is to bring hardware tokens in scope, that we identify some of them explicitly
22:30:52 <Karen> …there should be a work item to go maintain a list so we know what we are working against
22:30:54 <Karen> …a list
22:31:06 <Karen> …if TE people want to propose stuff
22:31:14 <Karen> Detlef: would need to be a temporary list
22:31:30 <Karen> …strongly recommend a mechanism that would support arbitrary tokens
22:31:35 <Karen> Siva; Maybe representatiion
22:31:44 <Karen> Peter; current hints of what people want to be looking at
22:31:53 <Karen> KarenLu: Origines
22:31:55 <Karen> s/origins
22:32:14 <Karen> Sean: If we are talking hardware tokens, we are talking middleware as part of the box
22:32:25 <Karen> …does deployment come into this? How can I deploy middleware?
22:32:33 <Karen> Harry: middleware is out of scope
22:32:47 <schuki> q+
22:32:51 <Karen> @: should be some guidelines or best practices regarding middleware
22:32:59 <Karen> Harry: Guidelines are fine
22:33:12 <virginie> q?
22:33:32 <Karen> Natasha: Interaction with other standards bodies that have interaction with the lower stuff?
22:33:37 <schuki> q-
22:33:38 <Karen> Harry: We will have a list of liaisons
22:33:45 <Karen> …groups will get notified
22:33:50 <Karen> …anything else?
22:34:19 <Karen> …goal is not to make list bigger but smaller; but really look at what's missing; what could be standardized from a tech level
22:34:25 <Karen> …Next do some hand showing
22:34:39 <Karen> ….W3C has an open, multi-stakeholder process
22:34:53 <Karen> …if you would like to see this happen and don't have cycles to contribute, don't raise your hand
22:34:59 <rbarnes> https://en.wikipedia.org/wiki/Occupy_movement_hand_signals
22:35:01 <Karen> …we'll do that round first
22:35:07 <virginie> gym exercice for all ....
22:35:10 <Karen> ..the we will reflect on the results of that
22:35:16 <Karen> …we'll keep the work items out of this phase
22:35:36 <Karen> …There are two distinct kinds of APIs; high vs low level
22:35:41 <Karen> …let's do high level first
22:35:46 <Karen> …Simple, two-factor API
22:35:46 <solar> especially apt: http://www.ibiblio.org/hhalpin/harry-small.jpg
22:35:59 <Karen> …around an authenticator; do people like that idea?
22:36:04 <Karen> …no one likes that idea?
22:36:21 <Karen> …use U2F as an example; higher level traction
22:36:29 <Karen> …is that what people think we should standardize next
22:36:36 <Karen> Colin: what is the alternative
22:36:48 <Karen> @: Does not imply we would take concepts
22:36:57 <Karen> …similar to web crypto and support those?
22:37:08 <Karen> Harry: We'll go to web crypto next; we are asking higher level first
22:37:17 <virginie> s/@/israelh
22:37:25 <Karen> Dirk: trying to understand question
22:37:36 <Karen> …are we trying to understand API for two factor systems and nothing else?
22:37:51 <Karen> Harry: not nec nothing else, but do we want a higher level abstraction web crypto API
22:37:58 <Karen> …low level is generate, retrieve keys
22:38:02 <Karen> …make a simple API
22:38:08 <Karen> …you could fill with right level bits
22:38:12 <virginie> explanation : if you raise your hands, basically, it means you are ready to give effort/workload/contribution to that topic
22:38:18 <Karen> @: These words are red herring
22:38:31 <Karen> …many people in this room have been saying it makes sense to have a higher level API
22:38:37 <Karen> …next step i show to stage it
22:38:45 <Karen> …ask a question about…authentication in that space
22:38:58 <Karen> …that might be a better question to ask than U2F which is very narrow question to ask
22:39:15 <Karen> Harry: How many people we should have a higher level API, higher than the current web crypto spec?
22:39:25 <Karen> …let me count, and keep hands up
22:39:37 <virginie> question :is authentication a high level api ?
22:39:38 <Karen> [Harry counts]
22:39:50 <Karen> Harry: this is a very high level PI
22:40:00 <Karen> [about 14]
22:40:19 <israelh> +1
22:40:20 <Karen> …Now we'll go down to the lower level and particular features in order, which are completely arbitrary
22:40:27 <Karen> ….Discovery
22:40:33 <Karen> [hands: 13]
22:40:38 <Karen> s/13/14
22:40:43 <Karen> …Key Discovery
22:40:48 <israelh> -1 on the high level PI and +1 on discovery
22:40:53 <Karen> [hands: 25+]
22:40:56 <Karen> …really popular
22:41:01 <Karen> …somewhat vaguely stated
22:41:05 <Karen> …Device Discovery
22:41:44 <Karen> Harry: right now you cannot discover keys at all
22:42:11 <Karen> Siva: there may be several devices with multiple keys that need to be discovered
22:42:16 <Karen> Harry: I know it's a bit fuzzy
22:42:53 <Karen> …maybe generate a key; crypto function on device; a bit different from key discovery
22:43:14 <Karen> [hands: 10]
22:43:29 <colin_g> how about tiny numbers
22:43:32 <Karen> Harry: Certificate metadata
22:43:38 <Karen> ..having some of that baked into API
22:43:43 <Karen> [jhands: 8]
22:43:57 <Karen> Harry: putting hardware tokesn from out of scope into the charter
22:44:10 <Karen> [30+]
22:44:21 <Karen> …Attestation of provenance
22:44:38 <Karen> [hands: 20]
22:45:13 <Karen> …Discovery mechanism..with poss extension of CORS
22:45:16 <Karen> [hands: ]
22:45:27 <Karen> …Persistent key storage
22:45:30 <Karen> [hands: 12]
22:45:40 <Karen> …User owned keys separate from origin owned keys
22:45:47 <Karen> [hands: 14]
22:45:57 <Karen> …multi-origin support in some large sense
22:46:24 <Karen> [hands: 16+]
22:46:40 <Karen> …System key discovery…operating level system keys not necessarily in hardware token
22:46:48 <Karen> [hands: @]
22:46:56 <Karen> …Origins of signatures
22:47:03 <Karen> [hands: 13]
22:47:08 <vkata> Bake in context information into signatures, such as origin
22:47:15 <Karen> …Local user authentication gesture; binding with key usage
22:47:28 <Karen> [hands: 27]
22:47:34 <Karen> …Anonymous credntials
22:47:41 <Karen> [hands: 8-9]
22:48:04 <Karen> …We'll need to take a break shortly and then discuss the results of these polls
22:48:14 <Karen> …Seems like there is moderate support
22:48:24 <Karen> …and high support in green
22:48:32 <Karen> …most popular is putting hardware tokens in scope
22:48:36 <Karen> …that's a no-brainer
22:48:52 <Karen> Mike: Make a clarifying comment
22:49:05 <Karen> …point out that you cannot do that without key discovery on the hardware tokens
22:49:15 <Karen> @: and you cannot do that without device discovery
22:49:22 <Karen> Harry: getting a feeling for directions
22:49:40 <Karen> …some feeling that CORS and device, key discovery are related and popular
22:49:46 <Karen> …and having that bound to signatures is popular
22:49:49 <Karen> …and attestation
22:49:53 <Karen> …also popular
22:50:00 <Karen> …then a bunch of things that are semi-popular
22:50:11 <Karen> …High-level API; algorithm discovery
22:50:11 <virginie> s/@/Philip
22:50:16 <Karen> …BigNum....well
22:50:19 <Karen> …put up for debate
22:50:31 <Karen> …multi-origin support is moderately popular
22:50:36 <Karen> …access control model
22:50:43 <Karen> …variation of signature context; subtext
22:50:47 <Karen> …moderately popular
22:50:51 <Karen> …11 and above
22:50:57 <Karen> …I would say that what we might want to do
22:51:03 <Karen> …I don't want to end here, but take a break soon
22:51:08 <Karen> …we should discuss these things in some detail
22:51:23 <Karen> …The low-level is a no-brainer, even though there are details here
22:51:46 <Karen> …Ask if there are any real objections, or clarifying comments
22:52:04 <Karen> Mike: the local authentication gesture, in order to enable the use of the key
22:52:29 <Karen> …is not something that there is an APi for at all; platform functionality, so may not be in scope
22:52:37 <Karen> @: be comfortable with verification
22:52:43 <Karen> Detlef: I don't agree
22:52:55 <Karen> …if we understand verification of a concept, there may be more complexitiy
22:52:59 <virginie> s/@/bhill2
22:53:15 <Karen> …local user authentication; maybe a PIN or biometrics is just one part of a more sophisticated protocol
22:53:24 <Karen> …we should understand authentication as a generic concept
22:53:29 <Karen> …then user authentication is one special case
22:53:38 <Karen> …if we understand authentication generically
22:53:48 <colin_g> q+
22:53:59 <Karen> Juan: gain access to key, seems in scope …for a trusted key entry
22:54:05 <Karen> @: need a pass
22:54:11 <Karen> …allow interactions by UA
22:54:17 <Karen> …we don't expect those
22:54:29 <Karen> Juan: yes, but we do give guidance
22:54:30 <virginie> reminder to people talking : give your name for the scribe :)
22:54:37 <Karen> …as to what is appropriate and inappropriate
22:54:48 <Karen> @: So would be optional…what is supported?
22:54:49 <virginie> s/@/juan
22:54:55 <Karen> …seems to be a distinction
22:55:02 <Karen> …what user authentication should take
22:55:09 <virginie> oups... s/@/israel
22:55:09 <Karen> @: My point is if you say user interaction
22:55:18 <virginie> s/@/israelh
22:55:21 <Karen> Israel: That is not an API like what Mike was saying earlier
22:55:30 <Karen> …implying leakage of info into the web page
22:55:32 <harry> q?
22:55:54 <Karen> Dirk: I am not saying a call to the API to enter fingerprint
22:56:02 <Karen> …when you create a key…hey browser make me a key
22:56:05 <rbarnes> point of order: it is not appropriate to discuss charter text today.  there is not any consensus on the problem to be solved.
22:56:16 <Karen> …then you use the key the call to use that key is like call that does not require the user gesture
22:56:18 <engelke> +1 Dirk
22:56:20 <Karen> …does that make sense?
22:56:25 <Karen> …answer is yes and no
22:56:28 <Karen> …same sign call
22:56:37 <Karen> …but say that particular to sign something and it triggers something
22:56:41 <Karen> Harry: we have a lot of hands up
22:56:44 <Karen> …quick question
22:56:54 <Karen> …we will close queue now
22:56:59 <Karen> …Colin, Detlef and KarenLu
22:57:02 <wseltzer> zakim, close queue
22:57:02 <Zakim> ok, wseltzer, the speaker queue is closed
22:57:05 <Karen> …then take a coffee break
22:57:16 <Karen> …how many people want to stay for the chartering process?
22:57:25 <Karen> …If you don't want to stay, you are free to go
22:57:37 <Karen> …we'll use a mailing list
22:57:50 <Karen> …to continue to discuss and clarify after the break
22:57:58 <Karen> Siva: Who is on the mailing list?
22:58:02 <Karen> …is it the WG?
22:58:05 <virginie> discussion can happen on the web security IG here : http://lists.w3.org/Archives/Public/public-web-security/
22:58:13 <Karen> Harry: Everyone will get an email with the name of the WG mailing list and you can join the list
22:58:24 <Karen> ColinG: clarification to add
22:58:34 <Karen> …I wanted to suggest on BigNum that we add some points of clarification
22:58:46 <Karen> …one the discussion of anonymous credentials that you had suggested
22:58:59 <Karen> …and another one may be the effects of metadata within context of metadata
22:59:06 <Karen> Detlef: I would like ask Dirk
22:59:14 <Karen> …to clarify this issue
22:59:29 <Karen> …if you generate a key, will certain access control conditions
22:59:32 <Karen> …a question of policy
22:59:38 <Karen> …is it being treated generically
22:59:41 <public_screen> We'll notify the attendees list where discussions of chartering will occur.
22:59:42 <Karen> …it's very easy
22:59:50 <Karen> …standardized in ISO 17860
23:00:10 <Karen> Dirk: I don't like the words "arbitralily complex"
23:00:21 <Karen> KarenLu: question related to level of assurance
23:00:26 <Karen> Harry: let's return in 15-20 minutes
23:00:30 <Karen> rrsagent, make minutes
23:00:30 <RRSAgent> I have made the request to generate http://www.w3.org/2014/09/11-crypto-minutes.html Karen
23:18:57 <virginie> Note : the show of hand result is now captured under https://www.w3.org/Security/wiki/IG/webcryptonext_workshop
23:20:20 <KarenOD> KarenOD has joined #crypto
23:29:56 <nvdbleek> nvdbleek has joined #crypto
23:33:53 <virginie> harry : there will be further discussion on the mailing list http://lists.w3.org/Archives/Public/public-web-security/
23:33:59 <colin_g> yay
23:34:20 <virginie> harry : the discussion of the charter will be done here, and anyone can join
23:34:47 <virginie> wseltzer : we have your email address, but just in case, if you have any doubt, please send it to harry and/or wselter
23:35:14 <virginie> harry : we should clarify what people means with respect to technical feature
23:35:23 <virginie> harry : queue is open to questions
23:36:07 <virginie> please note that the show of hand has been captured on the wiki https://www.w3.org/Security/wiki/IG/webcryptonext_workshop
23:36:33 <virginie> harry : we need to clarify some of the features
23:37:09 <Ullrich> Ullrich has joined #crypto
23:37:31 <virginie> wseltzer : there will be a mail follow up, please read the minutes
23:37:34 <rbarnes> rbarnes has joined #crypto
23:37:50 <virginie> wseltzer : and we will have a review of the charter, for the next level of details
23:38:21 <virginie> wseltzer : eg what does it mean to have hardware token in scope ? what precise definition, what we can do with hardware token ?
23:38:26 <Cathy> Cathy has joined #crypto
23:38:35 <virginie> wseltzer : what we mean by discovery ....
23:39:02 <virginie> wseltzer :what sort of permission request to we need to get their agreeemnt, how do expose this to user/browser/services
23:39:14 <virginie> wseltzer : are there any holes missing ?
23:39:25 <virginie> wseltzer : are there any question we missed ?
23:39:37 <AdrianC> Q+
23:39:38 <virginie> wseltzer : any process of W3C quetsion ?
23:39:43 <public_screen> zakim, open queue
23:39:43 <Zakim> ok, public_screen, the speaker queue is open
23:40:26 <virginie> adrianC : to karen, if we want to bring back hardware token in the discussion, a starting point is the secure element api on github
23:40:52 <virginie> adrianC : ... is that any other WG discussin it ?
23:41:14 <virginie> KarenLu : it was discussed in sysapp wg, but it is unlikely they will follow up on it
23:41:28 <virginie> adrianC : can we take it in there ?
23:41:49 <virginie> KarenLu : i think it is prbably a low level API, but it could be a separate WG
23:41:56 <wseltzer> q+ bhill
23:42:08 <wseltzer> q- colin_g
23:42:17 <virginie> siva : if we extend the access to se to be a box, we @@
23:42:41 <virginie> harry : patent commitment are hard
23:42:54 <virginie> harry : we dont like strtaing WG unless really necessary
23:43:19 <wseltzer> ACTION: wseltzer to review SysApps Secure Element discussion
23:43:19 <trackbot> Created ACTION-147 - Review sysapps secure element discussion [on Wendy Seltzer - due 2014-09-18].
23:43:25 <colin_g> Radiation
23:43:29 <virginie> harry : we need to know why it died into sysapp wg, because it is bad design, badly writtent, an not be understood
23:43:42 <colin_g> Radiation will not cure app issues
23:43:48 <virginie> harry : moving a feature from one wg to another may not be a good practise
23:43:55 <wseltzer> q+ Axel
23:44:00 <wseltzer> q- bhill
23:44:17 <AxelNennker> AxelNennker has joined #crypto
23:44:18 <virginie> bhill2 : reminds that it is not a W3C secure api , it is a proporietray contribution
23:44:38 <virginie> bhill2 : and it is noot related to how the web work
23:44:43 <wseltzer> ack Axel
23:44:51 <wseltzer> q+ Siva, Adrian
23:45:07 <martin_paljak> q+
23:45:18 <virginie> axel : wg contributors told me that there is an API that arbitraty javascript shouod access to
23:45:39 <wseltzer> s/SysApps secure element/unoficcial secure element/
23:45:41 <virginie> axel : on the other hanf, mozilla FF will implement it, binded with NFC use case
23:45:48 <virginie> s/hanf/hand
23:46:09 <public_screen> q- s/hanf/
23:46:10 <virginie> axel : the impelmentation will be very similar to what gemalto has proposed in their API
23:46:28 <wseltzer> s/implementation/implementation in FirefoxOS/
23:46:38 <virginie> axel : maybe it is not a good idea to expose it, but we should standardize smthg to avoid fragmented impelmentation
23:46:49 <wseltzer> ack siva
23:46:52 <virginie> axel : it does not have to be in web crypto, but it has to exist
23:47:29 <wseltzer> q+
23:47:41 <virginie> siva, : assuming this becomes a defined working group, it has to get built somewhere, in W3C, or somewhere else
23:47:56 <virginie> siva : we see that hardware token is in scope
23:48:16 <virginie> siva : W3C could decide it will be design here, or elsewhere
23:48:23 <wseltzer> ack next
23:49:07 <virginie> 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
23:49:20 <virginie> adrianC : abd after we will see what the web industry will do it
23:49:38 <virginie> adrianC : or we will have 20 impelmentations, and we will see if it is ok
23:49:52 <virginie> bhill2 : if it falls into the scope, i'll bring my ideas here
23:50:07 <virginie> french scribe needs help....
23:50:32 <virginie> martin : practical question , what are the next steps to progress ?
23:50:39 <wseltzer> ack next
23:51:02 <virginie> martin : from a organization point of view, there are a lots of dependency, so how do we proceed to manage the overlapping area
23:51:31 <virginie> martin : we have a lots of plugins, and we would like to know when we will have to upgrade it
23:51:53 <virginie> martin : we have right now resosurces that are spent to that, and we need to speed up the process
23:52:01 <virginie> martin : what are the next steps ?
23:52:04 <virginie> q?
23:52:33 <bhill2> https://github.com/opoto/secure-element/issues/5
23:52:48 <virginie> wseltzer : we have to work on forming consensus, iterating on the draft, call for impelmentation, do testing, making sure there independant implementations
23:52:49 <bhill2> this is a bug I opened against the spec in April
23:52:54 <bhill2> it was closed without really fixing it
23:53:25 <herve> herve has joined #crypto
23:53:27 <virginie> wseltzer : our aim is to have a process that move quickly through those steps
23:53:47 <siva> siva has joined #crypto
23:53:52 <siva> q+
23:53:54 <virginie> wseltzer : our goal is to draft a charter proposal in the next month or 6 weeks for discusson
23:54:07 <harry> harry has joined #crypto
23:54:10 <colin_g> q+
23:54:14 <virginie> wselzer : the next web crypto wg will be during the TPAC week on the 27th of oct
23:54:16 <siva> siva has joined #crypto
23:54:30 <harry> http://www.w3.org/2014/11/TPAC/
23:54:31 <virginie> s/27th/30th
23:54:43 <harry> Note that you have to register
23:54:44 <virginie> wselzer : the next web crypto wg will be during the TPAC week on the 30th of oct
23:55:05 <virginie> detail about the TPAC weel http://www.w3.org/2014/11/TPAC/
23:55:29 <virginie> harry : you need to register to TPAC, it is santa clarar
23:55:41 <virginie> s/clarar/clara
23:56:18 <virginie> harry : 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
23:56:36 <virginie> martin : me, as a non member I will be registring, what else can I do ?
23:57:11 <virginie> wseltzer : the wg gets down to discussing the proposed recommendations, and conversation is lead by members
23:57:21 <virginie> wseltzer : so your company has to be member
23:57:34 <virginie> wseltzer : but we do our work in public in open comment
23:57:37 <virginie> q+
23:58:06 <harry> q?
23:58:11 <virginie> wseltzer : we need to make sure that all comments are taken into acocunt, but also that the contributions are made under the patent free ip policy
23:58:11 <harry> ack wseltzer
23:58:20 <virginie> s/ip/intellectual prpoerty
23:58:30 <harry> http://www.w3.org/20/
23:58:36 <virginie> s/prpoerty/property
23:58:41 <harry> Oct 29th is 25th anniversary of the Web with Tim Berners-Lee
23:58:58 <harry> (i.e. inventor of Web and W3C Director/Founder)
23:59:08 <virginie> siva : what process for getting something like the access to se in W3C ?
23:59:16 <virginie> siva : what do we need to do ?
23:59:52 <virginie> 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