HadrienGardeur
commented
2 days ago @llemeurfr this is something that we had in mind while working on the initial draft for the spec.
The idea being that the server that emits license doesn't have to be the same than the one that's serving the Status Document as long as they can interact with one another.
A typical use-case for that would be ODL. Let's say that I can borrow an ebook that's available:
- protected by LCP
- protected by ACS
- and online through Web Reader
In ODL, a loan returns a License Status Document (LSD). In this specific case, this LSD would include links to:
- an LCPL license
- an ACSM license
- and to the Web Reader itself
If the LCP server cannot point to that LSD and must serve its own instead, we'll end up with two separate documents:
- the one returned in ODL
- and the one referenced in the LCPL file
As you can imagine, that's not ideal.
I can give other use cases for that, there are plenty of good reasons to keep them separate when an implementer knows what it's doing.
If possible, it would be useful to allow an LCP implementer to define a custom endpoint for checking the status of a license, where additional logic could be implemented before serving the status document.
Similar functionality was previously implemented for renew_custom_url using a uri template: https://github.com/readium/readium-lcp-server/blob/f56eaae46535cf3729e0d60a2f474e98dcf6effe/config/config.go#L103
So in an example where we want our custom endpoint to be at 0.0.0.0:5050?action=lcp_status, we could provide a custom templated link like...
... and LCP would use this link in the lcpl file and elsewhere.
In our particular use case, we would like to implement logic that would attempt to automatically renew the loan when status is checked, allowing us to issue short-term loans that auto-renew as long as they're being actively used (and as long as a renew is currently available).