Read only API keys

[PatStLouis]

@esune Is there plan/use case to create 'read-only' api keys in traction? Let's say I want to create an API key that can only allow a client to read the content of the wallet but not carry other operations such as issuance?

[esune]

@PatStLouis for now we are thinking only of admin/non-admin privileges (where admin includes operations such as connecting to endorsers, publishing DIDs, etc.). Do you have a use-case/scenario in mind?

[PatStLouis]

My use-case is to have an external software read the content of my wallet (credentials + dids) without enabling it to carry actions such as publishing or managing credentials. A model we are starting to see emerge is the concept of having a traction tenant storing many 'public' credentials of varying entities (like the BCMinesActPermits being issued to Orgbook) and I want to have an external software query the stored credentials without being able to carry other actions on behalf of that traction tenant.

[esune]

Got it. We don't have it in the roadmap currently, I would consider having a dedicated service rather than direct access to the wallet though for those scenarios to also act as a load-balancer for requests (i.e.: you don;t want your tenant spammed by requests).

[loneil]

If the intent of the wallet is just to be a Holder that other people can access then the existing patterns of ledger writes requiring endorsement suffice?

For the ledgers that Traction is currently using, write operations require the Endorser to approve transactions from that author agent. So the Holder wallet being used for this use case just wouldn't be connected to the Endorser and set up to auto-approve anything.
So even if someone has an API key to call the Holder wallet, they wouldn't successfully be able to publish creds or other ledger write operations that require endorsement anyways.

IE, I think this would be covered with existing governance decisions without API key gating (but I agree with Emilano's point that if external callers are able to make API calls on behalf of the tenant than some other software layer preventing spam requests and such would be a good idea)

[PatStLouis]

I agree the current authorization are probably sufficient. It might be an overkill to get granular access rights by api keys. Happy to close this issue if there's no further comments!

[esune]

Closing as we seem to agree the use-case would be better solved in a different way 🙂