[Openid-specs-heart] Comment on Section 2.1.3 of Health Relationship Trust Profile for OAuth 2.0

Mon Dec 7 20:29:50 UTC 2015

NPE-to-NPE data exchange can be in two-different use-cases depending on
whether the resource covers one patient or a bunch. If what we mean by
"bulk transfer" is a resource with multiple patients, then the risk and
liability profile for the RS is very different from NPE-to-NPE transfers of
single patient resources. The liability to mass hacking applies only to the
bulk case. The security of using a separate key to each patient's AS is
lost in the "bulk" case. The bulk case also is less likely to be able to
send notice to the patient that a transaction occurred. The patient can
provide a significant liability shield to the RS in the single patient cas
that's not available in the multi-patient case.

For all of these reasons, I suggest we stick to single patient resources in
HEART for now.

Adrian

On Mon, Dec 7, 2015 at 1:37 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> I'm skipping up and replying to this note vs. the deeper "public key"
> discussion below because I frankly don't "get" that part of the discussion.
>
> I suspect it would be a good idea to develop a couple of use cases that
> support *why* we are profiling bulk transfer types of flows. Agreed that
> they are "back-channel" flows, and if they take place in a context that is
> meant to be patient centric, then it would be important to understand the
> full end-to-end context. On the other hand, if we are profiling them just
> for completeness in something like pure provider-to-provider (NPE-to-NPE)
> contexts, we should be clear about that.
>
> I have no problem with using the technical OAuth and UMA terms as clearly
> defined in the relevant specs; we have "entity roles" subsections in our
> use case documents for that very purpose. I do like Adrian's higher-order
> roles (and other roles as required) also, because they add healthcare and
> real-life context (and that's why we have entity-to-role mappings in our
> use cases).
>
> BTW, I don't see why NPE-to-NPE data exchange can't happen in loosely
> coupled contexts. Protected Web APIs are often used in an "enterprise"/service
> account
> <https://developers.google.com/identity/protocols/OAuth2ServiceAccount>
> fashion across domains (and PKI certificates are often used for
> authentication in these cases...).
>
>
> *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 Thu, Dec 3, 2015 at 1:47 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> The direct access client is based on deployment experience with the RHEx
>> project and others, where organizations performed bulk data synch transfers
>> between each other. There is an extremely high degree of trust between
>> these organizations, and it’s not just “something form this organization
>> requested it” it’s actually “this specific piece of software requested this
>> specific set of things”. And it’s not on any one user’s authority, it’s a
>> contract that supersedes that. So there’s something that was signed in a
>> dark room someplace that says this transaction can take place within
>> certain parameters, and this is the technology to support that. It’s not up
>> to us to define what those contracts look like, but we can have a say on
>> how the technology is leveraged. Instead of leaving all of these groups to
>> come up with their own “private or internal” way to handle security, we
>> thought it better to give a standards-based mechanism that benefits from
>> much of the rest of the HEART profile updates.
>>
>>  — Justin
>>
>>
>> On Dec 3, 2015, at 12:32 PM, Dale Moberg <dale.moberg at orionhealth.com>
>> wrote:
>>
>>
>> Hi, with advance apologies for the holiday-induced delay to our editor.
>>
>> Section 2.0 introduces three Client Profiles Types in sections 2.1.1 +
>> 2.1.2 and section 2.1.3. I agree with others in the group that the Client
>> Profile types do present “vanilla” profiles for three of the now five
>> specified OAuth2 token grant types (found in RFCs 6749 7521).
>> The Full Client and Browser Embedded clients with User delegation are
>> certain to be of value in healthcare (and for the OAuth2-protected security
>> services of UMA and OpenId Connect).
>>
>>
>> I do, however, have concerns about any inter-organizational uses of the
>> Direct Access Client type in healthcare that I wish to present next. I
>> would advocate deferring implementation of the Direct Access client type
>> until more is agreed upon the intended usage of this pattern. If the only
>> real usage is for “internal” bulk downloads, then organizations are free to
>> accomplish downloads in several ways, including a Direct Access client
>> pattern if they wish. Internal usage can proceed without standards that
>> support interoperability; private or proprietary solutions could suffice.
>> But, if the pattern is implemented for inter-organizational  data sharing,
>> the Direct Access client type has several  deficiencies.
>>
>>
>> OAuth2 Full Client types allow a “resource owner” to delegate access to a
>> Client application. While our group often is thinking about important
>> healthcare use cases where resource owners and resource sets map,
>> respectively, to patients and their medical records, nothing requires
>> restricting the pattern in this way. For example, a physician might be a
>> resource owner (and be entitled to both read and delegate access) to all of
>> his patient records to others involved in patient care, by referrals or
>> other processes. What counts semantically in “owner” is that an end user
>> has a userid and password that, in combination with a registered client and
>> its secret is granted access to a set of resources.
>>
>>
>> So it could be that for a given resource set, there are multiple owners
>> (accessors) able to present credentials and ids and delegate access to a
>> resource set to registered clients presenting their credentials. Or there
>> could be one owner. Bank accounts, facebook pages, google docs – all
>> exhibit their own distinctive requirements for privacy and sharing, and it
>> is at a policy level that these requirements get mulled over and policies
>> get thrashed out.
>>
>>
>> As a mechanism of requesting and granting or refusing access, the Direct
>> Client type does not mesh well with interorganizational access requests
>> because of some specifics about the healthcare domain.
>>
>>
>> First, direct access clients are not to be dynamically registered
>> (according to our profile) -- which is very sensible.
>>
>>
>> So registration must be for a client that “on its own” is trusted with
>> resources.  Now suppose that the resource pool (the set of all resource
>> sets) exposes an API that is to support Direct Access Clients. And suppose
>> that the Client is not in the security domain of the resource or
>> authorization servers. Clearly there needs to be considerable trust
>> extended to allow registration of such a client. Because once registered,
>> the access authorization check—no matter what resource is requested-- can
>> only be based on the client_id and the accompanying client_secret. On this
>> basis, a JWT (access token) is issued – containing no more specific or
>> granular information about the requester  than its organizational
>> identity;  the resource server can check the JWT, is signature and make a
>> call to an introspection service. But the authorization service, once
>> trusted, has said access is permitted, no matter what the resource happened
>> to be, provided the client id and secret are OK.
>>
>>
>> Now conceivably there are organizations with data to be shared that could
>> leverage organizational identity as a basis for data sharing. A producer of
>> goods might request access to a data base to see all goods purchased by a
>> retailer, and based on which organization is requesting, disallow a
>> producer from seeing how much the retailer had purchased from a competing
>> producer, but still see its own products that had been purchased.But
>> healthcare data sharing is governed by privacy regulations that reflect
>> such challenges as “who’s asking?” “what is their role?" and “what’s
>> your need to know with respect to healthcare provision?” Depending on the
>> answers to these questions, tied to the identity and role(s) of the
>> requesters and their healthcare relevant relationships to the
>> patients/customers, access is granted. The problem with the Direct Access
>> client is that the information needed to check the policy is not provided
>> in the request. A significant side effect would be that no audit trail
>> could be produced to document who got the information and in what capacity
>> and circumstances the information is to be used.
>>
>>
>> The problem is that the requesting organization has the relevant
>> information about the user(s), role(s) and relationships to the patients
>> but it is not information available in the registration, in the access
>> request, or as an intrinsic part of the client-credentials-only flow used
>> in the Direct Access Client type.  The inter-organizational trust/access
>> problem can be succinctly described by noting that we expect the
>> authorization/resource organization to be able to consult the same
>> information about the Direct Access client access request approval
>> identities, roles, and relationships as is used for an internal system
>> request. And the Direct Client pattern lacks specification of ways that the
>> information, or an explanation of how to obtain the information, that is
>> needed for checking that typical healthcare policies apply.
>>
>> If implementers think that the Direct Access Client support would be
>> important to offer “inside the four walls” -- to use one of our expert’s
>> vivid phrase — then I suppose the profile could be released with that
>> understanding of its intended application range. I would urge the
>> committee to consider very carefully whether they are sufficiently
>> comfortable with the
>> inter-organizational/inter-regional/inter-security-domain security issues
>> to recommend implementation for that context of use.
>>
>> Dale Moberg
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151207/e1b0a89f/attachment.html>