[Openid-specs-heart] HEART Profiles and dependencies

[Adrian Gropper]

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

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

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.

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.

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.

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151130/c2a2fe27/attachment.html>