Web Authentication WG F2F -- 13 May 2016

<inserted> scribenick: wseltzer

tony: Welcome
... looking at timeline, we have a year charter

<selfissued> Mike Jones

tony: want to get issues closed by the end of the year
... by TPAC, in September, we'd like to have our work finalized

https://www.w3.org/2016/09/TPAC/

tony: we will have a WG meeting at TPAC
... we'll also meet with WebAppSec

-> https://www.w3.org/2016/09/TPAC/schedule.html TPAC schedule

[[ Tuesday 20 September is Webauthn meeting]]

tony: we want to walk out with two things, FPWDs and a timeline for next steps

rbarnes: let's talk about status, how we got to now

Status

<inserted> Vijay's slides

vgb: I'm going to review goals and status
... feel free to interrupt
... Diagram: user, client, relying party
... at a high level, RP wants to ask the client, "does human user X want to do action Y?"
... client should be able to ask permission, user give permission
... RP gets crypto assurance that an actual human said yes; and an assertion of level of trust on that assurance
... user authenticator
... a black box the user interacts with, protected
... user authenticators today include embedded authenticators
... built into the device, e.g. fingerprint sensor, camera, code entry
... there, user interacts directly with the client; maybe the device has an enclave
... confidence in assertion depends on your confidence on level of protection
... second type, external authenticator; hardware separate from the device
... interact with client in different ways
... they roam, to multiple different clients
... hybrid, using the phone as authenticator for the laptop
... Goals: provide end-to-end secure user authenticaiton for the web
... enable RPs to trust that a human did something
... reason to adopt this API is to interact with the existing devices out there as authenticators
... encourage rapid adoption
... At least 3 of us have built JS APIs on top of existing authenticators
... we're not starting from a blank page, but learn from previous efforts

@@2: This doesn't preclude native clients?

vgb: no, it doesn't. We're talking at W3C about the Web platform
... underlying OS has its own platform
... if we capture the right level of abstraction, it's likely that native APIs will look similar
... but that's not our charter

gmandyam: native apps can use webview

vgb: web platform isn't just web browsers; it's browser engines, libraries you can build into native apps

SamSrinivas: If we get work here done right, it's a strong incentive for others to use the APIs
... so the same keys work across platforms

vgb: authentication is one step; it's important then to stitch together with other pieces
... We want to bootstrap with existing authenticators, and also enable new capabilities

rbarnes: goal is to create a level of abstraction that's compatible with some of the past and what we want to enable in the future
... incorporate and build on

vgb: we don't have to take along the authenticators that aren't good enough
... but start with some
... Where we started: FIDO specs submitted to W3C
... FIDO realised, we should come to W3C for Web platform standards
... contributed 3 specs, Web API, Signature format (proof of consent), Attestation (crypto statement saying how much to trust the authenticator)
... FIDO continues work, developing the authenticators
... protocols for talking to authenticators, hardware certification
... very roughly, Webauthn is RP-Client interaction, while client-user communications are specified in FIDO
... this group started in February
... We got feedback that 3 docs together weren't clear
... so first we (Dirk) combined the documents
... a single document, with three logical parts
... added a glossary

-> https://w3c.github.io/webauthn/ Webauthn editor's draft

vgb: renamed things, JC did lots of work there
... bikeshed, fix WebIDL

<scribe> ... ongoing: discussion with W3C TAG

UNKNOWN_SPEAKER: technical architecture group, reviewing the design of the spec
... working with them on RP separation issue
... active dialog within WG on right level of abstraction, explanation

vgb: Three parts of the spec: API, Authenticator model, Extensions
... API: for the developer; we're paying lots of attention to UX, security for the user, privacy; flexibility for extension
... Authenticator: developers can skim it, coding the server back-end for validation
... goal is to provide logical model, clarify how it's exposed to the platform; interop

@@3: No notion of FIDO server?

vgb: goal is to capture in the authenticator model all the things a server would need to know
... W3C doesn't define business logic

rbarnes: goals isn't to specify what server should do, but what it should expect from the client (authenticator via the browser)

vgb: something a web developer can read and understand what's going on, interoperate

@@3: this comes from FIDO 2.0, which has the notion of server

tony: server doesn't provide attestation
... other parts are still within FIDO Alliance

vgb: FIDO metadata service, a service that provides some side information
... some info you can access in many different ways; we're not going to mandate where you get it
... give you something as an identifier

