Web Authentication WG -- 04 Mar 2016

<inserted> scribenick: wseltzer

Intros around the table

tonynad: Welcome
... reviewing the agenda

-> https://lists.w3.org/Archives/Public/public-webauthn/2016Mar/0000.html Agenda

scribe: We'll call for adoption of the drafts that began as member submission
... we'll look at editors, workmode, scheduling

Felipe_Moreno: Bloomberg
... work on the fingerprint authentication for the Bloomberg terminal
... also using tokens for webapp login

Mirko: Surepass ID, a FIDO authenticator

Keiji: W3C fellow from Keio University

Salah_Machani: RSA

Kavvan_Alikhani: RSA

Rob_Trace: Microsoft, networking and security, JS APIs

Debbie_Mac: FIDO

Alexei: Identity team at Google

Dirk_Balfanz: Google, active in FIDO

Sam_Srinivas: Security PM at Google

Christiaan_Brand: Google

JC_Jones: Mozilla

Hubert: PayPal

Rolf_Lindemann: Nok Nok

Juan_Lang: Google engineering manager

Pier_Deganello: Federal Reserve

Mike_Jones: Identity at Microsoft

Axel_Nennker: Deutsche Telekom

Jeff_Hodges: PayPal

Harry_Halpin: W3C/MIT

Jakob_Ehrensvard: Yubico

David_Martin: CESG

Morgan_Davis: Plantronics innovation team

Giri_Mandyam: Qualcomm

Adam_Powers: Technical Director, FIDO Alliance

Adam_Cooper: UK Cabinet office, identity assurance

John_Fontana: Yubico

Derek_Hanson: Yubico

<harry> scribenick: harry

<selfissued> Mike Jones

Intro to W3C

<wseltzer> Wendy's Slides

wseltzer: W3C is a global standards body for the Web
... directed by Tim Berners-Lee, hosted by 4 offices
... 70 people on staff
... if you are a W3C member, get your AC member to join
... if not a W3C meeting, do talk to myself or Harry
... One important part of the W3C is the royalty-free patent policy
... we need to assure all contributions are coming via member representatives
... the chairs and Team can work together to make sure invited experts can come
... if they can't be a W3C member
... we run by consensus
... we can't force anyone to do anything
... we try to get implementable specs
... that are interoperable
... Working Group is governed by its charter
... you and your advisory committee read the charter
... approved scope and limitations
... our goal is to get to Rec
... within the time on the charter
... chairs responsible for guiding consensus
... and making sure things on track
... Harry Halpin is Team Contact
... we have WebEx for scheduling
... usually teleconferenes
... IRC for minutes
... all meeting minutes are published
... we broadcast all our decisions and give people on mailing list opportunity to follow up
... anything that happens in F2F and teleconference
... or W3C Recommendation Track
... is our process
... for moving to a Recommendation
... W3C is a Member Submisison
... it can then be adopted as a Working Draft

wseltzer: when we publish first working draft

wseltzer: then we have a Last Call where we make sure we get the document finalized
... we try to get patent commitments early as possible
... and if someone raises a patent, we have a Patent Advisory Group
... that can work through patent-related claims
... we encourage regular updates
... as editors work through issues
... and pull requests
... using Github
... we go to Candidate Recommendation when we think the spec is technically sound
... and has all the features we want in place
... to get to Proposed Recommendation
... at least two interoperable implementations
... that have been tested
... every feature must have two inter-operable implementations
... then goes to PR
... Proposed Recommendation
... there's a Director Review
... we hope to do this for a year

rbarnes: What matters is what is stable
... usually around Last Call/CR things have settled down

wseltzer: ideally we'd like to do things like tests as we go on

rbarnes: We want things stable and settled down 6-9 months given we have a mature startin

<wseltzer> Wendy's Slides

Credential Management API

<rbarnes> link to the Credentials slides https://docs.google.com/a/mozilla.com/presentation/d/1pMUuw2xiZt36Mn4GJG51917smsqHS0u77E5l5rd5kmY/edit?usp=sharing

<scribe> scribenick: wseltzer

rbarnes: WebAppSec Credential management API
... ideas from that spec informed FIDO 2.0

-> https://w3c.github.io/webappsec-credential-management/ Credential Management

<gmandyam> * Has the slide deck been uploaded?

rbarnes: can we create a deterministic password manager interface

<gmandyam> * Ignore - IRC was slow in updating

rbarnes: instead of the heuristics UAs have been applying
... imperative interface from the page to the browser
... behind this interface, managing the credential
... We need a name for these credentials. Get your bikeshed paint out
... Introduction to the concept, so we can see how it makes sense to integrate
... Moving parts: password credential, object as opaque representation

<gmandyam> * Sorry - original question still stands. Where is the slide deck on Credentials Mgmt. that Richard is currently discussing? I cannot find a link, and the slide deck is difficult to see on the projector given the font color and black background.

rbarnes: password manager never sees the credential itself, some XSS protection
... credential objects, a store and get interface
... types of credentials
... the spec has notion of federated credential, password credential
... does it make sense to have a FIDO credential, encapsulating the functionality we're talking about here
... internal keyHandle, pubKey, sign()
... what do we want the object to look like, how do you create, manage

Pier: thinking about how browsers handle PKI, does FIDO look like client cert?

rbarnes: sounds like a question for another WG
... you'd want to handle differently because of origin separation
... it's important here that each origin has a different keypair

Pier: so it's a different use case

AxelNennker: Crential management spec renamed local to site-bound credential

<harry> +1 StrongOriginBoundCredential

rbarnes: origin-bound is important
... sketch of what a FIDO credential would look like

<JeffH> OriginBoundStrongCred

<JeffH> aka OBSCred

rbarnes: create, register,
... we need registration to be async
... but constructors can't be async
... that would pass back some signature objects

<vgb> i like OBSCred better than SOB Credential...

<JeffH> lol

gmandyam: FIDO 2.0 uses credential management

rbarnes: do we want to align more closely?
... we might just need to re-align

<harry> To re-state, do we want to align with Credentials API or expose via multiple levels (i.e. FIDO 2.0 is higher level now, Credentials API is a bit lower)

rbarnes: worth thinking about the benefits: determinism, a simpler data-store
... than indexdb
... FIDO-like credentials, you'd get simplicity of storage interface, reuse of design patterns
... think about a site where you can log in with password or FIDO credential
... makes the flow easier

<rbarnes> link to the Credentials slides https://docs.google.com/a/mozilla.com/presentation/d/1pMUuw2xiZt36Mn4GJG51917smsqHS0u77E5l5rd5kmY/edit?usp=sharing

FIDO 2.0 Current Status

<wseltzer> FIDO 2.0 slides from Dirk, Alexei, Vijay, and Rolf

<adam_powers> btw, "/msg Zakim help" if you want to see the full list of commands or https://www.w3.org/2001/12/zakim-irc-bot

dirkbalfanz: I'll share some background, Adam on FIDO, Rolf, Alexei, Vijay on JS API
... FIDO 2.0. FIDO released 1.0, then submitted 2.0 to W3C

<AxelNennker> Here is the link to the W3C WebAppSec's credentialmanagement draft: https://w3c.github.io/webappsec-credential-management/

dirkbalfanz: 1.0, UAF and U2F
... UAF focused on mobile deployment

<adam_powers> FIDO 1.0 = UAF + U2F

<rbarnes> to the point raised by gmandyam earlier: today is going to have a lot of intro/background to get everyone on the same page

<JeffH> UAF is about replacing passwords. U2F is about making pswds non-phishable.

dirkbalfanz: U2F, hardware tokens that help with authn
... we want to get to a spec that covers all use cases, is implemented on all platforms
... "platform"=thing I write an application atop
... use cases: authenticator
... authenticate local user, auth to server
... 1/ built-in authenticator
... 2/ special-purpose devices, e.g. USB tokens, 2d factor device with key material
... renders password non-phishable

<JeffH> a top-level goal of OBSCreds is non-phishability

dirkbalfanz: 3/ smartphone, has key material and can authenticate user
... What do we need to standardize to create ecosystem
... RP App to Client
... Web Platform, we need agreement among those in this room
... also RP App to RP server
... e.g. verifying signature, what the signature should look like
... when you create a new keypair
... also system to authenticator, if the authenticator isn't built-in
... CTAP, happening elsewhere

<JeffH> CTAP == Client To Authenticator Protocol (was: External Authnr Protocol)

dirkbalfanz: FIDO 2.0 API, 2 calls
... makeCredential, getAssertion
... makeCredential, asymmetric crypto, generate a new keypair
... with attestation
... telling you what generated the keypair
... makeCredential, get back the public key, attestation
... getAssertion asks for signature
... get a challenge from the server, call getAssertion to sign challenge
... sign the challenge+some platform information: origin
... unphishable, MITM-resistant authentication

<nicolagreco> "

dirkbalfanz: typeless authentication

Pieralberto: can this do server authentication to client?

dirkbalfanz: we've focused on client authentication to server

rbarnes: we're not talking about a network protocol
... interaction within the browser so web content can talk to token

felipe_bbg: looking at the other side of the authentication, server

Rolf: FIDO uses TLS
... if the client is compromised, all you can do client-side is transaction authentication
... man-in-the-browser can misuse the authenticated channel
... implementation can use other security mechanisms, TEE, trusted UI, etc.
... attested signing

SamSrin: we want easy authentication for the user, 2d factor

vijay: if the user isn't sure the right person is asking, signature shouldn't be generated. vs in our case, signature will be generated but it won't be usable
... because origin is in the signature, so it can't be repurposed

felipe_bbg: question was based on who initiates

dirkbalfanz: we rely on the browser to represent which origin is requesting authentication

<JeffH> wrt the threat model, please see analysis here: https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-security-ref-v1.0-ps-20141208.html

rbarnes: with any web API, you can't get away from some degree of trust in the browser

<rbarnes> ack

rbarnes: this group should have clear documentation of which parties are trusted to do what, and the bounds of that trust

dirkbalfanz: if browser is no longer acting on user's behalf...

JeffH: I included a link to the security document, threat analysis

rbarnes: I welcome your pull request

dirkbalfanz: use case, bound authenticator
... user gesture authorizes binding of the keypair
... registration, then authentication
... RP gets credential ID (server side, or left in cookie, local storage)
... challenge, credential id
... user gesture authorizes use of private key
... return signature on nonce, origin, token binding,
... authentication without a username
... getAssertion without credential ID
... platform talks to authenticator, asks user to select account,
... then same flow

felipe_bbg: is it assumed there's only one authenticator?

dirkbalfanz: no, it should work with multiple
... use case, 2fa token, registration
... token has no storage, just returns wrapped key
... registration: RP app calls makeCredential
... inputs, nonce + account info
... returns public key, credential id, attestation info
... device could choose to wrap the private key it just generated, call that a credential
... authentication. these devices probably won't be sole authenticator
... but on a device that already knows who the user is
... simple user gesture, such as touching a button, protects against automated attack

nicolagreco: where does the user gesture come from?

dirkbalfanz: need something unforgeable, e.g. touching a button
... last use case, login with smartphone
... registration, switch from username password to phone; generate credential on phone, forward request
... phone makes sure the user is there, generates keypair
... again, platform returns pubkey, credential id, attestation
... authentication. assume there's no latent ID, I just carry my phone up to a kiosk
... RP can call getAssertion without knowing user's credential id
... User Experience
... what does it look like to a user
... account chooser
... UA can know what kind of authenticator the account uses
... RP can draw UI that tells user what to do next, e.g. insert security key

pier: does the RP need to remember how the user logged in?

dirkbalfanz: it's useful

rbarnes: lots of keypairs, it's up to the RP to keep track

dirkbalfanz: option for the RP to make getAssertion call without credential ID
... let the platform, authenticator figure out who the user is, how they want to login
... platform can combine multiple sources of account info, RP gets it only after the user chooses one

SamSrin: app should be able to ask for authentication, from platform (OS, web browser)
... the browser can package lots of the detail for the user

<scribe> New participants

Alex_Russel: Google, TAG

Garret_Robinson: Freedom of the Press Foundation

[break]

<scribe> scribenick: jcj_moz

Starting again with Part 2 of FIDO background, dirkbalfanz presenting

dirkbalfanz: showing the system-level of what needs standardization at w3c; 3 of the documents uploaded are the parts relevant to the web
... we must agree on the key & signature formats, the web API,
... Now going to let Vijay go through the web API

Vijay: Authenticator is hardware that gathers user consent
... May be simple or not, but does crypto when users tell it to
... Could have a management interface, permitting credential removal, etc., but may not
... Identifies the kind of authenticator, but not identify the individual device
... Credentials are keypairs that live on the Authenticator
... WebIDL for makeCredential: Takes in account information,
... which has display names, image URL, identifiers
... Does not get read back out; the RP doesn't ever get to see what Account info the Authenticator has
... Second param: Crypto parameters. Wide variety of crypto algorithms, authenticator-agnostic way of specifying what's acceptable

rbarnes: Purpose of the algorithm is to ensure the RP can verify what comes out of the Authenticator

Vijay: Yes, you pass in a sequence of crypto params, if the call succeeds, the results will be one of these crypto params
... The attestation is used in the challenge. The timeout is UI sugar.

<JeffH> "UI Sugar" -- a technical term :)

Vijay: The blacklist (seq of credential) is interesting. The use case is: If you are a RP, you are creating credentials on a smartphone, you don't want to create duplicate credentials for the same account
... These are the credentials I already have for this user, so if you recognize one, don't respond to this query
... "If you know any one of these, I'm not interested in talking to you."
... Extensions are the extra things... selecting authenticators - e.g., Bank may only want to use the authenticators they hand out
... There are a set of such extensions
... All extensions are all optional. When you get back a response from API, it will tell you which it processed
... FIDO Credential Info object will give you a credential ID, the algorithm ID used for the credential, a pubkey,

