See also: IRC log
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/desgin/design/ Succeeded: s/JeffH: q?// Succeeded: s/adds/offers a/ Succeeded: s/This key/RSA key/ Succeeded: s/@/kpfleming/ Succeeded: s/@/dka/ Succeeded: s/stamp is done by the account holder/key has come from a secure hardware device/ Succeeded: s/How/... How/ Succeeded: s/all/all features/ Succeeded: s/screen/wseltzer_screen/G Found ScribeNick: kaoru Found ScribeNick: wseltzer_screen WARNING: No scribe lines found matching ScribeNick pattern: <wseltzer_screen> ... Found ScribeNick: rigo Inferring Scribes: kaoru, wseltzer_screen, rigo Scribes: kaoru, wseltzer_screen, rigo ScribeNicks: kaoru, wseltzer_screen, rigo WARNING: No "Topic:" lines found. Present: Dan Appelquist Kevin P. Fleming WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 28 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/28-websec-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]