Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 10 Jan 2011 21:00:03 +0100

Independent of where this items belong to, the advice to only hand out 
tokens to authenticated clients is stronger as required by the core 
spec. There is a whole class of clients (native apps), which cannot keep 
secrets
for the purpose of authentication.

Moreover, what is the benefit of authenticating clients?

regards,
Torsten.

Am 13.12.2010 15:00, schrieb Brian Campbell:
> I think James makes a good point here.
>
> On Thu, Dec 9, 2010 at 10:45 PM, Manger, James H
> <[email-masked]>  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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth