[Openid-specs-heart] Principles for selecting "Vanilla" OAuth vs. UMA
Justin Richer
jricher at mit.edu
Wed Jul 1 13:20:06 UTC 2015
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
> <mailto: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):
>
> 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 <tel:%2B1%20425.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 <mailto: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
> <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
> <mailto: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 <mailto: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 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel:301-326-6843>
>
> <http://nate-trust.org>
>
> *From:*agropper at gmail.com <mailto:agropper at gmail.com>
> [mailto: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
> <mailto: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 <mailto: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
> <mailto: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 <tel:301-540-2311>
>
> (m) 301-326-6843 <tel: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
> <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
> <mailto: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
> <mailto: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
> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/ef89d5db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 47402 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/ef89d5db/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/ef89d5db/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 3142 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150701/ef89d5db/attachment-0003.jpe>
More information about the Openid-specs-heart
mailing list