rbarnes: The pubkey is a serialized....

Vijay: It's a JWK object

Vijay clarifies it's a JS Object from WebCrypto

<JeffH> The publicKey attribute contains the public key associated with the credential, represented as a JsonWebKey structure as defined in [WebCryptoAPI].

Vijay: Attestation statement is a proof about the authenticator

<JeffH> https://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Vijay: The consent serves 2 purposes: 1) You're consenting to the creation of the credential, and 2) you're selecting between multiple authenticators

(During implementation of makeCredential)

question: AxelNennker "Is this an NFC case?"

Vijay: If you want to use something like an NFC reader, you would have to tap the NFC device on the reader, that we know it's there. It's more challenging
... Contactless smart card similar
... You can always know the reader is there, and use heuristics to tell if a user has used it in the past

alexei_goog: We have gone through this with U2F in FIDO, we have a demo
... of the platform drawing how the user interacts with u2f, we can show that

Vijay: If the credential cannot be created - one of twos things - if it's async, the Promise never comes back...
... If there's a timeout... Well, the challenge is that this is very platform-specific
... Think about multiple authenticators. The RP doesn't know there are 4 authenticators, the platform does.
... If 4 authenticators, and 1 fails, do you wait for the other 3?

<JeffH> heh

Vijay: This is the slow operation, makeCredential, it is not getAssertion
... GetAssertion - fewer parameters, basically all are optional

<alexei_goog> weiler: :-P

Vijay: Credential object is from makeCredential prior call
... Could have an extension with a transaction confirmation string

question: Is "Credential" the same as the WebAppSec credential interface?

Vijay: It started there
... client platform figures out the authenticators and includes origin, RP, and constructs the To-Be-Signed thing to the authenticator
... Authenticator prompts consent

<AxelNennker> Align with https://w3c.github.io/webappsec-credential-management/#interfaces-credential-types-credential

Vijay: The specific authenticator on which you consent responds, and can include more stuff as extensions
... example: current geolocation
... Also of course the signature

Question: This response only happens if the signature was produced?

Vijay: Platform gives an error, how it is presented to the client is tricky
... Authenticator knows, for each credential, the RP ID it's associated with
... When asked to sign something, Authenticator has to check if it matches, the credential to the RP ID
... The Authenticator gets the RP ID from the credential, and from the platform, and compares the two
... So that's getAssertion. At end of process you get a signature. If you request extensions they may or may not be present.
... Only guarantee is that it's a signature from one of the Authenticators
... You get out 3 things: One is the challenge, one is extensions the RP provided, and one is extensions what the Authenticator added

rbarnes: Can the authenticator add extensions that the RP doesn't ask for?

Vijay: There's nothing that prevents authenticators from adding all the extensions it wants to
... No such thing as critical extensions. If you don't recognize, skip

alexei_goog: If a platform sees an extension it doesn't like, it may drop the request

Vijay: Platform could say 'this is a privacy-stealing extension' and throw it away

rbarnes: There's an affordance as to what's possible

Vijay: Yes; this is a discussion we've had for a very very long time
... critical extensions: If you have them, can make for difficult user experience. Inconsistent
... If an RP gets an assertion that it thinks is weak, it could prompt another factor of auth like a text message
... Give the RP the tools to quantify the risk, you do what you want

comment gmandyam : Could be part of the work of this WG, re: spectrum of errors

question: How much do you need to protect the credential going to the wrong authenticator?

Vijay: The assertion is a fairly robust thing, it's signing random nonce, not reusable, assertion won't be useful tomorrow
... While credential ID is a key, it's a wrapped private key. It's an attack surface, you can leak the credential ID but it requires a user to consent to attack
... Signatures include RP ID, origin, in the response and the server can verify if the sig was not meant for you

rbarnes: AxelNennker brought up privacy concerns
... We should be clear that the only notion of what the RP is to an Authenticator is what the platform says

Vijay referred to only available over HTTPS...

Vijay: RP Choices you get to make. You can use Authenticator as a first factor vs second factor
... You get to decide, as a RP, maybe only rely on authenticators you handed out to people
... makeCredential is kind of sensitive. Intent is to take the credential ID and associate it with the user, so that providing proof of possession later ties this to a user. So you must believe this with some level of assurance. Not specified in spec
... RP may want to do significant due diligence out of band to confirm the registration
... UI for getAssertion can be driven 2 ways: Driven by RP javascript and leverage localStorage...
... Or it could fall back on the platform entirely
... which is a lot simpler
... There is affordances for fancy UI

keiji: Is there risk making a phishing UI?

(keiji actually said fake UI, not phishing)

