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

[Eve Maler]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151207/0b4ea68d/attachment.html>