Meeting minutes
Action item review
Ian: I reached out to Nina Satragno; currently not hearing plans for support of cached credentials
smcgruer_[EST]: A question is to support roaming authenticator support in SPC without cached credentials; it becomes a UX topic in the fallback UX.
… "we didn't find any credentials want to plug in a roaming authenticator"?
John_Bradley: There's also the case where the roaming authenticator is plugged in.
smcgruer_[EST]: Agreed.
Ian: What would implementation impact be to support detected credentials on roaming authenticators?
smcgruer_[EST]: There's be some work to check if they are connected.
John_Bradley: That will likely be different on each platform. Roaming authenticators also includes "hybrid"
… there's not a clear differentiation from hardware keys
(Regarding "passkey providers" on Android)
Rouslan: Not yet; let's see SPC adoption trends
John_Bradley: We need to understand the roadmap to get more interest from WebAuthn WG
… the special authenticator built into Chrome; is that currently synching?
rouslan: Every OS is different from Chrome's perspective, so may need a more specific question.
slobodan: An Android...GPM will sync SPC between 2 Android devices
John: On Android, where are passkeys stored? GPM or Chrome?
smcgruer_[EST]: In a secure enclave
… the only place we store passkeys in chrome is macOS
John_Bradley: So you are using GPM for other ones, it's just that things that use the passkey provider API get to GPM?
smcgruer_[EST]: SPC on Android talks directly to GPM. On Windows we use Windows Hello (which is soon to become a many passkey provider situation). On MacOS we use the chrome profile authenticator (one of 3 options on MacOS)
… every platform now has many platform authenticators.
NickTR: Can you describe Chrome password manager v. Google password manager? Are they the same thing?
smcgruer_[EST]: They should be the same thing, except on MacOS .. chrome has a legacy passkey storage as well as a GPM
Ian: What documentation do we need for all this?
John_Bradley: Maybe a matrix so that people who are deploying this understand where credentials will sync?
Tomasz: It would be good to document this.
… can you say more about iOS
rouslan: The secure enclave would be used for the BBK.
… what exactly will be used for the passkey portion is still a bit up in the air.
Ian: Would chrome team be able to put this together?
smcgruer_[EST]: Yes, we can. What should be an RP's expected model from SPC?
Ian: Would be good to know for BBKs as well.
John_Bradley: There should be "caveats" regarding credential exchange (at least for those marked cross-origin). For BBK it probably needs to be what the platform is and where it would be on that platform.
… whereas for passkeys it's who passkey provider is and if cross-origin flag is synched across platforms.
ACTION: smcgruer_[EST] to put together a matrix of currently supported platform authenticators per platform.
SPC Implementation update from Chrome
(SPC Update slides from Stephen McGruer)
smcgruer_[EST]: Lots of great work from Chrome Team on this. SPC for Chrome on Android is ready
… if you turn on a set of flags you get BBKs, support for UX, payment entity logos, payment instrument details, etc.
… Canary 139
(We see demos)
(We see a new "no matching credential" screen)
(We see demo showing one payment entity logo)
(We see a demo showing no payment entity logos)
smcgruer_[EST]: Goal is to ship everything in M139. Stable would be released around 5 August.
… this will be an experiment-controlled rollout, but our toal is 100% of stable mid-to-late-August. So pilots in Sep/Oct would be possible.
… if you want to test, easiest is to locally set the flags on your device
(No questions)
smcgruer_[EST]: Future plans
… M140 we hope to confirm the securePaymentConfirmationAvailability API (we have a small issue to fix)
… also Testdriver APIs for testing BBKs and new fallback flow
… TBD (but soon): ship same UX changes and BBKs on desktop (Windows, MacOS)
… we are starting development now
… still under investigation: SPC in Chrome on iOS
… feasibility study to start
jean-luc: Will these changes be available in custom tabs?
smcgruer_[EST]: yes.
… not Webviews (at least for now).
jean-Luc: So I will be able to trigger SPC from a native app through custom tabs?
smcgruer_[EST]: Yes.
Payment Request implementation update from Chrome
(Rouslan shows a matrix)
rouslan: Update on availability of PR API and handlers on different systems
Rouslan: Note support in WebView
Note that Apple Pay is supported in all browsers on iOS through PR API
Note that Google Pay available on android through Webview since M137
(For other payment apps on android, they are native apps and connect to PR Api through native Android API pay intent)
IJ: is there any interest from these payment app providers on additional adoption through PH API on other platforms?
Rousan: Besides Google Pay there's a small number of other (Web-based) payment handlers; I don't think we track those
… but the biggest PH is Google Pay
smcgruer_[EST]: I saw a recent PH demo from a payment service provider; pretty exciting but it was just a demo
Ian: Any roadmap for PR or PH at this time?
Rouslan: Nothing we can share at this time.
Open issue review
w3c/secure-payment-confirmation#98
IJ: What's the latest on immediate mediation?
… in WebAuthn
John: We are currently evaluating the proposal for immediate mediation.
… that is intended to allow for better UX in theory
… if there's no credential immediately available
… based on an allow list.
… the RP gets an error and can pop up alternative dialogs
… there are still privacy discussions.
… but it seems to be likely to go ahead (that would be my guess)
IJ: What does that suggest to SPC folks at Chrome?
smcgruer_[EST]: One important question is SPC is cross-origin
… that may have more privacy implications.
… is immediate mediation supposed to work inside of a cross-origin iframe?
John: I believe it would. The cross-origin iframe would need to be loaded from the other origin with permission
smcgruer_[EST]: I think that if there are cases where an RP is using an iframe with its own SPC credential, we should follow WebAuthn
slobodan: Does immediate mediation imply supplying allows credential IDs?
John: Yes, I believe it requires them but I'd need to check.
smcgruer_[EST]: I thought it was the opposite (no credentials provided) but that can be thwarted easily
smcgruer_[EST]: You could see a future where, if you are doing SPC with your own context, you can do that (with immediate mediation)
w3c/
smcgruer_[EST]: The size has increased slightly with the UX, but may not merit clean closing of the issue. This is also an implementation issue.
w3c/
IJ: Did that make it into the fallback UX discussions?
smcgruer_[EST]: In my mind, it does not make sense to have a timeout now that it's a confirmation dialog.
… separate question of whether we should support abortcontroller.
smcgruer_[EST]: I will put a comment in that one and close it
w3c/
smcgruer_[EST]: At this time it's still supported (in the new UX).
… at this moment we've not made a decision to drop from the spec, but to my knowledge nobody is using this at this time.
Ian: Let's leave in for now as we get more adoption.
Meeting time
Ian: Can we move one hour later to align with WSPIG?
Gerhard: My preference would be to use this time slot instead of the WPSIG slot
<Tomasz> +1 for Gerhard's point
John: If we move the slot to an hour later, it will conflict with the FIDO technical WG and you'll lose my contribution
Next Meeting
3 July