There are little functional requirements for signature providers. Most obviously, we expect that it will provide some useful way to sign logs, what means it should be able to provide an integrity proof of either a complete log file or even some log records some time after the logs are recorded.
There is no "official signature provider spec" available. As usual in open source, the provider interface is well defined inside its actual source header file. Take a look for example at rsyslog's git to see the definition.
If you look at that code, the interface is fairly simple. The primary entry points a programmer needs to define are
The initial provider that ships directly with rsyslog is using a secure remote signing service provided by Guardtime. There are various reasons why I selected this provider, and I elaborated at length on them in my blog posting on why I selected Guardtime as first rsyslog signature provider. In a nutshell, it is a method that does not rely on local secrets and as such can not be circumvented (again: details in my other posting). Obviously, Guardtime offers paid services, but they also operate free services for everyone to use (a key point when I evaluated that technology).
If you have privacy concerns about the Guardtime provider, you may want to read my blog posting on just that question.
Note that signature provider implementations can use the above entry points in any way they like. For example, the may ignore file open and close and do all work in record write. So this small interface is highly flexible. If you look at the full interface description, you'll also see some more events which primarily provide housekeeping functionality. If you intend to write your own signature provider, I suggest to start with a copy of the guardtime provider and change it according to your needs. That way, you have a great example of how the housekeeping calls are handled.