This message discusses an issue not brought up yet in our meetings; I encourage you to follow the link and read the thread in GitHub before discussing here (or there...).

Perhaps despite headline appearances, this is a rather philosophical issue In the thread. At the end of the thread, I make a proposal:

"We could say more here about how the AS-RS trust model and the ability to recognize resource owner context within that trust model determines the behavior of the operations. (It's not just List that's affected, it's actually all of them.) If OAuth is used for protection, then the AS-RS trust is formed in an in-band manner and the necessary context is passed in the authorization header. If any other method is used for protection, then trust is formed in some manner that is not in-band, and the necessary context has to be established in some other way. UMA happens to use the former."

The PAT really is the special contextual sauce that makes a whole bunch of things in UMA work... Thoughts on adding this?

Separately, in looking at what other UMA-specific elements might be holding RReg back from generic application to OAuth (and OIDC, for OP/AP linkages), the only thing I'm coming up with is the mention of "policy setting" (active) as possible uses of info in the description documents. But even then, "resource protection monitoring" (passive) is another listed usage. And it would be cool if other grants of OAuth started to use RReg to centralize management of where your access token is, so that you can go and revoke it -- a kind of policy setting, if crude.

Am I missing anything else?