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

Thu Jul 9 14:46:38 UTC 2015

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 <http://forgerock.org/openuma/> 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://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>
> 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] *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
>
>  <http://www.oneugm.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.oneugm.com>*
>
>   <http://www.oneugm.com>
>
> 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.
> <http://www.oneugm.com>
>
>   <http://www.oneugm.com>
>
>   <http://www.oneugm.com>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> *Openid-specs-heart at lists.openid.net*
> *http://lists.openid.net/mailman/listinfo/openid-specs-heart*
> <http://www.oneugm.com>
>
>    <http://www.oneugm.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150709/f4ee791e/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/f4ee791e/attachment-0001.jpg>