- WG-UMA - mailman.kantarainitiative.org

Is the right to agency core to VRM and to UMA?
by Adrian Gropper 07 Feb '16

07 Feb '16

(Apologies for cross-posting but I think it's appropriate in this case) I'm a member of the hi:project http://hi-project.org/ (click 90 sec. video) Today's newsletter <http://hi-project.org/?wysija-page=1&controller=email&action=view&email_id=…> had interesting links to open banking API initiatives: > *" Retail banks*. Her Majesty's Treasury, ably supported by the Open Data > Institute, is progressing an open banking API > <https://www.gov.uk/government/consultations/data-sharing-and-open-data-in-b…>. > With the involvement of the Open Bank Project > <https://openbankproject.com/about/>, located in Germany. According to > the trade newspaper American Banker, "U.K. Push for Open Bank APIs Makes > U.S. Look So Last Century > <http://www.americanbanker.com/news/bank-technology/uk-push-for-open-bank-ap…> > ." > I don't know what the HM Treasury will conclude after their open banking API "Call for Evidence" but I can see dark clouds for hi:proj, decentralization, and VRM if the Open Bank Project and the American Banker articles are the path. The problem is that these articles promote an app store controlled by the bank rather than the individual. This effectively shuts out open source apps and introduces a rent-seeking app certification process controlled by the bank just like the control by Apple or Google through their app-store. Now, to be sure, I have no problem at all paying my bank a transaction fee for checks or API access. I do however have a big problem if my bank restricts who I can send a check to or what app can connect to my account. This is exactly what I am directly involved in with hehathcare APIs in the US. Here, for example, is my testimony a couple of weeks ago: https://www.healthit.gov/FACAS/sites/faca/files/APITF_Testimony_AdrianGropp… The ability to grant unconstrained ***third party*** access to an API that is all over the HM Treasury call is absolutely essential to decentralization and, I would claim VRM. This is what UMA and HIE of One is all about. It's much easier in US healthcare because US law treats access to patient data as a "right" and will likely impose a corresponding "duty" to respect an individual's right to specify their "agent" for access to the API. In the HIE of One (and hopefully HEART) approaches, the individual specifies the UMA-standard Authorization Server and that Authorization Server, acting as my agent, has sole discretion over what app and what app user can see my data (or is it midata?) at the hospital or the bank. Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Notes from UMA telecon 2016-02-04
by Eve Maler 05 Feb '16

05 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 MinutesRoll call Quorum was not reaching. Approve minutes Deferred. Force-rank use cases What's A and what's B in terms of priority (since we probably can't get more "rank-y" than that)? John W suggests working from "likelihood of error occurring" and "impact of the error". The other factor is "detectability of the error". If the exploit is 100% undetectable, that's bad. This is a good way to prioritize #security work (which is overtly about bugs). For feature work prioritization, we had talked about gathering "customer need" in 2016 or 2017. Mike adds that this could include "developer adoption" – so are we targeting developers and deployers both? "Customers" would typically mean those who know they need UMA. "Developer adoption" is about building community among those who may not know they "need UMA" yet. (This is what Adrian's goal is around an always-on AS, to entice RS and client developers.) George questions that UMA should be looking for adoption in the OAuth fashion. How do we define #wideeco? If we correctly define mechanisms for dynamic onboarding of disparate parties, wouldn't it be the case that the narrower ecosystems would tend to use those mechanisms to build their deployments? The question is whether dynamic mechanisms add too much overhead for static partnerships to be willing to use. So maybe it's not just about correct definition of mechanisms; it's about a continuum of needs. There's definitely a tension present around when to optimize for #wideeco, and what our options are. It's not just about how to gather claims securely from Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them. There are other considerations as well, as we look at the broader implications of what "value-add features" are desired. AI: Eve and James: Share technical paper/thoughts on potential solutions to "Bob when his claims providers and Alice's AS-as-a-claims-client have not pre-established trust between them" So far – all still being discussed: #IoT (Eve), #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco (Adrian, Justin), #trust, #security (Justin, Eve) Justin adds a vote for the issues he submitted that have to do with implementation simplification and, in some cases, making it an OAuth extension grant (?). This needs a new "hashtag". *AI:* Eve: Add a #simplification label and add the self-contained token discussion to that issue. John W notes that constraining sharing based on geolocation would be a good idea. Eve suggests adding an issue on this. *AI:* Eve: Set up one more round of ad hoc #239 meetings next week, in hopes of finishing then. Validation of self-contained token discussion on that back channel: - Mike Schwartz@All: I don't think self-contained tokens is limited to IOT... - Mike Schwartz@All: And also, I'm not sure its possilble... - Justin Richer@All: Self contained tokens are in no way limited to IoT and that's not hte only issue of IoT. And how is it not possible? People have been doing it for many, many years. - George Fletcher@All: agreed that self-contained tokens are limited to IoT. I also think that while we should use JWT for the token syntax there are some real issues to solve here. - Mike Schwartz@All: of course self contained tokens are possible, but the way we defined the RPT flow - Mike Schwartz@All: the RPT gets issued, and its empty - Mike Schwartz@All: and then permissions get added. - Mike Schwartz@All: So its not that RPT can't be self-contained, but it can't be used as an access token - Mike Schwartz@All: because the access token value would change - Justin Richer@All: That's not how we issue RPTs. We don't issue RPTs until there are permissions to it. If we add permissions we'd issue a new RPT which is valid. - George Fletcher@All: Yes, or become a "super" token which has it's own security issues. - Justin Richer@All: Right, super tokens are a big problem in wider cases. Charter revision Deferred. Use case work See the issue #239 meeting series email thread for the continuing notes on that. Attendees As of 20 Jan 2016, quorum is 7 of 12. (Evariste, François, Domenico, Kathleen, Sal, Thomas, Andi, Robert, Maciej, Eve, Søren, Mike) 1. Eve 2. Mike 3. Kathleen 4. Andi Non-voting participants: - Justin - John W - George - Adrian - Sarah - Jin *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

4 4

uma privacy definition
by arr＠worldknowledgebank.com 05 Feb '16

05 Feb '16

Is there an uma definition of privacy? Regards, Ann Racuya-Robbins "When you share what you know in a just way you sustain life and transform the way the world works." Ann Racuya-Robbins Founder Virtual Democratic Countries https://www.worldknowledgebank.com<https://www.worldknowledgebank.com/> 4440 Willard Ave #729 Chevy Chase, MD 20815 and 2 Placita Road, La Puebla, Espanola, New Mexico 87532 202.304.7103, 505.216.5343, 301.951.1809 This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

8 25

Notes from UMA legal telecon 2016-02-05
by Eve Maler 05 Feb '16

05 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+legal+subgroup+notes 2016-02-05 - Term definition work (see issue #240 <https://github.com/KantaraInitiative/wg-uma/issues/240>) – for reference, here are all the open #trust issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> Attending: Eve, Scott, Paul, Jim, John W, Adrian, Ann, Jon N, Mark, Kathleen *Regulation of consent* Should we be concerned about EU regulators "regulating away" the potential power of UMA around proactive enduring consents (e.g., policies that are indefinite until revoked) because on subsequent reference to them by an AS they're not "explicit"? Is there a way to influence the thinking of regulators and/or have two-way conversations with them so that implementations and deployments can give individuals the right buttons and knobs and UX's? It's certainly possible to make appointments with regulators. The US regime has a property basis, whereas the European basis is human rights. Revisiting one's consent in context (monitoring one's consent) would theoretically be a powerful way to exercise one's rights. In the healthcare world, coming from paper vs. digital, notice was expensive. But in the digital world, notice is free at the margin. Mark notes that: "We are working on a model practice papers to send to regulators wth the Kantara sponsored workshops." He will send a note to the list with more information as required. He thinks we don’t think we need to worry about regulators regulating away consent directives, as consent is regulated by purpose and notice. *AI:* John W: Find ways to reach out to regulators to start conversations. *Digital Contracts, Identities, and Blockchain - new event at MIT <http://www.commonaccord.org/index.php?action=doc&file=S/About/Conference/Fl…>* This event has very limited seating and is invitation-only. If you want to attend, let Jim H know soonest! The notion is secure, DRY, peer-to-peer text objects handled as if they were software objects. *Term definitions* Our term definitions of record are here <http://www.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/…> . We can define whatever terms we want, but we don't want to "chase our tails". Agency (here meaning legal agency, the ability to take responsibility) is different from being a hunk of, say, software; software isn't a thinking thing. We're in the business of helping services that want to be, say, IdPs and merchant services and healthcare services *also* be UMA services to create the legal agreements they need, and since they'll be UMA clause novices, we're providing starter UMA clauses for them. Note that an UMA authorization server operator is different from talking about a data processor or data controller. The the former term is an "UMA legal" term of art, and the latter are regulatory terms of art. Wherever we use the latter, we would have to refer to our source of the definition – ISO 29100 <https://www.iso.org/obp/ui/#!iso:std:45123:en> is what CIS refers to for consent receipts. The pairs we currently have are: - resource owner:Authorizing Party - requesting party:Requesting Party - authorization server:Authorization Server Operator - resource server:Resource Server Operator Where things break down: A use case: Alice (Individual) wants dentist's office (Legal Person) to get access to her calendar for the purpose of scheduling a root canal. The dentist's office receptionist (Individual acting on behalf of the Legal Person, as an employee or contractor) tries to access the resource, using a client (Client). Questions: Let's not overcook this. Think in terms (ha) of the next strawman iteration. Since no one expressed strong feelings about making any changes, we will leave the terms as they are till changes are forced on us. 1. Should we give a generic name to the clients, authorization servers, and such? Are they Non-Person Entities as a general category now? What would be the usefulness of this? *Don't add.* 2. We've called the receptionist in this use case a Requesting Party Agent to date. Is that right? What benefit does it confer? There is actually an UMA flow (or possibly several flow options) to which it correlates. *Eve suggests:* Keep for now and try to use it in practice to see if it works. 3. Does UMA want to trace duties to preserve the rights of the Individual? *No further discussion.* 4. Does Individual want to be Natural Person? *Don't change.* 5. Is the ability of the Individual to consent constrained in the circumstances of the transaction, e.g., by regulations? (Think in terms of term definitions for now. This is a much bigger question!) *Don't change anything.*. It seems we have nothing more to discuss on issue #240 unless problems arise. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Joint FHIR - SPM - HEART Meeting at HIMSS16 - Las Vegas Monday 2/29 2-5 PM
by Adrian Gropper 04 Feb '16

04 Feb '16

The leadership of the FHIR standards group has arranged a meeting that should, among other things, facilitate harmonization between the HEART and FHIR workgroups. The meeting will also be a great opportunity for a broader patient perspective than we typically get into standards work. We owe this early success to the Society for Participatory Medicine leadership of Peter Elias and ePatient Dave and the eager engagement of Grahame. Thank you! FHIR has booked a room on Monday 29th Feb 2016, 2-5 pm, at Embassy Suites hotel (http://www.lasvegasembassysuites.com/) There's space for 24 people and we should advertise this to our communities. Please send RSVP to grahame(a)healthintersections.com.au Adrian -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

1 0

Agenda for UMA legal telecon 2016-02-05
by Eve Maler 04 Feb '16

04 Feb '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-02-05 - Term definition work (see issue #240 <https://github.com/KantaraInitiative/wg-uma/issues/240>) – for reference, here are all the open #trust issues <https://github.com/KantaraInitiative/wg-uma/issues?q=is%3Aopen+is%3Aissue+l…> *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Agenda for UMA telecon 2016-01-04
by Eve Maler 03 Feb '16

03 Feb '16

http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-02-04 Date and Time - *Thu Feb 4,* 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 - (Note that a short ad hoc meeting to discuss issue #239 will be held just prior, on the same dial-in) - Roll call - Approve minutes of UMA telecon 2016-01-07 <http://internetidentityworkshop.com/> - Force-rank use cases in our UMA Roadmap for 2016 <http://kantarainitiative.org/confluence/display/uma/UMA+Roadmap+for+2016> page: #IoT, #APIsec, #fedauthz, #RSctrl, #ROctrl, #wideeco, #trust, #security - Appoint a small contingent to look at revising our charter <http://kantarainitiative.org/confluence/display/uma/Charter> - Dig into the top item on our use case pile - AOB *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Putting the new issue in context, including [legal]
by Eve Maler 02 Feb '16

02 Feb '16

In case the technical particulars of issue #239 might have made some folks' eyes glaze over, I wanted to paraphrase it in a couple of different ways to help us all analyze it. The ad hoc meeting this morning was very useful to dig into more details (and I'm sure there's more to come), but at this point we've been focusing most heavily on the tech side. We started thinking in terms of "risk" towards the end of the call, a more subjective and squishy task when we're talking about protocols. (There are a lot of sources on the 'net discussing "threat vs. vulnerability vs. risk"; here's one <http://simplicable.com/new/security-risk-vs-vulnerability-vs-threat>. The idea is that risk has to capture the business upside of doing X with good guys involved, along with the business downside of doing X with bad guys in the mix.) The attack in issue #239 <https://github.com/KantaraInitiative/wg-uma/issues/239>, put in more business-y terms, could be stated this way (Justin et al., please adjust if I've misrepresented too much): Alice has a resource R she wants to share with Bob, and she uses an UMA authorization server and resource server to do so. Before Bob gets as far as actually attempting access to that resource using his legitimate UMA client app C, attacker Eve starts the "UMA dance" using an UMA "attacker client" app AC that has the same identifier as Bob's app. Eve's app manages to "phish" Bob into providing the necessary claims to Alice's AS for some other apparent purpose (not for getting Alice's resource R), and the rest of the UMA flow unfolds in a way that lets Eve get resource R instead of Bob. In legal-y (model text-y) terms, we could observe that: - Alice the RO (Authorizing Party or AuthzP), the resource server operator (RSO), the authorization server operator (ASO), and possibly the Client Operator??, are all let down because resource R is ultimately exposed to Eve (the attacker) and not the intended RqP, Bob. This is really bad. - Also, the ASO has been tricked into collecting claims outside of the intended purpose of authorizing access to the AuthzP's resources. I think we have a model clause about how the ASO needs to be restrained about why to collect claims. - However, Bob (RqP) has exposed his claims to an ASO that he does have an authorization API token (AAT) with, and that ASO normally would hang onto his tokens for legitimate access to various resources. Not sure if that makes this a "breach" of his claims or not. - (There's maybe some other observations we could make here...) All in all, it's a great use case for the model text work. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

1 0

Ad hoc WG meeting tomorrow at 8am PT to work on issue #239
by Eve Maler 02 Feb '16

02 Feb '16

This week's schedule is to meet tomorrow at 8-9am PT/10-11am CT/11am-noon ET/4-5pm UK/5-6pm CET at our usual number. (At that time, we'll discuss whether to also meet during the half-hour before our Thursday call.) Sorry for the last-minute notice... It seemed we would reach critical mass among a sufficiently techie crowd at this time. We'll figure out our schedule on a weekly basis for working on this issue. This call is now on our online calendar: http://kantarainitiative.org/confluence/display/uma/Calendar If you'd like an invite, let me know. The progressive agenda for this meeting series: - Analyze the nature of the vulnerability and the use cases at risk at the various time horizons (now/near-future/far-future) to be sure we understand its parameters - Analyze the proposed mitigations and see if there are any others we have missed - Assemble pros and cons for the mitigations and the forms in which they can be "packaged" to bring forward to the whole WG *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

2 1

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