[Openid-specs-ab] Front channel and back channel

Nat Sakimura n-sakimura at nri.co.jp
Thu Nov 21 15:12:40 UTC 2013


Thanks Justin.


2013/11/20 Justin Richer <jricher at mitre.org>

>  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:
>
>
>
>  When an Access Token is returned *via the user agent using the implicit
> or hybrid flow*, 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 *through the user agent*. 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 *through the user agent*for the response types of
> code token and token is the same. Thus, the implementations should be
> prepared to detect *whether the Access Token was issued through the user
> agent or directly through from the Token Endpoint* and deny offline
> access if the token was issued *through the user agent*.
>
>   -- Justin
>
>
> On 11/20/2013 02:53 AM, n-sakimura wrote:
>
> I suppose it was taken from SP800-63 or so.
> Anyways, we should define them or replace them with more direct wordings.
>
> Front channel essentially, as you are aware of, is the communication
> through the user agent.
> Back channel is the direct communication between the client and the
> server.
>
> Any volunteer for the definition wordings?
>
> Nat
>
> (2013/11/20 3:54), Mike Jones wrote:
>
>  We use the terms “front channel” and “back channel” in the Security
> Considerations but never define them.  Does anyone have a definition?
>
>
>
>                                                             -- Mike
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> --
> Nat Sakimura (n-sakimura at nri.co.jp)
> Nomura Research Institute, Ltd. Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>
> 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。
> 誤って本メールを受信された場合は、申し訳ござ&#1235
>  ;
>  6;|
> 14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
> 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.
>
>
>
> _______________________________________________
> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131121/dbf65842/attachment.html>


More information about the Openid-specs-ab mailing list