<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">Is there any chance you can convince Apple that the changes they make to the Safari ViewController are actually bad for security?</div> <br> <div id="bloop_sign_1498202242109916928" class="bloop_sign"><div><br></div><div>-------</div><div>Dominick Baier</div></div> <br><p class="airmail_on">On 20. June 2017 at 14:56:30, William Denniss via Openid-specs-ab (<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">From a technical standpoint, I believe mobile Safari
is currently the best option for native app OAuth in iOS 11.
Furthermore, due to UI improvements to how iOS performs the app
switch, it's a <i>lot</i> nicer than when we last tried it in iOS 8
(where the context switch tended to feel a bit jarring).
<div><br></div>
<div>
<div>The main issue in the past however was obtaining the
policy <a href="http://openradar.appspot.com/radar?id=5744622710030336">permission</a>
to use mobile Safari for sign-in. Your note is very intriguing
Chuck.</div>
<div><br></div>
<div>I'm thinking of adding mobile Safari as a supported option in
AppAuth for iOS, for those who have the ability to use it.</div>
<div><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 14, 2017 at 1:55 PM, Chuck
Mortimore via Openid-specs-ab <span dir="ltr"><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">We've managed to work through that with Apple, and
have been using this technique on iOS for targeted use-cases for
some time now. Note that it is optional, and our default
behavior is still in app.</div>
<div class="m_-4694519544218165218HOEnZb">
<div class="m_-4694519544218165218h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 14, 2017 at 11:09 AM, Iain
McGinniss <span dir="ltr"><<a href="mailto:iainmcgin@google.com" target="_blank">iainmcgin@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><span>On Wed, Jun 14, 2017 at 10:40 AM,
Chuck Mortimore via Openid-specs-ab <span dir="ltr"><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>></span>
wrote:<br></span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">We're proceeding with an implementation that allows
us to target mobile safari or a registered mobile app as the
IDP. Perhaps a little closer to earlier drafts. Happy
to share our plans if anyone is interested.</div>
</blockquote>
<div><br></div>
<div>Google Sign-in used to switch to Safari or an installed Google
app to perform authorization, and Apple stated that this was
against their policy and started rejecting apps from the app store
that used this pattern. SafariViewController is the only explicitly
permitted mechanism for federated identity on iOS.</div>
<div><span class="m_-4694519544218165218m_-4762860017432050714HOEnZb"><font color="#888888"><br></font></span></div>
<div><span class="m_-4694519544218165218m_-4762860017432050714HOEnZb"><font color="#888888">Iain</font></span></div>
<div>
<div class="m_-4694519544218165218m_-4762860017432050714h5">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075HOEnZb">
<div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 14, 2017 at 8:09 AM, George
Fletcher via Openid-specs-ab <span dir="ltr"><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><font face="Helvetica, Arial, sans-serif">However, if the user is using iCloud
keychain, then their credentials should be filled in for the user
so not too bad. The issue, is that if account is using 2FA the user
will have to do the 2FA dance for every app. That could be a
pain.<br>
<br>
Thanks,<br>
George<br></font>
<div>
<div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962h5">
<br>
<div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-cite-prefix">
On 6/13/17 5:57 PM, Justin Richer via Openid-specs-ab
wrote:<br></div>
<blockquote type="cite">This has nothing to do with OIDC’s session
management, but rather sessions in the browser itself. From
what I understand, the per-app silos would prevent the OP from
knowing it’s the same user coming in from different apps, since
they wouldn’t have access to the session and cookie jar. So the UX
degrades rather poorly as the user is prompted to log in separately
to their identity provider (with primary credentials) from every
single app.
<div><br></div>
<div> — Justin</div>
<div><br>
<div>
<blockquote type="cite">
<div>On Jun 13, 2017, at 5:40 PM, rich levinson via Openid-specs-ab
<<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>>
wrote:</div>
<br class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124Apple-interchange-newline">
<div>
<div text="#000000" bgcolor="#FFFFFF">Hi Nat, et al,<br>
<br>
I am not sure I understand why this situation should cause anything
to "break".<br>
<br>
Let me explain my view of this situation, in the context of general
session mgmt,<br>
which is the following:<br>
<br>
In the "OpenID Connect Session Management 1.0" spec:<br>
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-session-1_0.html" target="_blank">http://openid.net/specs/openid<wbr>-connect-session-1_0.html</a><br>
it says:<br>
<blockquote>
<pre>"In OpenID Connect, the session at the RP typically starts
when the RP validates the End-User's ID Token.
...
When the OP supports session management, it MUST also return the Session State
as an additional session_state parameter in the Authentication Response.
...
This parameter is:
session_state
Session State.
JSON [RFC7159] string that represents the End-User's login state at the OP.
It MUST NOT contain the space (" ") character.
This value is opaque to the RP.
This is REQUIRED if session management is supported.
The Session State value is initially calculated on the server."
</pre></blockquote>
This indicates that the OP has knowledge of the End-User's login
state at the OP.<br>
However, this login state is independent of the "session at the
RP", which is<br>
created when the client app (RP) rcv's the identity token which, in
the protocol,<br>
is well after the End-User logged in at the OP.<br>
<br>
Later in the spec, section 5, it is also stated that:<br>
<blockquote>
<pre>"5. RP-Initiated Logout
An RP can notify the OP that the End-User has logged out of the site and
might want to log out of the OP as well.
In this case, the RP, after having logged the End-User out of the RP,
redirects the End-User's User Agent to the OP's logout endpoint URL.
This URL is normally obtained via the end_session_endpoint element
of the OP's Discovery response or may be learned via other mechanisms."
</pre></blockquote>
This basically confirms the supposition above that the OP login and
the RP session are<br>
effectively independent entities.<br>
<br>
Now, let's consider the case where a 2nd RP decides to start a
session w the same End-User,<br>
presumably, a 2nd RP on the same device where the 1st RP
established a session.<br>
<br>
When the 2nd RP sends the Authentication Request to the OP's
/authorize endpoint,<br>
it seems obvious to me that the OP knows the End-User is logged in
and would have<br>
no problem issuing a 2nd id-token to the 2nd RP, w/o re-logging in
the End-User.<br>
<br>
Assuming this is the case, then I do not understand why ios-11, by
"siloing" the apps<br>
prevents the OP from issuing new id-tokens to each app, all under
the original<br>
OP-login by the End-User.<br>
<br>
Am I missing something?<br>
<br>
Thanks,<br>
Rich<br>
<br>
<br>
<br>
<br>
<div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-cite-prefix">
On 6/12/2017 8:04 PM, Nat Sakimura via Openid-specs-ab
wrote:<br></div>
<blockquote type="cite">
<div dir="ltr">Maybe we can call upon the privacy community as well
raising the voice that this is very bad for privacy.
<div>I wonder what is the privacy enhancement they have in
mind. </div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Jun 9, 2017 at 2:34 AM 'Iain McGinniss' via
OIDF Account Chooser list <<a href="mailto:oidf-account-chooser-list@googlegroups.com" target="_blank">oidf-account-chooser-list@goo<wbr>glegroups.com</a>>
wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello all,
<div><br></div>
<div>Just to bring this to your attention: Apple has essentially
killed single sign-on for native apps in iOS 11. Changes made to
SFSafariViewController (used by AppAuth, and the recommended
mechanism for federated login by Apple) now mean that browser state
is partitioned per app, so there is no way for an existing
authentication in the browser to be reused by an app.</div>
<div><br></div>
<div>This fundamentally breaks an important part of OpenID Connect
- users will now need to re-authenticate with their IDP in every
app that they use. There is still time to provide feedback to Apple
on this change, though they have been discussing this change in
terms of "enhancing privacy" and I'd be very surprised if they
change tack now.</div>
<div><br></div>
<div>Iain</div>
</div>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google
Groups "OIDF Account Chooser list" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a href="mailto:oidf-account-chooser-list+unsubscribe@googlegroups.com" target="_blank">oidf-account-chooser-list+unsu<wbr>bscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-mdMgac&s=XtvXRyjw8QvajPlQD8M0d6xQJnp_3jK9zv_hDOXEOXY&e=" target="_blank">https://groups.google.com/d/op<wbr>tout</a>.<br></blockquote>
</div>
<div dir="ltr">--<br></div>
<div data-smartmail="gmail_signature">
<p dir="ltr">Nat Sakimura</p>
<p dir="ltr">Chairman of the Board, OpenID Foundation</p>
</div>
<br>
<fieldset class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124mimeAttachmentHeader">
</fieldset>
<br>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-freetext" href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-mdMgac&s=tYftjD7QNKeiH9oZIyspoUu_QX44iHnFoAzyiuQapmg&e=" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__lists.op<wbr>enid.net_mailman_listinfo_open<wbr>id-2Dspecs-2Dab&d=DwICAg&c=RoP<wbr>1YumCXCgaWHvlZYR8PQcxBKCX5YTpk<wbr>KY057SbK10&r=nNxUKneeZofWTyt9q<wbr>clOUTeEg29NkEkknFyDupoNiiA&m=z<wbr>6H6MqLIToKnju5TQdKnYOa6pGD9lyM<wbr>xhwLO-mdMgac&s=tYftjD7QNKeiH9o<wbr>ZIyspoUu_QX44iHnFoAzyiuQapmg&e<wbr>=</a>
</pre></blockquote>
<br></div>
______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><br>
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-ab</a><br>
</div>
</blockquote>
</div>
<br></div>
<br>
<fieldset class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124mimeAttachmentHeader">
</fieldset>
<br>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-ab</a>
</pre></blockquote>
<br></div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-ab</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-ab</a><br>
<br></blockquote>
</div>
</div>
</div>
<br></div>
</div>
</blockquote>
</div>
<br></div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-ab</a><br>
<br></blockquote>
</div>
<br></div>
</div>
</div>
</div>
_______________________________________________
<br>Openid-specs-ab mailing list
<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
<br></div></div></span></blockquote></body></html>