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

Debbie Bucci debbucci at gmail.com
Thu Jul 2 13:07:47 UTC 2015


The word existing FHIR profiles gives me pause ... The current profiles in
Argonaut are focused primarily on internal use of FHIR.   The backend
services - and even some of registry - dynamic client work out of Blue
Button Plus more align with the Alpha HEART profiles.

I am do not have a vote - not sure I see the option that aligns with my
thinking.   I think its too early to say. Need to play in the sandbox a
bit.   Terminology seems to get in the way ...  I thought the work/profiles
are to be layered - so even in the UMA context - if the workflows is an
OAUTH2 workflow or OpenID Connect because there is an id_token and some
additional attributes - then it is what it is.   According to the OAUTH
spec - how a client gets a redirect URL  to ask/assist the resource owner
for authorization is out of scope - they automagically have those redirect
URLs and some pre-arranged relationship with the resource server it wants
to get to - does the client really have to know UMA is in play?   On the
surfaces that seems to be a layer above it.   I don't have an answer - and
standing up the sandbox so I can see for myself.

I know there are things that we will need to make up (extensions) not
matter which direction we choose.



On Thu, Jul 2, 2015 at 8:11 AM, Nagesh Bashyam <nagesh.bashyam at drajer.com>
wrote:

> My two cents.
>
>
>
> I would vote for #2.
>
> Hopefully the HEART OAuth profile and the existing SmartOnFHIR Security
> specifications end up being the same as we go forward.
>
>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, July 01, 2015 3:51 PM
> *To:* Josh Mandel
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Principles for selecting "Vanilla"
> OAuth vs. UMA
>
>
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150702/a84865b9/attachment-0001.html>


More information about the Openid-specs-heart mailing list