Eve, Thanks for thinking this through, great work as usual...
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?
For Gluu use cases, the AS and RS are usually in the same security domain.
How often does the client need to get credentials dynamically vs. pre-provisioned?
We push clients to use OIDC dynamic client registration. But sometimes they are using a form which calls the dynamic clent registration API.
How often is the client running autonomously, vs. operated by a human?
50/50. For example, in one of our current projects the mobile app talks to an initial set of API's, which themselves calls shared API's.
What are the actual use cases on the ground so far?
As I mentioned above, the main use case we are trying to solve is mobile app calling API's which call API's.
Are they such that the extensibility profile in the spec provides a starting point from which we could work outward?
Not sure.
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)?
As mentioned before, I like the permission ticket design, and I think its better than the "client-to-AS-first" pattern for a number of reasons. However... I think that in the interest of aligning with existing practices, it would be advantageous for us to undertake this work. - Mike