the core spec creates per-origin keys. amazon.com gets one key, and google.com gets a different one. and because the keys are different, they can't be used like a shared ID to track. checks out....
however, the Federated DBSC section explicitly breaks this rule to allow key sharing.
worse? In Federated DBSC, a Relying Party (RP) can only use an existing hardware key if the Session Provider (SP?!) "allows" it in their /.well-known/ file. Google can simply refuse to add my startup to their relying_origins list....
my startup is forced to make users do a manual, high-friction login, while Google's own services (YouTube, Meet) stay "seamlessly secure." Google (the SP) effectively decides which small businesses (RPs) get to have a "smooth" user experience. It turns a security protocol into a competitive permit system.
the death of the "Open" Web and the rise of "Identity Blocs => to make Federated DBSC work, the RP and the SP have to mutually "handshake" via .well-known files. this creates a web where security is no longer a universal standard you just "enable," but a partnership you must negotiate. so we end up with Identity Blocs. You’re either in the "Google/Okta/Microsoft" garden where everything is secure and fast, or you’re in the "Open Web" where every site feels clunky and "less secure" because they don't have the "blessing" of a major Session Provider. It makes it nearly impossible for a new, independent identity system to gain traction.
Oh shoot
how do we get back to "Marking HTTP As Non-Secure" and less dragging legacy idps
the core spec creates per-origin keys. amazon.com gets one key, and google.com gets a different one. and because the keys are different, they can't be used like a shared ID to track. checks out....
however, the Federated DBSC section explicitly breaks this rule to allow key sharing.
worse? In Federated DBSC, a Relying Party (RP) can only use an existing hardware key if the Session Provider (SP?!) "allows" it in their /.well-known/ file. Google can simply refuse to add my startup to their relying_origins list....
my startup is forced to make users do a manual, high-friction login, while Google's own services (YouTube, Meet) stay "seamlessly secure." Google (the SP) effectively decides which small businesses (RPs) get to have a "smooth" user experience. It turns a security protocol into a competitive permit system.
the death of the "Open" Web and the rise of "Identity Blocs => to make Federated DBSC work, the RP and the SP have to mutually "handshake" via .well-known files. this creates a web where security is no longer a universal standard you just "enable," but a partnership you must negotiate. so we end up with Identity Blocs. You’re either in the "Google/Okta/Microsoft" garden where everything is secure and fast, or you’re in the "Open Web" where every site feels clunky and "less secure" because they don't have the "blessing" of a major Session Provider. It makes it nearly impossible for a new, independent identity system to gain traction.
Oh shoot
how do we get back to "Marking HTTP As Non-Secure" and less dragging legacy idps