What message to send for PATCH Password failure?

To clarify: I understand HTTP status 400 should be used and I think the AccountNotModified message should be given in this case. I am interested in the correct solution. At the same time, I am thinking about a quick hack solution: Add an ["Oem"]["IBM"] field to the AccountNotModified message which states something like: "The new password was not accepted. A possible cause is the password value failed PAM validation checks."
I would give additional information, such as: the password is not complex enough, was re-used too soon, etc.m but I don't know how to get that level of details.

If I tried to PATCH a new password into my account and got AccountNotModified with the explanation above, I might be tempted to try a different password. And that is what I want. Is that direction correct for Redfish?

I think we want to have a message in the Base message registry for this case (and others) where a property value is not correct. It could be due to a regex violation per the patterns term, password complexity rules, or some other problem. But essentially we need something more deterministic for a client to know a value is not correct.

As a developer implementing a Redfish complaint application, where do I find guidance on how to select the right messages to respond? I see DSP0266 Redfish Spec > Service Responses > Error Responses, but I want more help. Is there anything in redfish.dmtf.org/education. Where is the right place for this?

• 1. PropertyValueTypeError, if the value has the wrong JSON type.
• 2. Use one of the following (the most specific message that applies to the situation):
•   - PropertyValueNotInList - for enum types
  - PropertyValueOutOfRange - for example, when the value is out of its numeric range
  - PropertyValueFormatError - when neither of the previous two messages apply and the format is well-defined
  - PropertyValueConflict, PropertyNotWritable, etc.
  - PropertyValueNotAccepted (PROPOSED) - when the format is not well-defined or the criteria for its acceptance can change
  - PasswordValueNotAccepted (PROPOSED) - a specialization of PropertyValueNotAccepted which omits the value from the message body.
  

Here is a proposal for the new messages:
PropertyValueNotAccepted (PROPOSED)
- Usage notes: Using this implies your code is using some backend service for which it cannot completely characterize the rules for valid values, or those rules change over time. A canonical example is Linux PAM which may have rules about password complexity which change over time (as the system is patched) or rules about re-using passwords. Prefer to use PropertyValueFormatError when applicable.
- MessageId: Base.TBD.PropertyValueNotAccepted
- Message: The new value %1 was not accepted. The reason is: %2 <-- Reason %2:string can be directly from PAM, for example, BAD PASSWORD: it is too short
- ParamTypes: [string, string] Note: This message can only be used for string-type parameters.
- Usage notes: This is a specialization of the PropertyValueNotAccepted message for passwords. This omits the password value from the message.
- MessageId: Base.TBD.PropertyValueNotAccepted
- Message: The new password was not accepted. The reason is: %1 <-- Reason %1:string can be directly from Linux PAM, for example, "BAD PASSWORD: it is too short".
- MessageId: PropertyValueRegexError
- Message: The new value %1 for the %2 property does not match regular expression: %3.

In the above, I've proposed both PropertyValueNotAccepted and PasswordValueNotAccepted. I can see a need for both, but I really only need one or the other. (I don't have a current use case for PropertyValueRegexError, but a need for it was mentioned in this thread.)
I would prefer having a PasswordValueNotAccepted message so I won't have to redact the password value. I greatly prefer to limit the propagation of password values.

Here is how the response would look for my current situation (specifically, PATCH new Password fails):
- error:
-     code: AccountNotModified
-     @message.ExtendedInfo:
-         (array)
-             MessageId: Base.(PROPOSAL).PasswordValueNotAccepted
-             Message: The new value %1 was not accepted. The reason is: %1 <-- Reason %1 can be directly from PAM, for example, BAD PASSWORD: it is too short
-         (array)
-             Or one of any number of other messages per the decision tree above.

Three questions:
1. Does the structure of my overall response look correct? Am I using AccountNotModified and (proposed) PasswordValueNotAccepted correctly?
2. Is the next step drafting a pull request to add these new messages to the spec?
3. I would like to be able to refer to a decision tree (such as outlined in this reply). I think it would help my future self and other developers in the OpenBMC project. Do you think it is worthwhile? Is there one already I am missing? Where is the right place for something like this?

The Base.1.7.0 message registry has a new PropertyValueIncorrect message that I can can use for the original problem.

Recall that I really really don't want to propagate the password value, even one that was not accepted.
Does the Redfish spec allow me to redact the password property value ("%2" in the message)?  For example, can I supply an empty string or the value *REDACTED* for this value?

Also, this message does not allow me to offer additional diagnostic messages about why the value was incorrect. For example, which regular expression does the value not match? Or in my case, I have messages from Linux-PAM modules that say why the new password was not accepted (shown here in the format: value -- response):
> abc -- BAD PASSWORD: it is WAY too short
> 0penBmc -- BAD PASSWORD: is too simple
> password -- BAD PASSWORD: it is based on a dictionary word
> 0penBmc12345678 -- BAD PASSWORD: it is too simplistic/systematic

Naturally different PAM implementations will have slightly different messages.
Can I add these in an Oem field of the PropertyValueIncorrect message, if so how? Or should I send another message?