A status document should convey that a user passphrase has changed

[llemeurfr]

The architecture of the 3 servers is so that if a user modifies his passphrase, the frontend server keeps the new passphrase is its DB and uses it the next time a license is generated.
But the LSD server is not notified of that action (which is not tied to a license), therefore status documents related to this user cannot reflect an update of the license in the license datetime property.

Consequence: if a user imports an ebook in an app, reads it once, then modifies his passphrase on the library frontend, the old passphrase will still be used for opening the ebook, until an event like renew/return triggers a notification to the LSD server, which will change the license update datetime. Then the new passphrase will be needed to open the ebook, because the app will fetch a new version of the license.

I don't see an easy solution to that issue.

[danielweck]

Right, once a user changes his/her passphrase in the "backend", what is the expected UX?

1. (unlikely scenario) the user is fully aware that previously-delivered publications still use the old passphrase, but this only becomes problematic if/when the reading app does not have a cached (saved) passphrase for these publications, for example when uninstalling+reinstalling the app (reset settings), or switching to another reading app ... at which point the user is prompted to provide an old passphrase that he/she might not remember anymore.
2. the server-side system transparently/automatically updates all previously-generated publication licenses for this user, and publishes corresponding update notifications via LSD. When the user requests reading a publication affected by this change, the client-side reader app follows the LSD protocol and downloads + injects the new license (which matches the new passphrase).

So, (2) is realistically implementable as a core feature of the ecosystem, but do we need a new vocabulary item for the LSD "interaction"? (i.e. spec. change?)

[llemeurfr]

And the user may face a discrepency: if he has fetched twice a license, once before he changed his passphrase and once after, as the date of update of the license is identical in both cases, there will be not automatic update of the license via the license status check, until something modifies the end date of the license. Therefore he may have to use different passphrases depending the license he is using.

[danielweck]

Why would the license "update" date be the same in this case? Wouldn't a change of passphrase trigger the re-generation of a license (so that the keycheck field is correct), and therefore an "incremented" timestamp?

[llemeurfr]

This may be implemented in the LCP Server v2.