Meeting minutes
SPC
Explainer for supporting non-queryable authenticators
Explainer for supporting connected roaming authenticators
stephen_mcgruer: Today SPC supports one authenticator per platform and we are looking into expanding support.
… the first explainer describes a proposal for what to change to support a greater set of authenticators.
… the second explainer talks about how we might support connected roaming authenticators (underlining the idea that they have to be immediately available when SPC is called)
<raginpirate> I realize I should have used the agenda, but I'd love to mention Shopify's recent thoughts on Payment Handlers and Payment Request as we've playing around with it internally. If we're able to fit it in at least :)
<raginpirate> ty!
stephen_mcgruer: In the non-queryable explainer there are examples of user experience dead-ends that we want to avoid.
… we did that historically by assuming we can query dynamically for credential existence.
… but this excludes non-queryable authenticators.
… the explainer basically states that we need to fundamentally change SPC's approach to no longer assume that you can always query for credentials, while trying still to avoid UX dead-ends.
… the two main ideas are (1) allow non-queryable credentials but prefer queryable ones; this would allow fallback UX for the non-queryable authenticators.
… (2) the second idea is a flag that allows callers to say "always show the transaction dialog regardless of silent availability detection.
Ian: What are the primary platform authenticators that can be used?
stephen_mcgruer: Will allow password managers, for example.
stephen_mcgruer: On MacOS there's be more Apple access.
… possibly on Windows if there is support for 3p password managers.
Ian: Any mockups yet?
stephen_mcgruer: I have my quick-ee mockups but we don't have "serious" ones yet.
stephen_mcgruer: One big call-out I want to make. You notice this says "rp.com"; one of the original requests from the WebAuthn community was that, if an rp has not opted in to the 3p bit, "don't show them anywhere."
… so for example, support stephen.com makes an SPC call with credentials from microsoft.com. If you land on a page that says "use my passkey from microsoft.com" [even if the passkeys are not 3p enabled] seeing microsoft.com might confuse people that there's some association between the two sites.
… so most of the proposals here only work in a first party context.
… we have to revisit the policy of not showing 3p origin (and may stick with it or not)
Ian: Is doing "non-queryable" a prerequisite for doing plugged-in roaming authenticators?
stephen_mcgruer: No, although there's a backwards compatible fix common to both of them.
… we should be taking in the proper public key description which describes the transport; we should allow other transports.
… we might want to rename the member, this would require deprecation/migration. But SPC usage is mostly for pilots. I am leaning with stronger alignment with WebAuthn.
Ian: Any WebAuthn experiences to draw from?
TimC: You may remember early in passkeys you could link your passkey to chrome/windows. That feature was intended to allow a trusted list of credentials. I also wanted the platform to cache keys previously plugged into a trusted device.
… that would help with some of these scenarios. The UI could say "connect this key" since cached.
… but that latter scenario was not implemented in windows.
stephen_mcgruer: I did originally include using a cache, but didn't keep it. Cache would be an add-on to improve UX flows.
TimC: There's not one use case that would push it over the finish line but all together could.
TimC: Regarding security keys, it's a small but important group of users. That's always the debate.
… I think in practice long term people that want to use security keys will use them to protect their accounts.
… I don't see most users having keys with them all the time to do payments.
Ian; So the platform authenticators that are non-queryable go up in priority.
<stephen_mcgruer> https://
<stephen_mcgruer> https://
ACTION: Olvis will read the explainer to provide feedback.
(the non-queryable one)
Ian: can we work towards something for TPAC?
stephen_mcgruer: I can say that we are interested in these proposals; maybe there's a world in which we have prototypes (no promises!)
subtopic+ SPC locale field
w3c/
Darwin: SPC has a "locale" field to list language priorities for SPC dialog. But that field is ignored today by Chrome since browsers can't support lots of language in practice.
… and in general we want a set of things to be in the same language (e.g., spc, settings, passkeys)
… but the RP provides some strings for the dialog and those strings might be language-specific.
… so an issue might be that some strings are in one language but the rest of the dialog might be in another language.
… our proposal is to use the set locale as a trigger for validation. We would seek a match between what dialog is using and pick any matching locale. But if none match, then we would return an error message.
… if you don't sent locale, then validation is skipped.
… an alternative that we did consider ... there is an API to return the site preferred language, but that's not always the browser language.
Ian: Imagine browser language is an arabic script and the site explicitly sets locale to English, then SPC will fail?
stephen_mcgruer: Yes.
Darwn: But the browser can provide a list of languages that they want the site to be in. With this proposed change, the RP can basically test languages and supply date elements that correspond to the browser language.
<stephen_mcgruer> navigator.languages returns a list of users preferred languages, BUT not guaranteed where in the list the browser UX language is (or even if it is present in the list!)
Darwn: the caller can do language matchmaking after payment request constructor is called.
… the caller can pick the best match.
Ian: Let's get some I18N review.
Darwin: +1
ACTION: Ian to reach out to I18N WG to seek feedback on issue 343
ACTION: Bjorn to review the explainers regarding authenticators.
Payment Method Manifest
Allow up to 3 same-site redirects when fetching Link header - #52
(This has been merged)
stephen_mcgruer: Payment method manifest is used for payment handlers in Chrome. When you specify a payment method identifier the browser fetches manifests.
… but there was a mismatch between the spec and the chrome implementations. The original spec said you could not follow redirects.
… but in general there are same-site redirects (e.g., http->https, or adding "www."). Chrome allows 3 hops in the redirect flow.
… we merged the pull request to match the spec with the implementation
Shopify thoughts on PR API and Payment Handlers
Daniel: Shopify has looked at PR/PH previous. We are looking at it again with the lens that it might help us with PCI topics.
… we think that payment handlers could help us improve the user experience
… we have some questions from our recent explorations.
… frame size is one.
… having additional control to shrink/expand based on context would be great.
… there's also a concern about number of PR calls.
… I want more than one to be able to be available and would like the spec to support
… I have lots of tabs open and want to be able to switch payment handlers by context.
… There is also a question of nested wallets.
… so we may want to do nested payment handlers.
Issues list for payment handlers
Westin: Thank you for the summary. We are also in general looking at agentic a lot, and embedding agentic experiences in other surfaces.
ACTION: Daniel to raise issues on the payment handler repo regarding desired functionality
stephen_mcgruer: From the Chrome side at least, we are excited about working on these issues with you. We are also well-aware of some of them...
… yes, we should make it possible to change frame size (as is possible with popup windows)
… popup windows can have both static sizes, and also can have limited resizing capabilities.
… regarding one payment request per browsing context...I think the spec is correct here that each tab has a single active PR API.
<benoit> framesize: please remember to allow for zoom ability - important for those that are visually impared
stephen_mcgruer: I think this is probably mostly an implementation issue.
… but I agree that this is one that we should address.
stephen_mcgruer: But nested payment requests are complicated.
… the spec does not currently allow nested payment handlers.
TPAC planning
https://
<benoit> +1 :)
stephen_mcgruer: For autofill, likely to be a breakout
Next meeting
10 September