<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Comments inline.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 30, 2015, at 6:04 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" class="">agropper@healthurl.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="">The HEART Profiles can follow a logical sequence of dependencies in order to make them easier to understand and more generative in support of current and future use-cases. The natural order of the profiles can be such that changes in a later HEART profile do not impact the HEART profiles earlier in the order. <br class=""><br class=""></div><div class="">One might suppose that the order would be:<br class=""><br class=""></div><div class="">1 - (First) <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank" class="">HEART profile for OAuth 2.0.</a><br class="">2 - <a href="http://openid.bitbucket.org/HEART/openid-heart-oidc.html" target="_blank" class="">HEART profile for OpenID Connect.\</a><br class="">3 - <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank" class="">HEART profile for User-Managed Access (UMA).</a><br class=""></div><div class="">4 - (last, for now) HEART profile for FHIR <br class=""></div></div></div></blockquote><div><br class=""></div><div>That is the intended order.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><div class="">However, the HEART profile for OAuth 2.0 has numerous mentions of OpenID Connect including: <br class=""></div><div class=""><div style="margin-left:40px" class="">"The authorization server MUST provide an
OpenID Connect service discovery endpoint listing the components
relevant to the OAuth protocol:"<br class=""></div>This suggests that the labeling of the profiles is misleading. The second profile might more accurately be labeled "HEART Profile for OpenID Connect Providers”.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>OpenID Connect provides a service discovery mechanism that also includes, by its nature, an OAuth discovery mechanism. If there were a generic OAuth discovery mechanism (and there likely will be in the future), we would mandate that instead. The label is not misleading, but I believe you’re misunderstanding where the relevant pieces of functionality come from and what they do. If you find any mentions of OpenID Connect that depend on implementation of that protocol, those need to be excised. I don’t see any.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">Next up, the third profile, HEART profile for UMA, appropriately only mentions UMA once:<br class=""><div style="margin-left:40px" class="">"The authorization server MUST implement the
UMA discovery mechanism as well as the OIDC discovery mechanisms
described in the HEART OAuth 2.0 Profile."<br class=""></div>It's notable that neither FHIR nor health is mentioned anywhere in the third profile. Good.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>That’s the intent on all of them.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">Lastly, for now, I would expect the fourth profile to be titled something like "HEART profile for FHIR". In theory, this profile need not mention the authorization server of 1 or 3 at all. FHIR and other domain-specific standards are very important for interoperability between servers and clients but it's counterproductive to interoperability to confuse the operators of authentication servers or authorization servers with domain-specific issues. If we do, it will only serve to slow adoption.<br class=""></div></div></div></div></blockquote><div><br class=""></div><div>The profile is correctly labeled as it is specific to the OAuth portions of protecting FHIR. There will be other aspects of FHIR that will be covered in other profiles. This profile has dependencies on only the first of the above list, not the other two. They will all, however, work together.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><br class=""></div><div class="">There may be profiles beyond 4. I would expect 42CFR Part 2, or wearables, or resource discovery (Relationship Locator Service) in healthcare would be level 5 because they are healthcare-sub-specific. I would not expect these level 5 profiles to impact the authorization server either. <br class=""><br class=""></div><div class="">The impact of family relationships or user role on HEART profiles depends on perspective. It could be:<br class="">- an authorization server issue that has nothing to do with healthcare, <br class=""></div><div class="">- a resource discovery issue that has nothing to do with UMA or OpenID Connect or OAuth,<br class=""></div><div class="">- an HL7 standards issue where they complicate FHIR by applying it to resources that don't have a single subject. It's up to us in HEART to determine which of these three, if any concerns HEART. I'm not sure if we need to decide this issue sooner rather than later because I hope it doesn't change profiles 1-3 at all.<br class=""><br class=""></div></div></div></div></blockquote><div><br class=""></div><div>They will impact the development of the authorization server in that they will require certain scopes and functionality to be available at the authorization server. We can suggest scope flexibility and genericism in the core profiles to help make this happen more easily, but it’s misleading to think that a semantic profile will have no impact on a deployed system. It’s also misleading to believe that all generic implementations of an oauth authorization server will require deep code changes due to the semantics that we’re proposing.</div><div><br class=""></div><div><br class=""></div><div>Hope this helps,</div><div><br class=""></div><div> — Justin</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">Adrian<br class=""></div><div class=""> <br class=""></div><div class=""><br class="">-- <br class=""><div class="gmail_signature"><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""><div dir="ltr" class="">Adrian Gropper MD<span style="font-size:11pt" class=""></span><br class=""><br class=""><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class="">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)" class=""><br class="">DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)" class=""></span>
</div></div></div></div></div></div></div></div>
</div></div></div>
_______________________________________________<br class="">Openid-specs-heart mailing list<br class=""><a href="mailto:Openid-specs-heart@lists.openid.net" class="">Openid-specs-heart@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-heart<br class=""></div></blockquote></div><br class=""></div></body></html>