In the identity management case we are not necessarily talking about solutions that are "good" or "bad". The issue is that certain people care about one use case and other people care about other use cases. I use the term "use case" in a generic sense to also include certain deployment assumptions (e.g., has to work with existing programming languages, deployment environments), or design themes (e.g., XML vs. JSON). So, for example, in the OAuth case there are people who care a lot about different Websites sharing data between each other (the photo sharing / photo printing use case). Again others think that the smart phone use case is more important. The solutions for these two cases are slightly different (because they can rely on different assumptions). Initially, people start with a single use case they care about. The work gets attention and other people start to use the protocol as well and notice that it does not meet their use cases. So, they add functionality. Over time the set of specification becomes more complex and a beginner does not see through the specification jungle anymore. Then, these newcomers start from scratch to fix all these "complex protocols". Typically, these persons like to reject any idea that was done in the past (such as learning from the experience the previous generation had made). The cycle starts from the beginning. We went through these cycles several times already in the identity management world. We had seen this with the transition from Kerberos to SAML, from SAML to OpenID, from OpenID to OAuth. At some point we should ask ourselves whether the problem that is being solved is multi-faceted and the resulting solution will just not be a 10 page document (unless it is incomplete). I believe that application developers shouldn't even worry about the details of the protocol suite. They should be using a library instead. We use libraries all the time and particularly with security protocols. Take TLS as an example. No application developer would come up with the idea to write their own TLS stack either. They let security professionals write those libraries. On Aug 2, 2012, at 1:58 PM, Worley, Dale R (Dale) wrote: >> From: Murray S. Kucherawy [superuser@xxxxxxxxx] >> >> I think it's impossible to determine with certainty whether someone >> standing at the mic and asserting a position is doing so based on what >> an employer is insisting on doing, or that person's opinion. > > But it is possible, over a period of time, to get a good estimate of > whether someone promotes technically poor solutions that are > commercially advantageous for their employers. > > Indeed, relative to our fundamental principle of openness, "All may > speak; not all are listened to.", in order to be listened to, someone > has to spend some time to establish a reputation for technical quality > of their contributions, and not being a shill for poor ideas advanced > by their employers. > > Dale