search

WICG / webpackage

Web packaging format
Other
1.23k stars 116 forks source link

Expose signing date to Javascript #449

Open jyasskin opened 5 years ago

jyasskin commented 5 years ago

While a publisher could manually incorporate the signing time into the content of their signed package, it would be easier for libraries to use that time, for example to check that content isn't "too old", if there were a standard place to look for it.

For signed exchanges, we could put it into the Document, for example document.package.signedAt. However:

  1. A signed exchange can have multiple signatures with different signing times. The most important one is the one that establishes cross-origin trust, but libraries might want to be able to see other signatures.
  2. We also want to be able to see the signing time for members of bundles, which might work better as a field in the Response, and then we might refer to the Response or the relevant fields from any Document initialised from it...
  3. This might be a concept we should expose for other cached things, in which case the place we expose it should make sense for non-packaged things. At that point, would we just expose the Date HTTP header? The signing time(s) could be different from the Date, so we might want to expose both anyway.
sleevi commented 5 years ago

I'd like to avoid exposing this, for now.

As you note, there isn't a notion of a single signing date, but there may be multiple. It's also important the the signing dates may change over time as content is resigned, but the 'logical' date of the content, if you will, may not have changed. That is, if I append a signature, is it refreshing the lifetime of the data?

Other signing solutions make sure to treat these elements as distinct; even counter-signature schemes like timestamping schemes treat signing and timestamping independently.

From an Extensible Web Manifesto perspective, it seems like SXG and Bundles provide all the necessary building blocks to explore a variety of solutions. Further, as you note, the 'Date' header may be sufficient in the future, or may be generally applicable even to content from the disk cache.

By avoiding prematurely standardizing it, we ensure that there are not implicit or explicit dependencies, by 'things-that-are-packaged', on 'how-they-are-packaged'. For example, I want to avoid a situation where moving from one signature to many signatures complicates the API, or if a trusted timestamping service would be introduced, where there are multiple notions of 'signing date'. The less we expose, the better, and authors have the flexibility to explore the paths with their cows for the platform to later standardize :)