)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"0c966c551a24608dbaa1a8686c6369720c59b8f0","unresolved":true,"context_lines":[{"line_number":11,"context_line":"users, and domains."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Key features:"},{"line_number":14,"context_line":"- Projects and users get new dedicated RBAC policies"},{"line_number":15,"context_line":"  (``identity:create_{project,user}_with_explicit_id``) that default"},{"line_number":16,"context_line":"  to admin-only, which is more restrictive than the base create"},{"line_number":17,"context_line":"  policies that allow domain managers"},{"line_number":18,"context_line":"- Domains use existing ``identity:create_domain`` policy"},{"line_number":19,"context_line":"  (already admin-only), so no additional policy is needed"},{"line_number":20,"context_line":"- Global uniqueness checking across all resource types prevents ID"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":10,"id":"30e28b58_8b779dab","line":17,"range":{"start_line":14,"start_character":2,"end_line":17,"end_character":37},"updated":"2026-07-15 17:09:27.000000000","message":"I don\u0027t like this.  Keystone has a established one-to-one relationship between API endpoints and policies which is documented here: https://docs.openstack.org/keystone/latest/getting-started/policy_mapping.html\n\nAdding a separate second policy for something that can easily be done by updating the existing policy seems like a bad approach to me.\n\nI\u0027ve updated the split spec for Projects to reflect this change.","commit_id":"24876482066c893b7198dbb3af4d9a14a83d5a1c"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"a5289d2a08e84f1b2beb625b959644a855077c2d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"902fae70_fd93049b","updated":"2026-04-09 13:54:05.000000000","message":"A very big problem with the spec (while I agree we need to solve the problem itself) is the fernet. During the keystone-rs work I have figured out why we stick with dash-less IDs - the format does not survive the serialization roundtrip (IDs are stored as binary UUID and are deserialized always into the simple format since there is no way to get info about the original form). That leads to the fact, that you can get new auth, but when the token is being used the user does not actually exist (when the id contain dashes). In my eyes this is the major issue making such intrusion not worth with the current python implementation of Keystone.\n\nBut I am absolutely with you that users should be able to specify the ID during resource creation. It is just that the current architecture makes it pretty hard","commit_id":"9936bddc7e67507e8de24e802110a0950f89cd87"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"73db3c5281b76de7b0886a9834eb9de67aed5a84","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0d3c6811_c26e8ccc","in_reply_to":"751ebc4a_a417d21f","updated":"2026-05-18 21:51:04.000000000","message":"As noted at the PTG, the original spec accepted dashed UUIDs on input, but then stripped them of the dashes before storing them in the DB.  This prevents the problem that @artem.goncharov@gmail.com refers to.  However, it was decided also at the PTG to simply only accept non-hashed UUIDs to make sure there is no confusion.\n\nI have uploaded a new spec that specifies this.  Also, I have included the suggestion not to use explicit_x_id (as is present for explicit_domain_id) and just use id instead.","commit_id":"9936bddc7e67507e8de24e802110a0950f89cd87"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"be7f2a03bfb8884cddcdbbb10ae56c746285135d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"751ebc4a_a417d21f","in_reply_to":"902fae70_fd93049b","updated":"2026-05-11 23:40:19.000000000","message":"If we\u0027re using dash-less IDs then we can always ensure we strip them off and the format survives round trips?","commit_id":"9936bddc7e67507e8de24e802110a0950f89cd87"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"29dbc416ea30c89e3858928c7884dbfbd73eb224","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"aed3b9b3_f20b9d6d","updated":"2026-05-20 20:17:32.000000000","message":"@artem.goncharov@gmail.com Can we remove the -2?","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"1680f9b48f97a2e29442d2e7b4440a1da4231c06","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"22f4a72c_67b4f48b","updated":"2026-05-26 15:08:49.000000000","message":"A couple of minor issues, but otherwise it looks good to me","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"00171815e89fa84f9714c076f926855c8fad8cbe","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"72cb9d32_9da7e072","updated":"2026-05-21 05:29:16.000000000","message":"Sure","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"407e9f05_b7c3e81c","updated":"2026-05-27 20:33:00.000000000","message":"I think this should not be done. I see many problems for the public cloud case, where nobody can trust anyone, and where even the domain manager is just one of the customers; policies might also allow a certain role on a project to create sub-projects.\n\nMany things now depend (rightly or wrongly) on project id staying unique. We should not break this promise.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"91e71993_f155169b","updated":"2026-05-27 19:56:00.000000000","message":"Overall, this looks great.  I just have a few questions/comments that need to be addressed before I can +2.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":5890,"name":"Doug Goldstein","email":"cardoe@cardoe.com","username":"cardoe"},"change_message_id":"f6223c73a9ed165902bf0df2a6d502cdc200ee99","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"b55508af_bc02699c","updated":"2026-05-27 00:44:57.000000000","message":"We are interested in this spec as well.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"3f103219c9174444a14c7742e81b10775f0a2fe3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"132ea97d_b7339f06","updated":"2026-05-26 19:23:49.000000000","message":"comments from @dwilde@redhat.com resolved.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"aa87a3e542dd25046038b6c8da7f27bf5d25fee1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":4,"id":"22928181_f28e6e16","in_reply_to":"407e9f05_b7c3e81c","updated":"2026-05-27 20:39:08.000000000","message":"A small correction - many things also depend on project id and user id being completely safe.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"ccfc0f4b_29ac53e4","updated":"2026-06-09 20:07:23.000000000","message":"Interim review, haven\u0027t reached the end yet","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"36c9488a6b305e0add3801c275140428ba68febb","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":10,"id":"c87c493b_3dfa141e","updated":"2026-07-15 16:54:03.000000000","message":"Splitting this into two specs, one for projects and domains, and one for users.\n\nThe spec for Projects and Domains is here: https://review.opendev.org/c/openstack/keystone-specs/+/997320","commit_id":"24876482066c893b7198dbb3af4d9a14a83d5a1c"}],"specs/keystone/2026.2/explicit-resource-ids.rst":[{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"1680f9b48f97a2e29442d2e7b4440a1da4231c06","unresolved":true,"context_lines":[{"line_number":189,"context_line":"lowercase hexadecimal characters).  Callers must strip dashes from AD"},{"line_number":190,"context_line":"``objectGUID`` or Entra ID ``id`` values before passing them to the API."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"**Proposal**: Add ``id`` as an alias for ``explicit_domain_id`` in the"},{"line_number":193,"context_line":"schema and API controller, with ``id`` taking precedence if both are"},{"line_number":194,"context_line":"supplied.  Both fields continue to enforce dashless hex format only.  The"},{"line_number":195,"context_line":"``explicit_domain_id`` field is maintained for backwards compatibility but"},{"line_number":196,"context_line":"is deprecated in favor of ``id``."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Project ``id`` field (new capability)"},{"line_number":199,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"025c5c4b_20c3e180","line":196,"range":{"start_line":192,"start_character":0,"end_line":196,"end_character":33},"updated":"2026-05-26 15:08:49.000000000","message":"We should probably return a 400 if both ``id`` and ``explicit_domain_id`` are specified in the same request.","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"eca17c655e3d657408dc3a5fc1a304fc9109705c","unresolved":true,"context_lines":[{"line_number":189,"context_line":"lowercase hexadecimal characters).  Callers must strip dashes from AD"},{"line_number":190,"context_line":"``objectGUID`` or Entra ID ``id`` values before passing them to the API."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"**Proposal**: Add ``id`` as an alias for ``explicit_domain_id`` in the"},{"line_number":193,"context_line":"schema and API controller, with ``id`` taking precedence if both are"},{"line_number":194,"context_line":"supplied.  Both fields continue to enforce dashless hex format only.  The"},{"line_number":195,"context_line":"``explicit_domain_id`` field is maintained for backwards compatibility but"},{"line_number":196,"context_line":"is deprecated in favor of ``id``."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Project ``id`` field (new capability)"},{"line_number":199,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0fe55869_219d587c","line":196,"range":{"start_line":192,"start_character":0,"end_line":196,"end_character":33},"in_reply_to":"025c5c4b_20c3e180","updated":"2026-05-26 18:42:37.000000000","message":"OK - I can do that.","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"3f103219c9174444a14c7742e81b10775f0a2fe3","unresolved":false,"context_lines":[{"line_number":189,"context_line":"lowercase hexadecimal characters).  Callers must strip dashes from AD"},{"line_number":190,"context_line":"``objectGUID`` or Entra ID ``id`` values before passing them to the API."},{"line_number":191,"context_line":""},{"line_number":192,"context_line":"**Proposal**: Add ``id`` as an alias for ``explicit_domain_id`` in the"},{"line_number":193,"context_line":"schema and API controller, with ``id`` taking precedence if both are"},{"line_number":194,"context_line":"supplied.  Both fields continue to enforce dashless hex format only.  The"},{"line_number":195,"context_line":"``explicit_domain_id`` field is maintained for backwards compatibility but"},{"line_number":196,"context_line":"is deprecated in favor of ``id``."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Project ``id`` field (new capability)"},{"line_number":199,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3fa97006_993960e4","line":196,"range":{"start_line":192,"start_character":0,"end_line":196,"end_character":33},"in_reply_to":"0fe55869_219d587c","updated":"2026-05-26 19:23:49.000000000","message":"Done","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":7414,"name":"David Wilde","email":"dwilde@redhat.com","username":"d34dh0r53"},"change_message_id":"1680f9b48f97a2e29442d2e7b4440a1da4231c06","unresolved":true,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"**Proposal — accept any non-empty string up to 64 characters**:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Accept any non-empty string up to 64 characters.  No format constraint beyond"},{"line_number":293,"context_line":"the database column limit is applied.  The existing ``parameter_types.user_id``"},{"line_number":294,"context_line":"schema (already unconstrained) reflects this reality."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"This means:"},{"line_number":297,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"c9e764f7_40559718","line":294,"range":{"start_line":292,"start_character":0,"end_line":294,"end_character":53},"updated":"2026-05-26 15:08:49.000000000","message":"Some sanitization is required here, we should not allow control characters, non-printing characters, and \"/, ?, #, %\" in the user_id. Probably restricting to URL-safe characters is sufficient.","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":9914,"name":"Ade Lee","email":"alee@redhat.com","username":"alee"},"change_message_id":"eca17c655e3d657408dc3a5fc1a304fc9109705c","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"**Proposal — accept any non-empty string up to 64 characters**:"},{"line_number":291,"context_line":""},{"line_number":292,"context_line":"Accept any non-empty string up to 64 characters.  No format constraint beyond"},{"line_number":293,"context_line":"the database column limit is applied.  The existing ``parameter_types.user_id``"},{"line_number":294,"context_line":"schema (already unconstrained) reflects this reality."},{"line_number":295,"context_line":""},{"line_number":296,"context_line":"This means:"},{"line_number":297,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7393ca9c_5c9b512a","line":294,"range":{"start_line":292,"start_character":0,"end_line":294,"end_character":53},"in_reply_to":"c9e764f7_40559718","updated":"2026-05-26 18:42:37.000000000","message":"Acknowledged","commit_id":"1c25c79fedcc52f18783b8d7ce830e2f42aa58d8"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Additional use cases that benefit from the same feature:"},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"* **Fernet token portability.** A Fernet token encodes the project and user"},{"line_number":55,"context_line":"  UUID. Issuing a token against Region A and validating it against Region B is"},{"line_number":56,"context_line":"  only possible if the same UUID refers to the same entity on both regions."},{"line_number":57,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"97e93a8c_8ce2695f","line":54,"updated":"2026-05-27 20:33:00.000000000","message":"This is a stretch. It requires many other pre-requisites, for example, shared revocation events state and synchronized role assignments.\nGood luck debugging user\u0027s question \"my token works in region A but does not work in region B, why?\"","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":61,"context_line":"  yield consistent shadow-user IDs. The ability to specify user IDs"},{"line_number":62,"context_line":"  requested here is for **local** users that are not backed by LDAP."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"* **Disaster-recovery re-creation.** If a project or user is deleted and must"},{"line_number":65,"context_line":"  be re-created (e.g. as part of a DR runbook), using the original UUID allows"},{"line_number":66,"context_line":"  all previously issued tokens and stored policy references to remain valid."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* **Parity with other OpenStack resources.** Images and Flavors already accept"},{"line_number":69,"context_line":"  a caller-supplied UUID at creation time. Projects and users are conspicuous"}],"source_content_type":"text/x-rst","patch_set":4,"id":"6a8cdf88_bd39a49b","line":66,"range":{"start_line":64,"start_character":2,"end_line":66,"end_character":76},"updated":"2026-05-27 20:33:00.000000000","message":"I don\u0027t think it will work.\nWhen a project is deleted, the role assignments are also deleted.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":69,"context_line":"  a caller-supplied UUID at creation time. Projects and users are conspicuous"},{"line_number":70,"context_line":"  exceptions."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Note: ``keystone-manage`` already provides ``project_setup`` and ``user_setup``"},{"line_number":73,"context_line":"subcommands that can create projects and users with predefined IDs, but this"},{"line_number":74,"context_line":"capability is not exposed through the standard v3 REST API.  The goal of this"},{"line_number":75,"context_line":"spec is to close that gap, and to address validation defects in the existing"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9809c778_8da4d935","line":72,"range":{"start_line":72,"start_character":0,"end_line":72,"end_character":4},"updated":"2026-05-27 19:56:00.000000000","message":"Maybe worth mentioning here that these subcommands do have limitations.  For example, you cannot create a  project that belongs to a specific domain.  Only the `Default` domain is supported by the `project_setup` subcommand.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":86,"context_line":"Proposed Change"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Extend the ``POST /v3/projects`` and ``POST /v3/users`` APIs to accept"},{"line_number":90,"context_line":"an optional ``id`` field in the request body.  When present, its value is used"},{"line_number":91,"context_line":"as the entity UUID instead of a server-generated value.  When absent, behaviour"},{"line_number":92,"context_line":"is unchanged."}],"source_content_type":"text/x-rst","patch_set":4,"id":"4e415162_fc3fde30","line":89,"range":{"start_line":89,"start_character":37,"end_line":89,"end_character":55},"updated":"2026-05-27 20:33:00.000000000","message":"In the proposed design, a caller-supplied user.id is stored verbatim as the primary key of the SQL user table, and the same column name is used as the foreign-key target by role_assignment.actor_id, revocation events, the token model\u0027s user_id claim, and audit event subjects, none of which carry a domain qualifier. Independently, when domain_specific_drivers_enabled is true, Keystone\u0027s federation and LDAP shadowing paths populate the id_mapping table with public_ids derived as sha256(domain_id + \"user\" + local_id), and those public_ids also flow through identity_api.get_user as user IDs.\n\n\nCould the spec clarify the following please:\n\n1. What prevents an authenticated caller permitted by \nidentity:create_user from choosing a user.id whose value coincides with a\n public_id that the federation or LDAP shadowing path will later compute\n for a different principal in a different domain, given that the inputs \nto the SHA-256 (domain_id, the literal \"user\", and the IdP unique_id or \nLDAP local_id) are not confidential?\n2. If such a coincidence occurs, which of the two records, the locally \ncreated user in domain Y or the federated/LDAP entity in domain X, is \nintended to be returned by identity_api.get_user(id), and which is \nintended to be the subject of role_assignment rows that reference that \nid as actor_id?\n\nA short example in the Security Impact section covering the case \nwhere the caller-supplied id collides with a not-yet-materialized \nfederated or LDAP public_id, and the case where it collides with one \nthat materializes later, would help reviewers confirm that the design \nintentionally addresses both directions.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":true,"context_lines":[{"line_number":86,"context_line":"Proposed Change"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Extend the ``POST /v3/projects`` and ``POST /v3/users`` APIs to accept"},{"line_number":90,"context_line":"an optional ``id`` field in the request body.  When present, its value is used"},{"line_number":91,"context_line":"as the entity UUID instead of a server-generated value.  When absent, behaviour"},{"line_number":92,"context_line":"is unchanged."}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f04fd66_21f60b53","line":89,"range":{"start_line":89,"start_character":37,"end_line":89,"end_character":55},"in_reply_to":"4e415162_fc3fde30","updated":"2026-06-09 20:07:23.000000000","message":"The statement is not fully correct - there are NO FK constraints across provider boundaries.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":102,"context_line":"* The field is consumed during creation and does not appear as a separate"},{"line_number":103,"context_line":"  attribute in the response body — the resulting entity\u0027s ``id`` field"},{"line_number":104,"context_line":"  contains the value, as with auto-generated IDs."},{"line_number":105,"context_line":"* For projects and domains: ``id`` accepts a UUID in dashless hex form only"},{"line_number":106,"context_line":"  (``xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx``, 32 lowercase hexadecimal characters)."},{"line_number":107,"context_line":"  This matches the format auto-generated IDs use internally and the format"},{"line_number":108,"context_line":"  returned in all API responses, avoiding confusion about output format."}],"source_content_type":"text/x-rst","patch_set":4,"id":"c8d5f9a8_4b14223d","line":105,"updated":"2026-05-27 20:33:00.000000000","message":"Openstack is a collection of REST API services. Nova, Barbican, Cinder and other, maybe custom services do not know that a project is deleted in Keystone.\n\nThere are 2 approaches to this problem:\n1. Pre-cleanup. Do not allow to delete a project before all its resources are gone. This is difficult.\n2. Post-cleanup. Allow to delete a project and then at some point delete its resources using internal cleanup tools. I know for sure that this approach is widely accepted in certain clouds.\n\n\nIn a cloud with the approach 2, an attacker can try to recreate a project immediately after it is deleted, and steal its resources. They can monitor a list of project ids because it is allowed by policies (and having own policy.yaml is a perfectly fine scenario), or by using a vulnerability.\n\nPlease note: there are many different drivers out there, binding their resources to project id. Sometimes these resources are exposed not via the service where they originally were created in.\n\nHow do you propose to protect against that?","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":106,"context_line":"  (``xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx``, 32 lowercase hexadecimal characters)."},{"line_number":107,"context_line":"  This matches the format auto-generated IDs use internally and the format"},{"line_number":108,"context_line":"  returned in all API responses, avoiding confusion about output format."},{"line_number":109,"context_line":"* For users: ``id`` accepts any non-empty string up to 64 characters,"},{"line_number":110,"context_line":"  with no format constraint beyond the database column limit.  This reflects"},{"line_number":111,"context_line":"  the diversity of stable identifiers in use across different IdP systems"},{"line_number":112,"context_line":"  (UUIDs, short usernames, directory attribute values)."}],"source_content_type":"text/x-rst","patch_set":4,"id":"97467650_1b250cc2","line":109,"range":{"start_line":109,"start_character":2,"end_line":109,"end_character":69},"updated":"2026-05-27 20:33:00.000000000","message":"Nova\u0027s parameter_types.user_id and project_id validators are ^[a-zA-Z0-9-]*$, alnum and dash only. Any keystone user with id john.doe or jane@example.com calling Nova with a microversion path that quotes their user_id in the request body, for example admin-on-behalf operations on /os-keypairs, /os-server-groups, or /os-quota-sets/{tenant_id}/users/{user_id}, receives HTTP 400 from Nova\u0027s request schema.\n\n\nnova/scheduler/client/report.py:2562-2564 builds \u0027/usages?project_id\u003d%s\u0027 % project_id then concatenates \u0027\u0026user_id\u003d%s\u0027 % user_id without urllib.parse.quote. So if there is a \u0026 in the id, request parameters can be smuggled. I don\u0027t exactly understand what it leads to, still not nice.\n\nnova/crypto.py:131-132 builds subject \u003d \u0027/CN\u003d%s\u0027 % user_id and upn \u003d \u0027%s@localhost\u0027 % user_id. Line 143 passes subject as the -subj argument to processutils.execute(\u0027openssl\u0027, ...). Lines 159-167 write upn into an OpenSSL config file (content % upn). Triggered by POST /os-keypairs with type\u003dx509 (microversion ≥ 2.2) via compute/api.py:7066-7070. Keystone\u0027s proposed user_id charset allows \u003d, \",\", +, \u003c, \u003e, quote, space, backslash - all DN delimiters or OpenSSL-config metacharacters. With user_id alice,O\u003devil, the resulting subject is /CN\u003dalice,O\u003devil — a forged Organisation field on the certificate.\n\nI have found 37 other issues in other openstack services that will get broken with this new design.\n\nHorizon and Skyline are especially vulnerable. I am concerned about them, because they probably don\u0027t expect to have \u003cscript\u003ealert(\"hello world\")\u003c/script\u003e in the user id.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":311,"context_line":"* Operators can supply a UUID (with or without dashes), a ``sAMAccountName``,"},{"line_number":312,"context_line":"  a ``uid`` value, or any other stable opaque identifier from their directory,"},{"line_number":313,"context_line":"  as long as it doesn\u0027t contain the prohibited characters."},{"line_number":314,"context_line":"* The stored value is used verbatim as the primary key; no normalisation is"},{"line_number":315,"context_line":"  performed."},{"line_number":316,"context_line":"* ID uniqueness is still enforced by the database (409 Conflict on duplicate)."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"**Trade-off**: A looser format provides no early feedback if a caller"},{"line_number":319,"context_line":"accidentally passes a malformed value.  However, forcing UUID format on"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1fe57978_904303c5","line":316,"range":{"start_line":314,"start_character":0,"end_line":316,"end_character":78},"updated":"2026-05-27 19:56:00.000000000","message":"If no normalization of UUIDs will be done, then how does this affect uniqueness?  Consider a sample UUID like `9e9876dc-c2c0-418c-9d1f-5e179f18537b` and the same UUID without dashes `9e9876dcc2c0418c9d1f5e179f18537b`  Would these be considered unique by the system or will they be considered distinct and both allowed to exist at once?","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":354,"context_line":"  deployer operational complexity without providing finer-grained control than"},{"line_number":355,"context_line":"  RBAC. This spec instead relies on existing policy rules to control access."},{"line_number":356,"context_line":""},{"line_number":357,"context_line":"* **Separate RBAC rules.** Dedicated policy actions"},{"line_number":358,"context_line":"  ``identity:create_project_with_explicit_id`` and"},{"line_number":359,"context_line":"  ``identity:create_user_with_explicit_id`` could be enforced in addition to"},{"line_number":360,"context_line":"  the existing create rules. This allows restricting explicit-ID creation to"}],"source_content_type":"text/x-rst","patch_set":4,"id":"fb50eb0c_b484289b","line":357,"range":{"start_line":357,"start_character":2,"end_line":357,"end_character":26},"updated":"2026-05-27 19:56:00.000000000","message":"I\u0027m not sure I understand how this would work.  It seems to me this is just describing an alias that would be appended to the existing policy?  Given that currently we have a one-to-one mapping of policy to endpoint, we would need to change policy enforcement to somehow consider more than one distinct policy per endpoint?  In my opinion this is not a viable alternative.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":398,"context_line":"tokens scoped to that entity to gain access again.  This is an inherent"},{"line_number":399,"context_line":"consequence of ID reuse and is consistent with behaviour already permitted for"},{"line_number":400,"context_line":"domains via ``explicit_domain_id``.  Operators in environments where this risk"},{"line_number":401,"context_line":"is a concern should tighten the relevant policy rules or adopt the separate"},{"line_number":402,"context_line":"RBAC rule alternative described above."},{"line_number":403,"context_line":""},{"line_number":404,"context_line":"Notifications Impact"},{"line_number":405,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"36842e1f_2abaedb4","line":402,"range":{"start_line":401,"start_character":54,"end_line":402,"end_character":38},"updated":"2026-05-27 19:56:00.000000000","message":"See comments above.  I don\u0027t think it\u0027s possible to adopt separate rules for a single endpoint.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":503,"context_line":"       if domain_id is None:"},{"line_number":504,"context_line":"           domain_id \u003d domain.pop(\u0027explicit_domain_id\u0027, None)"},{"line_number":505,"context_line":"       else:"},{"line_number":506,"context_line":"           # If both were supplied, pop explicit_domain_id silently"},{"line_number":507,"context_line":"           domain.pop(\u0027explicit_domain_id\u0027, None)"},{"line_number":508,"context_line":""},{"line_number":509,"context_line":"       if domain_id is None:"},{"line_number":510,"context_line":"           domain \u003d self._assign_unique_id(domain)"},{"line_number":511,"context_line":"       else:"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ff120800_0e487d02","line":508,"range":{"start_line":506,"start_character":11,"end_line":508,"end_character":1},"updated":"2026-05-27 19:56:00.000000000","message":"This does not match the description in line 193 that states that:\n\n\u003e If both ``id`` and ``explicit_domain_id`` are\nprovided in the same request, the API returns HTTP 400 Bad Request to\nprevent ambiguity about which value to use.\n\nI think that returning 400 as described above is a better approach than silently ignoring `explicit_domain_id`.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":562,"context_line":""},{"line_number":563,"context_line":"5. **keystone/identity/schema.py** — Add ``id`` to the user create request"},{"line_number":564,"context_line":"   schema.  Use a simple string type with length constraints (1-64 chars)"},{"line_number":565,"context_line":"   since user IDs can come from diverse IdP systems and carry no format"},{"line_number":566,"context_line":"   constraint beyond the database column width:"},{"line_number":567,"context_line":""},{"line_number":568,"context_line":"   .. code-block:: python"},{"line_number":569,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7bf69e30_74ca53da","line":566,"range":{"start_line":565,"start_character":51,"end_line":566,"end_character":46},"updated":"2026-05-27 19:56:00.000000000","message":"In line 297 the spec does restrict the values to exclude the following:\n\n\u003e * Control characters (ASCII 0x00–0x1F, 0x7F)\n* Non-printing characters\n* URL-unsafe characters: ``/``, ``?``, ``#``, ``%``\n\nCan we validate these exclusions in the schema?","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":691,"context_line":"    * ``test_create_domain_with_id`` — dashless UUID accepted"},{"line_number":692,"context_line":"    * ``test_create_domain_with_explicit_domain_id`` — backwards"},{"line_number":693,"context_line":"      compatibility test for deprecated field name"},{"line_number":694,"context_line":"    * ``test_create_domain_id_precedence`` — verify ``id`` takes precedence"},{"line_number":695,"context_line":"      when both ``id`` and ``explicit_domain_id`` are supplied"},{"line_number":696,"context_line":"    * ``test_create_domain_with_dashed_id_fails``"},{"line_number":697,"context_line":"    * ``test_create_domain_with_invalid_id`` (expect 400)"},{"line_number":698,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"356abdad_9f5733b6","line":695,"range":{"start_line":694,"start_character":4,"end_line":695,"end_character":62},"updated":"2026-05-27 19:56:00.000000000","message":"Change this test to expect a 400 when both are supplied.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":696,"context_line":"    * ``test_create_domain_with_dashed_id_fails``"},{"line_number":697,"context_line":"    * ``test_create_domain_with_invalid_id`` (expect 400)"},{"line_number":698,"context_line":""},{"line_number":699,"context_line":"12. **keystone/tests/unit/test_v3_identity.py** (users):"},{"line_number":700,"context_line":""},{"line_number":701,"context_line":"    * ``test_create_user_with_id_uuid`` — dashless UUID accepted"},{"line_number":702,"context_line":"    * ``test_create_user_with_id_arbitrary_string`` — e.g. ``jsmith``"},{"line_number":703,"context_line":"    * ``test_create_user_with_id_dashed_uuid`` — dashed UUID accepted and"}],"source_content_type":"text/x-rst","patch_set":4,"id":"ffa0cc8b_7a90b533","line":700,"range":{"start_line":699,"start_character":4,"end_line":700,"end_character":1},"updated":"2026-05-27 19:56:00.000000000","message":"Add a test to demonstrate the expected behavior when the same UUID is provided both with and also without dashes.  Will both be accepted?  Will the first be accepted and the second one rejected?","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":704,"context_line":"      stored as-is (user IDs accept any string ≤64 chars)"},{"line_number":705,"context_line":"    * ``test_create_user_with_invalid_id`` — empty string and \u003e64 chars"},{"line_number":706,"context_line":"      rejected (expect 400)"},{"line_number":707,"context_line":""},{"line_number":708,"context_line":"keystone-manage CLI"},{"line_number":709,"context_line":"~~~~~~~~~~~~~~~~~~~"},{"line_number":710,"context_line":""},{"line_number":711,"context_line":"13. **keystone/cmd/idutils.py** — Fix two defects in the existing"},{"line_number":712,"context_line":"    ``project_setup`` and ``user_setup`` implementations and add format"}],"source_content_type":"text/x-rst","patch_set":4,"id":"1c227228_01e4beb4","line":709,"range":{"start_line":707,"start_character":1,"end_line":709,"end_character":19},"updated":"2026-05-27 19:56:00.000000000","message":"As I mentioned above, the `project_setup` and `user_setup` have additional limitations.  For example, the Domain ID cannot be provided like it can be in the API.  This may be a good opportunity to ensure that all values that can be provided via the API can also be provided to these subcommands.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":867,"context_line":"is:"},{"line_number":868,"context_line":""},{"line_number":869,"context_line":"1. **Document** that the ``--id`` option requires Keystone v3.15 or later."},{"line_number":870,"context_line":"2. **Optionally**, callers can inspect the Keystone endpoint discovery document"},{"line_number":871,"context_line":"   and verify that the reported version is at least ``v3.15`` before sending"},{"line_number":872,"context_line":"   the request."},{"line_number":873,"context_line":"3. Operators must ensure they upgrade Keystone before relying on this feature"},{"line_number":874,"context_line":"   in automated workflows."},{"line_number":875,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"fe696176_fac48e78","line":872,"range":{"start_line":870,"start_character":3,"end_line":872,"end_character":15},"updated":"2026-05-27 19:56:00.000000000","message":"Why not do this programmatically in the client?  The version is available in the keystone root endpoint.  It would be trivial to check that and give an error if \u003cv3.15","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"651c116502bcfa166329f3e2c67387f34f6a5f0d","unresolved":true,"context_lines":[{"line_number":881,"context_line":""},{"line_number":882,"context_line":"* **New clients** should use ``id`` for consistency with projects and users."},{"line_number":883,"context_line":"* **Existing clients** using ``explicit_domain_id`` continue to work unchanged."},{"line_number":884,"context_line":"* If both fields are supplied in a single request, ``id`` takes precedence."},{"line_number":885,"context_line":""},{"line_number":886,"context_line":""},{"line_number":887,"context_line":"Dependencies"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5355bb34_9b4bd030","line":884,"range":{"start_line":884,"start_character":0,"end_line":884,"end_character":75},"updated":"2026-05-27 19:56:00.000000000","message":"Change this to state that an error will occur instead of `id` taking precedence.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"87d9c8bc6df6d7f66883c7699e14b409299c4a03","unresolved":true,"context_lines":[{"line_number":982,"context_line":"options set the ``id`` attribute on the SDK resource object, which the SDK"},{"line_number":983,"context_line":"then forwards to the API.  This work is a follow-on and depends on the SDK"},{"line_number":984,"context_line":"change above."},{"line_number":985,"context_line":""},{"line_number":986,"context_line":""},{"line_number":987,"context_line":"Documentation Impact"},{"line_number":988,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"613db389_abd9a343","line":985,"updated":"2026-05-27 20:33:00.000000000","message":"There is logging impact. pycadf/identifier.py:is_valid accepts non-UUID values but emits a Python warnings.warn(...) for every audit event.","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":13478,"name":"Boris Bobrov","email":"b.bobrov@sap.com","username":"bbobrov"},"change_message_id":"b74bba75a94e623b6e83bc373af509ed920c6a20","unresolved":true,"context_lines":[{"line_number":1000,"context_line":""},{"line_number":1001,"context_line":".. [1] Previous (unmerged) spec: \"Allow admin to specify project id on"},{"line_number":1002,"context_line":"       creation\" —"},{"line_number":1003,"context_line":"       https://review.opendev.org/c/openstack/keystone-specs/+/323499"}],"source_content_type":"text/x-rst","patch_set":4,"id":"0ea63df6_58ed9857","line":1003,"updated":"2026-05-27 21:27:04.000000000","message":"To add more context, this had also been discussed heavily in https://review.opendev.org/c/openstack/keystone/+/403866. My comments and opinions from there still stand.\nThe bug about this functionality was also marked as invalid before - https://bugs.launchpad.net/keystone/+bug/1646563","commit_id":"45c82037e823e52a7b44ab3263b4a3e6df8b0255"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":true,"context_lines":[{"line_number":106,"context_line":"  (``xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx``, 32 lowercase hexadecimal characters)."},{"line_number":107,"context_line":"  This matches the format auto-generated IDs use internally and the format"},{"line_number":108,"context_line":"  returned in all API responses, avoiding confusion about output format."},{"line_number":109,"context_line":"* For users: ``id`` accepts alphanumeric characters and hyphens up to 64"},{"line_number":110,"context_line":"  characters (``^[a-zA-Z0-9-]*$``), matching Nova\u0027s user_id validation to"},{"line_number":111,"context_line":"  ensure compatibility across OpenStack services. Operators can optionally"},{"line_number":112,"context_line":"  configure ``[identity] explicit_user_id_pattern \u003d uuid`` for stricter"}],"source_content_type":"text/x-rst","patch_set":8,"id":"247d8dd7_0ffcb640","line":109,"updated":"2026-06-09 20:07:23.000000000","message":"looking again at the fernet roundtrip also user_id will be always uuid without dashes (if it was uuid). So nova check is less strict than what keystone user_id can be","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":true,"context_lines":[{"line_number":296,"context_line":"capability accepts a narrower range of IDs than Keystone already handles"},{"line_number":297,"context_line":"internally."},{"line_number":298,"context_line":""},{"line_number":299,"context_line":"**Proposal — match Nova\u0027s user_id validation by default**:"},{"line_number":300,"context_line":""},{"line_number":301,"context_line":"The default validation pattern is ``^[a-zA-Z0-9-]*$`` (up to 64 characters),"},{"line_number":302,"context_line":"which matches Nova\u0027s user_id schema validation. This ensures that"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f2f29fae_47128bf9","line":299,"updated":"2026-06-09 20:07:23.000000000","message":"So the question is: can the user_id contain dashes in real life or it is simply a \"naive\" pattern in Nova that mixes cards here?","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":true,"context_lines":[{"line_number":391,"context_line":"  re-synchronisation.  It is not a viable alternative for resilient"},{"line_number":392,"context_line":"  multi-region deployments."},{"line_number":393,"context_line":""},{"line_number":394,"context_line":"* **Federation / Keystone-to-Keystone.** K2K federation can share"},{"line_number":395,"context_line":"  authentication state across regions but requires trust relationships between"},{"line_number":396,"context_line":"  deployments and does not give the operator control over which UUID a project"},{"line_number":397,"context_line":"  or user has in each region\u0027s local database."}],"source_content_type":"text/x-rst","patch_set":8,"id":"22ecf158_b268b8f9","line":394,"updated":"2026-06-09 20:07:23.000000000","message":"we can\u0027t rely on the K2K anymore since saml2 libs are being dropped by distros and so it need to go away independently on what happens here","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c5471d84d551a535e0a16e84509ebde383a0f105","unresolved":true,"context_lines":[{"line_number":414,"context_line":"  additional policy is needed for explicit IDs since domain creation is already"},{"line_number":415,"context_line":"  restricted to administrators only."},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"**Project creation** (new policy: ``identity:create_project_with_explicit_id``):"},{"line_number":418,"context_line":"  Requires admin role only (``role:admin``), which is more restrictive than"},{"line_number":419,"context_line":"  the base ``identity:create_project`` policy that allows domain managers"},{"line_number":420,"context_line":"  (``role:manager``). This prevents domain managers from creating projects with"}],"source_content_type":"text/x-rst","patch_set":8,"id":"d8b9a2cf_8949a52d","line":417,"updated":"2026-06-09 20:07:23.000000000","message":"It\u0027s a shame oslo.policy can\u0027t check the attribute for being defined without a custom check. I know it\u0027s very easy to do so but I do not want also Keystone to start overriding the native checks (and become another Neutron). I wish we could extend the existing policy rule instead of introducing a new one","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"0c966c551a24608dbaa1a8686c6369720c59b8f0","unresolved":true,"context_lines":[{"line_number":414,"context_line":"  additional policy is needed for explicit IDs since domain creation is already"},{"line_number":415,"context_line":"  restricted to administrators only."},{"line_number":416,"context_line":""},{"line_number":417,"context_line":"**Project creation** (new policy: ``identity:create_project_with_explicit_id``):"},{"line_number":418,"context_line":"  Requires admin role only (``role:admin``), which is more restrictive than"},{"line_number":419,"context_line":"  the base ``identity:create_project`` policy that allows domain managers"},{"line_number":420,"context_line":"  (``role:manager``). This prevents domain managers from creating projects with"}],"source_content_type":"text/x-rst","patch_set":8,"id":"387ea5cd_c5df1f17","line":417,"in_reply_to":"d8b9a2cf_8949a52d","updated":"2026-07-15 17:09:27.000000000","message":"I\u0027m not sure I understand what you mean by using a \"custom check\"?  The ``target`` dict exists already in Keystone and can be used to modify the existing policies instead of adding secondary policies.","commit_id":"798083c01992ef94581d67e3a6c132ea1d66dfab"},{"author":{"_account_id":7973,"name":"Douglas Mendizábal","email":"dmendiza@redhat.com","username":"dougmendizabal"},"change_message_id":"0c966c551a24608dbaa1a8686c6369720c59b8f0","unresolved":true,"context_lines":[{"line_number":116,"context_line":""},{"line_number":117,"context_line":"  - **Domains**: Use existing ``identity:create_domain`` policy (already"},{"line_number":118,"context_line":"    admin-only), so no additional policy is needed."},{"line_number":119,"context_line":"  - **Projects**: Use new ``identity:create_project_with_explicit_id`` policy"},{"line_number":120,"context_line":"    (admin-only), which is more restrictive than ``identity:create_project``"},{"line_number":121,"context_line":"    that allows domain managers."},{"line_number":122,"context_line":"  - **Users**: Use new ``identity:create_user_with_explicit_id`` policy"},{"line_number":123,"context_line":"    (admin-only), which is more restrictive than ``identity:create_user``"},{"line_number":124,"context_line":"    that allows domain managers."},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"  This prevents domain managers from creating resources with arbitrary IDs"},{"line_number":127,"context_line":"  that could enable resource theft via ID collision attacks."}],"source_content_type":"text/x-rst","patch_set":10,"id":"a728c21f_4b6b45a2","line":124,"range":{"start_line":119,"start_character":2,"end_line":124,"end_character":32},"updated":"2026-07-15 17:09:27.000000000","message":"As I mentioned in the commit message comment, I think it would be better to just update the existing policies instead of introducing secondary policies to only two APIs.","commit_id":"24876482066c893b7198dbb3af4d9a14a83d5a1c"}]}