<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;">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">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <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">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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="http://lists.openid.net/mailman/listinfo/openid-specs-native-apps">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></body></html>