ISO 15000-2:2021

Electronic business eXtensible Markup Language (ebXML) — Part 2: Applicability Statement (AS) profile of ebXML messaging service

This document describes the AS4 Profile, which provides a subset of the functionality of ISO 15000‑1:2021, along with implementation guidelines based on the "just-enough" design principles and electronic data interchange functional requirements to trim down ISO 15000-1:2021 into a more simplified specification for web services business-to-business messaging. It specifies: - three conformance profiles of ISO 15000-1:2021 (see Clause 4); - a number of AS4 additional features (see Clause 5); - complementary requirements for the AS4 multi-hop profile (see Clause 6); - AS4 usage profile of ISO 15000-1:2021 (see Clause 7); - definitions of conformance (see Clause 8). Annex A provides some sample messages to support implementation. Annex B provides a sample XSLT stylesheet to generate an AS4 receipt. This document is applicable to all types of organizations (e.g., commercial enterprises, government agencies, not-for-profit organizations) that exchange documents or data electronically using messaging.

Commerce électronique en langage de balisage extensible (ebXML) — Partie 2: Titre manque

General Information

• Status: Published
• Publication Date: 14-Feb-2021
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/TC 154 - Processes, data elements and documents in commerce, industry and administration
• Drafting Committee: ISO/TC 154 - Processes, data elements and documents in commerce, industry and administration
• Current Stage: 6060 - International Standard published
• Start Date: 15-Feb-2021
• Due Date: 12-Feb-2022
• Completion Date: 15-Feb-2021

Relations

• Consolidated By: ISO 29481-2:2025 - Building information models — Information delivery manual — Part 2: Interaction framework
• Effective Date: 16-Dec-2023

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 15000-2
First edition
2021-02
Electronic business eXtensible
Markup Language (ebXML) —
Part 2:
Applicability Statement (AS) profile of
ebXML messaging service
Reference number
©
ISO 2021
© ISO 2021
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents
Foreword . vi
Introduction . vii
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 4
4 AS4 conformance profiles for ISO 15000-1:2021 . 5
4.1 General . 5
4.2 The AS4 ebHandler conformance profile . 5
4.2.1 General . 5
4.2.2 Feature set . 5
4.2.3 WS-I conformance profiles . 8
4.2.4 Processing mode parameters . 8
4.3 The AS4 light client conformance profile . 10
4.3.1 General . 10
4.3.2 Feature set . 11
4.3.3 WS-I conformance requirements . 13
4.3.4 Processing mode parameters . 13
4.4 The AS4 minimal client conformance profile . 15
4.4.1 General . 15
4.4.2 Feature set . 15
4.4.3 WS-I conformance requirements . 16
4.4.4 Processing mode parameters . 18
4.5 Conformance profiles compatibility . 19
5 AS4 additional features . 21
5.1 General . 21
5.2 Compression . 21
5.3 Reception awareness features and duplicate detection . 23
5.4 Alternative pull authorization . 24
5.5 Semantics of receipt in AS4 . 24
5.6 Sub-channels for message pulling . 25
5.7 Additional features errors . 26
6 Complementary requirements for the AS4 multi-hop profile . 27
6.1 General . 27
6.2 Rationale and context . 27
6.3 General constraints . 28
6.4 Processing mode parameter . 29
6.5 AS4 endpoint requirements . 29
7 AS4 usage profile of ISO 15000-1 . 31
7.1 General . 31
7.2 AS4 usage rules . 31
7.2.1 Core components / modules to be used. 31
7.2.2 Bundling rules . 32
7.2.3 Security element . 33
7.2.4 Signing messages . 33
7.2.5 Signing SOAP with attachments messages . 34
7.2.6 Encrypting messages . 34
7.2.7 Encrypting SOAP with attachments messages . 35
7.2.8 Generating receipts . 35
7.2.9 MIME header and filename information . 37
7.3 AS4 usage agreements . 37
7.3.1 General . 37
7.3.2 AS4 usage agreement parameters . 37
7.3.3 Controlling content and sending of receipts . 37
7.3.4 Error handling options . 38
7.3.5 Securing the pull request . 39
7.3.6 Reception awareness parameters . 41
7.3.7 Default values of some P-Mode parameters . 41
7.3.8 HTTP confidentiality and security. 42
7.3.9 Deployment and processing requirements for CPAs . 43
7.3.10 Message payload and flow profile . 43
7.3.11 Additional deployment or operational requirements . 44
8 Conformance statements . 45
8.1 General . 45
8.2 AS4 ebHandler conformance . 45
8.3 AS4 light client conformance. 45
8.4 AS4 minimal client conformance . 46
8.5 AS4 minimal sender conformance . 46
8.6 AS2/AS4 ebHandler conformance . 46
8.7 AS4 multi-hop endpoint conformance . 46
iv © ISO 2021 – All rights reserved

