<div dir="ltr"><div>Thanks so much for this Josh.   Justin will be in Prague next week so I would like to postpone the broader scope/approach discussion until he returns and Eve is available as well.  I have no answers - just questions and lots of them!</div><div><br></div><div>Instead I would like to use that time as an opportunity to pull the focus back to the PHR *as source of truth* and do as we originally intended - focus on the use case. </div><div><br></div><div>Gajun Sunthara has been building an open source  FHIR based PHR from scratch as a way to understand the underlying standards and protocols.   It's been amazing to see the concepts develop over time as he's socialized his efforts.</div><div><br></div><div> He has implemented OpenID Connect and has connected to a number FHIR resources and created a local store of his own.   Additionally he has a running list of endpoints that seem to align with what I think a personal  UMA authorization may look like (at least to a consumer).   So many ways to extend those concepts.</div><div><br></div><div>The authorization service - or source of truth will need to be flexible and meet the consumers need across a number of different RS clients and APIs and standards.  Gaj's UI makes me believe its possible to do.</div><div><br></div><div><div>if there is time after the demo, I'd like to use to focus on JUST the scopes that a PHR would need to communicate and enable read/write between PHR and PCP as both client and RS.</div><div><br></div><div><br></div><div>Deb</div></div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 11:31 AM, Josh Mandel <span dir="ltr"><<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><p style="font-size:12.8px" dir="ltr">As promised: this is the version of the SMART on FHIR specification that includes the most recent changes in response to review from the Argonaut participants: <a href="http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/" target="_blank">http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/</a></p><p style="font-size:12.8px" dir="ltr">Beyond a set of editorial changes, the most relevant updates are:</p><p style="font-size:12.8px" dir="ltr">1. Addition of "aud" as a parameter on the authorization request. This is a security fix that mitigates against a malicious resource server (in the absence of a whitelisting protocol by which public client apps decide which resource servers to trust).</p><p style="font-size:12.8px" dir="ltr">2. Moved "launch:" out of the scopes list and into a separate parameter of the authorization request (this cleans up the semantics of our scopes list a bit, and sounds similar to what we were calling an "audience" on today's phone call).</p><p style="font-size:12.8px" dir="ltr">3. Added a scope called  "online_access" (by analogy to the OIDC "offline_access" scope). This scope is used to request a refresh token that lasts until a user signs out of the EHR.</p></div><div class="gmail_extra"><br><div class="gmail_quote"><div><br></div></div></div></blockquote></div></div></div>