STAR Message-Level Security can be defined as information carried in the message itself, which enables Privacy Identification and Authentication.

Message senders in upstream automotive typically assume one of three key roles; Dealership or Dealership Management System, Intermediary and OEM. STAR Transport does not prescribe how a receiver should view these business relationships. The Guidelines do describe a limited set of Security technologies and methods to be applied directly to a message in transit. In other words, STAR defines Identity and Authentication mechanics to enable a sender to authorize a transaction, but STAR does not prescribe how the message receiver actually decides whether a sender is authorized or not to execute a service or query for information.

A receiver must identify a sender based on:

OR

A receiver must authenticate a sender based on:

STAR currently allows for two types of security tokens - Digital Certificates & Username/Password.

STAR does not take into account security data located in the SOAP body or BOD payload of a message, all Message-Level security data is contained within SOAP Message Headers.

STAR Messages MAY be Digitally Signed using Digital Certificates as a basis of the signature. STAR recommends that Digital Certificates not be passed in the message itself. If present in a message, a Digital Certificate MUST be protected through Data Encryption. If the parties agree, a reference to a known certificate, such as a Distinguished Name, MAY be passed in a message.

By signing a message, the sender is making the statement "I am the subject represented by the Digital Certificate and this is a message from me". In other words, the sender's Identity can be determined by the fact the sender holds the private key associated with a specific Digital Certificate and the sender has digitally signed the message using that private key. STAR allows for the use of self-signed certificates. The use of self-signed certificates provides adequate security in most use cases in which STAR transactions will occur. If a trading partner needs added security above and beyond the security provided by self-signed certificates, they may use a 3^rd party root CA. Using a root CA can provide an added level of assurance that the party is who they say they are, but at significant cost to the trading partners involved.

STAR Messages MAY include a Username in the SOAP Message Headers. If present, a Username / Password combination MUST be used to Authenticate the message sender.

Senders MUST take steps to ensure the protection of passwords. If a Password is sent in the message, it MUST be obfuscated using data encryption or some other method that makes the Password unreadable to any party other than the intended recipient. If Password is not obfuscated at the message level, it must be encrypted at the Transfer Infrastructure-Level using SSL.

If the two parties agree, a hash of the Password MAY be passed in place of the Password itself.

Parts of STAR messages MAY be encrypted using XMLEncryption. Typically, a sender uses the Public Key of the receiver (based on the receivers Digital Certificate) to generate an encrypted Symmetric Key that is then used to encrypt parts of the message. When received, the receiver processes the message, which uses its Private Key to decrypt the Symmetric Key, and uses the Symmetric key to decrypt the message.

Within the message Header elements, WS-Security 2004 elements MAY be used to help a receiver determine what parts of the message are encrypted.

System, Source and Target Authentication are commonly associated with Transfer Infrastructure-Level security. Typically, HTTP/S is used in conjunction with infrastructure components such as Firewalls and LDAP Directories to establish the Identity of the Systems involved in messaging. STAR does not prescribe any methods for these features at the Message-Level. Implementations of these features are discussed in detail under Infrastructure-Level Security.