[Openid-specs-heart] Comment on Section 2.1.3 of Health Relationship Trust Profile for OAuth 2.0
Glen Marshall [SRS]
gfm at securityrs.com
Mon Dec 7 21:05:41 UTC 2015
I am concerned about this discussion thread re: risk and just technical
mitigations. In a business evaluation we would see an analysis of the
actual risk $ value versus the cost of various mitigations - technical,
administrative, transfer of risk via insurance, etc. A choice of an
intricate technical solution may be more costly than other choices.
Perhaps we can filter-out complex cases and focus on those in which a
technical mitigation would be an more-or-less obvious best choice.
*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
On 12/7/15 15:29, Adrian Gropper wrote:
> 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
> <mailto: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 <tel:%2B1%20425.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
> <mailto: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
>> <mailto: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
>> <mailto: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
> <mailto: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
> <mailto: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/
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151207/eb6e625f/attachment.html>
More information about the Openid-specs-heart
mailing list