Let's explore the specific use cases that highlight limitations or impedance mismatches of current flows.
If I understand correctly, Pedro's and Mike's use cases are very similar. We've generally been calling this an API security use case. (BTW, just saying they're "NPE" use cases is ambiguous because there are other flows where a human resource owner shares with an NPE requesting party at some point, but the API security use case does have a non-person entity (organization) as an RO.)
API security is like traditional web services security use cases, and it's a situation where a security architect would often reach for vanilla OAuth.
Questions for you guys: What's the "coupling quotient" of the real-life use cases being considered? How often are the AS and RS in the same security domain? How often does the client need to get credentials dynamically vs. pre-provisioned? (Note that OAuth ecosystems today are tightly coupled by nature: The AS/RS is in one domain, and clients are statically provisioned with credentials, often to be sure that they can execute terms of service.) How often is the client running autonomously, vs. operated by a human?
The API security use case overall would normally already be signed up to a smart client that knows the API, knows the API's scopes, knows the AS location, and wants to get down to making API calls. In a person-to-person delegation use case, Alice is likely to give Bob first-order consideration -- he'll get what scopes he'll get, and he'll like it! -- in configuring policy constraints.* But in autonomous-client API security use cases, I suspect AliceCorp needs the client to be more, well, autonomous in wanting to request every scope it can handle, and perhaps in some human-operated client variants (AliceCorp-to-Bob) of the API security use case as well (asking up-front for everything it can handle).
So, based on this analysis, some thoughts and key questions.
Thoughts: As I had noted to Pedro in private email back in October, there is an “
extensibility profile” in the UMA Core spec to allow lots of optimizations when the RS and AS are tightly coupled. This would enable more efficient RS-AS communication regarding resource set registration, permission registration, and token introspection — it could all be “implicit” because the same hunk of software is on both sides. However, some tokens would still have to be produced for client consumption because it may still be a third-party hunk of software.
Key questions: What are the actual use cases on the ground so far? Are they such that the extensibility profile in the spec provides a starting point from which we could work outward? Or do they support a serious requirement for a "client-to-AS-first" flow in the context of a loosely coupled RS and AS, vs. the currently native "client-to-RS-first" flow in UMA V1.0.x that drove the design of the existing permission ticket and a sufficiently "dumb" client (no knowledge of AS location and no knowledge of scopes)?
Eve
*UMA still allows for Alice's policy to constrain clients, of course (because policy doesn't appear on the wire in UMA), and any client involved in an Alice-to-Bob use case that can't handle scope x will never attempt an API call using scope x anyway...