[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