<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body 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 href="mailto:paul.madsen@gmail.com">paul.madsen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<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 href="mailto:Openid-specs-native-apps@lists.openid.net">Openid-specs-native-apps@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-native-apps<br></blockquote></div><br></div></body></html>