<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>I agree with your assessment. We are getting there :-)</div>
<div><br>
</div>
<div>Besides passing a target URI as part of the request to the TA, I think TA needs to pass this target URI to AS as well. This URI is needed by AS to do authorization check.</div>
<div><br>
</div>
<div>In the request that TA sends to AS, we should add customURL and bundle_id for AS to do validation check. This is to cover the situation where TA will not call AppInfo endpoint to obtain all apps or the result is not updated soon enough.</div>
<div><br>
</div>
<div>In the current working draft, do you assume the access token can be reused or it is a one time token? If used as authorization header, it would use Bearer header? What is the name if we use HTTP parameter? I feel that this token is a little different from
the traditional access token. The way we pass it in should be made different so IdP could separate them apart.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Emily</div>
<div><br>
</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>Thursday, July 10, 2014 9:26 AM<br>
<span style="font-weight:bold">To: </span>Emily Xu <<a href="mailto:exu@vmware.com">exu@vmware.com</a>><br>
<span style="font-weight:bold">Cc: </span>Paul Madsen <<a href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.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>>,
Ashish Jain <<a href="mailto:ashishjain@vmware.com">ashishjain@vmware.com</a>>, Dale Olds <<a href="mailto:olds@vmware.com">olds@vmware.com</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;">
What you are describing is a native app that invokes a web view.
<div><br>
</div>
<div>I think it is consistent with what I have added.</div>
<div><br>
</div>
<div>You have some additional details in your description. </div>
<div>I would say the way the web part of the app is loaded and determining if there is a session is part of the app and implementation specific. </div>
<div>What you have is a reasonable way to do it, but there may be other ways depending on the design of the web app. </div>
<div><br>
</div>
<div>Once the native app decides it needs a a session passing the request to the TA and getting the access token and base URI back is what I was thinking. </div>
<div>The binding spec needs to be changed to pass a target URI as part of the request to the TA (assuming that an app could have multiple targets, and the response needs to include the base </div>
<div>init_sso URI as well as the token. That still needs to be added.</div>
<div><br>
</div>
<div>The native app is allowed to pass the access token on a query parameter, though that is not recommended for security reasons. If the web view is using Java scrypt then sending it as a POSt or header should be no big deal. That is how node.js and other
apps make OAuth calls now. Some thought needs to be put in to cross domain communications, but that can be dealt with by the web app.</div>
<div><br>
</div>
<div>So I think we are largely agreeing.</div>
<div><br>
</div>
<div>John B.</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>On Jul 10, 2014, at 12:04 PM, Emily Xu <<a href="mailto:exu@vmware.com">exu@vmware.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; 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 (<a href="https://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=c8ee1932111e024a0e0aabeb5aba6130dd1b1f4d17a116f8f0714d5c9e595e47">https://idp.com/launch/webapp1</a>)</li><li>A web view is opened by a client app, and redirect the browser to <a href="https://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=c8ee1932111e024a0e0aabeb5aba6130dd1b1f4d17a116f8f0714d5c9e595e47">
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://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=c8ee1932111e024a0e0aabeb5aba6130dd1b1f4d17a116f8f0714d5c9e595e47">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://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=c8ee1932111e024a0e0aabeb5aba6130dd1b1f4d17a116f8f0714d5c9e595e47">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://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1?ota%3Dsomething&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=5eb3f298c6d4397a8adca3c04fd7cf8723b7a645f7658a77905ff836e60aed0d">
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://urldefense.proofpoint.com/v1/url?u=https://idp.com/launch/webapp1?ota%3Dsomething&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2BncOwzCBhNISAoJVtNvVMw%3D%3D%0A&m=agKgD7co4a8lmQY3QN4op%2FnmQ38zX6pvOR%2FZvLZnnRU%3D%0A&s=5eb3f298c6d4397a8adca3c04fd7cf8723b7a645f7658a77905ff836e60aed0d">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; 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 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></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</span>
</body>
</html>