Meeting minutes
FedCM
smcgruer_[EST]: FedCM may have applications to payments in terms of user recognition.
… this story starts with the tracking issue that is enabled by cookies
… browsers changing to avoid tracking without the user's permission or awareness
… we are getting rid of 3p cookies so need to find alternatives for well-known use cases such as federated login
… aggregation of logins in identity providers (IDP)
… simplifies life for web sites who can hand over login to IDPs
… there are downsides to current approaches (not part of today's discussion)
… seamless federated login as practiced today relies on 3p cookies
… RP.com reached out to idp.com who keeps track of login state...but in a 3p context
… the emerging solution is FedCM: browser mediates the identity discussion
… the site lists supported IDPs.
… the browser goes to the IDPs without telling the IDPs why it's asking. The IDP can access cookies in a 1p context.
… the IDP can tell the browser what accounts the IDP knows.
… the browser can display these choices to the user (without showing merchant yet) and allow the user to consent to identify themselves (via browser UX)
… after the user selects an identity, there are other flows between the RP and IDP (not discussed here).
… summary:
* The browser enforces isolation, which allows IDP to access 1p cookies. The IDP does not know who is asking.
* There is a privacy issue - what happens if there is *no account*?
… right now they are not showing the user any dialog if there are no accounts, and they are also not telling the merchant site.
… perhaps in the future there might be an SPC-like failure screen
[We see UX]
[Status]
* Single-IDP option-UX shipping in Chrome 108
* Spec is in development in the FedIDCG
* Two other browser vendors have indicated support for this publicly
* There are things not yet implemented
- Auto sign-in for returning users (but 1p cookies could be use)
- Multi-IDP support....early discussions are happening
- Handling not-signed-in IDPs not yet supported
- Work still happening on UX
[What about payments]
smcgruer_[EST]: FedCM will always require user understanding and consent...and returning flows will at least show the user something
… but I think FedCM could still be useful
… e.g., PSPs that offer a service across merchants
… or banks/PSDs wanting to authenticate the user without redirect/popup
[Demo of FedCM with SRC]
Gerhard: Really interesting; gives me a payment handler kind of feeling
… the little window that popped up...is that a 1p iframe?
… is the size changeable?
smcgruer_[EST]: That iframe in my demo is opened by Visa (3p)
Gerhard: What identifier is passed back?
smcgruer_[EST]: The merchant passes a list of IDPs to the browser
… the browser talks to each SRC system (with cookies)
… those SRC systems are asked to return "list of accounts"
… so for my demo I provided card list rather than login names
smcgruer_[EST]: What the user cannot see is that there's a token associated with what the user selects (e.g., some user identifier that enables the rest of the flow)
Gerhard: There's no requirement to do any other UX after the FedCM.
smcgruer_[EST]: Correct
JeanLuc: Thanks for this presentation. The demo basically shows the browser as an SRC-I. Could you use FedCM instead as an alternative to the recognition domain?
smcgruer_[EST]: You could take the more "traditional" view of FedCM -- you could simply present the user's SRC identity (e.g,. my email address).
… any SRC system that has a cookie in its domain could send back that identity.
… one issue here is that you might of N identical identities in this case, and there is no de-duplication function here.
… so maybe there's a way with FedCM to tell the browser "where you see identical strings, just pick any one"
JeanLuc: Very interesting
nicktr: Really cool.
… can you call FedCM from inside of a payment handler
smcgruer_[EST]: Technically there's no reason you couldn't...but I don't know what will happen in mobile windows
Ian: How is privacy handled in passing of IDP info?
smcgruer_[EST]: Domain only. Probably a .well-known
Fahad_: For multi-IDP there might be different ways to de-dup, e.g., "stop as soon as you find one"
smcgruer_[EST]: Multi-IDP is very early stage exploration; this would be good feedback to the FedIDCG
… my idea for this is that there would be a deduplication field. The browser shows only one.
Fahad_: What happens when the user returns to RP.com?
smcgruer_[EST]: With FedCM today, the user would have to choose to continue.
… RP.com could put a first party cookie; that's feasible but there are downsides
… it would be good to engage with the CG on returning user flow
… we'd probably tell the user "you are being logged in" rather than doing it silently
Fahad_: The spec has a client id. When the IDP returns info they talk about "already approved client id"
smcgruer_[EST]: The IDP could lie and that would lead to tracking silently
… but I personally think that if a user comes back to a site where the user has previously used FedCM, the site should be able to trivially get back identity via FedCM
Fahad_: In the browser UX .. is the IDP name set by RP.com?
… can multiple IDPs have the same display name?
smcgruer_[EST]: The IDPs are represented by their origin
Fahad_: We were interested with "Sign in with click to pay"
SPC use cases
[SPC Progress so far]
Gerhard: Both Open Banking and 3DS support more than just single transaction. What might we do next with SPC?
[we look at current fields displayed by SPC transaction dialog, primary use case, and primary authentication approach]
Gerhard: We'd like to start here discussion of next use cases for SPC
Gerhard: I can see three axes for extension -- (1) additional display fields (2) new use cases/transactions (3) other forms of authentication
Gerhard: there are some additional UX topics (not part of my 3 categories above) - opt-out, icon size
[Trusted merchant list]
Gerhard: "Trust this merchant" in the display.
… another one is "Trust this device"
Gerhard: Imagine we are doing this in open banking...the user journey would start with "pay with my bank"
… there would be a redirect to the bank
… the SPC confirmation could happen in that context, followed by a redirect
… do we need a redirect capability
Ian: How does this relate to SPC?
Gerhard: Want to "trust a merchant"; the user could say essentially "don't do a step up in the future". The issuer could record that information.
Ian: Why does the user's view matter?
Gerhard: It's part of EMVCo requirement
… to offer this option
JeanLuc: If I understand correctly, the merchant could populate the field without any user validation.
Gerhard: For me, the point is that the SPC display is browser-controlled and thus the merchant can't fake it
JeanLuc: The merchant could attack in the second AREQ
Charter
Ian: Our charter was approved; we are now operating under the new one. Please ask your AC Reps to join (since we changed patent policy; this is a formality in practice).
Schedule
<Ian> Next meeting: 8 December
FTF?
Ian: The co-Chairs and I have discussed organizing a face-to-face before TPAC 2023. I reached out to the EMVCO and FIDO folks to find out their schedules so we might piggy-back. A couple of options emerged:
- 13-14 March in Amsterdam? (After EMVCo meetings)
- 26-27 May in Dublin (After FIDO meetings)
Ian: Please start thinking about this and agenda items. The Chairs will continue to discuss potential dates. It would be great to hear from you today whether you'd like us to organize a face-to-face.
<clinton2> +1 (either; as long as no overlap with other meetings)
<Gerhard> +1
<JeanLuc> +1
<mg> +1
<benoit> +1 (either)
<Ian> +1 (either)
<Fahad_> +1
<cferro> May is better I think! +1
<ChristianA> +1
<Rolf> +1
<rouslan_> +1 (may have to be virtual for me)