<div dir="ltr"><div><div>The word existing FHIR profiles gives me pause ... The current profiles in Argonaut are focused primarily on internal use of FHIR.   The backend services - and even some of registry - dynamic client work out of Blue Button Plus more align with the Alpha HEART profiles.<br><br></div>I am do not have a vote - not sure I see the option that aligns with my thinking.   I think its too early to say. Need to play in the sandbox a bit.   Terminology seems to get in the way ...  I thought the work/profiles are to be layered - so even in the UMA context - if the workflows is an OAUTH2 workflow or OpenID Connect because there is an id_token and some additional attributes - then it is what it is.   According to the OAUTH spec - how a client gets a redirect URL  to ask/assist the resource owner for authorization is out of scope - they automagically have those redirect URLs and some pre-arranged relationship with the resource server it wants to get to - does the client really have to know UMA is in play?   On the surfaces that seems to be a layer above it.   I don't have an answer - and standing up the sandbox so I can see for myself.  <br><br></div>I know there are things that we will need to make up (extensions) not matter which direction we choose.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 8:11 AM, Nagesh Bashyam <span dir="ltr"><<a href="mailto:nagesh.bashyam@drajer.com" target="_blank">nagesh.bashyam@drajer.com</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">My two cents.<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">I would vote for #2. <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hopefully the HEART OAuth profile and the existing SmartOnFHIR Security specifications end up being the same as we go forward.  <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"><u></u> <u></u></span></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"">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>Justin Richer<br><b>Sent:</b> Wednesday, July 01, 2015 3:51 PM<br><b>To:</b> Josh Mandel<span class=""><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> Re: [Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA<u></u><u></u></span></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Of the set, I prefer option #2. That is to say, if we can solve it simply with OAuth, then let’s just do an OAuth version of it. If you’ve got a way to apply UMA to it, or it requires UMA, then sure, do so. But I think that we should simplify the alice-to-alice case to vanilla OAuth wherever we can.<u></u><u></u></p><div><div class="h5"><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Remember, this is for understanding specific use cases, and not for the work that HEART is doing overall. We’ll still produce profiles for OAuth and UMA (and the various bits and bobs that go with that). The question is when to apply which one to our use cases to understand what’s happening.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"> — Justin<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><div><p class="MsoNormal">On Jun 29, 2015, at 5:12 PM, Josh Mandel <<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>> wrote:<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><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><u></u><u></u></p><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></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:<u></u><u></u></span></p><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></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"><u></u><u></u></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. <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></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"><u></u><u></u></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. <u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></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"><u></u><u></u></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.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></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?)<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt">Looking forward to discussion,<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-size:9.5pt">  -Josh<u></u><u></u></span></p></div></div><p class="MsoNormal">_______________________________________________<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><u></u><u></u></p></div></blockquote></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div><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" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>