<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Lucida Console;color: #000000">
This reminds me of the "security zones" feature in IE and how painful that is/was. I have heard that they will be removing it (I guess from Edge?).<br><div><br></div><div class="mb_sig"><span style="font-family: Lucida Console">-Brock</span><div><br></div></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">On 6/6/2018 2:07:25 PM, David Waite via Openid-specs-ab <openid-specs-ab@lists.openid.net> wrote:</p>Hi Vittorio,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">They had this blog post about the change: <a href="https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/" class="">https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/</a></div><div class=""><br class=""></div><div class="">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.<br class=""><div><br class=""></div><div>The RFC is for the session access API that they have implemented above, prompting the user and requiring user interaction to use.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div><br class=""></div><div>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. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div>-DW</div><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 6, 2018, at 9:53 AM, Vittorio Bertocci via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p style="font-size: 12.8px;text-decoration-style: initial;text-decoration-color: initial" class="">Hi
all,</p><p style="font-size: 12.8px;text-decoration-style: initial;text-decoration-color: initial" class="">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.<br class="">
</p>
<ul style="font-size: 12.8px;text-decoration-style: initial;text-decoration-color: initial" class="">
<li style="margin-left:15px" class="">Did anyone else experience similar
issues?</li>
<li style="margin-left:15px" class="">What are the WG's thoughts about
whether this calls for a revision of how session works in OIDC?</li>
<li style="margin-left:15px" class="">There is one RFC for WebKit that
could provide an alternative location for the session, detailed
<a href="https://github.com/whatwg/html/issues/3338" class="">here</a>.
Did anyone consider it? Any insights?</li>
</ul><p style="font-size: 12.8px;text-decoration-style: initial;text-decoration-color: initial" class="">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.</p><p style="font-size: 12.8px;text-decoration-style: initial;text-decoration-color: initial" class="">Thanks
in advance for your insights</p>
V.
</div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div>
</blockquote>
</div>