Meeting minutes
SPC updates
Feature detection updates
Darwin: We are awaiting approval, should be in Chrome 147 or 148 at the latest.
Stephen: So if in 147 would be rolled out completely by mid-April.
Ian: What about the spec?
Stephen: We landed the spec change last week in the editors draft.
Stephen: We were asked whether we talked to the TAG and are are suggestion we do an FYI to the TAG.
… our argument is that this is a small addition to an existing API so an FYI is appropriate
uv=discouraged update
Darwin: I have confirmed that uv=discourged for android they will ignore it. They don't imagine changing this in the foreseeable future.
stephen: Summary then is uv=discouraged is not respected on any platform.
… so we need to continue our conversation with the Android folks on our detailed use cases.
Ian: Would it make sense to invite people to this call?
stephen: Not yet
ACTION: Stephen and Darwin to continue conversations with the Google password manager team on how we might address double step-up use cases.
BBK requirements / spec gap
w3c/
stephen: We struggled with how best to describe the situation. Some browsers support "profiles" differently on different platforms. E.g., there is only one profile per signed-in account for Chrome on Android.
… the interesting question is what is the desired underlying guarantee.
Ian: The high-level requirement was "can't be removed from the device." And we narrowed in.
Stephen: Right, we narrowed in for clarity, but not for security properties.
… in my head "not leave the device" is a security requirement but "not leave the user agent" is more of a practical requirement.
Stephen: On desktop, our implementation is per chrome profile.
… each profile has its own storage.
Ian: What problem do we want to solve ?
John: Fraud risk management team wants to know about guarantees that the implementation provides
Ian: Could you ask what guarantees people would like?
John: Sure.
ACTION: John_Earnshaw to get more information from his fraud team to understand what guarantees are being sought.
ACTION: Stephen and Darwin to propose an editorial fix to the specification language regarding one passkey per BBK requirement.
SPC issue review
w3c/
Ian: THis is not viewed as part of V1 so propose to close issue 65
stephen: Agree to close.
… but note that you can't call SPC in a Payment Request because you can't do recursive payment request calls. Nobody has asked for this use case to be addressed.
ACTION: Ian to close issue 65
w3c/
Ian: At TPAC we moved in the direction of supporting "low friction" flows so was ready to close.
… and we heard it was important to stay close to passkeys.
Gerhard: My sense was the "confirm" button was low-enough friction
Ian: Let's leave this open based on what we heard today. We are aiming for low friction.
ACTION: Ian to update issue 34 with the latest info
(More on issue 34)
Henna: We wanted a coupling with passkeys so that you could have a single enrollment that gives you both options (with or without SPC).
Gerhard: The original three superpowers of SPC were (1) secure display (2) running in a different domain than the RP (3) dynamic linking
Ian: What use case have we missed with DC API + SPC + DBSC?
Henna: I heard we want a signature cross-domain (with user interaction)
Gerhard: In a lot of domains, possession is good enough.
… the whole world is using OTP which creates phishing issues.
Henna; The other argument I heard at TPAC is that if you have a key that can work cross-domain (user is aware of what's happening but no authentication)
… but I can't remember whether key unaffiliated with a passkey but user confirm was ok or not ok.
Henna: I agree that we should list use cases and how we address them.
… I'd be happy to work with Gerhard to see if there's another use case and the topic of "how do we solve it"?
Ian: Please recall previous chats about this idea (e.g., man in the middle attacks)
Gerhard: A challenge with SPC is that it requires support for FIDO, and that's more than is needed for some use cases.
Payment Request updates
Stephen: we received a request from PayPal regarding clearer error messages, to differentiate a failure due to user canceling during a flow and a failure due to some error happening in the payment app.
… Marcos and I worked on this and landed the update to the Payment Request specification to allow this concept to exist for payment apps.
… so next step is to land this for different payment app types, starting with Web-based payment handlers.
… then after that we'll look at making this work in native (Android) apps
… PayPal indicated this improvement would help their use case.
Next meeting
26 March
Bjorn: I'll be able to talk about roaming authenticators on 26 March