Hello team,
I use PdfTimestamper to add RFC 3161 timestamps when creating PAdES signatures, and I would like to ask whether you would consider adding support for Bearer / API token authentication for TSA servers.
I am aware of the authentication options currently provided by PdfTimestamper: Username and Password for HTTP Authorization, and ClientId for client certificate / digital ID authentication at the TLS level.
These options cover TSA providers that use username/password authentication or TLS client authentication.
However, some commercial TSA providers also support and recommend using an API token through Bearer authentication, for example:
Authorization: Bearer <API_TOKEN>
As far as I can see from the current public API of PdfTimestamper, there is currently no way to directly specify such an Authorization header.
Would it be possible to add support for Bearer authentication, for example through a property such as:
timestamper.BearerToken = apiToken;
Another option, which I think might be more universal, would be to expose a property that allows the value of the HTTP Authorization header to be specified directly, for example:
timestamper.Authorization = "Bearer " + apiToken;
This would allow PdfTimestamper to support Bearer as well as other HTTP authentication schemes without requiring a separate property for each one.
As an even more general alternative, would it be possible to provide public access to the HTTP headers of the TSA request, for example through a collection, callback/event, or another mechanism that would allow custom HTTP headers to be added or modified before the RFC 3161 request is sent?
My main goal is to be able to add:
Authorization: Bearer <API_TOKEN>
without having to override GetTimestampToken(Stream) and reimplement the RFC 3161 request/response logic that PdfTimestamper already provides.
I also have an existing class derived from PdfTimestamper in which I override EstimatedTimestampTokenLength and reserve a sufficiently large fixed size for the timestamp token.
I originally implemented this some time ago because the standard PdfTimestamper implementation made an additional TSA request to determine or estimate the required timestamp token size before making the actual request for the timestamp token.
With paid TSA services, this is not particularly economical because timestamp requests may be charged individually. In practice, an additional request is consumed solely for estimating the token size. For this reason, I chose to reserve a sufficiently large amount of space in advance by overriding EstimatedTimestampTokenLength, so that only the actually required TSA request is made.
My implementation of this workaround is quite old, and until now I had not checked whether this behavior was still present in the latest GemBox.Pdf versions. I have now seen your recent explanation that the additional request is still used for estimating the timestamp token length and that overriding EstimatedTimestampTokenLength with a suitable fixed value is the recommended way to avoid that additional TSA request.
So, in summary, my questions are:
-
Would it be possible to add direct Bearer / API token authentication support to PdfTimestamper, in addition to the existing HTTP username/password and TLS client authentication options?
-
Alternatively, could a public property be added that allows the HTTP Authorization header value to be specified directly?
-
As a more general solution, could public access to the TSA request HTTP headers be provided, allowing custom headers to be added or modified before the request is sent?
Thank you in advance.