)]}'
{"/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":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"}]}