<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hi John,</div>
<div><br>
</div>
<div>Thank you for updating draft with web init sso flow. In the working draft, TA or client app needs to add "access_token" to authorization header or as HTTP form post parameter.</div>
<div><br>
</div>
<div>Is it possible for us to short circuit this step to simplify the work needed by TA, client app, and IdP? What about this hybrid flow?</div>
<ol>
<li>User click on a web clip installed on his device (https://idp.com/launch/webapp1)</li><li>A web view is opened by a client app, and redirect the browser to <a href="https://idp.com/launch/webapp1">
https://idp.com/launch/webapp1</a></li><li>IdP received the request and sees no user session. IdP returns 401</li><li>Client app processes 401, then sends a request to TA for web init url: scope=clientapp urn:oauth:web-sso&web<span style="font-style: italic; ">init</span>uri=<a href="https://idp.com/launch/webapp1">https://idp.com/launch/webapp1</a></li><li>TA sends request to AS: refresh_token=primary<span style="font-style: italic; ">refresh</span>token&scope=clientapp urn:oauth:web-sso&web<span style="font-style: italic; ">init</span>uri=<a href="https://idp.com/launch/webapp1">https://idp.com/launch/webapp1</a></li><li>AS validates client app and issue one time access token and append it to webinituri
<a href="https://idp.com/launch/webapp1?ota=something">https://idp.com/launch/webapp1?ota=something</a></li><li>TA pass the webinituri+ota token to client app's customUrl</li><li>Client app redirects the browser to <a href="https://idp.com/launch/webapp1?ota=something">https://idp.com/launch/webapp1?ota=something</a></li><li>IdP receives the request, process the one time token, set IdP session cookie, generates SAML response and post it to webapp1</li></ol>
<div>Since AS knows how IdP accept this SSO token, the token can be added by AS directly. This approach would simplify TA or client app quite a bit. Since one time token is used, this is relatively secure. </div>
<div><br>
</div>
<div>What do you think about this flow?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Emily</div>
<span id="OLK_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>John Bradley <<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, July 9, 2014 7:17 AM<br>
<span style="font-weight:bold">To: </span>Paul Madsen <<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>Emily Xu <<a href="mailto:exu@vmware.com">exu@vmware.com</a>>, "<a href="mailto:openid-specs-native-apps@lists.openid.net">openid-specs-native-apps@lists.openid.net</a>" <<a href="mailto:openid-specs-native-apps@lists.openid.net">openid-specs-native-apps@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-native-apps] Asymmetry between native & web apps?<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
OK I will do a draft with it being a OAuth protected IdP hosted sso_init endpoint to look at for the call today.
<div><br>
</div>
<div>I agree it is better but more prescriptive on the IdP.</div>
<div><br>
</div>
<div>John B.<br>
<div>
<div>On Jul 8, 2014, at 1:36 PM, Paul Madsen <<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div text="#000000" bgcolor="#FFFFFF"><font size="+1"><font face="Arial">is not the question *how* the TA asks for a fresh web_init_url?<br>
<br>
1) by using its access token against the AppInfo endpoint<br>
2) by using its refresh token against the token endpoint<br>
<br>
#1 seems wasteful, as the AS would generate new web_init_url's for all web apps, not just the one in question<br>
<br>
paul<br>
<br>
</font></font>
<div class="moz-cite-prefix">On 7/8/14, 9:47 AM, Emily Xu wrote:<br>
</div>
<blockquote cite="mid:CFE00469.55330%25exu@vmware.com" type="cite">
<div style="font-family: Calibri, sans-serif; font-size: 14px;">Is it possible to do a hybrid approach?</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<div><font face="Calibri,sans-serif">The web_</font><span style="font-family: Calibri, sans-serif; font-size: 14px; font-style: italic; ">init_</span><span style="font-family: Calibri, sans-serif; font-size: 14px; font-style: italic; ">sso URI
</span><span style="font-family: Calibri, sans-serif; font-size: 14px; ">returned from </span><font face="Calibri,sans-serif">app_info endpoint contains short lived session at the IdP. Since this uri contains short lived session token, a new URI needs to be
generated again later when the session is expired.</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">We should also provide a way for a client app to request a new web_<span style="font-style:
italic; ">init_</span>sso URI with a fresh one time use token. For example, a client app could request a new web_init
_sso URI from AS through TA:</font></div>
<div><font face="Calibri,sans-serif"><br>
</font></div>
<div><font face="Calibri,sans-serif">C</font><font face="Calibri,sans-serif">lient app -> TA: scope=clientApp1&web<span style="font-style: italic; ">init</span>uri=<WebApplaunchUri>&customUrl=<clientapp1CustomUrl>&bundleId=<clientApp1Bundleid></font></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">TA->AS: scope=clientApp1&web<span style="font-style:
italic; ">init</span>uri=<WebApplaunchUri>&customUrl=<clientapp1CustomUrl>&bundleId=<clientApp1Bundleid></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">AS: validates client App1, and generate onetime token</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">AS->TA: webiniturl=<WebAppLaunchUri?onetimetoken=jdfkdjkfdj>&customUrl=<clientapp1CustomUrl></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">TA->client app's customUrl: webiniturl=<WebAppLaunchUri?onetimetoken=jdfkdjkfdj></div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">Client app1: launch web app using the url with onetime token</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">IdP will generate session token using the one time token.</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">By using this approach, it is more secure since only the one time token is added as uri parameter. A client app could use this approach to launch web app using NAPPS session instead of asking IdP
to authenticate user again.</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">Thanks,</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;">Emily</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;"><br>
</div>
<span id="OLK_SRC_BODY_SECTION" style="font-family: Calibri, sans-serif; font-size: 14px; ">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style="font-weight:bold">From: </span>John Bradley <<a moz-do-not-send="true" href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>><br>
<span style="font-weight:bold">Date: </span>Monday, July 7, 2014 5:57 AM<br>
<span style="font-weight:bold">To: </span>Paul Madsen <<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a moz-do-not-send="true" href="mailto:openid-specs-native-apps@lists.openid.net">openid-specs-native-apps@lists.openid.net</a>" <<a moz-do-not-send="true" href="mailto:openid-specs-native-apps@lists.openid.net">openid-specs-native-apps@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-native-apps] Asymmetry between native & web apps?<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;">
The app_info endpoint needs to generate fresh web_init_sso URI each time it is called. I expect that they have limited lifetimes at the IdP.
<div><br>
</div>
<div>I am assuming that these are short lived URI to call an endpoint at the IdP that will establish a session and do IdP intit SSO from there. </div>
<div>If that session expires the client/SP/RP will send the user back to the IdP and the IdP would deal with it as a normal flow. </div>
<div>I suppose it could somehow the user back to the TA and start again with a new web_init_sso uri but that seems more complicated that it is worth.</div>
<div><br>
</div>
<div>The problem with making them symmetrical is that one is a URI and the other is a token.</div>
<div><br>
</div>
<div>To do that we would need to define a web_init_sso_base_uri that is delivered in discovery or from the app_info response. </div>
<div>Then we would get a access token for web sso from the token endpoint and invoke a browser to call the endpoint with the access token to start the IdP init SSO.</div>
<div><br>
</div>
<div>That would remove the need to generate fresh URI from the app_info endpoint and be more secure as we would not be passing the secret value in a query parameter.</div>
<div><br>
</div>
<div>On the other hand having a single uri to pass to the browser is going to be simpler for most implementers, and most start_sso endpoints are not OAuth protected.</div>
<div><br>
</div>
<div>So there are plusses and minuses to using a access token for both.</div>
<div><br>
</div>
<div>John B</div>
<div><br>
</div>
<div><br>
<div>
<div>On Jul 7, 2014, at 8:19 AM, Paul Madsen <<a moz-do-not-send="true" href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"><font size="+1"><font face="Arial">The current model is that the TA uses its refresh token to obtain access tokens for native apps, but obtains the web_init_sso URL for a web application in the AppInfo returned JSON<br>
<br>
Is there value in making the model symmetrical for the two application types, ie the TA uses its refresh token to obtain a web_init_sso 'token'<br>
<br>
Without this sort of explicit request to enable web apps, what would the TA do when the web session expired?<br>
<br>
paul<br>
</font></font></div>
_______________________________________________<br>
Openid-specs-native-apps mailing list<br>
<a moz-do-not-send="true" href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>
<a moz-do-not-send="true" href="https://urldefense.proofpoint.com/v1/url?u=http://lists.openid.net/mailman/listinfo/openid-specs-native-apps&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=R6O1w3X3Nn9BCk0KoIS9VWb9KuFPS%2FGilBQ7QJc0YYI%3D%0A&s=cbdf71cec0cbeb8a05e05f0ae574af5091047eccb8c17c1f25ef8bdf99ffe712">http://lists.openid.net/mailman/listinfo/openid-specs-native-apps</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span></blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>