Questions FedCM API demo does not work with "Block third-party cookies" enabled

[solatsuta]

Overview

Hello, I am developing an IdP that is affected by third-party cookie blocking.
From an RP's iframe, I call a URL that executes the FedCM API of the IdP and expect the RP to be able to log in.
In fact, I have incorporated the FedCM API and confirmed that the use case is satisfied.

However, if you enable "Block third-party cookies" in the Chrome settings, the FedCM API will not work.
I would like to confirm that this is the intended behavior as it is the same in the official demo, etc.

• https://fedcm-rp-demo.glitch.me/
• https://fedcm-top-frame.glitch.me/

Thanks for reading this far.
This issue is made in translation. Sorry if the language is strange.

How to reproduce

1. enable "Block third-party cookies" in chrome://settings/cookies
   • Normal operation can be confirmed by disabling it.
2. visit the following page
   • https://fedcm-rp-demo.glitch.me/
   • https://fedcm-top-frame.glitch.me/
3. console.log confirms that the token cannot be retrieved
   • look at console.log('Error retrieving a token.')

Question

• With Chrome's "Block Third-party cookies" enabled, does the third-party FedCMAPI called from within an RP iframe work?
  • If so: Is it correct to say that it is a bug if it doesn't work now?
  • If not: How should use cases where the RP exchanges session state with the IdP via an iframe be avoided under "Block Third-party Cookies"?
    How should this be avoided under "Block Third-party cookies"?

Supplemental

• Chrome version is 115.x
• Iframe on RP with identity-credentials-get attribute
  • e.g. <iframe src="3rd-party.example" allow="identity-credentials-get"></iframe>.
  • Reference: https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API#permissions_policy_integration_and_iframe_support

[krgovind]

@solatsuta Yes, FedCM is currently disabled when the "Block third-party cookies" setting is enabled in Chrome, but my understanding in speaking with @samuelgoto is that the API will be enabled in the future when Chrome starts to phase-out default support for third-party cookies.

For testing, we recommend that you additionally enable chrome://flags/#fedcm-without-third-party-cookies. Please let us know if that doesn't work.

[samuelgoto]

will be enabled in the future when Chrome starts to phase-out default support for third-party cookies.

Yes, that's correct. So far, the belief is that if we can ship the IdP Sign-in Status API we will be able to enable FedCM without 3PC. So, if all goes according to plan, yes, we would have FedCM enabled without 3PC at some point.

[solatsuta]

@krgovind
Thank you. I can confirm that with the chrome flag enabled, the FedCM API works on my RP site and two demo sites.

[solatsuta]

Thanks. This issue has been resolved.
Looking forward to further progress on 3PC.

[samuelgoto]

Hello, I am developing an IdP that is affected by third-party cookie blocking.

Any chance you have a link handy that we could use to try your IdP ourselves? Any chance that's something that is publicly available?

From an RP's iframe, I call a URL that executes the FedCM API of the IdP and expect the RP to be able to log in.
In fact, I have incorporated the FedCM API and confirmed that the use case is satisfied.

I'm glad to hear that your use case is satisfied and that the FedCM can be of help through the process!!

Thanks. This issue has been resolved.
Looking forward to further progress on 3PC.

Note that, for FedCM to operate without third party cookies, it is conditioned on the use of the IdP Sign-in Status API. So, in case you haven't already, please give the Origin Trial a try, and please do let us know if you run into any trouble!

[solatsuta]

@samuelgoto
Sorry for the late reply. Thanks.

Any chance you have a link handy that we could use to try your IdP ourselves? Any chance that's something that is publicly available?

There is a URL that is publicly available.
I am dealing with a Japanese service called mobage and the domain for the service is https://sp.mbga.jp. Please access it from your smart phone.
The IdP domain for the service is https://connect.mobage.jp.

However, the use case affected by 3PC in this service is to play 3rd party games published on the service.
Since only Japanese is supported, we think it is difficult to try 3PC scenarios.

I'll give the Origin trial a try.
I had not grasped the Sign-in Status API. This has been very informative.
Very much appreciated.

[samuelgoto]

The IdP domain for the service is https://connect.mobage.jp/.

Is this a FedCM-compatible IdP? We can't seem to find the .well-known file in it:

curl -L https://mobage.jp/.well-known/web-identity

[solatsuta]

Is this a FedCM-compatible IdP? We can't seem to find the .well-known file in it:

No, FedCM is not supported;
we have tested in our development environment that FedCM will satisfy our use case. We have not deployed to production yet.

The URL is the IdP of the production environment I am developing for and is not a URL where FedCM can be tested. My apologies.

[samuelgoto]

we have tested in our development environment that FedCM will satisfy our use case.

Ah, glad to hear that it satisfies your use case!

Can you give me a sense of which RPs would be using the https://mobage.jp/ IdP? Would any website be able to use the IdP? Or just a few? If the latter, have you considered First Party Sets instead?

[solatsuta]

@samuelgoto

As for the RPs used, I can't tell you because many RPs use them.
What we can tell you is that we are in the Platforom business and we are developing games on our platform. For example, services like App Store or Google Play.
IdPs are used to play the games that are deployed on our services.

The user needs to be authenticated and authorized to play the game, but from the game's (RP's) point of view, the IdP is a 3rd party, so it falls under the 3PC category.

We have considered FPS, but have determined that it cannot be used at the level of providing services to users due to the following problems.
We are intentionally not restricting IdPs so that they can develop their games without any inconvenience.

• RP's domain is not unique
• The domain of RP increases or decreases
• RP's domain can be replaced

We are not operationally willing to have hundreds or thousands of associated sites tied to https://connect.mobage.jp. Sorry.