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

[Debbie Bucci]

Before someone says it....I know folks were hesitant to keep discovery in
scope and we kind of waved our hand about it but  for some use cases we
need to figure out the flows that make sense ...
On Apr 5, 2015 9:27 PM, "Justin Richer" <jricher at mit.edu> wrote:

> 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
>
> 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
>
>
>
> _______________________________________________
> 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/afc005b2/attachment-0001.html>