[Openid-specs-heart] "Individual-to-NPE" sharing episodes in UMA use cases, and "design pattern" solution options

[Eve Maler]

So much juiciness in this thread... I am overwhelmed. :-) A couple of
thoughts to follow up:

*Caching:* I guess I'm something of a contrarian on the caching problem. In
real life we see a continuum of app and human behavior around how sharing
is done, based on:

   - *Data volatility over time* (stable home addresses make
   downloading/copying/caching more attractive than volatile calendars do --
   for the latter we share URLs, sometimes secured or at least "secret")
   - *"Stasis" of the data operations desired* (reading/printing operations
   makes downloading/copying/caching more attractive than complex API calls do
   -- for the latter we share endpoints, mostly often secured)
   - *Sharing method affordances* (by-value methods like generating PDFs,
   when available, make downloading/copying/caching more attractive than a
   Share button that lets you create a policy for accessing the original
   (endpoint-based) source of truth in an access-controlled way)

One of the original motivations of UMA was precisely to enable protection
over a "feed" of data, meaning roughly that a URL from which a fresh
version of data can be sourced should be able to be freely shared, without
necessarily implying that anyone in possession of the URL automatically
gets the data. UMA does not inherently rely on "magic links" or "secret
URLs", and thus it helps to boost the affordances around by-reference
sharing methods vs by-value methods.

There are still, of course, other challenges to solve. Genome data is an
example of especially non-volatile data; being able to capture "purpose of
use" restrictions enforceably is one goal of UMA's legal subgroup, partly
to remove some friction around non-volatile data.

But we were talking about EHR copying and caching on the call. To me, this
an example of fairly volatile data that also tends to have much more value
when absorbed into a specialized client ecosystemthat knows about the
specific API calls to use vs just getting, say, a "dead" PDF. (BTW, my
latest UMA demo actually demonstrates how a medical pro can naively share
the URL for a patient's IoT bath-scale weight data with a colleague, which
doesn't automatically confer access privileges; rather, the resource owner
gets a "pending request" that she can field. Happy to share that with y'all
at some point.)

Finally, "time-to-live strategy" is a time-honored way to manage some kinds
of cache abuse, and UMA has one or two more potential points for managing
TTL than even OAuth. Here's a short section
<https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.1.3.4>
that discusses it.

*"Relationship-based access control":* There was some thread discussion
about a) roles being something that could indeed be practical and familiar,
at least in the HL7 context, b) groups being a potentially viable approach
because of their simplicity and familiarity, particularly with "email-like"
identifiers in place, and c) the attractions of having Alice sharing with
(what appears to be) a single other individual.

In the interests of time, I didn't go into more detail about another
experimental approach I've briefly mentioned on previous calls, but which I
think may be helpful here: applying access controls -- that is, policies --
in some automated fashion based on the relationships established between
people, and/or between people and things, and/or between things. This could
potentially take a lot of confusion out of Alice's interactions and
mistakes out of sharing patterns within organizations. In my company we've
started referring to this as ReBAC, for relationship-based access control.
(From where we're sitting, it starts getting essential real quick when you
have to scale to All The Devices...) Thoughts?


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!

