ISO/TR 24097-3:2019

TECHNICAL ISO/TR
REPORT 24097-3
First edition
2019-02
Intelligent transport systems — Using
web services (machine-machine
delivery) for ITS service delivery —
Part 3:
Quality of service
Reference number
ISO/TR 24097-3:2019(E)
©
ISO 2019

---------------------- Page: 1 ----------------------
ISO/TR 24097-3:2019(E)

COPYRIGHT PROTECTED DOCUMENT
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved

---------------------- Page: 2 ----------------------
ISO/TR 24097-3:2019(E)

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Notation and conventions . 4
5.1 Namespace URI and prefixes used in this document . 4
5.2 Web service syntax notation: pseudo-schemas . 5
5.3 XPath 1.0 expression . 6
5.4 XML infoset . . 6
5.5 SOA stack name notation . 6
5.6 Examples . 6
6 Web services overview . 6
7 QoS overview . 7
8 QoS standards . 8
8.1 WS-Policy language . 9
8.2 WS-Policy 1.5 — Framework .10
8.2.1 Policy authoring style .10
8.2.2 A policy description by combining domain specific policies .13
8.3 WS-Policy 1.5 — Attachment.13
8.3.1 Combining multiple policies .15
8.3.2 Policy attachment points, policy subjects, and policy scope.15
9 Domain specific policy overview .17
9.1 Messaging metadata (WS-Addressing metadata) .18
9.1.1 WS-Addressing standard .18
9.1.2 WS-Addressing 1.0 — Core and Web Services Addressing 1.0 — SOAP Binding .19
9.1.3 WS-Addressing 1.0 — Metadata .20
9.1.4 Elaboration of WS-AddressingMetadata .20
9.2 WS-SecurityPolicy (WSSP).21
9.2.1 WSSP standard .21
9.2.2 WSSP scope.22
9.2.3 WS-SecurityPolicy fundamental .23
9.2.4 Cryptographic algorithms and key length .24
9.2.5 WSSP use case .24
9.2.6 Validation of WS-SecurityPolicy document .29
9.3 Web Services Reliable Messaging Policy Assertion .29
9.3.1 RM Policy Assertions .30
9.4 MTOM policy (MTOM Serialization Policy Assertion 1.1).30
9.5 SOAP usage policy (Web Services SOAP Assertions) .31
10 Metadata versioning .31
11 Security considerations.32
Annex A (informative) Security relevant web services standards .34
Annex B (informative) JAX-WS .38
Bibliography .39
© ISO 2019 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TR 24097-3:2019(E)

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 24097 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO 2019 – All rights reserved

---------------------- Page: 4 ----------------------
ISO/TR 24097-3:2019(E)

Introduction
In order to provide high quality ITS services, various types of service coordination are indispensable,
e.g. coordination between financial industries in an Electronic Fee Collections service. Service systems
are constructed in a heterogeneous platform, e.g. hardware, OS, middleware, and/or application
development language. Web services are technologies for heterogeneous distributed systems
coordination.
To provide web services in an agile and interoperable manner, the use of standard based metadata
was proposed in ISO 24097-1. Web service (WS) metadata is a formal description of a web service.
It is expressed by: Interface metadata and QoS (Quality of Service) metadata. WS metadata is a
technical contract between a web service provider and its consumers, so both sides are aware of
this interface. This provides the base of interoperability between a service provider's program and a
service consumer's program. Because metadata is based on standards, software tools can support the
WS lifecycle through design to servicing and upgrading.
Figure 1 — ITS WS metadata use case
The interface metadata standard is the WSDL. This topic was covered in ISO/TR 24097-2.
QoS metadata is a combination of domain specific requirements and constraints such as security,
reliable messaging, message addressing, and SOAP message transmission optimization.
This document focuses on these QoS topics.
© ISO 2019 – All rights reserved v

---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/TR 24097-3:2019(E)
Intelligent transport systems — Using web services
(machine-machine delivery) for ITS service delivery —
Part 3:
Quality of service
1 Scope
This document aims to promote ITS web services interoperability. Historically, web services
interoperability evolved through activities shown in Figure 2. Applying the first two steps properly is
the key to interoperability.
Figure 2 — Evolution of web services developing circumstances
This document focuses on the following topics:
— WS-policy language;
— domain specific policy metadata:
— WS-Aaddressing policy metadata;
— WS-ReliableMessaging policy metadata;
— WS-Security Policy metadata;
— SOAP Message transmission optimization Policy;
— other policies.
© ISO 2019 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/TR 24097-3:2019(E)

2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
claim
declaration made by an entity
EXAMPLE Name, identity, key, group, privilege, capability.
3.2
claim confirmation
process of verifying that a claim applies to an entity
3.3
domain
specific area to which policy applies
EXAMPLE Security or message transmission reliability.
3.4
endpoint
combination of a binding and a network address
3.5
IDE
software that provides comprehensive facilities for application (including web services) development
3.6
initiator
role sending the initial message in a message exchange
3.7
instance document
XML document that conforms to a schema
EXAMPLE If the schema is WSDL, the XML document is an WSDL instance document.
3.8
metadata
data describing an instance of WS behaviour consisting of interface metadata (WSDL description) and
QoS metadata
3.9
policy assertion
requirement, capability or other property of a web service
3.10
policy subject
entity with which a policy assertion can be associated
EXAMPLE Endpoint, message, resource, operation.
2 © ISO 2019 – All rights reserved

---------------------- Page: 7 ----------------------
ISO/TR 24097-3:2019(E)

3.11
recipient
role that processes the initial message in a message exchange
3.12
security binding
set of properties that provide enough information to secure a given message
exchange
3.13
security binding assertion
policy assertion that identifies the type of security binding being used to secure
an exchange of messages
3.14
security binding property
aspect of securing an exchange of messages
3.15
security token
token
collection of (one or more) claims
3.16
supporting token
security token used to provide additional claims
3.17
token assertion
description of a token requirement
Note 1 to entry: Token assertions defined within a security binding are used to satisfy protection requirements.
3.18
web service policy language
WS-Policy
language that is used to expresses domain specific policy and/or an instance of a
web service requirement and policy attachment to relevant WSDL constructs
4 Abbreviated terms
BP (WS-I) Basic Profile
BPEL Business Process Execution Language
ENISA European Union Agency for Network and Information Security Agency
EPR End Point Reference
HTTP Hypertext Transfer Protocol
JAX-WS Java API for XML Web Services
JSR Java Service Request
IDE Integrated Development Environment
MAP Message Addressing Property
MTOM SOAP Message Transmission Optimization Mechanism
© ISO 2019 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/TR 24097-3:2019(E)

NIST National Institute of Standards and Technology
OASIS Organization for the Advancement of Structured Information Standards
SOA Service Oriented Architecture
STS Security Token Service
TC Technical Committee
QoS Quality of Services
URL Universal Resource Locator
W3C World Wide Web Consortium
WG Working Group
WS Web Service
WS-I Web Services Interoperability organization
WSSP Web Services Security Policy
XKMS XML Key Management Specification
XML eXtensible Markup Language (SOAP 1.2)
NOTE SOAP is not an abbreviated terms. It is a proper noun.
5 Notation and conventions
5.1 Namespace URI and prefixes used in this document
This document uses many namespace prefixes throughout; they are listed in Table 1.
The choice of any namespace prefix is arbitrary and not semantically significant. However, the prefix
shall be unique in any single document. We use the namespace prefixes as shown Table 2.
NOTE For reasons of brevity, not all examples are shown as full schemas. In this case, it is assumed that the
namespace prefix has been declared in a parent element. In this case, the namespace prefix identified in Table 2
is used as a convention.
Table 2 — Namespace and prefix convention
Prefix XML namespace URI Specifications
s
Either of s11 or s12
s11 http://schemas.xmlsoap.org/wsdl/soap/
SOAP 1.1
s12 http://schemas.xmlsoap.org/wsdl/soap12/
SOAP 1.2
wsdl http://schemas.xmlsoap.org/wsdl/
WSDL 1.1
wsdl20 http://www.w3.org/ns/wsdl"
WSDL 2.0
wssa http://www.w3.org/2011/03/ws-sas
SOAP Version assertion policy
xs http://www.w3.org/2001/XMLSchema
[XML-Schema1], [XML-Schema2]
xsi http://www.w3.org/2001/XMLSchema-
XML Schema Structures
instance
wsic http://ws-i.org/schemas/conformanceClaim
WS-I conformance claim
wssa http://www.w3.org/2011/03/ws-sas
WS-SOAPAssertions
4 © ISO 2019 – All rights reserved

---------------------- Page: 9 ----------------------
ISO/TR 24097-3:2019(E)

Table 2 (continued)
Prefix XML namespace URI Specifications
bp12 http://ws-i.org/profiles/basic-
BP 1.0
profile/1.2/"
wsp http://www.w3.org/2006/07/ws-policy
WS-Policy 1.5
wsam http://www.w3.org/2007/05/addressing/
WS-Addressing metadata
metadata
wsrmp http://docs.oasis-open.org/ws-rx/
WS-ReliableMessaging Policy Assertion
wsrmp/200702
wsu http://docs.oasis-open.org/
Utility schema
wss/2004/01/oasis-200401-wss-
wssecurity-utility-1.0.xsd
wsse http://docs.oasis-open.org/wss/2004/01/ [WS-Security]
oasis-200401-wss-wssecurity-secext-1.0.xsd
sp http://docs.oasis-open.org/ws-sx/
WS-SecurityPolicy 1.3
ws-securitypolicy/v1.3/cd/ws-
securitypolicy.xsd
ds http://www.w3.org/2000/09/xmldsig#
[XML-Signature]
xenc http://www.w3.org/2001/04/xmlenc#
[XML-Encrypt]
wsc http://docs.oasis-open.org/ws-sx/ws-
This specification
secureconversation/200512
mtom http://www.w3.org/2007/08/soap12-mtom- MTOM Serialization Policy Assertion
policy
tns
The “this namespace” (tns) prefix is used
as a convention to refer to the current web
service.
When developing web services, we need to check what version(s) of the standards the software under
development should support. In a standards body like W3C and OASIS, new versions are frequently
released, but support tools follow behind with some time lag. Therefore, it is up to the developers to
determine if it is appropriate to implement the latest versions.
5.2 Web service syntax notation: pseudo-schemas
Every web service language, e.g. WSDL, WS-Policy, has its own schema to validate the user’s instance
description. Because web service language is complex, it is helpful to know the grammar at a glance.
For that reason, pseudo-schemas (or shorthand schemas) are used to represent schema syntax. In this
representation:
— The syntax appears as an XML instance, but values indicate data types instead of literal values.
— Characters are appended to elements and attributes to indicate cardinality:
— "?" (0 or 1);
— "*" (0 or more);
— "+" (1 or more).
— The character "|" is used to indicate a choice between alternatives.
— The characters "("and")" are used to indicate that contained items are to be treated as a group with
respect to cardinality or choice.
— The characters "["and"]" are used to call out references and property names.
— Ellipses ("…") indicate points of extensibility. Additional children and/or attributes may be added
at the indicated extension points but do not contradict the semantics of the parent and/or owner,
© ISO 2019 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/TR 24097-3:2019(E)

respectively. By default, if a receiver does not understand an extension, the receiver should ignore
the extension.
5.3 XPath 1.0 expression
An XPath 1.0 expression is used to specify an XML element and/or attribute.
EXAMPLE
/wsdl11:definition/wsdl11:message, wsdl11:definition/wsdl11:binding/wsdl11:@name
5.4 XML infoset
A WS-Policy document relies on the XML Information Set [XML Information Set]. Information item
properties are indicated by the style [infoset property].
5.5 SOA stack name notation
The SOA stack name is represented in bold italics.
EXAMPLE messaging
5.6 Examples
To clarify an explanation, we give examples using "Eclipse" (from Eclipse Foundation) IDE and its
plug-in web tool platform (hereafter WTP). This is only an example of an available tool and not a
recommendation for Eclipse.
We selected Eclipse because it:
— is open software (not specific vendor software);
— provides an integrated development environment (from design to deployment, based on latest
software technology);
— supports many high-quality candidate plug-ins;
— has a context-based wizard;
— was developed by a community that included W3C members;
— has reasonable documentation; and
— is similar to many commercial IDEs, which should facilitate other IDE users to understand the
information presented in this document.
In this document all examples are informative.
6 Web services overview
The ISO 24097 series enables a plurality of geographically dispersed intelligent transport systems
using various platforms to exchange necessary information, thereby realizing a service that is high in
quality and reflects user needs. For service providers and service users to realize interoperability, the
requirements shown in Table 1 are necessary.
6 © ISO 2019 – All rights reserved

---------------------- Page: 11 ----------------------
ISO/TR 24097-3:2019(E)

Table 1 — Basic requirements for interoperable ITS web services
Basic requirements Requirement content Reference material
To ensure interoperability be- Describe the technical requirements ISO 24097-1:2017
tween the ITS service provider with interface and QoS metadata and
and the service user, the service make it public to the service user in
provider describes and discloses some way (e.g. UDDI and/or endpoint
the technical requirements of reference). Service users develop user
the ITS service in metadata. The systems under these conditions.
service user creates a program
according to the metadata.
Metadata standards are some- When there is a provision in WS-I, use ISO 24097-1:2017, A.4.2
times generalized, and if you can metadata within that range.
implement interoperability with
restrictions, use WS-I.
As the ITS service may evolve, For each interface and QoS domain ISO 24097-1:2017, 6.2.1.3
version control is necessary. metadata, give a version number.
ISO 24097-1:2017, 7.2.4
When considering new services,
Version numbers are given in the follow-
consider backward compatibility
ing system:
and protect service users when
possible. If backward compat-  Form: m.n.a:
ibility cannot be implemented,
  m: major version number
