Meeting minutes
Nadalin: PR 1814
elundberg: editorial, fixing a reference
sbweeden: I approved
… it's trivial
nadalin: no objections to merging
nadalin: 1774
elundberg: still open
nadalin: 1821
sbweeden: approve, it's trivial
nadalin: merge
nadalin: 1813
elundberg: editorial, renaming some properties
nadalin: good to merge
nadalin: 1812
elundberg: restructures DPK attestation to use credential record abstraction
… for easier reading. I'd like some review
elundberg: please take a look if you're interested in DPK extension
nadalin: 1801
smcgruer: Web Payments WG request to allow x-origin iframe to support payments use cases
… awaiting further reply
johnpascoe: Apple's disagreements are noted there, remain
akshay: do we have reasoning?
johnpascoe: It seems the wrong point for credential creation; likely to create user confusion
… user confusion that URL in URL bar isn't for what you're registering credential
… hard to convey accurately to user what's happening
akshay: I see the confusion where the URL differs from what you're registering
… 3DS use case shouldn't be mixed with login use case is solved by an extra property
johnpascoe: proposed fix is make sure you register 3DS credentials on a different subdomain from login
akshay: many RPs do not care about payments
… ability of random websites to call a prompt concerns me
… can we have a RP opt-in, e.g. .wellknown to allow the x-origin UI?
smcgruer: this is enrollment
akshay: security-wise, server can check responses
… but the fact that a random website can *ask* for login.microsoft.com is a brand and usability problem
smcgruer: for authentication time, there's an opt-in, default off
… I wasn't aware of that concern at enrollment
… still don't fully see it
akshay: phishing resistance. previously, you could clone a website; webauthn says the browser won't even show you the login
… now, why is prompt coming from random phishing website
smcgruer: not seeing huge difference from popup
… back to John's point, nothing today stops an RP from creating a passkey for whatever they want
… even if they tell the user the passkey is only for payments, it will show up in password manager
@@: do we know how mozilla feels?
dveditz: generally uncomfortable with creating credentials in x-origin iframe; have to think further whether webauthn makes a difference
… need to think more about user experience for username/password vs passkey
akshay: I'd like a couple weeks to review
nadalin: question of how many implementations we'd get, as well as consensus or not
smcgruer_[EST]: thanks for input. we want to hear questions and concerns
smcgruer: there's a silent fall-back from dev perspective, it won't work if not implemented
smcgruer_[EST]: in the original issue, there's a list of payment folks who want to do this
… they're not looking to create an account, but to create a passkey
… they've authenticated the user to some extent, and want to create a passkey for future interactions
nadalin: we'll leave it for a few more weeks
… return at next meeting in 2 weeks.
nadalin: Untriaged, 1822
elundberg: should there be more granular resident key options
… don't exhaust limited space
sbweeden: prefer if unlimited depends on cooperative RP involvement
… if you're going to preserve discoverable credential space, client needs to help orchestrate
johnpascoe: as browser, do we just assume any key has limited storage
elundberg: recent CTAP has a field
… if nothing, you should assume limited
akshay: in deployment, you're selecting one UX or another; in "preferred", I don't really know how UX will work
… I don't think there's a webauthn change required here.
… platform or browser could make tweaks
elundberg: that makes sense
davidwaite: this is to solve for the starvation case
… there could be recommended heuristics
nadalin: leave this as-is for now
nadalin: 1819
… this may be implementation
… I'll ask adam
nadalin: 1818
elundberg: close, redirected
nadalin: 1817
sbweeden: re duplication of data in client extension results
… duplicate in unsigned data seems a recipe for reading from the wrong place
elundberg: agree. would like comment from Mike Jones
sbweeden: let's wait for Mike Jones, Adam
nadalin: 1816
… any objection to closing?
… 1808
elundberg: we closed earlier, as there's no ask for change
… got requested to reopen, but no response
nadalin: close it again
… if asks to reopen again, we need feedback
nadalin: 1803
sbweeden: elundberg responded
… if I want to pursue, should offer a non-normative PR
nadalin: leave open and revisit
matthewmiller: can we look at 1255,, duplicate of issue that's rather old
… comes down to browser implementation, whether there's any desire for the feature
… L3 has some precdent for serializing options for use in a form
elundberg: agree that JSON serialization makes the threshold lower
… I'd like to see the feature but don't feel strongly
johnpascoe: I'd like to see the feature too
matthewmiller: would like to see it to make webauthn a first-class feature in the DOM
sbweeden: what's the motivation for not wanting to use javascript?
matthewmiller: e.g. allowing frontend devs to work in HTML, as with username/password form
… declarative form-building
nadalin: need to look at the charter scope
dveditz: Moz would have some interest, e.g. Tor project, noscript
nadalin: leave it for consideration
elundberg: shall I note tentative support from Safari and Firefox, but issue is low priority
dveditz, johnpascoe: interest, not support