No, it is not mandatory, and not recommended, either. Since the user cannot perform a GET on a Session resource without already authenticating, it doesn't serve any purpose to show in the payload. But it is valid, so not a problem... Password is shown in the ManagerAccount resource so that the user knows the name of the password property in order to PATCH to update it correctly. It's defined in the Session schema as it needs to be part of a POST to create a new Session - and the "null on read" is a common description for all instances of "Password" in the Redfish data model.
Hi Jeff, Thanks for the details and "Password": null was shown as sample in Redfish Specification DSP0266_1.15.1.pdf ( 126.96.36.199 Session login) Please remove password from sample response if not required which can avoid confusion.
As from your reply, I understand it's not recommonded to show "Password": null in response(payload) of Post sessionservice's Sessions resource collection
In my opinion, I don't see the harm in leaving "Password": null in the GET response to the Session resource. It does convey it's a supported property. While it is ultimately something a user cannot do anything with after a Session resource has been created, it does provide consistency in the data model in terms of a client provides a property in a create operation, and it does see it in the new resource (although it's null in this case). But as Jeff pointed out, it's not mandatory, so if you want to omit it, then that's entirely legal. I see this as akin to the "HttpHeaders" property in EventDestination; it's null in responses to show support for the property and keeps the GET response as parallel as possible to what the client specified in the POST operation, but it's not configurable.