Okay, one last response from me for the night — tomorrow morning it’s time to switch to “spec mode”.
I seem to have been less than clear in my point about UMA as Agency Law.
The Resource Servers hold all of the cards for adoption of UMA. To pretend otherwise is wishful thinking or a deep faith in regulation of technology.
My POV: It's reasonable for us to be non-neutral on the point of which transactional relationships to focus on more heavily. Some relationships are more fraught, or more misaligned in terms of interests, than others, and being use-case based is helpful. It’s no accident that we ended up mentioning two specific pairwise relationships in the legal subgroup mission statement out of all the possible ones: Alice-and-Bob (the end-to-end sharing relationship UMA exists to make possible), and service-and-hub (that is, RS-and-AS).
It’s becoming a truism, but I’ll point out again that the RS in access federation is in much the same position as the RP in identity federation: likely reluctant to lose control, concerned about liability, and somewhat disbelieving that such a job could be "outsourced to the cloud”...
To drive this point home, I would add two more points to the UMA as Restatement of Agency:
- The Third Party (UMA-RS) that registers an Agent (UMA-AS) deserves a Payment (8.14) to offset their cost in offering the API and their opportunity cost of foregoing the branding and advertising benefits of a manual Web portal that would otherwise tax the Principal's attention.
- The Third Party is encouraged to provide a choice of Agents for Principals that don't already have one. The Agent can be changed by the Principal at any later time. This is not required by Agency Law but it would provide a large incentive for RSs to adopt UMA before someone else does.
(The meeting Adrian and I had yesterday was extremely valuable, and I encourage folks — especially the
DoLs — to check out the resulting
document.)
I haven’t read the original source that you're analyzing here, so I’ll take your word for it on the citations and detail, but I like the direction of #1. (I’m not sure that “the branding and advertising benefits of a manual Web portal” need be given up totally.) #2 seems kind of specific.
Finally, to Mark's point, I did not mean to imply anything about MVCR. My perception of MVCR and UMA is that they are pretty much the same thing and that we are doing ourselves a dis-service by keeping them at all separate.
MVCR has benefits in today’s world (e.g. when Alice uses a random website) even sans UMA, and UMA has benefits even sans MVCR. But together they can be awesomesauce.
Eve