change the major version number
  (xs:positiveInteger)
(see the right column), but con-
tinue the old version service for a  n: minor version number
reasonable period.  (xs:nonNegativeInteger)
  a: draft version number
  (xs:NCName)
Interface metadata Use WSDL 1.1. ISO/TR 24097-2:2015, 6.1
SOAP version Prioritize SOAP 1.2 over SOAP 1.1. ISO/TR 24097-2:2015, 7.1
Description of QoS Define the QoS for each domain. This document
Other than SOAP MTOM, it is described
as a policy standardized by the QoS
standard.
Recommend description of SOAP MTOM
based on JSR 224
Enable QoS Other than SOAP MTOM, based on the This document
WS-PolicyAttachment standard, consid-
ering the scope of policy, give it to the
correct attachment point.
7 QoS overview
The QoS describes the requirements and constraints of a web service. The following figure shows the
whole web services stack. The black shaded parts are relevant to QoS standards.
© ISO 2019 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/TR 24097-3:2019(E)

Figure 3 — QoS relevant metadata
8 QoS standards
Web services metadata is a high-level description of a specific web service. It consists of the Interface
metadata and the QoS metadata.
The Interface metadata is WSDL 1.1 and/or WSDL 2.0.
The QoS metadata is an expression of the required functionality or constraint of a specific web service. A
web service requires various types of functionality or constraints such as reliable message transmission,
secure messaging, and/or data transmission optimization. Therefore, QoS metadata are divided into
domain-specific categories based on SOA principles. This allows domain-specific experts to standardize
8 © ISO 2019 – All rights reserved

---------------------- Page: 13 ----------------------
ISO/TR 24097-3:2019(E)

content based on their expert knowledge and rich experience. Modular structure standards enable
users (service providers and/or service consumers) to select functions and constraints as needed.
To develop domain-specific QoS standards, the W3C prepared a common policy description language
known as the WS-Policy. The latest domain-specific QoS standards using WS-Policy are: Web Services
Policy 1.5 — Framework and Web Services Policy 1.5 — Attachment.
The Web Services Policy 1.5 — Framework is applied to describe domain-specific standards. All domain-
specific policy standards are described by this common syntax (see Figure 4). Common domain-specific
policies include standardized Security Policy, Messaging Policy, Reliable Messaging Policy, and SOAP
Messaging Policy. If policy users want their specific policy, users can create their policy based on the
WS-Policy language.
The Web Services Policy 1.5 — Attachment enables a policy attachment to WSDL and/or UDDI and
executes the policy at run time. The user is responsible for adding the attachment as needed. This
language provides a combining facility for domain-specific policies, e.g. applying both a security policy
and a reliable transmitting policy, which is called a “merge” in the standard.
The following figure depicts the policy language structure and the relationship between Interface
metadata.
Figure 4 — Web services metadata and their relationships
8.1 WS-Policy language
Table 3 summarizes the WS-Policy language standards and the introductive or guideline documents
developed by W3C.
© ISO 2019 – All rights reserved 9

---------------------- Page: 14 ----------------------
ISO/TR 24097-3:2019(E)

Table 3 — WS-Policy related documents
Standard Description Document location
Web Services Policy 1.5 — Provides a general-purpose policy http://www.w3.org/TR/ws-
Framework model and corresponding syntax policy/
to describe the policies.
Web Services Policy 1.5 XML
http://www.w3.org/2007/02/ws-policy.xsd
Schema URI
http://www.w3.org/TR/ws-
Web Services Policy 1.5 — Describes a mechanism for attach-
policy-attach
Attachment ing policies to WSDL or UDDI.
Introductive or guideline document
http://www.w3.org/TR/ws-
Web Services Policy 1.5 — Introductive document of explain-
policy-primer/
Primer ing how to use WS-Policy 1.5
http://www.w3.org/TR/ws-
Web Services Policy 1.5 — Provides guidance for domain
policy-guidelines/
Guidelines for Policy Assertion specific assertion authors that
Authors will work with the Web Services
Policy 1.5. Some parts for service
providers.
8.2 WS-Policy 1.5 — Framework
The WS-Policy 1.5 Framework is able to model both a single policy (a collection of assertions that acts
as one policy, without alternatives) and also multiple policy alternatives. This means that model service
providers may express their policies in multiple policy alternatives and thereby allow users to select
the policy that suits them best.
Figure 5 — WS-Policy model
8.2.1 Policy authoring style
W3C’s WS-Policy working group organizes policy expressions in two forms: normal form and compact
form. The two forms are semantically the same.
The normal form enumerates all possible cases (alternatives) the service supports; each alternative is
mutually e
...