| Standards for Technology in Automotive Retail |
| Home - News Feed

STAR Interoperability Rules
Prev |  | Next

## STAR Interoperability Rules

### Level 1

STAR1001

  All web services must be compliant to the rules and specifications outlined by the WS-I Basic Profile.

STAR1002

  Appropriate compliance markers are required as specified by the WS-I Conformance Claim Attachment Mechanisms document.

STAR1003

  All implementations are required to support Username/Password for authentication.

STAR1004

  All implementations are REQUIRED to send information over HTTPS.

STAR1005

  All passwords are required to be sent as plain text or hashed.

STAR1008

  All services and clients must be compliant to the general Security requirements Outlined by the WS-I Basic Security Profile 1.0 .The optional attributes defined in the Profile is also to be relaxed in the STAR Implementation.

STAR1009

  All STAR Web Services are REQUIRED to understand and handle the STAR Specific SOAP Faults.

STAR1010

  All STAR soap fault error codes are REQUIRED to be be prefixed with STAR: and the appropriate STAR error code. i.e. STAR:Invalid Structure

STAR1011

  All STAR soap fault error codes are REQUIRED to appear in the standard SOAP:Fault block.

STAR1012

  SOAP Faults are for Critical Processing errors only. Informational or warning errors should not be sent as a SOAP Fault.

STAR1013

  ConfirmBOD reason codes that are sent at the Warning or Informational status, SHOULD NOT trigger a resending of the BOD.

STAR1014

  WS-Security errors must send the appropriate WS-Security SOAP Fault for the authorization being used.

STAR1015

  STAR BOD Specific and Generic Transports must be message level interoperable.

STAR1016

  Application level error messages MUST NOT be returned with a SOAP Fault, and MUST be returned using the appropriate BOD.

STAR1017

  The service provider must keep track of contents that are deemed to have been received by the client to avoid resending.

STAR1018

  A SOAP Header MUST contain one manifest element for each content element in the SOAP body.

STAR1019

  A manifest is REQUIRED to have namespaceURI, element, contentID, and version attributes. Even though version is listed as optional it is REQUIRED for STAR BOD and DTS transports.

STAR1020

  The client must be able to handle duplicate messages from a service provider.

### Level 2

STAR2001

  Level 2 implementations MUST use X509 certificates.

STAR2002

  Implementations MUST conform to section 12, " X.509 Certificate Token" of the WS-I Basic Security Profile 1.0.

STAR2003

  "At-Least-Once" requires the sending party to uniquely identify a message and the receiving party to acknowledge the receipt of the message, giving the sender an auditable record stating that the message has been received. If the sender does not receive an acknowledgment of receipt in a reasonable amount of time (Time-Out), it MUST retry the message send.

STAR2004

  If a message was not able to be sent it MUST be retried at least three times.

STAR2005

  "At-Most-Once" requires a sending party to uniquely identify messages, to retry failed messages and requires the receiving party to identify and ignore any duplicate messages. In order to know which messages to ignore, it is REQUIRED that the receiving party persist received messages in a durable store.

STAR2006

  "Once-And-Only-Once / Exactly-Once" requires the sender to uniquely identify each message and to retry any message that the receiver fails to acknowledge. The receiver must acknowledge receipt of messages and ignore duplicate messages. It is REQUIRED that the receiver persist messages in a durable store to enable duplicate elimination.

STAR2007

  For indicating Routing information, STAR requires the use of WS-Addressing or WS-MakeConnection if the end point is not directly addressable.

STAR2008

  Acknowledgement of Receipts MUST be enabled during the use of At-Most-Once and Once and Only Once reliability.

STAR2009

  STAR requires that the messages be sequenced to ensure proper delivery and processing of related messages.

STAR2010

  Error handling is REQUIRED to follow the recommendations of the WS-I Reliable and Secure Profile in regards to handling of errors.

STAR2011

  Security in regards to Digital Certificates MUST follow the rules outlined by STAR2002 and the WS-I Reliable and Secure Profile.

STAR2012

  At-Most-Once or Once-And-Only-Once / Exactly-Once implementations must support the handling of duplicate messages.

STAR2013

  Attachments MUST use MTOM attachments or SOAP with Attachments. MTOM attachments are RECOMMENDED over SOAP with Attachments.

STAR2014

  The use of DIME attachments MUST NOT be used.

Prev |  | Next
10.2. Attachment Element | Home | Appendix A. STAR Level One Check List