Meeting minutes
SPC
Chrome 145 release
Darwin: Chrome 145 supports BBKs in stable. The new UX for desktop is rolling out right now (initially behind a flag), and should be fully out by the end of next week in stable (not behind a flag).
Sami: The capability functionality is on par with what we saw at TPAC?
Ian: Yes, I believe so.
BBK Feature detection
Darwin: w3c/
Ian: Anyone want to actively review the pull request?
Ian: What is time frame for feature detection?
Darwin: Aiming for Chrome 147 or 148 (to stable by late April)
RESOLUTION: The editors will merge PR 320
Mitigating double step-up features
Ian: What's the status?
stephen: Right now we are focused on feature detection to unlock pilots
… we are still interested in the double step-up features
Roaming Authenticators and SPC
Bjorn: We are still working on that internally and will get back to you (either with requirements in issue 12 or in a separate requirements document).
BBK questions
John_Earnshaw: The BBK requirements document has some requirements that don't appear to be reflected in the specification.
… e.g., requirements say that there's a 1:1 relationship between a BBK and passkey/browser/device, but that binding is not reflected in the specification.
Stephen: The spec may not yet represent requirements that the implementation already meets.
… we can fix that.
Stephen: But it's also possible we have diverged since the requirements.
… could someone do the gap analysis and ask about implementation?
… that's easier to react to.
ACTION: John_Earnshaw to review the BBK requirements document and the current SPC and document any gaps via a new issue in the SPC repo.
Test suite for SPC
John_Earnshaw: There are some bits in the spec not covered in the SPC test suite (e.g., securePaymentConfirmationAvailability)
… is this a gap?
https://
stephen: It's hard to test that API because you can't control the underlying machine. I suspect there's a gap
… we should add a set of manual WPTs (not optimal)
… we could have a naive test for securePaymentConfirmationAvailability()
stephen: I agree the test suite should say something
Ian: Is test suite work happening on feature detection?
Darwin: Will be hard because we won't know if test machine has a TPM.
Stephen: We can test that the API exists...
… the capabilities API is worse because the browser can exclude keys if they are not supported (for privacy)
ACTION: Stephen and Darwin to look into adding test(s) for securePaymentConfirmationAvailability()
Ian: Any other SPC topics?
Sharanya: So to clarify there will be two signals for what is supported?
Ian: Do you need to check both for SPC and BBK or just BBK suffices?
Darwin: I think you get an error if you just check for BBK and SPC is not available.
Stephen: We should find out from developers the right thing.
Facilitated payment links
(Ian presents background on this topic, and reviewing pros and cons in different approaches)
Stephen: Chrome is shipping the API, but it's not a high priority right now. There's interest in the capability, however.
Stephen: Can we quietly put this on the back burner for the next period
Ian: Could the Chrome Team experiment to gather some data inform the discussion?
Stephen: It's an interesting space, I could share some metrics with people today. There's a lot of use today (mostly countries in Asia); there's non-trivial usage/adoption.
<stephen_mcgruer> https://
Ian: Will this UX be subsumed by DPC?
Henna: In principle it could, but I haven't thought through it.
<stephen_mcgruer> Compared to PaymentRequest.show: https://
Henna: If the payment has a VC and a schema.
John_Bradley: In theory DC API could be called within PR API but you'd need more information
John: DC API has still not been instrumented to support Web-based wallets. But some governments say that native wallets are a burden for their populations.
Henna: Where is that today?
… is that a DC API discussion?
John: Yes, it's part of DC API discussion.
… not surprisingly there are different schools of thought, at times even within the same company
… but the current prioritization of DC API is for native apps
Henna: Are there technical challenges or mostly prioritization topic?
John_Bradley: A combo of religion and prioritization.
John_Bradley: I think DC API should support both native and web-based wallets.
… but web-based has other security considerations
Ian: Anything blocking from the DC API perspective?
John_Bradley: no, it's more implementation questions for platforms about what they are going to support for their selectors.
… there's nothing in the design of DC API (from a JS surface perspective) that limits you to one kind of digital credential holder versus another.
John_Bradley: There's also the debate about trusted web apps
… you have to be a trusted web app to get access to WebBluetooth. So there are JS apis that are only available to "trusted web apps"
… there are technical details that need to be sorted out about how this happens or would happen with wallets in trusted contexts.
Ian: Should we insert ourselves into the conversations about web-based wallets due to PH API?
Stephen: PH API represents learnings; not sure if PH API is suitable as-is, but we could inform discussions.
… Web-based payment handlers are based on service-workers, and it may be more suitable to revisit the architecture for credential-based wallet.
Ian: Is there a WG where Web-based wallets are being discussed?
John_Bradley: Right now that's "future work"
… an extension could allow a Web-based wallet
Ian: Maybe people could use PH API instead of an extension.
… there may be security benefits to using PH, with DC API glue
stephen: PH API and Payment Method Manifest describe ways to do just-in-time implementation
next meeting
12 March