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

Jeffrey: Johan asked questions about this that we should answer. Breakout next week?

Peter: be good to get Lea involved

Matthew: would seem reasionable we don't have an opinion on UX until we get the results of the study. Sounds like they are wanting to do some actual evidence gathering so we'd want to see it wouldn't we?

Jeffrey: yeah and this is the early review so they'll file something else when they're ready to ship. Plausibly this could be esatisfied with conerns pending the UX, but worth figuring out the second half of the question

Jeffrey: we should answer the question about complexities of popin approach

Dan: I channelled discussion..

Jeffrey: I think the complexity is the questions about how to do the UI to present the fact that it's partitioned but still looks like a popup. I think that was interpreted as developer complexity but it's UI complexity

Dan: yeah. We don't want to specify UI..

jeffrey: important for specs to give an example of good UI. We don't specify UI, but it should be clear it's implementable with good UI.

Hadley: I agree. Having an example makes the point better than anything else would

Jeffrey: also assumption that we have to keep popups as the way of doing these things.. I don't know we agree that popups need to stay a critical part of these flows. Some of our anser might be please keep an open mind, maybe getting rid of popups is the right answer

Dan: related to payment flows?

Jeffrey: payment and login of various sorts

Peter: talks about login flows and id as a service providers

Jeffrey: lots of sites find it useful to contract out their authentication

Peter: they use particular mechanisms that rely on third party cookies. There are other mechanisms that don't necessarily require this. Not sure if the use cases are broad enough.

Jeffrey: a bunch of small companies probably really need this to work

Dan: is it necessary to add this new thing which adds a whole bunch of new complexity in the UI, and a new kind of identity that the user needs to be able to parse, in order to satisfy these cases? Or can the cases be satisfied with existing technologies? Is it just trying to streamline something? Or do we really need this witout 3p cookies or we can't do it? The other question is if not FedCM then what other technologies are in the pipeline that could more reasonably implement this user flow? Rather than a new type of partitioned identity.

Peter: is there anybody really working on the SSO type solution? There's also.. I know I've seen various review requests for managing logged in state. I wish .. it's long overdue that browsers have a role to play in user authentication and session management. Almost every website ends up rolling their own or falling back on some third party provider. We have Basic Auth which has bad UX. Client Certs has its own problems. Everybody has to role something else. Why don't we have proper APIs in the browser to begin sessions, detect if the user logged in, do session management/ If we had those we could add the hooks to do third party providers and SSO in a clean way.

Dan: instructive anecdote - I agree with the doom and gloom. On the other hand... I bought cheese, wine and chocolate - all essentials - from websites that supported web payment. I didn't have to log into any of those sites. I used web payment from my browser. I said I want it delivered here. I didn't use apps. Nobody tried to steer me to apps or login. No SSO. That's the future we hsould be pushing people towards. This is how I want to be using the web. It doesn't ask for more than it needs, and it provides chocolate, wine and cheese. All using browsers blocking third party cookies. These capabilities do exist.

Dan: I can log into dev.to with Github credentials, even without 3p cookies, so what's the real problem we're trying to solve here.

Jeffrey: Federated identity is actually a privacy issue; we'd rather people use 1p login. Someone's going to be able to smuggle identifying info through URLs...

Peter: that's what SAML does...

Jeffrey: maybe the answer to this API is - we're not gonna block SAML so why do you need these pop-ins?

Jeffrey: I don't think we'll be effective if we just say "don't do this". I think we can say "we're still nervous" - please keep looking for alternatives.

Peter: Someone should be working on solving Okta "well".

Jeffrey: I think this team would say that's what they're working on, that if the UI can be solved, partitioned popins are a good way to handle Okta's use case.

Peter: I worry this isn't specific enough, and there aren't enough hooks for the browser to mitigate it. Rather a narrow focused API to solve the proper use case, that can't be abused for other things.

