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

Eve Maler eve.maler at forgerock.com
Thu Jul 9 15:17:51 UTC 2015


John, no doubt you're 200% overbooked, but if we could attract you to the
UMA meetings, you'd probably find our current workstream fascinating. :-)
The Kantara Leadership Council members laugh at me for getting excited
about the "BLT sandwich" (business-legal-technical) progress updates I give
them... We are literally mapping specific bits of UMA flows to the norms of
sociotechnical systems being identified in cutting-edge academic research.

Then again, maybe I need to get a life.


*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 Thu, Jul 9, 2015 at 8:07 AM, Moehrke, John (GE Healthcare) <
John.Moehrke at med.ge.com> wrote:

> Eve,
>
>
>
> You are right on…
>
>
>
> As one of the co-chairs of the HL7 Security wg, I have struggled with
> this. However in Healthcare we must keep moving forward. So the work in HL7
> is to incrementally improve the ability to capture anything we can related
> to the act of consent, and the meaning of that consent. We recognize these
> as difficult domains. Historic precedent in healthcare is embarrassing.
>
>
>
> In HL7 we have two different encodings. One is based on the format of a
> document used for all other medical-fact documentation (CDA). The format is
> not important, but it is important to indicate that it is a form that
> healthcare handles for almost everything related to the patient, so it is
> easy for them to handle it for this purpose too. It is a form however that
> is totally foreign to any access control decision system. We thus recognize
> that the rules might be ‘equivalently’ encoded in some access control
> decision language (common is XACML today). The equivalency is left to
> humans to agree… Thus the bridging of the divide between them is not
> computable, but we are trying.
>
>
>
> The HL7 FHIR effort is just getting going, and for the most part will
> start with the same capability, just with different technical encoding.
> Still not necessarily fixing the big issue… But getting more processable
> (FHIR is predominantly HTTP/REST and encodes things in more simple XML or
> JSON; where as CDA is ugly XML).
>
>
>
> The actual systems-design might have the Access Control rules interjected
> at the time that the patient gives consent; or might interpret the consent
> at the time of needing to make a decision. This is a systems-design
> responsibility that is not the role of HL7. There are good reasons to do
> either, especially since healthcare is a lifelong effort (so we think in
> 100+ years).
>
>
>
> So, look to HL7 to help with capturing the ceremony of Consent. But they
> definitely need help with the Enforcement, we hope HEART can help with. AND
> we all need to work on everything in-between.
>
>
>
> John
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Eve Maler
> *Sent:* Thursday, July 09, 2015 9:47 AM
> *To:* Kinsley, William
> *Cc:* openid-specs-heart at lists.openid.net
>
> *Subject:* Re: [Openid-specs-heart] Flip the question of “Vanilla" OAuth
> vs. UMA
>
>
>
> Hi Bill-- I'm not sure what the HL7 consent/contract standards are about,
> but based on what I know of "notice and consent" (privacy) theory, and
> "contract" (legal) theory (IANAL but I have collected lawyers for many
> years as part of my UMA work), there is not very much in the technical
> underpinnings of almost any technical or machine-readable consent flow used
> on the web today, to support a true non-adhesion contract for Alice.
> (Perhaps the closest thing on the OAuth side would be requiring an OAuth
> scope unchecking facility, but that's still not a formal mapping to a
> contract model -- has someone done that mapping?)
>
>
>
> In the UMA group, with the help of Tim Reiniger (the primary drafter of
> the new Virginia digital identity law), we have recently started applying a
> "license" vs. a "contract" paradigm to the UMA flows. In fact, we're
> planning to discuss this on today's UMA call in a little over an hour.
>
>
>
> I may be on the wrong track here, but this is what your note put me in
> mind of...
>
>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e=>
> community!
>
>
>
> On Wed, Jul 8, 2015 at 8:08 AM, Kinsley, William <BKinsley at nextgen.com>
> wrote:
>
> I need Eva to verify that what I am saying is correct, I am still coming
> up to speed on UMA … HL7 has/is developing FHIR consent(contract) standards
> and I believe the oAuth and UMA profiles are in scope to support these and
> possibly others.
>
>
>
> To easily support interoperability, is it possible (or in scope) to
> develop profile standards or profile taxonomy that would be flexible and
> adaptable so that the RS would be able to process FHIR consents even if
> they are modified by a specific implementation without  special coding.
> This could be too idealistic, out of scope or just not supportable with
> oAuth and/or UMA profiles.
>
>
>
> For example: A client could connect to any FHIR resource and process any
> Heart Profile that is provided, even if the client is another RS running in
> a “Client” role to another RS .
>
>
>
> Bill
>
>
>
> *From:* Eve Maler [mailto:eve.maler at forgerock.com]
> *Sent:* Tuesday, July 07, 2015 10:00 PM
> *To:* Aaron Seib
> *Cc:* Kinsley, William; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Flip the question of “Vanilla" OAuth
> vs. UMA
>
>
>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.kantarainitiative.org_uma_rec-2Doauth-2Dresource-2Dreg-2Dv1-5F0.html-23rfc.section.4&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=XZvNdZZ9gPcuIcTPhPiiE_QBSahOHLBvTzItUZRdivI&e=> that
> is mitigated by the use of "well-known and standardized" description
> elements. (See this UMA issue
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_xmlgrrl_UMA-2DSpecifications_issues_151&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=71o1AnmsYBp0TU9vvpx_TuaYsMN1txaagwxyDCElFnc&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__forgerock.org_openuma_&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=N6U-VffSODQM0Eo_2TrZgSe_XSZepWfJ14eAp4h6qGY&e=>
> community!
>
>
>
> On Tue, Jul 7, 2015 at 2:56 PM, Aaron Seib <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
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=tPRDdAyGDknsaFwvwbIPyKu9NkZpJ-UX0L62WfJTfPk&e=>
>
>
>
> *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
>
>
>
>
>
>
>
>
>
>
>
>
> *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
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
> *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
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>*
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
> 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.
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.oneugm.com&d=AwMFaQ&c=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI&r=B4hg7NQHul-cxfpT_e9Lh49ujUftqzJ6q17C2t3eI64&m=G5SLFEapI55EmVv6qepixkuIjAo8MIS-sDAtWeTMWBY&s=bzR8BQA3rz7axUDSwHpXrotdgE261lSqW-LBhoq1GWs&e=>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150709/00079dea/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/20150709/00079dea/attachment-0001.jpg>


More information about the Openid-specs-heart mailing list