Vijay: A lot of the security of these schemes is that authenticator is its unique thing. You can hack RP, hack the platform...
... The Authenticator truthfully records what it sees, and server can evaluate what it gets from the Authenticator

<wseltzer> [lunch 30 min break]

FIDO->W3C

rbarnes: Just had some technical discussion, want to bring back up to higher level
... Got some info from dirk on the FIDO specs and WebAppSec and interconnection this morning
... What we're doing in WebAuth is to take the top layers of FIDO 2.0, from FIDO, and standardize them
... WebAuth says, when you're in JavaScript, when you're in a Browser, here's how you ask for stuff: credentials, signatures
... The Browser has to figure out how to fulfill that. The details of how the Browser does that can be FIDO. You can use some other system that fulfills these requirements
... Could be provided by the OS, hardware, etc.
... W3C is providing the general API and there are multiple ways to satisfy

rbarnes is showing a "T-shape" where the down-line is a Cryptographic protocol that transits from the Web API down to hardware

rbarnes: Any questions? Wanted to level-set in how this group relates to FIDO
... There could be other implementations that could use this API. Could speak to some other trusted environment.
... FIDO is important, got the whole thing started, but could imagine others

harry: Token requirements, certifications are not done by W3C. W3C has success at the narrow focus.

<johnk_> how is that "trusted environment" different from an authenticator?

Anthony: Testing will not be for FIDO Conformance, but W3C API

rbarnes: When we get to browser testing, browsers under test will be tested for compliance to the API only

<harry> FIDO will continue FIDO certification and testing on parts of the eco-system outside of the Web (authenticator/OS-level)

keiji: Who works on standard protocols between the RP Server and the RP Javascript?

<harry> We'll stay in touch to make sure it all works, and the level of abstraction should be open (i.e. no lock-in)

rbarnes: Probably will define the message patterns between the servers, but not the wire protocol. Not concretely how the JS talks to the RP Server

<harry> however, browser test-suites are an entire different animal than authenticator certification

rbarnes: We will start from the one that's in the baseline, consider hiding things or too-fido specific things, and maybe define extensions

Anthony: We'll call for adoption of the docs later today

hubert-paypal: question regarding ...issues with implementations, deleting from the client side?
... Can you delete credentials in WebAppSec?

rbarnes: I don't think deleting credentials exists right now

Anthony: Want to do a demo of what's working today

SamSrin: There are existing implementations in the wild.

alexei_goog: Goal: convince you all this isn't completely crazy; some of the problems have been solved before in similar context

rbarnes: Show what kinds of things we want to enable with this API

[cbran & alexei_goog presenting now]

alexei_goog: Show logging into Google using U2F. 2 different form factors: Both made by Yubico, same thing with different form factors
... One has NFC, and both have capacitive touch sensor

cbran: Credentials are on one token, but will plug both in so can demonstrate what happens when there are two

alexei_goog: Creds aren't ON the token, they are associated WITH a token
... Logs into Google, is prompted for a "Security Key"

alexei_goog logged in by touching the associated authenticator. Now logging out again

alexei_goog: Academics are planning to do usability studies on these devices across different demographics

cbran: One is registered, one is not, and touch the wrong one and see what happens
... When you touch the wrong one, you get an error
... alexei_goog will now perform a musical number

note: [difficult to translate to IRC]

<gmandyam> *alexei_goog: can you share the reference to the paper you recently presented on FIDO?

cbran shows re-sign in again, then demonstrates that Google lets you register multiple tokens

scribe: second token was registered using his mobile phone
... and then he signs back out

Then cbran shows an Android device on the projector

Using his Android phone he goes to log in to Google with that same account

scribe: and then cbran shows us all his password

cbran: This is not the final UI.

alexei_goog: This login page is being rendered by an Android application, but this would be the Platform

cbran shows using NFC to authenticate using the yubikey

scribe: and then moves to BLE, which alexei_goog notes is even _less_ final and also flakey

cbran shows this doing BLE.

Rolf is now presenting on Attestation Statements

Rolf: Now we've come to the fun stuff - Less UX, more crypto
... Someone may want to implement authenticator on top of a TPM, embedded secure element, hardware... Also user gestures could be fingerprint, or face recognition, things we can't come up with now but will in the future
... For the RP the security depends on these choices: what kind of authenciator was used?
... Sometimes we might want a bit more strength to it sometimes, this is a distinction

<mirko_> SurePassID has a demo similar to Google's if anyone is interested in seeing it. Just find me, Mirko. I'm in the shirt with the FIDO logo on it.

