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

Wed Jun 6 22:05:35 UTC 2018

To be clear, I wasn't /advocating/ individual engagements. I was 
describing what happened the last time a similar situation presented itself.

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

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
>>>
>>>       
>>>
>>>   
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180606/9d94cd2b/attachment.html>