On Tue, Oct 20, 2015 at 2:52 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Our goal is interoperability. I suggest we base our design pattern
> priorities on (a) the recent GAO report and (b) the doctors in my state
> medical society.
>
> (a)
> Electronic Health Records: Nonfederal Efforts to Help Achieve Health
> Information Interoperability GAO-15-817: Published: Sep 16, 2015. Publicly
> Released: Sep 29, 2015. http://www.gao.gov/products/GAO-15-817 that says:
>
> "Stakeholders and initiative representatives GAO interviewed described
>> five key challenges to achieving EHR interoperability, which are consistent
>> with challenges described in past GAO work. Specifically, the challenges
>> they described are (1) insufficiencies in health data standards, (2)
>> variation in state privacy rules, (3) accurately matching patients' health
>> records, (4) costs associated with interoperability, and (5) the need for
>> governance and trust among entities, such as agreements to facilitate the
>> sharing of information among all participants in an initiative."
>>
>
> (b)
> Two MA medical society resolutions and our Task Force (which Dr. Sullivan
> chairs) have all concluded that physicians need to have control over
> information sharing for their patients without what ONC calls "blocking" by
> the institutions or EHR vendors that may be involved. Our Task Force has
> actually suggested to the AMA that physicians should have a way to get
> access to the patient-controlled EHR interface. This approach is sometimes
> referred to as patient-directed exchange. Note that patient-directed
> exchange does not mean that the patient gets to see her own data (as with a
> patient-mediated or PHR exchange). The FHIR resource goes directly from the
> NPE to the Requesting Party. In this way, and with appropriate FHIR
> cooperation, this helps solve difficult provenance, cache consistency, and
> patient matching issues.
>
> Of the 5 GAO "challenges" (2), (3), and (5) would be completely eliminated
> by a patient-directed design pattern. (1), the data standards, is a
> combination of FHIR and HEART outcome. (4), costs, should be equivalent for
> any FHIR API design pattern, but even if costs were an issue, the
> patient-directed exchange allows for patient pay to remove that barrier.
>
> Choosing to deliver a patient-directed design pattern as our HEART
> baseline does not preclude either FHIR or HEART from delivering other
> design patterns in the future but it will inform the work of FHIR and align
> our efforts with the GAO and physician comments.
>
> Therefore, I propose this Baseline HEART Sequence Diagram
> <http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IFByZXNlbnRzIEluIABdBgpSUy0-Uk86IEdldHMgQ3JlZGVudGlhbAAqCVNpZ24gSW4gdG8gTlBFIFBvcnRhbAAtCURpc3BsYXkAFgVST0kgRm9ybQAxCnBlY2lmeSBBdXRoJ3ogUwCCXAoAgQgJVGV4dCBSAINkByBEZXNjcmlwdGlvbgCBLgVBAHIOAIM2BgB7BwCBNAVBUzogRkhJUgAtFkEAgVQHAEMiQ29uZmlybQCBJQUAhA8JIFBvbGljaWVzAEMGAB0KXG4AgSkJUmVnaXN0cgCEQwUAgQkJQ29uc2VudCBSZWNlaXB0CgCDYBUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDKAsAhB0LAIQWDiBScVAgZGlzY292ZXIAhAsGAIYjCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhAYLUnFQAIJYBgCECAlDbGFpbXNcbmUuZy4gYm9iQG1lZGljYWxzb2NpZXR5Lm9yZwCCSgZxUACEGRMARwgAgyEMUwBcCk1heSBuZWVkIHRvAIIrB2VyIEMAhkwFAIMgBUMAgiISQwCDeAZSAIZJBnMAgwwOAC0IR3JhbgALEQCCIBsAgmERMgCGGwogCkMAhh4GQWNjZXNzAIRJDgCEZAlBY2NvdW50aW5nIGZvciBEaXNjbG9zdXIAgxUdAINYETMAhxAMCg&s=mscgen>
> based on the *Individual to Individual* design pattern (also supported by
> Justin's comment above).
>
> Here's the source code for anyone to improve or fork.
>
> title Baseline HEART Sequence Diagram
>
> participant "Alice resource\nowner (RO)" as RO
> participant "NPE resource\nserver (RS)" as RS
> participant "Agent authorization\nserver (AS)" as AS
> participant "Bob client\napp (C)" as C
> participant "Bob requesting\nparty (RqP)" as RqP
> note over RO, RS, AS, C, RqP
> NPE = Non-Person Entity / This is the Individual-to-Individual Design
> Pattern
> end note
>
>
> RO->RS: Presents In Person
> RS->RO: Gets Credential
> RO->RS: Sign In to NPE Portal
> RS->RO: Display NPE ROI Form
> RO->RS: Specify Auth'z Server (AS)
> RO->RS: Text Resource Description
> RO->AS: Sign In to Agent Portal
>
> RS->AS: FHIR Resource Description
> AS->RO: Text Resource Description
> RO->AS: Confirm Authorization Policies
> AS->RS: Confirm\nResource Registration
> RS->AS: Consent Receipt
>
> note over RO, RS, AS
>  End of UMA Phase 1
> end note
>
> note over RS, AS, C, RqP
>  RqP discovers the resource via message or directory query
> end note
>
> RqP->AS: Presents Claims\ne.g. bob at medicalsociety.org
> AS->RqP: Gets Credential
> RqP->AS: Sign In to AS
> RqP->AS: May need to Register Client
> AS->C: Consent Receipt
> C->AS: Requests Authorization
> AS->C: Grants Authorization
>
> note over RS, AS, C, RqP
>  End of UMA Phase 2
> end note
>
> C->RS: Access FHIR Resource
> RS->AS: Accounting for Disclosure
>
> note over RS, AS, C, RqP
>  End of UMA Phase 3
> end note
>
> Adrian
>
>
>
> On Tue, Oct 20, 2015 at 11:30 AM, Glen Marshall [SRS] <gfm at securityrs.com>
> wrote:
>
>> For the individual-to-role pattern, HL7 has a role based access control
>> standard.  It includes and extensive vocabulary of healthcare roles, and it
>> is extensible.  This can be used to share access control role semantics
>> across authorization services.
>>
>> The individual-to-NPE and individual-to-role patterns presents some
>> interesting challenges.  One of them is that the mapping of access
>> permissions depends on the location and work assignments.  For example,
>> health care staff may be assigned to different care locations and have
>> legitimate access only to the patients' data for that location.  Similarly,
>> the role assigned to a person will vary.  I do not know how amenable these
>> cases are to technical solutions.  Current practice is to assume compliance
>> of the staff to institutional policies.
>>
>> What identifying data needs to be shared among users to access Alice's
>> [current] authorizations?  What is its provenance?
>>
>>
>> *Glen F. Marshall*
>> Consultant
>> Security Risk Solutions, Inc.
>> 698 Fishermans Bend
>> Mount Pleasant, SC 29464
>> Tel: (610) 644-2452
>> Mobile: (610) 613-3084
>> gfm at securityrs.com
>> www.SecurityRiskSolutions.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151020/b1d2e759/attachment.html>