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

Aaron Seib aaron.seib at nate-trust.org
Wed Jul 1 18:52:37 UTC 2015


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): 

 

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>
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=BQMF
aQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTy
lromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruh
ILdIbP-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_mailma
n_listinfo_openid-2Dspecs-2Dheart&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZM
SdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSg
Lpm&m=ryqH6CnV4EuvUczah4T-_bOvQ-k_dgfruhILdIbP-As&s=LecIgXIFC9tivHNWP-gc4XTu
asRZYGvNaV4ZFNFCnEg&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.or
g_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1Q
eR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUc
zah4T-_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.or
g_donate-2D2_&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1Q
eR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=ryqH6CnV4EuvUc
zah4T-_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

 

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


More information about the Openid-specs-heart mailing list