[Openid-specs-heart] Comment on Section 2.1.3 of Health Relationship Trust Profile for OAuth 2.0
Justin Richer
jricher at mit.edu
Fri Dec 4 03:02:12 UTC 2015
>> So, I still say that nothing you're saying makes any sense to me.
> Is that still the case?
Yes, it's still the case. If everything you say below is true, then what
problem do you have with the current drafts? It sounds like they already
do everything you want, which I think has always been the case. And
they're very clear about this functionality as well. What's the problem?
What's missing? Why even bring it up and have an enormous argument about
it when in the end the answer is "the spec says this >> Oh that's perfect!"?
-- Justin
On 12/3/2015 9:19 PM, Adrian Gropper wrote:
> inline really this time...
>
> On Thu, Dec 3, 2015 at 8:59 PM, Adrian Gropper <agropper at healthurl.com
> <mailto:agropper at healthurl.com>> wrote:
>
> inline...
>
> On Thu, Dec 3, 2015 at 6:54 PM, Justin Richer <jricher at mit.edu
> <mailto: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.
>
>
> That's perfect! That's exactly what I want to be clear about. The safe
> harbor comes from the AS taking responsibility for protecting and
> using its private key. The AS is the agent of the patient regardless
> of how many clients or resource servers the AS deals with as the
> patient's agent.
>
> In the case that the AS is the agent for multiple patients, it would
> be up to the AS to decide if to use the same or different keypairs for
> each patient. As I understand the profiles, the RS and clients should
> not have any say in that decision.
>
>
> 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.
>
>
> That's perfect too. We're in complete agreement. I just want to
> document this as well as possible for all the folks in HEART and HL7
> and HHS.
>
>
> 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.
>
>
> I'm not sure what you're trying to say. As long as only the AS has the
> private key, and the protocol works the RS is protected. Eventually
> this will be up to the folks at OCR and it's also up in Josh's API
> Task Force. This is not HEART's or FHIR's problem. All we can do is
> spec the protocol to enable the safe harbor. Whether the safe harbor
> is law is going to be up to OCR.
>
>
> 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.
>
>
> I agree that auditability will be important for the safe harbor. Under
> Agency Law
> https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement(third)Agency.pdf
> <https://users.wfu.edu/palmitar/ICBCorporations-Companion/Conexus/UniformActs/Restatement%28third%29Agency.pdf>
> the RS will need to show that it is acting "in good faith" and it will
> need to provide "notice" to the RO (maybe via the AS) if it decides to
> ignore or override the outcome of the token introspection process.
> Auditability is all about the RS proving that it acted in good faith
> and provided appropriate notice.
>
> I agree that this need not be part of our current work. For the time
> being, we are just laying the foundation for the safe harbor to be
> possible. Auditability need not be standardized and profiled but it
> certainly could add value if it is.
>
>
> So, I still say that nothing you're saying makes any sense to me.
>
>
> Is that still the case?
>
> Adrian
>
>
> -- 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 <mailto: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 <mailto: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
>>> <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
>>>
>>>
>>>
>>>
>>> --
>>>
>>> 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
>>> <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/
>
>
>
>
> --
>
> 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/07c71a07/attachment-0001.html>
More information about the Openid-specs-heart
mailing list