<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="">This does not sound like a good idea and in fact goes against the advice in the native apps spec, which says that each app should have a unique callback URL. <div class=""><br class=""></div><div class="">In order for this idea to work, you’d need to have everyone agree on a redirect URI generation scheme across all different apps, and have the AS recognize and process that scheme as well. This scheme could of course be easily coopted by attackers, but I don’t think that’s any different from the scheme registration we have today. </div><div class=""><br class=""></div><div class=""> — Justin<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 14, 2017, at 5:27 AM, rich levinson 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="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hi Iain, Justin, and Phil,<br class="">
<br class="">
Thanks for the replies.<br class="">
<br class="">
It seems that the issue boils down to the fact that under ordinary
circumstances,<br class="">
the user device would send the session cookie from the first login,
which would<br class="">
enable the OP to determine that the same user who is already logged
in is making<br class="">
a request from another app on the same device.<br class="">
<br class="">
However, ios-11, w its app silo does not send this cookie, so the OP
has no context,<br class="">
for knowing the user is already logged in.<br class="">
<br class="">
Based on looking @ the native app proposal:<br class="">
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12">https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12</a><br class="">
<br class="">
it appears possible that when a client app registers w the op, that
the "redirect-uri"<br class="">
could possibly designed such that all apps registered from a single
device could<br class="">
conceivably use a redirect-uri prefix that would identify those apps
as sharing<br class="">
a common device.<br class="">
<br class="">
If the registration also included info that the common device was a
"single-user device",<br class="">
such as a cell phone, then when the client-app sends the
authorization request,<br class="">
the op could check if there was already a session set up for that
device, inferring<br class="">
that that a 2nd req from a 2nd app from the same single-user device
could be associated<br class="">
w the same user that had established a session from the 1st req from
the 1st app of<br class="">
the same "single-user device".<br class="">
<br class="">
This would effectively be a scheme for replacing dependence on the
cookie,<br class="">
w dependence on the integrity of the redirect-uri's registered w
the op,<br class="">
which could also be double-checked w the client-id that the op
assigned to the app.<br class="">
<br class="">
Does that seem like a reasonable way to address the issue?<br class="">
<br class="">
Thanks,<br class="">
Rich<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 6/13/2017 5:57 PM, Iain McGinniss
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAL-ERL4LMm1x94nAqYuRhpD0QCAtGDO+qw2wRtvpG_XqVGJRfw@mail.gmail.com" class="">
<div dir="ltr" class="">Each SFSafariViewController (SFSVC) instance is
essentially a new browser, with the following consequences:
<div class=""><br class="">
</div>
<div class="">1. If the user signs in to the OP in Safari, this signed in
state is not visible from any SFSVC instance.</div>
<div class="">2. If the user signs in via an SFSVC, this signed in state
also cannot be synchronized to Safari.</div>
<div class=""><br class="">
</div>
<div class="">As a result, there's no shared OP session between any apps;
the user must re-authenticate with the OP within every app
that uses it.</div>
<div class=""><br class="">
</div>
<div class="">Furthermore, the <a href="https://webkit.org/blog/7675/intelligent-tracking-prevention/" moz-do-not-send="true" class="">Intelligent Tracking Prevention</a> <i class="">may</i> flag
the OP domain as a capable of tracking the user, at which
point any cookie / local storage state associated with that
domain is "redacted" if the user has not interacted with the
OP domain in the last 24 hours. "Interaction" here
specifically means loading a top-level page on that domain and
clicking on something. It seems highly likely that *.<a href="http://google.com/" moz-do-not-send="true" class="">google.com</a>
is going to be marked as a tracking domain in Safari.</div>
<div class=""><br class="">
</div>
<div class="">So, if you do anything in iframes with your OP domains (we
do at Google), your cookies are going to appear and disappear
in a very unpredictable way. Session state is going to become
very unreliable.</div>
<div class=""><br class="">
</div>
<div class="">I plan to give an impromptu short talk on these changes at
CIS.</div>
<div class=""><br class="">
</div>
<div class="">Iain</div>
<div class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Tue, Jun 13, 2017 at 2:40 PM,
rich levinson via Openid-specs-ab <span dir="ltr" class=""><<a href="mailto:openid-specs-ab@lists.openid.net" target="_blank" moz-do-not-send="true" class="">openid-specs-ab@lists.openid.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 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_-1077663280331052625moz-txt-link-freetext" href="http://openid.net/specs/openid-connect-session-1_0.html" target="_blank" moz-do-not-send="true">http://openid.net/specs/<wbr class="">openid-connect-session-1_0.<wbr class="">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<span class=""><br class="">
<br class="">
<br class="">
<br class="">
<br class="">
<div class="m_-1077663280331052625moz-cite-prefix">On
6/12/2017 8:04 PM, Nat Sakimura via
Openid-specs-ab wrote:<br class="">
</div>
</span>
<blockquote type="cite" class=""><span 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" moz-do-not-send="true" class="">oidf-account-chooser-list@<wbr class="">googlegroups.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" moz-do-not-send="true" class="">oidf-account-chooser-list+<wbr class="">unsubscribe@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" moz-do-not-send="true" class="">https://groups.google.com/d/<wbr class="">optout</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_-1077663280331052625mimeAttachmentHeader"></fieldset>
<br class="">
</span>
<pre class="">______________________________<wbr class="">_________________
Openid-specs-ab mailing list
<a class="m_-1077663280331052625moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank" moz-do-not-send="true">Openid-specs-ab@lists.openid.<wbr class="">net</a>
<a class="m_-1077663280331052625moz-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" moz-do-not-send="true">https://urldefense.proofpoint.<wbr class="">com/v2/url?u=http-3A__lists.<wbr class="">openid.net_mailman_listinfo_<wbr class="">openid-2Dspecs-2Dab&d=DwICAg&<wbr class="">c=<wbr class="">RoP1YumCXCgaWHvlZYR8PQcxBKCX5Y<wbr class="">TpkKY057SbK10&r=<wbr class="">nNxUKneeZofWTyt9qclOUTeEg29NkE<wbr class="">kknFyDupoNiiA&m=<wbr class="">z6H6MqLIToKnju5TQdKnYOa6pGD9ly<wbr class="">MxhwLO-mdMgac&s=<wbr class="">tYftjD7QNKeiH9oZIyspoUu_<wbr class="">QX44iHnFoAzyiuQapmg&e=</a>
</pre>
</blockquote>
<br class="">
</div>
<br class="">
______________________________<wbr class="">_________________<br class="">
Openid-specs-ab mailing list<br class="">
<a href="mailto:Openid-specs-ab@lists.openid.net" moz-do-not-send="true" class="">Openid-specs-ab@lists.openid.<wbr class="">net</a><br class="">
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank" moz-do-not-send="true" class="">http://lists.openid.net/<wbr class="">mailman/listinfo/openid-specs-<wbr class="">ab</a><br class="">
<br class="">
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
<br class="">
</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></div></body></html>