<div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap">I demonstrated a way to be sure that a native app and web app were on the same machine using localhost over 2 years ago. YouTube link below. What I have not been able to do is create an e-e secure link between them on the same device. That would not be too hard for browser guys to do; but they have no incentive.</span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"><br></span></div><div><a href="https://www.youtube.com/watch?v=Tq4hw7X5SW0">https://www.youtube.com/watch?v=Tq4hw7X5SW0</a><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"><br></span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"><br></span></div><div><span style="background-color:rgb(242,242,242);color:rgba(0,0,0,0.9);font-family:-apple-system,system-ui,system-ui,"Segoe UI",Roboto,"Helvetica Neue","Fira Sans",Ubuntu,Oxygen,"Oxygen Sans",Cantarell,"Droid Sans","Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Lucida Grande",Helvetica,Arial,sans-serif;font-size:14px;white-space:pre-wrap"> </span>..tom</div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 17, 2023 at 8:19 AM George Fletcher via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</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 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"><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">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">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">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><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><table border="0" cellspacing="0" cellpadding="0" width="100%" height="30"><tbody><tr><td><br>
</td></tr><tr>
</tr><tr><td><br>
<br>
</td></tr></tbody></table><br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="https://lists.openid.net/mailman/listinfo/openid-specs-ab" rel="noreferrer" target="_blank">https://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div>