[Openid-specs-heart] CHIME Launches $1M Challenge to Solve Patient ID Problem

Adrian Gropper agropper at healthurl.com
Mon Jan 25 20:31:42 UTC 2016


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 at 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 at 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 at 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 at healthurl.com
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jan 25, 2016 at 11:49 AM, Josh Mandel <
>>>> Joshua.Mandel at 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 at 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 at 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 at 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 at 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 at 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 at 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_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=>
>>>>>>>>>> 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 at 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 at 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 at 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 at 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=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=qupbYXH4yZuzhNsgW0jcwq786o--G6D1m7GlkENe1lw&e=>
>>>>>>>>>>>>>> https://webfinger.net/
>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>> 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 at 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 at securityrs.com>
>>>>>>>>>>>>>>> Date: 2016/01/24 7:07 AM (GMT-08:00)
>>>>>>>>>>>>>>> To: HEART List <openid-specs-heart at 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_Halting-5Fproblem&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=eVT2hXrUini0He7H6c-zHwPxd4ROV6nwfZ53AECX76o&e=>
>>>>>>>>>>>>>>> .)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.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=>http://www.healthdatamanagement.com/news/chime-launches-1m-challenge-to-solve-patient-id-problem
>>>>>>>>>>>>>>> <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=>*
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *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 at securityrs.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>>> www.SecurityRiskSolutions.com
>>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Openid-specs-heart mailing list
>>>>>>>>>>>>>>> Openid-specs-heart at lists.openid.net
>>>>>>>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>> http://patientprivacyrights.org/donate-2/
>>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart <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=>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>>>>>> http://patientprivacyrights.org/donate-2/
>>>>>>>>>>>>> <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=>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=2VMieJq3EmwTLglsueFRPjnL6SoON964_PI0l93fF_Q&s=z-4rXqaGl6wWaDWmWBhUiw11pQ596WWRLsAHF3kxUgM&e=>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Openid-specs-heart mailing list
>>>>>>>>>>> Openid-specs-heart at lists.openid.net
>>>>>>>>>>>
>>>>>>>>>>> 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=
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=6qsDGXlfn6YB2nKRHOhQbq7-F60_1nlM8F6SOwyMwac&s=rAJTxml04Ym8Bi0-vj0w_QpsXopAevr1vwGI1Qko-Jw&e=>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=1UaGqWJeKd4UdDAld99dOkLSgTEJUfV8Vu3sylh0h5E&s=mJ4JXE5T1szAX1UEoejeV2TSq_kh1t6enN2DsyBOd5g&e=>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> 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.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=w3SjjqRMdmtH3aphsxB60HkTmVUKOv5ObNc_9eJxmtY&s=5L56gsnzOm5hcTK0lJvbihx2PFR-5L-hscdP5z__0WE&e=>
>>>>
>>>
>>>
>>
>> --
>>
>> 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 at 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160125/90987a78/attachment-0001.html>


More information about the Openid-specs-heart mailing list