Don’t worry ico-man! But you may want to duck and cover… NOW!
What is this all about? What even is a third party cookie?
A cookie is “third party” when it is set by a component in a browser (like an iframe) in a domain that is different from the url of the page to which the person navigated. The biggest offender here is what we know as tracking cookies. No one wants to be tracked.
Most browsers enable you to disable third party cookies–some browsers even make this the default setting. But in about a year and half, a day will come when Google will push an update to Chrome that blocks all third party cookies. Other browser vendors will follow suit, if they haven’t done so already. And anything that relies on third party cookies will break.
Some fear the Web itself may break. I personally wonder what the impact will be on decades of marketing tools that provide companies with rich intelligence on who is visiting their site, and how they got there.
But blocking third party cookies will also impact some of the good guys. “Federated login” (e.g. enterprise and social login) relies on third party cookies to enable the one federated logout mechanism that occasionally works: OpenID Front-Channel Logout? When 3PCD happens, this will no longer work.
The good news for the good guys–federated identity providers–is that Google has got your back. They run a little IDP themselves, so they understand the advantages of federated digital identity. In this video, Sam Goto, a software engineer from Google, provides an overview of the Chrome team’s work to introduce a new API into Chrome specifically designed to support federated IDP use cases. Sam has also published a W3C draft community group report, called Federated Credential Management API. Here is the abstract:
This specification defines a set of high-level APIs that enables users to continue to use Identity Providers to authenticate to Relying Partys without incurring into Unsanctioned Web Tracking. It accomplishes that by exposing the explicit user controls needed to manage the lifecycle of their federated accounts.
This is a screenshot from the video which shows some of the interfaces, and how the browser (i.e. the “User Agent”) will mediate between federated IDP’s and RP’s.
Another interesting way to consider the WebCM API is with regard to the relationship between the User, Account (on the RP) and the Session (in the Browser):
Will WebCM finally fix logout? Or maybe, is WebCM a part of a solution to logout that connects to the work being undertaken by the Security Event WG? It’s hard to know the answer to this question, but at least we’re not just sticking our heads in the sand anymore and hoping that logout will fix itself.
With good communication, and time for IDP vendors (e.g. Gluu) to support these new features, the Web won’t break! In other words, Super-Google-Man, Sam Goto, will save us! Go Sam!