Annex A (informative) Sample messages. 47
Annex B (informative) Generating an AS4 receipt . 52
Bibliography . 55

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 the OASIS ebXML Messaging Services Technical Committee (as “OASIS
AS4 Profile of ebMS 3.0 Version 1.0”) and drafted in accordance with its editorial rules. It was assigned
to Technical Committee ISO/TC 154, Processes, data elements and documents in commerce, industry and
administration and adopted under the "fast-track procedure".
A list of all parts in the ISO 15000 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.

vi © ISO 2021 – All rights reserved

Introduction
Historically, the platform for mission-critical business-to-business (B2B) transactions has steadily
moved from proprietary value-added networks (VANs) to Internet-based protocols free from the data
transfer fees imposed by the VAN operators. This trend has been accelerated by lower costs and product
ownership, a maturing of technology, internationalization, widespread interoperability, and
marketplace momentum. The exchange of electronic data interchange (EDI) business documents over
the Internet has substantially increased along with a growing presence of extensible markup language
(XML) and other document types such as binary and text files.
The Internet messaging services standards that have emerged provide a variety of options for end users
to consider when deciding which standard to adopt. These include pre-Internet protocols, the EDIINT
series of IETF RFC 3355 AS1, IETF RFC 4130 AS2 and IETF RFC 4823 AS3, simple XML over hypertext
transport protocol (HTTP), government specific frameworks, OASIS ebXML messaging (ebMS) 2.0, and
web services variants. As Internet messaging services standards have matured, new standards are
emerging that leverage prior B2B messaging services knowledge for applicability to web services
messaging.
The emergence of the OASIS ebMS 3.0 Standard, now ISO 15000-1:2021, represents a leap forward in
Web Services B2B messaging services by meeting the challenge of composing many web services
standards into a single comprehensive specification for defining the secure and reliable exchange of
documents using web services. ISO 15000-1:2021 composes the fundamental web services standards
W3C SOAP 1.1, W3C SOAP 1.2, W3C SOAP with Attachments, OASIS WS-Security 1.0 and 1.1, W3C WS-
Addressing, and the OASIS reliable messaging standards WS-Reliability 1.1 and WS-ReliableMessaging -
currently at version 1.2, together with guidance for the packaging of messages and receipts along with
definitions of messaging choreographies for orchestrating document exchanges.
Like AS2, ISO 15000-1:2021 brings together many existing standards that govern the packaging,
security, and transport of electronic data under the umbrella of a single specification document. While
ISO 15000-1:2021 represents a leap forward in reducing the complexity of web services B2B messaging,
the specification still contains numerous options and comprehensive alternatives for addressing a
variety of scenarios for exchanging data over a web services platform.
In order to fully take advantage of the AS2 success story, this profile of ISO 15000-1:2021 has been
developed. Using ISO 15000-1:2021 as a base, a subset of functionality has been defined along with
implementation guidelines adopted based on the “just-enough” design principles and AS2 functional
requirements to trim down ISO 15000-1:2021 into a more simplified and AS2-like specification for web
services B2B messaging. The main benefits of AS4 compared to AS2 are:
● compatibility with web services standards;
● message pulling capability;
● a built-in receipt mechanism.
AS4 also provides a minimal client conformance profile that supports data exchanges that have lower-
end requirements and do not require (the equivalent of) some of the more advanced capabilities of AS2
and ISO 15000-1:2021, such as support for multiple payloads, message receipts and signing or
encryption of messages and receipts.
Profiling ISO 15000-1:2021 means:
● defining a subset of ISO 15000-1:2021 options to be supported by the AS4 handler;
● deciding which types of message exchanges shall be supported, and how these exchanges should
be conducted (level of security, binding to HTTP, etc.);
● deciding of AS4-specific message contents and practices (how to make use of the ebMS message
header fields, in an AS4 context);
● deciding of some operational best practices, for the end-user.
The overall goal of a profile for a standard is to ensure interoperability by:
● establishing particular usage and practices of the standard within a community of users;
● defining the subset of features in this document that needs to be supported by an
implementation.
Two kinds of profiles are usually considered when profiling an existing standard:
1. Conformance profiles. These define the different ways a product can conform to a standard,
based on specific ways to implement this document. A conformance profile is usually associated
with a specific conformance statement. Conformance profiles are of prime interest for product
managers and developers: they define a precise subset of features to be supported.
2. Usage profiles (also called deployment profiles). These define how a standard should be used
by a community of users, in order to ensure best compatibility with business practices and
interoperability. Usage profiles are of prime interest for IT end-users: they define how to
configure the use of a standard (and related product) as well as how to bind this document to
business applications. A usage profile usually points at required or compatible conformance
profile(s).
AS4 is defined as a combination of:
● three primary AS4 conformance profiles (see Clause 4) that define three subsets of
ISO 15000-1:2021 features, at least one of which is to be supported by an AS4 implementation;
● a set of additional features (see Clause 5);
● an optional complementary conformance profile (see Clause 6) that specifies how to use AS4
endpoints with ISO 15000-1:2021 intermediaries. This is based on a simplified subset of the
multi-hop messaging feature defined in the ebMS 3.0 Part 2, Advanced Features specification;
● an AS4 usage profile (see Clause 7) that defines how to use an AS4-compliant implementation in
order to achieve similar functions as specified in AS2.
The three primary AS4 conformance profiles (CP) are the following:
(1) The AS4 ebHandler CP. This conformance profile supports both sending and receiving roles,
and for each role both message pushing and message pulling;
(2) The AS4 light client CP. This conformance profile supports both sending and receiving roles,
but only message pushing for sending and message pulling for receiving. In other words, it does
not support incoming HTTP requests, and may have no fixed IP address.
viii © ISO 2021 – All rights reserved

