Joel: Welcome! Gonna show a live use case for FedCM
Demo to bootstrap the conversation
Shop.app is the buyer-facing identity at Shopify
Reaching checkout when you’re not authenticated can be complicated
Buyers that reach checkout authenticated, they’re more likely to successfully complete checkout
We want to help the buyer and the merchant
So, we’re trying to authenticate the user ahead of checkout
One example is “lead capture” - giving users a discount early in their journey
Traditionally the discount would go to an email. But if the user authenticates, they get the discount in their online wallet
20% uplift so more users are able to achieve their goals
Also gives merchants the ability to customize the user’s journey
Merchants can also customize their customer accounts -to track orders, etc
Without SSO, you have to create an account for each merchants
We saw that 50% are more likely to sign in if they already have a shop.app account
In yesterday’s world with third party cookies we can see one-tap opportunity to authenticate the user (rather than OTP, which is cumbersome)
Today, with FedCM, it allows us to provide the one tap experience
Users can see their information, decide to share that identity with the merchant and only then the info is shared
What about passkeys? We leverage them, but without FedCM the users are forced to sign in again on every merchant site
Question: Is that using Shared Storage?
Joel: Not really. We’ll get into it later
<live demo>
Jina (Google identity): Are you sharing cross-site data?
Joel: One thing of interest is the phone number. We want to allow the buyer to share with the merchant.
We’re exploring FedCM APIs that would allow further sharing of information
Christian: When you sign in on the merchant, does that translate to other merchants?
Joel: Other merchant on a different domain will not be signed
Christian: As a user, I don’t normally go to shop.app
Joel: This happens organically in a few different ways. E.g. Lead capture, reaching checkout
About 150 million users that are eligible for a FedCM prompt, and a fifth of them in a signed in state
Christian: you’re using passive mode. If you’re not logged in there’s no prompt. What do you do?
Joel: Active mode is something we’re looking into. Either prompt of a popup that enables you to sign in
Zach: Talked about signing in before checkout. IIUC, during checkout it’s better to not show the prompt
Any scenario to show that after?
Joel: yeah. E.g. sign in for order tracking
Kushal: Can you sign into any IDP?
Joel: Multi-IDP - we’ll talk about it more
Aaron: without FedCM, if I’m on a shop I never visited before. Without checking in, I get an email an hour later with a coupon
Would FedCM disale that?
Joel: That’s not possible with 3P disabled. With 3P disabled and FedCM, that won’t be possible
Aaron: What about “sign in with shop” can it be done with SSO?
Unless there’s a way to standardize credit card sharing
Joel: Each merchant is a separate origin, so you’d need to sign on on each merchant separately.
Aaron: Can I bring my own IDP into this? Why not let me provide the information from my IDP?
Joel: This is a merchant choice. They can choose whatever IDP or wallet they want
Brian: I’m trying to understand. Federated single sign on has been available for a few years. Is it just a fancy one click UI?
Sam: It is the browser mediated UI that’s the difference. If you dismiss the browser UI you can still use the OpenID UI (that relies on top-level redirects)
Aaron: so mainly a user experience optimization.
Sam: yeah
Gary: Merchant can opt in to multiple IDPs
Sam: That also exists in the form of a nascar flag, where the user chooses the provider
It just fundamentally changes the UX friction
Aaron also brought out a point that you can bring your own IDP
Gary: Merchants would have to make that happen
Practically getting a random website on the web to enable IDP
Sam: I think it can practically happen because Shopify hosts millions of origins and can enable that for those stores
Joel: e.g. if you’re a small IDP that manages a membership, so you can connect multiple stores that respect that IDP membership
Gustavo: Another piece is brand recognition. Shopper see buttons you know (pay buttons)
Gary: concerned by the opposite - want privacy
Gustavo: The value proposition of paypal was that - but over time many of those processors started including shopper information that gets relayed to the merchant
Gary: If e.g. I don’t trust Shopify to not sell my data in the future
Gustavo: If you shopped on a Shopify powered store, they already have your data
Joel: The long term interest of the buyer is important to shopify. If the buyer has less friction, that’s a flywheel that helps merchant.
Gustavo: valid concern, but doesn’t change the risk
Fernando: Once you accept the sharing, the point around 3P cookies disappear. Is this equivalent to sharing storage that allows 3P cookies?
Joel: The user can continue to share their data with the site. FedCM enables lower friction
Fernando: From a technical perspective, this is same as 3P cookies
Sam: Short answer is “yes”. We allow shared storage if you accepted the prompt
But the devil is in the defaults. Information is shared only when the user accepts
Fernando: do you see this happening with other things? We can keep adding semantic sharing while it doesn’t really matter
Sam: that’s storage access API
Vitalii: It gives users better context for the user. This is way more understandable. Maybe the language can be improved, but it’s a better UX
Sam: Conceptually this is embedded to prompt “sign in to website with IDP”
Nick: two things happening at once
Phil: Thinking that UX is the main driver for this. What is the protocol that you’re using to sent request and response through FedCM
Joel: This is on the IdP, not a FedCM concern.
Phil: Wondered what that looked like
Joel: Aaron has a great blog post on that
Aaron: Should we standardize that layer above FedCM?
Joel: The initial build is a signed JWT and we’re using the nonce parameter. Not released yet
Concern in the WG that after the user have consented, the IDP can share more
Sam: We want the OAuth profile
Aaron: So we should get you involved
Phil: It’s not OAuth, but SSO
Aaron: doesn’t exist just yet
Sam: We would want to reuse our common experience to create a secure protocol
Christian: wanted to respond to Gary about “bring your own IDP”. We’re working on a IDP registry, so the IDP just need to opt-in to an IDP registry
Gary: Is there a vetting process?
Sam: working on it
Steve: If I’m a shopper and get the login, does that mean that the merchant has all my data before I need to checkout?
Joel: Depends on the phase in which you’re logging in. Nothing is shared in the moment. If you complete a purchase, then e.g. address is shared
Steve: need user agency regarding what’s shared
Sam: Multiple IDP API would enable the same with several IDPs in a single account chooser and offer that to the user
As opposed to the nascar flag, a logged out user doesn’t see IDP they are not logged in
That gives opportunities when it comes to “bring your own IDP”
Regarding progressive disclosure, it anchors things in a different way.
E.g. we can expose the information in browser surfaces that are not available to the rendered content
Autocomplete UI
Button flows a lot less controversial as they require user activation, but would also work with multiple IDP APIs
Joel: They also give the user an opportunity to sign in in case they are not
Sam: These things are in different stages of maturity
Yoav: button flow can mix well with fenced frame unpartitioned data
Sam: it would help users escape the fence
Shivani: Not even. The goal is just to show something to the user
Joel: Any other browser implementers that want to share they opinions?
<no>
Sam: How much is blocked on other browser support?
Joel: Not blocked. Just want to know when non-Chromium users can take advantage of this
Sam: how does it look for mercado libre?
Gustavo: Looks appealing
Pablo (Mercado Libre): Does the UI change over time? If I delete data from the RP, when would I need to consent ?
Sam: If the browser seen the user before and the IDP agrees, auto auth enables automatic sign in without a user prompt
It’s optional so you can ask to get a prompt every time
Pablo: how does that work for multipl IDPs?
Nicolás: Only for a returning user on the RP. If the user clears their cookies, that can also affect the browser’s knowledge. It’s a signal from the user that they want to clear it
Pablo (mercado libre): Considered cases where the merchant initiates that process in a webview
Sam: Are you referring to the fact that webviews don’t share the cookie jar?
Working actively with Edge to support. Interested in getting accounts from the OS rather than the cookie jar
Christian: Is your problem that you can’t use FedCM inside of WebViews? It’s not working right now
Ben: We’d definitely like to hear more input from people interested in this