<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>I continue to find these discussions fascinating and high-yield, so please don't take my "status quo" reasoning in the wrong light. I'm pushing back on what's different because it's the only way I know to get at the important questions!</div><div><br></div><div>Responses inline (and I've snipped a bunch to try to focus on key points).</div></div><div><br></div><div>Best,</div><div><br></div><div>  -Josh</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></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></div></blockquote><div><br></div></span><div>Talking about an "OAuth-first" approach for setting policies is making me confused.</div></div></div></div></blockquote><div><br></div><div>I was trying to describe an approach to designing scopes that would be amendable to OAuth workflows and UMA workflows. I just wanted to be clear that the UMA policy-setting piece is meant to have a strong, helpful UX, no matter what decisions we make about scope design. So yes: the policy-setting is something that happens in the UMA world, and perhaps that was the source of confusion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I know what it looks like to enable OAuth-like flows in UMA when Alice is both the requesting party and the owner of the resource. And I know what it looks like to enable Alice to set policies at an UMA authorization server (which might hold the results of a previous OAuth-like flow done in UMA). But I don't know what "setting policies in OAuth" means because the OAuth experience is about consenting at run time</div></div></div></div></blockquote><div><br></div><div>I think you introduced the phrase "setting policies in OAuth". I was trying to describe how the policy-setting plays out in UMA, and then thinking through two different ways in which the world might be broken down into UMA-friendly (Resource Set, scope) tuples.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>So the closest UX analog would probably be the wording displayed in an OAuth consent dialog, maybe something like:</div><div><ul><li>View [and prescribe] your medications</li><li>View [and delete] your steps</li></ul></div></div></div></div></blockquote><div>Yes, that's right. Or a runtime OAuth consenting flow like "first pick which record(s) you want to share; then pick which pieces of it to share" (a process that could be repeated as needed to share different pieces of different records).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_extra"></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://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_resource-2Dtypes_StepCounts-3Ahttps-3A__openid.net_heart_scopes_view&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Yvi0iXWjH-HuDwj067Ier3mSZrAAoByMQ55RWTEncls&s=3eZ-ycJwrGeqj21YuaP-LIULSjdLS_pIcorkjW-UcZs&e=" 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></blockquote><div><br></div></span><div>In what sense is "reuse" meant here?</div></div></div></div></blockquote><div><br></div><div>In the sense of: UMA and OAuth both use something called "scopes". To what extent can the same scope values be used in both contexts? Or if not literally the same values, to what extent can we define a deterministic mapping between them, so we only have to define the actual concepts once?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>A coding model, or an architectural model, or a semantic model?...</div></div></div></div></blockquote><div><br></div><div>I'm not sure what these mean, but I think I've answered your question above.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Let's say (totally making this up) the FHIR has two endpoints, with one endpoint for medication records and one for fitness steps. There's an UMA-standardized resource type for each. There's "<b><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_med.json&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Yvi0iXWjH-HuDwj067Ier3mSZrAAoByMQ55RWTEncls&s=XQmQhCmLFsJ8xmKSmiMAjy9ALdeP13Bkn1oF30MKlSc&e=" target="_blank">https://www.hl7.org/fhir/rsrc/med.json</a></b>", with instances of it registered with scopes "<b>view</b>", "<b>download</b>", "<b>transmit</b>", and "<b>add</b>" (so some clients can insert new entries). Alice's medications might be in a resource something like "<b>/alice/meds</b>". (What's displayed in her AS dashboard might look a lot nicer than that.) And there's "<b><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__www.hl7.org_fhir_rsrc_step.json&d=BQMFaQ&c=qS4goWBT7poplM69zy_3xhKwEW14JZMSdioCoppxeFU&r=c7b1QeR755-dBx2b0xnlepDTylromoEzcLl-6ixmBL3TpXSxSvtAvT553fzSgLpm&m=Yvi0iXWjH-HuDwj067Ier3mSZrAAoByMQ55RWTEncls&s=NRFrrL6qQ_Do9SoJ561B8i1oz9_4FoW3I2ZN6_L-mRI&e=" target="_blank">https://www.hl7.org/fhir/rsrc/step.json</a></b>", with instances of it registered with scopes "<b>view</b>", "<b>download</b>", "<b>transmit</b>", and "<b>chart</b>". Alice's steps might be in a resource like "/alice/steps".</div><div><br></div><div>(If the scopes are in the form of URIs, they could be standardized to a further degree, in that a bunch of metadata could be pulled by the authorization server and used to present standard labels and icons, and other semantics could be linked to them.)</div><div><br></div><div>If the very same API were OAuth-protected, with the very same resource endpoints, there might still be the same resource endpoints, with the same scopes, where three of them work on both resource types, "<b>add</b>" only works on "<b>med</b>", and "<b>chart</b>" only works on "<b>step</b>". These resources could still have a standardized meaning in terms of both resource naming and schema/format; there just would be nowhere to "hook" a standardized resource type URI into.</div></div></div></div></blockquote><div><br></div><div>This approach is totally possible. I haven't seen anything quite like it in the wild (but please point me to good examples!), perhaps because the UX of asking someone to consent N times in a row to N different OAuth "authorize" calls could become painful. In typical OAuth implementations, at least, the model is one consent flow per authorization request, and one authorization request per service provider. So we typically see an app asking to connect "to my google account," and then I can specify which pieces. In places where I've seen more fine-grained access, they've either been implicit ("allow this PDF viewer app to read all documents that you open from GDrive <i>with this PDF viewer app</i>" -- so the binding to actual resources happens at runtime), or non-standardized (e.g. Google Docs lets you generate share links, but there's no automated OAuth-y way to do it. It's just a custom in-app interface for generating/revoking these links).</div><div><br></div><div><br></div><div><br></div></div></div></div>