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

Fri Dec 4 01:59:56 UTC 2015

inline...

On Thu, Dec 3, 2015 at 6:54 PM, Justin Richer <jricher at mit.edu> wrote:

> I'm not sure that key is used for what you think it's used for. That
> public key is the public key *of the AS *and it is likely a single key
> for all clients and protected resources. The tokens are signed with this
> key but the transactions/requests/resources are not. Only the AS can prove
> possession of this key, which is kinda the point: only the AS can mint
> tokens from the AS. The RS does not establish this key. The RS does not
> have the private key for this public key. Nor does the client. Each AS will
> have its own key, which is published at its own URL. These keys will be
> there regardless of what kinds of clients or RS's are attached to the AS.
>
> Technically you could use a different key to sign every access token that
> you put out, but what does that buy you? I can see no benefit of doing that
> since every RS will validate the signature separately, if it does so at
> all. The RS can ignore the signature on this token and use introspection to
> validate it at runtime. After all, in many circumstances and deployments, a
> self-contained token should not be enough. The client ignores it entirely
> and just passes the token through opaquely.
>
> The kind of legal protection you're talking about has nothing to do with
> public keys or signatures. An evil client will only have access to whatever
> it was delegated by nature of the AS being the only entity in the system
> capable of minting tokens that the RS will accept. This is OAuth 101 and
> has nothing to do with the format of the token or the server's possession
> of a keypair. As stated above, the RS can verify the token without any
> knowledge of the key and signature.
>
> What the legal question does have to do with is auditability of the
> transaction. That's where the conversation on auditable transaction
> receipts came in at IIW this year, and that's something that can (and
> should) be built on top of all of this as a separate layer. That is not
> part of this current work.
>
> So, I still say that nothing you're saying makes any sense to me.
>
>  -- Justin
>
>
> On 12/3/2015 6:12 PM, Adrian Gropper wrote:
>
> The public key I'm talking about is (*emphasis added*)
> 4.1.
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#rfc.section.4.1>
> Discovery
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#Discovery>
>
> The authorization server MUST provide an OpenID Connect service discovery
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#OpenID.Discovery>
> [OpenID.Discovery] endpoint listing the components relevant to the OAuth
> protocol:
> issuer The fully qualified issuer URL of the server authorization_endpoint The
> fully qualified URL of the server's authorization endpoint defined by OAuth
> 2.0 <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC6749>
> [RFC6749] token_endpoint The fully qualified URL of the server's token
> endpoint defined by OAuth 2.0
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC6749>
> [RFC6749] introspection_endpoint The fully qualified URL of the server's
> introspection endpoint defined by OAuth Token Introspection
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7662>
> [RFC7662] revocation_endpoint The fully qualified URL of the server's
> revocation endpoint defined by OAuth 2.0 Token Revocation
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7009>
> [RFC7009] jwks_uri The fully qualified URI of *the server's public key*
> in JWK Set
> <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html#RFC7517>
> [RFC7517] format I never mentioned encryption. I understand that all of
> the encryption in HEART is done by the SSL certificates that every server
> (RS and AS) has to have.
>
> What I'm trying to make clear, is that each HEART protected resource,
> regardless of who specifies the AS and what kind of client is seeking
> access can have its own separate public key that is provided by the AS as
> part of 4.1 above. Is this statement consistent with the three HEART
> profiles as proposed?
>
> The reason that I'm being a stickler on this point is a liability issue
> from the resource server's perspective. I want to make sure that the RS can
> claim a legal safe harbor for breach of a protected resource as long as it
> can show that only that AS, as specified in 4.1 above, could have delegated
> access to whatever client shows up asking for the resource. An unverified
> and evil client, for example, should have access to only one patient
> regardless of how evil it is. This puts the burden of client and RqP
> verification completely on the shoulders of the AS that is doing the
> resource registration dance 4.1. Hence the "safe harbor" when the RS can
> prove that the RO specified the AS.
>
> PS: This has nothing to do with the RHEx situation where the RS was
> expected to take responsibility for registration of the client and
> authentication of the RqP. The RS was on the hook for a lot more in RHEx.
> The RS is also on the hook for a lot more when the RS specifies the AS, as
> it can in OAuth.
>
> Adrian
>
> On Thu, Dec 3, 2015 at 4:48 PM, Justin Richer <jricher at mit.edu> wrote:
>
>> Adrian,
>>
>> I’m still not sure where you’re getting public keys from. It sounds like
>> you’re proposing a completely different technology stack which, as far as
>> I’m aware, doesn’t exist.
>>
>>  — Justin
>>
>> On Dec 3, 2015, at 4:05 PM, Adrian Gropper <agropper at healthurl.com>
>> wrote:
>>
>> Thanks Dale for raising this important issue. One of the problems is that
>> the term "resource owner" is overloaded and that makes the discussion of
>> OAuth vs. UMA unnecessarily complex. The point you are raising is directly
>> related to the ONC API Task Force that was just created and guidance that
>> might be issued by OCR on the patient right of access to the MU3 API.
>>
>> Resource owner is confusing in HEART because it could be:
>> - the Resource Subject (the person, including a child or a disabled
>> elder) that a FHIR resource pertains to
>> - the Resource Delegate (the person that has access to technology and the
>> (legal) right to manage a FHIR resource
>> - the Resource Custodian, that has the right to delete the resource and
>> is typically responsible for protecting access. This is typically a HIPAA
>> covered entity such as the hospital, lab, or insurance co that exposes a
>> FHIR resource pertaining to a single subject.
>>
>> Section 2 of the HEART OAuth 2.0 Profile
>> http://openid.bitbucket.org/HEART/openid-heart-oauth2.html is confusing
>> in this respect and it makes the transition to the HEART UMA Profile
>> http://openid.bitbucket.org/HEART/openid-heart-uma.html particularly
>> difficult.
>>
>> The majority of my comments around these drafts have to do with this
>> overloading of the "resource owner" term. The HEART "delegation" use-case
>> is partly designed to resolve this ambiguity. This is also why I suggest
>> that for both security and interoperability UMA is easier to profile than
>> OAuth.
>>
>> The HEART profiles do not need to deal with multi-subject bulk transfers,
>> transfers from Alice to Alice, and resources that pertain to multiple
>> subjects such as a patient list. These can be done in other ways or can be
>> added to HEART later. In order to inform the MU3 API requirement, and to
>> allow a broad interpretation of "patient right of access" with security
>> safe harbors for the HIPAA CE, the HEART profiles must allow the
>> Authorization Server to register clients and authenticate requesting
>> parties without any blocking by the resource server. This is achievable
>> when every resource can be protected by a separate public key link that is
>> provided by the AS at resource registration time. I believe that the
>> current profiles allow for this during dynamic registration of the AS, but
>> I certainly think it could be clearer.
>>
>> Adrian
>>
>> On Thu, Dec 3, 2015 at 12:32 PM, Dale Moberg <
>> <dale.moberg at orionhealth.com>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
>>>
>>>
>>
>>
>> --
>>
>> 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
>>
>>
>>
>
>
> --
>
> 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/
>
>
>

-- 

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/20151203/8264f514/attachment.html>