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

[Nick Roy]

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] https://met.refeds.org/
[2] https://technical.edugain.org/status

On 6/6/18 2:40 PM, Vittorio Bertocci via Openid-specs-ab wrote:
> 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
>>
>>      
>>
>>  
>>
>