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

cspzhouroc <cspzhouroc@comp.polyu.edu.hk> Wed, 09 January 2013 08:13 UTC

Return-Path: <cspzhouroc@comp.polyu.edu.hk>
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 F0EF121F8541 for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 00:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.461
X-Spam-Level:
X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 gJWJdYWu5hFD for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 00:13:42 -0800 (PST)
Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9521F853C for <oauth@ietf.org>; Wed, 9 Jan 2013 00:13:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 1649F50387; Wed, 9 Jan 2013 16:13:40 +0800 (HKT)
X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk
Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Wzr-P1vf8jEf; Wed, 9 Jan 2013 16:13:39 +0800 (HKT)
Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 1011450378; Wed, 9 Jan 2013 16:13:39 +0800 (HKT)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_c23d971cd37010adba4d22002e201026"
Date: Wed, 09 Jan 2013 16:13:40 +0800
From: cspzhouroc <cspzhouroc@comp.polyu.edu.hk>
To: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <76052798-FF20-4637-97F4-CED948099266@oracle.com>
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> <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com> <7c77a1b3013a22ed01efe15e741f3265@comp.polyu.edu.hk> <76052798-FF20-4637-97F4-CED948099266@oracle.com>
Message-ID: <a61edb4977734d079a0c6096fccd69ad@comp.polyu.edu.hk>
X-Sender: cspzhouroc@comp.polyu.edu.hk
User-Agent: RoundCube Webmail/10.5
Cc: Peng Zhou <zpbrent@gmail.com>, 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 08:13:45 -0000

  

Noted and thank you very much for your help :-) 

On Wed, 9 Jan
2013 00:11:20 -0800, Phil Hunt wrote: 

> Yes
> 
> Phil 
> 
> Sent from
my phone. 
> 
> On 2013-01-09, at 0:09, cspzhouroc wrote:
> 
>> Do you
mean, in the stage that AS notify the authorization code to the client
through the RO, the AS has not authenticated the client yet. Therefore,
the AS cannot send the authorization code to the client directly.
Instead, the AS will authenticate the client when the client send the
authorization code to AS for exchanging an access token? 
>> 
>> On Tue,
8 Jan 2013 23:31:22 -0800, Phil Hunt wrote: 
>> 
>>> 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 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 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 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
>>>>>>> 
>>>>>>> -- 
>>>>>>> Thanks &
Regards,
>>>>>>> Prabath 
>>>>>>> Mobile : +94 71 809 6732 
>>>>>>>

>>>>>>> http://blog.facilelogin.com [3]
>>>>>>> http://RampartFAQ.com
[4]
>>>>> 
>>>>>> _______________________________________________
>>>>>>
OAuth mailing list
>>>>>> OAuth@ietf.org [5]
>>>>>>
https://www.ietf.org/mailman/listinfo/oauth [6]

  

Links:
------
[1]
mailto:prabath@wso2.com
[2] mailto:zpbrent@gmail.com
[3]
http://blog.facilelogin.com
[4] http://RampartFAQ.com
[5]
mailto:OAuth@ietf.org
[6]
https://www.ietf.org/mailman/listinfo/oauth
[7]
mailto:cspzhouroc@comp.polyu.edu.hk
[8]
mailto:cspzhouroc@comp.polyu.edu.hk
[9]
mailto:cspzhouroc@comp.polyu.edu.hk