Hi Dimitri,

To explain my point on the call -

If a timestamp needs to be handed to a TSA of a particular type to be verified, then the timestamp might as well be opaque to any client - a client requests it be created, and then some other client requests it be verified, but the client doesn't care about the contents.

I think the value of spec'ing the internals of a linked timestamp format is only if we want independently implemented TSAs and timestamp "verifiers" (which may or may not be TSAs themselves) to interoperate, i.e. if we want a timestamp produced by a TSA to be verifiable by independently implemented verifying services.

But achieving that seems complicated. The TSA producing a timestamp has lots of options, in terms of different aggregating, accumulating, linking, and publishing schemes. Either we'd need to only support a specific approach to each of these, or design a data format and verifying algorithm (and perhaps other supporting protocols/data formats, for publishing derived values and retrieving them) so general it would work no matter how the timestamp issuer does things.

Probably either way is doable, but given that we can do a simple, signed timestamp that's "good enough" for most people, and given that linking schemes are IPR-encumbered, I think we should design a format and protocol general/extensible enough to support linking schemes in the future, but not tackle them right away.

But we should figure out what requirements we need to put in, to support extensibility to linking schemes. For example, you mentioned that timestamp production might be a 2-phase process, where you get part of the signature right away, and then come back after a round ends to get the rest. What other specific requirements would we need to add to support linked schemes?

Trevor