- WG-UMA - mailman.kantarainitiative.org

Re: [WG-UMA] [Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem
by Adrian Gropper 25 Jan '16

25 Jan '16

(apologies for cross-posting) Thanks, Josh. As always, you are able to explain the issue much better than me. This is why I've tried my best to understand the gaps between UMA as it is today and something that lays cliaim to user-managed access. FHIR and UMA and, consequently, HEART are all new and we need to be very clear about how we design this next generation of protocols. In the UMA legal subgroup, we've tried to map UMA into "Agency Law", the relatively simple branch of law that dictates how an individual (patient) can specify an agent (as in lawyer, accountant, or doctor) to act on their behalf. Suffice it to say, that agency law does not assume that an agent will have any conflict of interest in the baseline case but that conflicts of interest can arise in the real world (for example when a broker is put in an agency role). It's up to all of us, FHIR, UMA, and HEART, to develop around the requirement for agency on the part of the individual. We can layer on all sorts of other complexities to deal with brokerage and jurisdictional issues, but if we don't start with clear personal agency in the Authorization Server, then we will keep chasing the increased complexity and insecurity of our networks for another 10 years. Adrian On Monday, January 25, 2016, Josh Mandel < Joshua.Mandel(a)childrens.harvard.edu> wrote: > That's illuminating, at least. It sounds like you're interested in > changing the underlying protocol (i.e. effectively designing something new > instead of UMA). There's nothing wrong with that, but making these changes > implicitly and then calling the new thing "UMA" is exacerbating the > confusion on this list. > > Also, I can't help responding to the following comment that you made on #5: > >> You're mixing up the identity of an authorization service with the >> identity of a user or persona. > > > -- that's exactly correct! Using the AS's public key to identify the user > would be mixing up the identity of the AS with the user. That's exactly why > I'm saying you *cannot equate* them. So perhaps we agree on this point at > least :-) > > -J > > On Mon, Jan 25, 2016 at 11:56 AM, Adrian Gropper <agropper(a)healthurl.com > <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: > >> >> >> On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel < >> Joshua.Mandel(a)childrens.harvard.edu >> <javascript:_e(%7B%7D,'cvml','Joshua.Mandel(a)childrens.harvard.edu');>> >> wrote: >> >>> Adrian, I'm afraid we're talking past one another here. Let me try to >>> spell out the logic and see if you follow and agree with each step: >>> >>> 1. UMA allows a user to stand up her own Authorization Server >>> >> Yes >> >>> 2. UMA does not require a user to stand up her own Authorization Server >>> >> I don't know. It may be that's the only way for an UMA-like approach to >> privacy and security to scale. >> >>> 3. Given #2, an UMA-based protocol cannot assume that every user will >>> stand up her own Authorization Server >>> >> Why not? Can't a service host an arbitrary number of AS? >> >>> 4. Given #3, an UMA-based protocol must assume that some Authorization >>> Servers will work on behalf of multiple users >>> >> That depends on how we choose to define Authorization Server. >> >>> 5. Given #4, an UMA-based protocol cannot equate an Authorization >>> Server's identity with a user's identity >>> >> You're mixing up the identity of an authorization service with the >> identity of a user or persona. >> >>> 6. Given #5, an UMA-based protocol cannot use an Authorization Servers >>> public key to identify a user. >>> >> It's all in how we define Authorization Server, isn't it? >> >> Adrian >> >>> >>> Is there a point at which you disagree? >>> >>> -J >>> >>> On Mon, Jan 25, 2016 at 11:40 AM, Adrian Gropper <agropper(a)healthurl.com >>> <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: >>> >>>> No, I'm not saying anything about how the public key associated with a >>>> persona is used for encrypting messages to the client. The use of a public >>>> key the way to identify a persona or account is already well established in >>>> blockchain and is completely compatible with a personal owned AS. That's >>>> all I'm saying. >>>> >>>> The use of whatever keys or tokens will be used in messaging between >>>> the RS and the Client is up to the "security folk" Justin refers to. Are >>>> the security folk saying that having a personal persona AS is impossible? >>>> >>>> Adrian >>>> >>>> On Mon, Jan 25, 2016 at 11:34 AM, Josh Mandel < >>>> Joshua.Mandel(a)childrens.harvard.edu >>>> <javascript:_e(%7B%7D,'cvml','Joshua.Mandel(a)childrens.harvard.edu');>> >>>> wrote: >>>> >>>>> In UMA, the RS does indeed learn the AS's public key (by asking the >>>>> AS). But the public key is not used in the way you seem to want (namely, >>>>> it's not used to encrypt any patient data). It sounds to me like you're >>>>> focusing on an implementation detail (the fact that the AS happens to have >>>>> a public key associated with it), and extrapolating to some unfounded >>>>> conclusions (that this forms the basis for encrypting patient data with a >>>>> patient-specific key) from that detail. >>>>> >>>>> -J >>>>> >>>>> On Mon, Jan 25, 2016 at 11:26 AM, Adrian Gropper < >>>>> agropper(a)healthurl.com >>>>> <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: >>>>> >>>>>> Justin, >>>>>> >>>>>> All I'm saying is that each patient persona gets to have a private >>>>>> key and that key is kept safe in their AS - period. >>>>>> >>>>>> Let's start with that, and then the security folks can tell us how >>>>>> the RS gets the Client's public key. Can't UMA do that? >>>>>> >>>>>> Adrian >>>>>> >>>>>> On Mon, Jan 25, 2016 at 11:02 AM, Justin Richer <jricher(a)mit.edu >>>>>> <javascript:_e(%7B%7D,'cvml','jricher(a)mit.edu');>> wrote: >>>>>> >>>>>>> The way encryption is handled between the RS and the Client does not >>>>>>> follow from the right to choose an AS and has nothing to do with the AS’s >>>>>>> JWK. Think about it this way: how would the client get the AS’s private key >>>>>>> to decrypt the message? >>>>>>> >>>>>>> — Justin >>>>>>> >>>>>>> On Jan 25, 2016, at 10:52 AM, Adrian Gropper <agropper(a)healthurl.com >>>>>>> <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: >>>>>>> >>>>>>> I think we're mostly all on the same wavelength. The first priority >>>>>>> is to bake the right to control one's own AS and the corresponding jwk into >>>>>>> FHIR and HEART. This should be easy to reach consensus on given recent OCR >>>>>>> guidance that includes the "right to delegate access to a third party". >>>>>>> >>>>>>> The way encryption is handled between the RS and Client follows from >>>>>>> the above. >>>>>>> >>>>>>> Adrian >>>>>>> >>>>>>> On Mon, Jan 25, 2016 at 10:38 AM, Josh Mandel < >>>>>>> Joshua.Mandel(a)childrens.harvard.edu >>>>>>> <javascript:_e(%7B%7D,'cvml','Joshua.Mandel(a)childrens.harvard.edu');> >>>>>>> > wrote: >>>>>>> >>>>>>>> Let's generously read Adrian's claim here as "a patient who cares >>>>>>>> enough can set up her own AS, and thereby ensure that her AS's jwk is >>>>>>>> unique to her". So yes, you can (with enough effort -- which might be >>>>>>>> driven down by technology) get to the point of one jwk per AS, if you >>>>>>>> really want. >>>>>>>> >>>>>>>> But even if you do so, the AS's jwk in HEART* isn't really an >>>>>>>> "encryption key" sense in the way Adrian would have it*. In other >>>>>>>> words, the AS's jwk is not used as an "encryption key" for the patient's >>>>>>>> healthcare data at any point. (It *is* used to sign tokens in the >>>>>>>> UMA flow, including the PAT and the AAT.) >>>>>>>> >>>>>>>> By the way, >>>>>>>> http://openid.bitbucket.org/HEART/openid-heart-uma.html#rfc.section.2.1 >>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HE…> >>>>>>>> says that an "aud" claim in the AAT specifies the "RPT authorization >>>>>>>> endpoint"; UMA refers to this as simply the "RPT endpoint", and I think the >>>>>>>> HEART profile's language should be consistent (this tripped me up for 10min >>>>>>>> just now). >>>>>>>> >>>>>>>> -J >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jan 25, 2016 at 10:02 AM, Adrian Gropper < >>>>>>>> agropper(a)healthurl.com >>>>>>>> <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: >>>>>>>> >>>>>>>>> Why "most likely not"? Is it a security issue? a cost issue? We >>>>>>>>> don't have to compromise privacy for security in our connected world. >>>>>>>>> >>>>>>>>> On Mon, Jan 25, 2016 at 9:55 AM, Justin Richer <jricher(a)mit.edu >>>>>>>>> <javascript:_e(%7B%7D,'cvml','jricher(a)mit.edu');>> wrote: >>>>>>>>> >>>>>>>>>> But it's not like that, the arity is very different. >>>>>>>>>> >>>>>>>>>> Every record is associated with an AS, perhaps a separate AS for >>>>>>>>>> each record/patient but most likely not. >>>>>>>>>> >>>>>>>>>> Every AS is associated with a jwks_uri, but only one per AS. >>>>>>>>>> >>>>>>>>>> -- Justin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1/25/2016 9:02 AM, Adrian Gropper wrote: >>>>>>>>>> >>>>>>>>>> It means that every patient record is associated with a separate >>>>>>>>>> jwks_uri for that patient's AS. >>>>>>>>>> >>>>>>>>>> On Mon, Jan 25, 2016 at 8:59 AM, Justin Richer <jricher(a)mit.edu >>>>>>>>>> <javascript:_e(%7B%7D,'cvml','jricher(a)mit.edu');>> wrote: >>>>>>>>>> >>>>>>>>>>> Yes you did. Quote: >>>>>>>>>>> >>>>>>>>>>> "The system is also much more resistant to data breaches as data >>>>>>>>>>> holders (UMA Resource Servers) must implement separate *encryption >>>>>>>>>>> keys *for each patient." >>>>>>>>>>> >>>>>>>>>>> So if you don't mean separately encrypting the data for each >>>>>>>>>>> user, what does that statement mean? The access token isn't an encryption >>>>>>>>>>> key. >>>>>>>>>>> >>>>>>>>>>> -- Justin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 1/25/2016 8:57 AM, Adrian Gropper wrote: >>>>>>>>>>> >>>>>>>>>>> I never said anything about how the data is encrypted. I only >>>>>>>>>>> talk about how access to the FHIR API is controlled. >>>>>>>>>>> >>>>>>>>>>> Adrian >>>>>>>>>>> >>>>>>>>>>> On Mon, Jan 25, 2016 at 8:55 AM, Justin Richer < >>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','jricher(a)mit.edu');>jricher(a)mit.edu >>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','jricher(a)mit.edu');>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Adrian, >>>>>>>>>>>> >>>>>>>>>>>> I've asked this before and thought we'd settled it, but it >>>>>>>>>>>> keeps coming up: where are you getting the idea of encrypting the data to >>>>>>>>>>>> the patient using a patient's key? That is not in scope for HEART, nor is >>>>>>>>>>>> it part of any of the underlying protocols. >>>>>>>>>>>> >>>>>>>>>>>> -- Justin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 1/25/2016 8:52 AM, Adrian Gropper wrote: >>>>>>>>>>>> >>>>>>>>>>>> Establishing a separate URI for each patient is likely to be >>>>>>>>>>>> the only stable solution to the patient ID problem. The issue, however, is >>>>>>>>>>>> how many URIs will a patient be allowed to have? If the URIs are coercive, >>>>>>>>>>>> in the sense of a chip or tattoo issued by government or an equivalent >>>>>>>>>>>> global authority (Facebook?) or the URI is derived from DNA or an iris >>>>>>>>>>>> scan. (Iris scans are a good positive IDs and can be read from 30 feet away >>>>>>>>>>>> with modern technology.) >>>>>>>>>>>> >>>>>>>>>>>> Let's assume, for our purposes, that an iris scanner costs >>>>>>>>>>>> about as much as a credit card terminal, cheap enough for every front >>>>>>>>>>>> office, ambulance, and police car. Is the patient ID problem solved? I >>>>>>>>>>>> don't think so. >>>>>>>>>>>> >>>>>>>>>>>> Patients can have one or more separate URIs in order to help >>>>>>>>>>>> manage their health records. Today, we typically use email address for this >>>>>>>>>>>> purpose, with WebFinger >>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFa…> >>>>>>>>>>>> https://webfinger.net/ >>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFa…> >>>>>>>>>>>> as a standardized way to discover linked attributes such as the patient's >>>>>>>>>>>> UMA Authorization Server and the associated public key. >>>>>>>>>>>> >>>>>>>>>>>> UMA for patient ID brings numerous benefits including much >>>>>>>>>>>> greater transparency and security. The patient now has a single portal >>>>>>>>>>>> (their UMA AS) to view all current relationships under that particular >>>>>>>>>>>> patient ID persona. The system is also much more resistant to data breaches >>>>>>>>>>>> as data holders (UMA Resource Servers) must implement separate encryption >>>>>>>>>>>> keys for each patient. >>>>>>>>>>>> >>>>>>>>>>>> I think the HEART group is in a good position to compete for >>>>>>>>>>>> the CHIME challenge on this basis and I'd be happy for me and PPR to help >>>>>>>>>>>> organize a submission. >>>>>>>>>>>> >>>>>>>>>>>> Adrian >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Jan 24, 2016 at 1:20 PM, Aaron Seib < >>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','aaron.seib(a)nate-trust.org');> >>>>>>>>>>>> aaron.seib(a)nate-trust.org >>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','aaron.seib(a)nate-trust.org');>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I appreciate your expertise and action. >>>>>>>>>>>>> >>>>>>>>>>>>> I don't necessarily agree with some of your statements here >>>>>>>>>>>>> but that is the beauty of open processes. >>>>>>>>>>>>> >>>>>>>>>>>>> Let's strive to do all we can - together. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Aaron Seib >>>>>>>>>>>>> @CaptBlueButton >>>>>>>>>>>>> (O) 301-540-9549 >>>>>>>>>>>>> (M) 301-326-6843 >>>>>>>>>>>>> >>>>>>>>>>>>> "The trick to earning trust is to avoid all tricks. Including >>>>>>>>>>>>> tricks on yourself." >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -------- Original message -------- >>>>>>>>>>>>> From: "Glen Marshall [SRS]" < >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm(a)securityrs.com');> >>>>>>>>>>>>> gfm(a)securityrs.com >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm(a)securityrs.com');>> >>>>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00) >>>>>>>>>>>>> To: HEART List < >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','openid-specs-heart(a)lists.openid.net');> >>>>>>>>>>>>> openid-specs-heart(a)lists.openid.net >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','openid-specs-heart(a)lists.openid.net');>> >>>>>>>>>>>>> >>>>>>>>>>>>> Subject: [Openid-specs-heart] CHIME Launches $1M Challenge to >>>>>>>>>>>>> Solve Patient ID Problem >>>>>>>>>>>>> >>>>>>>>>>>>> This is pertinent to our data-sharing use cases. There is no >>>>>>>>>>>>> current solution to accurately sharing/gathering patients' clinical data >>>>>>>>>>>>> stored among various repositories. In turn, that makes applying access >>>>>>>>>>>>> controls across all of a patient's data in those repositories difficult. >>>>>>>>>>>>> I'm happy to see Chime's challenge. >>>>>>>>>>>>> >>>>>>>>>>>>> However, the related problem of discovering where all of one's >>>>>>>>>>>>> data might be is computationally intractable. It is equally intractable to >>>>>>>>>>>>> gather and combine all access permissions and regulatory restrictions on >>>>>>>>>>>>> patients' data, even if there were a useful means to do so. (Both are >>>>>>>>>>>>> equivalent to the halting problem >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_…> >>>>>>>>>>>>> .) >>>>>>>>>>>>> >>>>>>>>>>>>> Having a single "source of truth" repository is one direction >>>>>>>>>>>>> for a solution, as is having a single access permissions source. Keeping >>>>>>>>>>>>> them updated with new data and permissions is possible, even if difficult >>>>>>>>>>>>> in the short run. >>>>>>>>>>>>> >>>>>>>>>>>>> However, establishing unique URIs for each patient's data and >>>>>>>>>>>>> permissions is the same as having a universal patient identifier. That >>>>>>>>>>>>> might be subject to current Congressional funding restrictions. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> *The College of Healthcare Information Management Executives >>>>>>>>>>>>> on Tuesday launched a $1 million National Patient ID Challenge to develop >>>>>>>>>>>>> solutions to ensure 100 percent accuracy of every patient’s identity to >>>>>>>>>>>>> reduce preventable medical errors.* >>>>>>>>>>>>> >>>>>>>>>>>>> * >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagemen…>http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-sol… >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagemen…>* >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> *Glen F. Marshall* >>>>>>>>>>>>> Consultant >>>>>>>>>>>>> Security Risk Solutions, Inc. >>>>>>>>>>>>> 698 Fishermans Bend >>>>>>>>>>>>> Mount Pleasant, SC 29464 >>>>>>>>>>>>> Tel: (610) 644-2452 <%28610%29%20644-2452> >>>>>>>>>>>>> Mobile: (610) 613-3084 <%28610%29%20613-3084> >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm(a)securityrs.com');> >>>>>>>>>>>>> gfm(a)securityrs.com >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','gfm(a)securityrs.com');> >>>>>>>>>>>>> >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutio…> >>>>>>>>>>>>> www.SecurityRiskSolutions.com >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutio…> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Openid-specs-heart mailing list >>>>>>>>>>>>> Openid-specs-heart(a)lists.openid.net >>>>>>>>>>>>> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart(a)lists.openid.net');> >>>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart >>>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailma…> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Adrian Gropper MD >>>>>>>>>>>> >>>>>>>>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>>>>>>>>>>> HELP us fight for the right to control personal health data. >>>>>>>>>>>> DONATE: >>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>>>> http://patientprivacyrights.org/donate-2/ >>>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Openid-specs-heart mailing listOpenid-specs-heart(a)lists.openid.net <javascript:_e(%7B%7D,'cvml','Openid-specs-heart(a)lists.openid.net');>http://lists.openid.net/mailman/listinfo/openid-specs-heart <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailma…> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Adrian Gropper MD >>>>>>>>>>> >>>>>>>>>>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>>>>>>>>>> HELP us fight for the right to control personal health data. >>>>>>>>>>> DONATE: >>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>>> http://patientprivacyrights.org/donate-2/ >>>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> 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/ >>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> 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/ >>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Openid-specs-heart mailing list >>>>>>>>> Openid-specs-heart(a)lists.openid.net >>>>>>>>> <javascript:_e(%7B%7D,'cvml','Openid-specs-heart(a)lists.openid.net');> >>>>>>>>> >>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailma… >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> 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/ >>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> 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/ >>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> 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/ >>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >>>> >>> >>> >> >> >> -- >> >> 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/ >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.or…> >> > > -- 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/

1 0

Fwd: [Cups-friends] SOUPS 2016 Call for Papers, Posters, and Proposals
by Eve Maler 24 Jan '16

24 Jan '16

Anyone interested?? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl [image: SOUPS 2016 banner] <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> SOUPS 2016 is just around the corner with our first deadlines only two weeks away. We are pleased to announce that the Call for Papers <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and the Call for Posters and Proposals <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> for the Twelfth Symposium on Usable Privacy and Security (SOUPS 2016) <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> are now available. SOUPS 2016 will bring together an interdisciplinary group of researchers and practitioners in human computer interaction, security, and privacy. The program will feature technical papers, a poster session, workshops and tutorials, panels and invited talks, and lightning talks. Please see the Call <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…>for Papers <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and/or the Call for Posters and Proposals <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> for details. Some important dates to keep in mind: *Friday, January 29, 2016*: Proposals for Workshops, Tutorials, Invited Talks, and Panels due *Tuesday, March 1, 2016*: Paper registration deadline *Monday, May 16, 2016*: Poster abstracts and proposals for Lightning Talks and Demos due SOUPS 2016 will be co-located with the 2016 USENIX Annual Technical Conference <http://s.usenix.org/acton/ct/2452/s-0176-1601/Bct/l-sf-cl-70116000000FReXAA…> and will take place June 22–24, 2016, in Denver, CO. Sunny Consolvo, *Google* Matthew Smith, *University of Bonn* soups16chairs(a)usenix.org Please use soups16chairs(a)usenix.org to contact Sunny Consolvo or Matthew Smith. For more details and announcements like and follow our Facebook page at: https://www.facebook.com/SOUPSconference

3 2

UMA for Healthcare - calling all umanitarians
by Adrian Gropper 24 Jan '16

24 Jan '16

UMA is perfect for healthcare. Preamble: Healthcare has just discovered REST and OAuth and is struggling with major unsolved patient identity and privacy problems that UMA can solve. The UMA opportunity is global. Three kinds of health records access have been tried in the developed world (UK has a centralized government-controlled system, AU has a centralized patient-controlled system, and US has a mess of private silos and state exchanges with little or no patient control). It can be argued that all three of these approaches is failing for privacy and scalability reasons. History: For over a year, I've been working with a geek physician (Michael Chen) that has an open-source electronic patient record (EHR) to convert it into an UMA-based and compatible alternative to the three incumbent models above. The idea is to have each patient own and control the technology that hosts their individual health record and use UMA and OIDC to connect her personal EHR server to institutional systems, licensed clinicians, and family caregivers. Michael has made a lot of progress is separating his EHR code into a practice copy and a patient copy and integrating MITREid Connect into the separated pieces. Last week, a number of things came together including the first public presentation of this project that I put up on YouTube, publicized by a very articulate practicing physician http://thehealthcareblog.com/blog/2016/01/23/the-patient-centered-health-re… , a major publication http://www.nejm.org/doi/full/10.1056/NEJMp1512142 by long-time academic collaborators of mine, and a bunch of behind-the-scenes activity leading to separate testimony in Washington this week by Eve and by me http://bit.ly/APItaskforce . In healthcare, as opposed to more typical commerce, patients have a "right of access" to our own health data which can be used to drive adoption of UMA by physicians and tech innovators. The major health IT conference in the US is coming up at the end of February and it's a major opportunity to promote UMA. *Need Help:* Michael Chen and I need help with our respective GitHub projects (NOSH and HIE of One) in order to complete the proof of concept while the regulators and geeks are still firming up the healthcare standards and profiles. I am particularly lame and am hoping to get some coding help around HIE of One which I'm building around Debian/FreedomBox at https://github.com/HIEofOne/PersonalAS/wiki/Milestone-1:-OpenID-Connect-Cli… As you can see there, the FreedomBox community will also help and help drive adoption. I think Roland's UMA code for Python could do much of this and, because NOSH is using MITREid Connect, the result would be more broadly interesting. Can any umanitarian help add an UMA AS to FreedomBox? Thanks, Adrian -- 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/

1 0

Reminder: no WG or legal subgroup meeting this week
by Eve Maler 19 Jan '16

19 Jan '16

If you have *action items*, this is a great chance to try to complete them. (I'm aware that several are weighing on my own head. :-) Also, our 2016 APAC-friendly sync meetings don't start up again until next week. As always, you can check the meeting schedule by looking at our online *calendar* <http://kantarainitiative.org/confluence/display/uma/Calendar>. If you haven't received an *invitation* to any of these meeting series and would like to, drop me a private note and I'll add you. Also, if you'd like to receive *Skype* pings about impending meetings a few minutes before they start, let me know your Skype handle and I'll add you to our chat group. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Deriving UMA [Legal] from the law and one simple assumption
by Adrian Gropper 16 Jan '16

16 Jan '16

In the last month two very important regulatory guidance documents have been released by the EU and US governments respectively: http://europa.eu/rapid/press-release_MEMO-15-6385_en.htm and http://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.ht… By adding to these regulations a single constraint - that an individual can own and specify the UMA Authorization Server if they choose to - I think we can derive a complete UMA Legal profile and associated clauses. I've started analysis of the US reg at http://bit.ly/HEARTfromHIPAA I think a similar analysis could be interesting for the EU regs. Adrian -- 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/

5 8

Notes from UMA legal subgroup telecon 2016-01-15
by Eve Maler 15 Jan '16

15 Jan '16

*Please note:* No meeting next week! We'll resume the week after. http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-15 - Review the emerging WG roadmap use cases <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss the "RO access limit discretion" use case <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss other open editorial issues for the candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>, as outlined in previous meeting notes below Attending: Eve, Ann, Adrian, Jim, Jon, Mark, Sal, Thomas What Eve calls the "Adrian clause" is this part of UMA Core Sec 3.3.3 <https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#give-acce…>: "The resource server MAY apply additional authorization controls when determining how to respond." What does the "RS authorization discretion" use case mean? Should the AS be made officially aware that the RS still didn't give access (similar to the "Shoebox" technical idea), or could the RS somehow need some other assurances that it can be compliant? This goes right back to the Adrian clause, and complementarily, to the Shoebox idea. The RS could either warn Alice, or could verify the requesting party on its own. Is this broad-based, or truly healthcare-specific? To how many jurisdictions does it apply? Adrian suggests another case of a warning. A data processing process might take some time to complete, and only licensed practitioners can receive in-process results. Would it be useful to develop a model clause, or even a pair of model clauses? Sounds like it's useful to try, and then go back and see if it's getting used. What does the "RO access limit discretion" use case mean? There is something of an opposite to the Adrian clause in the same section: "The resource server MUST NOT give access in the case of an invalid RPT or an RPT associated with insufficient authorization." A way of looking at it is: - Conditions: RO wants sharing to happen; AS executes those directions appropriately, such that the RPT is valid and is associated with sufficient authorization data: - RS gives access - normal case - RS doesn't give access - To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION? - For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE? - Conditions: RO doesn't want sharing to happen; AS executes those directions appropriately, such that the RPT is invalid or is associated with insufficient authorization data: - RS doesn't give access - normal case - RS does give access - To remain compliant with the law of some jurisdiction - MUST PRODUCE NOTIFICATION? - For some other reason - MUST NOT HAPPEN WITHIN AN UMA FLOW GOVERNED BY THE PAT MINTED WITH THE AS ABOVE? The idea of getting notices is that the RO could severe the relationship with the RS if they want. Of course, sometimes there are legal constraints on even getting a notification. Can you ever trust the AS to serve the RS, versus the RO? Only at the business agreement level could an AS start to consider jurisdictional issues that RS's care about. *Please note:* No meeting next week! We'll resume the week after. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA legal subgroup telecon 2016-01-15
by Eve Maler 14 Jan '16

14 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes UMA legal subgroup notesDate and Time - *Fridays,* 8-9am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar ------------------------------ 2016-01-15 - Review the emerging WG roadmap use cases <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss the "RO access limit discretion" use case <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14> - Discuss other open editorial issues for the candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…>, as outline in previous meeting notes (see link above) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA telecon 2016-01-14
by Eve Maler 14 Jan '16

14 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 MinutesRoll call Quorum was not reached. Quick legal subgroup update The subgroup meetings are going to continue, and consensus was reached on releasing beta model text by the end of Q1. Update on AIs from last week Andi now has the data he needs for the blog post. We need to publish the specs first; that should happen tomorrow. Mike is doing a Kantara blog post <http://www.gluu.org/blog/gluus-rsa-conference-2016-events/> about RSA sessions, including those that relate to UMA (and beer!), and can mention others. Eve is doing a privacy talk with Josh Alexander (and they'll be singing again too [image: (smile)]). A good idea is to send calendar invitations to those you'd really like to come to your talk. Hopefully Kantara will be sponsoring the Non-Profits on the Loose party again at RSA! Keep on the lookout. Even if not, let's all try to get together and hoist an UMArtini (or something – or a BLT...). Thomas and Maciej and Eve are very close to finishing other AIs. Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? We are looking for "customer need" for these use cases and technical issues. Let's put initials of participants where they can confidently express "customer need" in 2016 or 2017 (or, if you want to remain pseudonymous, get in touch with Eve and she will put XX in for your initials). use case technical issue IoTAPI securityfederated authz RS authorization discretion (also "legal"?) RO access limit discretion (also "legal")wide ecosystems (is this a meta- use case?) access federations ("legal") AAT burden permission reg extension MSclient-to-AS-first efficiency MSself-contained token validation RPT needs refresh token* Shoebox endpoint* An issue that Mike wants UMA to explore is the new NAPPS solution <https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00> being proposed that uses PKCE. It leverages new system browser capabilities to return control to a native app using a custom scheme that the native app registered. Could this solution be applied to how a client delivers an RPT to a mobile app? Since the client just makes a direct back-channel call to the RPT endpoint at the AS, is this needed? Perhaps not right now, but maybe this could be used where we use a redirect flow (redirecting Bob for claims gathering after getting need_info with redirect_user), or if we start considering an authorization code-type flow for a redesigned client interaction with the AS a la Justin's suggestion (AAT-free). Mike remarks that a self-contained token is interesting but may be a nice-to-have for him vs. a self-contained token. In the work he's describing here <http://ox.gluu.org/doku.php?id=uma:oauth2_access_management>, the client-to-AS-first pattern could be relevant. Adrian would like an RS to be able, based on jurisdictional requirements, to get hold of verified attributes of the requesting party. This likely goes beyond healthcare, he surmises. What happens if the RS trusts the AS to be the RO's agent but doesn't trust the AS to make proper authorization decisions on behalf of the RO (e.g., by assessing verified attributes presented by the RqP)? Currently UMA says that if the RS cares about such attributes, it can gather them locally; it doesn't (by default) get them from the AS. Are we interested to develop a token profile for this to come from the AS? Perhaps there's not enough impetus. What about a "Shoebox" endpoint? The AS could present this endpoint for more than "consent receipts" – importantly, notifications are a big part of many laws. It would be great to bounce this off our legal subgroup. Is it, in fact, right for the AS to take on such an endpoint? What "RO access limit discretion" means is that we want to set up a one-way valve. Currently the spec it's a MUST, but technically it's not possible to enforce that the RS not give access when the permissions in the RPT say "no" in a technical fashion. However, it may be possible to set up a conformance suite in such a fashion to catch such cases and force the throwing of an audit log entry. In fact, this could be a case where a "Shoebox endpoint" could be a key part of a technical solution, in that we could mandate notices for certain kinds of access given. *AI:* Eve: Put starred items in the left column into GitHub issues. AI: Eve: Post matrix in a more prominent wiki place and start to check off relationships among the columns and rows, and advertise the opportunity to state priorities. Attendees As of 18 Dec 2015, quorum is 6 of 11. (Evariste, François, Domenico, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. François 3. Domenico Non-voting participants: - Steve - Katie - Adrian - George *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-01-14
by Eve Maler 12 Jan '16

12 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-14 Date and Time - *Thu Jan 14,* 9-10am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-01-17 if quorum - Quick legal subgroup update - Update on AIs from last week - Review roadmap use case/technical issue matrix (Eve AI) and figure out what to dive into/how/when in Q1 - Good F2F opportunities? - Good liaison opportunities? - Charter AIs? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Notes from UMA legal subgroup telecon 2016-01-08
by Eve Maler 08 Jan '16

08 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-08 - Review proposed mission and timeline <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review high-level requirements <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> - Review latest candidate model text <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> Attending: Eve, Ann, Jim, Adrian, Jon, Mark, Thomas, Bill Wendell (guest - ears only), Andrew Hughes, Sal Mission and timeline discussion A proposed mission and timeline were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Jon speaks in support of the three goals. Is "model clauses" the right phrase, given that "EU model clauses" is something of a term of art? We're free to call it whatever we want. RoboClauses? [image: (smile)] Maybe the connection to EU model clauses is helpful to us. Regarding meeting scheduling, if text review is paramount in the early going, availability of interested parties is the most key. Offline review and reporting of comments by others could work great. "Model text" was Eve's temporary phrase covering not just the clauses but also the definition. "Model T – you can start with any color you want, as long as it's black!" We're thinking that the "standard" meeting time of Fridays at 8am PT would be okay for starters in working on the model text. Note that Eve can't make January 22, so maybe we can move or skip that one. Andrew's project is holding a F2F in January, and by February will possibly be really ready to need our outputs. Right now they're wrestling with different views on what "authorization" means. Is it authorization to release information? access to an API? (UMA would rely on the semantics of the API being protected for the definition.) Mark notes that consent and permission definitions should come into the picture as well. This does actually impact our term definitions because we use the word "Authorization" as part of our UMA role names, and so we may have to define Authorization, or at least define it in a limited sense so that a context in which the word is defined in a different sense is not incompatible or confusing wrt our usage. If there is, somewhere (EU?), a standard vocabulary, can we leverage it? Or is it too backwards-looking? Let's add this to our open issues. *AI:* Eve: Add model text issues to our issues backlog and tag them appropriately, including the issue of defining authorization, consent, etc. Consenus on the mission is positive. What should our timeline actually be? Jim recommends that we target a real version number of 1.0. We can achieve this sooner rather than later if we have real review by people who really need this text! Eve has been collecting external reviewer candidates. We did some more brainstorming. The right time for a beta version of the model text for review: end of March 2016. *AI:* Eve: Send continuing calendar invitations. Requirements discussion Some proposed high-level requirements were sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/-xxfPj0xJ…> . Eve did a quick reading of the proposed high-level requirements. People started dropping off, but it sounded like there was at least some weak rough consensus. [image: (smile)] We'll work with this list for now until it proves problematic. Draft model text The latest model text for review, with commentary, was sent in this message <https://groups.google.com/forum/#!topic/kantara-initiative-uma-wg/j5hKnR6VB…>. It lives persistently here <http://www.commonaccord.org/index.php?action=list&file=GH/KantaraInitiative…> . We took a quick look at the message sent out. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0