[Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA

Adrian Gropper agropper at healthurl.com
Wed Jul 1 19:27:21 UTC 2015


I don't understand the logic of #1 over #3. UMA is a superset of OAuth and
can do everything it does. The argument for OAuth was developer simplicity.
Having to do both OAuth and UMA means more work for the developer and a
fragmented ecosystem that does not provide as much community support to
either OAuth or UMA.

My vote is on #3.

Adrian

On Wed, Jul 1, 2015 at 2:52 PM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> I would like to toss my chip into the (a): do all the things bucket as
> well.
>
>
>
> Aaron
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Justin Richer
> *Sent:* Wednesday, July 1, 2015 9:20 AM
> *To:* openid-specs-heart at lists.openid.net
>
> *Subject:* Re: [Openid-specs-heart] Principles for selecting "Vanilla"
> OAuth vs. UMA
>
>
>
> So that sounds like you're putting in a chip for Josh's option (a): do all
> the things.
>
>  -- Justin
>
> On 7/1/2015 5:24 AM, Eve Maler wrote:
>
> After overnight reflection (I'm in the UK at the moment), I might have
> been a bit unclear in my previous message, and may have come off sort of
> harsh. If so, I'm sorry about that!
>
>
>
> What I guess I mean is, in our daily lives, we are among the various
> parties in the world who are working on use cases that go through a
> technology selection process and end up choosing OAuth, UMA, OIDC, a
> variety of APIs, solution stacks, etc. With our "HEART hats" on, it's our
> responsibility according to our charter to scan the use case and technology
> selection landscape and be sure we're paying attention to both our own and
> others' experiences along these lines and covering design patterns that are
> worth profiling for security, privacy, and interop on several levels. It's
> not our responsibility to eliminate design pattern options.
>
>
>
> *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, Jun 30, 2015 at 7:21 PM, Eve Maler <eve.maler at forgerock.com>
> wrote:
>
> I'm a little confused about this thread.
>
>
>
> We first launched the group with a discussion that looked like this: "We
> are going to profile a variety of technologies. For those who want to
> deploy technology foo, the profile for foo will be of interest to them. For
> those who want to deploy technology bar which builds on foo, the profiles
> for both foo and bar will be of interest to them." and so on.
>
>
>
> Eventually we produced a picture that looked something like this (this is
> my latest, prettiest version):
>
>
>
> [image: Inline image 1]
>
> Obviously, where vanilla OAuth will suffice, it's interesting because it's
> widely deployed and understood. But for some OAuth-esque flows, UMA can
> provide additional value, and FWIW, I'm in some conversations where this is
> being requested.
>
>
>
> If someone is interested to do something with OAuth towards the purpose of
> "enabling an individual to control the authorization of access to RESTful
> health-related data sharing APIs", of course we should consider profiling
> that function. Likewise, if someone is interested to do something with UMA
> towards that purpose, according to our charter, I would have said we should
> consider profiling that function.
>
>
>
> So I don't understand the question [highlight is mine] "When HEART
> encounters a use case like this, by which principle(s) we should *select* vanilla
> OAuth vs. UMA?"
>
>
>
> *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, Jun 30, 2015 at 2:45 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Josh – I agree and support the notion of soliciting input from those who
> have implemented these types of solutions in the past.  Ensuring that we
> don’t define requirements that are unimplementable is pragmatic  but we
> should not forget that the healthcare system alleges to be consumer
> centric, not software developer centric.
>
>
>
> We shouldn’t abandon appropriate principles because it cost more to
> realize every time we tackle this problem as a nation.
>
>
>
> *From:* Josh Mandel [mailto:Joshua.Mandel at childrens.harvard.edu]
> *Sent:* Tuesday, June 30, 2015 8:57 AM
> *To:* Aaron Seib; Adrian Gropper
> *Cc:* openid-specs-heart at lists.openid.net
>
>
> *Subject:* Re: [Openid-specs-heart] Principles for selecting "Vanilla"
> OAuth vs. UMA
>
>
>
> It would be valuable to solicit input in this discussion from software
> developers who will actually be implementing these services, or who have
> implemented these services in the past. The relative weight and merit of
> "KISS" needs to be informed by the implementer community. Otherwise we risk
> defining principles that work great as principle but lead to downstream
> implementation pain.
>
> For what it's worth, vanilla OAuth certainly supports views of who's
> authorized and the ability to revoke access -- within one authorization
> server at a time. And Adrian's "principle T" could clearly be built in a
> cross-AS way with vanilla OAuth (essentially as a logging API where the
> user specifies a logging endpoint).
>
> Best,
>
> Josh
>
>
>
> On Tue, Jun 30, 2015, 08:39 Aaron Seib <aaron.seib at nate-trust.org> wrote:
>
> +1 Adrian.
>
>
>
> I believe that the consumer should be able to go to a management portal
> and see who is authorized to access their data and be able to deactivate
> that access when they no longer want the relationship to exist.
>
>
>
> I have seen products that support this functionality today – not sure if
> it was OAuth only that supported it.
>
>
>
> Aaron Seib, CEO
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* agropper at gmail.com [mailto:agropper at gmail.com] *On Behalf Of *Adrian
> Gropper
> *Sent:* Monday, June 29, 2015 10:02 PM
> *To:* Aaron Seib
> *Cc:* Josh Mandel; openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Principles for selecting "Vanilla"
> OAuth vs. UMA
>
>
>
> Also, as we debate what KISS actually means in terms of HEART, please
> allow me to propose a second Principle.
>
> *Principle T - (T is for Transparency) - Any HEART transaction between
> Client and Resource Server that includes individual patient-level
> information MUST post a contemporaneous accounting for disclosures message
> to any endpoint specified by the patient.*
>
> Please note that Accounting for Disclosures is required by HIPAA but has
> been widely ignored as "too hard" with legacy protocols. I hope that HEART
> use-cases related to HIPAA take this requirement to heart. There are
> various interpretations of Accounting for Disclosures. Some would require
> the patient to visit each resource server patient portal the way we check
> bank statements. Another interpretation would send the patient a simple
> notice the way many banks email you when a pre-authorized monthly payment
> is made. Most of us that are now signing into three or more banks a month
> to look at the register would agree that being able to set a notice address
> and a policy for when to be notified is a preferable and more scalable
> approach.
>
> I suggest that we have to make "contemporaneous accounting for disclosures
> to any patient specified endpoint" a HEART principle and take that into
> account when we consider the complexity of profiling OAuth or profiling UMA
> for every use-case.
>
>
> Adrian
>
>
>
> On Mon, Jun 29, 2015 at 6:32 PM, Adrian Gropper <agropper at healthurl.com>
> wrote:
>
> +1 Aaron.
>
> Here's a principle I would suggest:
>
> *Principle A - If the Resource Owner takes responsibility for a HEART
> transaction between Client and Resource Server, then the transaction MUST
> go through and the RS gets a safe harbor.*
>
> Adrian
>
>
>
> On Mon, Jun 29, 2015 at 5:39 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
> Josh – I almost didn’t pick up on your bias but the parenthetical gave it
> away.
>
>
>
> I almost always agree that starting with the simplest set of tools first
> and incrementally expanding is the best approach but the fact of the matter
> is that we did this with Direct and said that Direct is just Transport and
> the policy enforcement and representation of Patient Privacy Preferences
> would emerge as needed.  I think Direct has been around as a concept for
> three or four years now and despite widely broadcast claims to the contrary
> the only use cases that it is frequently used for are the simplest – like
> those you can solve with OAuth alone.
>
>
>
> I am sure that there is more to consider but as a counter point to your
> somewhat hidden bias I would offer another veiled bias to not repeat the
> mistakes of the past and actually accept that someone has to solve the hard
> problems cause there are not that many easy ones in healthcare.
>
>
>
> I would like to suggest that we rise to the challenge and pursue a path
> that will have a broader impact with this effort.  If we are just talking
> about transport between two trusted end points where the users already
> trust one another I think there is a methodology on hand to handle that.
> What we need is something that can handle a little more complexity.
>
>
>
> I will take my beatings from the community for speaking out on this issue
> if everyone thinks I am nuts.
>
>
>
> Aaron Seib, CEO
>
> (o) 301-540-2311
>
> (m) 301-326-6843
>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nate-2Dtrust.org&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=wEMNkvG4CHEP-h0wUM8o3RjqoJmPW_nF0iRLkXeVzbk&e=>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Josh Mandel
> *Sent:* Monday, June 29, 2015 5:13 PM
> *To:* openid-specs-heart at lists.openid.net
> *Subject:* [Openid-specs-heart] Principles for selecting "Vanilla" OAuth
> vs. UMA
>
>
>
> On today's call we discussed a use case where a patient can help connect
> her patient portal (a.k.a. her EHR account) account to an external PHR.
> This is a great, common use case that we know we could handle with either
> "vanilla" OAuth, or UMA, or both. Of course, software systems need to know,
> up front, whether they'll be talking vanilla OAuth or UMA -- because the
> wire protocols are different.
>
>
>
> The question: When HEART encounters a use case like this, by which
> principle(s) we should select vanilla OAuth vs. UMA? Some examples of
> principles (to stimulate discussion) might be:
>
>
>
> *Example principle #1: "Do all the things"*
>
> We should produce two profiles each time this kind of situation comes up:
> one describing how to do it with vanilla OAuth, and one describing how to
> do it with UMA. This provides maximum flexibility for implementers with
> different needs/contexts.
>
>
>
> *Example principle #2: "KISS"*
>
> Any time vanilla OAuth can handle a use case, we should use vanilla OAuth.
> Save UMA for when it's required. This provides a simpler environment with
> fewer moving parts and stronger out-of-the-box software library support.
>
>
>
> *Example principle #3: "UMA everywhere"*
>
> Use UMA across the board, and avoid vanilla OAuth. Since UMA handles a
> more general set of use cases, and there's value in consolidation, UMA
> should be the preferred option in all cases. This way, implementers only
> ever need to do one (very general) thing.
>
>
>
> (I've tried to state these examples neutrally, but I must admit bias in
> favor of #2. Does that come through?)
>
>
>
> Looking forward to discussion,
>
>
>
>   -Josh
>
>
>
> _______________________________________________
> 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__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=LecIgXIFC9tivHNWP-gc4XTuasRZYGvNaV4ZFNFCnEg&e=>
>
>
>
>
> --
>
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=4hShFnNwgWw3-5xNU7OurqLFaHiaM9OneSrzGCWHmbw&e=>
>
>
>
>
>
>
>
> --
>
> Adrian Gropper MD
> Ensure Health Information Privacy. Support Patient Privacy Rights.
> http://patientprivacyrights.org/donate-2/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__patientprivacyrights.org_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=4hShFnNwgWw3-5xNU7OurqLFaHiaM9OneSrzGCWHmbw&e=>
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> 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
>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> 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/20150701/44750c18/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 50273 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/44750c18/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/44750c18/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/44750c18/attachment-0003.jpg>


More information about the Openid-specs-heart mailing list