<div dir="ltr"><div><div><div>To answer the reverse - I'd like to better understand:<br><br></div>ATT interactions and dependencies  - .   asynchronous authorizations and on the wire or calculus that happens  - flow is different get that ...<br></div>PAT - how that aligns/replaces/supplements the traditional Access Control  (PIP, PEP ABAC/RBAC) stuff  most likely will be required - <br></div>OAuth 2.0 likeness  ... I don't necessarily see where there will be an entirely different rewrite.   Example:  - authentications may be assumed via a standard OAUTH flow - yet some implementations will choose to add the additional id_token (OIDC).    If an RPT token is handled programatically as an access token  ...what has to change?   So ... seems to me that client flows could (would) be designed differently anyway  based on whether Bob or Alice is making the request.  <br><br><br><div><br><div><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 9, 2015 at 12:55 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">If you get  a life be sure to leave a bread crumb trail so the rest of us can follow you out.<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">Aaron<u></u><u></u></span></p><span class=""><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:image002.jpg@01D0BA46.909511F0" height="48" border="0" width="205"></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-bounces@lists.openid.net</a>] <b>On Behalf Of </b>Eve Maler<br><b>Sent:</b> Thursday, July 09, 2015 11:18 AM<br><b>To:</b> Moehrke, John (GE Healthcare)</span></p><div><div class="h5"><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] Flip the question of “Vanilla" OAuth vs. UMA<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">John, no doubt you're 200% overbooked, but if we could attract you to the UMA meetings, you'd probably find our current workstream fascinating. :-) The Kantara Leadership Council members laugh at me for getting excited about the "BLT sandwich" (business-legal-technical) progress updates I give them... We are literally mapping specific bits of UMA flows to the norms of sociotechnical systems being identified in cutting-edge academic research.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Then again, maybe I need to get a life. <u></u><u></u></p></div></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><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" value="+14253456756" 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!<u></u><u></u></p></div></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Thu, Jul 9, 2015 at 8:07 AM, Moehrke, John (GE Healthcare) <<a href="mailto:John.Moehrke@med.ge.com" target="_blank">John.Moehrke@med.ge.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Eve,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">You are right on… </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As one of the co-chairs of the HL7 Security wg, I have struggled with this. However in Healthcare we must keep moving forward. So the work in HL7 is to incrementally improve the ability to capture anything we can related to the act of consent, and the meaning of that consent. We recognize these as difficult domains. Historic precedent in healthcare is embarrassing.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In HL7 we have two different encodings. One is based on the format of a document used for all other medical-fact documentation (CDA). The format is not important, but it is important to indicate that it is a form that healthcare handles for almost everything related to the patient, so it is easy for them to handle it for this purpose too. It is a form however that is totally foreign to any access control decision system. We thus recognize that the rules might be ‘equivalently’ encoded in some access control decision language (common is XACML today). The equivalency is left to humans to agree… Thus the bridging of the divide between them is not computable, but we are trying.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The HL7 FHIR effort is just getting going, and for the most part will start with the same capability, just with different technical encoding. Still not necessarily fixing the big issue… But getting more processable (FHIR is predominantly HTTP/REST and encodes things in more simple XML or JSON; where as CDA is ugly XML).</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">The actual systems-design might have the Access Control rules interjected at the time that the patient gives consent; or might interpret the consent at the time of needing to make a decision. This is a systems-design responsibility that is not the role of HL7. There are good reasons to do either, especially since healthcare is a lifelong effort (so we think in 100+ years).</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So, look to HL7 to help with capturing the ceremony of Consent. But they definitely need help with the Enforcement, we hope HEART can help with. AND we all need to work on everything in-between.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">John</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></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:<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>Eve Maler<br><b>Sent:</b> Thursday, July 09, 2015 9:47 AM<br><b>To:</b> Kinsley, William<br><b>Cc:</b> <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openid.net</a></span><u></u><u></u></p><div><div><p class="MsoNormal"><br><b>Subject:</b> Re: [Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA<u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Hi Bill-- I'm not sure what the HL7 consent/contract standards are about, but based on what I know of "notice and consent" (privacy) theory, and "contract" (legal) theory (IANAL but I have collected lawyers for many years as part of my UMA work), there is not very much in the technical underpinnings of almost any technical or machine-readable consent flow used on the web today, to support a true non-adhesion contract for Alice. (Perhaps the closest thing on the OAuth side would be requiring an OAuth scope unchecking facility, but that's still not a formal mapping to a contract model -- has someone done that mapping?)<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">In the UMA group, with the help of Tim Reiniger (the primary drafter of the new Virginia digital identity law), we have recently started applying a "license" vs. a "contract" paradigm to the UMA flows. In fact, we're planning to discuss this on today's UMA call in a little over an hour.<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">I may be on the wrong track here, but this is what your note put me in mind of...<u></u><u></u></p></div></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><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=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<u></u><u></u></p></div></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Jul 8, 2015 at 8:08 AM, Kinsley, William <<a href="mailto:BKinsley@nextgen.com" target="_blank">BKinsley@nextgen.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">I need Eva to verify that what I am saying is correct, I am still coming up to speed on UMA … HL7 has/is developing FHIR consent(contract) standards and I believe the oAuth and UMA profiles are in scope to support these and possibly others. </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">To easily support interoperability, is it possible (or in scope) to develop profile standards or profile taxonomy that would be flexible and adaptable so that the RS would be able to process FHIR consents even if they are modified by a specific implementation without  special coding. This could be too idealistic, out of scope or just not supportable with oAuth and/or UMA profiles. </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">For example: A client could connect to any FHIR resource and process any Heart Profile that is provided, even if the client is another RS running in a “Client” role to another RS .</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a">Bill</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif";color:#44546a"> </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""> Eve Maler [mailto:<a href="mailto:eve.maler@forgerock.com" target="_blank">eve.maler@forgerock.com</a>] <br><b>Sent:</b> Tuesday, July 07, 2015 10:00 PM<br><b>To:</b> Aaron Seib<br><b>Cc:</b> Kinsley, William; <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] Flip the question of “Vanilla" OAuth vs. UMA</span><u></u><u></u></p><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">Commenting on one of Aaron's bulleted items:<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Profiling "a standard way to label assets managed by the RS" is one of the tasks I was contemplating to be potentially in scope for our semantic UMA profile. This is because it is possible for resource set descriptions (these are things that an UMA RS registers at an AS, to put resources under protection) to include resource types. As I understand it, the FHIR API conveys data structures that reflect quite a lot of HL7 standardization work already done, which amounts to "resource typing".<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">While a lot of companies with proprietary APIs might not want to standardize their resource assets, there's a lot of power in standardized resource labeling in open ecosystems like the one we're working on. For starters, there's a <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.kantarainitiative.org_uma_rec-2Doauth-2Dresource-2Dreg-2Dv1-5F0.html-23rfc.section.4&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=XZvNdZZ9gPcuIcTPhPiiE_QBSahOHLBvTzItUZRdivI&e=" target="_blank">security consideration</a> that is mitigated by the use of "well-known and standardized" description elements. (See this <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xmlgrrl_UMA-2DSpecifications_issues_151&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=71o1AnmsYBp0TU9vvpx_TuaYsMN1txaagwxyDCElFnc&e=" target="_blank">UMA issue</a> for some background.) For another example, standard types could drive automated policy workflows in interesting ways.<u></u><u></u></p></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>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=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e=" target="_blank">ForgeRock.org OpenUMA</a> community!<u></u><u></u></p></div></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p></div></div><div><div><div><p class="MsoNormal">On Tue, Jul 7, 2015 at 2:56 PM, Aaron Seib <<a href="mailto:aaron.seib@nate-trust.org" target="_blank">aaron.seib@nate-trust.org</a>> wrote:<u></u><u></u></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"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for starting this new thread.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I am not expert in this space (yet) but let me see if I can repeat back what I think you are proposing.  </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Are you suggesting that for Resource Server (RS) be able to accept a standard profile authorization assertion (based on the UMA profile) from a standard (UMA-based) Authorization Server (AS)?   </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I maybe out of date but I seem to remember reading that the UMA profile states that the Authorization Policy service capabilities (as required to implement an AS) are out of scope for the UMA profile - as are the specific policies for how you label assets (network, applications, data) managed by the RS with access tokens that are registered with and managed by the AS.  </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">To echo back your language is your suggestion that </span><span style="font-size:14.0pt;font-family:"Cambria","serif";background:yellow">it</span><span style="font-size:14.0pt;font-family:"Cambria","serif""> ^would^ <span style="background:yellow">be simpler to have consistent patterns (libraries) implemented</span></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> that would address what the UMA profile has intentionally said is out of scope?  I.e., </span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span style="font-size:7.0pt;color:#1f497d">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">addressing the need for a standard way to label assets managed by the RS; and (?) </span><u></u><u></u></p><p><span style="font-size:11.0pt;font-family:Symbol;color:#1f497d">·</span><span style="font-size:7.0pt;color:#1f497d">        </span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">a standard way to represent the inputs to an Authorization Policy Service</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In my mind this would allow us to not only solve the simple cases but also enable us to develop libraries that represent the applicable policy of a given Federal Reg or libraries of applicable state law that could be re-used by everyone.  It might also enable the different associations to provide recommended policies to be adopted by their members and plugged into the solution following a period of local policy tweaking by a given institution or Agency.</span><u></u><u></u></p><p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Am I getting this right?</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Aaron Seib, CEO</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">@CaptBlueButton </span><u></u><u></u></p><p class="MsoNormal"><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><u></u><u></u></p><p class="MsoNormal"><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><u></u><u></u></p><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=tPRDdAyGDknsaFwvwbIPyKu9NkZpJ-UX0L62WfJTfPk&e=" target="_blank"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d;text-decoration:none"><img src="cid:image003.jpg@01D0BA46.909511F0" height="48" border="0" width="205"></span></a><u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></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>Kinsley, William<br><b>Sent:</b> Monday, July 06, 2015 8:45 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] Flip the question of “Vanilla" OAuth vs. UMA</span><u></u><u></u></p></div></div></div></div><div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">I am starting a new thread …  I think we need to flip the question of “Vanilla" OAuth vs. UMA”. I feel confident that we are going to discover use cases that cannot be supported by “Vanilla” OAuth or would be greatly simplified by using UMA. </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">Maybe the real question to ask is:  Are there any augments (use case, technology restriction, cost, etc.) that justifies NOT using (requiring) UMA?</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">From a interoperability, quality, security and development perspective, would it be simpler to have consistent patterns (libraries) implemented that are more likely to be “drop-in compatible” without source changes. While the standard itself would be considered rigid, it would be flexible by the use and implementation of the UMA profiles.     </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">The caveat here is the resource server (RS) would need to be able to accept/process a UMA profile without developing custom code to interpret it.  Would this require resource servers to adhere to a standard set of UMA profiles or a defined UMA profile taxonomy that could describe the healthcare consent models (if one exists)?</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif"">Bill</span><u></u><u></u></p></div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><u></u><u></u></p></div><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""> </span><u></u><u></u></p></div><table style="width:670.45pt;margin-left:5.4pt" border="0" cellpadding="0" cellspacing="3" width="1117"><tbody><tr style="height:26.25pt"><td style="padding:.75pt .75pt .75pt .75pt;height:26.25pt"><p class="MsoNormal" style="margin-bottom:6.7pt;text-align:right" align="right"><span style="font-family:"Arial","sans-serif""> </span><u></u><u></u></p></td><td style="padding:.75pt .75pt .75pt .75pt;height:26.25pt"></td></tr></tbody></table><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> </span><u></u><u></u></p><table style="width:670.45pt;margin-left:5.4pt" border="0" cellpadding="0" cellspacing="3" width="1117"><tbody><tr><td style="padding:.75pt 9.85pt .75pt 9.85pt"></td></tr></tbody></table><p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Cambria","serif""> </span><u></u><u></u></p></div></div><table style="width:670.45pt;margin-left:5.4pt" border="0" cellpadding="0" cellspacing="3" width="1117"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-bottom:6.7pt"><b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">William Kinsley<br></span></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Enterprise Architect, Ambulatory</span><u></u><u></u></p><div><p class="MsoNormal" style="margin-bottom:6.7pt"><b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">NEXTGEN HEALTHCARE<br></span></b><span style="font-size:10.0pt;font-family:"Calibri","sans-serif"">Solutions for: Ambulatory, Inpatient and Community Connectivity<br>795 Horsham Road, Horsham, PA 19044<br><a href="tel:%28215%29%20657-7010%20x21128" target="_blank">(215) 657-7010 x21128</a> [o]  <br><a href="mailto:BKinsley@nextgen.com" target="_blank">BKinsley@nextgen.com</a></span><u></u><u></u></p></div></td><td style="padding:.75pt .75pt .75pt .75pt"></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span><u></u><u></u></p></div><table style="width:487.5pt;margin-left:5.4pt" border="0" cellpadding="0" cellspacing="3" width="813"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-bottom:6.7pt"><b><i><span style="font-size:10.0pt;font-family:"Calibri","sans-serif";color:#e46c0a"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:#e46c0a;text-decoration:none">Be ready for MU and ICD-10 in 2015. Start your EHR version 5.8 and KBM version 8.3 upgrade today. Get the resources you need at </span><span style="color:#007cb9">www.nextgen.com/upgradecentral</span></a></span></i></b><u></u><u></u></p></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span><u></u><u></u></p></div><table style="width:492.0pt;margin-left:5.4pt" border="0" cellpadding="0" cellspacing="3" width="820"><tbody><tr><td style="padding:.75pt .75pt .75pt .75pt"><p class="MsoNormal" style="margin-bottom:6.7pt"><span style="font-size:6.0pt;font-family:"Arial","sans-serif""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none">This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you for your cooperation.</span></a></span><u></u><u></u></p></td></tr></tbody></table><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span><u></u><u></u></p></div><div style="margin-top:6.7pt;margin-bottom:6.7pt"><p class="MsoNormal"><span style="font-family:"Arial","sans-serif""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a></span><u></u><u></u></p></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"><br>_______________________________________________<br>Openid-specs-heart mailing list<br></span>Openid-specs-heart@lists.openid.net<span style="color:windowtext;text-decoration:none"><br></span>http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=" target="_blank"><span style="color:windowtext;text-decoration:none"> </span></a><u></u><u></u></p></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></div></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>