<div dir="ltr">Thanks Justin. </div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/20 Justin Richer <span dir="ltr"><<a href="mailto:jricher@mitre.org" target="_blank">jricher@mitre.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Instead of burdening us with more defined terms that are used only
    once here, I would concur that we ought to do a direct word
    replacement like Nat suggests below. So the text in 16.4 Offline
    Access would become:<br>
    <br>
    <br>
    <br>
    <blockquote>
      <p> When an Access Token is returned <b>via the user agent using
          the implicit or hybrid flow</b>, there is a greater risk of it
        being exposed to an attacker, who could later use it to access
        the UserInfo endpoint. If the Access Token does not enable
        offline access and the server can differentiate whether the
        Client request has been made offline or online, the risk will be
        substantially reduced. Therefore, this specification mandates
        ignoring the offline access request when the Access Token is
        transmitted <b>through the user agent</b><b></b>. Note that
        differentiating between online and offline access from the
        server can be difficult, especially for native clients. The
        server may well have to rely on heuristics. Also, the risk of
        exposure for the Access Token delivered <b>through the user
          agent</b> for the response types of <tt>code token</tt> and <tt>token</tt>
        is the same. Thus, the implementations should be prepared to
        detect <b>whether the Access Token was issued through the user
          agent or directly through from the Token Endpoint</b> and deny
        offline access if the token was issued <b>through the user
          agent</b>. </p>
      <br>
    </blockquote>
     -- Justin<div class="im"><br>
    <br>
    <div>On 11/20/2013 02:53 AM, n-sakimura
      wrote:<br>
    </div>
    </div><blockquote type="cite"><div class="im">
      
      <div>I suppose it was taken from SP800-63
        or so. <br>
        Anyways, we should define them or replace them with more direct
        wordings. <br>
        <br>
        Front channel essentially, as you are aware of, is the
        communication through the user agent. <br>
        Back channel is the direct communication between the client and
        the server. <br>
        <br>
        Any volunteer for the definition wordings? <br>
        <br>
        Nat<br>
        <br>
        (2013/11/20 3:54), Mike Jones wrote:<br>
      </div>
      <blockquote type="cite">
        
        
        <div>
          <p class="MsoNormal">We use the terms “front channel” and
            “back channel” in the Security Considerations but never
            define them.  Does anyone have a definition?</p>
          <p class="MsoNormal"> </p>
          <p class="MsoNormal">                                                           

            -- Mike</p>
          <p class="MsoNormal"> </p>
        </div>
        <br>
        <fieldset></fieldset>
        <br>
        <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
      </blockquote>
      <br>
      <br>
      </div><pre cols="72"><div class="im">-- 
Nat Sakimura (<a href="mailto:n-sakimura@nri.co.jp" target="_blank">n-sakimura@nri.co.jp</a>)
Nomura Research Institute, Ltd. 
<a href="Tel:+81-3-6274-1412" target="_blank">Tel:+81-3-6274-1412</a> Fax:<a href="tel:%2B81-3-6274-1547" value="+81362741547" target="_blank">+81-3-6274-1547</a>

$BK\%a!<%k$K4^$^$l$k>pJs$O5!L)>pJs$G$"$j!"08@h$K5-:\$5$l$F$$$kJ}$N$_$KAw?.$9$k$3$H$r0U?^$7$F$*$j$^$9!#0U?^$5$l$?<u<h?M0J30$NJ}$K$h$k$3$l$i$N>pJs$N3+<(!"J#@=!":FG[I[$dE>Aw$J$I0l@Z$NMxMQ$,6X;_$5$l$F$$$^$9!#(B</div>$B8m$C$FK\%a!<%k$r<u?.$5$l$?>l9g$O!"?=$7Lu$4$6(B&#1235
 ;
 6;|
14;$B$;$s$,!"Aw?.<T$^$G$*CN$i$;$$$?$@$-!"<u?.$5$l$?%a!<%k$r:o=|$7$F$$$?$@$-$^$9$h$&$*4j$$CW$7$^$9!#(B
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
</pre>
      <br>
      <fieldset></fieldset>
      <br><div class="im">
      <pre>_______________________________________________
Openid-specs-ab mailing list
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/" target="_blank">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en" target="_blank">http://twitter.com/_nat_en</a>
</div>