rbarnes: as vgb said, this API is designed to have compatibility, with existing and new authenticators that fit the model

vgb: third part, Extensions
... Extensions: advanced stuff, without advance determination what things might be there
... we tried it out by trying to describe some extensios in the spec
... in the future, anyone should e able to publish an extension, anywhere, and have it be interoperable
... All our work is documented in github
... with all the logs of commits and issues addressed
... when we started, we gave issues milestones, FPWD or later
... we have no remaining FPWD milestone issues
... it's my understanding the group believes we're now at a point to invite wide review
... we're confident in the direction fo the spec, ready for more eyes
... remaining issues, but not fundamental changes of direction
... e.g. top-level window or navigator, names
... credentialType vs version
... optional parameters -> dictionary?
... but these issues don't change the basic abstractions
... so implementers should review in detail to see if it's internally consistent, implementable
... goal to do another few iterations
... Next steps: get FPWD announced soon
... expect at least one more rev where the API changes
... goal to get to implementation quickly, talk to implementers about what obstacles remain
... conclude by end of year

tony: I'd hope we can use TPAC to review implementations

vgb: we'd like to get a complete draft before TPAC, so we can discuss it there

vgb: lots of these authenticators are multi-factor
... factors in the realm of the authenticator
... these specs cover human consent, more than continuous authentication
... strong privacy concerns about something that doesn't prompt the user

sridhar_muppidi: dialog among parties; not just giving permission

vgb: lots of business logic on the server side
... e.g. at a bank, user giving consent is one signal among many
... the goal here isn't to taxonomy all the things RPs could do, but to provide an ingredient
... and to specify it completely and interoperably

rbarnes: compare WebRTC, there are many components it takes to create a phone; goal is to create primitives

sridhar: simple scenario, authenticate, then want to send a push notification
... how do we map the pieces, W3C, FIDO, OpenID Connect...

JeffH: in terms of how this composes with federated identity, all thosse specs say authentication fo the user to IDP is out of scope, this fits there

sridhar: you may want an additional level of challenge
... e.g., embedding a policy for authentication
... can we walk through a simple scenario?

selfissued: authentication context class references, adopted by OIDC
... a place in the authentication request to say "please use this business policy"
... authzn server (IDP) replies back with a token saying I did or did not use that policy
... glue, with respect to FIDO, define one or two policies that use of authenticators with various characteristics would satisfy

vgb: we've tried to walk through a very simple scenario end-to-end and see how it would work
... it would be valuable if people with more complex scenarios would work through them too

sridhar: I want to get rid of complex custom scenarios
... where do I use webauthn?

Kamal: GSMA working on mobile authenticators, work with FIDO

vgb: if those scenarios reveal problems with this spec, bring them back
... that's probably from review at the next level of detail
... keep in mind scope of this group, not trying to specify federation, frameworks

rbarnes: we do have an issue to add an explainer doc
... that could help

vgb: We're looking for volunteers

sridhar: I'll help

Kamal: can anyone use APIs, or is certification required?

wseltzer: anyone who can interoperate can use the API

vgb: we've written a JS shim

rbarnes: we'll talk about schedule and likely evolution in a bit
... if you're writing to the API, think about how much churn will happen right now, and we'll send signals when things settle down
... Moz is also implementing

FPWD

tony: we'd like to move to a consensus call to move this to FPWD
... does anyone have any issues?

selfissued: I hear a lot of demand for a public draft

PROPOSED: Move webauthn to FPWD

selfissued: so moved

JeffH: second

<rbarnes> +1

wseltzer: Process-wise, we CfC here, then send to ML

SamSrinivas: I think the attestation needs to be simplified dramatically. Does FPWD preclude that change?

wseltzer: no, we can still make techncal changes

gmandyam: patent exclusions here too

wseltzer: Patent policy @@

SamSrinivas: we shouldn't take momentum from FPWD to keep things complex

tony: the group will decide that.

RESOLUTION: Move webauthn to FPWD, put CfC to list

tony: we'll send to list with one week from today

gmandyam: even fi there are objections, you don't need to resolve them, just document them

tony: so a week from now, we should be able to put out FPWD

<scribe> Meeting: Web Authentication WG

[15 min break]

[return]

<inserted> scribenick: JeffH

Token binding

Dirk Balfanz holding forth...

https://tools.ietf.org/html/draft-ietf-tokbind-protocol

