That text still seems more restrictive than what is in the framework specification. And it's probably unnecessary - to the point James made previously, any mention of the AS (beyond specifying the token_type) in a "using a token" specification should probably be avoided unless there is a very specific reason for including it. In general, the AS is involved when "getting a token" and the RS is involved when "using a token."
On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones <michael.jo...@microsoft.com>wrote: > Thanks for your input, Brian. I accepted these suggestions for draft -02. > The referenced text now reads: > > Furthermore, the > authorization server MUST ensure that it only hands out tokens to > clients it has authenticated first and authorized. For this > purpose, the client MUST be authenticated and authorized by > the authorization server. The authorization server MUST also > obtain the consent of the resource owner > prior to providing a token to the client. > > I'll leave it up to Eran how much of this security considerations text to > incorporate into the framework specification. > > -- Mike > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Brian Campbell > Sent: Thursday, December 09, 2010 1:38 PM > To: oauth > Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 > security considerations > > I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, > however, a couple things jumped out at me in areas that hadn't received much > attention yet so I wanted to raise the questions on a separate thread. > > Near the end of section 3.2. Threat Mitigation, it says: > > " Furthermore, the resource server MUST ensure that it only hands out > tokens to clients it has authenticated first and authorized. For > this purpose, the client MUST be authenticated and authorized by the > resource server. " > > Was the intent here to say authorization server rather than resource > server? The resource server doesn't hand out tokens. Also, aren't there > legitimate cases where the client isn't authenticated (anonymous or other > cases where the client can't keep secrets)? > > Then it says: > > "The authorization server MUST also receive a > confirmation (the consent of the resource owner) prior to providing a > token to the client." > > Does this allow for implicit consent? On my first read of it, I interpret > this as potentially being more restrictive than what is in > draft-ietf-oauth-v2-11 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
