<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>To be clear, I wasn't <i>advocating</i> individual engagements.
I was describing what happened the last time a similar situation
presented itself.</p>
<p>Hopefully there can be heuristics used to distinguish IdPs from
trackers that don't entail checking against a list.<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/6/18 1:50 PM, Nick Roy wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SN1PR0801MB1518AFAF95152E635FD816AD83650@SN1PR0801MB1518.namprd08.prod.outlook.com">
<pre wrap="">Individual company agreements don't work when you have 2748 IdP/OP[1]
across 51 countries [2].
Those are SAML deployments, but at some point hopefully lots of them
will be OIDC-fed deployments, too.
Nick
[1] <a class="moz-txt-link-freetext" href="https://met.refeds.org/">https://met.refeds.org/</a>
[2] <a class="moz-txt-link-freetext" href="https://technical.edugain.org/status">https://technical.edugain.org/status</a>
On 6/6/18 2:40 PM, Vittorio Bertocci via Openid-specs-ab wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, the analogies with last year's initiative are strong... but I seem
to remember that after an initial coordinated effort, things broke down
into individual companyX->Apple engagements. However things did get better.
As far as clear ask, I like David's language below: "how federated login
sites can avoid being classified as tracking under ITP". What do we think?
On 6/6/18 12:18 PM, Mike Jones wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
For what it’s worth, the OpenID community successfully engaged with
Apple last year to prevent them from breaking SSO when iOS 11 was
released. Apple added the SFAuthenticationSession API in response to
the feedback provided. It’s probably possible for us to engage to
prevent breakage again if there’s a clear problem definition and ask.
-- Mike
*From:*Openid-specs-ab <a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab-bounces@lists.openid.net"><openid-specs-ab-bounces@lists.openid.net></a> *On
Behalf Of *Vittorio Bertocci via Openid-specs-ab
*Sent:* Wednesday, June 6, 2018 12:05 PM
*To:* David Waite <a class="moz-txt-link-rfc2396E" href="mailto:david@alkaline-solutions.com"><david@alkaline-solutions.com></a>
*Cc:* <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
*Subject:* Re: [Openid-specs-ab] ITP and OIDC session issues
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: <a class="moz-txt-link-freetext" href="https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/">https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/</a>
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 <<a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:openid-specs-ab@lists.openid.net"><mailto:openid-specs-ab@lists.openid.net></a>> 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
<a class="moz-txt-link-rfc2396E" href="https://github.com/whatwg/html/issues/3338"><https://github.com/whatwg/html/issues/3338></a>. 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
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-rfc2396E" href="mailto:Openid-specs-ab@lists.openid.net"><mailto:Openid-specs-ab@lists.openid.net></a>
<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>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>