<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Sounds a bit like the original
"Native Apps" OIDF working group flow:)</font><br>
<br>
<div class="moz-cite-prefix">On 6/14/17 3:01 PM, Chuck Mortimore
wrote:<br>
</div>
<blockquote
cite="mid:CA+wnMn-=zakyyDcP_jW9RgX7H6wddbjeCDbyEac++w7pkCJkPA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi Chris
<div><br>
</div>
<div>In current state, we have an option to switch to mobile
safari on a per-customer basis. When our apps boot, if
configured with a tenant specific URL, they load metadata from
a .well-known endpoint which controls this behavior. PKCE is
used to secure callbacks over custom scheme URIs.</div>
<div><br>
</div>
<div>We're currently working on adding the ability to specify a
custom scheme to act as the IDP, as well as specific software
in our mobile SDKs to deal with the handleOpenURL calls.
Essentially an SP app reads metadata, switches to IDP app,
which uses it's session to initiate the OAuth flow for the SP
app. Once approved a custom scheme redirect_uri switches back
to the SP app which completes the OAuth flow (PKCE verified)
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jun 14, 2017 at 11:10 AM, Chris
Phillips <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:Chris.Phillips@canarie.ca" target="_blank">Chris.Phillips@canarie.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div
style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi Chuck,</div>
<div>Yes, please share. Definitely interested in
understanding the approach particularly the scaling
aspects of the technique.</div>
<div>As an operator of a national federation that
participates worldwide with thousands of IdPs[1] it's
helpful to understand how portable the approach is.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>C</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://technical.edugain.org/status"
target="_blank">https://technical.edugain.<wbr>org/status</a> </div>
<div><br>
</div>
<span id="m_-1874132751077751495OLK_SRC_BODY_SECTION">
<div
style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium
none;BORDER-LEFT:medium
none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df
1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt"><span
style="font-weight:bold">From: </span>
Openid-specs-ab <<a moz-do-not-send="true"
href="mailto:openid-specs-ab-bounces@lists.openid.net"
target="_blank">openid-specs-ab-bounces@<wbr>lists.openid.net</a>>
on behalf of Chuck Mortimore via Openid-specs-ab <<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>><br>
<span style="font-weight:bold">Reply-To: </span>
Chuck Mortimore <<a moz-do-not-send="true"
href="mailto:cmortimore@salesforce.com"
target="_blank">cmortimore@salesforce.com</a>><br>
<span style="font-weight:bold">Date: </span>
Wednesday, June 14, 2017 at 1:40 PM<br>
<span style="font-weight:bold">To: </span> George
Fletcher <<a moz-do-not-send="true"
href="mailto:gffletch@aol.com" target="_blank">gffletch@aol.com</a>><br>
<span style="font-weight:bold">Cc: </span> "<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>
Ab" <<a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>><br>
<span style="font-weight:bold">Subject: </span> Re:
[Openid-specs-ab] Single Sign-On is dead on iOS 11<br>
</div>
<div><br>
</div>
<div>
<div>
<div>
<div class="h5">
<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>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div class="h5">On Wed, Jun 14, 2017 at 8:09
AM, George Fletcher via Openid-specs-ab
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>
<div class="h5"><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>
<div>
<div class="m_-1874132751077751495h5">
<div>
<div class="h5"><br>
<div
class="m_-1874132751077751495m_8510855096493843124moz-cite-prefix">On
6/13/17 5:57 PM, Justin Richer via
Openid-specs-ab wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">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>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>
<div class="h5">
<div>On Jun 13, 2017, at
5:40 PM, rich levinson via
Openid-specs-ab <<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid.net"
target="_blank">openid-specs-ab@lists.openid.<wbr>net</a>>
wrote:</div>
<br
class="m_-1874132751077751495m_8510855096493843124Apple-interchange-newline">
</div>
</div>
<div>
<div text="#000000"
bgcolor="#FFFFFF">
<div>
<div class="h5">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
moz-do-not-send="true"
class="m_-1874132751077751495m_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_-1874132751077751495m_8510855096493843124moz-cite-prefix">On
6/12/2017 8:04 PM, Nat
Sakimura via
Openid-specs-ab wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div class="h5">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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_-1874132751077751495m_8510855096493843124mimeAttachmentHeader"></fieldset>
<br>
</div>
</div>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="m_-1874132751077751495m_8510855096493843124moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><a moz-do-not-send="true" class="m_-1874132751077751495m_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.<wbr>proofpoint.com/v2/url?u=http-<wbr>3A__lists.openid.net_mailman_<wbr>listinfo_openid-2Dspecs-2Dab&<wbr>d=DwICAg&c=RoP1YumCXCgaWHvlZYR<wbr>8PQcxBKCX5YTpkKY057SbK10&r=nNx<wbr>UKneeZofWTyt9qclOUTeEg29NkEkkn<wbr>FyDupoNiiA&m=z6H6MqLIToKnju5TQ<wbr>dKnYOa6pGD9lyMxhwLO-mdMgac&s=t<wbr>YftjD7QNKeiH9oZIyspoUu_QX44iHn<wbr>FoAzyiuQapmg&e=</a>
</pre></blockquote>
</div><span class="">
______________________________<wbr>_________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a moz-do-not-send="true" class="m_-1874132751077751495m_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>
</span></div></blockquote></div>
</div>
<fieldset class="m_-1874132751077751495m_8510855096493843124mimeAttachmentHeader"></fieldset>
<pre>______________________________<wbr>_________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" class="m_-1874132751077751495m_8510855096493843124moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a><a moz-do-not-send="true" class="m_-1874132751077751495m_8510855096493843124moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mail<wbr>man/listinfo/openid-specs-ab</a></pre></blockquote>
</div></div></div><span class="">
______________________________<wbr>_________________
Openid-specs-ab mailing list
<a moz-do-not-send="true" href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.n<wbr>et</a>
<a moz-do-not-send="true" 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>
</span></blockquote></div>
</div></div></div></span></div>
</blockquote></div>
</div>
</blockquote>
</body></html>