Testing UMA means testing controlling an individual's online data by himself!

One of the reasons I joined the UMA-WG, was that I wanted to be involved in a project right from the specs and not when it is time for systemtesting. Next to that, the concept of UMA fascinates me and worth making me sweat!
The active discussions we have about the testability of the specs inspire me to improve my work as a systemtester.
The implementations of UMA can be in legious domains: enterprise, government, education, e-commerce etc. etc.
This makes it a project where IT-architects from different domains can work together making user stories and use cases and improve this user centric authorization protocol.
Yes, we also have OpenID and OAuth, but, IMFO, OpenID is for authenticating the user and OAuth for authorizing it.
UMA let an individual control the authorization of data sharing and service access made between online services on the individual's behalf, as a layer on OAuth. It doesn't involve the authentication, but is very much dependent on OAuth and its possible changes, which are very much monitored by the UMA-WG.

A few years ago I started this blog, because I wanted to share my thoughts on testing SaaS and identity. The latter, because, IMFO, testers were mixing up authentication and authorization, which is disturbing, because it are important elements of web2.0, online user-interactivity.
With OpenID I started, but UMA drives me more because it is fresh, very user-centric and can be interoperable with OpenID through OpenID/AB, melting two of my favorite testsubjects (authentication and authorization) in one.

I wait for the day I can test an online user-interface (say banking :-) ) where an individual, with the help of the UMA-protocol, can control the data he or she wants to share with third parties, on the individual's behalf.

Something worth sweating for!