<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Justin,<br>
<br>
Based on your response, I am not sure whether it is addressing the
actual suggestion<br>
that I made.<br>
<ol>
<li>The suggestion recommended that each app register w common
redirect-uri "prefix".<br>
i.e. the suffix would likely include a unique identifier for
the app within that prefix,<br>
so each app would have a "unique callback URI".</li>
<li>The scheme is driven on the end-user side, by the end-user
desiring to have SSO<br>
on the user's device. Therefore, when registering each app,
which presumably is<br>
triggered by the end-user, who is loading the app on their
device, all that needs<br>
to be done is have the device provide its proposed redirect-uri
prefix to the app<br>
during registration, along w a flag indicating the intent is
that this app is to be<br>
part of the SSO collection for the single-user device, plus the
app, itself, providing<br>
the suffix that disambiguates it from other apps using the same
prefix on the same<br>
device.</li>
<li>The scheme is driven on the az-svr/OP side by the assignment
of the unique client-id<br>
to the app, resulting in a unique redirect-uri + client-id pair
for the registered app.</li>
<li>Therefore, an intruder would need to know a.) the unique
redirect-uri, <br>
b.) the unique client-id, and c.) the fact that the end-user
has an active OP login state,<br>
in order to impersonate the app.<br>
The security of this combo would need to be compared to the
security of a cookie,<br>
which is a bearer token, which could also be used by an
intruder in the current<br>
scheme of things.</li>
</ol>
<p>Bottom line, I think my suggestion might provide an
easy-to-implement, easy-to-use,<br>
and relatively equivalent level of security to the current schemes
which are based<br>
on cookies.</p>
<p>Also, a relatively small change to the az-svr impl could combine
the "single-user device flag"<br>
w the registered redirect-uri to determine if an az-svr/OP
session already exists for<br>
a client w the common redirect-uri prefix.</p>
<p>Note also, this suggestion is only intended to address the SSO
issue, not the inter-app<br>
communication issue, which I think, in general, is separable and
premature to discuss<br>
until a soln is found for SSO.</p>
<p>Also, Apple may be convinced to allow the cookies, in which case
my suggestion is not needed,<br>
but could be considered as a fallback strategy for SSO if Apple
does not allow the cookies.<br>
</p>
<p> Thanks,<br>
Rich</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/14/2017 7:50 AM, Justin Richer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6B69B50E-4219-444B-B681-611CFCFB4998@mit.edu">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="" moz-do-not-send="true">openid-specs-ab@lists.openid.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Dnative-2Dapps-2D12&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=7CDpxUxVoeNQ7vGTbkwCgVZTExe_bgoey_zSEftia-U&e="
moz-do-not-send="true">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://urldefense.proofpoint.com/v2/url?u=https-3A__webkit.org_blog_7675_intelligent-2Dtracking-2Dprevention_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=SckFDrWm-pr4jO3aKXTNcLF9cFESHwKEi6xmYh4cbZs&e="
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="https://urldefense.proofpoint.com/v2/url?u=http-3A__google.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=fDWs3bFW2PpXshC3tcUA9HkqFp4Rpo6okQ8dZuJWQ9k&e="
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="https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dsession-2D1-5F0.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=esCBAjLi0rE6cyxpEdt-kd2c61ezIJP_8v1euB48-kk&e="
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="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=AdULqkg4OrLa18bnS9NfGgUMspZprPqSxSYwMR9bX04&e="
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="" moz-do-not-send="true">Openid-specs-ab@lists.openid.net</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
<br>
</body>
</html>