Comment 3 for bug 1751279

I think this is certainly something worth thinking about. The difficulties of "not allowing clients to say who they want to access as", but needing the ability to re-use a pre-existing identity is difficult.
Even if we didn't have anonymization, cross-model relations would mean that each new deploy should show up as a different identity. I suppose you could try to set up a chain-of-trust that "I am application foo in model UUID X-Y-Z", and find a way to trust that nobody else could pretend to be a model UUID X-Y-Z with name foo.

You sort of have implicit trust in the single-model case, as whoever deployed 'postgresql' has the same access permissions as whoever deployed its client.

However, CMR explicitly means you have different access control lists (even on the same controller).

It still feels to me that the only way you can really do it is to default each application as getting a unique identifier, generated by the authorizing charm, which can then be saved by the operator, and supplied as config in a future deployment.

We could certainly make it more straigtforward to manage this information (having to run 'juju run relation-get' is not a pleasant way to get information.)