https://tools.ietf.org/html/draft-ietf-tokbind-https

<rbarnes> giri: this? https://tools.ietf.org/html/draft-thomson-http2-client-certs-00

<rbarnes> i don't think that's addressed at the same thing

Giri: asks about whether some present work ion client certs in http is relevant here

dirk: will have to familiarize with it and think about it....
... token binding specs superseed the prior channel id internet-drafts

<gmandyam> A comparison to http://www.ietf.org/id/draft-thomson-http2-client-certs-02.txt would be useful. Seems to address the concern about client cert being sent via TLS.

hubert: asks how this is different from tls cert pinning

<wseltzer> tony: looking for volunteers to review draft, write explainer text

<wseltzer> Alexei, Adam, Mike, Jeff, Giri volunteer to review

jdirk/jeffh: tokbinding is making replay of protocol objects detectable, where channel binding is about ensuring client can detect MITM when tls channel established

wseltzer: additional context wrt W3C process, what FPWD means, pub of subsequent WDs...

FPWD triggers "wide review", CR is next major milestone, attaining it reqs "wide review"

scribe: eg review by those listed in webauthn charter have indeed reviewed...
... we are obliged to tug sleeves...
... we will send explicit reqs to those groups soliciting review...

FPWD gets us pub'd in w3.org/TR/webauthn/

scribe: we can refresh w3.org/TR/webauthn/ as we go along...we are working towards CR...implementors should be warned that this is unstable
... CR implies API stability
... thus we can snapshot editors' drafts to /TR/webauthn as appropriate
... the WG needs to decide criteria for such snapshots
... eg can establish milestones for such snapshots and assign issues to milestones and do snapshot when the issues have been closed

rbarnes: any objs to this plan?
... <none heard> thus we'll do that

TonyN: so.... with that we'll have Adam Powers discuss his work on tests

RESOLUTION: We will publish WD from "milestone" labels when all the issues for a milestone have been closed

Testing

AdamP: need to discuss what tests should do and what to test
... should we be testing that sigs are verifiable ?

rbarnes: we should test what's defined in the spec, thus testing sigs is in scope

mikej: we need to test both good and invalid things....

giri: how's webcrypto tests working?

rbarnes: they are working on fleshing out their test suite

wseltzer: they are yes dvlp'g more full-fledged tests .... overall goal of a test platform is that the w3c can determine whether we have interoperable implementations of the spec's features
... if we write good tests, it helps ensure consistency of the web platform

rbarnes: [something wrt webcrypto not being a good example at this time..]

rbarnes/adamp: ...maybe using webcrypto for our tests not good idea at this time....

tonyn: what is w3c IP rules wrt contributed test tools ?

rbarnes: we do define an authnr model, so can test "underneath" the browser that verifies what is sent in to authnr is correct....
... can probably have two classes of tests what goes into authnr, and one is input from and output to the Webauthn RP's webapp client

rolf: webapi passes things thru from WRP code to authnr, and authnr output passed back thru webapi to WRP code
... so some things, eg authnr itself, are outside scope of W3C

mikej: is impt to have test tools for the clients of webauthn api -- eg if we can emit bad sigs from webauthn api, we can test client behavior --- so for health of overall ecosystem we need such tests....

vijay: i want to sep two things, (a) it is in scope to claim compliance with the spec that emitted sigs are correct, (b) ..?.. -- wrt mke's suggestion that is testing my test suite

sam: we test against a known-good authnr.....a way to shake out all needed test cases, verify that all the data passed to API gens expected results
... eg in chrome we support USB authnrs, possible to have known-good authnr, and all probs server has are server problems

mikej: w/o getting in to details i think it is impt to test both success paths and error-handling paths

rolf: we would not expct JS to verify sig -- it gets sent to svr to validate....

rbarnes: but it is not in our scope to dictate that the JS sends to a server vs do things on its own....
... all we need to test is that the api is faithfully passing thru objects -- will be impt to use a authnr and verify that the results are as expected
... ie anything the user agent does is in-scope, and part of what the authnr does is a;lso in-scope because it is spec'd in the spec

mikej: have a bunch of experience with eg saml federations, a bunch don't check sigs on assns.....

vijay: we are not spec'g the RP behavior so why are such tests in scope

mikej: it is impt that servers-side get tested at an ecosystem level

rbarnes: not sure how a generic test can be made for RPs

