[Openid-specs-heart] "Scope" of sharing and purpose of use

Justin Richer jricher at mit.edu
Mon Dec 14 21:00:59 UTC 2015


This is the semantic OAuth profile. There is only one Authorization Server for this profile.

 — Justin


> On Dec 14, 2015, at 11:56 AM, Adrian Gropper <agropper at healthurl.com> wrote:
> 
> Does the "user" scope require all of the patient-level resources to share the same Authorization Server?
> 
> If so, then "user" seems to break the assumption that, with UMA, the resource owner gets to choose her Authorization Server. If not, then the "user" use-case is what I call a "discovery" use-case and should be a completely separate resource from the ones that are "patient" scoped.
> 
> Adrian
> 
> On Mon, Dec 14, 2015 at 11:22 AM, Justin Richer <jricher at mit.edu <mailto:jricher at mit.edu>> wrote:
> “Permission Type” is really a whole lot simpler than people are making it out to be. 
> 
> 
> “patient” means “get me a single specific record for a single specific person”. When there is no other indicator (the “aud” parameter) this is the record for the currently logged in person. This is going to be a common enough use case, and it’s the default OAuth case, that optimizing for this makes sense. 
> 
> “user” means “get me all of the records that I have access to”. There is no record indicator here in the query because it’s basically a get-all-the-stuff type of request. What matches might be a single record. It might be many records. It might be aggregate data. But it’s not a query for a specific record when this permission type is used.
> 
> 
> 
> Both of these can be in cases where Alice has user-to-user delegated access to her family members. For the “patient” scope with no “aud” parameter, the token is good for Alice’s record. For the “patient” scope with an “aud” parameter, the token is good for the record indicated by that aud parameter. But just that one specific record! Using this token to get other records will fail. For the “user” scope it’s a request for all records Alice has access to. She can’t specify which one, since that’s not what this kind of scope is for.
> 
> 
>  — Justin
> 
> 
>> On Dec 13, 2015, at 11:10 PM, Aaron Seib <aaron.seib at nate-trust.org <mailto:aaron.seib at nate-trust.org>> wrote:
>> 
>> I still don’t think I am 100% on what Discovery means in this context. <>
>>  
>> Here is the def you provided:
>>  
>> Discovery means: the user(1) doesn't know who will be on the list. That puts a lot of responsibility on the RS to do the right thing(2). In HIEs for example, they insist the user is a practicing physician because they want to reduce their liability if someone's name pops up on a list that the user should not have seen.
>> 
>>  
>> (1)    Who is the user?  I am still looking to the Permission Type <http://openid.bitbucket.org/HEART/openid-heart-fhir-oauth2.html#rfc.section.2.1> to see if I can get that set of terms to line up in my head.  Patient was a permission type which in the health domain correlates to the patient who is the subject of the PHI that the Resource Server may be disclosing.  The assumption being that we can match the identity of the person who is using a client application to connect to the resource server  (owned by the institution that operates the Resource Server – in the API TF scope the typical example being a EMR used by the caregiver that the patient has had treatment) with the Medical Record Number (MRN) or equivalent in the Resource Servers enterprise context (I don’t see any reason why we can’t say that an HIE with an MPI might be able to simplify this by correlating the MPI values to the person who is using the client app to access data about themselves across Resource Servers that have data about that person “Patient”).
>> 
>> (2)    Do the Right Thing -
>> 
>>  
>> Sorry for all the verbiage – I want to get my meager understanding spelt out so it can be corrected.  This may not be fruitful but it occurs to me that something that isn’t apparent that is becoming more apparent to me as I wrestle with this is that the idea of User may be better understood as a set of several or more sub-categories.
>> user
>> The scope is for a bulk set of records (I am assuming that it is implied here that set of records is meant to convey data for more than one person – the notion of a record is not clear to me here I must admit)  or for aggregate data not representing a single patient (is this meant to be a distinction or a reiteration of the bulk set of records?  What is the difference?), based on what is available to the current user (here is where the turn of phrase seems to be slipping.  I am still struggling with the some notion being conveyed here.
>>  
>> The question that comes to mind is if we look at the set of records being made available ‘to the current user’ is that person’s record one of those found in the set of records?  There seem to be a couple of distinctions that are probably implied but might help to make explicit.  At a minimum there are two cases that come to mind:
>> (1)  The case where the ‘Current User’ may have a record in the set being returned and any other person’s record being disclosed is permitted because that other person granted the User permission.
>> (2)  The case where the ‘Current User’ does not have a record in the current set and is accessing them as a result of capacity being vested in them by the Record owner, because of their professional role.
>>  
>> I am not sure if there is a more precise way to look at it but it would seem to be that the root difference has something to do with how the User got the permission.  It may not be evident I am seeing the difference being based on how the user got the permission.  In case (1) I think of the person as a family care giver who has access to other ‘family’ members records because they granted that to him\her to have access and it is not in the role of providing treatment as traditionally defined by HIPAA.  In the (2) case I see it being derived based on the fact that the person is in a Treatment role as defined by HIPAA and the Record Owner (i.e., the Hospital et al) gives them permission to access certain records.
>> 
>>  
>> I think the key to unraveling this not is to differentiate between users who are not acting in a professional capacity from those that are as the applicable authorization to disclose is derived from two separate authorities.  In Case (1) the User is getting permission to access those other records because the patients whom the records are about gave him\her permision as they may given their right to share with whomever they please while under case (2) they are getting permission as an aspect of their professional requirements as warranted by the resource owner.
>> 
>>  
>> Not sure if this is half baked or not but there if there is a fly in the ointment it seems to me that it has to do with what John referred to as purpose of use earlier on.  Assume that the User in case 2 has a purpose of use to be treatment and I think it is easier to digest.  The word to use for the Consumer’s purpose of use alludes me right now. 
>> 
>>  
>> I think the unifying issue is that the user’s purpose of use must be the same for all the records being retrieved. 
>> 
>>  
>> I think that is the issue with Discovery that is hard to get a grasp on. 
>> 
>>  
>> If an HIE is granting permission to a Requesting party (why do we use the word User rather then requeting party here?) for a set of records it should only be for one or the other purpose of use and the purpose of use must match the part being played for the transaction being responded to by the RS as known to the RO. 
>> 
>>  
>> Aaron Seib
>> NATE <http://www.nate-trust.org/>, CEO
>> @CaptBlueButton
>> (o) 301-540-2311 <tel:301-540-2311>
>> (m) 301-326-6843 <tel:301-326-6843>
>>  
>>  
>> From: agropper at gmail.com <mailto:agropper at gmail.com> [mailto:agropper at gmail.com <mailto:agropper at gmail.com>] On Behalf Of Adrian Gropper
>> Sent: Friday, December 11, 2015 5:29 PM
>> To: Aaron Seib
>> Cc: openid-specs-heart at lists.openid.net <mailto:openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>>  
>> Hi Aaron, Thanks for highlighting the important issue of discovery.
>> 
>> Discovery means: the user doesn't know who will be on the list. That puts a lot of responsibility on the RS to do the right thing. In HIEs for example, they insist the user is a practicing physician because they want to reduce their liability if someone's name pops up on a list that the user should not have seen.
>> 
>> I meant RO (resource owner), It makes no sense for the RS to send a notice to themselves.
>> 
>> Yes, RqP is the Requesting Party which is the party that controls the Client that is accessing the AS and the RS. The RqP might be the patient subject (the RO) themselves using an app or PHR but that case would be handled by OAuth. (We call that the Alice-to-Alice case). UMA is interesting because it allows the RqP user to be someone other than Alice therefore enabling true health information exchange. This is what makes HEART so useful and our HEART Profiles so important.
>> 
>> Adrian
>>  
>> On Fri, Dec 11, 2015 at 4:53 PM, Aaron Seib <aaron.seib at nate-trust.org <mailto:aaron.seib at nate-trust.org>> wrote:
>> Hi – I meant to ask you last week.  When you say Discovery in the first bullet I am not sure I know what you mean.  Can you expand on that for me?  I think I get everything except that below.
>> 
>>  
>> 
>> I don’t know why we are trying to be so cryptic on the work group.  This is unfortunate. 
>> 
>>  
>> 
>> You use RO below and I think it might be a typo but have to confirm.  Is it meant to have been something else?
>> 
>>  
>> 
>> What is RqP an abbreviation of? Requesting Party?
>> 
>>  
>> 
>> From: Openid-specs-heart [mailto:openid-specs-heart-bounces at lists.openid.net <mailto:openid-specs-heart-bounces at lists.openid.net>] On Behalf Of Adrian Gropper
>> Sent: Friday, December 11, 2015 3:37 PM
>> To: Moehrke, John (GE Healthcare)
>> Cc: openid-specs-heart at lists.openid.net <mailto:openid-specs-heart at lists.openid.net>
>> Subject: Re: [Openid-specs-heart] "Scope" of sharing and purpose of use
>> 
>>  
>> 
>> Let me attempt at mediation :-)
>> 
>> - We're talking about resources that have a single subject (the patient) Resources with more than one subject, such as a patient list are a completely different matter because they involve discovery (I don’t get this?  Discovery of what?  The identity of each person in the list?). The special case of a mom with 2 kids can simply, if inelegantly, be handled by polling for each of the subjects. There's no discovery involved.
>> 
>> - The major difference between OAuth and UMA is that in UMA the resource is under the control of a separate legal entity. Therefore, when a client (and the client's user) shows up to request the resource, the client may present claims or attributes to either or both the resource server (RS) and/or the authorization server (AS). To say this another way: In UMA there's some kind of legal agreement between the resource server and the authorization server. In OAuth there is none because they are the same.
>> 
>> - The sharing of control between the RS and the AS is subject to institutional, local, and federal controls. All of the situations that John listed boil down to "good faith" and "notice" to the RO when the resource server acts on the instructions of the AS based on the actual attributes of the client (C) by client attributes do you mean attributes of MSHV or of the User of MSHV, Aaron Seib? and the client's user (RqP – this is Aaron Seib, right?  What does RqP stand for?).
>> 
>> Adrian
>> 
>>  
>> 
>> On Fri, Dec 11, 2015 at 3:01 PM, Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com <mailto:John.Moehrke at med.ge.com>> wrote:
>> 
>> Hi Eve,
>> 
>>  
>> 
>> It is clear that there is a communications problem between those that  are comfortable in the language of speaking about OAuth/UMA, and those that are comfortable in the language of speaking about Healthcare Access Control needs.  I can read every word you have said, but I have no idea what you said.
>> 
>>  
>> 
>> I think one of our problems is that we keep skipping from use-cases where the “user” is the “patient” trying to access their own data; and use-cases where the “user” is a clinician trying to help the “patient”. There are many MORE use-cases including parents, children, guardians. There are many MORE use-cases around researchers, public-health, billing, payers. And there are a huge variety of all of these. There are authorization mechanisms that stem from direct authorization by the patient, to indirect because of context, and the ultimate for healthcare ‘because their life is in jeopardy and I am a licensed clinician that can save their life’. Followed by many medical-ethical traps like having a personal discussion about a particularly tragic test result before the lab fact is directly exposed.
>> 
>>  
>> 
>> We need to solve all of these, however to solve any one would be helpful.
>> 
>>  
>> 
>> John
>> 
>>  
>> 
>> From: Eve Maler [mailto:eve.maler at forgerock.com <mailto:eve.maler at forgerock.com>] 
>> Sent: Friday, December 11, 2015 11:43 AM
>> To: Moehrke, John (GE Healthcare)
>> Cc: openid-specs-heart at lists.openid.net <mailto:openid-specs-heart at lists.openid.net>
>> Subject: "Scope" of sharing and purpose of use
>> 
>>  
>> 
>> Hi John-- (I changed the subject line and deleted older parts of the thread.)
>> 
>>  
>> 
>> When you say "scope" here, I suspect you mean "scope" of the sharing use case, rather than something like an OAuth or UMA scope, so I'm just checking. So a "single-patient scope" means that the only human we're paying attention to in the use case is the patient, and "any application with users that are authorized to multiple patients" seems to mean a use case that involves party-to-party sharing, with multiple humans involved. However, you follow the latter with "would need to get multiple scopes", so I'm not sure. Note that "getting multiple scopes" as a technical construct doesn't have anything to do with sharing with an autonomous third party.
>> 
>>  
>> 
>> FWIW, here is how I think, at a high level, about configuring the delegation of rights to access resources. It's all about parts of speech.
>> 
>>  
>> 
>> OAuth lets a user (patient) do this configuration at run time while using a client app, by opting in to the authorization server's issuance of an access token to that app. By contrast, UMA lets a user (patient) do this configuration anytime, generally by instructing the authorization server to check whether some combination of the client app and the requesting party using the app meet various requirements (policy). So OAuth is kind of an attenuated version of UMA wrt the constraints on delegation of access rights.
>> 
>>  
>> 
>> system          subject          verb             object                adjective
>> 
>> OAuth                client ID             OAuth scopes          (implicitly some endpoints)  n/a
>> 
>>                      (and always Alice)
>> 
>> UMA                  claims-based eg Bob,  UMA scopes over...    UMA resource sets            claims-based e.g. TPO,
>> 
>>                      client ID/type, etc.                                                     time limitations, etc.
>> 
>>  
>> 
>> It's possible to conflate purpose-of-use into the UMA scopes system, but it's as awkward as conflating (ordinarily implicit) resource sets into the OAuth scopes system (resource1.read, resource1.write, etc.), which is why OAuth has invented the audience parameter to try and solve the problem of a single authorization server protecting several APIs. This is why I suggest using a claims-based system above.
>> 
>> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=BWKe_zUfK7VyJCEdTSN-5cG7TelP0b1X-x3kyeaODmk&e=> community!
>>  
>> 
>> On Mon, Dec 7, 2015 at 2:00 PM, Moehrke, John (GE Healthcare) <John.Moehrke at med.ge.com <mailto:John.Moehrke at med.ge.com>> wrote:
>> 
>> The discussion on the call today was too hard to break into. Even for a big mouth like me.
>> 
>>  
>> 
>> I am okay with limiting our next couple of profiles to single patient scopes. As much of the email discussion has pointed out patient controlled access is our primary scope, and logically (if not  technically) this  is easy to understand with scopes that are single patient.
>> 
>>  
>> 
>> Yes this means that any application with users that are authorized to multiple patients would need to get multiple scopes; so be it. For now…  For Enterprise use, this is troubling; but for most uses that happen from outside of an enterprise or between enterprises this limitation is not unreasonable. The most common APIs in healthcare for this are already patient centric. So it is not a big problem.
>> 
>>  
>> 
>> The user experience does not need to be impacted by this profiled limitation
>> 
>>  
>> 
>> The future does not need to be impacted by this profiled limitation.
>> 
>>  
>> 
>> Which means that one viewpoint for scope can be the identity of the patient that one is asking for access to. This is not the only scope we will ever support; but is one method that would satisfy some use-cases today.
>> 
>>  
>> 
>> Another view on scope, that I have been involved with in other groups, is to use a high-level vocabulary that is used often in the Access Control policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment, Research, Emergency, etc…
>> 
>>  
>> 
>> To go deeper than these two vectors through scopes in a general purpose healthcare access control infrastructure is futile.
>> 
>> Next level deeper in scopes would come from workflow centric implementation guides. That is a specification that is defining a workflow, could define a scope(s) for that workflow.
>> 
>>  
>> 
>> John
>> 
>>  
>> 
>> _______________________________________________
>> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=b-IeKH8ALrT6jaP_pgYHavTt27UVQVYtlz9y5w5CRak&e=>
>>  
>> 
>> 
>> _______________________________________________
>> 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 <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/ <http://patientprivacyrights.org/donate-2/>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com/>
>> Version: 2016.0.7294 / Virus Database: 4483/11158 - Release Date: 12/11/15
>> 
>> 
>> 
>> 
>> --
>>  
>> 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/ <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 <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/ <http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151214/cadb355e/attachment-0001.html>


More information about the Openid-specs-heart mailing list