<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I suspect the difference is between a app that has a social 'log in with google' button that launches a browser, vs a salesforce or slack app that asks for an email address to determine whether authentication happens internally or externally.</div><div class=""><br class=""></div><div class=""><div class="">I personally find my most solid mental model of Apple Store policy to be imagining to be run by old-school brick and mortar executives. I just come up with analogies of say 'would they let you do this in a Best Buy?'</div></div><div class=""><br class=""></div><div class="">Apple is willing to have services give away their app only if the upsell to paid service is either within apple's network (so that they get a cut) or *completely* external such that a case can be made that the app is not providing marketing value. Launching a browser via a button makes that relationship harder to evaluate.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2017, at 6:56 AM, William Denniss via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class="">lot</i> nicer than when we last tried it in iOS 8 (where the context switch tended to feel a bit jarring).<div class=""><br class=""></div><div class=""><div class="">The main issue in the past however was obtaining the policy <a href="http://openradar.appspot.com/radar?id=5744622710030336" class="">permission</a> to use mobile Safari for sign-in. Your note is very intriguing Chuck.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jun 14, 2017 at 1:55 PM, Chuck Mortimore via Openid-specs-ab <span dir="ltr" class=""><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class="">openid-specs-ab@lists.openid.<wbr class="">net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><div class="gmail_quote">On Wed, Jun 14, 2017 at 11:09 AM, Iain McGinniss <span dir="ltr" class=""><<a href="mailto:iainmcgin@google.com" target="_blank" class="">iainmcgin@google.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jun 14, 2017 at 10:40 AM, Chuck Mortimore via Openid-specs-ab <span dir="ltr" class=""><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class="">openid-specs-ab@lists.openid.<wbr class="">net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><br class=""></div></span><div class="">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><span class="m_-4694519544218165218m_-4762860017432050714HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Iain</div></font></span><div class=""><div class="m_-4694519544218165218m_-4762860017432050714h5"><div class=""> </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 class=""><div class="gmail_quote">On Wed, Jun 14, 2017 at 8:09 AM, George Fletcher via Openid-specs-ab <span dir="ltr" class=""><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" class="">openid-specs-ab@lists.openid.<wbr class="">net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000" class="">
<font face="Helvetica, Arial, sans-serif" class="">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 class="">
<br class="">
Thanks,<br class="">
George<br class="">
</font><div class=""><div class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962h5"><br class="">
<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 class="">
</div>
<blockquote type="cite" class="">
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 class=""><br class="">
</div>
<div class=""> — Justin</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">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" class="">openid-specs-ab@lists.openid.<wbr class="">net</a>>
wrote:</div>
<br class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124Apple-interchange-newline">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""> Hi Nat, et
al,<br class="">
<br class="">
I am not sure I understand why this situation should
cause anything to "break".<br class="">
<br class="">
Let me explain my view of this situation, in the context
of general session mgmt,<br class="">
which is the following:<br class="">
<br class="">
In the "OpenID Connect Session Management 1.0" spec:<br class="">
<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 class="">-connect-session-1_0.html</a><br class="">
it says:<br class="">
<blockquote class="">
<pre class="">"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 class="">
However, this login state is independent of the "session
at the RP", which is<br class="">
created when the client app (RP) rcv's the identity
token which, in the protocol,<br class="">
is well after the End-User logged in at the OP.<br class="">
<br class="">
Later in the spec, section 5, it is also stated that:<br class="">
<blockquote class="">
<pre class="">"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 class="">
effectively independent entities.<br class="">
<br class="">
Now, let's consider the case where a 2nd RP decides to
start a session w the same End-User,<br class="">
presumably, a 2nd RP on the same device where the 1st RP
established a session.<br class="">
<br class="">
When the 2nd RP sends the Authentication Request to the
OP's /authorize endpoint,<br class="">
it seems obvious to me that the OP knows the End-User is
logged in and would have<br class="">
no problem issuing a 2nd id-token to the 2nd RP, w/o
re-logging in the End-User.<br class="">
<br class="">
Assuming this is the case, then I do not understand why
ios-11, by "siloing" the apps<br class="">
prevents the OP from issuing new id-tokens to each app,
all under the original<br class="">
OP-login by the End-User.<br class="">
<br class="">
Am I missing something?<br class="">
<br class="">
Thanks,<br class="">
Rich<br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<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 class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">Maybe we can call upon the
privacy community as well raising the voice that
this is very bad for privacy.
<div class="">I wonder what is the privacy
enhancement they have in mind. </div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">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" class="">oidf-account-chooser-list@goo<wbr class="">glegroups.com</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">Hello all,
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Iain</div>
</div>
-- <br class="">
<br class="">
--- <br class="">
You received this message because you are
subscribed to the Google Groups "OIDF Account
Chooser list" group.<br class="">
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" class="">oidf-account-chooser-list+unsu<wbr class="">bscribe@googlegroups.com</a>.<br class="">
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" class="">https://groups.google.com/d/op<wbr class="">tout</a>.<br class="">
</blockquote>
</div>
<div dir="ltr" class="">-- <br class="">
</div>
<div data-smartmail="gmail_signature" class=""><p dir="ltr" class="">Nat Sakimura</p><p dir="ltr" class="">Chairman of the Board, OpenID
Foundation</p>
</div>
<br class="">
<fieldset class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="">______________________________<wbr class="">_________________
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 class="">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 class="">com/v2/url?u=http-3A__lists.op<wbr class="">enid.net_mailman_listinfo_open<wbr class="">id-2Dspecs-2Dab&d=DwICAg&c=RoP<wbr class="">1YumCXCgaWHvlZYR8PQcxBKCX5YTpk<wbr class="">KY057SbK10&r=nNxUKneeZofWTyt9q<wbr class="">clOUTeEg29NkEkknFyDupoNiiA&m=z<wbr class="">6H6MqLIToKnju5TQdKnYOa6pGD9lyM<wbr class="">xhwLO-mdMgac&s=tYftjD7QNKeiH9o<wbr class="">ZIyspoUu_QX44iHnFoAzyiuQapmg&e<wbr class="">=</a>
</pre>
</blockquote>
<br class="">
</div>
______________________________<wbr class="">_________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.n<wbr class="">et</a><br class="">
<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 class="">n/listinfo/openid-specs-ab</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="m_-4694519544218165218m_-4762860017432050714m_-4357492681076521075m_-1296803909472040962m_8510855096493843124mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="">______________________________<wbr class="">_________________
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 class="">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 class="">n/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
<br class="">
</div></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.n<wbr class="">et</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailma<wbr class="">n/listinfo/openid-specs-ab</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.n<wbr class="">et</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailma<wbr class="">n/listinfo/openid-specs-ab</a><br class="">
<br class=""></blockquote></div></div></div><br class=""></div></div>
</blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" class="">Openid-specs-ab@lists.openid.n<wbr class="">et</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" class="">http://lists.openid.net/mailma<wbr class="">n/listinfo/openid-specs-ab</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div></div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>