<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi John,<br>
<br>
I admit I do not know every detail and nuance associated w
OAuth/OIDC.<br>
Therefore, I will try to clearly state my assumptions, and will be
more than<br>
happy to be corrected if they are wrong.<br>
<ol>
<li>I assume each application on a mobile device has a unique
client-id<br>
associated w a specific az-svr. (based on 2 below)<br>
</li>
<li>I assume each application on a mobile device has a unique
redirect-uri,<br>
which enables it to receive authorization responses from the
az-svr.<br>
If this was not the case then how else could the app rcv the
responses.</li>
<li>Therefore, when a client app is registered on the az-svr,
dynamically,<br>
or otherwise, the az-svr has a unique pair: [client-id,
redirect-uri]<br>
associated w each client app that can access the az-svr from a
specifi<br>
mobile device.</li>
</ol>
<p>Now, if multiple apps from a single device are registered w the
az-svr,<br>
then, initially, at least, this set of apps are neither associated
w the same<br>
device, nor associated w any end-user. They are simply a set of
unique<br>
client-id,redirect-uri pairs among a huge set of all other pairs
from all<br>
other apps on all other devices registered w the az-svr.</p>
<p>So, when an az-req is made from a client app on the device to the
az-svr,<br>
this is the first time the app becomes associated w an end-user,
which<br>
happens when the end-user logs in and the az-svr authorizes the
end-user<br>
to use the client-app, as well as authorizing the client-app to
perform<br>
operations on behalf of the end-user, as specified in the scope of
the<br>
az-req.</p>
<p>At this point, the az-svr can record a triple:
[user-id,client-id-1,redirect-uri-1]<br>
which associates the end-user w the client-app.</p>
<p>Similarly, if a 2nd app from the same device is used for the
first time w<br>
the same az-svr, then a 2nd triple can be established:<br>
[user-id,client-id-2,redirect-uri-2]<br>
which can now be relate the end-user to both client-id-1 and
client-id-2.</p>
<p>What is still unknown @ the az-svr is whether client-id-1 and
client-id-2<br>
are associated w the same device.</p>
<p>I have not found any obvious way to do this using the existing
protocol<br>
messages, but it seems to me that if it is in the end-user's
interest to tie<br>
these apps together for the purposes of SSO, then it should be
fairly<br>
straight-forward matter to enable the user to establish these ties<br>
during the consent phase, whereby the user might enter some kind<br>
of personal device-id to associate w the app that the user is
giving consent to.</p>
<p>This would enable all the knowledge necessary to establish SSO on
the<br>
az-svr, w/o having to rely on cooperation from the device OS,
which<br>
apparently is being designed to prevent this from easily happening
w/o<br>
the user's knowledge.</p>
<p>This scheme, however, could be implemented w the user's knowledge
and<br>
consent, and should be able to enable other features as well if
desired.</p>
<p>Comments?</p>
<p> Thanks,<br>
Rich</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 6/14/2017 2:35 PM, John Bradley
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C966E134-8A8C-44CE-9E9E-FC5D4EBE572F@ve7jtb.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Er..
<div class=""><br class="">
</div>
<div class="">No you are just pushing the problem around. How
would the AS know that all the apps are from the same device
when doing dynamic client registration.</div>
<div class=""><br class="">
</div>
<div class="">Any app learning the redirect_uri for a device could
then move that to a different device and use it to login as the
user.</div>
<div class=""><br class="">
</div>
<div class="">I don’t think this would work.</div>
<div class=""><br class="">
</div>
<div class="">John B.</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jun 14, 2017, at 4: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="">
<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"
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://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=""
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>
</blockquote>
<br>
</body>
</html>