<div dir="ltr">Adrian,<div><br></div><div>I think what Aaron is pointing out is that your first bullet is perfectly legitimate for a organization like HEART. Your second bullet is a declaration of a specific 'policy', and HEART can't declare policy. HEART can make it more easy to do some policies, but there is no way for any specification to declare that it shall not be used in a way that is disagreeable by the writers of that specification. I agree with your intent, however it is useless for a specification to say things like this, and it can be detrimental to try.</div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M +1 920-564-2067<br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</div></div></div>
<br><div class="gmail_quote">On Wed, Aug 31, 2016 at 11:34 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"><div dir="ltr"><div><div>Aaron, I don't understand what you are saying, please say more. <br><br>Note that I use HEART in the sense that a "profile of UMA" specifies some policy and technical restrictions that drive interoperability. For example, when our profile says you MUST support dynamic client registration, that's both a policy and a technical statement.<br><br></div>What are you trying to achieve?<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Adrian<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 31, 2016 at 12:20 PM, Aaron Seib <span dir="ltr"><<a 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">I am not sure how it limits Alice’s ability to specify any AS for a HEART resource at all. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">There is no forcing function that requires and RS to be able to use her AS is the issue.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Technology alone does not solve that problem.<u></u><u></u></span></p><span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron Seib, CEO<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> (o) <a href="tel:301-540-2311" value="+13015402311" target="_blank">301-540-2311</a><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">(m) <a href="tel:301-326-6843" value="+13013266843" target="_blank">301-326-6843</a><u></u><u></u></span></p><p class="MsoNormal"><a 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:image001.jpg@01D20382.01808F40" width="205" border="0" height="48"></span></a><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p></span><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 href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Wednesday, August 31, 2016 11:09 AM<br><b>To:</b> Eve Maler<br><b>Cc:</b> HEART List</span></p><div><div><br><b>Subject:</b> Re: [Openid-specs-heart] An approach to data portability for the RO's policies<u></u><u></u></div></div><p></p><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Are we all in wild agreement here that a policy-sharing API is nice to have but:<u></u><u></u></p><ul type="disc"><li class="MsoNormal">optional, a feature to be standardized in some future version of UMA, and<u></u><u></u></li><li class="MsoNormal">not to be used to limit Alice's ability to specify any AS for a HEART resource?<u></u><u></u></li></ul><p>Adrian<u></u><u></u></p><p><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 11:03 AM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<u></u><u></u></p><div><p class="MsoNormal">Another use case for a policy sharing API: how a resource owner's new AS can <i>import</i> polices held by a previous non-UMA-enabled service.<u></u><u></u></p></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>London and Paris!</b><u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 7:44 AM, John Moehrke <<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>> wrote:<u></u><u></u></p><div><p class="MsoNormal">HI All,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Policy portability is the scope that the FHIR Consent is focused on. So this use-case is one for which HEART has an interest in FHIR Consent. This not the only encoding of policy, but might be better to focus on enforcement, while pointing at FHIR Consent for portability.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">John<u></u><u></u></p></div></div><div><p class="MsoNormal"><span style="color:#888888"><br clear="all"><u></u><u></u></span></p><div><div><div><p class="MsoNormal"><span style="color:#888888">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M <a href="tel:%2B1%20920-564-2067" target="_blank">+1 920-564-2067</a><br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/jo<wbr>hnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.b<wbr>logspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")<u></u><u></u></span></p></div></div></div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 9:24 AM, Nancy Lush <<a href="mailto:nlush@lgisoftware.com" target="_blank">nlush@lgisoftware.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">Hi Andrew and Eve,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">I am with you. Policy portability is a topic that has surfaced as we consider use cases for HEART implementation. Thanks for sharing this, Eve.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">I do think we should define a continuum of what can be achieved ‘Now’, what ‘Not Yet’ and what is in the future. We need to be able to talk about the ‘not yet’ and ‘future’ solutions without getting bogged down. There are so many benefits to the most basic features that we should try to nail those as a top priority. </span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d">-Nancy</span><u></u><u></u></p><p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@lists.openid.net</a>] <b>On Behalf Of </b>Andrew Hughes<br><b>Sent:</b> Wednesday, August 31, 2016 9:50 AM<br><b>To:</b> Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>><br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openi<wbr>d.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] An approach to data portability for the RO's policies</span><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Hi Eve - please don't be discouraged. <u></u><u></u></p><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Policy portability is important for many reasons, not least to prevent lock-in to a specific technology or UMA component provider - I hope others on the list chime in to debate the proposal and understand the implications for the full range of use cases that the group is studying.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">andrew.<u></u><u></u></p></div></div></div></div></div><div><div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><div><div><div><p><b>Andrew Hughes </b><span style="font-size:7.5pt">CISM CISSP <br></span>Independent Consultant<br><b>In Turn Information Management Consulting</b><u></u><u></u></p><p><span style="font-size:10.0pt;font-family:"Helvetica","sans-serif";color:#212121">o <a href="tel:%2B1%20650.209.7542" target="_blank">+1 650.209.7542</a><br></span>m <a href="tel:%2B1%20250.888.9474" target="_blank">+1 250.888.9474</a><br><span style="font-size:7.5pt">1249 Palmer Road,<br>Victoria, BC V8P 2H8</span><br><a href="mailto:AndrewHughes3000@gmail.com" target="_blank"><span style="font-size:7.5pt">AndrewHughes3000@gmail.com</span></a><span style="font-size:7.5pt"> </span><br><span style="font-size:7.5pt"><a href="http://ca.linkedin.com/pub/andrew-hughes/a/58/682/" target="_blank">ca.linkedin.com/pub/andrew-hug<wbr>hes/a/58/682/</a><br><b>Identity Management | IT Governance | Information Security </b></span><u></u><u></u></p></div></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 6:13 AM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<u></u><u></u></p><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><p class="MsoNormal">An UMA RS does not understand, nor have to understand, policy; no entity needs to understand policy in order to get UMA benefits. An RS only has to understand how to interact with the UMA protection API and with UMA clients. That is still true, even if other ecosystem players (AS's today, maybe other peripheral players tomorrow) add value through policy manipulation, at an API I've just sketched that isn't even standardized today and could be complex and multi-natured. I have no idea how you imagine such an API destroying UMA's salutary properties given that <i>it's not even part of UMA and we can't prevent anyone from coming up with it and UMA-protecting it anyway</i>.<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">You know what, never mind. Sorry I tried to explain how policy could be portable.<u></u><u></u></p></div></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" target="_blank">+1 425.345.6756</a> | Skype: xmlgrrl | Twitter: @xmlgrrl<br><b>ForgeRock Summits and UnSummits</b> <a href="http://summits.forgerock.com/" target="_blank">are coming to</a> <b>London and Paris!</b><u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p><div><div><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 5:39 AM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<u></u><u></u></p><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><p class="MsoNormal" style="margin-bottom:12.0pt">Debbie,<u></u><u></u></p></div><p class="MsoNormal">My stance is simply patient-centered. There's nothing patient-centered about not giving the patient a choice of _one thing_, anything, that they can specify when an RS claims HEART compliance. <u></u><u></u></p><ul type="disc"><li class="MsoNormal">Can the patient specify a notification email address when a new Client is registered? <u></u><u></u></li><li class="MsoNormal">Can she specify a notification when a new RqP seeks access? <u></u><u></u></li><li class="MsoNormal">Can she register another RS to use the same AS that she is being forced to use? <u></u><u></u></li><li class="MsoNormal">Does HEART offer a solution to Alice's multiple portals problem?<u></u><u></u></li><li class="MsoNormal">What does HEART mean if Alice can't specify the AS?<u></u><u></u></li></ul><p>I think you may be confusing the UI issue with how UMA works. I have no problem with providing a UI for policies at the AS as long as we're clear that Alice must be able to specify the AS. That would solve the problem you seem to be trying to solve because the RS would be able to "bolt on" a UI to capture Alice's policy and then send that policy directly to Alice's AS using OAuth. In that instance, the thing you're calling a "privacy manager" is not an AS in the HEART sense although it can have UMA functionality in cases where Alice does not have an AS of her own choice. <u></u><u></u></p><p>Let's keep going with this "privacy manager" concept and take it to the next level where the "privacy manager" runs a full UMA AS and Alice tries to register another resource server. Let's assume the "privacy manager AS" is run by the Veterans Health Administration and the new resource server that Alice wants to register holds her social media data and is not HIPAA covered and maybe not even in US jurisdiction. Now, the VA as AS operator is forced to be responsible for issuing access tokens to some RS in some other country that holds personal data about Alice that's not even close to their responsibilities. What's the likelihood of the VA doing that? Is there any amount of XACML that can protect the VA under these circumstances? Will the VA accept logins and credentials from would-be Bob RqPs that come asking for access?<u></u><u></u></p><p>Under this "policies on the wire" construct, the VA would have a choice to say to Alice: "You can't register this particular RS here." please use another AS. At that point, Alice has two ASs and the exchange of policies between them via an interface does not help Alice or make HEART work. How does the VA AS work with the other AS?<u></u><u></u></p><p>So, to put this in terms that "privacy manager' vendors (and RS customers) can understand, they can go into the UMA Authorization Business and we hope they do. Their AS policy interface can be tightly coupled to a particular RS in order to provide some usability benefits because the policy UI is presented to the patient in the context of the RS. That is a real value add. Michael Chen and I implemented this feature in the current HIE of One demo between Alice's HIE of One AS and Alice's pNOSH PHR because it presents Alice's UI in the PHR context so she can see what information would be released as she makes her elections. However, this does not avoid the RS offering Alice the choice of an AS that she specifies. The HEART-compliant "privacy manager" will need to honor the AS whether it's specified by Alice or built and run by the privacy manager vendor and their customer.<u></u><u></u></p><p><span style="color:#888888">Adrian</span><u></u><u></u></p><p><span style="color:#888888"> </span><u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p></div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Aug 31, 2016 at 7:38 AM, Debbie Bucci <<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>> wrote:<u></u><u></u></p><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"><p>I don't see it that way. Your stance seems to be all or nothing. How can you encourage an ecosytem to grow by being so rigid?<u></u><u></u></p><p>Alice would not be forced to share anything. I see it more of enabling the bolt on of privacy managers - potentially minimizing the UI placed on RS and easing the burden of data entry for the patient. There are policy requirement outside the UMA protocol that will need to be satisfied (thank you Luis for that clarification/thought).<u></u><u></u></p><p>Alice can build/run AND outsource.<u></u><u></u></p></blockquote></div><p class="MsoNormal"><br><br clear="all"><u></u><u></u></p></div></div><p class="MsoNormal">-- <u></u><u></u></p><div><div><div><div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Adrian Gropper MD<br><br><span style="font-family:"Arial","sans-serif";color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span> <u></u><u></u></p></div></div></div></div></div></div></div></div></div></blockquote></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>______________________________<wbr>_________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><u></u><u></u></p></div><p class="MsoNormal"><br><br clear="all"><br>-- <u></u><u></u></p><div><div><div><div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Adrian Gropper MD<br><br><span style="font-family:"Arial","sans-serif";color:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>HELP us fight for the right to control personal health data.<br>DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span> <u></u><u></u></p></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br><br clear="all"><br>-- <br><div data-smartmail="gmail_signature"><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.<wbr>org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div><br>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.<wbr>openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/<wbr>mailman/listinfo/openid-specs-<wbr>heart</a><br>
<br></blockquote></div><br></div>