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

Wed Jul 8 02:45:05 UTC 2015

A part of me wishes we would separate out the resource labeling while
potentially keeping it in scope. How far could we get by defining just one
really non-controversial resource like Alice's allergies? Or one really
useful resource like Alice's insurance coverage? Sooner or later, we may
need to deal with replacing the current role of CCD-A as a transition of
care document and more.

In the long run, the health standard groups like HL7 are going to need
market drivers or regulations to do most of the resource mapping. I don't
see this as a current priority for HEART.

Adrian

On Tuesday, July 7, 2015, Eve Maler <eve.maler at forgerock.com> wrote:

> Commenting on one of Aaron's bulleted items:
>
> Profiling "a standard way to label assets managed by the RS" is one of the
> tasks I was contemplating to be potentially in scope for our semantic UMA
> profile. This is because it is possible for resource set descriptions
> (these are things that an UMA RS registers at an AS, to put resources under
> protection) to include resource types. As I understand it, the FHIR API
> conveys data structures that reflect quite a lot of HL7 standardization
> work already done, which amounts to "resource typing".
>
> While a lot of companies with proprietary APIs might not want to
> standardize their resource assets, there's a lot of power in standardized
> resource labeling in open ecosystems like the one we're working on. For
> starters, there's a security consideration
> <https://docs.kantarainitiative.org/uma/rec-oauth-resource-reg-v1_0.html#rfc.section.4> that
> is mitigated by the use of "well-known and standardized" description
> elements. (See this UMA issue
> <https://github.com/xmlgrrl/UMA-Specifications/issues/151> for some
> background.) For another example, standard types could drive automated
> policy workflows in interesting ways.
>
>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
> On Tue, Jul 7, 2015 at 2:56 PM, Aaron Seib <aaron.seib at nate-trust.org
> <javascript:_e(%7B%7D,'cvml','aaron.seib at nate-trust.org');>> wrote:
>
>> 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
>>
>> <http://nate-trust.org>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:
>> openid-specs-heart-bounces at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *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
>> <javascript:_e(%7B%7D,'cvml','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 *
>> *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.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> <javascript:_e(%7B%7D,'cvml','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 <javascript:;>
> 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/20150707/f03fca2e/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/f03fca2e/attachment-0001.jpg>