johannhof
commented
8 months ago Hi @sebastiannielsen, thanks for filing an issue. I personally haven't been aware of BankID so far. RWS is meant to be a web platform mechanism that is relatively agnostic to the business incorporating it, within the constraints of the set formation requirements for service sites, associated, etc. of course.
From your comment, it sounds like you're not actually encountering any breakage and the affected sites don't seem to use third-party cookies for their authentication schemes? If you do encounter any breakage, on the Chrome side we'd love to hear about it at https://goo.gle/report-3pc-broken, which will help us dig deeper into the specific needs of the site and determine the right mitigations / APIs that should be used.
That might be RWS, or another solution such as FedCM, it depends a lot on how the application is actually structured and the business requirements behind their architecture (I.e. to what degree they can change their existing implementation). In your example, it sounds like there would be an exchange of information between multiple unrelated third parties (Webshop, Klarna, Nordea, IdP) which is by definition not a valid use case for RWS. If skatteverket.se and funktionstjanster.se are related sites, they could make use of RWS to solve their third-party cookie breakage (again, if there's actually any breakage).
Closing this issue for now as it doesn't seem actionable but happy to follow up in case you have another question.
Here in sweden, we have a lot of sites that login through a common "provider" site, but they are not OAUTH2 compatible (OAUTH2 doesn't fullfill bank standards, mainly that the RP could provision a longer login time than a IDP allows).
One example, is that when you login on https://www.skatteverket.se (tax agency in sweden to do tax declaration), which then redirects user to: https://m01-mg-local.auth.funktionstjanster.se , which performs the login, and then sets a third-party cookie that https://www.skatteverket.se can access.
The login method is not standarized (its a local mobile app called "BankID" containing a government-issued login token public and private key) meaning the current Webauthn and identity APIs doesn't work since the login method is neither Passkey, FIDO2 or a username/password combination.
Instead, you usually scan a QR code (with an app) containing a challenge, or you already have a established session so they initiate a signature or similiar based on the social security number currently logged in.
I note however that even tough the browser informs me that 3rd party cookies being blocked on the site m01-mg-local.auth.funktionstjanster.se , it still works, so I guess they worked around the 3rd party cookie phaseout somehow. I guess they detect third party cookies being blocked, and they then somehow work it around.
But still, its important that RWS doesn't break this functionality, as there is a like a tousands sites that login through a "common" government endpoint like this way. Banks, government entites.
The trust chains can in these ways become super long. Imagine a webshop, implementing a common checkout from ProviderA, which in turn implements Klarna (a post-payment billpay method https://www.klarna.se ) which in turn needs to identify the user via BankID through their bank to confirm that they own a bank account.
It would be: Webshop --> Requesting login to Provider A --> Requests login to Klarna --> Request login to lets say Nordea --> Request login through Nordea's identity provider.
Theres a hell lot of third party cookies in this soup of different providers involved in a webshop transaction.
And requiring sites to submit to a public "repostitory" and then get "approved" just to implement BankID login on their websites. Im kind of scared this 3rd party cookie phaseout will totally break BankID in sweden.