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

[Adrian Gropper]

>From the patient's perspective, the 9 realities of Registration,
Delegation, Payer Eligibility, Consent Directives, Patient Portal, Patient
Discovery for HIE directories, Secure and Insecure Messaging, and
Accounting for Disclosures are likely to be a constant across all of the
use-cases. As we consider the various use-cases, can we please look at this
from the perspective of the patient first, and the developers second.

Will a combination of OAuth and UMA make sense to patients faced with the 9
realities at each and every service provider?

Adrian

On Wed, Jul 1, 2015 at 3:50 PM, Justin Richer <jricher at mit.edu> wrote:

> Of the set, I prefer option #2. That is to say, if we can solve it simply
> with OAuth, then let’s just do an OAuth version of it. If you’ve got a way
> to apply UMA to it, or it requires UMA, then sure, do so. But I think that
> we should simplify the alice-to-alice case to vanilla OAuth wherever we can.
>
> Remember, this is for understanding specific use cases, and not for the
> work that HEART is doing overall. We’ll still produce profiles for OAuth
> and UMA (and the various bits and bobs that go with that). The question is
> when to apply which one to our use cases to understand what’s happening.
>
>  — Justin
>
> On Jun 29, 2015, at 5:12 PM, Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu> wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/20150701/cfa8b616/attachment.html>