(3) The AS4 minimal client CP. Like the light client CP, this conformance profile does not support
the push transport channel binding for the receiving role and therefore does not require HTTP
server capabilities. As its name indicates, this CP omits all but a minimal set of features.
Compatible existing conformance profiles for ISO 15000-1:2021 are the following:
● Gateway RM V3 or Gateway RX V3: a message service handler (MSH) implementing any of these
profiles will also be conforming to the AS4 ebHandler CP (the reverse is not true).
Full compliance to AS4 actually requires and/or authorizes a message handler to implement a
few additional features beyond these conformance profiles, as described in clause 8. These
additional features are described in Clause 5.
INTERNATIONALE STANDARD ISO 15000-2:2021(E)

Electronic business eXtensible Markup Language
(ebXML) —
Part 2:
Applicability Statement (AS) profile of ebXML messaging
service
1 Scope
This document describes the AS4 Profile, which provides a subset of the functionality of
ISO 15000-1:2021, along with implementation guidelines based on the “just-enough” design principles
and electronic data interchange functional requirements to trim down ISO 15000-1:2021 into a more
simplified specification for web services business-to-business messaging.
It specifies:
- three conformance profiles of ISO 15000-1:2021 (see Clause 4);
- a number of AS4 additional features (see Clause 5);
- complementary requirements for the AS4 multi-hop profile (see Clause 6);
- AS4 usage profile of ISO 15000-1:2021 (see Clause 7);
- definitions of conformance (see Clause 8).
Annex A provides some sample messages to support implementation.
Annex B provides a sample XSLT stylesheet to generate an AS4 receipt.
This document is applicable to all types of organizations (e.g., commercial enterprises, government
agencies, not-for-profit organizations) that exchange documents or data electronically using messaging.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 15000-1:2021. Electronic business eXtensible Markup Language (ebXML) — Part 1: Messaging Service
3.0 Core Specification.
INTERNET ENGINEERING TASK FORCE (IETF). RFC 1952. GZIP file format specification version 4.3. IETF
RFC. May 1996. http://tools.ietf.org/html/rfc1952
INTERNET ENGINEERING TASK FORCE (IETF). RFC 2045. Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies. IETF RFC. November 1996.
http://www.ietf.org/rfc/rfc2045.txt
INTERNET ENGINEERING TASK FORCE (IETF). RFC 2616. Hypertext Transfer Protocol — HTTP/1.1. IETF
RFC. June 1999. Available from http://www.ietf.org/rfc/rfc2616.txt
OASIS. OASIS ebXML Business Signals Schema, 21 December 2006. OASIS Standard. http://docs.oasis-
open.org/ebxml-bp/ebbp-signals-2.0
OASIS. OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features. Committee Specification
01, 19 May 2011. OASIS committee specification. Available at http://docs.oasis-open.org/ebxml-
msg/ebms/v3.0/part2/201004/ebms-v3-part2.odt
OASIS. Web Services Security: SOAP Message Security 1.1. OASIS Standard incorporating Approved Errata.
1 November 2006. Available from http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-os-
SOAPMessageSecurity.pdf
OASIS. Web Services Security UsernameToken Profile 1.1. OASIS Standard. 1 February 2006. Available
from http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf.
OASIS. Web Services Security X.509 Certificate Token Profile 1.1. OASIS Standard incorporating Approved
Errata. 1 November 2006. Available from http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-errata-
os-x509TokenProfile.pdf
WEB SERVICES INTEROPERABILITY ORGANIZATION. WS-I Attachments Profile Version 1.0, WS-I Final
Material. 20 April 2004. Available from http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html
WEB SERVICES INTEROPERABILITY ORGANIZATION. Basic Profile Version 2.0, WS-I Final Material. 9
November 2010. Available from http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html
WEB SERVICES INTEROPERABILITY ORGANIZATION. Basic Security Profile Version 1.1, WS-I Final Mate-
rial. 24 January 2010. Available from http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html
WORLD WIDE WEB CONSORTIUM (W3C). SOAP Version 1.2 Part 1: Messaging Framework. W3C Recom-
mendation. 27 April 2007. Available from http://www.w3.org/TR/soap12-part1/
WORLD WIDE WEB CONSORTIUM (W3C). SOAP Messages with Attachments, W3C Note. 11 December
2000. Available from http://www.w3.org/TR/SOAP-attachments
WORLD WIDE WEB CONSORTIUM (W3C). Web Services Addressing 1.0 – Core. W3C Recommendation. 9
May 2006. Available from http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
2 © ISO 2021 – All rights reserved

