I think James makes a good point here.
On Thu, Dec 9, 2010 at 10:45 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: > I think these items shouldn't be in the bearer spec at all. They are about > "getting a token", not about "using a bearer token" so they should be left to > the core spec. > > -- > James Manger > > > -----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
