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

[Eve Maler]

There's a really old issue on the UMA docket, here:

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150405/3a5b2d91/attachment.html>