Minutes of 2012-05-24 meeting APPROVED.
We've gone a bit beyond our original timeframe according to the charter we approved, and so it's a good time to examine our charter. One item we documented was an intent to submit the UMA specs to IETF for hopeful eventual standardization there. Does it make sense to widen the consideration of this question at this point, given what we know of OAuth's process to date, the governance models of IETF and other organizations, etc.? Thomas has spent decades in IETF and knows it well. The OAuth WG's experience has demonstrated the typical pace of development there. Sal points out that we've submitted individual I-Ds to IETF, but moving the conversation wholly to a new place is a different juncture. The quality of conversation in the current WG has been excellent. Let's ruminate on this more over time.
Eve notes that while business use cases weren't originally in our scope, we've seen some implicit scope creep simply because some organizations seem to have "UMA-shaped holes" and express interest in UMA. Two companies now have given us feedback that the "user centricity" of UMA and its name have held them back from fully being interested in using it. Kevin has interest in both individuals and non-person entities (NPEs) being "users". So perhaps this is just a perceptual problem.
Should we consider how else we can accelerate adoption? Interop testing is a really key piece. Resources have been so tight that it's been difficult to create the feature tests etc. Eve, Joe, Kevin, Sal, Domenico, and Maciej are committing to doing an online OSIS feature-test-fest for two hours sometime in the next couple of weeks. Let's plan for June 13 9-11am PT. (Now in online calendar.)
Could we discuss "UMA for Enterprise" as "UMAE"? Maybe we could publish a use cases document specific to this, answering the question: "Can I use UMA for Enterprise?" "Yes, UMAE." :-) We have consensus to produce this as a deliverable or set of deliverables. Kevin agrees to figure out a starter list of questions around this that we can put in the FAQ. (Now done on the list.)
How does OpenID Connect solve distributed claims? This is a "mode", in which you get a pointer and an OAuth token to use at the location of the pointer. What we're thinking about is analogous: The AM could optionally present a discovery API to requesters, whose endpoints could be UMA-protected (so in this case it's really a host that's co-located with the AM). The use case is that Bob could approach Alice's AM to find where her calendar is. But the problem is that Alice may have multiple AMs. Ideally there'd be a separate discovery service component, possibly UMA-protected and possibly literally co-located with the AM but not required to be. This is still out of scope for UMA proper, but some folks are expressing a strong need for this.