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

[Nick Roy]

On 6/6/18 4:05 PM, Vittorio Bertocci wrote:
> To be clear, I wasn't /advocating/ individual engagements. I was
> describing what happened the last time a similar situation presented itself.

Understood - I'm just expressing dismay at browser behavior that breaks
the web.

> 
> Hopefully there can be heuristics used to distinguish IdPs from trackers
> that don't entail checking against a list.

That seems like the right thing to do.

Nick

> 
> 
> On 6/6/18 1:50 PM, Nick Roy wrote:
>> 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
>>>>
>>>>      
>>>>
>>>>  
>>>>
>