OASIS Business Document Exchange Technical Committee

The official charter for this Technical Committee is provided below. (For additional information, see the Call for Participation that was issued when this TC was formed.)

The OASIS Business Document Exchange TC approved a revised charter on 19 April 2012. This page is the archived version of the original charter. The revised charter is here.

  1. Name of the TC:

    OASIS Business Document Exchange Technical Committee

  2. Statement of Purpose:

    The purpose of the TC is to define specifications for a lightweight and federated messaging infrastructure supporting a 4-corner model[1] for the secure and reliable exchange of electronic documents. Wherever possible, the TC specifications will be based on profiles of existing standards from OASIS and elsewhere.

    The TC does not intend to replace existing messaging service standards. Instead, it will provide a simplified model for the exchange of documents, based on profiles of existing messaging service standards, plus some additional necessary infrastructure.

    The foundation for the work will be the specifications developed as part of the PEPPOL[2] project, which provide the infrastructure for public eProcurement in Europe; however, the specifications will be designed for use with any business process. The TC intends to become the maintenance forum for interfaces implemented by the PEPPOL project and similar infrastructure initiatives.

  3. Scope of work of the TC:

    The primary objective of the TC is to specify an addressing mechanism that supports a 4-corner model. This addressing mechanism may be used with many transport protocols; however, initially the TC will focus on START/LIME and ebMS.

    The specific objectives will be to:

    1. Establish specifications for a lightweight and federated document transport infrastructure supporting the secure and reliable exchange of electronic business documents.
    2. Profile and maintain a robust, secure and lightweight addressing mechanism (SMLP) capable of exposing metadata about endpoints (including supported business processes, content standards, transport protocols, and security requirements) and capable of being operated in a highly distributed environment.
    3. Support the dynamic creation of connections based on look-up of services at runtime.
      1. Profile and maintain the START (Secure Trusted Asynchronous Reliable Transport) protocol. START is intended to be used as a transport profile between Service Providers in the 4-corner model.
      2. Profile and maintain the LIME (Lightweight Message Exchange) protocol, a secure and reliable lightweight messaging protocol. LIME is intended to be used as a transport profile between senders or receivers and their Service Providers in a 4-corner model.
    4. Profile and maintain the ebMS 3.0 protocol for use in the 4-corner model with SMLP.
    5. Give guidance on using other transports in a 4-corner model.
    6. Develop specifications that support service levels appropriate for large scale deployment.

    Out of scope:

    The TC will not profile synchronous end-to-end messaging protocols, as they are not appropriate in a 4-corner model of network interconnections. Nevertheless, the addressing mechanism should be equally suitable for synchronous and asynchronous exchanges and can therefore be used in synchronous scenarios not covered by the 4-corner model.

    End-to-end proof of delivery will not be covered by the TC, but proof of delivery between Service Providers is in scope.

    Authentication mechanisms between senders or receivers and their Service Provider will not be covered by the TC.

  4. List of deliverables:

    The TC will produce an integrated set of Committee Specifications including a set of XML Schemas and an XML-based request/response protocol for the exchange of documents.

    Committee Specifications will cover:

    1. BDEA (Business Document Exchange Architecture): A specification of a 4-corner model for the exchange of business documents.
    2. SMLP (Service Metadata Location and Publishing): A specification for a robust, secure, federated and lightweight addressing mechanism.
    3. START (Secure Trusted Asynchronous Reliable Transport): A profile of secure, trusted, asynchronous and reliable messaging.
    4. LIME (Lightweight Message Exchange): A profile of a secure and reliable, lightweight messaging protocol.
    5. A profile of ebMS (ebXML Message Service Specification) 3.0 for secure, trusted, asynchronous and reliable messaging with SMLP.
    6. Test and conformance suites aiding the development of interoperable implementations of the profiles.

    The first Committee Specifications will be based on the specifications made by the PEPPOL project (see http://www.peppol.eu/work_in_progress/wp8-Solutions%20architecture%2C%20design%20and%20validation/results/d8.2-version-1.0-of-the-peppol-infrastructure/d8.2-version-1.0-of-the-peppol-infrastructure).

    This will be the main focus of the first nine months. These specifications will be contributed to the TC by the specifications' owner.

    The TC intends that the Committee Specifications will become OASIS Standards.

    It is estimated that the delivery of an initial set of specifications will take one to two years.

    It is the goal that the first deliverables will be as follows:

    • March 2011: Committee Specification Drafts under OASIS namespaces based on PEPPOL specifications.
    • July 2011: Committee Specification Drafts for implementation by the PEPPOL project.
    • October 2011: Public review of Committee Specification Drafts
    • December 2011: Committee Specifications approved
    • March 2012: Committee Specifications become OASIS Standards
  5. IPR Mode under which the TC will operate:

    The TC will operate under the Non-Assertion Mode.

  6. The anticipated audience or users of the work:

    The initial target groups for the TC are

    1. Service providers and self-service providers (for example Value Added Network Operators, Banks, eProcurement solution providers etc).
    2. Software companies (e.g. suppliers of middleware and software platforms)
    3. Public institutions
    4. Large private companies
  7. Language of the Technical Committee:

    The business of the Technical Committee will be conducted in English.

[1] The 4-Corner Model

A document exchange process set-up whereby each Participant has contracted with one or several separate Service Providers, whereby the Service Providers ensure the correct interchange of documents between the Participants.

When senders and receivers of documents are supported by their own consolidator service provider (for the sender) and aggregator service provider (for the receiver), it is referred to as a 4-Corner model. A network usually based on open standards provides connectivity and the facilities for the secure trusted exchange of business documents. In the 4-Corner models, the consolidator and aggregator roles are often two different service providers.

Definition inspired from http://www.e-invoice-gateway.net/helpandsupport/glossary/

[2] The PEPPOL Project http://www.peppol.eu