WORLD WIDE WEB CONSORTIUM (W3C). Extensible Markup Language (XML) 1.0. W3C Recommenda-
tion 26 November 2008. Available from http://www.w3.org/TR/REC-xml/
WORLD WIDE WEB CONSORTIUM (W3C). XML Signature Syntax and Processing (Second Edition). W3C
Recommendation. 10 June 2008. Available from http://www.w3.org/TR/xmldsig-core/
WORLD WIDE WEB CONSORTIUM (W3C). XML Encryption Syntax and Processing. 10 December, 2002.
Available from http://www.w3.org/TR/xmlenc-core/
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 15000-1:2021 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/
4 © ISO 2021 – All rights reserved

4 AS4 conformance profiles for ISO 15000-1:2021
4.1 General
AS4 is more than a conformance profile, in the sense given in the OASIS ebXML Messaging Services,
Version 3.0: Conformance Profiles OASIS committee specification. It is a combination of a conformance
profile and a usage profile, as explained in the Introduction. Consequently, only this clause is conforming
to the format recommended in the OASIS ebXML Messaging Services, Version 3.0: Conformance Profiles
OASIS committee specification for describing conformance profiles. The usage profile part (clause 7) is
following a format based on tables similar to those found in the OASIS Deployment Profile Template for
OASIS ebXML Message Service 2.0 Standard.
4.2 The AS4 ebHandler conformance profile
4.2.1 General
The AS4 ebHandler conformance profile addresses common functional requirements of e-Business/e-
Government gateways. It is identified by the URI:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4ebhandler
NOTE: this URI is only an identifier, not a document address.
4.2.2 Feature set
The AS4 CP is defined in Table 1, using the table template and terminology provided in Annex G
(“Conformance”) of ISO 15000-1:2021
Conformance Profile summary: <“Sending+Receiving” / “AS4 ebHandler” /
profile: Level 1 / HTTP 1.1 + SOAP 1.2 + WSS 1.1 >
AS4 ebHandler
Functional aspects Profile feature set
ebMS MEP The following ebMS simple message exchange patterns (MEPs) shall be supported both
as Initiating and Responding partner:
● One-way / push
● One-way / pull
This does not prevent an implementation to also support asynchronous two-way MEPs.
Regardless of which MEP is used, the sending of an eb:Receipt message shall be
supported:
● For the one-way / push, both “response” and “callback” reply patterns shall be
supported.
● For the one-way / pull, the “callback” pattern is the only viable option, and the
user message sender shall be ready to accept an eb:Receipt either
piggybacked on (or bundled with) an eb:PullRequest, or piggybacked on
another user Message, or sent separately.
In all MEPs, the user message receiver shall be able to send an eb:Receipt as a
separate message (i.e. not piggybacked on an eb:PullRequest message or on another
user message). An MSH conforming to this profile is therefore not required to bundle an
eb:Receipt with any other ebMS header or message body.
The ebbpsig:NonRepudiationInformation element as defined in the OASIS
ebXML Business Signals Schema, 21 December 2006 OASIS Standard shall be used as
content for the eb:Receipt message, i.e. when conforming to this profile a receiving
MSH shall be able to create an eb:Receipt with such a content, and a sending MSH
shall be able to process it.
Reliability Reception awareness, defined as the ability for a sending ebHandler to notify its
application (message producer) of lack of reception of an eb:Receipt related to a sent
message, shall be supported. This implies support for:
● correlating eb:Receipt elements with previously sent user messages, based
on the ebMS message identifier;
● detection of a missing eb:Receipt for a sent message;
● ability to report an error to the message producer in case no eb:Receipt has
been received for a sent message.
The semantics for sending back an eb:Receipt message is as follows: a well-formed
ebMS user message has been received and the MSH is taking responsibility for its
processing (additional application-level delivery semantics, and payload validation
semantics are not relevant).
Support for a WS reliable messaging specification is optional.
Security The following security features shall be supported:
● Support for the OASIS Web Services Security: SOAP Message Security 1.1. OASIS
Standard.
● Support for username / password token, digital signatures and encryption, as
specified in OASIS Web Services Security UsernameToken Profile 1.1, OASIS Web
Services Security X.509 Certificate Token Profile 1.1, and the W3C
Recommendations XML Signature Syntax and Processing and W3C XML
Encryption Syntax and Processing.
● Support for content-only transforms.
● Support for security of attachments.
● Support for message authorization at P-Mode level (see ISO a:—, 10.11)
Authorization of the Pull signal, for a particular MPC, shall be supported at
minimum.
● Transport-level secure protocols such as SSL or TLS.
Two authorization options shall be supported by an MSH in the receiving role, and at
least one of them in the sending role:
● Authorization Option 1: Use of the WSS security header targeted to the “ebms”
actor, as specified in clause 10.12 of ISO 15000-1, with the
wsse:UsernameToken profile. This header may either come in addition to the
regular wsse security header (XML signature for authentication), or may be the
sole wsse header, if a transport-level secure protocol such as SSL or TLS is used.
● Authorization Option 2: Use of a regular wsse security header, using XML
a
signature and X509 for authentication, and no additional wsse security header
targeted to “ebms”. In that case, the MSH shall be able to use the credential
present in this security header for Pull authorization, i.e. to associate these with
a specific MPC.
The use of transport-level secure protocols such as SSL or TLS is recommended.
6 © ISO 2021 – All rights reserved

