- WG-UMA - mailman.kantarainitiative.org

Reminder: APAC-friendly sync 2016-01-28
by Eve Maler 26 Jan '16

26 Jan '16

- *Thu Jan 28* at APAC-friendly times - Voice: Skype: +99051000000481, 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) - See the UMA calendar for additional dial-in and timing details (e.g., the call time = *Wed Jan 27 4pm PT*): http://kantarainitiative.org/confluence/display/uma/Calendar If you wish to be added to the calendar invitation, send me a note. If you wish to be added to our Skype chat group to receive reminders before I open the bridge, include your Skype handle. The standing agenda is to review recent WG progress, collect participant feedback, check on action item status, and attend to any other relevant business. Others besides those in APAC-ish regions are welcome to join. This sync series has been useful for some who have a standing conflict with our weekly WG calls. However, the sync series doesn't "count towards quorum" if you're a voting participant. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New "UMA Legal" area on the KI UMA wiki
by Eve Maler 25 Jan '16

25 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+Legal ...which you can get to easily with the following link: http://tinyurl.com/umalegal As we were reaching out to potential external reviewers and other interested parties, we were getting questions about where the legal info was on the site, so I did a bit of consolidation and updating, and created the tinyurl. (Note also that the UMA wiki and the KI site generally have been updated to reflect the publication of the UMA V1.0.1 Recommendations!) Next I'll do my action item about creating open issues for the editorial questions that have arisen on the model text. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

25 Jan '16

Eve, can you unpack the technical solution point that you're making? Are you saying that an n:1 solution is currently incompatible with a 1:1 solution and which role is on either side of the : ? Adrian On Mon, Jan 25, 2016 at 3:23 PM, Eve Maler <eve.maler(a)forgerock.com> wrote: > I'm very glad to see this clear elucidation of where the splits in > understanding/belief are. > > The UMA WG's design center never actually assumed or required a strict 1:1 > relationship between RO and AS, as can be seen in the charter > <http://kantarainitiative.org/confluence/display/uma/Charter> and requirements > and design principles > <http://kantarainitiative.org/confluence/display/uma/UMA+Requirements>. > > The nature of agency law, as I understand it, is precisely to ensure that > the agent's interests align properly with those of the principal so that > the agent acts within their authority when they act on behalf of the > principal. This should hold true whether there is a 1:1 or n:1 > relationship, and it's part of why the UMA legal subgroup is doing its work. > > Of course, if technology can do a good job of keeping an agent in line, > then a legal remedy might not be required. But so far, I haven't seen jwk > be a good candidate for a technical solution. > > People have asked me about various encryption or DRM solutions being used > on top of UMA. Generally my response to them is that they can use such a > thing if they want to. However, solutions involving encryption can impose > costs that many ecosystems can't bear (particularly wide ecosystems with > lots of third-party clients -- witness OAuth V1.0), and often the players > end up treating such requirements as failure and route around them by > emailing content or sharing passwords. :-) Access control systems must make > the right thing to do be the easiest thing to do. > > > *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging > Technology > Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community! > > On Mon, Jan 25, 2016 at 9:32 AM, Adrian Gropper <agropper(a)healthurl.com> > wrote: > >> (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 >>> > wrote: >>> >>>> >>>> >>>> On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel < >>>> 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> 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> 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> 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> >>>>>>>> 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> 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> 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> 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> >>>>>>>>>>> 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 >>>>>>>>>>>> > 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 < >>>>>>>>>>>>> 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 < >>>>>>>>>>>>>> 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]" <gfm(a)securityrs.com> >>>>>>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00) >>>>>>>>>>>>>>> To: HEART List <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> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> 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@lists.openid.nethttp://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 >>>>>>>>>>> >>>>>>>>>>> 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/ >> >> >> _______________________________________________ >> Openid-specs-heart mailing list >> Openid-specs-heart(a)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/

1 0

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