Martin: there will be a breakout session in TPAC about this... defer until after that.

no updates

Jeffrey: altetnatives mentioned FedCM, Storage acces, Exemption Heuristics... The question is is there a way to do UI that is clear enough?

Yves: to make sure that people are not tricked.

Jeffrey: that it's not the main origin but that it has access the identity of the origin if there is communicaiton. Not clear that there is any UI that can communicate that. We can ask for solid UX studies that users understand the right thing from some plausable UI...

Dan: user need.

Yves: SSO was listed .. but if fedCM is here then maybe it's not needed?

Peter: the user need is a need for business to maintain their current product... current business model. and i don't think this actually serves... users. It's a dangerous weakening of the web security model and user protections to support a dangerous use case that never should have existed in the use case.

Matthew: they have some UX proposals.. you end up with 2 URL bars ... which is a really really big change... Setting aside the issues they might have about understanding the URL anyway, but having 2 URL bars that would cause implementation pushback...

Dan: the URL is important.

Lea: (1) cookie partitioning and (2) the UI component ... still unclear what that UI is... not sure how these mockups differ from ...

Jeffrey: there's a "please note"...

Lea: what I was going to say is that the most contraversial of the 2 is the whole cookie thing... but not sure why that's needed. None of these address post messages... So why not just use post message? If this is a differnt way to open a popup...

Jeffrey: security benefits to using cookies ... we can make it more secure ... that's some of the motivation here.

Lea: but post message is just used when the popup communicates...

Jeffrey: yes but post message has to go through javascript... This would work without javascript. Core idea is that the authentication token is never exposed to javascript... The context here is that people hire companies to do their login for them - like Octa - so if your site is foo.example, it goes to foo.octa.com ... so it blocks cookies. There have been proposals to use CNAMES and some browsers have taken action to block use of CNAMES for this purpose... Authentication companies are worried about using CNAMEs for this purpose...

Lea: cost / benefit question is open but assuming they are useful - could we layer them differently? What if the different popup UI was a different component?

Jeffrey: example of this in the Arc browser today...

Dan: I've used Octa... I think the use case is valid...

Peter: but the reliance on 3p cookies - which was a bug ... what I'm opposed to is adding features to the web ... that exist purely to support someone's business needs... I have mixed feelings about the CNAME thing... there has been abuse of CNAMEs... fundamentally I get that user authentication is hard - and some people want to outsource that. fine with building a mechanism into the web platform to allow for that. Happy with a dedicated API to do user authentication.

Dan: yes - i agree if we

Lea: I agree it's a common flow - but fedcm us way down the line... Also wondering if the main advantage is the cookie partition thing is to do post message without JS then why not just do that... and the browser takes care of communicating it to those origins... Maybe instead of extending cookies or extending the security model of cookies...

Yves: what you described sounds like first party sets though... so might not be the perfect model... If you're defining what you want to export to another site... content of a header... Also re: fedcm not being implemented... therefore there should be a clear path to deprecating...

Jeffrey: another aspect - it's partitioned - it's not intened to share identities across the 2 sites - it's trying to be like an iframe... a general popup with post message would be too powerful.

Matthew: we discussed when we talked about document PiP that maybe there is a fundamental problem. I like the idea of decoupling UI but in this case since it's privacy maybe not... They compare themselves to fedcm - what about lightweight fedcm?

dan to draft a comment based on above

Jeffrey: they announced a dev trial ...

Jefrey: fedcm is for a 3rd party but this is for using a 3rd party only for authentication - but on behalf of the first party ...

.. the explainer doesn't actually explain the use case...

we discuss CNAMES as an alternate way of supporting an oursourced authentication service

Peter: hard to say CNAMES is a good pattern ...

Hadley: I think there is a clear distinction in the use cases, especially re how much you need to trust the third party. You have to trust whoever is doing your authentication, because they can authenticate as anyone. You don't have to trust you advertisers though -- that's not how the ecosystem works..

Dan: posts comment