SV_MEETING_TITLE -- 28 Oct 2015

<kaoru> scribenick: kaoru

Wendy: Two new WG on security, Web authentication and Hardware based authentication.
... Point we are is draft charters and collect feedbacks.
... FIDO alliance and hardware integration for discussion.

<rigo> Charter for Hardware Security: http://w3c.github.io/websec/hasec-charter.html

Wendy: We have a couple of draft charters.
... This is public. We are going to invite developers and implementers to vote for or against the charter.

<rigo> wseltzer: on chartering, explains the making of charter, drafting and then presenting to AC

<rigo> ... currently chartering in early stage

Wendy: We are at pre-review stage here, gather inputs, and wait for needs.

Jeff: Two goals are API and attestation formats for web applications.

<rigo> JeffH: definition of API for authentication. Gathering input. WG will not ground zero. Industry has already developed things over the years

Jeff: WG is not started from ground-zero. Industry specs dat FIDO alliance did is incorporated.

<rigo> ... are things in FIDO that do this thing. But to make it ubiquitous, have to bring it here

Jeff: Here's FIDO 2.0
... From three or four years trying to gather critical mass.
... Basic mission is to change authentication online by mechanisms supplanting password.

<wseltzer> https://fidoalliance.org/wp-content/uploads/FIDO_Alliance_-_Membership_Agreement.pdf

Jeff: and submitting specs for formal standardization, W3C and IETF.
... Overall goal is to nurture ecosystem. FIDO Alliance doesn't ship products.
... Shared user secrets are often exploited. Tons of issues a week about stolen credentials.
... One-time codes back via SMS is still phishable.
... Major Industry trend is mobile devices or laptop to pins and then simpler stronger user verifications on personal devices.

<bhill2> lots of similarities between hoba and fido

Jeff: Leverage local device auth to remote
... Paypal and docomo has enough users. Google and twitter support second-factor.
... UAF is verified on biometrics. U2F still requires passwords but prevent phishing.
... Scalable attacks are very difficult. They need to steal physical devices.
... FIDO ready program started Apr 2014. FIDO 1.0 Dec 2014
... Privacy and security design is the primary principle.
... No 3rd party in the protocol, no secrets on the server side, biometric data stays on device, no linkability between Services/Accounts.
... 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.
... On login, server sends the challenge and the device signs it. The server can verify with the device's public key.
... Decouple local auth modality from auth protocol. People can use different biometrics without changing the protocol.
... What is missing: client-side is not ubiquitous. Web platform, android, windows, etc.

<wseltzer> JeffH: Ideally, all platforms should have built-in API for strong auth

Jeff: To accelerate adoption, give incentives to RP that all devices work, etc.
... What FIDO is doing now: crafting standards for future built-ins, future APIs, standardized model on OS level.

<wseltzer> JeffH: Bringing Web API to W3C

Barry: httpauth WG come up with better solutions but browser vendors seems not interested. HOBA

Jeff: Difference is business perspective.

<bhill2> fido wire protocol is almost exactly like HOBA, but then adds a crypto binding layer that allows device-type attestation

@: JavaScript API to test under the control of the web site. HTTP header is what JS find difficult to control.

Jeff: Amazon offers a security key and Google Chrome can use it.

<Zakim> timbl, you wanted to ask about what form the user identifier takes, and about matching diff levels of autherntication with authorization

Brad: Metadata describing device types, level of assurance, etc. supports how the user experience that device offers.

timbl: @

Jeff: You use the user accout.

<wseltzer> https://www.w3.org/TR/credential-management-1/

<annevk> Is there any integration with <form>?

<rigo> xforms?

<annevk> sure

<bhill2> annevk: no, it's challenge-response

Jeff: Key pair is allocated and public key is returned. Credential management and authenticator works challenge/signature based.

<Zakim> timbl2, you wanted to wonder abouhow you trust a key you buy on amazon

<bhill2> JS API

<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

timbl: You separate authentication from authorization?

<wseltzer> JeffH: separate modality of user interaction from underlying protocol

Jeff: No. Separating user verification on user modality and auth protocol.

<bhill2> annevk: right now the apis are imperative, much like the new credential manager apis are

<annevk> bhill2: and this key thing is still per-origin right?

<annevk> bhill2: not a big fan of those either

<bhill2> new keys created per-origin, and per-account-identifier

<annevk> ah, didn't know about the latter

<bhill2> you can use the same fido device to authenticate unlinkably to two email accounts at the same provider, e.g.

Jeff: FIDO certification program gives trust to the devices.

<annevk> yeah makes sense

timbl: Manufacturer reputation based.

Jeff: RSA key works only with my employer because it's synchronized with the company server.
... But the key from Amazon works with any sites that support the mechanism

Virginie: Vender perspective of FIDO tokens are same kind of security that banking provide to account holders.
... Consumer take a choice of a key and service providers set a bar of the security level.

