When getting tokens from keystone, the response will contain a token body. One of the attributes of the token response is a list of roles that correspond to the scope of the token (e.g. roles for a project, or domain, etc.)
Traditionally, the list of roles only consists of two pieces of information about each role, the `id` and the `name`. During the implementation of domain-specific roles, the token provider API was modified to handle those cases [0]. The result is that when you get a trust scoped token, the list of roles actually includes the `domain_id`, too. This is because the token provider API copies the role reference from the role API directly into the token response [1], instead of only using the `id` and `name` attributes.
The good this is that this is only done when the role's domain_id == None, which means we're not leaking any sensitive information about domain-specific roles. The bad thing is that it doesn't really present any useful information and if 'domain_id' is in the role reference it's always None. This results in trust-scoped tokens having different responses than other token formats. It also opens up the ability for more data leakage in the event we ever expand the role entity to include another attribute.
This was uncovered in a patch to make parts of our JSONschema testing more DRY [2].
[0] https://review.openstack.org/#/c/263064/19
[1] https://github.com/openstack/keystone/blob/694ef627dd5a544b8200703fa4a42220d6f4784c/keystone/token/providers/common.py#L393-L394
[2] https://review.openstack.org/#/c/407587/1
Note that a fix for this is going to be backwards incompatible, even though the patch the introduced the issue technically was backwards incompatible.
We should consult the TC about fixing this or wait until we have microversion support.