jwrosewell
commented
2 years ago I'm not sure how including the identifier in the signing process with the preferences addresses the problem outlined. The PAF/OneKey solution uses organisational measures (the Model Terms) to address many such issues associated with fraudulent actors. Indeed that is a key feature of the solution compared to others which attempt to address every possible scenario of abuse via only technical measures ignoring the role of organisational measures widely used by others including Google to prohibit bad behaviour.
In any case the preferences must be signed by the User Interface Provider (see Model Terms). The Random ID (RID) must be provided by the Operator. These are not always the same entity.
The Seed can be modified to contain both the identifiers and the preferences in the same data structure. This can be signed to ensure that once they leave the Operator, UIP environment they can't be tampered with.
For these reasons we would prefer to remove the current relationship between the identifier and preferences entities.
The current design enforces that preferences are signed with the PAF id.
The rationale is to avoid a fraudulent actor taking a valid (signed) preferences object and attempting to reuse it for a user that did not set their preferences, or did set a different preferences value. Or, more problematic, would take the preferences object and use it for all website visitors.
When signing preferences with ids, we ensure the value of the preference was set for a particular user.
This comes with some constraints:
I think the advantages outweigh the drawbacks but the question has been raised in implementation.