Update authority

[BigBlueHat]

If you send me a .epub file (or any other downloadable file), I have it. You can't update it without sending me another .epub--which I can choose to replace the old one, or I can use as a separate one, or I can ignore entirely.

This (somewhat) relates to this quote from #23:

o  Downgrade prevention: An early version of a publication might
   contain incorrect content, and a publisher should be able to
   update that without worrying that an attacker can still show the
   old content to users.

An attacker, in this scenario, is considered someone besides the publisher, but in the eyes of the reader (who has potentially paid for a publication) the publisher and the "attacker" may be the same--i.e. Amazon removing copies of 1984 (etc).

Given that a single publication is currently identified by it's publication "address" (a URL) and (if we use WebPackage) will be signed by a single origin's certificate (i.e. rented authority mapped into that URL), what other facilities must we provide (on behalf of the reader) to prevent "overwriting" by either an attacker or even a publisher (however well intentioned).

How do we enable the reader to keep a publication--defined as part of the Web--if/when the underlying technology (domain, URL, certificate, etc) change under their feat?

See also #25.

[iherman]

I wonder whether this is not a question for the Publ WG (too). What is the long term model that this industry wants?

Cc @TzviyaSiegman @GarthConboy

[llemeurfr]

Proposal: close this issue, as LPF will essentially be used as epub today and epub has no update mechanism: the recipient of a package chooses to replace a file by another or not.

note: If #31 's decision is not to implement a signature mechanism, the reader will not know that the provider of an updated LPF file has changed.