<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi George,</p>
<p>Thanks for passing your web session bootstrap draft. It proves
this was in need of a solution 10 years ago and still is :)</p>
<p>Let me know if I got this correct about the web session
bootstrapping:</p>
<ul>
<li>The client passing the bootstrap-token to the web session
endpoint at the AS establishes a session (cookie) for the token
subject (the user), without any user interaction.<br>
<br>
</li>
<li>The AS then redirects the brower to dest_url, i.e. the web app<br>
<br>
</li>
<li>The web app would then make an authZ request to the AS, but
because we'll now have an AS session for the user, the login
prompt will be skipped and the client web app will be able to
get its tokens without further user interaction (okay, assuming
explicit consent).</li>
</ul>
<p><br>
</p>
<p>Coming back to the native SSO flow, I was thinking that the
device_secret could be used to link device related context, i.e. a
browser fingerprint. So when the handover token is generated, this
context will serve the OP later in the browser based flow to check
that the device wasn't changed.</p>
<p>But there are issues with the browser fingerprinting:</p>
<ul>
<li>If the original authZ request to get the device_secret is far
in the past, the user may have updated their browser or browser
settings, or even switched to a different one, which will break
the fingerprint comparison at the OP. Depending on how this is
seen, it may be a sought effect.<br>
<br>
</li>
<li>Browser fingerprinting has issues on its own, being bad for
privacy it may not be such a good idea using it, and I suppose
browsers will eventually seek to suppress it.<br>
</li>
</ul>
<p><br>
</p>
<p>One crude way to bind the browser session to the device is to
record the client's IP address in the issued handover token. When
the token gets consumed at the OP the browser IP address will be
checked against the one in the token. Presuming the two events are
close in time, it should be unlikely that the device's IP address
changes between the token issue and its use. So this might work as
a sort of check. BTW, the session bootstrapping token could use
the same technique.</p>
<p>I'm wondering what else can be done. The native SSO spec builds
on the premise that the flow cannot rely on browser cookies or
other state, correct?</p>
<p><br>
</p>
<p>Regarding the device_secret URN, the token exchange has examples
how to register them in a spec:</p>
<p><a class="moz-txt-link-freetext"
href="https://www.rfc-editor.org/rfc/rfc8693#name-oauth-uri-registration"
moz-do-not-send="true">https://www.rfc-editor.org/rfc/rfc8693#name-oauth-uri-registration</a></p>
<p>With servers which have the x-oath URN the new std URN could be
added as an alias, so that both new and old clients would work.<br>
</p>
<p><br>
</p>
<p>Vladimir<br>
</p>
<pre class="moz-signature" cols="72">Vladimir Dzhuvinov</pre>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 17/01/2023 18:19, George Fletcher
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJnLd9KzMMpjqqF-bo+=KG1D9B_7tQWHJSTXpN_LZ2AkAGrTzg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi Vladimir,<input name="virtru-metadata"
type="hidden"
value="{"email-policy":{"disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"expandedWatermarking":false,"expires":false,"sms":false,"expirationNum":1,"expirationUnit":"days","isManaged":false,"persistentProtection":false},"attachments":{},"compose-id":"12","compose-window":{"secure":false}}">
<div><br>
</div>
<div>This is great news regarding the implementation.</div>
<div><br>
</div>
<div>Regarding the URN... I styled them after the URNs in the
OAuth Token Exchange spec and yes, not registering an
official one or using the ietf OAuth params in an oversight.
It should be
`urn:ietf:params:oauth:token-type:device_secret` and I will
need to work with Mike on how that should get changed and
what it might mean to existing implementations.</div>
<div><br>
</div>
<div>I agree that authentication from a mobile app to web app
is a common transition and another space for which there is
little specification. I wrote a draft for this back in 2013
I believe:) The biggest issue is that if not using a
WebView, there is no way to ensure the web request is coming
from the same device where the mobile app is running. All
parameters must be present on the URL and so it's possible
for an attacker to start the flow on one device and the URL
with all required parameters to another device for
completion.</div>
<div><br>
</div>
<div>That said, I'm definitely open to options for how we
might specify a safe way to perform this step seamlessly.
I'm attaching the old draft (v2 though I believe I did an v3
version but don't seem to have access to it anymore).</div>
<div><br>
</div>
<div>Thanks,</div>
<div>George</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote" style="">
<div dir="ltr" class="gmail_attr">On Tue, Jan 17, 2023 at 5:32
AM Vladimir Dzhuvinov <<a
href="mailto:vladimir@connect2id.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">vladimir@connect2id.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi George,<br>
</p>
<p>After voting for the implementer's draft of the native
SSO we now consider adding it in the open source Nimbus
OIDC Java SDK we maintain.</p>
<p>We noticed the actor_token_type uses an x-oath URN
instead of the common format of other registered token
type URIs. I'm not sure if that was a missed artifact
from an early spec or implementation, or is intentional:<br>
</p>
<p>"urn:x-oath:params:oauth:token-type:device-secret"</p>
<p><a
href="https://openid.net/specs/openid-connect-native-sso-1_0-04.html#section-4.1"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://openid.net/specs/openid-connect-native-sso-1_0-04.html#section-4.1</a><br>
</p>
<p><a
href="https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri</a></p>
<p><br>
</p>
<p>Some people who read the draft have faced the problem
of integrating mobile and web SSO into one seamless UX.
Say a user who is logged into a mobile app performs an
action that opens a web page belonging to the app
vendor. This will typically trigger a new OpenID auth
request, and that is perceived as super bad and
illogical UX. Handover between mobile and web app
appears to be fairly common. Often it doesn't require
the user to be authenticated at the target web page, but
occasionally it does.</p>
<p>So, the idea why not adapt the native SSO flow, roughly
as it is, to handle signing into a web app.</p>
<p>Here is one flow that is currently being considered:</p>
<ul>
<li>It requires the native client to know the client_id
of the web app.<br>
<br>
</li>
<li>It requires the web app to be a confidential client.<br>
<br>
</li>
<li>The native client makes a token exchange request,
stating the client_id of the target web app in the
"audience" parameter (this is not semantically
correct, because the web app is not the ultimate
consumer of the issued token) and the
"requested_token_type" to indicate a new "handover"
token. The native clients sends the ID token and
device secret used in the native SSO token exchange.<br>
<br>
</li>
<li>The returned handover token will be encrypted by the
OP to self (or will be a random string key pointing a
DB record at the OP), and carry the end-user ID, her
auth context (if any), and the client_id of the target
web app.<br>
<br>
</li>
<li>The native app will open a web app link in the
system browser, passing the handover token.<br>
<br>
</li>
<li>The web app will make a new _authenticated_ token
exchange request, using the handover token to obtain
an ID token and potentially access and refresh token.
The OP will not release the requested tokens to the
web app unless the client_id in the validated handover
token matches the authenticated client (the web app).<br>
<br>
Another variant, if the web app doesn't support token
exchange, is to pass the handover token in a
login_hint of a standard prompt=none OpenID
authentication request, and continue from there as
normal. The handover token client_id will be checked
when the client authenticates at the token endpoint.
This variant could also work for web apps that are
public clients (SPAs).<br>
</li>
</ul>
<p><br>
</p>
<p>We are quite keen to support a flow that builds upon
the proposed native SSO to link associated web apps. I
wonder if you already considered something like this.
And your general thoughts on using the native SSO flow
to also cover web apps vs alternatives.</p>
<p><br>
</p>
<p>Vladimir<br>
</p>
<pre cols="72">--
Vladimir Dzhuvinov</pre>
</div>
</blockquote>
</div>
</div>
<hr><br>
<br>
<font color="#404040">The information contained in this e-mail is
confidential and/or proprietary to Capital One and/or its
affiliates and may only be used solely in performance of work or
services for Capital One. The information transmitted herewith
is intended only for use by the individual or entity to which it
is addressed. If the reader of this message is not the intended
recipient, you are hereby notified that any review,
retransmission, dissemination, distribution, copying or other
use of, or taking of any action in reliance upon this
information is strictly prohibited. If you have received this
communication in error, please contact the sender and delete the
material from your computer.</font><br>
<br>
<table width="100%" height="30" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
</tr>
</tbody>
</table>
<br>
</blockquote>
</body>
</html>