Thanks, David. Just to clarify, I think it is the right decision as well. But I just wanted to voice that I think we should simplify the AS where possible (i.e. where it doesn't sacrifice legitimate scenarios or simplicity on the client).
As a great example of good work being done here, removing the access token secrets was a great move IMO. I wouldn't have liked it a few months ago, but since it was among the more complex areas of the spec, hard to get right, and no one was planning to use it (from the sound of it) moving it to an extension spec makes tons of sense. -- 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 On Tue, Jun 15, 2010 at 8:53 AM, David Recordon <[email protected]> wrote: > I frame this goal a little differently. When there is a decision about > where to place needed complexity, we should place as little as > possible of it on the client. This means that the AS is more complex, > but I think that is the correct decision. > > --David > > > On Tue, Jun 15, 2010 at 8:19 AM, Andrew Arnott <[email protected]> > wrote: > > 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 > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
