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

Wed Jun 6 20:40:10 UTC 2018

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:
>
> 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 <openid-specs-ab-bounces at lists.openid.net> *On 
> Behalf Of *Vittorio Bertocci via Openid-specs-ab
> *Sent:* Wednesday, June 6, 2018 12:05 PM
> *To:* David Waite <david at alkaline-solutions.com>
> *Cc:* openid-specs-ab at lists.openid.net
> *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:
>     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/73c0049c/attachment.html>