On 04/02/13 16:27, William Mills wrote:
There are two efforts at signed token types: MAC which is still a possibility if we wake up and do it,
I'd rephrase it slightly differently, it is a possibility right now, OAuth2 supports custom tokens, the fact that OAuth2 may not formally approve MAC won't preclude the use of MAC in the OAuth2 compliant manner.
Of course OAuth2 putting a stamp of approval will make it more visible, without it, the existing MAC draft issues (if any) will end up being addressed at the specific implementations level only - not ideal for the community at large but it is up to OAuth2...
Cheers, Sergey
and the "Holder Of Key" type tokens. There are a lot of folks that agree with you. ------------------------------------------------------------------------ *From:* L. Preston Sego III <lpse...@gmail.com> *To:* oauth@ietf.org *Sent:* Friday, February 1, 2013 7:37 AM *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of oauth2 requests In an oauth2 request, the access token is passed along in the header, with nothing else. As I understand it, oauth2 was designed to be simple for everyone to use. And while, that's true, I don't really like how all of the security is reliant on SSL. what if an attack can strip away SSL using a tool such as sslstrip (or whatever else would be more suitable for modern https)? They would be able to see the access token and start forging whatever request he or she wants to. Why not do some sort of RSA-type public-private key thing like back in Oauth1, where there is verification of the payload on each request? Just use a better algorithm? _______________________________________________ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ 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
