So, in general, your thought process is correct.
- Create the digital content Document and save it.
- To prove that Author last saved Document they would sign the file with their asymetric key
- To prove when Document was saved you would cryptographicly time-stamp it with the help of a trusted Time Stamp Authority.
At any point in the future anybody can validate that the file is the same as it was at a point in time (unchanged since step 3) by validating the timestamp hash with the help of the TSA.
At any point in the future anybody can validate that the file is unmodified from when the Author saved it (unchanged since step 2) by validating Document's signature using Author's public key.
At the core, this seems to be what you are thinking about and yes this is how it does work. And yes, an implementation along these lines does comply with every standard that I am aware of (I work in the USA, but not with the FDA) for proving authenticity of documents across a time domain; including digital contracts (it provides proof of identity and proof of time signed). Though if you are attempting to use this for any purpose where compliance is mandatory then you should take the entire matter up with legal council. Let me be clear: I am not a lawyer and nothing I say should be construed as legal advise or a recommendation on a legally acceptable course of action for you and/or your company. If that is what is required, make sure that you and/or your company bring in your/their own lawyers to ensure you are compliant.
OK, now that the CYA is out of the way we need to look at implementation. You have a data payload for which you wish to guarantee authenticity. This isn't uncommon and is something we all deal with regularly ("verify the file hash before installing", "verify the message signature with my public key", etc). It is a known solved problem in our world. For verification of integrity of the payload, a hash of the payload is computed for comparison. For verification of authorship of a payload, the hash is computed and then cryptographicaly encrypted (using the Author's private key) -- a method we refer to as "signing the document". While you verify the integrity by making sure the hashes match, you check the authorship by decrypting the "signature block" using the supposed Author's public key -- this gives you the file integrity hash that you then verify as before.
Again, this is a solved problem with various schemes in existence to perform it. One of the most common is Pretty Good Privacy (PGP). The PGP standards include a full definition of how to create good cryptographic keys (a required pre-req for signing) and how to properly sign a message. At this point you get into the discussion of Opaque Signatures (where the signature and payload are combined into a single output) and detached signatures.
With an Opaque Signature you will only have one file in the output. It is a combination of the data payload from the original file, and the signature block. While this works well when you are also encrypting the payload (so you'd have to perform a separation and decryption to use the data anyway) its usefulness in scenarios where there is a desire to directly consume the data by an external program varies depending on if that program will be OK with the signature block. For textual messages an Opaque Sig normally isn't an issue. For binary files it will all depend on the software you want to use the file with.
Contrast that with a Separate Signature, where a secondary "signature file" is created to live side-by-side with the original (payload.data and payload.data.signature). This method increases your file count since there are new files for each signature, but the original file will still be able to be opened/viewed in it's intended software without any extra modifications or allowances. This makes the separate signature the more common method for binary files that remain in use. Separate Sigs also have an advantage when using a Time Stamping Authority; you only have to time-stamp the .signature file, reducing the size of the file being transmitted to/from the TSA.
And that then brings us around to the TSA's role in all of this. The thing about a Time Stamp Authority is that they should be near-universally trusted, external and unaffiliated to the parties they provide timestamps for, and impartial in their review of any action. The TSA's role requires them to be neutral across the domain where they are required to provide actionable data. That means if you only need a TSA to provide internal audit timestamps but those aren't required externally, then you can run your own internal authority. But if you need to be able to prove to an outside party that something is accurate as of a given date/time, then the TSA used should be external to both of you (to prove neither of you are tampering with the results). What the TSA actually does is take a file/data, add a timestamp (and, often, information about who requested the time stamp), and then sign the whole thing. So in the end, you may have payload.data, payload.data.signature, and payload.data.signature.timestamped (in some cases .signature is superseded by .signature.timestamped as the final file can provide both functions; other places may need to keep both.)
But this brings up the issue on offline time-stamping. And the answer there is, no. Using a TSA is, by its very nature, asking an external auditor to verify the time something happened. Using an offline TSA (I'm reading it here as: "I self-timestamp the documents without using an external party") breaks the entire reason for performing timestamping at all -- having an unbiased external party verify the time. Otherwise you might as well use the "last modified on date" from the filesystem; you can change your system clock and fake the modified date as easily as you could change the clock and fudge your own internal timestamp. (again, consult your lawyers, but if you're trying to comply to FDA standards then I'm going to assume you're trying to make proofs to an external regulator of some sort) So, no, an offline (or an internal, or an affiliated-to-you) TSA would not fulfill its purpose when trying to make proofs to external entities.
And, finally, a thought about something that came up in the comments (and I briefly touched above). There was some consideration about the fact that this balloons the number of files associated with a project. And, while the .sig and .time files may be small in size, it certainly does. One thing to look at if this is a consideration is what kind of files are being verified, how often in their lifecycle a time stamp is needed, and if they are individual & separable or a group of files in a single project. Most often such signatures and timestamps are applied to final output (or major checkpoint, but not to works in progress); so you don't need tons of these files for points-in-time, just the very few to handle when you need an authority signature. And, often one will look for this kind of authenticity verification for a project and not individual files. If that is the case, it may be prudent to bundle the files together in a single container (zip, tar, etc) and then perform the signing and timestamping on that container. Then you'd have two files: a single archive file for each completed project, and a .signature.timestamp to verify it.
