In your EIP-5192 thread, specifically the post that inspired you to include the locked function.
You specifically mentioned token transferability is possible, and this “shut up the nay-sayers arguing for better key rotation”. It doesn’t matter who has the rights to change token transferability, contract owner of token receiver, the fact that this is changeable makes my previous point:
Again, it’s not about what is “possible” or “achievable with EIP-5192”. What’s important is that the flexibility of EIP-5192 diminishes credibility of SBTs’ immutability.
If you want to argue that oh wait, I have changed my mind, and EIP-5192’s lock status CANNOT be changed by either parties after issuance. There are few things you have to do. First,
This should be in your EIP’s specification section, not here in the comment section of a related proposal. Your proposal made it very vague and ambiguous on who has the rights to change/assign lock status. Previously I thought you leave it to the implementation to decide the specific rules, but if you want to argue that lock/unlock status is permanent after issuance (which is basically what you are arguing in the previous post), your current EIP-5192 definitely needs a lot of modification on clarifying the rules, and I recommend you roll it back to review status if you intend EIP-5192’s lock status to be permanent after issuance.