Can someone explain me why there is no distinction between read and write permissions for access keys? Eg, If providing an access key to a dashboard, you would not want that application to be able to change node parameters, eg . transmit interval, time, reset etc.
A mockup example below for clarifying (this is not the current situation)
Tiny remark : I think the interface should state “permissions” instead of “name” (yellow highlight)
Thank you,
I’ve run into this a couple of times now. I would also like the possibility to create an access key that allows read access to messages from devices, without giving write access (which would allow to send downlinks). Haven’t found a solution yet…
Using ‘ttnctl’, I can see that an access key has distinct rights to “messages:up:r” and “messages:down:w”, but I’m still looking for a way to remove that “messages:down:w” permission.
Replying to self: this is probably unsupported, but: using the TTN Console with “developer tools” active, when adding an access key for “messages” only, it’s easy to see that this explicitly sets messages:up:r and messages:down:w in the payload. By removing the newly created access key and then editing the PU request that created it, I was able to create a key with only messages:up:r permissions.
Assuming that this will work, haven’t actually tested this new key yet 
The reason why this is important to me: I’m using the HTTP integration for several applications. HTTP integrations require that an access key is selected, and the data posted to an integration actually contains the access key. Since I generally don’t want the HTTP endpoints to send data back to nodes, I prefer to restrict the level of access that the application (or data recipient) has. As as always with security: implement it as close to the endpoint as possible.
Sounds like a valid use case. Perhaps log a feature request at the GitHub page for the project?
Repository for the version of TTN code base running.