Dan: Johann might say this is the focused API.

Peter: This isn't though; it's not focused to authentication.

Peter to post:

It seems like some of these use cases could be solved by a narrow, focused API that is built to solve the specific use case (login flow), rather than by introducing a new technology that also introduces a new kind of partitioned identity, which introduces the potential for user confusion (and abuse).

Peter: users don't understand the concept of partitioned identity...

Jeffrey: the whole UI experiment is to explain to users that this is happening in the context of another site but give the same security guarantees... Can we do for a pop-up like thing what we already can do for iframe.

Jeffrey: we think it aligns with users' expectations...

Matthew: a debate .. between low level primitives you can build on top of .. vs. specific high-level focused APIs... I think we'd agree that if you're gonna do a low level API you need to make sure it's secure & private. The current impasse we have is: TAG has said a focused API in this case would be better - but Google say the lower level stuff is good and is more private than what currently exists. However the only use case they've given is the login one - which is legit - but are there additional use cases where you need short-lived pop-ups? So could we have more use cases?

Peter: I agree.

Matthew: we asked for additional use cases... we did get a reply with one additional use case: web apps that are embedded in cross-origin iframes... Not a long list.

Jeffrey: it's kind of fundamental that it's storage will be partitioned... if you have a partitioned iframe then the popup would be partitioned...

Jeffrey: what does safari do if an iframe opens a popup? I can poke them to add this to the explainer...

Dan: they don't appear to have answered the UI questions we've raised...

Jeffrey: an early review ...

Dan: could we say "this looks good ... needs more use cases ... needs UI issues and abuse cases delt with ... please come back to us when you have a more fleshed out design" ?

Jeffrey: the iframe issue is in there... I don't object to that...

Peter: the response of .. it does seem reasonable... i'm concerned about the abuse cases... if it's gated by a permission then how do you explain it to a user? I don't think users in general understand the concept of partitioned storage...

Jeffrey: I think it doesn't require a permission... they are using framework... but no user permission.

Matthew: https://github.com/explainers-by-googlers/partitioned-popins/blob/main/README.md#ux from the user's perspective.. the domain/subdomain will be shown in the pop-in. From their spective what are we trying to cue them to check? Seeing a pop-in with an address in it ... should that cue them that this is privelidged in some way ... we want to avoid specifying UI but that's my concern...

Peter: no indication to the user that the popin is related...

Jeffrey: mobile UI is spoofable... as popin is drawing in the content frame...

Jeffrey: I think they need a story about what users are supposed to trust... Security UX folks aren't convinced we have trustworthy UI: https://emilymstark.com/2022/12/18/death-to-the-line-of-death.html

Dan: e.g. Web Payment uses trustworthy UI... so if there is no trustworthy UI then why are we doing Web Payment?

Peter: shrinking the chrome so much to give more screen real estate .. puts us in the position where the browser content can be spoofing that chrome.

Dan: i think we need to operate from the position that there is trustworthy UI.

Jeffrey: https://www.w3.org/TR/design-principles/#trusted-ui

Dan: i think from a TAG pov we need to stick to our guns.

Peter: I also respect the problem that on mobile there's a trend of behavours that makes that less the case...

Dan: also for full screen webapps...

Peter: but in that case there has been an action the user has taken...

This looks like a good problem space to investigate. We'd like to see more use cases fleshed out, especially cross-site iframes opening popups on their own origin. We think the UI question is critical to a full analysis of this proposal: please let us know when you have a proposed design for that. We're also hoping to see a full description of what parts of that UI users are expected to learn to trust, and how various combinations of malicious top-level, embedded, and popup sites could take advantage of that user trust (that is, explain the "abuse cases" and how they're mitigated).

Please reopen this issue when we can look at that analysis.

general support

we agree to close it as "satisfied with concerns" - jeffrey to post the comment

Peter: I still have questions... if they can address the concerns then fine... if not, then ...