mikej: a way to do in practice is that you have a webauthn api impl that has a synthetic authnr that generates test sigs that have known properties and test whether they are properly detected by the RP impl....

rbarnes: hm, things like that might be approp to include in the test suite....
... and spec out the sort of things that mike is talking about

adamp/mikej: framework for testing RPs is diff than one to test webauthn api, tho it is impt from ecosystem perspec

rolf: here in w3c we need to test the browser webauthn api impl

giri: fido is going to do cerification, might not address all of mikes goals but is step in that direction.....

adamp: tho we fido could possibly make some things broadly available

vijay: as mater of practicality, if we have some code that verifies assn emitted u have some useful assurance, it seems like having tests of your webauthn that depends on webcrypto is ok is reasonable because you'll run webcrypto tests too at some point
... and there's way to automate things --- so we can separate some of these test suite problems

adamp: sure, works for me

rbarnes: volenteers JC to help adamp with some of this

vijay: we have tests in w3c context that tests webauthn api, and then over in [fido] we will have approp tests for other portions of ecosystem....

tonyn: so at next F2F in sep, we'll be calling for impls and they'll need test suite

rbarnes: so btwn CR and PR is the window where tests will be used

adamp: ok so will start test plan

<wseltzer> https://hiptest.net/

adamp: will do it at hiptest.net

<rbarnes> apowers: also, thanks a lot for working on this. as WebCrypto shows, it can be really hard to get people to work on tests

tonyn: we have further disc topics for the day, eg wrt Attestion, Srido's use cases

Scenarios

<wseltzer> sridhar: scenario 1, login, then push notification to the device

srido: wrt use cases, start small..... user goes to RP, get challenged for uname&pswd, employs a device that is previously registered (of variosu possible modalities)
... how does this spec hope to address that... have a diagram that helps people understand....

<gmandyam> Note that FIDO produced an informative architecture specification 2 years ago: see https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-overview-v1.0-ps-20141208.html.

<gmandyam> This could be an informative reference in the WebAuthn spec, as opposed to putting a whole "explainer" section into the specification.

<AxelNennker> I have to leave. Sorry. One of the drawbacks when meetings are in the town one works. See you on the phone and Lisbon

srido: authn, validation, followed by continuous monitoring and re-authn as necessary

alexei: this is interesting and perhaps you should raise these items in the fido alliance in their deployment at scale WG....

tonyn: when we did xmldsig, we needed some of this explanatory info, a question is where is recorded, am fine with an explainer doc....

sirdo: the above was the 1st scenario

srido: 2nd scenario: user going to RP, RP has risk engine, and based that he suddenly appears in .de and we don't trust that as much, i may want to demaind two-factor authn at this time to get started....
... once authn'd things proceed.....but then want to do a high-value transaction.....so RP wishes to do 'step-up' challenge-response

vijay: yes, we've talked about this in webauthn context, i'm RP, ask for consent, get back something that I don't think passes muster, then RP can make step up request, eg a non-webauthn challenge-repsonse, and this is natural in webauthn flows
... so it is an impt and possible extension

tonyn: it will be the server that makes the decision whether the presented authn assn is sufficient
... RP may accept it or request further authn

srido: a bulid on this acenario is: rp says i need voice-based step-up, but am in noisy environm, so can switch to face-based
... last scenario: have custs that belive some of the validation needs to be on sever-side, eg w/biometrics, FIDO isn't sufficient/approp, how do we do this in combo with webauthn

giri: well there is w3c device and sensors WG maybe that can provide means ?

srido: there are custs that are doing both client-side and server-side biometrics and how do we take advantage/combine them....?

Issues

<wseltzer> Open issues in github

<wseltzer> vgb: Major class of issues: errors are underspecified

<wseltzer> ... also lots of editorial things that don't require much discussion

<wseltzer> ... start with things marked discuss?

<wseltzer> https://github.com/w3c/webauthn/issues?q=is%3Aissue+is%3Aopen+label%3Astat%3ADiscuss

tonyn [ ...tries to moderate unruly hungry hordes.... ]

tonyn: ok, we are on pre-lunch break now....

<wseltzer> [pre-lunch break]

<inserted> scribenick: wseltzer

[meeting resumes]

Vijay is reviewing issue labels and deleting unnecessary labels

https://github.com/w3c/webauthn/issues

https://github.com/w3c/webauthn/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc

Issue review

