[da_chicken]

> ...If only we could do something like: dry run and surface all the required permissions, then grant them in one fell (granular) sweep.

The problem with that is that it can be difficult to know what you need, and it may be impossible to simulate in any practical sense. Like, sure, I can stand up a pair of test systems and fabricate every scenario I can possibly imagine, but my employer does want me to do other things this month. And what happens when one of the systems involves a third party?

Really, the need is to be able to provision access after the relationship is established. It's weird that you need a completely new secret to change access. Imagine if this were Linux and in order to access a directory you had to provision a new user to do it? How narrow do you really think user security access would be in practical terms then?

[winwang]

> the need is to be able to provision access after the relationship is established

Could you go into more detail? At a base level interpretation, this is how it works already (you need a principal to provision access for...), but you presumably mean something more interesting?

[da_chicken]

With token-based access, you typically assign the role when the token is created. The access level the token has is typically locked at that point. If you're generating an API access token, you might specify the token is read-only. If you later decide that read/write access is needed, you need to generate a new token with the new access level and replace the token id and value in the client system.

It's not difficult, but it's a much bigger pain in the ass than just changing access or changing role on a user.