Merge the three states and the bug is predictable. A remembered identifier is a hint about who might sign in. The PingFederate authentication session is the only record of whether that person already proved it. The application session says nothing beyond whether this tab is signed in right now [3]. The author is blunt that a remembered account is not automatically a passwordless account [17], and that collapsing the three into one session produces repeated password prompts, stale panels and broken logout [2].
HttpOnly on the identifierFirstAdapter cookie prevents page script from reading it directly [7]. That is correct behavior, so the read has to happen server-side on PingFederate's own origin. Nothing about the demo topology lets you dodge that: the application is served from http://localhost:8080 and PingFederate from https://localhost:9031 [8], and those differ in both scheme and port, so the shared hostname buys you nothing [9]. Hence a status-only adapter that reads the native cookie and returns a sanitized list, with the widget drawing a chooser only when that list contains accounts [10]. The bridge itself is an origin-restricted iframe, sandboxed and nonce-carrying, delivering sanitized users to an allowed parent by postMessage [11].
Two decisions here are worth copying. The status endpoint stays out of the interactive policy, separate from the Identifier First and HTML Form sequence [13], so the chooser has no vote on an authentication outcome. And the adapter parses PingFederate's own representation, a URL-encoded comma-separated list of Base64-encoded identifiers, instead of minting a second account cookie, which the author notes would have added another source of identity state and made lifecycle behaviour harder to reason about [14][18]. A second cookie would drift out of sync with the Identifier First cookie as sessions changed, adding a stale copy of the same data with its own lifecycle to track.
The widget checks a remembered account with a silent authentication attempt rather than treating it as already signed in. It attempts authorization with prompt=none, and if silent authentication cannot complete it falls back to an interactive top-level request without forcing prompt=login [16]. Forcing it would violate the third rule the series sets itself, which is that a valid PingFederate session should let a remembered account continue with no further password prompt [5]. First sign-in is left alone: Identifier First collects the identifier, the HTML Form adapter validates the password, PingFederate records the successful identifier, and the callback validates state and exchanges the code with PKCE [15].
For the number of moving parts to be worth it in your environment, three things have to hold: the Identifier First adapter is already in your policy, you can deploy custom adapter code to a PingFederate 12.3.3 install [1], and you know the parent origin in advance. Note that both origins in this build are localhost [8]. Whether the hidden iframe still sees that cookie when the IdP sits on a different site rather than a different port is what I would test before promising anyone a silent sign-in.
