– DRAFT –
Web Authentication weekly

Working Group General Business

<steele> PLH: Are we still happy with the state of our test suites?

<steele> Adam: Tests are written before anything is written in chromium, so we have w3c tests in front of everything

<steele> PLH: If we're happy with tests, then happy to drop it for now

<steele> PLH: Any reason why we need to have the Decentralized Identifier WG as one of our dependent groups? We haven't interacted with them in a while.

<steele> Tony: It was put in there as a placeholder

<steele> PLH: Okay, let's drop it

<steele> PLH: Should we have care about Federated Identity WG?

<steele> (in the charter)

<steele> Tim: I think there's interest in having intersection

<steele> Tim: it's in the proposed WG charter and CG charter that there's overlap

<steele> PLH: Yeah, I'm asking if we should add it

<steele> PLH: Do we want to switch to a more liberal license? We've been using the same license for 2 years that restricts things like copying the spec

<steele> Tim is unsure what license means in the context of a public specification, as am I

<steele> PLH: The license is mostly around the copyright of the spec

<steele> ...most other working groups have caveats that allows for things like the ability to fork a spec

<steele> Adam: I thought we agreed on this last time

<steele> DavidT: I also thought so, I believe I checked with FIDO as well and they were on board

<steele> PLH: Okay, then we'll go ahead with reviewing/changing the license

<steele> PLH: We should have a new charter in about 2.5 months

<steele> That's all general business

Pull Requests

<steele> w3c/webauthn#1954

<steele> Pascoe: My internal contact said this is okay

<steele> DavidWaite: This should be good to go

<steele> Tony: Emil are you good with this one?

<steele> Emil: we added an example in 53, unmerged yet

<steele> w3c/webauthn#1953

<steele> Need to add examples

<steele> w3c/webauthn#1951

<steele> Pascoe: I've addressed comments on this, most of the outstanding comments have been addressed. Emil if you could please review

<steele> Tony: Nick have you reviewed?

<steele> NickS: yes, but let me formally LGTM the PR

<steele> Adam: I'll defer to Nina on this PR

<steele> w3c/webauthn#2027 by Emil

<steele> Emil: This just fixes a numbering of steps

<steele> Matthew just approved to help speed the request

<steele> Adam and Nick approve

<steele> 2027 has been merged by Emil

<steele> w3c/webauthn#2018

<steele> Anders: Nina had good feedback

<steele> Nina: Merge it

<steele> NickS merges with no disagreement

<steele> w3c/webauthn#2019

<steele> Adam: Nina are we okay with this?

<steele> Nina is okay with some amount of pedantry

<steele> A quick fix has been added

<steele> Tony: Any issues merging?

<steele> None

<steele> NickS merges

<steele> w3c/webauthn#2017

<steele> Emlin: I still have some issues to address on this PR

<steele> Tony: is there any problem having this for L3?

<steele> Emil: this should probably be part of L3, yes

<steele> no dissent

<steele> w3c/webauthn#1926

<steele> Tony: No known movement on this

<steele> Shane: I've talked to Ackshay, he's reached out to his internal contacts again, but says if we don't get a reply, we should arrive at our own interpretation

<steele> Tagging Monty Wiseman for his opinion

<steele> w3c/webauthn#2020

<steele> Tim: is this going to be duplicate to Google's extension?

<steele> ...it looks like Christiaan worked on it as well

<steele> unclear

<steele> John: Comes down to what are browsers comfortable with presenting in secure Chrome that's coming from the verifier? The problem we had in the past is that browsers said "no, we're not going to show an arbitrary string""

<steele> JohnB: If browsers have changed their mind on showing potentially unsecured strings in the browser then hooray we can move forward with this.

<steele> Shane: when I first got involved in L1, I thought these extensions were cool and then they never got used, and I was sad :(

<steele> Shane: and now they're back and I think they're really cool and want to use them :)

<steele> Tony: Has anyone talked with WPWG folks on this?

<steele> JohnB: I imagine this is known

<steele> Shane: I still a place for a simple extension like this

<steele> Shane: and a place for one with rigid structure characteristic ones like payments

<steele> Nick: this would be easier for some passkey providers, where there's more control over the dom

<steele> Tim: the big question is whether browsers are going to move ahead with implementing this extension, which they've been apprehesive about in the past

<steele> General discussion around the purpose and devlopment of the extension

<steele> Planning to follow up with Rolf and Christiaan on their intentions with the extension.

Discussion around UV requirements for 3rd party passkey providers