Bug 185372 - Intelligent Tracking Prevention blocking Norwegian BankID authentication service
Summary: Intelligent Tracking Prevention blocking Norwegian BankID authentication service
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari 11
Hardware: All Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-07 01:14 PDT by Kristoffer Skaret
Modified: 2018-05-14 10:51 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kristoffer Skaret 2018-05-07 01:14:28 PDT
BankID is an identity provider with 3.7 million users (90 % of the adult population in Norway). BankID is used by all the country’s banks and public digital services and an increasing number of enterprises in a range of different sectors.
 
Our latest addition to the product portfolio is an authentication service based on the OpenID Connect protocol. The service is public and centralized, and needs to be accessed from a large number of different domains. More information: https://confluence.bankidnorge.no/confluence/pdoidcl/introduction
 
The new service is highly dependent upon cookies via different components. One of these is Keycloak, one of the leading certified OpenID Connect implementations. This means other parties may also be affected by the problem.
 
Our challenge is that ITP occasionally seems to classify the service as a tracker and causes Safari to handle the cookies as third party ones. That makes the service unusable in those cases.
 
We have found this issue where a similar problem is reported: https://bugs.webkit.org/show_bug.cgi?id=178762
In the response, John Wilander states that «a couple of features are under consideration» to help sort this out.
 
1.      Could you provide more information about the possible features?
2.      If a solution is already on the way, when could we expect it to be ready?
3.      If necessary, we are interested in discussing different alternatives to the ensure the functioning of the new BankID services for Safari users.


Regards, Kristoffer Skaret
Comment 1 Radar WebKit Bug Importer 2018-05-07 22:58:22 PDT
<rdar://problem/40049378>
Comment 2 John Wilander 2018-05-07 23:28:39 PDT
Hi Kristoffer, and thanks for your report.

Have you read about the Storage Access API?
https://webkit.org/blog/8124/introducing-storage-access-api/
Comment 3 Kristoffer Skaret 2018-05-09 01:38:40 PDT
Hi John Wilander.
Thanks for the tip.

The Storage Access API is clearly a step in the right direction. It seems to be a helpful solution to allow embedding of cross-site content in an iframe, and I think we can take benefit from it in some cases. But unfortunately it does not completely fulfill our needs.

To be clear, here is a quick overview of our needs:
- The service must be able to load both in an iframe or as a top level frame (through new window or redirect)
- The service needs access to cookies.
- The service must work without user interaction. In fact one of the main features is to be able to authenticate the user without any user interaction.
- The service is triggered from a large and increasing number of different domains.

Our challenge is that ITP limits the access to cookies even if the service is loaded in the browser’s top frame.

Do you have any other suggestions, or possible solutions? 
For instance, is there any possibility to «whitelist» our domain from ITP in any way?
Comment 4 John Wilander 2018-05-14 10:51:39 PDT
(In reply to Kristoffer Skaret from comment #3)
> Hi John Wilander.
> Thanks for the tip.
> 
> The Storage Access API is clearly a step in the right direction. It seems to
> be a helpful solution to allow embedding of cross-site content in an iframe,
> and I think we can take benefit from it in some cases. But unfortunately it
> does not completely fulfill our needs.
> 
> To be clear, here is a quick overview of our needs:
> - The service must be able to load both in an iframe or as a top level frame
> (through new window or redirect)
> - The service needs access to cookies.
> - The service must work without user interaction. In fact one of the main
> features is to be able to authenticate the user without any user interaction.
> - The service is triggered from a large and increasing number of different
> domains.
> 
> Our challenge is that ITP limits the access to cookies even if the service
> is loaded in the browser’s top frame.
> 
> Do you have any other suggestions, or possible solutions? 
For instance, is
> there any possibility to «whitelist» our domain from ITP in any way?

The list of requirements you provide are things that allow cross-site tracking. That's exactly how cross-site tracking works.
   Our proposed solution is to adopt the Storage Access API and see how it works out for your customers. If there are enhancements to it that you think we can implement without opening up for cross-site tracking, we will absolutely take those into consideration. But any changes have to stand up against abuse cases and be something the user can understand.