Comparing FedCM and Lightweight FedCM

Functionality

	Lightweight FedCM	FedCM
when token* creation occurs	IDP page	RP page
token* lifetime	until overwritten by the IDP	API-call duration
where tokens* are stored	in the browser	not stored
are tokens* RP-specific?	no, unless you store a credential for each RP the IDP may have for that user	yes
how does the RP communicate to the IDP?	via URL parameters only if the IDP hasn't stored an effective credential yet, or via unpartitioned network requests after the UI is shown	the `nonce` parameter (and `params` parameter**)
account chooser UI hints	stored in-browser, with lifetime specified by IDP	dynamically fetched
allow Storage Access autogrant	yes	yes
multiple IDPs supported	yes	yes**
BYO-IDP supported	yes	yes**
round trips to IDP to show UI	0 or 1	3
IDP HTTP endpoints	0 or 1 that replies 200 OK to RPs in the Origin Header	3 or 4 custom endpoints
.well-known file required	no	yes, on eTLD+1
UI shown	account picker	account picker, ToS/PP dialog
account picker control by IDP and RP	icon and name***	picture, name, email, given name, "context", domain hint, login hints, optional ToS/PP bypass, color, background color, identity provider icon, identity provider name
login status endpoint	`navigator.credentials.store`	`navigator.login.setStatus`
unlinking API	re-store the credential, ineffective for the RP	`IdentityProvider.disconnect()`

* tokens are just arbitrary IDP data.

** proposed extension

*** If you want more control, it is advised you show website-specific information in the icon/name and use an IDP page to present auth choices.

	Lightweight FedCM	FedCM
Works without 3PC	yes	yes
Allows navigational tracking	yes	no
Timing attack	only via navigation*	yes
IDP can not learn about RP until the user selects it	only via navigation*	yes
Lifetime of IDP-RP-Linkage	until `navigator.credentials.preventSilentAccess` is called (should be when the RP logs out)	forever

* the navigation is the equivalent of a window.open call initiated by the RP