<div dir="ltr">I'm sorry, but this is getting just a bit silly. This is IAM 101.<div><br></div><div>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.<div><br></div><div>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.</div><div><br></div><div>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.<br><div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Stepping away from authentication, what you (I think) have been talking about is an AS whose<i> identity as a service technically literally also represents the identity of its individual</i>. That is not the typical job of any service I know, and UMA hasn't been designed for it either.</div><div class="gmail_extra"><br></div><div class="gmail_extra">*For techies reading this, I'm not getting into session management here! :-)</div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>New <a href="https://www.forgerock.com" target="_blank">ForgeRock Identity Platform</a> with <a href="https://www.forgerock.com/platform/user-managed-access/" target="_blank">UMA support</a> and an <a href="https://forgerock.org/openuma/" target="_blank">OpenUMA community</a>!</p></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Jan 29, 2016 at 7:31 AM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What is singular identity of the RO? Is it equivalent to biometric identity a la iris scan done by the RS?<div><br></div><div>In that case, can the AS be associated with one persona of the RO?</div><div><br></div><div>What protocol changes would be required?</div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Adrian</font></span><div><div class="h5"><br><br>On Friday, January 29, 2016, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.)<div><br></div><div>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 <i>identity</i> 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.</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>New <a href="https://www.forgerock.com" target="_blank">ForgeRock Identity Platform</a> with <a href="https://www.forgerock.com/platform/user-managed-access/" target="_blank">UMA support</a> and an <a href="https://forgerock.org/openuma/" target="_blank">OpenUMA community</a>!</p></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 25, 2016 at 12:31 PM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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 : ?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">Adrian<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 3:23 PM, Eve Maler <span dir="ltr"><<a>eve.maler@forgerock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm very glad to see this clear elucidation of where the splits in understanding/belief are.<div><br></div><div>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 <a href="http://kantarainitiative.org/confluence/display/uma/Charter" target="_blank">charter</a> and <a href="http://kantarainitiative.org/confluence/display/uma/UMA+Requirements" target="_blank">requirements and design principles</a>.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<span><font color="#888888"><br></font></span></div></div></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div></font></span><div><div>
<br><div class="gmail_quote">On Mon, Jan 25, 2016 at 9:32 AM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(apologies for cross-posting)<div><br></div><div>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.<div><br></div><div>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).</div><div><br></div><div>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.</div><span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">Adrian</font></span><div><div><br><br>On Monday, January 25, 2016, Josh Mandel <<a>Joshua.Mandel@childrens.harvard.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Also, I can't help responding to the following comment that you made on #5:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">You're mixing up the identity of an authorization service with the identity of a user or persona.</blockquote><div><br></div><div> -- 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 :-)</div><div><br></div><div> -J </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 11:56 AM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel <span dir="ltr"><<a>Joshua.Mandel@childrens.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div><br></div><div>1. UMA allows a user to stand up her own Authorization Server</div></div></blockquote></span><div>Yes <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>2. UMA does not require a user to stand up her own Authorization Server</div></div></blockquote></span><div>I don't know. It may be that's the only way for an UMA-like approach to privacy and security to scale. <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>3. Given #2, an UMA-based protocol cannot assume that every user will stand up her own Authorization Server</div></div></blockquote></span><div>Why not? Can't a service host an arbitrary number of AS? <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>4. Given #3, an UMA-based protocol must assume that some Authorization Servers will work on behalf of multiple users</div></div></blockquote></span><div>That depends on how we choose to define Authorization Server. <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>5. Given #4, an UMA-based protocol cannot equate an Authorization Server's identity with a user's identity</div></div></blockquote></span><div>You're mixing up the identity of an authorization service with the identity of a user or persona. <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>6. Given #5, an UMA-based protocol cannot use an Authorization Servers public key to identify a user.</div></div></blockquote></span><div>It's all in how we define Authorization Server, isn't it?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Adrian <br></div></font></span><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Is there a point at which you disagree?</div><span><font color="#888888"><div><br></div><div> -J <br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 11:40 AM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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. <br><br></div>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? <br><span><font color="#888888"><br></font></span></div><span><font color="#888888">Adrian<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 11:34 AM, Josh Mandel <span dir="ltr"><<a>Joshua.Mandel@childrens.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<span><font color="#888888"><div><br></div><div> -J</div></font></span><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 11:26 AM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Justin, <br><br>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. <br><br></div>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?<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">Adrian<br></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 11:02 AM, Justin Richer <span dir="ltr"><<a>jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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? <span><font color="#888888"><div><br></div><div> — Justin</div></font></span><div><div><div><br><div><blockquote type="cite"><div>On Jan 25, 2016, at 10:52 AM, Adrian Gropper <<a>agropper@healthurl.com</a>> wrote:</div><br><div><div dir="ltr"><div><div>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". <br><br></div>The way encryption is handled between the RS and Client follows from the above.<br><br></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 10:38 AM, Josh Mandel <span dir="ltr"><<a>Joshua.Mandel@childrens.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>But even if you do so, the AS's jwk in HEART<b> isn't really an "encryption key" sense in the way Adrian would have it</b>. In other words, the AS's jwk is not used as an "encryption key" for the patient's healthcare data at any point. (It <i>is</i> used to sign tokens in the UMA flow, including the PAT and the AAT.)</div><div><br></div><div>By the way, <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.bitbucket.org_HEART_openid-2Dheart-2Duma.html-23rfc.section.2.1&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=h493E96bkQd-wdHQtG9rOI29YYNBoODJ5dv5jBohH8M&e=" target="_blank">http://openid.bitbucket.org/HEART/openid-heart-uma.html#rfc.section.2.1</a> 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).</div><div><br></div><div> -J</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Mon, Jan 25, 2016 at 10:02 AM, Adrian Gropper <span dir="ltr"><<a>agropper@healthurl.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">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.<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 25, 2016 at 9:55 AM, Justin Richer <span dir="ltr"><<a>jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
But it's not like that, the arity is very different. <br>
<br>
Every record is associated with an AS, perhaps a separate AS for
each record/patient but most likely not.<br>
<br>
Every AS is associated with a jwks_uri, but only one per AS. <br><span><font color="#888888">
<br>
-- Justin</font></span><div><div><br>
<br>
<div>On 1/25/2016 9:02 AM, Adrian Gropper
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">It means that every patient record is associated
with a separate jwks_uri for that patient's AS.<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jan 25, 2016 at 8:59 AM, Justin
Richer <span dir="ltr"><<a>jricher@mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Yes you did. Quote:<span><br>
<br>
"The system is also much more resistant to data breaches
as data holders (UMA Resource Servers) must implement
separate <b>encryption keys </b>for each patient."<br>
<br>
</span> 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. <br>
<span><font color="#888888"> <br>
-- Justin</font></span>
<div>
<div><br>
<br>
<div>On 1/25/2016 8:57 AM, Adrian Gropper wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>I never said anything about how the data is
encrypted. I only talk about how access to the
FHIR API is controlled.<br>
<br>
</div>
Adrian<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jan 25, 2016 at
8:55 AM, Justin Richer <span dir="ltr"><<a></a><a>jricher@mit.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Adrian,<br>
<br>
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.<span><font color="#888888"><br>
<br>
-- Justin</font></span>
<div>
<div><br>
<br>
<div>On 1/25/2016 8:52 AM, Adrian
Gropper wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>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.)<br>
<br>
</div>
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.<br>
<br>
</div>
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 <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=" target="_blank"></a><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__webfinger.net_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=" target="_blank">https://webfinger.net/</a>
as a standardized way to discover
linked attributes such as the
patient's UMA Authorization Server
and the associated public key. <br>
<br>
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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Adrian<br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Jan
24, 2016 at 1:20 PM, Aaron Seib <span dir="ltr"><<a></a><a>aaron.seib@nate-trust.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>I appreciate your
expertise and action. </div>
<div><br>
</div>
<div>I don't necessarily agree
with some of your statements
here but that is the beauty
of open processes. </div>
<div><br>
</div>
<div>Let's strive to do all we
can - together.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><span style="font-size:15.4224px">Aaron
Seib</span>
<div><span style="font-size:17.489px">@CaptBlueButton<br>
</span>
<div dir="auto"><span style="font-size:15.4224px" dir="auto">(O) <a href="tel:301-540-9549" value="+13015409549" target="_blank">301-540-9549</a></span></div>
<div dir="auto"><span style="font-size:15.4224px" dir="auto">(M) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a></span></div>
<div dir="auto"><span style="font-size:15.4224px" dir="auto"><br>
</span></div>
<div dir="auto"><span style="font-size:15.4224px" dir="auto">"The trick
to earning trust is to
avoid all tricks.
Including tricks on
yourself."</span></div>
<div dir="auto"><br>
</div>
</div>
</div>
<div>
<div><br>
<br>
-------- Original message
--------<br>
From: "Glen Marshall
[SRS]" <<a></a><a>gfm@securityrs.com</a>>
<br>
Date: 2016/01/24 7:07 AM
(GMT-08:00) <br>
To: HEART List <<a></a><a>openid-specs-heart@lists.openid.net</a>>
<br>
Subject:
[Openid-specs-heart] CHIME
Launches $1M Challenge to
Solve Patient ID Problem <br>
<br>
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.<br>
<br>
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 <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Halting-5Fproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=eVT2hXrUini0He7H6c-zHwPxd4ROV6nwfZ53AECX76o&e=" target="_blank">halting
problem</a>.)<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
<i>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.</i><i><br>
</i><i><br>
</i><i><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=" target="_blank"></a><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.healthdatamanagement.com_news_chime-2Dlaunches-2D1m-2Dchallenge-2Dto-2Dsolve-2Dpatient-2Did-2Dproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=_qW1n-yVrg_DP1kqs-CW-XiipWZapB1GXpTiUdB-pMo&e=" target="_blank">http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem</a></i><br>
<div>-- <br><p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk
Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC
29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610)
644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610)
613-3084</a><br>
<a></a><a>gfm@securityrs.com</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=" target="_blank"></a><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.SecurityRiskSolutions.com&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=sO0EFn2RDc6nTcNVSjD-lEfCdZqy-TatdAT6ccpnTZI&e=" target="_blank">www.SecurityRiskSolutions.com</a></p>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openid.net</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian
Gropper MD<span style="font-size:11pt"></span><br>
<br>
<span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT
YOUR FUTURE -
RESTORE Health
Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for
the right to
control personal
health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank"><span style="color:#0563c1"></span></a><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank"></a><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank">http://patientprivacyrights.org/donate-2/</a></span><span style="color:#1f497d"></span> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Openid-specs-heart mailing list
<a>Openid-specs-heart@lists.openid.net</a>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br>
<br>
<span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT
YOUR FUTURE - RESTORE Health
Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for the right to
control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank"><span style="color:#0563c1"></span></a><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank">http://patientprivacyrights.org/donate-2/</a></span><span style="color:#1f497d"></span> </div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div><br>
<div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br>
<br>
<span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT
YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
HELP us fight for the right to control
personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>
DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openid.net</a><br>
</div></div><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQICAg&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=YlZbL57zFJCHlm8lTsjPaao9DWipNm9s50Q8ZFOgk54&e=</a><br>
<br>
<br></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=1UaGqWJeKd4UdDAld99dOkLSgTEJUfV8Vu3sylh0h5E&s=mJ4JXE5T1szAX1UEoejeV2TSq_kh1t6enN2DsyBOd5g&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><div><div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=w3SjjqRMdmtH3aphsxB60HkTmVUKOv5ObNc_9eJxmtY&s=5L56gsnzOm5hcTK0lJvbihx2PFR-5L-hscdP5z__0WE&e=" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>
</blockquote></div><br></div></div>
</blockquote></div></div></div></div><div><div><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div><br>
</div></div><br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a>Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div><div class="HOEnZb"><div class="h5"><br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div><br>
</div></div></blockquote></div><br></div></div></div></div></div>