My OWN $5/mo UMA Authorization Server

My Own $5/mo UMA Authorization Server

Thursday 2E

Convener: Adrian G.

Notes-taker(s): Eve M.

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

The HEART WG is potentially relevant for this conversation.

MITREid Connect is potentially relevant for this conversation.

Adrian does privacy advocacy. "Ownership of data" is a fraught term that he generally tries to avoid. But ownership of the authorization for access to data is conceivable. Here's an attempted definition: "There is no privacy policy." (Because there is nobody to have it with!) An UMA Authorization Server can be a Build, Run, or Outsource (Buy) proposition. Building your own AS makes ownership of authorization for access to data possible!

These are all still compatible, no matter which path you take, or even if you switch paths. Think of the example of email servers -- same thing. Dynamic registration of clients has to be handled and watched carefully in each of these paths.

In the HIE (Health Information Exchange) work Adrian has done, typically at the US state level, and the UMA work he's done, he's dreamed of being his "own HIE". The goal is "an HIE of One". How could this community build a reference implementation for this vision? Imagine, e.g., a Freedom Box for an HIE of One.

Alan K, when at HP Labs, had done some personal cloud appliance experiments, with the WebKey technology. They used self-signed certificates and DNS name registration. The appliance would re-register whenever needed. They worried that latency would be a problem, but it wasn't.  It was possible to get a free certificate that could generate other certificates.

Hardware:

• HP MyPersonalCloud appliance
  • Self-signed certificates: $0
  • DNS name registration: $15/year
    • WebKeys
  • No fixed IP address
  • Open source
  • Plug into router and email address in and out

Virtual hardware:

• OpenPDS (from MIT Media Lab, Sandy Pentland's lab)

Service:

• MITREid Connect (includes UMA)
• DigitalOcean (?) - Droplet

Phil suggests the idea of a cPanel, which is a control panel that could be installed on behalf of an individual ISP subscriber at a hosted domain. A Droplet isn't cPanel compatible, but the basic idea is the same. You would just need a credit card and then you could share a compiled Droplet. The only problem is that DigitalOcean won't do this for under $10/month.

However, a Droplet gets you only 512Mb of RAM, which is pretty constrained. Could a $40/mo virtual machine be worthwhile for a household? But then that changes the "ownership" equation. Spring is, unfortunately, very RAM-hungry.

Part of the HP business model was that if you bought a PC and support contract, then that would cover the cost of the cloud. Could that work here? With Apple HealthKit, maybe so -- or if you don't trust them, maybe not. :-) Right now, we have Prodigy, CompuServe, AOL, and SMTP -- we just have to get them all to speak SMTP!

Adrian's vision is that he wants to have, on his business card, the one string that lets him register his authorization server when he goes to a new doctor's practice etc., and then the only other possible thing on top would be a consent receipt. No messaging service or anything else would be required, other than compatibility with UMA.

Eve notes that there is more than just technical compatibility here. The systems have to work together, and interop and conformance help with this, but trust frameworks need to come into play here. It's not just institutions that impose on people; people impose their constraints on institutions and doctors too. E.g., people don't like seedy doctor's offices and want to know their data in a resource server is being treated securely. It's a "TOFU" (trust on first use) type of decision, built up from bilateral interaction.

The HP model nicely allowed for an application to be used directly by the requester with perfect compatibility. With the RESTful model, however, the URL (resource) pretty much assumes that the client needs to learn the API in question. The cool thing is that a marginally smart UMA client that knows the API in question can do trust elevation and get busy getting access.

A mobile device is really going to have to be involved if we want people to be comfortable using the interfaces to these authorization servers.

The important thing about ownership of the authorization for access to data ("There is no privacy policy" needed because there's nobody to have it with) is that it's absolutely necessary for true user-managed access (lowercase) of health data. The cool thing is that there seem to be a number of hardware and software options for building it in the not too distant future. The sticking point is that others in the ecosystem will have to come to accept dealing with an individual's chosen authorization server. If those other ecosystem players start speaking the FHIR (Fast Healthcare Interoperability Resources) API, then we can start really cooking with gas.