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(_at_)gmail(_dot_)com]
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