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

proposal to improve registration #10

Merged
merged 1 commit into from Mar 27, 2017

Conversation

Projects
None yet
2 participants
@eshellman
Contributor

eshellman commented Mar 27, 2017

This proposal addresses issues #5 and #6

@@ -368,7 +368,9 @@ When a client opens a License Document for the first time and gets access to its
* It <b>MUST</b> attempt to register itself again if it couldn't do so the first time that the License Document was opened
During the registration, the client <b>MUST</b> always send the same unique identifier for a specific device, no matter which Status Document it interacts with. Any further interaction <b>SHOULD</b> use the same identifier/name.
During the registration, the client <b>MUST</b> always try to send the same unique identifier for a specific device, no matter which Status Document it interacts with. Any further interaction with a provider <b>SHOULD</b> use the same identifier/name. The client <b>SHOULD</b> consider user privacy when generating a unique identifier, for example by generating a random string during software installation. To prevent user tracking across providers, the client <b>MAY</b> generate device unique ids for each provider.

This comment has been minimized.

@eshellman

eshellman Mar 27, 2017

Contributor

Since it's not always possible to ALWAYS send the same identifier for a device, this makes clear that the implementation should do what it can. It also makes clear that an implementation is not out of spec if it uses a different device ID for each provider. If LCP ecosystems are successful and have many participating providers, this is a measure that would prevent providers from sharing registration data for purposes of user tracking.

@eshellman

eshellman Mar 27, 2017

Contributor

Since it's not always possible to ALWAYS send the same identifier for a device, this makes clear that the implementation should do what it can. It also makes clear that an implementation is not out of spec if it uses a different device ID for each provider. If LCP ecosystems are successful and have many participating providers, this is a measure that would prevent providers from sharing registration data for purposes of user tracking.

@HadrienGardeur

This comment has been minimized.

Show comment
Hide comment
@HadrienGardeur

HadrienGardeur Mar 27, 2017

Contributor

Sounds reasonable to me.

Contributor

HadrienGardeur commented Mar 27, 2017

Sounds reasonable to me.

During the registration, the client <b>MUST</b> always send the same unique identifier for a specific device, no matter which Status Document it interacts with. Any further interaction <b>SHOULD</b> use the same identifier/name.
During the registration, the client <b>MUST</b> always try to send the same unique identifier for a specific device, no matter which Status Document it interacts with. Any further interaction with a provider <b>SHOULD</b> use the same identifier/name. The client <b>SHOULD</b> consider user privacy when generating a unique identifier, for example by generating a random string during software installation. To prevent user tracking across providers, the client <b>MAY</b> generate device unique ids for each provider.
If a provider uses registration to monitor license abuse, the provider <b>SHOULD</b> take care to prevent forged registrations.

This comment has been minimized.

@eshellman

eshellman Mar 27, 2017

Contributor

It's up to the provider implementation of course.

@eshellman

eshellman Mar 27, 2017

Contributor

It's up to the provider implementation of course.

@HadrienGardeur HadrienGardeur merged commit 5950edf into readium:master Mar 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment