CSC provider and user prompt

[PhE]

I try to understand what CSC could bring. I also read #56 and #53.
To be frank I did not look into your code yet. So my questions may be irrelevant.

Is CSC really going to provide usable API to the major signature providers ? Having Adobe and Docusign on board make me fear an "extend and extinguish" maneuver.

Is it possible to create CSC middleware based on pyHanko ?

How CSC handle user interaction, if it does ? What about authentification/2FA feedback ? For example SMS code sent to the user mobile phone.

Here is the context of those questions:
I have a working piece of code to interact with some signature providers
in combined workflow (same document with different signature providers mixed).
It seem better to me to maintain this code as published CSC middlewares.

By the way, thanks a lot for your work on pyHanko !

[MatthiasValvekens]

I was not involved with the design of the CSC spec, so my perspective on this is quite limited, but I can give you some input.

Is CSC really going to provide usable API to the major signature providers ? Having Adobe and Docusign on board make me fear an "extend and extinguish" maneuver.

I don't think full interoperability will ever be on the table (for reasons that I'll explain below). But the idea of standardising the core API operations for signing documents is in itself not a bad thing: users win because they can switch providers more easily, and signing providers win because they can more easily onboard integration partners to sell their stuff.

That said, while the idea is commendable, the CSC kind of dropped the ball on a couple things (in my opinion, that is):

• Attempting to include authentication/authorisation in the spec was a terrible idea from the start. You can tell from the way the spec is written that it was designed as a "we should make something that fits all the auth methods we already use", irrespective of whether that would even be relevant to an integrator calling the API, and without much concern for extensibility. Also, all vendors end up handling this aspect differently in the end, so you're better off disregarding that part of the specification completely (this is also why pyHanko doesn't even try to supply an auth handler implementation for CSC, there's just no point).
• The spec contains some questionable cryptographic assumptions that impact future-proofing; e.g. it presumes that a signature is created from a hash that is computed prior to signing, but this doesn't work for signature algorithms like EdDSA where the signing algorithm takes the full message as input (=> the "digesting" step already requires access to the private key).
• It's unclear to me how many CSC implementations are out there available for use by "small-time" users. I have the impression that some of the larger platforms use the CSC API only for "cloud-to-cloud" type integrations (if at all), without exposing it to the general public. But in the end that's a commercial choice, not a technical problem. It would explain why the auth parts of the spec are all over the place, though.

How CSC handle user interaction, if it does ? What about authentification/2FA feedback ? For example SMS code sent to the user mobile phone.

The CSC API does not define any of this, at best it sets out a way for the server to announce what authentication method(s) it supports, but doesn't actually prescribe any sort of implementation strategy.

Is it possible to create CSC middleware based on pyHanko ?

If you mean: software to talk to a CSC server and sign PDFs? Yes. But you have to supply the (likely vendor-specific) auth handler yourself.

It seem better to me to maintain this code as published CSC middlewares.

Well, if your providers all implement CSC on their servers: that could indeed be useful :). Feel free to publish them as a dependent library.

[PhE]

Thanks for your thoughts on CSC. I will look deeper in it with your points in mind.

Let's go a bit further on my current use case:
I have 2 signature providers A & B:

• Provider A has an API (not CSC) to automate a PDF signature : I send the PDF and the user email/phone and get back the signed PDF
• Provider B has no API : I automated the web user interaction to send the PDF and authenticate the user

I would like to have a common API to both of them.
I could define my own or use some existing public API specs.

This is where I'm wondering if CSC could help : I could provide a common CSC API for those providers.

I'm also curious if it makes sense for pyHanko to have those providers interfaces.

Have you heard about any other attempt to standardize the signing process ?