Part 1 illustrates the "UMA1" path through the current spec, where a "dumb" client can get by just fine without asking for any scopes and just accepting the context that's in the permission ticket. The RS gets to dictate whatever resource IDs and their scopes are to be considered, they get associated with the permission ticket, and this flow from AS to RS to client and then back to AS. The thinking in UMA1 was that, since it's party-to-party sharing and "user-managed access", whatever is in what we now call RequestedScopes is at the mercy of the calculated result of CandidateGrantedScopes; any access a client actually attempts that's allowed by policy would ultimately be granted, the whole thing generally acting in a minimal disclosure fashion.

Part 2 illustrates (at a high level) the "OAuth" path we've been working to design into the spec, where a "smart enough" client can request scopes at the token endpoint (if it's been smart enough to pre-register for them first). We tend to get stuck, I think, because the AS and RS are privy to information the client doesn't have and seems to need -- mostly a) which scopes were granted, but also b) which "resources in a generic sense" the requested and granted scopes belong to. Unfortunately, a resource ID represents a resource that's bound to its resource owner context by virtue of the RReg mechanism; we don't currently have a way to give the client the rest of the resource information without that context. (I've been looking at this I-D and can't tell if it applies or not.)

Part 3 assumes a putative way to pass around that information, which I'm calling "resource types" for now. I guess my questions are, How valuable do we think it is for a client to request scopes while asking for an RPT, and if it's really valuable, how much effort should we put into solving the problem "correctly" and "thoroughly" in the context of UMA and the goals of the current release?