<div dir="ltr">And, er, when I said "Alice signs into her resource server", I meant "<b>authorization</b> server".</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 15, 2015 at 5:24 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hi all,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I didn't mean to take a hard-line position on today's call about scope definitions! To my mind, our approach to scopes will need to work hand-in-hand with our approach to endpoint (or resource set) discovery -- so I feel a bit awkward discussing scopes here in isolation. But that said, let me see if I can at least highlight the tension that we heard in the past hour's discussion (in a neutral way):</div><div class="gmail_extra"><br></div><div class="gmail_extra">---</div><div class="gmail_extra"><i>Goal: Whatever the model, we want to support a use case where Alice signs into her resource server and can set some policies in an intuitive way. |She'd see something like (very, very roughly):</i></div><div class="gmail_extra"><br></div><div class="gmail_extra"> My Medications: </div><div class="gmail_extra"> * Who can view?</div><div class="gmail_extra"> * Who can write new prescriptions?</div><div class="gmail_extra"><br></div><div class="gmail_extra">My Step Counts</div><div class="gmail_extra"> * Who can view?</div><div class="gmail_extra"> * Who can remove?</div><div class="gmail_extra">---</div><div class="gmail_extra"><br></div><div class="gmail_extra">The question is about how this works under the hood.  I think we were discussing two models:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Model 1: The "UMA-First" approach</b></div><div class="gmail_extra"><i>We have a resource set like "Alice's Medications", with scopes like "view" and "prescribe". And we'd have a resource set like "Alice's Step Counts" with scopes like "view" and "delete".</i></div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Model 2: The "OAuth-First" approach</b></div><div class="gmail_extra"><i>We have a resource set like "Alice's FHIR Endpoint", with scopes like "Medications.view", "Medications.prescribe", "Steps.view", and "Steps.delete".</i></div><div class="gmail_extra"><div class="gmail_extra"><br></div><div class="gmail_extra">If the *types* of Resource Sets and the allowed scopes are standardized in advance (which UMA supports), then a mapping between Model 1 and "vanilla" OAuth could be as simple as: "concatenate the UMA resource set type followed by ':' followed by the UMA scope name" -- so for example, you might derive an OAuth scope like "<a href="https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view" target="_blank">https://openid.net/heart/resource-types/StepCounts:https://openid.net/heart/scopes/view</a>". Or under Model 2, the scopes could be reused directly (no mapping required). </div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course, some interesting things happen when we layer in details like...</div><div class="gmail_extra"><br></div><div class="gmail_extra">W<i>hat if Alice has access to <b>multiple records </b>(say, her own and her mother's)?</i> In vanilla OAuth the binding of permissions to these records is generally implicit. How should they play out in UMA? Under Model 1, we'd probably see two more Resource Sets created ("Alice's Mom's Medications" and "Alice's Mom's Steps"). Under Model 2, we'd probably see one more Resource Set created ("Alice's Mom's FHIR Endpoint").</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>
</blockquote></div><br></div>