Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework

Phil Hunt <phil.hunt@oracle.com> Wed, 09 January 2013 07:31 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F21221F87AC for <oauth@ietfa.amsl.com>; Tue, 8 Jan 2013 23:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awXLYx1mqDLT for <oauth@ietfa.amsl.com>; Tue, 8 Jan 2013 23:31:34 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 090D821F870A for <oauth@ietf.org>; Tue, 8 Jan 2013 23:31:33 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r097VR6R029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 07:31:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r097VPEY019489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 07:31:25 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r097VOIY012087; Wed, 9 Jan 2013 01:31:25 -0600
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jan 2013 23:31:24 -0800
References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <CAJV9qO80r93oOk-EjVukF0AUbc5-FWu8VhpVi+9WZBGzSjMrPA@mail.gmail.com> <CABFKGsdJtR3rX+=Puto2D40F9m4kT+rvR6EyU6mx3aEkxG5VNw@mail.gmail.com> <CAJV9qO_A-_5CbfREFBxXr1efaAG5hVdbOR03BNgWY=iBM11fFg@mail.gmail.com> <d2d4bd929ec0d00960e54bd9a3988bf3@comp.polyu.edu.hk> <C932A6E6-3967-4272-99D4-4D10D9A3860B@oracle.com> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk>
Mime-Version: 1.0 (1.0)
In-Reply-To: <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk>
Content-Type: multipart/alternative; boundary="Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C"
Content-Transfer-Encoding: 7bit
Message-Id: <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com>
X-Mailer: iPhone Mail (10A523)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Tue, 08 Jan 2013 23:31:22 -0800
To: cspzhouroc <cspzhouroc@comp.polyu.edu.hk>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Peng Zhou <zpbrent@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2013 07:31:35 -0000

The AS is independently authenticating the user and the client in separate steps.

Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. 

Phil

Sent from my phone.

On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:

>  
> 
> Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS?
> 
>  
> 
> On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote:
> 
>> The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. 
>> The redirect with code flow enables the separate contexts to be bound together. 
>> As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. 
>> 
>> Phil
>> Sent from my phone.
>> 
>> On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote:
>> 
>>> Dear Prabath:
>>> 
>>>  
>>> 
>>> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly?
>>> 
>>>  
>>> 
>>> Best Regards
>>> 
>>> Brent
>>> 
>>>  
>>> 
>>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote:
>>> 
>>> 
>>> 
>>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> wrote:
>>>> Dear Prabath:
>>>> 
>>>> Thank you very much for your responses :-)
>>>> 
>>>> However, I am still not quite sure why the authorization code must be
>>>> sent to the client through the RO's user-agent?
>>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken.
>>> Thanks & regards,
>>> -Prabath
>>>  
>>>> 
>>>> Best Regards
>>>> Brent
>>>> 
>>>> 2013/1/9 Prabath Siriwardena <prabath@wso2.com>:
>>>> > Prabath
>>> 
>>> 
>>> 
>>> -- 
>>> Thanks & Regards,
>>> Prabath
>>> Mobile : +94 71 809 6732 
>>> 
>>> http://blog.facilelogin.com
>>> http://RampartFAQ.com
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>