Thanks for the feedback and we'll discuss this, as we take any security concerns seriously.
A couple of points about those properties:
First, the "@odata.id" is essentially a "self" pointer containing the URI of the resource. The "@odata.id" is provided so that the source URI is included in the JSON payload response - so that the source location is not lost if client software passes the payload on separate from the HTTP details. Since a client has to know the URI to read it - this value provides no new information from a security perspective. The fact that the Service replies to the "/redfish/v1" URI means that Redfish v1.x is supported.
The "RedfishVersion" indicates the version of the Redfish Specification that the Service supports. This is NOT the firmware / software version of the implementation, only the protocol version. That would only be useful if a flaw in the protocol was discovered (while that has happened in other protocols/specifications - it's unlikely in Redfish as the bulk of the protocol definition is just HTTP/HTTPS).
That said, the "RedfishVersion" property is not required, and so may be omitted from the payload. It is placed here primarily as a means for software to detect functionality that was added in minor 1.x versions of the specification. We've also defined the "ProtocolFeaturesSupported" object to better answer those software questions, as the Version doesn't tell a client if the service actually implements the (optional) features of the specification.
Don't think what is in there according to the specification is that sensitive, but it does annoy me that vendors put all kind of extra information in there that the server's owner did not consent to disclose.
E.g. HP puts there: - iLO firmware version - what authentication mechanism is in use (local username/password vs LDAP/kerberos authentication) - hostname/certificate information that defaults to server's serial number, allowing an attacker to pull the server's hardware configuration from partsurfer.hp.com/ and look for say high value targets, or older gear that may no longer have updates.
And while Dell doesn't do that, it does puts enough clues in there to determinate it's a Dell server, and can also grab the server's serial from the SSL certificate's common name.
Would be nice if specification strictly disallowed any and all information disclosure without authentication.