timbl: How bank believe that the key has come from a secure hardware device?

kpfleming: Because it's part of the protocol.

Jeff: Secret is kept in the device; what's in the database is public key.

<annevk> keygen!

dka: What is the user experience enabled?

<rigo> meaning, get a new thumb if you lose your phone

Natasha: Automatically logging-in is not very safe because they do nothing. Challenge response is important.

bhill2: Various device can be used in markets.

Judy: FIDO only support local devices. Remote user identifications?

Jeff: That should be handled with other stack like TLS.

Judy: FIDO supports only on-line with servers. How about off-line?

<rigo> 8min left for http://w3c.github.io/websec/hasec-charter.html

Jeff: User verification is done locally. It changes nothing at local. It leverages local unlock.

Judy: Alibaba has use cases for off-line authentications.

bhill2: Challenge respose protocol requires online

<bhill2> you can have multiple accounts associated with one device

<rigo> timbl: question about multiple identities on one device in FIDO

<bhill2> or, for cheap external devices like U2F you could use multiple devices

<bhill2> but that kind of user experience is left to the competitive client-side implementation

Virginie: Hardware security WG

<bhill2> some devices might provide a rich user chooser experience, others might just always use, e.g. one account-per-fingerprint

<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.

<annevk> bhill2: why does the challenge have to come over the network?

<kpfleming> where else would it come from?

<bhill2> it doesn't necessarily

<annevk> I guess that's what you were hinting at, that you could store a couple for offline usage

<rigo> enabling services can be exposed via an API to javascript

<bhill2> I guess you could cache a few, or even choose a well-known challenge to represent "offline"

Virginie: Bring Secure element and trusted execution elements to web applications.

<bhill2> and apply different heuristics to deal with replay

<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

<rigo> Virginie: we have already some supporters like Orange, Deutsche Telekom, Intel etc

<annevk> kpfleming: looked into service workers?

<kpfleming> annevk: no, i have not, sorry

<annevk> kpfleming: that might help

Virginie: To help web apps discovery of secure tokens.

<kpfleming> annevk: thanks

Virginie: Extending WebCrypto API and incorporate Hardware secure tokens.

<rigo> API will make available that secure environment to web application

<rigo> ... secure workers e.g

Virginie: Crypto APIs, Storage API, IO, and citizen identities
... How to reuse citizen identities to manage online identities.

<annevk> rigo: they might get terminated then, but that makes the whole thing sound rather crude :/

Virginie: We have a lot of deliverables. We need to prioritize these.

David: Threats models are needed.

dbaron: Are there risks like super cookies to relate users across web sites?

<wseltzer_screen> mnot: question about linkability: can my bank link me with other uses of the card?

<wseltzer_screen> drogersuk: We need to think about the "apple bobbing" attack: where a site asks repeatedly for national IDs

<wseltzer_screen> drogersuk: principle of least privilege in information disclosure

<scribe> scribenick: wseltzer_screen

<kaoru> scribenick: rigo

<kaoru> scribenick annevk

<wseltzer_screen> judy-zhu: Did you consider regulatory requirements of countries?

<wseltzer_screen> virginie: in WebCrypto, we defined features, but can't override jurisdictional restrictions; not all features may be available everywhere

<wseltzer_screen> ... browsers don't want to do profiling

<wseltzer_screen> drogersuk: we'll have to look case-by-case, fight fragmentation

<wseltzer_screen> judy-zhu: this charter is not frozen

<wseltzer_screen> virginie: We'll take feedback for a few weeks, update the draft, then take to AC review

<wseltzer_screen> ... please send feedback over the next 3 weeks

<wseltzer_screen> https://w3c.github.io/websec/hasec-charter.html

<wseltzer_screen> manu: it would be good to prioritize the deliverables

<wseltzer_screen> virginie: already planning to do that

<wseltzer_screen> manu: is there linkability? it might be the answer is yes and we're ok with that, or with tokenization

<wseltzer_screen> virginie: derived credentials

<bhill2> I really wonder how many of these use cases would be better accomplished through OAuth-like patterns

<bhill2> I know the idea that the government today doesn't know everywhere I show my driver's license

<wseltzer_screen> manu: fundamental mode should be unlinkable

<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

<bhill2> are the privacy side-effects of making such credentials widely available online worse than the centralization?

bhill2: you do NOT make the credential available

<wseltzer_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

you can check its presence

in a given context

<wseltzer_screen> ... so ideally we won't have to worry too much about jurisdiction restrictions

<bhill2> rigo: but what kind of info can I get that's useful but not identifying?

<bhill2> a bank has a legal requirement to know exactly who I am

<bhill2> if that's the scenario we keep talking about

I can show you how you can prove that you're over 18 without ever getting identity information triggered by this API

<bhill2> to e.g. establish a new account

the new account is identifying you, not the hardware token

coffee

- DRAFT -

SV_MEETING_TITLE

28 Oct 2015

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output