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 2019
© 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

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
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

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.
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.
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

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
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

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,
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

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.
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

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.
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 exclusive. The normal form follows the syntax below:
(01)
(02) 
(03)   ( ( … )* )*
10 © ISO 2019 – All rights reserved

(04) 
(05)
A graphical representation of the syntax above is shown in Figure 6.
Figure 6 — Normal form expression
The normal form follows the rules below:
1) Each alternative is mutually exclusive.
2) Each nested policy contains at most one policy alternative [due to rule 1)].
This usually causes verbose policy expression compared to the compact form, which is shown below:
1) The compact form syntax:

( … |
… |
… |
… |
…
)*

2) No additional constraints;
3) The wsp:Optional = "xs:boolean" attribute may be attached to Assertion element.
Compact form is equivalent to normal form;


…





The following is an example from the WS-Policy 1.5 Framework document, which is useful to compare
both forms. The compact form is:
(01) xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02) 
(03)  
(04)   
(05)    
(06)     
(07)      
(08)      
(09)     
(10)    
(11)   
(12)   
(13)    



(15)      
(16)   

(17)   
(18)  
(19)
The equivalent normal form of the expression would be:
(01) xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:wsp="http://www.w3.org/ns/ws-policy" >
(02) 
(03)  
(04)   
(05)    
(06)     
(07)      
(08)       
(09)      
(10)     
(11)     
(12)      



(14)      
(15)     

(16)    
(17)   
(18)  
(19)  
(20)   
(21)    
(22)     
(23)      
(24)       
(25)      
(26)     
(27)     
(28)      



(30)      
(31)     

(32)    
(33)   
12 © ISO 2019 – All rights reserved

(34)  
(35) 
(36)
Comparing both expressions, the compact form is easier to read and to understand.
W3C Web Services Policy 1 [11] subclause 4.1 states "to simplify processing and improve interoperability,
the normal form of a policy expression SHOULD be used where practical". However, service users might
not have their own described policy. Moreover, some potential service users might not have software
to calculate compatibility (see paragraph below). Thus, in this case, the normal form cannot be used to
calculate compatibility. Considering this, the compact form may be the better choice.
If we encrypt one field message, are the policy alternatives exclusive? They are not exclusive even though
they look like they would be exclusive. This requires a semantic check, which might not be easy to do.
8.2.2 A policy description by combining domain specific policies
The WS-Policy enables the web services to be developed by dividing policy into modular domain-
specific policies. As a result, service providers are able to construct their own policy by combining
domain-specific policies. This results in not only higher productivity but also easier readability and
maintainability.
The compact form wsp:PolicyReference lets us facilitate outer policy reference. The syntax is as
follows:
(01) (02)   URI="xs:anyURI"
(03)  ( Digest="xs:base64Binary" ( DigestAlgorithm="xs:anyURI" )? )?
(04)   … >
(05)  …
(06)
The default digest algorithm is the "SHA1 hash", athough additional algorithms can be expressed. The
digest value to check is xs:base64Binary.
NOTE As shown in the compact form, psuedo schema, we can use wsp:PolicyRerence as many times
as desired. This means we can create domain specific policies independently and attach them to a WSDL attach
point independently. This offers an easier way to create a policy and promotes readability.
8.3 WS-Policy 1.5 — Attachment
The WS-Policy language is independent from WSDL; a policy can be attached to WSDL in one of three
ways: embedding a policy in WSDL directly, associating an outer policy to the WSDL, or creating an
outer policy reference from the WSDL.
Figure 7 — Policy association styles
"Embedding type" is an expression that captures both interface metadata and QoS metadata in one
document. It consists of numerous statements, and reuse of the QoS metadata outside of the WSDL is
impossible. This style may be the best option for a service provider who has a small number of web
services.
"Policy attaching type" is another recommended way by which we can expect the following benefits:
— Independent policy development from interface metadata. This allows designers to concentrate on
policy, and in some situations, policy can be developed by domain specific professionals;
— Increase of reusability. If a service provider has many WSs, the policy requirements among the
services may be similar, in which case the policy becomes reusable; and
— Ease of maintenance.
When using the wsp:PolicyReference element, a service consumer will know what kind of QoS is
required with the WSDL.
Outer policy reference is done using the wsp:PolicyReference. Using wsp:PolicyAttachment
it may be difficult for a consumer to know what kind of policy is required. It may be useful for a service
provider to govern the policies.
The syntax of wsp:PolicyReference is:
URI="xs:anyURI"
( Digest="xs:base64Binary" ( DigestAlgorithm="xs:anyURI" )? )?
… >
…

The wsp:PolicyReference/@Digest and wsp:PolicyReference/@DigestAlgorithm
provide the WS consumer the referenced policy integrity.
The following listing is an example of wsp:PolicyReference usage. In this example
wsdl:definition refers to the outer policy of /wsp:policy/@common.

…
14 © ISO 2019 – All rights reserved

"http://www.w3.org/ns/ws-policy” />
…

A referenced policy needs the wsu:Id attribute. In this case, the common policy document is located at
http: //www .example .org/tentative.

