This afternoon, I attended UMA WG session at Kantara Initiative. UMA stands for User Managed Access, formally known as ProtectServe.
The purpose of this Work Group is to develop a set of draft specifications that enable an individual to control the authorization of data sharing and service access made between online services on the individual’s behalf, and to facilitate the development of interoperable implementations of these specifications by others.
Thus, it roughly is equal to CX in it’s concept.
A little bit of comparison was done in today’s session.
Most notably:
In CX, contract proposal is sent from the data consumer to the data provider (user) while in UMA, the proposal is being sent from the data provider (user) to the data consumer.
This is subtle but important distinction, at least, philosophically.
In fact, when I started discussing CX among my friends, we first consider the user providing the policy just like UMA. It was because it is closer to the VRM like setting. Then, after a while, we made a conscious decision to do the other way round.
Why?
In most cases, the data consumer is actually web service. It is a machine. On the other hand, on the data provider side, there is the user, the human being, who makes the decision.
If we offer a contract proposal from the user side, the machine has to negotiate it automagically. It is hard.
It looked like it is an daunting task to do it over a wide range of possible use cases.
On the other hand, the other way round is easy. You show the user the condition and terms, and it is this human being parsing that proposal and making decision. This seemed like a reasonably easy thing to achieve technically.
To approximate user providing the acceptable policy, we can create a common repository of contract proposals and the user can publish the URL in his XRD, so that the data consumer can pick an acceptable policy.
I believe this approach saves us from the hard question of designing negotiation protocol and still achieve something roughly the same. Also, note that we do not have to agree on the syntax of the machine readable condition. It is up to the application to decide it(*1).
We are right now doing CX WG at OpenID Foundation. However, CX is not only for OpenID. I consider it as an OpenID Binding of CX. It can equally be done for OAuth or some other protocol.
UMA’s approach is definitely interesting, but I still do not know how it can be achieved. It is a “must track” kind of thing for me right now.
(*1) There was yet another reason to do it this way: I was not comfortable floating around a contract proposal signed by me waiting for some unknown party to counter-sign floating around. From the “consumer protection” (note different use of the term “consumer”) perspective, IMHO, the user should be the last one to sign.