[Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA

[Kinsley, William]

I am starting a new thread …  I think we need to flip the question of “Vanilla" OAuth vs. UMA”. I feel confident that we are going to discover use cases that cannot be supported by “Vanilla” OAuth or would be greatly simplified by using UMA.

Maybe the real question to ask is:  Are there any augments (use case, technology restriction, cost, etc.) that justifies NOT using (requiring) UMA?

>From a interoperability, quality, security and development perspective, would it be simpler to have consistent patterns (libraries) implemented that are more likely to be “drop-in compatible” without source changes. While the standard itself would be considered rigid, it would be flexible by the use and implementation of the UMA profiles.

The caveat here is the resource server (RS) would need to be able to accept/process a UMA profile without developing custom code to interpret it.  Would this require resource servers to adhere to a standard set of UMA profiles or a defined UMA profile taxonomy that could describe the healthcare consent models (if one exists)?

Bill


        [X]

William Kinsley
Enterprise Architect, Ambulatory

NEXTGEN HEALTHCARE
Solutions for: Ambulatory, Inpatient and Community Connectivity
795 Horsham Road, Horsham, PA 19044

(215) 657-7010 x21128 [o]
BKinsley at nextgen.com    [X] <http://www.oneugm.com>

Be ready for MU and ICD-10 in 2015. Start your EHR version 5.8 and KBM version 8.3 upgrade today. Get the resources you need at www.nextgen.com/upgradecentral<http://www.nextgen.com/upgradecentral>

This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter. Thank you for your cooperation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150707/1fbdb364/attachment.html>