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
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
Yeah you're right... is UMA ready to live up to all the hype of it solving life the universe and everything... probably not. Can we use it for API access management... sure. - Mike On 2015-10-06 07:09, Justin Richer wrote:
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
-- ------------------------------------- Michael Schwartz Gluu Founder / CEO mike@gluu.org
Thanks for this Justin I agree that this is a good way to look at things. As an example there are a number of things that measures something's maturity, these include: 1. Extent of deployments 2. Extent of conformance and interop 3. Availability of open source for all the endpoints (in multiple dev environments/language). On these measures UMA is still moving out the maturity model. Not recognizing this would be silly as would be treating the immature comments as damning. Justin nailed it, look at 1.01 if it fits use it and join us in making access control meet the privacy, scale and "userability" that is so needed on line today. b/r Sal -----Original Message----- From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Justin Richer Sent: Tuesday, October 06, 2015 8:10 AM To: Michael Schwartz Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] UMA is ready 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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Justin nailed it! Michael Chen and I ran headlong into many of the same issues Justin had already reported as soon as we started. More important, the more I've worked on UMA, the more concerned I get on how the profiling around the protocol is going to impact interoperability. How many Authorization Servers will each citizen have? Eve and I have started to work on that around the legal subgroup but we will need a broader discussion soon. That said, I remain guilty of evangelizing UMA far and wide and am truly grateful for the amazing work the group is doing. Thank you. Adrian On Tue, Oct 6, 2015 at 8:50 AM, Salvatore D'Agostino <sal@idmachines.com> wrote:
Thanks for this Justin I agree that this is a good way to look at things.
As an example there are a number of things that measures something's maturity, these include:
1. Extent of deployments 2. Extent of conformance and interop 3. Availability of open source for all the endpoints (in multiple dev environments/language).
On these measures UMA is still moving out the maturity model. Not recognizing this would be silly as would be treating the immature comments as damning.
Justin nailed it, look at 1.01 if it fits use it and join us in making access control meet the privacy, scale and "userability" that is so needed on line today.
b/r Sal
-----Original Message----- From: wg-uma-bounces@kantarainitiative.org [mailto: wg-uma-bounces@kantarainitiative.org] On Behalf Of Justin Richer Sent: Tuesday, October 06, 2015 8:10 AM To: Michael Schwartz Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] UMA is ready
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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
+1. We have just finished a pretty successful PoC of UMA here down-under. What does that mean? Well.. for use cases that UMA was designed for, it was great. For use cases where we stretched it way way over its intended scope, less so (wanted to see just how far we could go ..☺) For use cases that weren’t even in the scope of UMA, ditto. The point is that the distributed authorization and access control use cases can be pretty complex at the best of times..and they are highly contextual. You can’t design up front, for every single one of them. Add the fact it was Gov, multiple agencies, a lot of ‘system’ (headless use cases we called them) and you have super complexity. You have to do some supporting work in your software, in your processes, even maybe some customization here and there. But we came out with a clear understanding that we were a helluva long way better off than coding up something from scratch from OAuth to do.. well .. what UMA does really.. plus some other things. Cheers Colin From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Adrian Gropper Sent: Wednesday, 7 October 2015 3:05 a.m. To: Salvatore D'Agostino Cc: Michael Schwartz; wg-uma@kantarainitiative.org WG Subject: Re: [WG-UMA] UMA is ready Justin nailed it! Michael Chen and I ran headlong into many of the same issues Justin had already reported as soon as we started. More important, the more I've worked on UMA, the more concerned I get on how the profiling around the protocol is going to impact interoperability. How many Authorization Servers will each citizen have? Eve and I have started to work on that around the legal subgroup but we will need a broader discussion soon. That said, I remain guilty of evangelizing UMA far and wide and am truly grateful for the amazing work the group is doing. Thank you. Adrian On Tue, Oct 6, 2015 at 8:50 AM, Salvatore D'Agostino <sal@idmachines.com<mailto:sal@idmachines.com>> wrote: Thanks for this Justin I agree that this is a good way to look at things. As an example there are a number of things that measures something's maturity, these include: 1. Extent of deployments 2. Extent of conformance and interop 3. Availability of open source for all the endpoints (in multiple dev environments/language). On these measures UMA is still moving out the maturity model. Not recognizing this would be silly as would be treating the immature comments as damning. Justin nailed it, look at 1.01 if it fits use it and join us in making access control meet the privacy, scale and "userability" that is so needed on line today. b/r Sal -----Original Message----- From: wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org> [mailto:wg-uma-bounces@kantarainitiative.org<mailto:wg-uma-bounces@kantarainitiative.org>] On Behalf Of Justin Richer Sent: Tuesday, October 06, 2015 8:10 AM To: Michael Schwartz Cc: wg-uma@kantarainitiative.org<mailto:wg-uma@kantarainitiative.org> UMA Subject: Re: [WG-UMA] UMA is ready 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<mailto: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<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
So I just wanted to put in play the following as well after thinking about this a bit (I did just fire off the other comment..) What UMA is doing in my opinion is putting in place a standard for distributed authorization whether it be for an API or someone accessing a real thing in the real world. At a previous company we did this and made up our own auth and resource servers, token structure, signatures and clients as a way to do this. The benefits of having a standard as UMA exists today has tremendous value notwithstanding my maturity model comments below. UMA is no different than SAML, OAuth or OpenID in terms of evolution with wider use. I suspect that in many ways UMA is more mature than the other efforts upon initial release and those of us working on it have learned from these previous efforts all of which have contributed significantly to how we authenticate and authorize people and things notwithstanding the fact that they were barely ready (generous) when released. So while I agree with you Justin in terms of the need for the implementations, standard and profile to evolve that is different than whether or not it is ready, I really should have started my comments off there so I will end with it here. I don't think this is really a tin foil hat crowd and certainly the discussion has been unshielded for years. (you can recycle the tin foil for the PIV cards.. ;-). I think there is a case for the flip side, not to defend what has been done, it doesn't need that, but to make sure that the criticism doesn't eclipse or diminish the benefits that come from the wide adoption of something sorely needed. Respectfully, Sal -----Original Message----- From: Salvatore D'Agostino [mailto:sal@idmachines.com] Sent: Tuesday, October 06, 2015 8:51 AM To: 'Justin Richer'; 'Michael Schwartz' Cc: 'wg-uma@kantarainitiative.org UMA' Subject: RE: [WG-UMA] UMA is ready Thanks for this Justin I agree that this is a good way to look at things. As an example there are a number of things that measures something's maturity, these include: 1. Extent of deployments 2. Extent of conformance and interop 3. Availability of open source for all the endpoints (in multiple dev environments/language). On these measures UMA is still moving out the maturity model. Not recognizing this would be silly as would be treating the immature comments as damning. Justin nailed it, look at 1.01 if it fits use it and join us in making access control meet the privacy, scale and "userability" that is so needed on line today. b/r Sal -----Original Message----- From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Justin Richer Sent: Tuesday, October 06, 2015 8:10 AM To: Michael Schwartz Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] UMA is ready 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
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (5)
-
Adrian Gropper -
Colin Wallis -
Justin Richer -
Mike Schwartz -
Salvatore D'Agostino