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

Justin Richer jricher at mitre.org
Wed Nov 20 14:37:51 UTC 2013

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 list
>> Openid-specs-ab at lists.openid.net
>> http://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
> ????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
>   6;|
> 14;???????????????????????????????????????????????
> 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 list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131120/a3f3570c/attachment.html>

More information about the Openid-specs-ab mailing list