<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=us-ascii"><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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";
color:black;}
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";
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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";
color:black;}
span.hoenzb
{mso-style-name:hoenzb;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle21
{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";
color:black;}
.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 bgcolor=white 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'>I would like to toss my chip into the (a): do all the things bucket as well.<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<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Openid-specs-heart [mailto:openid-specs-heart-bounces@lists.openid.net] <b>On Behalf Of </b>Justin Richer<br><b>Sent:</b> Wednesday, July 1, 2015 9:20 AM<br><b>To:</b> openid-specs-heart@lists.openid.net<br><b>Subject:</b> Re: [Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>So that sounds like you're putting in a chip for Josh's option (a): do all the things.<br><br> -- Justin<o:p></o:p></p><div><p class=MsoNormal>On 7/1/2015 5:24 AM, Eve Maler wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal>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! <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div><div><p class=MsoNormal><br clear=all><o:p></o:p></p><div><div><div><div><div><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 href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Jun 30, 2015 at 7:21 PM, Eve Maler <<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>I'm a little confused about this thread. <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Eventually we produced a picture that looked something like this (this is my latest, prettiest version): <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><img border=0 width=472 height=241 id="_x0000_i1025" src="cid:image001.png@01D0B40D.91CC1530" alt="Inline image 1"><o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>So I don't understand the question [highlight is mine] "<span style='font-size:9.5pt'>When HEART encounters a use case like this, by which principle(s) we should <b>select</b> vanilla OAuth vs. UMA?</span>"<o:p></o:p></p></div></div></div></div></div><div><p class=MsoNormal><span style='color:#888888'><br clear=all></span><span class=hoenzb><span style='color:#888888'><o:p></o:p></span></span></p><div><div><div><div><div><p><b><span style='color:#888888'>Eve Maler<br></span></b><span style='color:#888888'>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="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</span><o:p></o:p></p></div></div></div></div></div><div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Tue, Jun 30, 2015 at 2:45 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</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'>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><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 shouldn’t abandon appropriate principles because it cost more to realize every time we tackle this problem as a nation.</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"'> Josh Mandel [mailto:<a 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 href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a></span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Subject:</b> Re: [Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA<o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></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. <o:p></o:p></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). <o:p></o:p></p><p>Best, <o:p></o:p></p><p>Josh <o:p></o:p></p><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'>On Tue, Jun 30, 2015, 08:39 Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></p></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><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'>+1 Adrian.</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 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><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 have seen products that support this functionality today – not sure if it was OAuth only that supported it.</span><o:p></o:p></p></div></div><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'> </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'>Aaron Seib, CEO</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'>(o) <a href="tel:301-540-2311" target="_blank">301-540-2311</a></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'>(m) <a href="tel:301-326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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 border=0 width=205 height=48 id="_x0000_i1026" src="cid:image002.jpg@01D0B40D.91CC1530"></span></a><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><div><div><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"'> <a href="mailto:agropper@gmail.com" target="_blank">agropper@gmail.com</a> [mailto:<a 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 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><o:p></o:p></p></div></div><div><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><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Also, as we debate what KISS actually means in terms of HEART, please allow me to propose a second Principle.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;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><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;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. <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>Adrian<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, Jun 29, 2015 at 6:32 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>+1 Aaron.<br><br>Here's a principle I would suggest:<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;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> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Adrian<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><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Jun 29, 2015 at 5:39 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<o:p></o:p></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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><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 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><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 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><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 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><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 will take my beatings from the community for speaking out on this issue if everyone thinks I am nuts.</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'>Aaron Seib, CEO</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'>(o) <a href="tel:301-540-2311" target="_blank">301-540-2311</a></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'>(m) <a href="tel:301-326-6843" target="_blank">301-326-6843</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><a 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 border=0 width=205 height=48 id="_x0000_i1027" src="cid:image003.jpg@01D0B40D.91CC1530"></span></a><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"'> Openid-specs-heart [mailto:<a 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 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><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'><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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.5pt'> </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: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><o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:9.5pt'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:9.5pt'>Example principle #1: "Do all the things"</span></b><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: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><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:9.5pt'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:9.5pt'>Example principle #2: "KISS"</span></b><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: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><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:9.5pt'> </span><o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style='font-size:9.5pt'>Example principle #3: "UMA everywhere"</span></b><o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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><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:9.5pt'> </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:9.5pt'>(I've tried to state these examples neutrally, but I must admit bias in favor of #2. Does that come through?)</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:9.5pt'> </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:9.5pt'>Looking forward to discussion,</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:9.5pt'> </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:9.5pt'> -Josh</span><o:p></o:p></p></div></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></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=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><o:p></o:p></p></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'><br><br clear=all><br>-- </span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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 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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'> </span><o:p></o:p></p></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div></div></div></div></blockquote></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" target="_blank">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><o:p> </o:p></p></div></div></div></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><br><br><br><o:p></o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>Openid-specs-heart mailing list<o:p></o:p></pre><pre><a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><o:p></o:p></pre><pre><a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><o:p></o:p></pre></blockquote><p class=MsoNormal><o:p> </o:p></p></div></body></html>