<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So that sounds like you're putting in a chip for Josh's option (a):
do all the things.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 7/1/2015 5:24 AM, Eve Maler wrote:<br>
</div>
<blockquote
cite="mid:CAMPbGmiU99K81siB83mC70oxXAydd8ey670J-nc-t857k1EbMg@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">After overnight reflection (I'm in the UK at the
moment), I might have been a bit unclear in my previous message,
and may have come off sort of harsh. If so, I'm sorry about
that!
<div><br>
</div>
<div>What I guess I mean is, in our daily lives, we are among
the various parties in the world who are working on use cases
that go through a technology selection process and end up
choosing OAuth, UMA, OIDC, a variety of APIs, solution stacks,
etc. With our "HEART hats" on, it's our responsibility
according to our charter to scan the use case and technology
selection landscape and be sure we're paying attention to both
our own and others' experiences along these lines and covering
design patterns that are worth profiling for security,
privacy, and interop on several levels. It's not our
responsibility to eliminate design pattern options.</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<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>
Join our <a moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org OpenUMA</a>
community!</p>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Tue, Jun 30, 2015 at 7:21 PM, Eve
Maler <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:eve.maler@forgerock.com" target="_blank">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 a little confused about this thread.
<div><br>
</div>
<div>We first launched the group with a discussion that
looked like this: "We are going to profile a variety of
technologies. For those who want to deploy technology
foo, the profile for foo will be of interest to them.
For those who want to deploy technology bar which builds
on foo, the profiles for both foo and bar will be of
interest to them." and so on.</div>
<div><br>
</div>
<div>Eventually we produced a picture that looked
something like this (this is my latest, prettiest
version):
<div><br>
</div>
<div><img src="cid:part3.02050508.02070208@mit.edu"
alt="Inline image 1" height="241" width="472"><br>
</div>
<div>Obviously, where vanilla OAuth will suffice, it's
interesting because it's widely deployed and
understood. But for some OAuth-esque flows, UMA can
provide additional value, and FWIW, I'm in some
conversations where this is being requested.<br>
</div>
<div><br>
</div>
<div>
<div>If someone is interested to do something with
OAuth towards the purpose of "enabling an individual
to control the authorization of access to RESTful
health-related data sharing APIs", of course we
should consider profiling that function. Likewise,
if someone is interested to do something with UMA
towards that purpose, according to our charter, I
would have said we should consider profiling that
function.</div>
<div><br>
</div>
<div>
<div>So I don't understand the question [highlight
is mine] "<span
style="font-size:12.8000001907349px">When HEART
encounters a use case like this, by which
principle(s) we should <b>select</b> vanilla
OAuth vs. UMA?</span>"</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><span class="HOEnZb"><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 moz-do-not-send="true"
href="tel:%2B1%20425.345.6756"
value="+14253456756" target="_blank">+1
425.345.6756</a> | Skype: xmlgrrl |
Twitter: @xmlgrrl<br>
Join our <a moz-do-not-send="true"
href="http://forgerock.org/openuma/"
target="_blank">ForgeRock.org OpenUMA</a>
community!</p>
</div>
</div>
</div>
</div>
</div>
</font></span>
<div>
<div class="h5">
<br>
<div class="gmail_quote">On Tue, Jun 30, 2015 at 2:45
PM, Aaron Seib <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org"
target="_blank">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 link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Josh
– I agree and support the notion of
soliciting input from those who have
implemented these types of solutions in
the past. Ensuring that we don’t define
requirements that are unimplementable is
pragmatic but we should not forget that
the healthcare system alleges to be
consumer centric, not software developer
centric.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">We
shouldn’t abandon appropriate principles
because it cost more to realize every time
we tackle this problem as a nation.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Josh Mandel [mailto:<a
moz-do-not-send="true"
href="mailto:Joshua.Mandel@childrens.harvard.edu"
target="_blank">Joshua.Mandel@childrens.harvard.edu</a>]
<br>
<b>Sent:</b> Tuesday, June 30, 2015 8:57
AM<br>
<b>To:</b> Aaron Seib; Adrian Gropper<br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a></span></p>
<div>
<div><br>
<b>Subject:</b> Re: [Openid-specs-heart]
Principles for selecting "Vanilla" OAuth
vs. UMA</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<p>It would be valuable to solicit input
in this discussion from software
developers who will actually be
implementing these services, or who have
implemented these services in the past.
The relative weight and merit of "KISS"
needs to be informed by the implementer
community. Otherwise we risk defining
principles that work great as principle
but lead to downstream implementation
pain. </p>
<p>For what it's worth, vanilla OAuth
certainly supports views of who's
authorized and the ability to revoke
access -- within one authorization
server at a time. And Adrian's
"principle T" could clearly be built in
a cross-AS way with vanilla OAuth
(essentially as a logging API where the
user specifies a logging endpoint). </p>
<p>Best, </p>
<p>Josh </p>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">On Tue, Jun 30,
2015, 08:39 Aaron Seib <<a
moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org"
target="_blank">aaron.seib@nate-trust.org</a>>
wrote:</p>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc 1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">+1
Adrian.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
believe that the consumer
should be able to go to a
management portal and see who
is authorized to access their
data and be able to deactivate
that access when they no
longer want the relationship
to exist. </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
have seen products that
support this functionality
today – not sure if it was
OAuth only that supported it.</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib, CEO</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(o)
<a moz-do-not-send="true"
href="tel:301-540-2311"
value="+13015402311"
target="_blank">301-540-2311</a></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a moz-do-not-send="true"
href="tel:301-326-6843"
value="+13013266843"
target="_blank">301-326-6843</a></span></p>
<p class="MsoNormal"><a
moz-do-not-send="true"
href="http://nate-trust.org"
target="_blank"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img
src="cid:part12.09010909.09010501@mit.edu" border="0" height="48"
width="205"></span></a></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:agropper@gmail.com"
target="_blank">agropper@gmail.com</a>
[mailto:<a
moz-do-not-send="true"
href="mailto:agropper@gmail.com"
target="_blank">agropper@gmail.com</a>]
<b>On Behalf Of </b>Adrian
Gropper<br>
<b>Sent:</b> Monday, June 29,
2015 10:02 PM<br>
<b>To:</b> Aaron Seib<br>
<b>Cc:</b> Josh Mandel; <a
moz-do-not-send="true"
href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b> Re:
[Openid-specs-heart]
Principles for selecting
"Vanilla" OAuth vs. UMA</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Also,
as we debate what KISS
actually means in
terms of HEART, please
allow me to propose a
second Principle.</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><b>Principle
T - (T is for
Transparency) - Any
HEART transaction
between Client and
Resource Server that
includes individual
patient-level
information MUST post
a contemporaneous
accounting for
disclosures message to
any endpoint specified
by the patient.</b></p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Please
note that Accounting for
Disclosures is required by
HIPAA but has been widely
ignored as "too hard" with
legacy protocols. I hope
that HEART use-cases
related to HIPAA take this
requirement to heart.
There are various
interpretations of
Accounting for
Disclosures. Some would
require the patient to
visit each resource server
patient portal the way we
check bank statements.
Another interpretation
would send the patient a
simple notice the way many
banks email you when a
pre-authorized monthly
payment is made. Most of
us that are now signing
into three or more banks a
month to look at the
register would agree that
being able to set a notice
address and a policy for
when to be notified is a
preferable and more
scalable approach. </p>
</div>
<p class="MsoNormal">I suggest
that we have to make
"contemporaneous accounting
for disclosures to any
patient specified endpoint"
a HEART principle and take
that into account when we
consider the complexity of
profiling OAuth or profiling
UMA for every use-case.</p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><br>
Adrian</p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">On Mon,
Jun 29, 2015 at 6:32 PM,
Adrian Gropper <<a
moz-do-not-send="true"
href="mailto:agropper@healthurl.com"
target="_blank">agropper@healthurl.com</a>>
wrote:</p>
<div>
<div>
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">+1
Aaron.<br>
<br>
Here's a principle I
would suggest:</p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><b>Principle
A - If the Resource
Owner takes
responsibility for a
HEART transaction
between Client and
Resource Server, then
the transaction MUST
go through and the RS
gets a safe harbor.</b>
</p>
</div>
<p class="MsoNormal">Adrian</p>
</div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal">On
Mon, Jun 29, 2015 at
5:39 PM, Aaron Seib
<<a
moz-do-not-send="true"
href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>>
wrote:</p>
</div>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in 0in
0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Josh
– I almost
didn’t pick up
on your bias
but the
parenthetical
gave it away.</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
almost always
agree that
starting with
the simplest
set of tools
first and
incrementally
expanding is
the best
approach but
the fact of
the matter is
that we did
this with
Direct and
said that
Direct is just
Transport and
the policy
enforcement
and
representation
of Patient
Privacy
Preferences
would emerge
as needed. I
think Direct
has been
around as a
concept for
three or four
years now and
despite widely
broadcast
claims to the
contrary the
only use cases
that it is
frequently
used for are
the simplest –
like those you
can solve with
OAuth alone.</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
am sure that
there is more
to consider
but as a
counter point
to your
somewhat
hidden bias I
would offer
another veiled
bias to not
repeat the
mistakes of
the past and
actually
accept that
someone has to
solve the hard
problems cause
there are not
that many easy
ones in
healthcare.</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
would like to
suggest that
we rise to the
challenge and
pursue a path
that will have
a broader
impact with
this effort.
If we are just
talking about
transport
between two
trusted end
points where
the users
already trust
one another I
think there is
a methodology
on hand to
handle that.
What we need
is something
that can
handle a
little more
complexity.</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I
will take my
beatings from
the community
for speaking
out on this
issue if
everyone
thinks I am
nuts.</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron
Seib, CEO</span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(o)
<a
moz-do-not-send="true"
href="tel:301-540-2311" target="_blank">301-540-2311</a></span></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m)
<a
moz-do-not-send="true"
href="tel:301-326-6843" target="_blank">301-326-6843</a></span></p>
<p
class="MsoNormal"><a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=wEMNkvG4CHEP-h0wUM8o3RjqoJmPW_nF0iRLkXeVzbk&e="
target="_blank"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img
src="cid:part21.08000203.08040302@mit.edu" border="0" height="48"
width="205"></span></a></p>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p
class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
Openid-specs-heart
[mailto:<a
moz-do-not-send="true"
href="mailto:openid-specs-heart-bounces@lists.openid.net"
target="_blank">openid-specs-heart-bounces@lists.openid.net</a>]
<b>On Behalf
Of </b>Josh
Mandel<br>
<b>Sent:</b>
Monday, June
29, 2015 5:13
PM<br>
<b>To:</b> <a
moz-do-not-send="true" href="mailto:openid-specs-heart@lists.openid.net"
target="_blank">openid-specs-heart@lists.openid.net</a><br>
<b>Subject:</b>
[Openid-specs-heart]
Principles for
selecting
"Vanilla"
OAuth vs. UMA</span></p>
<div>
<div>
<p
class="MsoNormal"> </p>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">On today's call we discussed a use case where a
patient can
help connect
her patient
portal (a.k.a.
her EHR
account)
account to an
external PHR.
This is a
great, common
use case that
we know we
could handle
with either
"vanilla"
OAuth, or UMA,
or both. Of
course,
software
systems need
to know, up
front, whether
they'll be
talking
vanilla OAuth
or UMA --
because the
wire protocols
are different.</span></p>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">The question: When HEART encounters a use case
like this, by
which
principle(s)
we should
select vanilla
OAuth vs. UMA?
Some examples
of principles
(to stimulate
discussion)
might be:</span></p>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:9.5pt">Example principle #1: "Do all the things"</span></b></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">We should produce two profiles each time this
kind of
situation
comes up: one
describing how
to do it with
vanilla OAuth,
and one
describing how
to do it with
UMA. This
provides
maximum
flexibility
for
implementers
with different
needs/contexts. </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:9.5pt">Example principle #2: "KISS"</span></b></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">Any time vanilla OAuth can handle a use case, we
should use
vanilla OAuth.
Save UMA for
when it's
required. This
provides a
simpler
environment
with fewer
moving parts
and stronger
out-of-the-box
software
library
support. </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:9.5pt">Example principle #3: "UMA everywhere"</span></b></p>
</div>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">Use UMA across the board, and avoid vanilla
OAuth. Since
UMA handles a
more general
set of use
cases, and
there's value
in
consolidation,
UMA should be
the preferred
option in all
cases. This
way,
implementers
only ever need
to do one
(very general)
thing.</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">(I've tried to state these examples neutrally,
but I must
admit bias in
favor of #2.
Does that come
through?)</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt">Looking forward to discussion,</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.5pt"> -Josh</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">_______________________________________________<br>
Openid-specs-heart
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a
moz-do-not-send="true"
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=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=LecIgXIFC9tivHNWP-gc4XTuasRZYGvNaV4ZFNFCnEg&e="
target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a></p>
</blockquote>
</div>
<p class="MsoNormal"><span
style="color:#888888"><br>
<br clear="all">
<br>
-- </span></p>
<div>
<div>
<p class="MsoNormal"><span
style="color:#888888">Adrian Gropper MD</span><span
style="font-size:7.5pt;color:#888888"><br>
</span><span
style="font-size:10.0pt;color:#888888">Ensure
Health Information
Privacy. Support
Patient Privacy
Rights.<br>
<a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=4hShFnNwgWw3-5xNU7OurqLFaHiaM9OneSrzGCWHmbw&e="
target="_blank">http://patientprivacyrights.org/donate-2/</a></span><u><span
style="font-size:10.0pt;color:blue"> </span></u></p>
<p class="MsoNormal"><span
style="color:#888888"> </span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- </p>
<div>
<div>
<p class="MsoNormal">Adrian
Gropper MD<span
style="font-size:7.5pt"><br>
</span><span
style="font-size:10.0pt">Ensure
Health Information
Privacy. Support Patient
Privacy Rights.<br>
<a
moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=4hShFnNwgWw3-5xNU7OurqLFaHiaM9OneSrzGCWHmbw&e="
target="_blank">http://patientprivacyrights.org/donate-2/</a><u><span
style="color:blue">
</span></u></span></p>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a moz-do-not-send="true"
href="mailto:Openid-specs-heart@lists.openid.net"
target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a moz-do-not-send="true"
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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Openid-specs-heart mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a>
</pre>
</blockquote>
<br>
</body>
</html>