<div dir="ltr"><div>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><br></div><div>One might suppose that the order would be:<br><br></div><div>1 - (First) <a href="http://openid.bitbucket.org/HEART/openid-heart-oauth2.html" target="_blank">HEART profile for OAuth 2.0.</a><br>2 - <a href="http://openid.bitbucket.org/HEART/openid-heart-oidc.html" target="_blank">HEART profile for OpenID Connect.\</a><br>3 - <a href="http://openid.bitbucket.org/HEART/openid-heart-uma.html" target="_blank">HEART profile for User-Managed Access (UMA).</a><br></div><div>4 - (last, for now) HEART profile for FHIR <br></div><div><br></div><div><div>However, the HEART profile for OAuth 2.0 has numerous mentions of OpenID Connect including: <br></div><div><div style="margin-left:40px">"The authorization server MUST provide an 
OpenID Connect service discovery endpoint listing the components 
relevant to the OAuth protocol:"<br></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><br></div><div>Next up, the third profile, HEART profile for UMA, appropriately only mentions UMA once:<br><div style="margin-left:40px">"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></div>It's notable that neither FHIR nor health is mentioned anywhere in the third profile. Good.<br><br></div><div>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><br></div><div>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><br></div><div>The impact of family relationships or user role on HEART profiles depends on perspective. It could be:<br>- an authorization server issue that has nothing to do with healthcare, <br></div><div>- a resource discovery issue that has nothing to do with UMA or OpenID Connect or OAuth,<br></div><div>- 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><br></div><div>Adrian<br></div><div> <br></div><div><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div></div>