Changing binding property of a service token results in conflicting tokens with the same name

[wmiaw]

SimpleMslStore does not remove service tokens of the same name if its binding changes. For example if a token is currently user-bound, and then the server sends back a new token of the same name that is device-bound, the old token of that name is not removed from the user-bound service token map when the new token is added. Since there should only be one token of any given name, if the binding changes the old token must be removed from the token map that is no longer applicable.

See SimpleMslStore.java#L229.

(Make sure to check the service token and receiving message logic in the Wiki documentation.)

[wmiaw]

This is as-designed, because multiple service tokens of the same name need to be supported when their binding properties are different. For example, different users should have different service tokens of the same name, and the more specific version of a token (e.g. device-bound over unbound, and user-bound over device-bound) should be used when it exists.

However the documentation is not explicit, and the code inconsistent.

• At no point in the documentation does it state there cannot be multiple tokens of the same name included in a single message header:
  • Messages#Service Tokens
  • Regular Messages#Service Tokens
• Messages#Service Tokens indicates that service tokens must be added to a message in a specific order, and also indicates that deleting a service token should be done by the service token name. However the latter does not explicitly take into account the binding property of the empty token being used to delete a token. The binding property should be taken into account, to prevent deleting tokens from all users when only one user is involved in a MSL transaction.
• Regular Messages#Token Management does not specify the logic for updating and deleting service tokens upon receipt.

Most of the service token management code is based on a Set container with equality defined by the tuple (name, master token serial number, user ID token serial number):

• SimpleMslStore.java#L229
• SimpleMslStore.java#L293

However the service token removal logic for an unbound service token removes all service tokens of that name, and likewise for the master-bound or user-bound tokens:

• SimpleMslStore.java#L337

Finally, the logic for adding/replacing service tokens when creating a message does so by name, preventing the inclusion of multiple tokens of the same name with an unknown priority order:

• MessageBuilder.java#L175
• MessageBuilder.java#L447