See also: IRC log
<inserted> scribenick: wseltzer
... 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
tony: we will have a WG meeting
... 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
<inserted> Vijay's slides
vgb: I'm going to review goals
... 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
... 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
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
... 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
... 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
... 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?
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
... 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
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
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]
<inserted> scribenick: JeffH
Dirk Balfanz holding forth...
<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
... <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
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
... 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
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
<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
... 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
... 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....?
<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?
tonyn [ ...tries to moderate unruly hungry hordes.... ]
tonyn: ok, we are on pre-lunch break now....
<wseltzer> [pre-lunch break]
<inserted> scribenick: wseltzer
Vijay is reviewing issue labels and deleting unnecessary labels
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
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
vgb: I think we'd do this one
... 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?
... we should explain how to do it either in extension or parameter
vgb: let's try to close out RP-ID
alexei-goog: I think credential ID covers this
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
... 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
vgb: duplicate of 17
rbarnes: it's possible that we'll
have a world where some authenticators don't involve user
... 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
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
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
... it can do so by forgetting the public key
... marking duplicate
JeffH: still a bug
<apowers> tangential question: do we tag the repo when we move to review draft?
vgb: is there a reason?
... 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
vgb: if transport hints is extension, this is no longer relevant
alexei-goog: should we constrain the length of credential ID?
... 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
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
... look at issue 94
vgb: make it explicit that this is an example, metadata service may not cover all authenticators or attestations
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]
vgb: reviewing issues to mark them as WD-01
vgb: make it optional
rolf: self-signed attestation, shows acces to private key
rbarnes: new issue
vgb: discuss on-list, to resolve for -01
vgb: requirs update to normative processing steps
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
... 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
rbarnes: make sure we have an issue around attestation
-> 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
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
... 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,
... aiming to get to CR, closing out last issues
[discussion of Lisbon weather in September]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) WARNING: Bad i||| command: i|going to review goals and status Succeeded: i|going to review goals and status|-> https://www.w3.org/Webauthn/slides/WebAuthnAPIStatus-vgb.pdf Vijay's slides Succeeded: s/useful test coverage/interoperable implementations of the spec's features/ Succeeded: i/Token binding/scribenick: JeffH Succeeded: i|tony: Welcome|scribenick: wseltzer Succeeded: s/@@4/Ketan/ Succeeded: s/bi/bit/ Succeeded: i|[meeting resumes]|scribenick: wseltzer Found ScribeNick: wseltzer Found ScribeNick: JeffH Found ScribeNick: wseltzer Inferring Scribes: wseltzer, JeffH Scribes: wseltzer, JeffH ScribeNicks: wseltzer, JeffH Present: Juan_Lang Mike_Jones Axel_Nennker Alexei_Czeskis Sam_Srinivas Vijay_Bharadwaj SooHyung_Kim Sangrae_Cho Seung-Hun_Jin Sridhar_Muppidi Kamal_Shah Ketan_Mehta George_Tang Axel_Nennker Rolf_Lindemann Adam_Powers John_Fontana Aiki_Matsushita Atsuhiro_Tsuchiya Koichi_Moriyama Hubert_Le_Van_Gong Jeff_Hodges Giridhar_Mandyam J.C._Jones Dirk_Balfanz Tony_Nadalin Richard_Barnes Wendy_Seltzer;_by_phone:_Adam_Cooper Agenda: https://github.com/w3c/webauthn/blob/master/meetings/2016-05-13-Berlin-f2f.md Got date from IRC log name: 13 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/13-webauthn-minutes.html People with action items:[End of scribe.perl diagnostic output]