[Openid-specs-heart] Vectors of Trust - HEART Edition

[Adrian Gropper]

A post about harmonizing the Argonaut and HEART approaches to FHIR:

http://thehealthcareblog.com/blog/2015/07/20/standards-alone-are-not-the-answer-for-interoperability/

Adrian

On Fri, Jul 17, 2015 at 7:52 AM, Adrian Gropper <agropper at healthurl.com>
wrote:

> I think all of us agree with Jocelyn Samuels that health data privacy and
> security can coexist (
> http://www.fiercehealthit.com/story/jocelyn-samuels-privacy-and-data-sharing-can-coexist/2015-06-04
> ). What does this specifically mean in the context of HEART and our current
> conversation about OAuth and UMA profiles?
>
> I'm adopting the phrase "vectors of trust" for this discussion because I
> think it applies to authorization in the same way it does to
> authentication. (For those that wish to dive in, there's a major healthcare
> patient authentication discussion underway in IDESG that you can ask me
> about.)
>
> Do scopes have anything to do with vectors of trust in the HEART
> authorization model? I'm having a hard time following the current
> discussion about scopes and how they relate to SMART on FHIR and Argonaut.
> To avoid the compromise of privacy vs. security we need to deal with the
> vectors of trust _before_ we profile scopes. This may be more true of UMA
> than it is for OAuth but I think it applies to both.
>
> To avoid a compromise between security and privacy, the RS must be granted
> a safe harbor for API access by the authenticated and autonomous resource
> owner. This protects the security interest of the RS and the privacy
> interest of the RO.
>
> The trust relationship between RS, AS, and Client must be designed to meet
> our Charter which includes a requirement of an "independent AS" that could
> be built by the RO. This is absolutely key to the scalability and
> generativity of HEART.
>
> It's less clear about how HEART will deal with a "built" Client or a
> client that is trusted only by the AS but not the RS. Who decides if the
> Client can participate in the "safe harbor by the authenticated and
> autonomous resource owner" contract? The profiling we do around OAuth and
> UMA should be able to solve this problem and it should probably be done
> ahead of the scopes discussion.
>
> I believe that once we understand the issues of an independent AS and of
> Client trust the difference between UMA vs. OAuth profiles, including
> scopes, in any particular use-case, will be easy to resolve.
>
> Adrian
>
> --
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> *http://patientprivacyrights.org/donate-2/*
> <http://patientprivacyrights.org/donate-2/>
>
>


-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150721/4db67bbf/attachment-0001.html>