[Openid-specs-ab] FED CM @ BlinkOn

Tue Nov 23 02:22:40 UTC 2021

I might be thick, but in my little world it feels like there's not a lot of appreciation for the potential damage that will be done by this. Here's my small world take.

First, my understanding is that there are lots of other clever ways to thumbprint browsers beyond cookies, so the premise that cookies are the main threat seems over simplified. Thus killing cookies in this way seems heavy handed given the collateral damage. If my understanding is correct, then the trackers will just work harder to use the other existing approaches. Perhaps I'm wrong and/or missing something? If so, I'd love the ELI5 [technical] explanation. This threatens the premise of this whole exercise.

Second, many of the examples used are of relationships between RPs and IdPs assumes social login that are third party situations (apps that signin w/ google, FB, apple, etc). There are so many more businesses out there that setup their own IdP that happens to be cross-site mechanically, but are in reality first-party in all other respects, and they have their own business rational for this. So it seems that the mindset of "oh everyone just uses one of the big social IdPs to login" is distorted from the reality of the relationships are between organizations and their users. Think of a hospital that has their own IdP to handle patients and the apps they need to login into to process their care. If this kind of thing is broken, then in your browser people won't be able to get login to get their chemo scheduling and follow up doctors visits (and I can tell you that apps in hospitals take years to get updated). Maybe you're aware of this already, but all the presentations I've ever seen don't seem to illustrate this level of understanding for non-social/non-enterprise login situations. I think the assumption there are only O(100) IdPs is very wrong/underestimated. Personally I have hundreds of customers/companies that run their own IdPs. I know the larger companies (Okta, Auth0, Gluu, ForgeRock, Ping, etc) have more customers than I do. That's at least many thousands of IdPs and the economic impact of this will be non-trivial.

Third, I think we've all learned over the years in the protocol space that having the browser involved as little as possible in communicating between the RP and IdP is a good thing. These proposals asking for the browser to take over all of this is... well... hard to grasp. It's a drastic shift from the momentum in the identity protocol space (e.g. PAR). The proposals I have seen in the video are trying to mediate protocol flows that are too simplistic (implicit flow w/ form posting id_tokens as the most common thing). Most scenarios I work thru don't pass id_tokens thru the browser, so these solutions seem presumptuous on protocol flows. Also, how do access tokens (for the underlying business APIs) fit into all of this, since that's the other half of what these protocols deliver to RPs?

Fourth, how do I get to write custom login UI during the login process? How does new user registration work in this world? What if I need to dynamically prompt for a MFA (or not) depending on the state of things? I might need to prompt the user for their email to federate to an additional external IdP (thus an additional hop) based on what the user inputs. I might need to accept custom parameters from the RP that affect the login workflow. I might need to introduce a 15-page workflow for a new EULA during login because of a change in the corporate policy. These things are very common and the exact reason companies setup their own IdP for their suite of apps and APIs. If the browser forces itself in the middle, that's a real deal breaker here, it seems. Why should the browser see user identifiers at all (and it doesn't quite help in the goal of reducing the the no-tracking goal)? So the assumption that solving login redirects w/ id_tokens and signout iframes as the main feature is wrong. I'm not sure this is the browser's job.

Finally, in my own personal browsing I use Firefox. I configure it to remove all cookies when I close the browser. I then explicitly configure the sites where I want cookies to be persistent. This seems like a nice way to achieve the purported goal without breaking the world. Why not make something like this the default? It's a hell of a lot simpler. I'd love to hear why this wouldn't work, and I was hoping back when we heard from the Firefox team that something like this wasn't a possible solution back when we had the 2-day W3C identity event. Again, assume I'm thick, so I'm sure I'm missing something here.

I'm sure as I actually spend more time getting into the technical details, I'll come across more issues/scenarios/questions. I'm happy to be wrong on all of my immediate reactions -- please share any links that corrects me on these concerns.

Thanks.

-Brock
On 11/17/2021 9:29:42 PM, Tom Jones via Openid-specs-ab <openid-specs-ab at lists.openid.net> wrote:
Presentation by dsinclair at chromium.og https://www.youtube.com/watch?v=9la0cBhVXac [https://www.youtube.com/watch?v=9la0cBhVXac]
Dan Sinclair & Yi Gu with Sam Goto answering questions.

points from me
1 Google wants to get rid of user name password for a more secure web.
2 Google cannot distinguish between a tracking cookie and a 3rd party logon
3 Google wants to preserve and elevate for a more private web
4 Not clear if that means a different web or to improve the one we got
5 3rd party cookies will be turned off in 2023
6 Origin trials early 2022 - no hard date for general availability.
7 spec completed sooner rather than later??
8 the browser will supply apis, the RPs will need to adapt.
9 his 1st diagram shows a back channel from IdP to RP
10 his network diagram claims there is not a direct connection
10 network does show a promise which flows from the UA to RP - typo?
11 the IdP publishes yet another endpoint for fed cm to browser
12 unclear if IdP data is available via api - that could be bad?
13 api built on top of cred man api
14 a scary ui is proposed - will users accept?
15 unclear how much RP needs to change - more if logout needed
16 only mobile at the current time
17 not a good solution, just trying to prevent the web from breaking.
[Fed CM BlinkOn 15.png]

..tom
_______________________________________________ Openid-specs-ab mailing list Openid-specs-ab at lists.openid.net http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211122/65083761/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Fed CM BlinkOn 15.png
Type: image/png
Size: 122040 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20211122/65083761/attachment.png>