llemeurfr
commented
6 days ago LCP providers do not store encryption keys; only the LCP Server has this information. To ease the update of an encrypted publication, we, therefore, enhance the LCP encryption tool so that if a content identifier is passed as a parameter, the code interrogates the license server and retrieves the encryption key used to encrypt the previous instance of the publication.
A new private route must be created in the license server so that retrieving content information becomes feasible (this is a standard REST route), the LCP encryption tool calls it only if a content identifier is passed as a parameter. If the content is not found in the license server, a new encryption key is generated as usual.
danielweck
Sometimes, replacing a publication in the LCP Server with a new version is important. This is especially the case if the publication's accessibility has been corrected. By doing so, users who already have a license for this publication can download the new version after deleting the previous instance from their reading application (note that there is no way with LCP to force a new download of the encrypted content; this is why suppressing the old instance and re-importing the license file in the reading app is required).
The LCP encryption tool has a parameter that allows forcing a content identifier for a newly encrypted publication. The general use case for this feature is to establish a simple relationship between the publication's identification in the ebook provider database and its identification in the LCP Server.
It also has a parameter that allows for a specific encryption key, but this parameter has not been documented. Controlling both the content identifier and encryption key is required for replacing a publication with a new version without breaking existing licenses, as described in the following use cases:
Use Case 1: A user gets a license for a publication. The publication is then updated with the same id but a different encryption key. The user opens the license in a new app. Consequence: Because the status document does not indicate a license modification, the license is not reloaded. The content is downloaded. The license cannot open a publication encrypted with a different encryption key.
Use Case 2: A user gets a license for a publication. The publication is then updated with the same id and encryption key. The user opens the license in a new app. Consequence: Because the status document does not indicate a license modification, the license is not reloaded. The content is downloaded. The license opens the publication because it was encrypted with the same encryption key. The hash or length of the content must not be checked; they do not correspond to the new encrypted content.
Use Case 3: A user gets a license for a publication. The publication is then updated with the same id and encryption key. The license date is also updated. The user opens the license in a new app. Consequence: Because the status document indicates a license modification, a fresh license is loaded. The content is then downloaded. The license opens the publication because it was encrypted with the same encryption key. The hash or length of the content can also be checked; they are good.
Use Case 4: A user gets a license for a publication. The publication is then updated with the same id and encryption key. The license date is also updated. The user opens the license in the same app. Consequence: The Status document indicates a change in the license. A fresh license is loaded. It contains a content hash and length that do not correspond to the content currently stored in the application, but this does not stop the reading application to process the local content as usual (because no file is downloaded, the importance of these attributes is null at this point).