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

_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma