I don't necessarily think it necessarily follows that a standard has to be complex to satisfy enough people.
I hope OAuth 2 succeeds but having read all three blog entries, I'm optimistically cautious. Neither of the subsequent blogs in my opinion properly addressed any of the concerns from the original entry, and the comments in the one blog actually attacked the personality of the person who quit. OAuth's current structure, increased scope, and desire to have profiles reminds me of SAML, but I guess with a more hip non-XML model. Ironically, SAML is the thing everyone is hoping to avoid. :-) On Wed, Aug 1, 2012 at 4:22 PM, Nathan Kopp <nathan.k...@cru.org> wrote: > I tend to agree with you. Anything that is flexible enough to satisfy > enough people to become a standard will become rather complex. The more > use-cases you try to accommodate, the more the complexity grows. That > doesn't mean it is bad, and therefore I don't think it should give anyone > pause about using Oauth in CAS. It just should be a reminder to be careful > to make sure our implementation is secure. > > The OAuth spec clearly outlines many security issues, though, which is > great! For one thing, it convinced me that we needed to enforce a > white-list of allowed services for our CAS server implementation. Allowing > unchecked redirecting to unregistered services is actually a much greater > security risk than I had considered. The OAuth spec writers seem to have > been very careful in analyzing their protocol. > > -Nathan > > > From: Ganesh and Sashi Prasad <g.c.pra...@gmail.com> > Reply-To: "cas-dev@lists.jasig.org" <cas-dev@lists.jasig.org> > Date: Monday, July 30, 2012 8:19 PM > To: "cas-dev@lists.jasig.org" <cas-dev@lists.jasig.org> > Subject: Re: [cas-dev] Article: OAuth 2.0 and the Road to Hell > > Thanks for the link, Scott. On first reading, Eran Hammer's criticism > seems damning. However, what he's essentially saying is that the OAuth 2.0 > spec in itself is too flexible and extensible, allowing naive developers to > produce non-secure implementations, and also that two "spec-compliant" > implementations may be non-interoperable. > > As we know from the Web Services experience, this is the sort of thing > that can be fixed with an Interoperability Profile (e.g., WS-I Basic > Profile). He did admit that there are implementations that are > straightforward, simple and secure. So I'm sure there will be a second > level of standardisation to fix the problems he's pointing out. It doesn't > mean that OAuth 2.0 is unusable. That would be reading too much into it. > > My blog on this has more detail: > http://wisdomofganesh.blogspot.com.au/2012/07/oauth2-whom-to-believe.html > > Regards, > Ganesh Prasad > > On 29 July 2012 08:55, Scott Battaglia <scott.battag...@gmail.com> wrote: > >> Interesting read as we attempt to evaluate which standards make the most >> sense for CAS to support: >> http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ >> >> Cheers, >> Scott >> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: >> g.c.pra...@gmail.com >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > nathan.k...@ccci.org > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
