January 2016 - WG-UMA - mailman.kantarainitiative.org

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

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