<div dir="ltr">Thanks for sending notes, Debbie! A couple of tweaks below:<div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell <a href="tel:%2B1%20425.345.6756" value="+14253456756" target="_blank">+1 425.345.6756</a> | 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 Wed, Aug 5, 2015 at 12:26 PM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.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>Attendees:</div><div>Eve Maler</div><div>Justin Richer</div><div>Josh Mandel</div><div>Adrian Gropper</div><div>Thomas Sullivan </div><div>Debbie Bucci</div><div><br></div><div>We have decided to delineate between mechanical and semantic scope docs.</div></div></blockquote><div><br></div><div>(Just "semantic", I think. The UMA doc, at least, will have more than scopes, and the OAuth one might possibly, too.)</div><div><br></div><div>We decided call the profiles that are just for security purposes "mechanical" so that we could name them right in the use case, everywhere the [PROFILING] tag appeared. I took a stab at defining what we mean by "semantic": "Related to either the FHIR API, or the content of the resources accessed through it" (or something like that).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>For the PCP <-> PHR use case:</div><div><br></div><div>The pre determined choice token confidential token choice and exactly what information needs (example: PHR's authorization endpoint) to be shared in advance between the PCP's EHR and Alice's PCP was left out of the discussion for now.</div></div></blockquote><div><br></div><div>I think we were talking here about a "confidential client" and what information it needs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>There is one basic mechanical Oauth generic flow that occurs twice in the use case.</div><div><br></div><div>Given the group has generally agreed that the SMART specifications are a good place to <em><strong>start </strong>... </em>for this particular use case the only semantic FHIR scope that is necessary is the patient/*.read scope that grants permission to read any resource for the current patient.</div></div></blockquote><div><br></div><div>So in other words, we're suggesting that the client ask for "the whole enchilada"...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>During the registration process Alice should be able to select at a fine grain level which resources she is willing to share with the PHR. This mimic's a specific process - Adrian please provide. This information will be used to generate the access token.</div></div></blockquote><div><br></div><div>...and that Alice be able to uncheck scopes she doesn't want to grant. Adrian talked about an "ROI" form (and I know he didn't mean return on investment -- can't remember what it stands for).</div><div><br></div><div>(This isn't a tweak, just a comment:) One of the things that trust frameworks above might want to nail down, over and above our profiling, is requirements around the UX displayed to patients to ensure they understand what they're authorizing. Even at our profile level, if there are large numbers of scopes for Alice to consider (I don't know how many there are), we may want to consider different ways of bucketing them as OIDC has done for attributes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>The one thing left at the end of the discussion is whether the patient record is implicit or explicitly stated. This is a design decision that may make a difference as we move towards our next use case in which delegation is a factor.</div><div><br></div><div>Corrections/updates appreciated. </div><div><br></div><div><br></div></div>
<br>_______________________________________________<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><br></div></div>