[Openid-specs-heart] Public FHIR Endpoints - are there any OAUTH endpoints to register and test

Aaron Seib aaron.seib at nate-trust.org
Tue Jul 21 14:22:31 UTC 2015

Yes, agile.  A handy def for agile might be:

- Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Perhaps, I am suggesting, we evolve the description of the requirements reusing what Argonaut has solved for to more explicitly delineate the greener-field aspects where UMA et al. compliment the solution space ?

Sent from my Verizon Wireless 4G LTE smartphone

<div>-------- Original message --------</div><div>From: Debbie Bucci <debbucci at gmail.com> </div><div>Date:07/21/2015  9:47 AM  (GMT-05:00) </div><div>To: Aaron Seib <aaron.seib at nate-trust.org> </div><div>Cc: Adrian Gropper <agropper at healthurl.com>, Justin Richer <jricher at mit.edu>, 	openid-specs-heart at lists.openid.net </div><div>Subject: Re: [Openid-specs-heart] Public FHIR Endpoints - are there any OAUTH endpoints to register and test </div><div>
</div>Eve posted a great visual a few weeks back.  Both UMA and OpenID Connect are layered on TOP of OAuth.

We need to start somewhere and focusing on the base seems the appropriate place to start from my POV.

I personally need to build to see...in order to understand the changes/adjustments that may need to be made to the base as we build upon it.

Agile right?

On Jul 21, 2015 8:51 AM, "Aaron Seib" <aaron.seib at nate-trust.org> wrote:
I am in the same boat as Justin – Dragon and I had a sidebar about this a week or so back and came to the same conclusion. 


The Use case should determine what is employed.  I am a visual guy – if we had a set of concentric circles OAUTH would be the center, a band of both OAUTH and UMA would surround that and then UMA would be the outer band.


Probably not helpful without some arrows that label the use case supported by each band but that is the way I have pictured it.  I am not sure that visualization stands up as I don’t know that you ever have a use case with UMA in isolation of OAUTH.  Can someone correct me?


It might help to spell out a specific use case in the legacy language of disclosure based on push:


1.      EMR1 sends protected health data to PHRA;

2.      Consumer using PHRA sends content from (1) to EMR2

3.      EMR2 receives content and its workflow can differentiate between PGHD and data that is unchanged since it left EMR1.


Could anyone on this thread convert this transaction into the OAUTH\UMA domain so that a layman would understand?



Aaron Seib, CEO


 (o) 301-540-2311

(m) 301-326-6843

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150721/cc225b6c/attachment-0001.html>

More information about the Openid-specs-heart mailing list