-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose signing date to Javascript #449
Comments
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 :) |
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 exampledocument.package.signedAt
. However:Response
, and then we might refer to the Response or the relevant fields from any Document initialised from it...Date
HTTP header? The signing time(s) could be different from theDate
, so we might want to expose both anyway.The text was updated successfully, but these errors were encountered: