– DRAFT –
Web Authentication Working Group

Face-to-face 2024-04-19

<elundberg> agl: on track, no signup yet but will send out attendance survey

<elundberg> plh: transferring my role to Simone Onofri

<elundberg> #2020

<elundberg> rolf: shouldn't be any worse than today

<elundberg> MatthewM: is the name abbreviated because of authenticator processing?

<elundberg> ...new name is "confirmation" extension

<elundberg> JohnBradley: saving bytes is important for authenticators in constrained hardware, with limited size buffers

<elundberg> Sweeden: some references to "txAuthSimple" or the like still remain

<elundberg> ...i.e. CollectedClientTxAuthSimpleData

<elundberg> MatthewM: I'm happy to move this forward

<elundberg> nadalin: Is there interest from more than 1 browser to support this?

<elundberg> agl: L3 or beyond?

<elundberg> ...there is interest, but [as for Chrome] not within L3 timeline

<elundberg> TimCappalli: should be enough implementations with ~1 browser and a couple of browser extensions/etc

<elundberg> agl: Chrome on Android would likely pass this through at some point, Chrome on iOS is not up to us

<elundberg> ...Windows does not yet have a pluggable provider interface

<elundberg> JohnBradley: Windows update cycle is ~6 months to a year

<elundberg> nadalin: sounds like this is unlikely to land in L3

<elundberg> Rolf: still interested in moving this along

<elundberg> nadalin: any password providers interested?

<elundberg> AndersÅberg: Bitwarden has no position yet

<elundberg> ...there is some interest

<elundberg> Rolf: need platform support to drive interest, and interest to drive platform support

<elundberg> #2023

<elundberg> my bad

<elundberg> #2033

<elundberg> nadalin: looks good to go

<elundberg> ...any other changes to editors/contributors?

<elundberg> elundberg: what's the difference between editors and contributors?

<elundberg> ...or rather, how do we make the difference

<elundberg> nadalin: contributors come with/draft ideas, editors make lots of text changes

<elundberg> ...no specific responsibilities of an editor, help churn the spec through process when that needs to be done

<elundberg> Nina: reading the W3C definition it seems like most of our "contributors" should be listed as "authors", but I don't think it matters much

<elundberg> simone: chairs appoint the editors

<elundberg> nadalin: merging #2033

<elundberg> #2017

<elundberg> elundberg: working on it

<elundberg> agl: changing to "code point MUST be removed" would make some implementations non-compliant

<elundberg> ...(client implementations)

<elundberg> ...but we _can_ make breaking changes between levels

<elundberg> ...Chrome would be find with that change

<elundberg> JohnBradley: nothing would change for authenticators

<elundberg> nadalin: could still cause problems

<elundberg> JohnBradley: what problems? it's causing problems now by doing the wrong thing

<elundberg> elundberg: what won't change is that for RPs, 64 bytes is the max without getting unpredictable results

<elundberg> #1954

<elundberg> w3c/webauthn#1954

<elundberg> DavidW: still pending, waiting for a workable example

<elundberg> ...#1953 awaiting review from JohnBradley

<elundberg> ...can synthesize an example, but want to wait for an actual prototype implementation

<elundberg> nadalin: #1953 is ok to merge

<elundberg> #1951

<elundberg> w3c/webauthn#1951

<elundberg> pascoe: pending review

<elundberg> #2040

<elundberg> w3c/webauthn#2040

<elundberg> ...restricting the origin to a single domain is too limited for some deployments

<elundberg> ...this would allow hosting a list of allowed origins at a .well-known URL

<elundberg> ...there is a recommended cap of 5 "labels" (i.e., domain minus eTLD)

<elundberg> ...unlimited number was considered too permissive, 5 was selected as a reasonable number

<elundberg> Sweeden: if this is a SHOULD, could client implementations set a lower limit?

<elundberg> agl: 5 should be the minimum

<elundberg> TimCappalli: would Apple support 5?

<elundberg> Pascoe: no comment

<elundberg> MatthewM: why /origins and not just /webauthn with a doc we can extend later?

<elundberg> agl: array is not a valid JSON root

<elundberg> TimCappalli: we considered merging with similar things for the passkey migration protocol, but these things seem unrelated enough

<elundberg> MatthewM: [passkey management?]

<elundberg> TimCappalli: separate spec outside of WebAuthn

<elundberg> Sweeden: seems reasonable to make it a shared .well-known/webauthn instead of separate endpoints

<elundberg> agl: my mistake, array can be a JSON root

<elundberg> DavidW: should be a JSON object root for extensibility

<elundberg> JohnBradley: we can create a registry for defining new properties

<elundberg> TimCappalli: changing to an extensible multi-purpose doc is a substantive change to the PR, might take a while

<elundberg> ...needs a new section to define the multi-purpose doc

<elundberg> MatthewM: how specific/single-purpose do other .well-knowns tend to be?

<elundberg> Sweeden: fairly general, I would support a single extensible endpoint

<elundberg> agl: we could postpone extracting a standalone section until we do define additional properties

<elundberg> Nina: a single endpoint could help with caching too

<elundberg> nadalin: hearing consensus for a single extensible endpoint

<elundberg> ...will this impact the other .well-known for passkeys in webbappsec?

<elundberg> TimCappalli: consider that unrelated for now

<elundberg> nadalin: adjourn