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

Josh Mandel Joshua.Mandel at childrens.harvard.edu
Tue Jun 30 12:57:07 UTC 2015


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=>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150630/7a2453de/attachment-0001.html>
-------------- 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/20150630/7a2453de/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/20150630/7a2453de/attachment-0003.jpg>


More information about the Openid-specs-heart mailing list