Rolf: Attestation lets the Server look up metadata and see what the information is about the given authenticator, or other known authenticators
... Want to know things about the model of the authenticator. Strong signals (cryptographic proof) without violating privacy
... 3 models for this:
... 1) Basic attestation: Set of authenticators that share one key+certificate injected at manufacturing, can't tell which auth it is, but can tell the model, so can't ID the individual
... Some information you can get, based on what the model is, but don't let the RP ID the authenticator correlates between otherwise-different users
... 2) Privacy CA, as defined by TCG, implemented in TPM.
... 3) DAA, ECDAA, Direct Anonymous Attestation,
... Back to Basic Attestation: Simple model, no need for runtime infra. Better privacy if the cert is shared over a large set, but conflict: better security if the cert is shared across a small set of authenticators
... Privacy CA requires runtime infra: the CA itself has to be in the middle
... 'What is the business model for those CAs?'
... Maybe a company may run a privacy CA for its employees
... Better security because keys aren't shared
... Privacy CA itself though knows all the correlations between Authenticators and Certs
... Direct Anonymous Attestation is a middle ground- doesn't need runtime infrastructure. DAA privkey is unique to an Authenticator, but the privkey is blinded / unlinkable
... It's an interesting model, more complicated cryptography
... TCG adopted ECDAA and are doing some tweaks
... Originally slow. ECDAA much faster, based on EC
... Attestation Types: The authenticator must control what gets signed as part of the Attestation Statement.
... We have to support things already in the market so already support "packed", "tpm" and "android"

Rolf shows the WebIDL for AttestationStatement and AttestationHeader

scribe: and AttestationCore, Client Data

Rolf: ClientData is provided by the Platform, not the Authenticator
... ClientData is in the Signature Format doc

Q: "Can the authenticator provide feedback to the browser re: its ability to comply, such as getting a request it cannot do."

<wseltzer> Lang et al., Security Keys: Practical Cryptographic SecondFactors for the Modern Web (the paper alexei_goog referenced)

Rolf: RP server has to understand and recompute the hash of the client data, but the Client Data's hashAlg is chosen by the platform/authenticator.

Vijay: Another take on your question is is part of the extension definition
... It's possible to define an extension and tries to do something, and the authenticator sends back an extension with whether it was successful or not

<gmandyam> * Thanks for the link, wseltzer

Vijay: but no one has defined one. Not clear that there is such a use case. Keep spec as simple as possible; if there's not a clearly defined use case, we don't do it

<alexei_goog> for the record, the Security Keys paper, refereced above by wseltzer, is academic and omits some spec details. Careful readers will notice a difference.

alexei_goog presenting Signature Format (returned by getAssertion)

alexei_goog: Goal of standardizing sig format, regardless of what Authenticator produces a signature, all RPs know how to parse it
... Goal of sig is to bind together info put in by RP, put in by Client / Platform, and info put in by Authenticator

alexei_goog shows the WebIDL for FIDOAssertion & ClientData

alexei_goog: The Authenticator only sees the hash of the ClientData struct

Q: Does this expose the Channel ID from tokenbinding?

alexei_goog: Exposes it to the RP

Vijay: The Authenticator gets to freeze the Channel ID

alexei_goog shows AuthenticatorData

alexei_goog: AuthenticatorData is a bit field because want to support very limited Authenticators

slightlyoff: Why is this a DOMString as opposed to an ArrayBuffer?

Vijay: No good reason; partly because we ported over pre-existing stuff
... In fact, we've been talking about the CredentialID could benefit from being ArrayBuffer

slightlyoff: The bitpacking would be error-prone to consumers

alexei_goog: We came into this with typing that wasn't the best

keiji: This API is not only for authentication? It cannot be used for generic signature, on email messages?

alexei_goog: No. Meant for authentication, period

keiji: Any future plan to use FIDO device to sign email?

Rolf: Signature counter included - make sure only authenticator controls this structure

alexei_goog: Counter.... Variable length extensions as CBOR
... There will be a registry of extensions w/ several examples
... How do you generate the signature? Authenticator takes Client Data Hash,...

rbarnes: Client here is browser/platform

alexei_goog: Authenticator Data concatenated with Client Data Hash and then signed using privkey

rbarnes: RP provides some challenge, which reflected in Client Data?

alexei_goog: Yes, in the ClientData. And remainder is contributed by client.

<wseltzer> FIDO 2.0 slides from Dirk, Alexei, Vijay, and Rolf

Charter scope and deliverables

<wseltzer> Webauthn Charter

<wseltzer> tonynad: Charter has been adopted, so no changes now

<wseltzer> ... charter gives us some deliverables

<wseltzer> ... notes the contributions as proposed starting point

<wseltzer> [many people show hands to having read the documents]

<cbrand> +1

wseltzer asks for any objections to the 3 submitted documents

<harry> PROPOSAL: Start WG with Working Drafts based on Member Submissions

