UMA telecon 2014-07-03

Date and Time

Agenda

Minutes

AI status

Thomas found a Windows-only tool that enables conversion of WebEx recordings into something more standard. He'll play with the excerpting process within the next week.

AI: Eve: Arrange to get an email sent to all webinar attendees with the recording and slide links.

Upcoming events

Discuss healthcare use cases

Adrian has been advertising UMA as being able to solve all known human problems. (smile) Debbie works out of the HHS Office of the National Coordinator (ONC). There's been a push for RESTful solutions. OAuth, OIDC, and other related solutions have been talked about, and there's been some nascent UMA interest. She's gotten the okay to do a small pilot, and has reached out to the VA. The VA is very interested in data segmentation, privacy, data provenance, and consent. The notion of a RESTful approach to solving problems where XACML is already in the works is interesting. VA, Kaiser Permanente, ONC, and (Adrian's) Patient Privacy Rights (PPR?) effort are keen to do a live demonstration at HIMSS 2015. Profiling is of high importance, and it's also important to point to reference implementations. This has all led to the collaboration. The current outlook is a healthcare-related OIDC-enabled healthauth.org (question) pilot. The biggest concern is that ONC wants to know precisely how this will be done; they'll be looking at the profiling and reference implementation work.

Adrian notes that this is all preceded by a lot of "consent management" work; ONC has sponsored Justin's work over the summer at MIT. The big question is now is: How much of UMA is generic, and how much is sector-specific and needs to be profiled? And another question is: Who gets to choose the AS: the RO, or someone else in the ecosystem? Following on this, if it's not the RO's choice, what profile would be active?

Debbie adds: How do these systems need to scale? It's quite possible that a user could have many AS services, and then what? What's the needed infrastructure, and what are the needed trust frameworks?

Mike comments: UMA supports a number of different trust models. He'd like to focus less on the bindings and more on the core stuff. He's been working on the Juju app security project. This is a framework that defines OIDC, UMA, and SCIM used in concert by cloud apps. The goal is to drive down the cost of web security. UMA's core is already pretty complex, with three entities. But they definitely do need other agreements around them in deployment.

Eve observes that once we've pushed our three technical specs to "mature draft" specification status, it may be the perfect time to get the contractual/legal Binding Obligations spec to the same status. We do need to help third-party profilers to figure out what the right dividing line between "core" and "profile" is, and also to advise how third parties can create (profile) new access federations that enable horizontal (e.g. being listed in an app store) or vertical (e.g. healthcare) ecosystems – or both (an RLS is a health-related directory/registry of sorts). And it would be good to figure out the relationships between identity federations and access federations – where is there daylight and why? Where is it inappropriate to link them?

Mike is part of a group that has proposed an OAuth multi-party federation group (this is the one that Prateek from Oracle has been promoting). They're thinking of proposing this as an OAuth2 WG at IETF or at OASIS vs. at the OpenID Foundation, because it's important not just for, say, social login but also for B2B collaboration. This could involve things like standardizing scope descriptions; see the examples here.

Debbie points out that Direct Trust involves S/MIME etc. at a technical level, and FICAM involves technical details but at a fairly high level.

Adrian decries the state of healthcare interop based on its heavy profiling. He wants UMA to contain the sedimented wisdom about what's core and what's specific (maybe attributes, but try to minimize what goes here).

Let's agree to capture issues for every known third-party profile to consider whether it should be "first-party", and thence whether it should be included in interop activities.

AI: Eve: Create issues around the trust elevation profile and anticipated healthcare profiling, informed by Mike's federation example.

Editors' ad hoc meeting to edit specs into shape

Attendees

September event plans are noted below:

Ann is founder and CEO of World Knowledge, and is active in NSTIC and IDESG.

Next Meetings