05:35:54 <RRSAgent> RRSAgent has joined #websec
05:35:54 <RRSAgent> logging to http://www.w3.org/2015/10/28-websec-irc
05:36:00 <kaoru> kaoru has joined #websec
05:36:01 <kiyoung> kiyoung has joined #websec
05:36:03 <keiji> keiji has joined #websec
05:36:05 <kura> kura has joined #websec
05:36:09 <kodonog> kodonog has joined #websec
05:36:20 <cscho> cscho has joined #websec
05:36:34 <JeffH> JeffH has joined #websec
05:36:52 <a12u> a12u has joined #websec
05:37:00 <daisuke> daisuke has joined #websec
05:37:09 <kinjim> kinjim has joined #websec
05:37:10 <kaoru> scribenick: kaoru
05:37:22 <kpfleming> kpfleming has joined #websec
05:37:25 <drogersuk> drogersuk has joined #websec
05:37:25 <rigo> rigo has joined #websec
05:37:44 <colin> colin has joined #websec
05:37:45 <kaoru> Wendy: Two new WG on security, Web authentication and Hardware based authentication.
05:37:46 <cscho> cscho has joined #websec
05:38:08 <kaoru> Wendy: Point we are is draft charters and collect feedbacks.
05:38:38 <kaoru> ... FIDO alliance and hardware integration for discussion.
05:38:57 <rigo> Charter for Hardware Security: http://w3c.github.io/websec/hasec-charter.html
05:39:53 <mdadas_> mdadas_ has joined #websec
05:40:33 <dbaron> dbaron has joined #websec
05:40:37 <Zakim> Zakim has joined #websec
05:40:41 <schuki> schuki has joined #websec
05:40:48 <a12u> a12u has joined #websec
05:41:05 <kaoru> Wendy: We have a couple of draft charters.
05:41:36 <Min> Min has joined #websec
05:41:43 <a12u> a12u has joined #websec
05:42:05 <drogersuk> drogersuk has joined #websec
05:43:48 <a12u> a12u has joined #websec
05:43:51 <kaoru> Wendy: This is public.  We are going to invite developers and implementers to vote for or against the charter.
05:44:27 <rigo> wseltzer: on chartering, explains the making of charter, drafting and then presenting to AC
05:44:34 <rigo> ... currently chartering in early stage
05:44:34 <kaoru> ... We are at pre-review stage here, gather inputs, and wait for needs.
05:44:40 <dka> dka has joined #websec
05:45:07 <kaoru> Jeff: Two goals are API and attestation formats for web applications.
05:45:13 <timbl> timbl has joined #websec
05:45:14 <dka> present+ Dan Appelquist
05:45:18 <a12u> a12u has joined #websec
05:45:33 <a12u> a12u has joined #websec
05:45:43 <kpfleming> present+ Kevin P. Fleming
05:45:52 <rigo> JeffH: definition of API for authentication. Gathering input. WG will not ground zero. Industry has already developed things over the years
05:46:00 <timbl> RRSAgent, pointer?
05:46:00 <RRSAgent> See http://www.w3.org/2015/10/28-websec-irc#T05-46-00
05:46:14 <kaoru> ... WG is not started from ground-zero.  Industry specs dat FIDO alliance did is incorporated.
05:46:21 <rigo>  ... are things in FIDO that do this thing. But to make it ubiquitous, have to bring it here
05:46:23 <wseltzer> q?
05:46:28 <a12u> a12u has joined #websec
05:46:49 <bhill2> bhill2 has joined #websec
05:47:02 <kaoru> Jeff: Here's FIDO 2.0
05:47:11 <ymasao> ymasao has joined #websec
05:47:45 <wseltzer> q?
05:47:47 <a12u> a12u has joined #websec
05:48:07 <Min_> Min_ has joined #websec
05:48:11 <yaso> yaso has joined #websec
05:48:20 <kaoru> ... From three or four years trying to gather critical mass.
05:49:08 <kaoru> ... Basic mission is to change authentication online by mechanisms supplanting password.
05:49:32 <wseltzer> https://fidoalliance.org/wp-content/uploads/FIDO_Alliance_-_Membership_Agreement.pdf
05:49:38 <kaoru> ... and submitting specs for formal standardization, W3C and IETF.
05:50:11 <kaoru> ... Overall goal is to nurture ecosystem.  FIDO Alliance doesn't ship products.
05:50:48 <kaoru> ...  Shared user secrets are often exploited.  Tons of issues a week about stolen credentials.
05:51:08 <kaoru> ... One-time codes back via SMS is still phishable.
05:52:00 <kaoru> ... Major Industry trend is mobile devices or laptop to pins and then simpler stronger user verifications on personal devices.
05:52:04 <bhill2> lots of similarities between hoba and fido
05:52:27 <kaoru> ...  Leverage local device auth to remote
05:53:09 <kaoru> ... Paypal and docomo has enough users.  Google and twitter support second-factor.
05:54:11 <kaoru> ... UAF is verified on biometrics.  U2F still requires passwords but prevent phishing.
05:54:35 <kaoru> ... Scalable attacks are very difficult.  They need to steal physical devices.
05:55:20 <kaoru> ... FIDO ready program started Apr 2014.  FIDO 1.0 Dec 2014
05:55:28 <barryleiba> q+
05:55:44 <kaoru> ... Privacy and security desgin is the primary principle.
05:56:41 <kaoru> ...  No 3rd party in the protocol, no secrets on the server side, biometric data stays on device, no linkability between Services/Accounts.
05:56:43 <kpfleming> s/desgin/design
05:58:09 <kaoru> ... FIDO registration starts just like current sign-up.  User approval allocates a new key slot and create key pair.  Public key is registered to the server.
05:58:28 <wseltzer> JeffH: q?
05:58:32 <wseltzer> q?
05:58:41 <wseltzer> s/JeffH: q?//
05:58:46 <kaoru> ... On login, server sends the challenge and the device signs it.  The server can verify with the device's public key.
05:59:28 <kaoru> ... Decouple local auth modality from auth protocol.  People can use different biometrics without changing the protocol.
06:00:02 <kaoru> ... What is missing: client-side is not ubiquitous.  Web platform, android, windows, etc.
06:00:08 <wseltzer> JeffH: Ideally, all platforms should have built-in API for strong auth
06:00:41 <kaoru> ... To accelerate adoption, give incentives to RP that all devices work, etc.
06:01:29 <barryleiba> barryleiba has joined #websec
06:01:38 <kaoru> ... What FIDO is doing now: crafting standards for future built-ins, future APIs, standardized model on OS level.
06:01:51 <wseltzer> ack barryleiba
06:02:18 <wseltzer> JeffH: Bringing Web API to W3C
06:02:26 <kaoru> Barry: httpauth WG come up with better solutions but browser vendors seems not interested.  HOBA
06:02:39 <timbl> q+
06:02:49 <kaoru> Jeff: Difference is business perspective.
06:02:50 <bhill2> fido wire protocol is almost exactly like HOBA, but then adds a crypto binding layer that allows device-type attestation
06:03:33 <timbl> q+ to ask about what form the user identifier takes, and about matching diff levels of autherntication with authorization
06:03:37 <kaoru> @: JavaScript API to test under the control of the web site.  HTTP header is what JS find difficult to control.
06:03:57 <barryleiba> q?
06:04:11 <kaoru> Jeff: Amazon adds security key and Google Chrome can use it.
06:04:20 <wseltzer> s/adds/offers a/
06:04:39 <timbl> q+ timbl2 to wonder abouhow you trust a key you buy on amazon
06:05:15 <wseltzer> ack timbl
06:05:15 <Zakim> timbl, you wanted to ask about what form the user identifier takes, and about matching diff levels of autherntication with authorization
06:05:15 <kaoru> Brad: Metadata describing device types, level of assurance, etc. supports how the user experience that device offers.
06:06:08 <kaoru> timbl: @
06:06:15 <kaoru> Jeff: You use the user accout.
06:06:19 <annevk> annevk has joined #websec
06:06:24 <wseltzer> https://www.w3.org/TR/credential-management-1/
06:06:27 <annevk> Is there any integration with <form>?
06:06:37 <rigo> xforms?
06:06:48 <annevk> sure
06:06:57 <bhill2> annevk: no, it's challenge-response
06:06:59 <kaoru> ... Key pair is allocated and public key is returned.  Credential management and authenticator works challenge/signature based.
06:07:03 <wseltzer> ack timbl
06:07:03 <Zakim> timbl2, you wanted to wonder abouhow you trust a key you buy on amazon
06:07:15 <bhill2> JS API
06:07:26 <annevk> bhill2: mostly thinking about password managers being able to prompt the user with this stuff and handle automatic submission after the token is provided
06:07:36 <kaoru> timbl: You separate authentication from authorization?
06:08:19 <wseltzer> JeffH: separate modality of user interaction from underlying protocol
06:08:21 <kaoru> Jeff: No.  Separating user verification on user modality and auth protocol.
06:08:55 <wseltzer> q+ virginie
06:09:03 <bhill2> annevk: right now the apis are imperative, much like the new credential manager apis are
06:09:07 <annevk> bhill2: and this key thing is still per-origin right?
06:09:14 <annevk> bhill2: not a big fan of those either
06:09:26 <bhill2> new keys created per-origin, and per-account-identifier
06:09:45 <annevk> ah, didn't know about the latter
06:10:04 <bhill2> you can use the same fido device to authenticate unlinkably to two email accounts at the same provider, e.g.
06:10:10 <kaoru> Jeff: FIDO certification program gives trust to the devices.
06:10:21 <annevk> yeah makes sense
06:10:26 <kaoru> timbl: Manufacturer reputation based.
06:11:11 <kaoru> Jeff: This key works only with my employer because it's synchronized with the company server.
06:11:25 <wseltzer> s/This key/RSA key/
06:11:32 <kaoru> ... But the key from Amazon works with any sites that support the mechanism
06:11:52 <dka> q+
06:12:46 <frodek1> frodek1 has joined #websec
06:13:08 <frodek1> q+
06:13:22 <wseltzer> ack virginie
06:13:35 <kaoru> Virginie: Vender perspective of FIDO tokens are same kind of security that banking provide to account holders.
06:13:53 <wseltzer> zakim, close queue
06:13:53 <Zakim> ok, wseltzer, the speaker queue is closed
06:14:02 <a12u> a12u has joined #websec
06:14:35 <kaoru> ... Consumer take a choice of a key and service providers set a bar of the security level.
06:15:51 <kaoru> timbl: How bank believe that the stamp is done by the account holder?
06:16:01 <kaoru> @: Because it's part of the protocol.
06:16:13 <kpfleming> s/@/kpfleming
06:16:47 <a12u> a12u has joined #websec
06:17:16 <kaoru> Jeff: Secret is kept in the device; what's in the database is public key.
06:17:17 <annevk> keygen!
06:17:21 <wseltzer> ack next
06:18:20 <kaoru> @: What is the user experience enabled?
06:18:26 <a12u> a12u has joined #websec
06:18:34 <kpfleming> s/@/dka
06:19:30 <rigo> meaning, get a new thumb if you lose your phone
06:19:53 <kaoru> Natasha: Automatically logging-in is not very safe because they do nothing.  Challenge response is important.
06:20:33 <kaoru> bhill2: Various device can be used in markets.
06:20:53 <timbl> timbl has joined #websec
06:21:23 <wseltzer> ack frodek1
06:21:28 <wseltzer> ack frode
06:21:38 <kaoru> Judy: FIDO only support local devices.  Remote user identifications?
06:21:48 <kaoru> Jeff: That should be handled with other stack like TLS.
06:21:51 <a12u> a12u has joined #websec
06:22:06 <kaoru> Judy: FIDO supports only on-line with servers.  How about off-line?
06:22:31 <rigo> 8min left for http://w3c.github.io/websec/hasec-charter.html
06:23:17 <kaoru> Jeff: User verification is done locally. It changes nothing at local.  It leverages local unlock.
06:23:42 <kinjim> kinjim has joined #websec
06:23:46 <a12u> a12u has joined #websec
06:24:15 <timbl> s/stamp is done by the account holder/key has come from a secure hardware device/
06:24:23 <kaoru> Judy: Alibaba has use cases for off-line authentications.
06:24:57 <a12u> a12u has joined #websec
06:25:26 <kaoru> bhill2: Challenge respose protocol requires online
06:25:42 <a12u> a12u has joined #websec
06:25:55 <bhill2> you can have multiple accounts associated with one device
06:25:57 <rigo> timbl: question about multiple identities on one device in FIDO
06:26:04 <bhill2> or, for cheap external devices like U2F you could use multiple devices
06:26:22 <bhill2> but that kind of user experience is left to the competitive client-side implementation
06:26:40 <kaoru> Virginie: Hardware security WG
06:26:46 <a12u> a12u has joined #websec
06:26:54 <bhill2> some devices might provide a rich user chooser experience, others might just always use, e.g. one account-per-fingerprint
06:27:12 <timbl> Have the folsk thought at the UI level about how to allow the user to handle multiple personas and make sure they are not useing the wrong one accidentally, how to switch persona in  laogged in sesssion, etc.
06:27:49 <annevk> bhill2: why does the challenge have to come over the network?
06:28:05 <kpfleming> where else would it come from?
06:28:09 <bhill2> it doesn't necessarily
06:28:29 <annevk> I guess that's what you were hinting at, that you could store a couple for offline usage
06:28:41 <rigo> enabling services can be exposed via an API to javascript
06:28:44 <bhill2> I guess you could cache a few, or even choose a well-known challenge to represent "offline"
06:28:50 <kaoru> ... Bring Secure element and trusted execution elements to web applications.
06:28:57 <bhill2> and apply different heuristics to deal with replay
06:28:57 <a12u> a12u has joined #websec
06:29:21 <a12u> a12u has joined #websec
06:29:33 <judy-zhu> judy-zhu has joined #websec
06:30:03 <bhill2> but it is about a challenge/response model, not about defining what it means to recognize a user locally - that's deliberately abstracted away
06:30:20 <rigo> Virginie: we have already some supporters like Orange, Deutsche Telekom, Intel etc
06:30:23 <annevk> kpfleming: looked into service workers?
06:30:34 <kpfleming> annevk: no, i have not, sorry
06:30:40 <annevk> kpfleming: that might help
06:30:41 <kaoru> Virginie: To help web apps discovery of secure tokens.
06:30:51 <kpfleming> annevk: thanks
06:31:04 <kaoru> ... Extending WebCrypto API and incorporate Hardware secure tokens.
06:31:07 <dbaron> dbaron has joined #websec
06:31:11 <rigo> API will make available that secure environment to web application
06:31:13 <barryleiba> barryleiba has left #websec
06:31:18 <rigo>  ... secure workers e.g
06:31:49 <kpfleming> zakim, open queue
06:31:49 <Zakim> ok, kpfleming, the speaker queue is open
06:31:58 <kaoru> ...  Crypto APIs, Storage API, IO, and citizen identities
06:32:36 <kaoru> How to reuse citizen identities to manage online identities.
06:32:55 <kaoru> s/How/... How/
06:33:30 <a12u> a12u has joined #websec
06:33:33 <annevk> rigo: they might get terminated then, but that makes the whole thing sound rather crude :/
06:33:37 <kaoru> ... We have a lot of deliverables.  We need to prioritize these.
06:33:44 <judy-zhu> q+
06:33:55 <screen> screen has joined #websec
06:34:04 <screen> q?
06:34:17 <kaoru> David: Threats models are needed.
06:34:21 <Kepeng> Kepeng has joined #websec
06:34:24 <screen> q+ manu
06:34:28 <screen> ack dbaron
06:35:12 <kaoru> dbaron: Are there risks like super cookies to relate users across web sites?
06:35:36 <screen> q+ mnot
06:35:47 <screen> ack mnot
06:36:57 <screen> mnot: question about linkability: can my bank link me with other uses of the card?
06:39:05 <a12u> a12u has joined #websec
06:39:18 <screen> drogersuk: We need to think about the "apple bobbing" attack: where a site asks repeatedly for national IDs
06:39:22 <kaoru> rrsagent, draft minutes
06:39:22 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html kaoru
06:39:39 <screen> q?
06:40:07 <screen> drogersuk: principle of least privilege in information disclosure
06:40:17 <kaoru> scribenick: screen
06:40:31 <kaoru> scribenick: rigo
06:40:34 <kaoru> scribenick annevk
06:40:48 <a12u> a12u has joined #websec
06:41:59 <screen> judy-zhu: Did you consider regulatory requirements of countries?
06:43:03 <screen> virginie: in WebCrypto, we defined features, but can't override jurisdictional restrictions; not all may be available everywhere
06:43:11 <screen> s/all/all features/
06:43:35 <screen> ... browsers don't want to do profiling
06:43:53 <a12u> a12u has joined #websec
06:43:56 <screen> drogersuk: we'll have to look case-by-case, fight fragmentation
06:44:12 <screen> judy-zhu: this charter is not frozen
06:44:32 <screen> virginie: We'll take feedback for a few weeks, update the draft, then take to AC review
06:44:43 <kpfleming> q+
06:44:54 <screen> ... please send feedback over the next 3 weeks
06:45:02 <screen> ack judy-zhu
06:45:16 <a12u> a12u has joined #websec
06:45:26 <screen> https://w3c.github.io/websec/hasec-charter.html
06:46:10 <screen> zakim, close queue
06:46:10 <Zakim> ok, screen, the speaker queue is closed
06:46:10 <Kepeng> q+
06:46:15 <screen> ack manu
06:46:41 <screen> manu: it would be good to prioritize the deliverables
06:46:42 <a12u> a12u has joined #websec
06:46:53 <screen> virginie: already planning to do that
06:47:37 <screen> manu: is there linkability? it might be the answer is yes and we're ok with that, or with tokenization
06:47:50 <screen> virginie: derived credentials
06:48:34 <bhill2> I really wonder how many of these use cases would be better accomplished through OAuth-like patterns
06:48:55 <bhill2> I know the idea that the government today doesn't know everywhere I show my driver's license
06:48:56 <aalfar> aalfar has joined #websec
06:49:13 <a12u> a12u has joined #websec
06:49:29 <screen> manu: fundamental mode should be unlinkable
06:49:33 <bhill2> but I wonder how realistic that actually is for online scenarios - what places /really/ need my fully authenticated government identity and aren't/won't be compelled to disclose that they saw it back to the government in question anyway
06:50:22 <kaoru> rrsagent, draft minutes
06:50:22 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html kaoru
06:50:24 <bhill2> are the privacy side-effects of making such credentials widely available online worse than the centralization?
06:50:25 <screen> ack kpfleming
06:50:33 <dbaron> dbaron has joined #websec
06:50:38 <a12u> a12u has joined #websec
06:50:46 <rigo> bhill2: you do NOT make the credential available
06:51:00 <screen> kpfleming: unlike the crypto API, this spec isn't asking implementers to implement crypto, just implementing an API to plug in hardware with the crypto
06:51:07 <rigo> you can check its presence
06:51:09 <a12u> a12u has joined #websec
06:51:18 <rigo> in a given context
06:51:22 <screen> ... so ideally we won't have to worry too much about jurisdiction restrictions
06:51:40 <bhill2> rigo: but what kind of info can I get that's useful but not identifying?
06:51:59 <bhill2> a bank has a legal requirement to know exactly who I am
06:52:07 <bhill2> if that's the scenario we keep talking about
06:52:24 <rigo> I can show you how you can prove that you're over 18 without ever getting identity information triggered by this API
06:52:24 <bhill2> to e.g. establish a new account
06:52:44 <rigo> the new account is identifying you, not the hardware token
06:52:46 <rigo> coffee
06:52:54 <rigo> RRSAgent, please draft minutes
06:52:54 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html rigo
06:53:54 <screen> rrsagent, make minutes
06:53:54 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html screen
06:54:03 <screen> s/screen/wseltzer_screen/G
06:54:05 <screen> rrsagent, make minutes
06:54:05 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html screen
07:00:21 <keiji> keiji has joined #websec
07:02:42 <frodek> frodek has joined #websec
07:03:32 <frodek> frodek has joined #websec
07:06:17 <kpfleming> kpfleming has left #websec
07:08:23 <AndChat|694784> AndChat|694784 has joined #websec
07:08:43 <dka> dka has joined #websec
07:11:07 <dveditz> dveditz has joined #websec
07:13:46 <ymasao> ymasao has joined #websec
07:13:55 <ymasao_> ymasao_ has joined #websec
07:22:07 <kaoru> kaoru has joined #websec
07:22:52 <kaoru> rrsagent, draft minutes
07:22:52 <RRSAgent> I have made the request to generate http://www.w3.org/2015/10/28-websec-minutes.html kaoru
07:25:21 <kaoru> kaoru has left #websec
07:29:57 <dka> dka has joined #websec
07:49:54 <yaso> yaso has joined #websec
08:20:30 <frodek> frodek has joined #websec
08:22:13 <frodek> frodek has joined #websec
08:26:13 <AndChat|694784> AndChat|694784 has joined #websec
08:30:49 <keiji> keiji has joined #websec
08:40:12 <Melinda> Melinda has joined #websec
08:40:18 <Melinda> Melinda has left #websec
08:53:41 <Zakim> Zakim has left #websec
08:55:30 <frodek> frodek has joined #websec
09:45:52 <keiji> keiji has joined #websec
09:59:51 <keiji> keiji has joined #websec
11:06:35 <keiji> keiji has joined #websec
11:58:08 <timbl> timbl has joined #websec