[Openid-specs-heart] HEART Profiles and dependencies

[Justin Richer]

Comments inline.

> On Nov 30, 2015, at 6:04 PM, Adrian Gropper <agropper at healthurl.com> wrote:
> 
> 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. 
> 
> One might suppose that the order would be:
> 
> 1 - (First) HEART profile for OAuth 2.0. <http://openid.bitbucket.org/HEART/openid-heart-oauth2.html>
> 2 - HEART profile for OpenID Connect.\ <http://openid.bitbucket.org/HEART/openid-heart-oidc.html>
> 3 - HEART profile for User-Managed Access (UMA). <http://openid.bitbucket.org/HEART/openid-heart-uma.html>
> 4 - (last, for now) HEART profile for FHIR 

That is the intended order.

> 
> However, the HEART profile for OAuth 2.0 has numerous mentions of OpenID Connect including: 
> "The authorization server MUST provide an OpenID Connect service discovery endpoint listing the components relevant to the OAuth protocol:"
> This suggests that the labeling of the profiles is misleading. The second profile might more accurately be labeled "HEART Profile for OpenID Connect Providers”.

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.

> 
> Next up, the third profile, HEART profile for UMA, appropriately only mentions UMA once:
> "The authorization server MUST implement the UMA discovery mechanism as well as the OIDC discovery mechanisms described in the HEART OAuth 2.0 Profile."
> It's notable that neither FHIR nor health is mentioned anywhere in the third profile. Good.

That’s the intent on all of them.

> 
> 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.

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.

> 
> 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. 
> 
> The impact of family relationships or user role on HEART profiles depends on perspective. It could be:
> - an authorization server issue that has nothing to do with healthcare, 
> - a resource discovery issue that has nothing to do with UMA or OpenID Connect or OAuth,
> - 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.
> 

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.


Hope this helps,

 — Justin


> Adrian
>  
> 
> -- 
> 
> Adrian Gropper MD
> 
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/ <http://patientprivacyrights.org/donate-2/>_______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151130/f177b8a9/attachment.html>