<JeffH> no objections

<hubert-paypal> +1

<rbarnes> +1

<cbrand> +1

<harry> +1

<slightlyoff> +1

<wseltzer> PROPOSED that we adopt the Member Submission as working drafts for the group

<JeffH> +1

<Rolf> +1

<alexei_goog> +2

<vgb> +1

<derek> +1

<alexei_goog> +1

RESOLUTION: Start WG with Working Drafts based on Member Submissions (from FIDO)

<rbarnes> SO SAY WE ALL

<wseltzer> https://github.com/w3c/webauthn

<inserted> scribenick: harry

question: Should we merge this all into one big draft?

<JeffH> link to slides ?

wseltzer: We'll do everything via github pull requests
... minor changes can just be done via editors
... so any issue, no matter how small, should be a github pull request
... we do a formal transition request (working group consensus)
... for publishing the documents at w3.org/TR/
... the WG does not have to reflect that the group thinks is done
... but that it wants more public review
... we can use automated publication tools

question: Do editors have to all agree on changes?

wseltzer: It's for each WG to figure out, editors should figure out level of questions
... and how controversial it is
... in which case, bring it up on the conference call.
... decisions made on meeting should be confirmed on mailing list
... adding features after CR requires going back through

<weiler> call dropped.

We like testing done like this

http://testthewebforward.org/docs/

its the format used by HTML5 test-suite

if we add it

it will then get added

to the same test-suite that runs rest of W3C tests

nadalin: let's make sure github notifications work for the mailing list
... we prefer some discussion before opening a new issue for the WG

wseltzer: Start on mailing list if the question is not clearly an issue for the spec
... so we can make it concrete enough for the WG to work through

Editors

nadalin: Let's get editors assigned
... we should first see if we can keep editors and the same ones want to stay

rbarnes: Attestion Rolf and Mike?

rolf: Happy to say in

rbarnes: Signatures, Aranar, Mike, Rolf, and Alexei

Rolf: Yep, let's keep it

rbarnes: API - shall we continue
... vgb, want to stay?

vgb: Yes
... keep the same editors and add J.C. from Mozilla.

nadalin: Anyone else want to play editor

Juan: I would like to be added

rbarnes: Anyone can submit patch, but editors are commiters

<Rolf> Rolf is rlin1 on github.com

wseltzer: we'll set up a single group
... union of all editors

jeffH: Let's move all the docs to a single document
... but first just move Member Submissions in as single docs

<hubert-paypal> Hubert is levangongPayPal on Github

jeffH: and then do a conversion to bikeshed

nadalin: Meeting plans?
... Weekly meetings

<JeffH> if there is a pointer to guidelines for the github<-->W3C tooling, please post to public-webauthn@w3.org ?

nadalin: what is day or time everyone is available
... anyone from asia? We have some europeans
... FIDO calls are on Friday
... We'd start next week

ok, will send a Doodle out re Monday/Tuesday/Wednesdays

early pacific/late Europe

Maybe will add a few Thursday/Friday options

nadalin: For our next f2f
... we are thinking May Berlin
... next to FIDO F2F
... Monday May 9th
... will propose that to the list
... the next meeting would likely be Lisbon in Sept.

selfissued: I'd prefer Friday, I have a speaking commitment on Munich

nadalin: Will send to list
... the next F2F is likely 3rd week of Sept. in Lisbon
... (Portugal)

scope

nadalin: Here's a set of use-cases
... not normative, but guiding
... will lead us into what we are doing
... what's out of scope
... multi-origin, federated identity, crypto-operations on keys

<JeffH> FIDO and Federation: https://docs.google.com/presentation/d/1_j6EYJZT_iT0LyLe_ErUS-Zxo6W93fmkqq1lhvnNqMM

harry: note that you should be able to use FIDO with federated identity
... just using authorization (i.e. OAuth)
... and the IETF is already thinking of this

wseltzer: We will keep this group focussed

rbarnes: Note that client cert exposed to multi-origins is explicitly out of scope
... some of the stuff keiji brought up, including signing other kinds of things
... is out of scope
... standard won't define UX

nadalin: we'll also have a test-suite
... and any informative reference

adam_powers: I'm happy to write tests
... just give me implementations

we will discuss making sure people that make tests like Adam

can get IE status

dependent on employer s

nadalin: There's been continued discussion on specs
... and so we need
... to move stuff from private github

