Intent to Implement: Changes to consent should trigger call to userId modules

[smenzer]

Type of issue

Intent to Implement

Description

The userId module provides consent data to each idSystem when requesting a new/refreshed ID (via the getId() method). On subsequent page views, if the ID system does not need a refresh, the userId module will optionally make calls to the idSystem with extendId() method (if it exists), followed by a call to decode() to pull out the ID value for use, but neither of these methods contain any consent data, nor are they intended to be used to call the idSystem again for a new/refreshed ID.

In some cases, the consent data may change from one page view to another (either there was no consent on the first request due to a CMP timeout; or a user changed their consent preferences via the CMP after the first page view). In this case today, the idSystem would not be aware that consent has changed and could be providing an invalid ID (since the stored object would be based on old consent data).

Proposal

The userId module should be aware of changes in consent from one request to the next. If consent changes, then userId modules should all be called with a new getId() call instead of just extendId() and decode().

Presumably, this could be done by storing the consent string in local storage and checking the value on each request to see if it changed, and if so, force a refresh.

I'm open to other suggestions on the proposal or implementation if anyone has any ideas.

[smenzer]

@olafbuitelaar fyi

[pycnvr]

This approach ends up generating a new pubcommonid every time the consent string changes. That's problematic. Since only id5 applies additional consent checks in its getId call and has also implemented extendId, it's probably better to pass along consent data in extendId call so that id5, and other subsystems in the future, can applies specialized consent checks when needed.

[smenzer]

@pycnvr if consent changes, though, isn’t it important to update the pubcommonid in case there should no longer be one? we're also not talking about a common occurrence, this is to be covered in case of changes, which is important. additionally, i think it should be the responsibility of the userid module to enforce things like changing of consent requiring a refreshed ID. the ID providers could choose not to change anything, but some will need to if they no longer have consent.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.