Some thoughts on Adrian's use cases, first from a very high level, then drilling down. Sorry for the length. I hope it’s w

orth it. :-) My goals here are to a) help those on the subgroup who are less familiar with UMA get more familiar with it (since I owe everyone a “remedial UMA flow explanation" on Friday’s call anyway), and b) connect the dots between these use cases and our discussion of last week.

So first, quoting liberally from the UMA FAQ to give us some terminology:

"Let's use the example of Alice, a typical web user, to introduce UMA terms and concepts. Alice is a "resource owner” [RO] who manages her calendar resource online. She might want to share her calendar information with a number of different parties for a variety of purposes, while not making it fully public to the whole world.

The calendar is known as a "protected resource", and Alice manages it at a web application called a "resource server” [RS]. She could have many resource servers for many different kinds of content she creates, along with other data about herself. In some cases, such as with credit scores, she can't actually control the values of data about herself.

The parties Alice wants to share her calendar with are called "requesting parties” [RqP]. They use "client” [C] applications to attempt access.

In some cases, Alice herself is a requesting party in addition to being a resource owner, such as when she wants to share calendar data out to different calendar applications that she likes to use. We call this "person-to-self" sharing.

In other cases, she wants to allow her friend Bob and her various family members to get calendar access. We call this "person-to-person" sharing.

Finally, she may want to allow non-individuals, such as e-commerce companies and government agencies, to get access. We call this "person-to-organization" sharing.

With UMA, Alice can manage all these types of sharing in a unified way, from a single web-application point of control called an "authorization server” [AS]. She can set policies that guide the authorization server in allowing or disallowing access by clients to protected resources at resource servers."

Now, to the use cases. These are four interestingly distinct design patterns of UMA usage. Some of the details in them represent challenges that UMA needs other technologies to solve fully, that may not have been fully worked out yet, or that may or may not reflect reality as things unfold. I’m pretty sure this is not an exhaustive list of all the design patterns that may be of interest to us, but it’s a good starter set (keeping in mind that it focuses on one vertical out of many).

There may be only 4 distinct use-cases for UMA in healthcare. I wrote this in order to prepare for the legal subgroup this morning. Feel free to share if it's useful.

• Alice-to-Alice N - The multiple portals problem - Alice wants to direct sharing herself

Alice wants to manage her EHR-1 and EHR-2 authorizations in one place. We call that place the AS.

• Alice registers her AS with her practice’s EHR-1.
• Alice registers her AS with another practice EHR-2.
• From then on, Alice can sign-in to her EHR, view accounting for disclosures, and manage authorizations.

(EHR = electronic health record)

I suspect this is not actually a person-to-self sharing use case, or at least not exclusively, but rather just a case of Alice setting up multiple RS’s to be managed from a single AS, and she might share out those resources to multiple other parties.

“Accounting for disclosures” is an interesting phenomenon. Here, the AS is passively logging that third parties are accessing Alice’s resources, but she can’t do anything about it. Maybe the CDC is accessing her records for public health reasons, etc. If there’s an actual policy on record that allows the access, say, a system-default policy she can’t change, then it’s technically under UMA’s control, but if it happens outside that, then any monitoring is just some application feature. (In fact, logging is not something UMA currently says anything about anyway.)

• Alice-to-Custodian - Delegation to a custodian
• Custodian creates an AS for Alice. Custodian has a sign-in to Alice’s AS.
• Alice registers her AS with her PCP’s EHR-1.
• Alice registers her AS with another practice’s EHR-2.
• From then on, Custodian can sign-in to Alice’s EHR, view accounting for disclosures, and manage authorizations.

(PCP = primary care provider)

Extremely interesting one. I don’t think the custodian “creates” an AS for Alice. Does this mean the custodian creates an AS account for Alice, who is an “offline person” or something? But that can’t be right because then Alice does some online stuff.

This one hinges on how custodianship and delegation are defined. The “D” word is a slippery one. If the custodian is “acting-as” Alice in her AS (and RS?) accounts, that’s one (tricky) thing. If the goal is chained delegation (beyond the delegate) in a multi-AS environment, that another (tricky) thing.

• Alice-to-Bob Directed - Alice wants to authorize her PCP for directed sharing
• Alice registers her AS with her PCP’s EHR-1.
• The PCP shares an Alice-specific context with Bob.
• Bob’s client EHR-2 presents claims to Alice’s AS, gets authorization.
• EHR-2 accesses resource from EHR-1.

This is sort of “classic UMA”, and it even mentions the client application that Bob is using!

So now it’s interesting to bring up other lurking ghosts that could be important, like Bob’s employer, the company operating the AS (if it’s not Alice personally), the company/ies operating the EHR systems, the hospital or government or whatever that the PCP office is affiliated with, etc.

This is a good time to introduce the “negative use cases”. Let’s say Carlos gets access to a resource, or at a time, or with a scope (permission type), that Alice didn’t want or wasn’t expecting. Who’s at fault? What went wrong?

• Did Alice set the policy wrong?
• Did the AS screw up on its back end or ignore Alice’s wishes somehow?
• Did EHR-1 wrongly or maliciously release the resource?
• Did EHR-2 misinterpret some signal it was given by the RS or the AS?
• Did EHR-2 insufficiently protect or maliciously share the access token it was given?
• Did Carlos, operating the EHR-2 client, use it wrong, or present false claims, or mistaken claims?
• (am I missing anything? probably)

• Alice-to-Bob HIE - Alice wants to be discoverable
• Alice registers her AS with her practice’s EHR-1.
• Alice picks up a flier for the state HIE with a Q/R code, reads their Privacy Policy
• Alice signs-in into her AS and scans the Q/R code.
• The HIE allows Alice to pick her discovery attributes, registers Alice’s AS.
• Bob’s client signs into the HIE, discovers Alice, gets authorization to EHR-1.

(HIE = health information exchange)

Another challenging one because you have to tack on a discovery service. This version of the use case looks easier than the usual one because it doesn’t call for the discovery service itself to be protected.

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma