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

Documenting UMA publication workflows
by Eve Maler 18 Jul '16

18 Jul '16

Hi folks-- Hope you are enjoying post-Christmas reentry or more holiday time, or whatever the case may be. Maciej and I are working on publishing the new Recommendations, and due to that, I unearthed the permanent/symbolic link information that I promised to Justin; we thought it would be a good idea to document the processes here -- and in the GitHub readme... It seems to work pretty well for now given that there isn't that much to the entire publishing process for our WG or others, but if you see ways to improve it for the future, let us know. After completing a draft spec revision cycle and getting it approved: 1. Edit the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources to change from Status #3 to #4 (see below), leaving the previous date in place. 2. Run the stylesheet over the XML sources to produce .html outputs, review the results as required, sync GitHub, and upload the last drafts by FTP (Eve and Oliver can do this). 3. Save the draft-uma-core-vn_n[_n] and draft-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with rec- instead. 4. Change the Status section of the new files from #4 to #5, the date, and any other metadata (some of this has to be done in the stylesheet, which is in the repo). 5. Update the two specs' References links to each other in the Reference section. 6. Run the stylesheet over the XML sources to produce HTML output with .html extensions, review the results as required, sync to GitHub, and FTP the HTML results to the website (Eve and Oliver can do this). 7. Get symbolic links created (see below) from the versioned rec- HTML links to generic links (Oliver can do this). After launching a new draft spec revision cycle: 1. Save the rec-uma-core-vn_n[_n] and rec-oauth-resource-reg-vn_n[_n] sources off to new files in the repo starting with draft- and having the agreed new version numbers instead. 2. Edit the Status section from #5 to #1. 3. Proceed to edit the new drafts, and periodically produce HTML results that can be uploaded through FTP. 4. Get symbolic links created from the versioned draft- HTML links to generic links (Oliver can do this). Here are the stages of the Status section (embed links throughout as appropriate): 1. This document is a draft technical specification produced by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 2. This document is a Kantara Initiative Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home>. 3. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. 4. This document is a Draft Recommendation approved by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and certified by the Leadership Council to undergo a Kantara All-Member Ballot. The Ballot having passed, this document has been superseded by the Recommendation version of the document. 5. This document was developed by the User-Managed Access Work Group <http://kantarainitiative.org/confluence/display/uma/Home> and approved by the Membership of the Kantara Initiative <http://kantarainitiative.org/> as a Recommendation. Here is how the symbolic links work: https://docs.kantarainitiative.org/uma/rec-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-vn_n[_n].html - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core-vn_n[_n].html - Permanent link to specific Core Rec https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg-vn_n[_n].ht… - Permanent link to specific RSR Rec https://docs.kantarainitiative.org/uma/rec-uma-core.html - Symbolic link to latest Core Rec https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg.html - Symbolic link to latest RSR Rec https://docs.kantarainitiative.org/uma/draft-uma-core.html - Symbolic link to latest Core draft https://docs.kantarainitiative.org/uma/draft-oauth-resource-reg.html - Symbolic link to latest RSR draft *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 2

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

30 Jan '16

We're back on track with "Authentication strength/LOA and pairing mechanics could be a matter for HEART profiling." The issue becomes, what is the chain of events that drives patient ID in the sense of enabling a patient-level FHIR client to access a patient-level FHIR resource? 1 - Although it's not the only way to build this chain, I start with "known to the practice" in the sense that a specific person's biometric can be associated with a specific primary key in either the FHIR client or FHIR resource server. There is no matching yet and the biometric, be it a photo or iris scan, is neither verified nor is it used for matching across the link. 2 - The patient provides an identifier to the Client FHIR endpoint that can eventually result in a match at the FHIR resource server. A persona. Depending on jurisdictional and business issues, this identifier may not be subject to any verification at all, verification to ensure correct spelling such as an email confirmation, or verification against a federated authority such as the state DMV. 3 - The persona identifier provided to the FHIR Client can be designed in all sorts of different ways. a - It could be globally unique and anonymous like a Bitcoin address. b - It could be globally unique and easily remembered like an email address or mobile number c - It could be globally unique and subject to a federation's jurisdiction like a driver's license number 4 - All of a, b, or c are then subject to discovery mechanics and standards such as blockchain, WebFinger or lookup in Surescripts or the state HIE. This eventually turns into an identifier that is unique to the FHIR resource server for that matching patient persona. 5 - The FHIR client presents to the FHIR resource server with a patient context and requests access. Hilarity and maybe more UMA ensues. Somewhere between 1 and 5 we have patient and requesting party authentications, AS and client registrations, and these touch UMA and HEART more or less directly. I prefer to think of the patient's persona and her UMA AS URI being a unified and key link in his chain of events. Adrian On Saturday, January 30, 2016, Eve Maler <eve.maler(a)forgerock.com> wrote: > I'm sorry to have misinterpreted your question. Your previous question to > me had to do with "1:1 vs. 1:n", not with the literal subject of the > thread, so I took your followup question to my previous response in the > same way. > > If an individual patient is the resource owner, we could say something in > HEART about requiring only "three-legged" types of OAuth and OAuth-based > grant flows, that is, the grant flows other than client credentials > (although maybe that's already sufficiently implied by the nature of the > protocols?). The entire point of these flows is to enable the RO to > traverse across from the client and, "SSO-like", authenticate to the AS and > authorize the client to work with the resource server. This is why I > observe that the resulting access token, in fact, acts something like a > pairwise pseudonymous identifier between the two. (UMA uses OAuth flows to > mint the PAT and AAT and thus acts the same way.) > > If a patient logs into an EHR system and that system had in place its own > capability to definitively match that patient upon onboarding that patient, > then -- so the theory of "online individuals" goes -- further pairing of > other services with that EHR systems (e.g. if the system is an RS and it > gets paired with an AS) enables chaining of patient matching, as long as > the level of assurance is high enough in the farthest upstream source of > matching and in the authentication method of each subsequently paired > service. > > Authentication strength/LOA and pairing mechanics could be a matter for > HEART profiling. > > > > > > *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging > Technology > Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > New ForgeRock Identity Platform <https://www.forgerock.com> with UMA > support <https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA > community <https://forgerock.org/openuma/>! > > On Sat, Jan 30, 2016 at 11:41 AM, Adrian Gropper <agropper(a)healthurl.com > <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: > >> Eve, >> >> This is not silly at all and it may or may not be about UMA. The subject >> of this thread is the so-called "Patient ID Problem". Here's a decent >> definition, from different perspectives of the problem: >> http://www.statnews.com/2016/01/28/experts-argue-unique-patient-identifier/ >> >> As your IAM 101 tutorial makes clear, "The OAuth relationship that Alice >> forms between the two services therefore can be effectively pseudonymous." >> >> Whether UMA likes it or not, it is squarely at the nexus between the >> pseudonimity of OAuth and the patient ID problem. Pretending that the UMA >> AS is separable, in practice, from the unique patient identifier simply >> confuses the issue and the role of HEART. >> >> FHIR is a direct connection between two institutions with their separate >> and hidden primary key for one person. The authorization system that >> manages that connection is HEART. There are only two possibilities: Either >> the patient is directly involved in establishing the correspondence of the >> two primary keys, or some institution is responsible for establishing that >> correspondence. In the US, for example, we have Surescripts claiming to be >> able to establish this correspondence for 230 Million people, whether they >> like it or not. (That's probably more than the NSA wants to claim.) >> >> The patient ID problem will be solved by some combination of these two >> paths. Whether either one uses UMA and HEART is not silly at all. >> >> Adrian >> >> >> On Saturday, January 30, 2016, Eve Maler <eve.maler(a)forgerock.com >> <javascript:_e(%7B%7D,'cvml','eve.maler(a)forgerock.com');>> wrote: >> >>> I'm sorry, but this is getting just a bit silly. This is IAM 101. >>> >>> When Alice uses any online service, the service knows how to distinguish >>> her vs. any other individual who uses the service. Typically the mechanism >>> used is "accounts" and Alice accesses her singular account by confirming >>> (authenticating) herself*; the service matches that individual to some >>> primary key associated with the account that can be thought of as an >>> "identifier". So whatever primary key(s) can serve roughly as an "identity" >>> for her. >>> >>> An AS is a kind of service that typically uses such a mechanism, >>> particularly when the service serves lots of individuals. An RS is also a >>> kind of service that typically uses such a mechanism. UMA does not depend >>> at all on the value of any primary key ("identifier") being the same in >>> both cases. The OAuth relationship that Alice forms between the two >>> services therefore can be effectively pseudonymous. >>> >>> The way that Alice confirms her identity ("authenticates") to each >>> service could be strong or weak, as appropriate. Biometrics (not always a >>> guarantee of authentication strength, particularly when not combined with >>> other factors/methods) might or might not be involved. >>> >>> If a service serves exactly one individual, it's up to that service and >>> that individual how the two are bound together. In that special case, the >>> usual IAM mechanisms could be messed with quite a bit, though if you're >>> building a software stack, it would probably cost a lot more to "go off the >>> rails" and build all this from scratch than to use off-the-shelf parts and >>> well-vetted standards that this existing software knows how to work with. >>> Also people know how to "log in" to services, and they might not know how >>> to "do something else" to interact with a service that's custom just for >>> them (though this objection could be overcome, of course). >>> >>> Stepping away from authentication, what you (I think) have been talking >>> about is an AS whose* identity as a service technically literally also >>> represents the identity of its individual*. That is not the typical job >>> of any service I know, and UMA hasn't been designed for it either. >>> >>> *For techies reading this, I'm not getting into session management here! >>> :-) >>> >>> >>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging >>> Technology >>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >>> New ForgeRock Identity Platform <https://www.forgerock.com> with UMA >>> support <https://www.forgerock.com/platform/user-managed-access/> and >>> an OpenUMA community <https://forgerock.org/openuma/>! >>> >>> On Fri, Jan 29, 2016 at 7:31 AM, Adrian Gropper <agropper(a)healthurl.com> >>> wrote: >>> >>>> What is singular identity of the RO? Is it equivalent to biometric >>>> identity a la iris scan done by the RS? >>>> >>>> In that case, can the AS be associated with one persona of the RO? >>>> >>>> What protocol changes would be required? >>>> >>>> Adrian >>>> >>>> >>>> On Friday, January 29, 2016, Eve Maler <eve.maler(a)forgerock.com> wrote: >>>> >>>>> UMA as designed is well compatible with n ROs and 1 AS, where the AS >>>>> is an always-on service acting in the interests of each of the ROs in turn. >>>>> (Think about how a SaaS service represents and serves each of its users >>>>> without mixing them up.) >>>>> >>>>> It can be technically compatible with 1 RO and 1 AS as well in the >>>>> exact same way, but things start to break down when others in the ecosystem >>>>> want to make a hard assumption that the *identity* of the AS (as an >>>>> agent of the RO) is "as good as knowing" the singular identity of the RO it >>>>> represents. This would require protocol changes. >>>>> >>>>> >>>>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging >>>>> Technology >>>>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >>>>> New ForgeRock Identity Platform <https://www.forgerock.com> with UMA >>>>> support <https://www.forgerock.com/platform/user-managed-access/> and >>>>> an OpenUMA community <https://forgerock.org/openuma/>! >>>>> >>>>> On Mon, Jan 25, 2016 at 12:31 PM, Adrian Gropper < >>>>> agropper(a)healthurl.com> wrote: >>>>> >>>>>> 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/ >>>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Adrian Gropper MD >>>> >>>> PROTECT YOUR FUTURE - RESTORE Health Privacy! >>>> HELP us fight for the right to control personal health data. >>>> DONATE: http://patientprivacyrights.org/donate-2/ >>>> >>>> >>> >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! >> HELP us fight for the right to control personal health data. >> DONATE: http://patientprivacyrights.org/donate-2/ >> >> > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

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

30 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-01-29 - Review the new UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016?sr…> page and the "#trust"-related use cases - Pick off some of the new "#trust" GitHub issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> to work on - Take a look at the documents Scott David shared in email on Jan 15 <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/scott$…> Attending: Eve, Domenico, Jon, Jeff, Kathleen, John, Dazza Regarding #RSctrl, John W notes that Russia is one case of a jurisdictional constraint where the cloud service has to be located in-country and that would have to override the RO's choice. Adrian has brought up healthcare-related constraints regarding delays in fulfilling the access request. In the case of cross-border transfer, EU adequacy rules for offshore transfer come into play. This is why cloud services have data sovereignty plays and data centers are coming up in All The Countries. The actual UMA Core spec has a clause, which Eve has dubbed the "Adrian clause": UMA Core Sec 3.3.3 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#give-access>: "The resource server MAY apply additional authorization controls when determining how to respond." Essentially, at a T (technical) level, *IF* the AS and the RS are run by different operators, we have very little direct control over the RS going against the RO's wishes as expressed by the artifacts produced by the AS. This is why it's so important to look at the L (legal) levers we can control. The #RSctrl use case is on pretty firm ground when it comes to legal compliance. How firm ground is it on in cases outside compliance? How far could we take mandating the usage of our clauses? It depends on the compliance situations and the jurisdictions. There are also technical solutions that can be layered on top of UMA, such as encryption. If regulation of encryption use is already present in an ecosystem, then very likely both the clauses and the complex technology can be mandated. (If it's an unregulated environment and/or some element of the ecosystem is commoditized and "free-wheeling", potential partners at the edge may walk away because encryption technologies are complex and add cost and friction.) We looked at Scott D's mapping exercise. Kathleen knows of a similar mapping exercise having been done and will point us to it. How might we be able to leverage such work? Jon suggests that we can look at the breakdowns of common text vs. factored-out differences to help us structure the elements of our model text that, of necessity, get into jurisdictional specifics. We can hopefully structure our common vs. factored-out elements in the same way. Eve suggests taking on the term definition work first, taking the many healthcare use cases as examples – and possibly writing the needed model clauses to motivate the right definitions. E.g., what if Alice needs to share access with a hospital, or hospital department, and Dr Bob gets access as an employee of that organization? There are questions around how a "Requesting Party Agent" would get defined, and possibly also "Client Operator". While health isn't the only set of use cases for this, it's 1) the hardest case, and 2) ready to try out our work! It sounds like we need to have focused text-bashing working sessions; our calls are the times we have available to do this. *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 30 Jan '16

30 Jan '16

Eve, This is not silly at all and it may or may not be about UMA. The subject of this thread is the so-called "Patient ID Problem". Here's a decent definition, from different perspectives of the problem: http://www.statnews.com/2016/01/28/experts-argue-unique-patient-identifier/ As your IAM 101 tutorial makes clear, "The OAuth relationship that Alice forms between the two services therefore can be effectively pseudonymous." Whether UMA likes it or not, it is squarely at the nexus between the pseudonimity of OAuth and the patient ID problem. Pretending that the UMA AS is separable, in practice, from the unique patient identifier simply confuses the issue and the role of HEART. FHIR is a direct connection between two institutions with their separate and hidden primary key for one person. The authorization system that manages that connection is HEART. There are only two possibilities: Either the patient is directly involved in establishing the correspondence of the two primary keys, or some institution is responsible for establishing that correspondence. In the US, for example, we have Surescripts claiming to be able to establish this correspondence for 230 Million people, whether they like it or not. (That's probably more than the NSA wants to claim.) The patient ID problem will be solved by some combination of these two paths. Whether either one uses UMA and HEART is not silly at all. Adrian On Saturday, January 30, 2016, Eve Maler <eve.maler(a)forgerock.com> wrote: > I'm sorry, but this is getting just a bit silly. This is IAM 101. > > When Alice uses any online service, the service knows how to distinguish > her vs. any other individual who uses the service. Typically the mechanism > used is "accounts" and Alice accesses her singular account by confirming > (authenticating) herself*; the service matches that individual to some > primary key associated with the account that can be thought of as an > "identifier". So whatever primary key(s) can serve roughly as an "identity" > for her. > > An AS is a kind of service that typically uses such a mechanism, > particularly when the service serves lots of individuals. An RS is also a > kind of service that typically uses such a mechanism. UMA does not depend > at all on the value of any primary key ("identifier") being the same in > both cases. The OAuth relationship that Alice forms between the two > services therefore can be effectively pseudonymous. > > The way that Alice confirms her identity ("authenticates") to each service > could be strong or weak, as appropriate. Biometrics (not always a guarantee > of authentication strength, particularly when not combined with other > factors/methods) might or might not be involved. > > If a service serves exactly one individual, it's up to that service and > that individual how the two are bound together. In that special case, the > usual IAM mechanisms could be messed with quite a bit, though if you're > building a software stack, it would probably cost a lot more to "go off the > rails" and build all this from scratch than to use off-the-shelf parts and > well-vetted standards that this existing software knows how to work with. > Also people know how to "log in" to services, and they might not know how > to "do something else" to interact with a service that's custom just for > them (though this objection could be overcome, of course). > > Stepping away from authentication, what you (I think) have been talking > about is an AS whose* identity as a service technically literally also > represents the identity of its individual*. That is not the typical job > of any service I know, and UMA hasn't been designed for it either. > > *For techies reading this, I'm not getting into session management here! > :-) > > > *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging > Technology > Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > New ForgeRock Identity Platform <https://www.forgerock.com> with UMA > support <https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA > community <https://forgerock.org/openuma/>! > > On Fri, Jan 29, 2016 at 7:31 AM, Adrian Gropper <agropper(a)healthurl.com > <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: > >> What is singular identity of the RO? Is it equivalent to biometric >> identity a la iris scan done by the RS? >> >> In that case, can the AS be associated with one persona of the RO? >> >> What protocol changes would be required? >> >> Adrian >> >> >> On Friday, January 29, 2016, Eve Maler <eve.maler(a)forgerock.com >> <javascript:_e(%7B%7D,'cvml','eve.maler(a)forgerock.com');>> wrote: >> >>> UMA as designed is well compatible with n ROs and 1 AS, where the AS is >>> an always-on service acting in the interests of each of the ROs in turn. >>> (Think about how a SaaS service represents and serves each of its users >>> without mixing them up.) >>> >>> It can be technically compatible with 1 RO and 1 AS as well in the exact >>> same way, but things start to break down when others in the ecosystem want >>> to make a hard assumption that the *identity* of the AS (as an agent of >>> the RO) is "as good as knowing" the singular identity of the RO it >>> represents. This would require protocol changes. >>> >>> >>> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging >>> Technology >>> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl >>> New ForgeRock Identity Platform <https://www.forgerock.com> with UMA >>> support <https://www.forgerock.com/platform/user-managed-access/> and >>> an OpenUMA community <https://forgerock.org/openuma/>! >>> >>> On Mon, Jan 25, 2016 at 12:31 PM, Adrian Gropper <agropper(a)healthurl.com >>> > wrote: >>> >>>> 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/ >>>> >>> >>> >> >> -- >> >> Adrian Gropper MD >> >> PROTECT YOUR FUTURE - RESTORE Health Privacy! >> HELP us fight for the right to control personal health data. >> DONATE: http://patientprivacyrights.org/donate-2/ >> >> > -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

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

29 Jan '16

What is singular identity of the RO? Is it equivalent to biometric identity a la iris scan done by the RS? In that case, can the AS be associated with one persona of the RO? What protocol changes would be required? Adrian On Friday, January 29, 2016, Eve Maler <eve.maler(a)forgerock.com> wrote: > UMA as designed is well compatible with n ROs and 1 AS, where the AS is an > always-on service acting in the interests of each of the ROs in turn. > (Think about how a SaaS service represents and serves each of its users > without mixing them up.) > > It can be technically compatible with 1 RO and 1 AS as well in the exact > same way, but things start to break down when others in the ecosystem want > to make a hard assumption that the *identity* of the AS (as an agent of > the RO) is "as good as knowing" the singular identity of the RO it > represents. This would require protocol changes. > > > *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging > Technology > Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl > New ForgeRock Identity Platform <https://www.forgerock.com> with UMA > support <https://www.forgerock.com/platform/user-managed-access/> and an OpenUMA > community <https://forgerock.org/openuma/>! > > On Mon, Jan 25, 2016 at 12:31 PM, Adrian Gropper <agropper(a)healthurl.com > <javascript:_e(%7B%7D,'cvml','agropper(a)healthurl.com');>> wrote: > >> 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 >> <javascript:_e(%7B%7D,'cvml','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 >>> <javascript:_e(%7B%7D,'cvml','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 >>>> <javascript:_e(%7B%7D,'cvml','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 >>>> <javascript:_e(%7B%7D,'cvml','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/ >> > > -- 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 1

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

29 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes Date 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-29 - Review the new UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016?sr…> page and the "#trust"-related use cases - Pick off some of the new "#trust" GitHub issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> to work on - Take a look at the documents Scott David shared in email on Jan 15 <https://groups.google.com/forum/#!searchin/kantara-initiative-uma-wg/scott$…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

New OAuth security advisory: "Authorization Server Mix-Up"
by Eve Maler 28 Jan '16

28 Jan '16

To read relevant links and commentary, please see these two OAuth and OpenID Connect email threads: - https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w - http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20160104/0059… If anyone thinks we need to add something beyond our current security considerations, it would be good to open a new issue and propose a severity level. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

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

28 Jan '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-01-28 Date and Time - *Thu Jan 28,* 9-10am PT - Voice: Skype: +99051000000481 or US +1-805-309-2350 (international dial-in lines <https://www.turbobridge.com/join.html>), room code 178-2540# - Screen sharing: http://join.me/findthomas - *NOTE:* *IGNORE* the join.me dial-in line shown here in favor of the dial-in info above (Kantara "line C" and the Skype line) - UMA calendar: http://kantarainitiative.org/confluence/display/uma/Calendar Agenda - Roll call - Approve minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> - V1.0.1 specs are out: Recommendations and I-Ds (see home page) - Thanks, Maciej/Thomas/Oliver! - Other pages are generally updated too - Review the new UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> page and *prioritize our work* - Good F2F <http://kantarainitiative.org/confluence/display/uma/Meetings+and+Minutes> opportunities for working sessions - Good liaison opportunities - How does it make sense to revise our charter <http://kantarainitiative.org/confluence/display/uma/Charter>? - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 3

Introduction
by Kathleen Connor 26 Jan '16

26 Jan '16

Hi everyone, I finally stopped just "lurking" and joined UMA as a voting member. Eve suggested that I introduce myself and let you know why I'm joining the Umatarians. My interest in UMA started while working for Mike Davis, VHA Security Architect, on the Privacy on FHIR [PoF] project, led by ONC and VA, which resulted in a demo at HIMSS 2015. A number of UMA/HEART members were actively involved including: Debbie Bucci, Justin Richer, and Adrian Gropper. And while the PoF project is done or dormant, that work just keeps progressing here, at HL7, IHE, and in ONC projects. Right now, I'm primarily focused on the HL7 FHIR Privacy and Security side of things, and there's increasing interest, talk, pressure for convergence between HL7 FHIR Privacy and Security with UMA/HEART where it makes sense - e.g., using HL7 Security Labels as OAuth claim tokens. As a newly elected cochair of HL7 Security WG, I'll be joining John Moehrke, another cochair, Glen Marshall, and others who regularly attend or monitor UMA to find ways for HL7 Security and Community Based Collaborative Care [CBCC] Work Groups to collaborate. I will also be looking for synergies with the ONC Patient Choice project, which I am currently working on as well. I'm looking forward to the opportunity to be more involved and getting to know the other UMA members. Thanks, K Kathleen Connor Baycliffe Strategies, Inc. Office - 360 357 3536 [Primary] Cell - 360 480 7599

3 2

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