<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<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 class="moz-txt-link-freetext"
href="https://openid.net/specs/openid-connect-native-sso-1_0-04.html#section-4.1"
moz-do-not-send="true">https://openid.net/specs/openid-connect-native-sso-1_0-04.html#section-4.1</a><br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#uri"
moz-do-not-send="true">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 class="moz-signature" cols="72">--
Vladimir Dzhuvinov</pre>
</body>
</html>