vgb: as we discussed earlier, we'll have at least one more draft with technical changes
... before we hit CR
... Candidate Rec is when we say we believe all technical issues are settled
... We're aiming for one more draft to iron out issues
... I'm going to close the FPWD milestone

[applause]

vgb: things that go into WD-01 are technical issues, or editorial issues so heinous we don't want to let the spec go with them
... other things are CR
... the two labels that are most useful: OKttoDo -- the group has decided it's ready, whoever wants to do it
... Discuss, to flag for discussion before coding a pull request
... 47 issues to go

https://github.com/w3c/webauthn/issues/6

vgb: I think we'd do this one differently today
... we don't have a way for authenticator to hint to the platform how it's accessible
... today, I think we'd call this request for extension

dirkbalfanz: you want to give a hint to the UA how to communicate with the authenticator

vgb: do we agree this should be in the next WD?

alexei-goog: yes
... we should explain how to do it either in extension or parameter

https://github.com/w3c/webauthn/issues/8

vgb: let's try to close out RP-ID

https://github.com/w3c/webauthn/issues/11

editorial

https://github.com/w3c/webauthn/issues/12

editorial

https://github.com/w3c/webauthn/issues/13

editorial

https://github.com/w3c/webauthn/issues/14

alexei-goog: I think credential ID covers this

https://github.com/w3c/webauthn/issues/17

vgb: a request for delete
... if we were to add a delete method, that would be a technical change
... I don't know how to fix this ... authenticator may not be listening
... also, many authenticators have no local state (U2F)
... delete can do nothing

alexei-goog: think of bluetooth pairing; if you want to unpair phone from laptop, you do it from the phone
... if the authenticator knows the credential, should be able to delete
... but not a matter for the RP

tony: there should be some explanatory text

gmandyam: what is the harm from leaving the credential ID when it's been deleted from the server
... I can't think of any harm
... so if deleting isn't enforceable, and there's no harm to leaving, let's close

Ketan: can you DOS the authenticator by storing too many keys?

vgb: every make credential requires user gesture
... that's a natural limiter
... depending on the bad guy to clean up after himself, because it's origin-bound, seems unhelpful
... it woudl need to be out-of-band

https://github.com/w3c/webauthn/issues/18

vgb: duplicate of 17

https://github.com/w3c/webauthn/issues/22

vgb: editorial

rbarnes: it's possible that we'll have a world where some authenticators don't involve user interaction
... so then you'd want the bit
... clearly define the bit

Rolf: we haven't yet defined clearly what we want to require
... we need to do that

rbarnes: if you want to know exactly what the device is doing, you need attestation
... at this general layer, you need a description

https://github.com/w3c/webauthn/issues/25

rolf: makeCredential is issued by server, timeout issues
... if it times out, generated credential can't be sent back ot the server
... then you have a keypair sitting around that can't be deleted
... an alternative way to avoid multiple credentials sitting around
... reuse credential if there's one available, or delete and overwrite, when asked to reate

vgb: because account info passed in, we could say, for unique set of account info, you can have only one credential id
... authenticator model could specify that
... you can't have more than one credential on a given authenticator for a unique set of account info fields

rolf: we never specified how to deal with multiple keys
... instead saying there will be only one key, it's the task of the authenticator to assure there's only one

dirkbalfanz: we say an authenticator should create only one keypair per credential ID

SamSrinivas: why is it different from losing authenticator?

gmandyam: key has been created, it's on the authenticator, there's a handle for it

rolf: it's dead, because challenge timed out at the server

SamSrinivas: recommendation to the authenticator vendor

gmandyam: multiple invocation of makeCredential

vgb: I propose we phrase "for a given authenticator, API caller has no right to expect that they should be able to create multiple credential IDs for the same account info."
... they shouldnt' be surprised if they present same info and get same credentialID or have knocked out the old one.

sridhar: did you discuss lost authenticators?

vgb: authenticator holds the private key, server holds pubkey; if authenticator is lost, deregister on the server

https://github.com/w3c/webauthn/issues/26

candidate for the "greatest hits album"

hubert: credential represents relationship between RP and user, belongs to both
... either party can sever

vgb: need a way for RP to sever
... it can do so by forgetting the public key
... marking duplicate

https://github.com/w3c/webauthn/issues/31

https://github.com/w3c/webauthn/issues/33

JeffH: still a bug

https://github.com/w3c/webauthn/issues/34

