<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.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.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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'>Josh – I almost didn’t pick up on your bias but the parenthetical gave it away.<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 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.<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 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.<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 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.<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 will take my beatings from the community for speaking out on this issue if everyone thinks I am nuts.<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'>Aaron Seib, CEO<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> (o) 301-540-2311<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(m) 301-326-6843<o:p></o:p></span></p><p class=MsoNormal><a href="nate-trust.org"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D;text-decoration:none'><img border=0 width=205 height=48 id="Picture_x0020_1" src="cid:image001.jpg@01D0B292.91B93DB0"></span></a><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><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:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Josh Mandel<br><b>Sent:</b> Monday, June 29, 2015 5:13 PM<br><b>To:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> [Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></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><o:p></o:p></p><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></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:<o:p></o:p></span></p><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><b><span style='font-size:9.5pt'>Example principle #1: "Do all the things"</span></b><span style='font-size:9.5pt'><o:p></o:p></span></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. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><b><span style='font-size:9.5pt'>Example principle #2: "KISS"</span></b><span style='font-size:9.5pt'><o:p></o:p></span></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. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><b><span style='font-size:9.5pt'>Example principle #3: "UMA everywhere"</span></b><span style='font-size:9.5pt'><o:p></o:p></span></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.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></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?)<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Looking forward to discussion,<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'> -Josh<o:p></o:p></span></p></div></div></div></body></html>