[Openid-specs-heart] As promised, background on UMA discovery and client-to-AS-first

[Justin Richer]

UMA doesn’t make the client smarter, it makes it differently stupid.

One problem with this RS-focused approach is that it doesn’t let the client ask for the minimal set of scopes that it needs to do something. UMA kinda assumes that the RS will hand out the right permissions set to the client, and if it didn’t then the client will be smart enough to ask again and get a new ticket with more permissions, somehow. This is fine if each resource maps 1:1 with a permission set, but a client is likely to know more about what it’s trying to do than an RS will at runtime, especially because the RS doesn’t know what client is asking for stuff or why. It just knows someone showed up for stuff and so I guess we’d better go get them a thing.

This is why in OAuth the client requests a set of scopes at authorization time. It’s trying to do something and it has an idea what that is, and the user can be asked at runtime about those permissions, interactively. It’s the classic alice-to-alice sharing that Eve talks about.

One can imagine a scenario in UMA wherein the RPT is actually a pre-scoped OAuth token, and UMA is used only for step-up credentials. Or UMA is used for discovery of the AS and the client kicks off a normal OAuth transaction from there, no tickets or RPTs or other stuff. (OAuth is severely lacking in service discovery and automation-connection aspects.) I think there’s something there and it hasn’t been adequately explored yet.

 — Justin (who is trying to avoid getting stuck writing the generic OAuth Discovery spec in the IETF)

> On Apr 5, 2015, at 3:33 PM, Eve Maler <eve.maler at forgerock.com> wrote:
> 
> There's a really old issue on the UMA docket, here:
> 
> https://github.com/xmlgrrl/UMA-Specifications/issues/20 <https://github.com/xmlgrrl/UMA-Specifications/issues/20>
> 
> 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.
> 
> In plain OAuth, a client application has to be smart enough to know all about the API it's calling, natch, and also what scopes to ask the authorization server (AS) for, like "I want write access, not just read access". It also needs to know where the AS is, because it's going to have to go straight there.
> 
> In the UMA profile of OAuth, 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 location of the resource 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.
> 
> There are a variety of opportunities and challenges here...
> 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
> 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.)
> 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
> An UMA AS that is also a discovery service would be a pretty handy thing
> 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. :-)
> 
> 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.
> 
> Hopefully this note isn't overwhelming, and whets the appetite of our diverse WG membership to learn and discuss more!
> Eve Maler
> ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150405/e2153116/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150405/e2153116/attachment.asc>