<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>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.<br>
    </p>
    <p>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?<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 6/6/18 12:18 PM, Mike Jones wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:BL0PR00MB029274DC3D70118EEBC3F163F5650@BL0PR00MB0292.namprd00.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#002060;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1207449551;
        mso-list-template-ids:1542638902;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#002060">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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#002060">                                                      
            -- Mike<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#002060"><o:p> </o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
                style="color:windowtext"> 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>
                <b>On Behalf Of </b>Vittorio Bertocci via
                Openid-specs-ab<br>
                <b>Sent:</b> Wednesday, June 6, 2018 12:05 PM<br>
                <b>To:</b> David Waite
                <a class="moz-txt-link-rfc2396E" href="mailto:david@alkaline-solutions.com"><david@alkaline-solutions.com></a><br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a><br>
                <b>Subject:</b> Re: [Openid-specs-ab] ITP and OIDC
                session issues<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p>Thanks David.<o:p></o:p></p>
        <p>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).<o:p></o:p></p>
        <p>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.<o:p></o:p></p>
        <p>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.<o:p></o:p></p>
        <p>Thx<o:p></o:p></p>
        <p>V.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">On 6/6/18 10:58 AM, David Waite wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">Hi Vittorio, <o:p></o:p></p>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">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.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">They had this blog post about the
              change: <a
                href="https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/"
                moz-do-not-send="true">https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/</a><o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">The RFC is for the session access API
                that they have implemented above, prompting the user and
                requiring user interaction to use.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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. <o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">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.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">-DW<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><br>
                <br>
                <o:p></o:p></p>
              <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
                <div>
                  <p class="MsoNormal">On Jun 6, 2018, at 9:53 AM,
                    Vittorio Bertocci via Openid-specs-ab <<a
                      href="mailto:openid-specs-ab@lists.openid.net"
                      moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
                    wrote:<o:p></o:p></p>
                </div>
                <p class="MsoNormal"><o:p> </o:p></p>
                <div>
                  <div>
                    <p class="MsoNormal"
                      style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
                        style="font-size:9.5pt">Hi all,<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-decoration-style:initial;text-decoration-color:initial"><span
                        style="font-size:9.5pt">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.<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:47.25pt;text-indent:-.25in;mso-list:l0
                      level1 lfo1">
                      <!--[if !supportLists]--><span
                        style="font-size:10.0pt;font-family:Symbol"><span
                          style="mso-list:Ignore">·<span
                            style="font:7.0pt "Times New
                            Roman"">       
                          </span></span></span><!--[endif]--><span
                        style="font-size:9.5pt">Did anyone else
                        experience similar issues?<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:47.25pt;text-indent:-.25in;mso-list:l0
                      level1 lfo1">
                      <!--[if !supportLists]--><span
                        style="font-size:10.0pt;font-family:Symbol"><span
                          style="mso-list:Ignore">·<span
                            style="font:7.0pt "Times New
                            Roman"">       
                          </span></span></span><!--[endif]--><span
                        style="font-size:9.5pt">What are the WG's
                        thoughts about whether this calls for a revision
                        of how session works in OIDC?<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:47.25pt;text-indent:-.25in;mso-list:l0
                      level1 lfo1">
                      <!--[if !supportLists]--><span
                        style="font-size:10.0pt;font-family:Symbol"><span
                          style="mso-list:Ignore">·<span
                            style="font:7.0pt "Times New
                            Roman"">       
                          </span></span></span><!--[endif]--><span
                        style="font-size:9.5pt">There is one RFC for
                        WebKit that could provide an alternative
                        location for the session, detailed
                        <a
                          href="https://github.com/whatwg/html/issues/3338"
                          moz-do-not-send="true">here</a>. Did anyone
                        consider it? Any insights?<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-decoration-style:initial;text-decoration-color:initial"><span
                        style="font-size:9.5pt">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.<o:p></o:p></span></p>
                    <p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-decoration-style:initial;text-decoration-color:initial"><span
                        style="font-size:9.5pt">Thanks in advance for
                        your insights<o:p></o:p></span></p>
                    <p class="MsoNormal">V. <o:p></o:p></p>
                  </div>
                  <p class="MsoNormal">_______________________________________________<br>
                    Openid-specs-ab mailing list<br>
                    <a href="mailto:Openid-specs-ab@lists.openid.net"
                      moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br>
                    <a
                      href="http://lists.openid.net/mailman/listinfo/openid-specs-ab"
                      moz-do-not-send="true">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><o:p></o:p></p>
                </div>
              </blockquote>
            </div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
        </blockquote>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>