[Openid-specs-ab] ITP and OIDC session issues

[Vittorio Bertocci]

Thanks David.

Unfortunately server side session isn't an option for the JS SDK use 
case, where the app might not have a backend (and even if it does, 
enlisting it to acquire and renew tokens to be used by the JS frontend 
would entail adding legs to the protocol).

About your conversation with Apple: would you be able to keep the list 
updated on what you learn from them? I would be happy to join the 
conversation and articulate the SDK use case, if that helps.

Use of iFrames for renewing tokens has never been trouble free (the 
zones in IE Brock mentioned in a different branch, disabled 3rd party 
cookies etc) but this change would make the problem far more ubiquitous, 
to the point that standard workarounds (don;t disable 3rd party cookies; 
etc) will go from controversial to unfeasible.

Thx

V.


On 6/6/18 10:58 AM, David Waite wrote:
> Hi Vittorio,
>
> Yes, Apple seems to be further moving from a model where all state is 
> isolated not just on the origin of the content, but segmented on both 
> the top-level URL bar location and the remote origin, e.g. a (local 
> location, remote location) pair.
>
> They had this blog post about the change: 
> https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
>
> The option to prompt the user for storage access that apple has 
> provided should only prompt once per site (hopefully), but can only be 
> triggered once the user has interacted with that site, e.g. clicked on 
> the iframe. So prompting is likely not only a bad UX from prompting, 
> but would require the user to interact with a component that isn’t 
> providing obvious value.
>
> The RFC is for the session access API that they have implemented 
> above, prompting the user and requiring user interaction to use.
>
> Hopefully it is not too self-serving to note that the DTVA proposal 
> uses back-end API to coordinate session management, so it should not 
> be affected by this change.
>
>
> As a second point, I reached out to the web evangelist at Apple for 
> clarification on how federated login sites can avoid being classified 
> as tracking under ITP. In particular, it seems a fully transparent SSO 
> (without user interaction with the IDP site) may cause the IDP to be 
> classified, at which point future redirects for SSO will get a (RP, 
> IDP) segmented state, with the user appearing unauthenticated and the 
> browser looking like a unique browser.
>
> There are a lot of technical, security, and user knowledge/empowerment 
> reasons to always have an IDP interaction on SSO, but it is a behavior 
> that a lot of deployments strive very hard to avoid.
>
> -DW
>
>> On Jun 6, 2018, at 9:53 AM, Vittorio Bertocci via Openid-specs-ab 
>> <openid-specs-ab at lists.openid.net 
>> <mailto:openid-specs-ab at lists.openid.net>> wrote:
>>
>> Hi all,
>>
>> We have been having issues with renewing tokens via invisible iFrame 
>> in our Javascript SDKs in the latest version of Safari - and 
>> yesterday's news about ITP 2.0 seem to suggest that the new default 
>> on Apple devices will be equivalent to disabling 3rd party cookies, 
>> which AFAIK breaks OIDC session management... and/or start displaying 
>> dialogs warning the user that they are being tracked at every operation.
>>
>>   * Did anyone else experience similar issues?
>>   * What are the WG's thoughts about whether this calls for a
>>     revision of how session works in OIDC?
>>   * There is one RFC for WebKit that could provide an alternative
>>     location for the session, detailed here
>>     <https://github.com/whatwg/html/issues/3338>. Did anyone consider
>>     it? Any insights?
>>
>> If the issue is confirmed, that will make use of OIDC session and 
>> related token renewal machinery unfeasible on Macs, iPhones and 
>> iPads. And without official guidance, that will likely spur a cottage 
>> industry of custom solutions. I hope we can come up with guidance 
>> that addresses the problem before that happens.
>>
>> Thanks in advance for your insights
>>
>> V.
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net 
>> <mailto:Openid-specs-ab at lists.openid.net>
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180606/22a083fa/attachment.html>