Automotive Retail Profile

STAR (Standards for Technology in Automotive Retail) is a non-profit automotive industry group which promotes voluntary standards for the benefit of automotive dealers and manufacturers. To promote adoption of common business messaging STAR has recently published detailed guidelines for Web Services and for ebXML Message Service version 2.0 (ebMS 2).

The Automotive Retail Profile is an ebMS technical testing profile with the goal to accelerate high quality adoption of key STAR transport recommendations. This profile is focused on testing key STAR requirements and recommendations that represent a compliant superset of the ebMS 2 specification. These recommendations include the ability to compress large payloads and the ability to flexibly populate ebMS Message Header fields in a manner that reflects that the message contains a STAR XML BOD payload.

STAR retains all copyrights to its publications. STAR guidelines can be obtained by visiting www.starstandards.org.

Technical Requirements

The Automotive Retail Profile is based on the STAR ebMS Transport Guidelines and describes a compliant superset of ebMS 2.0:

Messages MUST be compliant to ebMS 2.0
Messages MAY have multiple payloads
Use of HTTPs (SSL) is STRONGLY RECOMMENDED
XML payloads over one megabyte are RECOMMENDED to be compressed using gzip
If the Message contains one or more STAR XML BOD payloads, the Message header elements Service and Action MUST be populated based on the STAR XML payload content type. For a STAR XML BOD:

Service type attribute MUST be present and its value must be "STARBOD"
Service element value MUST equal the payload's STAR BOD Noun
Action element value MUST equal the payload's STAR BOD Verb

Message header elements Timestamp, CPAId PartyID are populated based on STAR requirements and recommendations:
- Timestamp value MUST be UTC, XMLSchema datetime format with no offsets
- CPAId value is RECOMMENDED to be in the format:
- PartyIDs MUST be agreed to by the parties involved and MAY be based on DUNs numbers or pre-assigned Manufacturer and Dealership identifiers.
When the Message header element MessageId is created by a backend application (i.e. the MessageId is not created by the MSH) parts of the messageID may be intended to assist with routing, correlation and auditing and the MessageId in this case MUST contain references to a Service identifier, a company name and a GUID (Globally Unique ID). The RECOMMENDED format is Service Identifier followed by a period (.) followed by a GUID followed by an at sign (@) followed by a company name in domain name format. For example:
PartsOrder.20060815-16:51:12-00023@sender.org
To clarify the above statement: If the MessageId is generated by the MSH, STAR does not provide a recommendation for a particular format for MessageId, but does REQUIRE that the format comply with ebMS 2. In other words the MessageId is required to be globally unique and conform to IETF RFC 2822, which effectively requires that MessageId's be of the format id-left "@" id-right.

Best Practices

During the Drummond Group Inc interoperability testing of the Automotive Retail Profile, implementing vendors formulated technical consensus items in order to achieve interoperability of the profile's requirements. These consensus items are considered best practices for implementing the Automotive Retail Profile. They are not part of the Automotive Retail Profile requirements but are considered critical in order to achieve widespread interoperability.

Compress first, Sign second

For the purposes of the Automotive Retail Profile, participants are required to apply compression first and Digital Signature second. During the current test round, there was discussion that there are cases where signing first and compressing second make sense.

This best practice is based on discussions with STAR members who worked directly on the STAR ebMS Transport guidelines, and it is intended that this order (compress first sign second) allows for implementations where a backend system may be responsible for the compression but the message handler will be responsible for the digital signature.

Compressed data will not be base64 encoded

A best practice was made that compressed data will be represented as simple binary data and would not be encoded as base64. The reasoning behind this practice is:

Base64 encoding is not needed as HTTP is considered to be a binary safe protocol
Base64 encoding and decoding would add unnecessary processing overhead

It was vetted with approval from the group that developed the STAR Transport guidelines.