Error generation and The following error processing capabilities shall be supported:
reporting
● Capability of the receiving MSH to report errors from message processing, either
as ebMS error messages or as SOAP faults to the sending MSH. The following
modes of reporting to a sending MSH are supported:
○ Sending error on the back channel of the underlying protocol
(ErrorHandling.Report.AsResponse="true").
○ Capability to report to a third-party address
(ErrorHandling.Report.ReceiverErrorsTo=).
● Capability of sending MSH to report generated errors as notifications to the
message producer (support for
Report.ProcessErrorNotifyProducer="true")(e.g. delivery failure).
● Generated errors: All specified errors in ISO 15000-1 shall be generated when
applicable, except for EBMS:0010: On a receiving MSH, there is no requirement
to generate error EBMS:0010 for discrepancies between message header and
the P-Mode.reliability and P-Mode.security features. A receiving MSH shall
generate such errors for other discrepancies.
Message partition Message partition channels (MPC) shall be supported in addition to the default channel,
channels so that selective pulling by a partner MSH is possible. This means AS4 handlers shall be
able to use the @mpc attribute and to process it as expected.
Message packaging The following features shall be supported both on sending and receiving sides:
● Support for attachments following IETF RFC 2045 and the W3C SOAP-with-
attachments recommendation.
● Support for message properties.
● Support for processing messages that contain both a signal message unit
(eb:SignalMessage) and a user message unit (eb:UserMessage) – this may
happen when a same ebMS message carries message units for different MEP
instances.
Per WS-I Basic Profile 2.0, at most one payload may be inserted as direct child element of
the SOAP Body.
Interoperability
The following interoperability parameters values shall be supported for this
Parameters
conformance profile:
● Transport: HTTP 1.1, conform IETF RFC 2616.
● SOAP version: 1.2, conform W3C SOAP Version 1.2 Part 1: Messaging Framework
W3C Recommendation.
● Reliability Specification: none.
● Security Specification: WSS 1.1 conform OASIS Web Services Security: SOAP
Message Security 1.1.
a
XML signature allows arbitrary XSLT transformations when constructing the plaintext over which a signature or
reference is created. Conforming applications that allow use of XSLT transformations when verifying either
signatures or references are encouraged to maintain lists of “safe” transformations for a given partner, service,
action and role combination. Static analysis of XSLT expressions with a human user audit is encouraged for
trusting a given expression as “safe”.
Table 1: AS4 ebHandler feature set
4.2.3 WS-I conformance profiles
The Web-Services Interoperability consortium has defined guidelines for interoperability of SOAP
messaging implementations. In order to ensure maximal interoperability across different SOAP stacks,
e.g. multipurpose Internet mail extensions (MIME) and HTTP implementations, implementations shall
comply with the following WS-I profiles whenever related features are used:
● WEB SERVICES INTEROPERABILITY ORGANIZATION. Basic Security Profile Version 1.1 Basic
Security Profile (BSP) 1.1.
● WEB SERVICES INTEROPERABILITY ORGANIZATION. WS-I Attachments Profile Version 1.0
Attachment Profile (AP) 1.0 with regard to the use of MIME and SOAP with Attachments.
NOTE 1: Compliance with AP1.0 would normally require compliance with BP1.1, which in turn requires the
absence of a SOAP envelope in the HTTP response of a One-Way MEP (R2714). However, recent BP versions such
as BP1.2 and BP2.0 override this requirement. Consequently, the AS4 ebHandler conformance profile does not
require conformance to these deprecated requirements inherited from BP1.1 (R2714, R1143) regarding the use of
HTTP.
NOTE 2: WS-I compliance is here understood as requiring that the features exhibited by an AS4 ebHandler shall
comply with these WS-I profiles. For example, since only SOAP 1.2 is required by the AS4 ebHandler, the
requirements from BSP 1.1 that depend on SOAP 1.1 would not apply. Similarly, none of the requirements for
DESCRIPTION (WSDL) or REGDATA (UDDI) apply here, as these are not used.
Implementations shall also conform to the following WS-I profile:
● WEB SERVICES INTEROPERABILITY ORGANIZATION. Basic Profile Version 2.0, Basic Profile 2.0
(BP2.0).
4.2.4 Processing mode parameters
General
This subclause contains a summary of P-Mode parameters relevant to AS4 features for this conformance
profile. An AS4 handler shall support and understand those that are mentioned as "required". For each
parameter, one the following situations applies:
• Full support is required: an implementation shall support the possible options for this
parameter.
• Partial support is required: support for a subset of values is required.
• No support is required: an implementation is not required to support the features controlled by
this parameter, and therefore is not required to understand this parameter.
An AS4 handler is expected to support the P-Mode set of section 4.2.4.2, both as a sender (of the user
message) and as a receiver.
General P-Mode parameters
● PMode.ID: support required.
● PMode.Agreement: support required.
8 © ISO 2021 – All rights reserved