<apowers> tangential question: do we tag the repo when we move to review draft?

https://github.com/w3c/webauthn/issues/39

vgb: is there a reason?

rolf: lifecycle
... for bug fixes, you want to be able to version

alexei-goog: shouldn't metadata service do that?
... in password world, if you have a user who comes to you with compromised password
... you recognize them, decide whether o rnot to let them in, then whether or not to make them gen a new key

vgb: you could just give it a new GUID

rolf: then the association with the old key gets lost

SamSrinivas: adding something to every assertion isn't a good idea

https://github.com/w3c/webauthn/issues/40

vgb: if transport hints is extension, this is no longer relevant

alexei-goog: should we constrain the length of credential ID?

vgb: why?
... just let it go, say you're writing code, be defensive

jcj_moz: people writing server software want to know, so they can program database tables

vgb: add guidance text, should check lengths?

rbarnes: prefer being explicit about metadata and structure, as opposed to flat field
... don't prescribe length; apps shoudl be defensive

https://github.com/w3c/webauthn/issues/42

ECDAA with 512-bit keys

apowers: inconsistency between bits fo the documemnt

vgb: we have a different issue, stop prescribing what servers do

apowers: give authenticators some guidance
... look at issue 94

https://github.com/w3c/webauthn/issues/47

vgb: make it explicit that this is an example, metadata service may not cover all authenticators or attestations

https://github.com/w3c/webauthn/issues/51

JeffH: this issue is no longer relevant, changed to buffer source

jcj_moz: where do you learn what to do wth this?

vgb: it's lookup key into metadata service

[15 min break]

[resuming]

vgb: reviewing issues to mark them as WD-01

https://github.com/w3c/webauthn/issues/86

vgb: make it optional

rolf: self-signed attestation, shows acces to private key

rbarnes: new issue

vgb: discuss on-list, to resolve for -01

https://github.com/w3c/webauthn/issues/95

vgb: requirs update to normative processing steps

https://github.com/w3c/webauthn/issues/97

vgb: figure this out in -01
... what's the difference between 97, 98?
... is 97 still relevant if you have opaque data in 98?

gmandyam: if client doesn't drop it
... opaque data is by definition one that client doesn't understand

rbarnes: I'd put this in CR, as not likely to result in major tech changes

gmandyam: if 98 goes in, I can look at dropping 97

https://github.com/w3c/webauthn/issues/100

vgb: editorial

https://github.com/w3c/webauthn/issues/101

rbarnes: make sure we have an issue around attestation

https://github.com/w3c/webauthn/issues/107

vjb: -01

-> https://github.com/w3c/webauthn/milestones/WD-01 WD-01 issues

jeffH: what date do we want?

vgb: let's see in 2 weeks
... setting all the no-milestone issues to CR

Wrap-up

vgb: Currently, we're chartered for a year, so our charter runs out in February
... we need a Rec in Feb
... it takes 4 weeks to get from PR to Rec
... that suggests Proposed Rec mid-Nov
... we want to declare Candidate Rec, call for implementations, at TPAC September
... remaining question: how to work between now and Sept
... close out all the technical issues
... it woudl be good to do one spin of the wheel with no technical issues
... need at least one WD with all technical issues resolved
... in the July time-frame

rbarnes: with implementer hat,
... one fo the July milestones is "start writing code"
... to have some stuff on the ground at CR

vgb: also as implementer, start implementation in July

tony: do we have any commitments to do the implementation? resources in the July timeframe?

vgb: we still want to go to CR in Sept, have two implementations by Nov

rbarnes: removing barriers to implementation

selfissued: I was going to ask when we think we'll have 2 interop implementations to test

dirkbalfanz: it's probably easy for us to polyfill chrome
... right now, support for FIDO U2F

selfissued: wondering whether for the blog post, I can talk about multiple in-progress implementations

SamSrinivas: we might be able to say fast-start, since we have something already
... run it by us

rbarnes: you can say three implementers with active code bases

selfissued: will run it by the group

rbarnes: our next F2F is TPAC, September
... aiming to get to CR, closing out last issues

[discussion of Lisbon weather in September]

[adjourned]

https://www.w3.org/2016/09/TPAC/schedule.html

- DRAFT -

Web Authentication WG F2F

13 May 2016

Attendees

Contents

Status

FPWD

Token binding

Testing

Scenarios

Issues

Issue review

Wrap-up

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output