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

Tue Jul 7 21:56:59 UTC 2015

Thanks for starting this new thread.

I am not expert in this space (yet) but let me see if I can repeat back what
I think you are proposing.  

Are you suggesting that for Resource Server (RS) be able to accept a
standard profile authorization assertion (based on the UMA profile) from a
standard (UMA-based) Authorization Server (AS)?   

I maybe out of date but I seem to remember reading that the UMA profile
states that the Authorization Policy service capabilities (as required to
implement an AS) are out of scope for the UMA profile - as are the specific
policies for how you label assets (network, applications, data) managed by
the RS with access tokens that are registered with and managed by the AS.  

To echo back your language is your suggestion that it ^would^ be simpler to
have consistent patterns (libraries) implemented that would address what the
UMA profile has intentionally said is out of scope?  I.e., 

·        addressing the need for a standard way to label assets managed by
the RS; and (?) 

·        a standard way to represent the inputs to an Authorization Policy
Service

In my mind this would allow us to not only solve the simple cases but also
enable us to develop libraries that represent the applicable policy of a
given Federal Reg or libraries of applicable state law that could be re-used
by everyone.  It might also enable the different associations to provide
recommended policies to be adopted by their members and plugged into the
solution following a period of local policy tweaking by a given institution
or Agency.

Am I getting this right?

Aaron Seib, CEO

@CaptBlueButton 

 (o) 301-540-2311

(m) 301-326-6843

From: Openid-specs-heart
[mailto:openid-specs-heart-bounces at lists.openid.net] On Behalf Of Kinsley,
William
Sent: Monday, July 06, 2015 8:45 PM
To: openid-specs-heart at lists.openid.net
Subject: [Openid-specs-heart] Flip the question of “Vanilla" OAuth vs. UMA

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

  <rtfimage://> 

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

 <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
<http://www.nextgen.com/upgradecentral> 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/cf47b2fd/attachment-0001.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/20150707/cf47b2fd/attachment-0001.jpg>