● PMode.MEP: support required for: http://www.oasis-open.org/committees/ebxml-msg/one-
way
● PMode.MEPbinding: support required for: http://www.oasis-open.org/committees/ebxml-
msg/push and http://www.oasis-open.org/committees/ebxml-msg/pull.
● PMode.Initiator.Party: support required.
● PMode.Initiator.Role: support required.
● PMode.Initiator.Authorization.username and PMode.Initiator.Authorization.password:
support required for: wsse:UsernameToken.
● PMode.Responder.Party: support required.
● PMode.Responder.Role: support required.
● PMode.Responder.Authorization.username and
PMode.Responder.Authorization.password: support required for: wsse:UsernameToken.
PMode[1].Protocol
● PMode[1].Protocol.Address: support required for “http” protocol (IETF RFC 2616).
● PMode[1].Protocol.SOAPVersion: support required for the WORLD WIDE WEB CONSORTIUM
(W3C). SOAP Version 1.2 Part 1: Messaging Framework.
PMode[1].BusinessInfo
● PMode[1].BusinessInfo.Service: support required.
● PMode[1].BusinessInfo.Action: support required.
● PMode[1].BusinessInfo.Properties[]: support required.
● (PMode[1].BusinessInfo.PayloadProfile[]: support not required)
● (PMode[1].BusinessInfo.PayloadProfile.maxSize: support not required)
PMode[1].ErrorHandling
● (PMode[1].ErrorHandling.Report.SenderErrorsTo: support not required)
● PMode[1].ErrorHandling.Report.ReceiverErrorsTo: support required (for address of the
MSH sending the message in error or for third-party).
● PMode[1].ErrorHandling.Report.AsResponse: support required (true/false).
● (PMode[1].ErrorHandling.Report.ProcessErrorNotifyConsumer support not required)
● PMode[1].ErrorHandling.Report.ProcessErrorNotifyProducer: support required
(true/false)
● PMode[1].ErrorHandling.Report.DeliveryFailuresNotifyProducer: support required
(true/false)
PMode[1].Reliability
Support not required.
PMode[1].Security
● PMode[1].Security.WSSVersion: support required for: 1.1.
● PMode[1].Security.X509.Sign: support required.
● PMode[1].Security.X509.Signature.Certificate: support required.
● PMode[1].Security.X509.Signature.HashFunction: support required.
● PMode[1].Security.X509.Signature.Algorithm: support required.
● PMode[1].Security. X509.Encryption.Encrypt: support required.
● PMode[1].Security.X509.Encryption.Certificate: support required.
● PMode[1].Security.X509.Encryption.Algorithm: support required.
● (PMode[1].Security.X509.Encryption.MinimumStrength: support not required)
● PMode[1].Security.UsernameToken.username: support required.
● PMode[1].Security.UsernameToken.password: support required.
● PMode[1].Security.UsernameToken.Digest: support required (true/false)
● (PMode[1].Security.UsernameToken.Nonce: support not required)
● PMode[1].Security.UsernameToken.Created: support required.
● PMode[1].Security.PModeAuthorize: support required (true/false)
● PMode[1].Security.SendReceipt: support required (true/false)
● Pmode[1].Security.SendReceipt.ReplyPattern: support required (both “response” and
“callback”))
4.3 The AS4 light client conformance profile
4.3.1 General
The AS4 light client conformance profile addresses common functional requirements of e-Business/e-
Government light gateways. It is identified by the URI:
http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/cprofiles/200809/as4lightclient
10 © ISO 2021 – All rights reserved

NOTE: this URI is only an identifier, not a document address.
As indicated by its name, this profile applies only to one side of an MEP (acting as a “client” to the other
party). It is not required and often not even possible for two MSHs conforming to this profile to engage
in a point-to-point exchange. Indeed, at least one MSH shall be ready to receive an incoming HTTP
request in any MEP as defined in ebMS, but this profile does not require this capability. As a result, when
an MSH is conforming exclusively to this profile, it can only engage into point-to-point exchanges with
MSHs that conform to “more” than this profile – e.g. MSHs that conform to the ebHandler profile– in
order to be able to receive requests. Two light clients can also exchange messages using store-and-
forward ebMS3 intermediaries, as described in Clause 6.
4.3.2 Feature set
The AS4 light client feature set is described in Table 2.
Conformance Profile summary: <“Sending+Receiving” / “AS4 light client” /
profile: Level 1 / HTTP 1.1 + SOAP 1.2>
AS4 light client
Functional Profile feature set
aspects
The following message exchange patterns (MEPs) shall be supported as Initiating partner:
ebMS MEP
● One-way / push
● One-way / pull
This does not prevent an implementation to also support two-
...