<div dir="ltr">Adrian, I'm just reviewing that bit now. In #4, "Alice then authorizes her PCP’s EHR (which now acts <b>as an authorization server</b> [<i>that's mention number 2</i>]) to update her PHR (which now acts as a client) every time the PCP’s EHR has new medical information (this information is a protected resource) about Alice." That mention is either a) weird, because the EHR would be acting as a resource server, rather than an authorization server, if it's generating data that the PHR is being a client for, or b) perhaps sensible, if we're freely mixing OAuth and UMA authorization servers in the same use case and we've got both here. In the latter case, I think we're going to have to get down to brass tacks and mention technologies throughout to remove ambiguity.<div><br></div><div>The 15 comments are, in fact, the result of notes taken during calls, and aren't questions pending any decisions. (As an aside, I would love to reformat the use case at some point to mark the core and peripheral parts more cleanly, but will wait on that...) So I don't think we're required to resolve them before proceeding.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Jul 26, 2015 at 7:52 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I look forward to the discussion. <br><br></div>The shared doc has some 15 comments. Can these be resolved before the call or will they need some other process for resolution?<br><br></div>I would like to propose the following topic for discussion around this use-case:<br><br></div>The use-case, as it's written, presumes that there are as many Authorization Servers as there are Relying Parties (2). Is this consistent with the HEART charter? Is it practical? Is it necessary for some reason?<br><br></div></div>Adrian<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Jul 26, 2015 at 9:33 PM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><p class="MsoNormal" style="font-size:13px"><b>Agenda :</b></p><ul style="font-size:13px"><li style="margin-left:15px">Visual Roll call <br></li><li style="margin-left:15px">OAuth Semantics/Approach - Eve Maler<br></li><li style="margin-left:15px">AOB</li></ul><br>Note to health subject matter experts - fair warning that we are going to get in the technical weeds tomorrow. We plan to go slow - so please join and ask questions. Its important for everyone to have a base understanding.<br><br>We will continue to focus on the Alice Enrolls with PCP use case but pull back a bit and instead of focusing on OAUTH scopes - talk more about the semantic approach we should take; separate the general security layer/requirements from FHIR.<br><br>Google Doc reference: <a href="https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit#heading=h.z5kasfweex6t" target="_blank">https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit#heading=h.z5kasfweex6t</a><br><br>We plan to start promptly at 4:00 and final wrap up at 4:55. We do hope you will join us.<br><br></div>
<br></div></div>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u> </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div></div>
</font></span></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>