<scribe> ACTION: Move issues from FIDO Github to W3C Github via proper channel [recorded in http://www.w3.org/2016/03/04-webauthn-minutes.html#action01]

<trackbot> Sorry, but no Tracker is associated with this channel.

trackbot, this is the future

<trackbot> Sorry, harry, I don't understand 'trackbot, this is the future'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

alexei: There are 50 issues
... typing between relying party and authenticators
... then we can close them in FIDO

wseltzer: we can use labels to classify them

<wseltzer> [short break]

Workflows in github, and reviewing issues in FIDO repository

<wseltzer> alexei: In FIDO, we've used OKtoDo, Discuss status

<wseltzer> alexei: 176 discuss

<wseltzer> ... 175, not for W3C

<wseltzer> ... 173

<wseltzer> Rolf: for me it's OKtoDo

<wseltzer> alexei: I don't fully grok this

<wseltzer> ... let's mark it as Discuss

<wseltzer> alexei: 172

<wseltzer> ... discuss

<wseltzer> ... 171

<wseltzer> Rolf: Just do it

<wseltzer> alexei: 169, OK

<wseltzer> ... 168 just do it

<wseltzer> ... 167, discuss

<wseltzer> ... 166, just do it

<wseltzer> ... 165, discuss

<inserted> scribenick: jcj_moz

gmandyam: 165: Not worded as a proper W3C issue?

alexei: Feel that having W3C talk about android seems wrong

harry: If it is indeed android specific, the general purpose rule should be that FIDO 2 stuff that goes to W3C, should make sure there are no dependencies that pulls Android into the W3C spec

alexei: Define a better abstraction for attestation

rbarnes: Spec suite for this WG needs to be largely complete; go through the whole process without relying on an external spec (unless it's normative -Mike)

Rolf: Have to somehow reference other specs like TPM

rbarnes: Good general discussion we could have regarding what the general interoperable profile should be

juanlang: Since we're having technical discussion, this is a point we should discuss

SamSrin: Intent of attestation proposal is to slot multiple forms into a generic proposal. Permit large islands to do their own thing.
... Don't want to get into Android / iOS, but give a generic spec

rbarnes: I'm realizing I confused attestations with assertions.
... Attestations not critical path
... Assertions are more important to be interoperable

[Harry is creating the issue[

alexei: 164, skipping since it's related to last issue
... 163, this needs another issue
... figure out the correct interface between CTAP and WebAPI

Vijay: Seems like a 'just do it'

alexei: OK to-do.
... 162, okay to do

^-- that was rbarnes

alexei: 161, clear the milestone
... 160, attestation, skip
... 159, close
... 158, discus

156, remove milestone

scribe: 155, account deletion, discuss

anthony: Or just remove milestone and not discuss

alexei: 154, discuss (it has a lot of text)
... 151, dangling references. Closed
... 150, a bunch of tags...

JeffH: 150, i would say okay to do.

rbarnes agrees and suggests adding to the WebAPI

alexei: 150: okay to do
... 148, okay to do
... 142, this is tied to deletiong

JeffH: We can reference this together with the deletion

alexei: 142 mark as discuss
... 140, Rolf asks for discussion.

Rolf: This must be unqiue globally

alexei: 140 we must discuss it
... 139, just do it
... 137, CTAP layer... there is no cancel in the WebAPI

JeffH: This is more about the effect on the Authenticator. Pull this milestone and reclassify

alexei: Should it be in the algorithm?

JeffH: we should open another issue.

alexei: 137 then discuss
... 136, discuss
... 135, mark as discuss
... 134, discuss b/c block of text
... 133, non-normative, just do it
... 132, recommend closing because we can't predict the future?

rbarnes: Closing this seems fine to me

JeffH: Clear the milestone

alexei: 131

Vijay: Provide a use case that doesn't rely on passwords

alexei: 131, OK to do, clarify it

130, remove milestone

alexei: ... 114: okay to do
... 108, Vijay says reference cleanup which is fixed if merging them all. Okay to do
... 108, remove the milestone
... 105, Duplicate of account deletion in 155
... 92, discuss
... 91, already done
... 87, okay to just do it.
... 74, discuss
... 71,

rbarnes: Already been closed twice!

JeffH: I'm taking care of it. I'll make it go away.

alexei: 39, going to get merged

rbarnes: is there any objection to merging the 3 documents?

<harry> Note I just added the three FIDO 2.0 to github

<harry> Hey, fill out the Doodle for our telecon: http://doodle.com/poll/srrmafhft29cudav

wseltzer: Is there any chance of them moving forward out of sync?

mike: Request: the editor that does it, flag the text so it's reviewable, so that nothing gets lost and that which gets added is in sync
... with that caveat, I'm OK doing it

JeffH: issue 39 closed

alexei: Going to open another issue to merge all the documents
... issue 4!

<wseltzer> wseltzer: thanks to our host, chairs, and all participants!

<wseltzer> [adjourned]

- DRAFT -

Web Authentication WG

04 Mar 2016

Attendees

Contents