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 >> [email protected] [5] >> https://www.ietf.org/mailman/listinfo/oauth [6] Links: ------ [1] mailto:[email protected] [2] mailto:[email protected] [3] http://blog.facilelogin.com [4] http://RampartFAQ.com [5] mailto:[email protected] [6] https://www.ietf.org/mailman/listinfo/oauth [7] mailto:[email protected]
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
