On 2011-03-31, at 7:32 AM, Skylar Woodward wrote: > A requirement for TLS on the callback would make OAuth prohibitive for many > of our developers. The developers are usually volunteers and they are already > donating their own resources to help a non-profit (from which US law mandates > the developers cannot profit). In other cases the developers are small firms > operating in developing counties where establishing and maintaing a valid > certificate may still be a imperfect art. > > In short, a requirement like this puts the nail in the coffin of many > would-be efforts to help out. > > So as Dick identifies here, we have sufficient security around the > authorization grant by tying it client credentials. I would thus be opposed > to the term "MUST." I also think it's helpful to have the language limit the > SHOULD to the non-user-agent cases. There's no reason we should suggest a > callback URI designed for client-side intercept to use an HTTPS url - so this > is in the spirit of Phil's response to Justin's comment on limiting the scope > of SHOULD.
Unfortunately I was mistaken. The attack that Francisco is discussing and George summarized is NOT dealt with by the client credentials. Summary: If authorized by Alice, client.com can expose information to the Attacker about Alice that is stored at resource.com. If the Attacker can intercept the authorization code (and likely any session management between Alice and content.com), client.com does not realize that it is being presented by the Attacker since it is common that the only identity that client.com has about the user is from resource.com, there is no way for resource.com to know they are not acting on behalf of Alice, even though the session is with the Attacker. The Attacker now has access to Alice's resources at resource.com via client.com The attack is enabled because there is no means for client.com to authenticate the user, and is often using resource.com to authenticate. -- Dick _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
