<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi – I meant to ask you last week. When you say Discovery in the first bullet I am not sure I know what you mean. Can you expand on that for me? I think I get everything except that below.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I don’t know why we are trying to be so cryptic on the work group. This is unfortunate. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>You use RO below and I think it might be a typo but have to confirm. Is it meant to have been </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>something else</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What is RqP an abbreviation of? Requesting Party?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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 [<a href="mailto:openid-specs-heart-bounces@lists.openid.net">mailto:openid-specs-heart-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Adrian Gropper<br><b>Sent:</b> Friday, December 11, 2015 3:37 PM<br><b>To:</b> Moehrke, John (GE Healthcare)<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> Re: [Openid-specs-heart] "Scope" of sharing and purpose of use<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Let me attempt at mediation :-)<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>- We're talking about resources that have a single subject (the patient) Resources with more than one subject, such as a patient list are a completely different matter <span style='background:yellow;mso-highlight:yellow'>because they involve discovery</span><span style='color:#1F497D'> (I don’t get this? Discovery of what? The identity of each person in the list?)</span>. The special case of a mom with 2 kids can simply, if inelegantly, be handled by polling for each of the subjects. There's no discovery involved.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>- The major difference between OAuth and UMA is that in UMA the resource is under the control of a separate legal entity. Therefore, when a client (and the client's user) shows up to request the resource, the client may present claims or attributes to either or both the resource server (RS) and/or the authorization server (AS). To say this another way: In UMA there's some kind of legal agreement between the resource server and the authorization server. In OAuth there is none because they are the same.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>- The sharing of control between the RS and the AS is subject to institutional, local, and federal controls. All of the situations that John listed boil down to "good faith" and "notice" to the <span style='background:yellow;mso-highlight:yellow'>RO</span> when the resource server acts on the instructions of the AS based on the actual attributes of the client (C)<i><span style='color:#1F497D'> by client attributes do you mean attributes of MSHV or of the User of MSHV, Aaron Seib?</span></i> and the client's user (RqP<span style='color:#1F497D'> – this is Aaron Seib, right? What does RqP stand for?</span>).<o:p></o:p></p></div><div><p class=MsoNormal>Adrian<o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Dec 11, 2015 at 3:01 PM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Eve,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>It is clear that there is a communications problem between those that are comfortable in the language of speaking about OAuth/UMA, and those that are comfortable in the language of speaking about Healthcare Access Control needs. I can read every word you have said, but I have no idea what you said.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think one of our problems is that we keep skipping from use-cases where the “user” is the “patient” trying to access their own data; and use-cases where the “user” is a clinician trying to help the “patient”. There are many MORE use-cases including parents, children, guardians. There are many MORE use-cases around researchers, public-health, billing, payers. And there are a huge variety of all of these. There are authorization mechanisms that stem from direct authorization by the patient, to indirect because of context, and the ultimate for healthcare ‘because their life is in jeopardy and I am a licensed clinician that can save their life’. Followed by many medical-ethical traps like having a personal discussion about a particularly tragic test result before the lab fact is directly exposed.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>We need to solve all of these, however to solve any one would be helpful.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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"'> Eve Maler [mailto:<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>] <br><b>Sent:</b> Friday, December 11, 2015 11:43 AM<br><b>To:</b> Moehrke, John (GE Healthcare)<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a><br><b>Subject:</b> "Scope" of sharing and purpose of use</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi John-- (I changed the subject line and deleted older parts of the thread.)<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>When you say "scope" here, I suspect you mean "scope" of the sharing use case, rather than something like an OAuth or UMA scope, so I'm just checking. So a "single-patient scope" means that the only human we're paying attention to in the use case is the patient, and "any application with users that are authorized to multiple patients" seems to mean a use case that involves party-to-party sharing, with multiple humans involved. However, you follow the latter with "would need to get multiple scopes", so I'm not sure. Note that "getting multiple scopes" as a technical construct doesn't have anything to do with sharing with an autonomous third party.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FWIW, here is how I think, at a high level, about <b>configuring the delegation of rights to access resources</b>. It's all about <b>parts of speech</b>.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>OAuth lets a user (patient) do this configuration at run time while using a client app, by opting in to the authorization server's issuance of an access token to that app. By contrast, UMA lets a user (patient) do this configuration anytime, generally by instructing the authorization server to check whether some combination of the client app and the requesting party using the app meet various requirements (policy). So OAuth is kind of an attenuated version of UMA wrt the constraints on delegation of access rights.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Courier New"'>system subject verb object adjective</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New"'>OAuth client ID OAuth scopes (implicitly some endpoints) n/a</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New"'> (and always Alice)</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New"'>UMA claims-based eg Bob, UMA scopes over... UMA resource sets claims-based e.g. TPO,</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:7.5pt;font-family:"Courier New"'> client ID/type, etc. time limitations, etc.</span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It's possible to conflate purpose-of-use into the UMA scopes system, but it's as awkward as conflating (ordinarily implicit) resource sets into the OAuth scopes system (resource1.read, resource1.write, etc.), which is why OAuth has invented the audience parameter to try and solve the problem of a single authorization server protecting several APIs. This is why I suggest using a claims-based system above.<o:p></o:p></p></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>Join our <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=BWKe_zUfK7VyJCEdTSN-5cG7TelP0b1X-x3kyeaODmk&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Dec 7, 2015 at 2:00 PM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The discussion on the call today was too hard to break into. Even for a big mouth like me.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I am okay with limiting our next couple of profiles to single patient scopes. As much of the email discussion has pointed out patient controlled access is our primary scope, and logically (if not technically) this is easy to understand with scopes that are single patient. </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes this means that any application with users that are authorized to multiple patients would need to get multiple scopes; so be it. For now… For Enterprise use, this is troubling; but for most uses that happen from outside of an enterprise or between enterprises this limitation is not unreasonable. The most common APIs in healthcare for this are already patient centric. So it is not a big problem.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The user experience does not need to be impacted by this profiled limitation</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The future does not need to be impacted by this profiled limitation.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Which means that one viewpoint for scope can be the identity of the patient that one is asking for access to. This is not the only scope we will ever support; but is one method that would satisfy some use-cases today.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another view on scope, that I have been involved with in other groups, is to use a high-level vocabulary that is used often in the Access Control policy – PurposeOfUse. This vocabulary is items like: Treatment, Payment, Research, Emergency, etc…</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>To go deeper than these two vectors through scopes in a general purpose healthcare access control infrastructure is futile.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Next level deeper in scopes would come from workflow centric implementation guides. That is a specification that is defining a workflow, could define a scope(s) for that workflow.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">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=CwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=PHeMeoVZ7WGQVkHh4j1pjEo3WjxiOtW0zWBvptezqXM&s=b-IeKH8ALrT6jaP_pgYHavTt27UVQVYtlz9y5w5CRak&e=" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Openid-specs-heart mailing list<br><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal><o:p> </o:p></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.org/donate-2/</span></a></span> <o:p></o:p></p></div></div></div></div></div></div></div></div></div><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 2016.0.7294 / Virus Database: 4483/11158 - Release Date: 12/11/15<o:p></o:p></p></div></body></html>