Meeting minutes
Welcome
[Hari, Ravi from PayPal say hi]
[Tony Lopreiato says hi]
NickTR: If you are new to the group, some ways we work (e.g., IRC) are a bit unique
Nick: No dumb questions. We push for consensus; genuine collaboration effort.
Chrome response to SPC feedback and prioritization
Stephen: I had hoped today to present some early findings from UX work; that will have to wait for a couple of weeks. But we do have a dedicated UX'er on our team
… looking at the feedback from Q4 2023
… at the moment we are focused on some high-level areas:
* UX
* Device binding
… within UX we heard two large buckets - feedback on UX today and feedback on other use cases
… for the moment we are starting with the current UX (e.g,. size of card art, issuer icons, fallback flow)
Ian: In 2 weeks some interesting ideas from Gerhard.
Stephen: Some things that we don't expect to happen in the short term -- Native SPC in Android.
<Leonard__Mastercard_> quick question: is the "UX person" part of the FIDO alliance UX Working Group?
Stephen: our stance is the same for recurring payments and non-payments use cases. We have not yet seen enough investment in SPC to go there yet.
Stephen: We are still pushing for more native authenticator support (e.g., 3p bit support on Windows)
Stephen: Regarding remote authenticators and hybrid, it's an area of interest but not yet strongly working on it...but we do want to continue working on it
NickTR: Very exciting to have a dedicated UX person
Ian: If Chromium appears on iOS might SPC be available?
Stephen: No reason not to. I'd be interested hear from people on that.
NickTR: I saw a post from Eiji Kitamura posting about an android functionality to turn passwords into passkeys. could that be used to magically upscale credentials for SPC?
Stephen: I don't think it supports 3p payment but we should look into that.
IJ: Is there any news on ACS deployments of SPC
JeanLuc: As far as I know, 3.2.1 certification has started. We might see some activation later in 2024.
SameerT: +1 to JeanLuc; although that may not mean everyone is offering it yet.
… 2.3.1.1 is the latest version
Ian: Stephen, what's the latest with 3p create() with WebAuthn?
Stephen: Yes, we've landed it in Canary. Will be in Chrome 123 stable around March. This was possible in SPC and now extends to any WebAuthn creation even without 3p payment bit.
… there's a new permission policy that mirrors the existing one.
Stephen: One thing that will affect this group is that at some point we'll migrate the permission policy from SPC spec to the WebAuthn spec; we'll want to deprecate the SPC one in the future.
… we also throw the wrong type of error in SPC (if you don't have user activation)
<nicktr> issue is here
Gerhard: In the past we've had challenges with using FIDO in iframe (from EMVCo's perspective).
… given what Stephen has said, what is the state of EMVCo's recommendation around iframe initiation and permissions?
<smcgruer_[EST]> https://
<smcgruer_[EST]> "This specification defines two policy-controlled features identified by the feature-identifier tokens "publickey-credentials-create" and "publickey-credentials-get". Their default allowlists are both 'self'. [Permissions-Policy]"
SameerT: A query is always welcome.
… I'll take this back to the WG
… we'll have to evaluate any spec changes
… we could already start communicating changes in FAQs and good practices guides.
SameerT: Stephen, how does 3p create() interact with passkey providers where the credential might be a passkey?
Stephen: Regarding syncing of passkeys, there is a new device-binding proposal under discussion.
… it's clear to the Chrome team that device-binding is an important element for financial services use cases.
Ian: Maybe you get device public key through SPC, both to demonstrate value and also to add value other SPC.
Stephen: Probably won't need to do that since we want this more generally.
Gerhard: Let's unpack this. Device-binding can be good for some purposes but also raises privacy issues.
… an idea would be to find the right way to create siloed device-bindings (merchant origin/bank pair)
smcgruer_[EST]: That's an interesting take
… for a given pair (or chain more broadly) you can do whatever you want. This is the CHIPS proposal; most of our privacy work seems headed in this direction.
… if you wanted to bind merchant A and bank B you can do that without any UI (with CHIPS)
… the place where SPC/FIDO/Request Storage access enter is when you want cross-domain state
… do others agree that pairwise bindings suffice?
Gerhard: We'll take what we can get. The hierarchy will help returning users on the same merchant.
… but one of my biggest concerns is the question "are there FIDO credentials on this device?"
Gerhard: the risk signal would definitely help us
… I'd like to increase the predictability of SPC's availability (and UX)
Jean-Luc: There are 2 other important aspects. It's important to be able to tie a private key to a device for risk management.
… and to increase the chances of low friction authentication.
… DBSC is interesting here as well; with that we can rely on the private key remaining in the OS TPM
smcgruer_[EST]: TPM is a great improvement.
… it came as a secure measure for avoiding cookie theft but also provides a great possession factor.
smcgruer_[EST]: We may want to go back to WebAuthn regarding information available silently.
<SameerT> +1 to RP (in 3p context) checking for it's own or associated credential being available on a device
Ian: I think it would make sense to answer question "Is there a credential associated with my origin on this device?"
smcgruer_[EST]; Maybe. in some cases it may not be obvious to know the answer (due to synching)
Gerhard: the fact that WebAuthn came up with discoverable credentials indicates that they consider this important. It might be useful to go to PING to see what they think about this idea.
… another option is to ask whether SPC could be conditional UI -available
<Zakim> nicktr, you wanted to ask about feature detection
nicktr: Given that SPC is currently an extension of PR API and PR API has a feature detection mechanism with canMakePayment(), is there a mechanism therein to allow an appropriately provisioned provider to ask if there's a credential?
smcgruer_[EST]: What does "appropriately provisioned" mean? We have multiple issues filed against canMakePayment() wrt privacy sandbox.
Upcoming W3C European Member Meeting
Ian: Jean-Luc will present at the 6 February W3C European Member meeting. Quick question: your sides show fraud going up in Europe (even with SCA)
Jean-Luc: Due to authorised push payment fraud (e.g., due to phishing)
Ian: Should we be discussing authorised push payment fraud on our agenda?
Jean-Luc: Two things could be interesting: UVI and UVM
… these are WebAuthn extensions
ACTION: Stephen to look into UVM extension and report back on its capabilities and deployment to the WG
Next meeting
15 February