xmlns:mtom="http://www.w3.org/2007/08/soap12-mtom-policy" />
…

NOTE There are three methods to identify policy: wsu:Id, xml:id, and wsp:Name. The schema outline for
attributes to associate an IRI is as follows: | xml:id="xs:ID" )?.>.
The W3C Policy standard recommends using the wsu:Id rather than xml:id because xml:id can
cause incompatibility problems when calculating a digital signature.
8.3.1 Combining multiple policies
It is considered common to combine multiple domain specific policies simultaneously, e.g. security
policy and reliability policy, because it is easier to consider and to manage independent policies. As
a result, multiple policies may be attached to an identical policy subject. In this case, all independent
policies are combined in the wsp:All element (see EXAMPLE below).
EXAMPLE

…



…
…

The system software would then interpret the policy as follows: (this process is called a merge):

…








…

8.3.2 Policy attachment points, policy subjects, and policy scope
To implement a policy as intended, the receiver needs to know the basic behaviour of the policy
attachment. Figure 8 shows the WSDL 1.1 structure, policy attachment points, and the policy subject.
The policy attachment points are the places where we can attach and associate policies. In Figure 8, the
attachment points are: Service, Port, Binding, Binding/Operation/input, Binding/Operation/output,
Binding/Operation/fault, Porttype, Porttype/Operation/input, Porttype/Operation/output, Porttype/
Operation/fault, and Message element. The policy subjects are the grouping concept of the similar
policy attachment points.
NOTE Some domain specific policies specify the attachment point(s). In that case, we follow the specification.
Figure 8 — Policy attachment points and policy subjects in WSDL 1.1
W3C defines the policy scope as a collection of policy subjects to which a policy can apply. When we
attach a policy expression to an attaching point, it propagates to an association relationship policy
attachment. Figure 9 shows how to propagate the policy expression.
16 © ISO 2019 – All rights reserved

Figure 9 — Attached policy scope example
If we attach a policy expression to an attachment point A, it propagates to the associating child policy
subject attachment point X and the attachment point Y (inheritance), and vice versa. Then the scope
of the attaching policy is Attachment point A, X, and Y, … (Case 1). In contrast, if we attach a policy
expression to a child policy attachment point, it affects to the parent policy attachment point (Case 2).
When we attach a policy expression to some point, we are required to see the policy scope.
9 Domain specific policy overview
Web services are developed two ways:
— Top-down approach, or
— Bottom-up approach.
The top-down approach starts with interface metadata and attaches QoS metadata to the interface
metadata.
The bottom-up approach starts from a production program to create interface metadata and QoS
metadata. Both metadata are used to evaluate a service from a technical viewpoint and if a service
consumer decides to use the service, he/she develops the program using the metadata. In this document,
only the top-down approach is considered. The standards for this are shown in Table 4.
Table 4 — Domain specific policy standards
a
Standardization domain Current standard
Web service security WS-SecurityPolicy 1.3
Reliable messaging Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.2
Sophisticated messaging Web Services Addressing 1.0 — Metadata
SOAP Message MTOM Serialization Policy Assertion 1.1
Transmission
Optimization
a
If a version number exists, e.g. “WS-SecurityPolicy 1.3”, it is the latest version.
NOTE Though the WS-Policy language supports the definition and use of user specific policy, it is out of the
scope of this document.
9.1 Messaging metadata (WS-Addressing metadata)
9.1.1 WS-Addressing standard
Table 5 summarises the standards related to WS-addressing:
Table 5 — WS-Addressing standards
Document URI (the first) and the
Standard name Description
schema location (the second)
http://www.w3.org/TR/ws-
Web Services Addressing Definition of abstract WS-Addressing
addr-core/
1.0 — Core (2006-05-09) information items.
http://www.w3.org/2005/08/
addressing.xsd
http://www.w3.org/TR/ws-
Web Services Addressing WS-Addressing information item's map-
addr-soap/
1.0 — SOAP Binding (2006- ping to SOAP
05-09)
The schema is included in
the upper one.
http://www.w3.org/
Web Service Addressing 1.0 — Definition of how to include abstract
TR/2007/REC-ws-addr-
Metadata (2007-09-04) WS-Addressing information in WSDL (1)
metadata-20070904/
http://www.w3.org/2007/05/
addressing/metadata.xsd
Test tool Document URI
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/
Web Services Addressing 1.0
testsuite/Overview.html?content-type=text/html;%20
Test Suite
charset=iso-8859-1
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/
Web Services Addressing 1.0
testsuitewsdl/Overview.html?content-type=text/html;%20
Metadata Test Suite
charset=iso-8859-1
Note that Old "Web Services Addressing 1.0 — WSDL Binding" is replaced by the new "WS Addressing
1.0 — Metadata". However, some software vendors still support this old version, which can cause
confusion.
NOTE In the Web Service Addressing 1.0 — Metadata, terms are based on WSDL 2.0. Therefore, when using
WSDL 1.1 rewording the WSDL 2.0 based terms to the WSDL 1.1 terms: Endpoint ⇒ wsdl:port,
InterfaceName ⇒ wsdl:portType, and ServiceName ⇒ wsdl:se
...