If the current draft is too hard for server developers to implement correctly, they should probably hire someone more capable. Server side development of a security protocol isn't something I'd like to see done by people without the proper experience. Once we have the security consideration section, this will become even more complex.
EHL From: [email protected] [mailto:[email protected]] On Behalf Of Andrew Arnott Sent: Tuesday, June 15, 2010 8:19 AM To: OAuth WG ([email protected]) Subject: [OAUTH-WG] On the ease of writing an authorization server I've read a few comments on this DL that a primary goal is that writing an OAuth 2.0 client should be very easy. I think we're doing well here. I know this ease for the client necessarily comes at the expense of some complexity on the server. As has also been pointed out recently (by Eran, I believe) the AS' job is considerably more complex now than it was in OAuth 1.0. While overall this may be a win, it also seems optimized for the few large service providers that are driving the spec (Facebook, Twitter, etc.). They definitely have the resources and understanding that a large investment in security is important. But as more web sites across the Internet drop using user passwords in favor of federated identity and/or OpenID-type protocols, the only way these sites can delegate access to user data will be to use a protocol like OAuth 2.0 since user passwords will no longer apply. Therefore very many web sites will become OAuth 2.0 resource servers, and likely given their size and requirements will be their on authorization server as well. Now we have a complex server-side protocol that may be "too" complex for the average-sized web site to implement correctly and confidently. So my $0.02 here is that we try to keep the AS side simple as well where possible. And invite responses from others. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
