Client Authorization keys should have an explicit scope rather than being global as is the case with the current (Q3 2022) tor daemon implementation

So in Gosling onion authorization is used for endpoint servers (the details don't really matter here). What is kind of frustrating is that onion authorization keys added via ONION_CLIENT_AUTH_ADD are global to the tor daemon, so in theory anybody using the tor daemon can also connect to an onion service with onion auth keys added may connect to the associated onion services.

This kind of sucks if you are using a 'system' or otherwise shared tor daemon (like on Tails or when folks use the bundled Tor Browser tor) since it takes a thing which should be private to the user w/e app has integrated Gosling and shares these credentials with all users of that tor instance.

Ideally some future arti API for connecting to an onion service should take an optional onion auth key (along with the uri, port, and circuit isolation token).

Our current APIs more less just wrap the control port command: https://github.com/blueprint-freespeech/gosling/blob/78753b9099385e5ddfa81e6602f39313c080e60a/source/gosling/src/tor_controller.rs#L1244