<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thanks David.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>Thx</p>
<p>V.<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/6/18 10:58 AM, David Waite wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8A71E9E9-8309-42E3-9276-E3AC1F66665F@alkaline-solutions.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
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="" moz-do-not-send="true">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=""
moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="content-type" content="text/html;
charset=utf-8" 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="" moz-do-not-send="true">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=""
moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
<br>
</body>
</html>