This behavior is documented according to our user API reference [0] in the `default_project_id` section. I do agree with Dolph's assessment on the inconsistencies though.
"The ID of the default project for the user. Setting this attribute does not grant any actual authorization on the project, and is merely provided for convenience. Therefore, the referenced project does not need to exist within the user domain. (Since v3.1) If the user does not have authorization to their default project, the default project is ignored at token creation. (Since v3.1) Additionally, if your default project is not valid, a token is issued without an explicit scope of authorization."
This behavior is documented according to our user API reference [0] in the `default_ project_ id` section. I do agree with Dolph's assessment on the inconsistencies though.
"The ID of the default project for the user. Setting this attribute does not grant any actual authorization on the project, and is merely provided for convenience. Therefore, the referenced project does not need to exist within the user domain. (Since v3.1) If the user does not have authorization to their default project, the default project is ignored at token creation. (Since v3.1) Additionally, if your default project is not valid, a token is issued without an explicit scope of authorization."
[0] http:// developer. openstack. org/api- ref/identity/ v3/index. html?expanded= create- user-detail