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

Josh Mandel Joshua.Mandel at childrens.harvard.edu
Mon Jun 29 21:12:58 UTC 2015

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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150629/8edfb71c/attachment.html>

More information about the Openid-specs-heart mailing list