The use case of not having to log in to system A which is being embedded within system B because you already logged in to system A? Without needing to introduce a third party SSO C? That's pretty "regular human", even if it's "medium sized corporation" instead of "Joe Regular" (but even Joe likes it if he doesn't have to log into the comment box on every site that uses THE_COMMENT_SYSTEM_HE_LIKES.)
This exists already. You can have cookies at higher level of the same domain. So foo.example.com and bar.example.com can share cookies at example.com. You can also use CORS to interact with a truly third party site. None of these require third party cookies.
A use case this doesn't address is embedding across two completely different domains, which is pretty common in the education space with LMS platforms like Canvas (https://www.instructure.com/canvas) embedding other tools for things like quizzes, textbooks, or grading. I ended up in a Chrome trial that disabled third-party cookies which broke a lot of these embeds because they can no longer set identity cookies that they rely on from within their iframe.
As nwalters also points out, this isn't the same at all. System A and System A' both from Source Α are not the same as System A (Source Α) and System B (Source Β).
Which you know, because you say "you can also use CORS to interact with a truly third party site". But now, I invite you to go the rest of the way - what if the third party site isn't Project Gutenburg but `goodreads.com/my-reading-lists`? That is, what if the information that you want to pull into System A from System B should only be available to you and not to anyone on the net?
BINGO! The issue here of course is that now instead of _two_ components (Front End A and Embed B) you now have four (the back ends must communicate and if A didn't need a back end ... well, now it does).
Now, if you meant "Use OAuth2 in the browser", that's just the original case (you can't authorize if you can't authenticate and it's the ambient authentication that's being stripped when you eliminate third party cookies).
You might not want to log in to both systems. For this specific case a link can still be used to the service that permits adding comments, that you are logged in to already, without needing to use third-party cookies.
Furthermore, cookies are not a very good way of doing logins. There are other problems with them, including of stealing them if someone else takes over the service, and of difficulty of users knowing what they are if they want to modify or delete specific cookies, and that the server must set the expiry which makes it difficult for end users to control. Methods that are controlled by the end user would be better.
Other methods of authentication can include:
- HTTP basic and digest authentication (which has some of the same problems).
- Two-factor authentication, which has many problems (especially if they are badly implemented).
- HMAC. For things that only require authentication for write access and that are idempotent, it should be safe whether or not the connection is encrypted. A proxy could spy on the operation but can only use it to do the same operation that you had just done, and cannot be used to do any other operation. However, these characteristics are not valid for all systems; e.g. it does not prevent replay and does not prevent spying on what you are doing. For uploading files to a server that are never changed or deleted, if the files are public anyways, and anyone already knows who uploaded them and when, and if nothing else is done with this authentication, then HMAC will work.
- X.509 client certificates. This requires TLS, although many servers already do anyways (although I think that for things that do not require authentication, the TLS should be optional instead). This is secure; if a server obtains a copy of your certificate they cannot use it to impersonate you. Furthermore, X.509 can be used to log in to multiple services without needing an authentication server, and a kind of 2FA is possible if the private key is passworded (and the server you are logging in to will never see the private key or the password). Also, it can be signed by a different issuer certificate that has a different key (the issuer certificate is normally someone else but could also be controlled by yourself as well if you want to); you could store the private key of the issuer certificate in a separate computer not connected to the internet (possibly in addition to being passworded), providing some additional protection if the subject certificate is compromised. There are many other benefits as well.
