[Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA

Adrian Gropper agropper at healthurl.com
Mon Jun 29 22:32:43 UTC 2015


+1 Aaron.

Here's a principle I would suggest:

*Principle A - If the Resource Owner takes responsibility for a HEART
transaction between Client and Resource Server, then the transaction MUST
go through and the RS gets a safe harbor.*

Adrian

On Mon, Jun 29, 2015 at 5:39 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Josh – I almost didn’t pick up on your bias but the parenthetical gave it
> away.
>
>
>
> I almost always agree that starting with the simplest set of tools first
> and incrementally expanding is the best approach but the fact of the matter
> is that we did this with Direct and said that Direct is just Transport and
> the policy enforcement and representation of Patient Privacy Preferences
> would emerge as needed.  I think Direct has been around as a concept for
> three or four years now and despite widely broadcast claims to the contrary
> the only use cases that it is frequently used for are the simplest – like
> those you can solve with OAuth alone.
>
>
>
> I am sure that there is more to consider but as a counter point to your
> somewhat hidden bias I would offer another veiled bias to not repeat the
> mistakes of the past and actually accept that someone has to solve the hard
> problems cause there are not that many easy ones in healthcare.
>
>
>
> I would like to suggest that we rise to the challenge and pursue a path
> that will have a broader impact with this effort.  If we are just talking
> about transport between two trusted end points where the users already
> trust one another I think there is a methodology on hand to handle that.
> What we need is something that can handle a little more complexity.
>
>
>
> I will take my beatings from the community for speaking out on this issue
> if everyone thinks I am nuts.
>
>
>
> Aaron Seib, CEO
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Josh Mandel
> *Sent:* Monday, June 29, 2015 5:13 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Principles for selecting "Vanilla" OAuth
> vs. UMA
>
>
>
> On today's call we discussed a use case where a patient can help connect
> her patient portal (a.k.a. her EHR account) account to an external PHR.
> This is a great, common use case that we know we could handle with either
> "vanilla" OAuth, or UMA, or both. Of course, software systems need to know,
> up front, whether they'll be talking vanilla OAuth or UMA -- because the
> wire protocols are different.
>
>
>
> The question: When HEART encounters a use case like this, by which
> principle(s) we should select vanilla OAuth vs. UMA? Some examples of
> principles (to stimulate discussion) might be:
>
>
>
> *Example principle #1: "Do all the things"*
>
> We should produce two profiles each time this kind of situation comes up:
> one describing how to do it with vanilla OAuth, and one describing how to
> do it with UMA. This provides maximum flexibility for implementers with
> different needs/contexts.
>
>
>
> *Example principle #2: "KISS"*
>
> Any time vanilla OAuth can handle a use case, we should use vanilla OAuth.
> Save UMA for when it's required. This provides a simpler environment with
> fewer moving parts and stronger out-of-the-box software library support.
>
>
>
> *Example principle #3: "UMA everywhere"*
>
> Use UMA across the board, and avoid vanilla OAuth. Since UMA handles a
> more general set of use cases, and there's value in consolidation, UMA
> should be the preferred option in all cases. This way, implementers only
> ever need to do one (very general) thing.
>
>
>
> (I've tried to state these examples neutrally, but I must admit bias in
> favor of #2. Does that come through?)
>
>
>
> Looking forward to discussion,
>
>
>
>   -Josh
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>


-- 
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/20150629/6034753e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/6034753e/attachment.jpg>


More information about the Openid-specs-heart mailing list