Or maybe, if we remove the tinfoil-lined hat, UMA really *is* half-baked in a lot of ways. I know it’s difficult to see that when you’ve invested a lot of time and effort into a project, but when criticisms come in it’s often best to start with “they may have a point” before jumping to the defense of decisions you’ve made. It’s implementable within certain circumstances, but that doesn’t make it a good fit for everywhere. It’s likely that most deployments of Gluu (and others like the demos I’ve seen from ForgeRock) are working within specific environments that fit very nicely with the assumptions that the UMA standard has made so far. I ran face-first into a lot of these assumptions while implementing UMA in our own project. It fit in some ways, and really really didn’t in others. We had to hack in a few pieces to make our demo work (like the cross-domain AAT, which is why I want it gone in the next revision). It’s possible you won’t know if it’s a good fit until you try to build it, so grab a couple engineers and go to town for a few weeks. If it works, great, you’ve got the start to a really good solution. If it doesn’t work, come tell the working group how and we’ll try to fix that. You’ve only invested a very small amount of time/money/effort and probably learned a lot about your problem in the process, so this is hardly a wasted investment. What I’d tell people looking at UMA today is to look at their problem set and use case. Does UMA 1.0.1 fit that use case? Awesome, use it! There are a handful of implementations that work just fine in their own use cases and may or may not be interoperable, we don’t actually know, but the ecosystem is just getting started so come join us. And I think that the software-engineering approach to spec management that this group is adopting is a very good (and hopefully repeatable) model for managing expectations and efforts of people using the spec. Problem is, most consumers of specs don’t quite get that yet, but I think they will. This community needs to do an even better job of managing expectations than we’re already doing. Is UMA ready? Sure, for some things. Is it perfect? Not at all. Is it universally applicable? Not a chance. Is it done? Hardly. And that’s OK, as long as we all work to manage expectations. For example, don’t tell people that UMA is the answer before you know their question. ;) — Justin
On Oct 6, 2015, at 12:49 AM, Mike Schwartz <mike@gluu.org> wrote:
I have heard and seen pushback that UMA is too immature to implement yet and that worries me.
Of course its hard to respond to hearsay, but maybe the ones saying UMA is immature have an interest in non-interoperability of API security. Maybe it's not in the interest of vendors who haven't implemented, or don't understand UMA, to say it's immature. Or maybe the ones saying its not mature would rather not see a standard evolving at an organization they can't control. Who knows...
Gluu had no trouble implementing UMA. And the changes from 1.0 to 1.0.1 are no worse than the changes we've seen in OpenID Connect (i.e. look at the new front channel and back channel logout proposed specs).
Ultimately, Gluu's customers are deriving a competitive business advantage by using UMA, and that's all that really matters to us.
What I'd like to see is more sample code and more libraries. I think that would help--i.e. implementation is exactly what is needed, not what should be delayed.
- Mike
------------------------------------- Michael Schwartz Gluu Founder / CEO _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma