<div dir="ltr">There's a really old issue on the UMA docket, here:<div><br></div><div><a href="https://github.com/xmlgrrl/UMA-Specifications/issues/20">https://github.com/xmlgrrl/UMA-Specifications/issues/20</a></div><div><br></div><div>Unless you're an UMAnitarian who has been around a while, though, reading through it may not help very much. So here is an attempt to give a brief layman's description of some background.</div><div><br></div><div>In <b>plain OAuth</b>, a client application has to be smart enough to know all about the API it's calling, natch, and also what <b>scopes</b> to ask the authorization server (AS) for, like "I want write access, not just read access". It also needs to know <b>where</b> the AS is, because it's going to have to go straight there.</div><div><br></div><div>In <b>the UMA profile of OAuth</b>, a client app -- which, you'll recall, might be used by someone who isn't the owner of the protected resources (Bob, say, instead of Alice) -- needs to know how to use the API, but it starts out knowing only the <b>location of the resource</b> it wants, and not anything else. So it "hits" the resource and gets told "Go to this AS location, take this permission ticket along, and you might or might not ultimately get the access token and scopes you're seeking." Essentially, it's allowed to be a lot dumber wrt AS location (it's told where to go) and scopes (it's never told what they are!). But it had to know (be told out of band, somehow) what the resource-of-interest was.</div><div><br></div><div>There are a variety of opportunities and challenges here...</div><div><ul><li>An UMA client that is able to be "smarter", going directly to an AS and asking for the scopes/permissions it wants, could be more efficient</li><li>The ability to have a discovery service that "blinds" the locations of health resources could protect those resources better, because even revealing the location URIs could be privacy-destroying (.../aids/test-results etc.)<br></li><li>An UMA client that knows the resources it wants but doesn't know precisely where they live could go to a discovery service to look up their locations</li><li>An UMA AS that is also a discovery service would be a pretty handy thing</li></ul><div>Notice that I'm kind of conflating two different things here. I'm honestly not sure if the "smarter client" goal is super-worth it, vs. the "discovery service co-located with the UMA AS" goal, but I'm throwing it out there because I've discussed it so many times with John Bradley, Nat Sakimura, Justin Richer... I'll also point out that we put discovery out of scope for this WG. :-)</div></div><div><br></div><div>Last thing I'll mention (noted in the linked issue) is that the UMA WG did put a solution in its "OAuth Resource Set Registration" spec, which can work with OAuth OIDC as well as UMA, to enable location discovery. It's the "uri" property, defined as "A URI that provides the network location for the resource set being registered." One way to use this is for an OIDC attribute provider to register locations of claims with a central IdP for building up distributed claims to be discovered.</div><div><br></div><div>Hopefully this note isn't overwhelming, and whets the appetite of our diverse WG membership to learn and discuss more!</div><div><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>
</div></div>