Of the two built-in providers, the only one that allows setting a key is Configuration. It makes sense for a key that was set previously to be displayed when the key is edited.
For security reasons, however, other providers that allow setting the key may want to indicate that the key has been set, but not actually display it. It can be up to the provider to decide how to do that. In the example I'm thinking of, it would be handled differently depending on what type of key it is: For API keys, asterisks would be displayed, except for the last four characters. For encryption keys, only asterisks would be shown.
The Drupal 7 version of Key deals with this issue by defining an "obscure key" callback function that can be defined and employed by the provider. The provider then needs to address the situation when a user submits an obscured key, recognizing that it hasn't actually been changed, so it doesn't get overwritten with asterisks (or whatever is being used as a placeholder for the actual key).
Of the two built-in providers, the only one that allows setting a key is Configuration. It makes sense for a key that was set previously to be displayed when the key is edited.
For security reasons, however, other providers that allow setting the key may want to indicate that the key has been set, but not actually display it. It can be up to the provider to decide how to do that. In the example I'm thinking of, it would be handled differently depending on what type of key it is: For API keys, asterisks would be displayed, except for the last four characters. For encryption keys, only asterisks would be shown.
The Drupal 7 version of Key deals with this issue by defining an "obscure key" callback function that can be defined and employed by the provider. The provider then needs to address the situation when a user submits an obscured key, recognizing that it hasn't actually been changed, so it doesn't get overwritten with asterisks (or whatever is being used as a placeholder for the actual key).