D6 – STANDARDISATION ROADMAP, VERSION 1.0 TRUSTCOM – 01945 25/10/2018

Deliverable

6


Deliverable datasheet

Project acronym: TrustCoM

Project full title: A trust and Contract Management framework enabling secure collaborative business processing in on-demand created, self-managed, scalable, and highly dynamic Virtual Organisations

Action Line:4

Activity:4.1

Work Package:13

Task:13.1

Document title:Standardisation Roadmap, version 1.0

Version:1.0

Document reference:

Official delivery date:31 July 2004

Actual publication date:

File name:

Type of document:Deliverable

Nature:Public

Authors:David Chadwick (UoS), Joris Claessens (EMIC), Theo Dimitrakos (CCLRC), Tomás Garcia (AtosOrigin), Christian Geuer-Pollmann (EMIC), Pablo Giambiagi (SICS), Jochen Haller (SAP), Paul Kearney (BT), Philip Robinson (SAP), Santi Ristol (AtosOrigin), Babak Sadighi (SICS), J Sairamesh (IBM), Ketil Stølen (SINTEF), Maroun Touma (IBM), Stefan Wesner [HLRS], Michael Wilson (CCLRC).

Reviewers:Olle Olsson (SICS),
Ketil Stølen (SINTEF),
Michael Wilson (CCLRC)

Approved by:

Version / Date / Sections Affected
1.0 / August 2004 / First published version of the Standardisation Roadmap.

Table of Content

1Executive summary

2Introduction

2.1TrustCoM standardisation objectives

2.2Scope and outline of this deliverable

3TrustCoM standardisation approach

3.1The concept of “Standard”

3.1.1Role of “standards”

3.1.2Different notions of “standard”

3.1.3Standards relevant to TrustCoM

3.2Standardisation contributions

3.2.1Profiles

3.2.2New contributions in specific areas

3.2.3Adaptations of existing standards

3.2.4Dissemination of TrustCoM results within standardisation initiatives

3.3Standards team

3.3.1Mission and activities

3.3.2Standardisation Manager

3.3.3Standardisation Champions

3.3.4Standardisation Contacts

3.4Liaisons with other projects and initiatives

3.4.1COPRAS

3.4.2ATHENA

3.4.3Other projects and initiatives

4First assessment TrustCoM related standards

4.1Trust, PMI and PKI

4.1.1Existing standards

4.1.2Potential contributions

4.2Contracts and SLAs

4.2.1Existing standards

4.2.2Potential contributions

4.3Policies and Security

4.3.1Existing standards

4.3.2Potential contributions

4.4Collaborative business processes

4.4.1Existing standards

4.4.2Potential contributions

4.5Web and Grid Services

4.5.1Existing standards

4.5.2Potential contributions

4.6Semantic technologies

4.6.1Existing standards

4.6.2Potential contributions

4.7Model driven security

4.7.1Existing standards

4.7.2Potential contributions

4.8Summary – relevant standardisation bodies

5Relevant standardisation bodies

5.1W3C

5.1.1W3C’s Mission

5.1.2W3C’s Goals

5.1.3W3C’s Role

5.1.4W3C’s Organization

5.1.5W3C’s operational structure

5.1.6W3C’s standardisation process and timescales

5.2OASIS

5.3“IBM/Microsoft”

5.4WS-I

5.5Liberty Alliance

5.6GGF

5.7OMG

5.8IETF

5.9ISO

5.10Ecma International

5.11UN/CEFACT

5.11.1UN/CEFACT structure

5.11.2UN/CEFACT Mission and objectives

5.11.3UN/CEFACT relevant standards

5.12Internet2

5.13Industry/domain-specific initiatives

6Appendix: standardisation activities of TrustCoM partners

6.1Atos Origin

6.2BT

6.3CCLRC

6.4EMIC

6.5HLRS

6.6IBM

6.7SAP

6.8SICS

6.9SINTEF

6.10UoS

1Executive summary

The TrustCoM project is developing a framework for trust, security, and contract management, for secure, collaborative business processing and resource sharing in dynamically-evolving Virtual Organisations. TrustCoM is committed to the adoption of open standards, and intends to build upon and extend interoperability specifications where possible.

This deliverable is made available at the end of the project’s initial scoping and requirements phase, and establishes a first baseline for further standardisation activities supporting this commitment. As such it is the initial version of the project’s Standardisation Roadmap. The Standardisation Roadmap will be regularly updated throughout the lifetime of the project, and supports and documents the standardisation activities within the TrustCoM project.

As part of the initial scoping and requirements phase, this initial version of the Standardisation Roadmap focuses on the identification of the areas for standardisation which are relevant to the project. It provides an assessment of the state of standardisation in each of these areas, including a preliminary identification of potential standardisation contributions, and maps this assessment to the relevant standardisation bodies and initiatives. In addition, the deliverable outlines the nature and management of further standardisation activities in the context of the project, and gives an overview of the related standardisation activities of the individual partners in the project.

We have defined seven research and technical development areas relevant to TrustCoM, each of which having one or two standardisation champions. These areas are: Trust, PMI and PKI; Contracts and SLAs; Policies and Security; Collaborative Business Processes; Web and Grid Services; Semantic technologies; and Model Driven Security. The first four areas map to the functional and implementation aspects of a framework for trust, contracts, and security, for collaborative business processing in VOs. The fifth and sixth areas include the technologies which this framework should build upon. The seventh and last area addresses the design and development aspects of the TrustCoM framework. A detailed overview of the technologies in each area is given in Deliverable 3 State of the Art Evaluation. This deliverable already gives a preliminary list of potential contributions in each of these areas, although an analysis of how these technologies can be adapted and contribute to the project is ongoing. Further refinement and especially selection will be carried out in order to focus our efforts.

It is important to emphasise that TrustCoM is an integrated project addressing trust, security, and contract management, for collaborative business processing, as a whole, focusing on the relationships and interactions between, and integration of, these issues, rather than investigating each of these issues separately and independently. In addition to standardisation contributions within individual areas, the starting focus and most immediate result of the TrustCoM standardisation activity is expected to be in the creation of profiles that integrate existing standards across the different areas. While there are already numerous specifications addressing various issues within most of the identified areas, there are almost no concrete guidelines at all with respect to combining different specifications into a single interoperable framework.

The TrustCoM standardisation activities are managed and supported by the standards team that is responsible for the definition and orchestration of a standardisation strategy for TrustCoM. The mission of the standards team is to monitor the emergence and further evolution of relevant standards for TrustCoM, to identify standardisation opportunities, to evaluate the readiness of technologies/ideas developed in the project, to assess the overall benefit of bringing them to standardisation, and finally to orchestrate submissions to suitable standardisation organisations. To initiate and materialise this, the standardisation activities also include dissemination of intermediate project results and proposals of potential standardisation contributions, within the appropriate bodies as well as standardisation-related initiatives and projects, in order to gather feedback. Project results and potential standardisation impacts will also be disseminated within the individual partner organisations, in order to ensure continuation of started standardisation contributions beyond the life-time and scope of the project.

2Introduction

The TrustCoM project [ will develop a framework for trust, security, and contract management, for secure, collaborative business processing and resource sharing in dynamically-evolving Virtual Organisations. TrustCoM is committed to the adoption of open standards, and intends to liaise closely with the relevant industry and standardisation forums, in order to ensure that the TrustCoM framework builds upon and extends existing and emerging interoperability standards. New specifications produced by TrustCoM are anticipated to be put forward as candidate standards where applicable.

The term “TrustCoM Framework” stands for the principles and paradigms, the processes and functions, and the architecture and the technology that underpin trustworthy, secure, and contract-driven operations of Virtual Organisations. However, when using the term “TrustCoM framework” in this deliverable, we mainly refer to the technological aspects, and how these are related to ICT standards and specifications. Other aspects of the TrustCoM framework, such as the socio-economic analysis, have less bearing on this workpackage.

2.1TrustCoM standardisation objectives

The achievement of the scientific and technological objectives of TrustCoM necessitates integration in several dimensions, including standards. The establishment of the WWW as the medium for distributing and processing information at a global scale has led to a proliferation of proprietary extensions of Web interoperability standards, sponsored by different consortia. In recognition of the fact that real interoperability is a prerequisite for secure collaborations in dynamic VOs, we will analyse and select existing / candidate open standards, and the software and systems engineering paradigms associated with them, as the basis for the TrustCoM framework specifications and reference implementation. Proposed improvements of these standards will be realised as interoperable extensions or revisions. Where no adequate candidate specifications exist, we intend to propose new standards, based on the TrustCoM framework specifications. Where applicable, we will bundle these together into interoperable “profiles”, similar to what is called “web service profiles”. These profiles should enable secure collaboration in dynamic VOs and contribute towards bridging the interoperability gap between current open standards. An important aspect is that the concept of profiles simplifies the specification, deployment and management of an integrated VO infrastructure, which builds upon, and glues together, many individual specifications.

TrustCoM is committed to the adoption of open standards, and will liaise closely with some of the main sponsors of Internet and Web standards (e.g., W3C, WS-Interoperability, OASIS, GGF, OMG) and other relevant government and industry forums in order to ensure that TrustCoM technological development and demonstration use and extend open interoperability standards. Furthermore, new specifications produced by TrustCoM will be put forward as candidate standards where applicable. TrustCoM aims to be a driving force in the evolution of “industrial strength” standards for secure collaboration, collaborative business processing, cross-enterprise contract management, and trust and security in cross-enterprise distributed systems and Grid Computing.

TrustCoM plays a significant role in testing and enhancing emerging standards and interoperability guidelines. The overall objectives of the TrustCoM standardisation activity are twofold:

  1. The standardisation activity must ensure that TrustCoM leverages the most up to date relevant standards and interoperability guidelines within its framework specifications and reference architecture. Existing / candidate open standards, and their associated software and systems engineering paradigms, will provide the basis for the applied research and technological development of TrustCoM.
  2. The standardisation activity must ensure that the results of TrustCoM contribute to the future developments of standards for trust, security and contract management, where necessary. Proposed improvements of these standards will be realised as interoperable extensions or revisions. TrustCoM will also be breaking ground in areas where no candidate specifications exist. In such areas, TrustCoM will propose new standards based on its Framework specifications, which are put forward to the appropriate technical committees for development and eventual ratification.

2.2Scope and outline of this deliverable

This deliverable constitutes the initial version of the project’s Standardisation Roadmap. The Standardisation Roadmap intends to support and document the standardisation activities within the TrustCoM project. It is a living document, and will be regularly updated throughout the lifetime of the project. This first version of the roadmap deliverable intends to establish an initial baseline for the further standardisation activities within the project.

The deliverable has essentially three parts. The first part (Sect. 3) briefly describes how the standardisation activities within TrustCoM are managed. The second part (Sect. 4) provides an initial assessment of the current state of standards that are relevant to TrustCoM. This assessment is based on the analysis performed, and still ongoing, within the project with respect to the suitability and potential gaps of the currently existing specifications. The third and final part (Sect. 5) gives a preliminary list of relevant standardisation forums, resulting from the first standardisation assessment. The appendix lists the current standardisation activities of the individual TrustCoM partners.

As mentioned above, this deliverable intends to establish an initial baseline for the standardisation activities within the project. Future releases of the standardisation roadmap will include further refinement, prioritisation, and selection of standardisation issues, which is needed in order to focus our efforts, and maximise our potential impact. Future releases of the roadmap will also report about potential past, ongoing, and envisaged concrete standardisation activities conducted by the project, and will outline further standardisation opportunities and directions in the context of trust, security, and contract management, for secure, collaborative business processing and resource sharing in dynamically-evolving Virtual Organisations.

3TrustCoM standardisation approach

This section briefly describes how the standardisation activities within TrustCoM are managed and supported. We first provide some background as to what TrustCoM considers as being a “standard”. We then give an outline of the TrustCoM standards team and its mission. Finally we describe potential other standardisation-related liaisons in addition to following-up and liaising with the relevant standardisation forums.

3.1The concept of “Standard”

3.1.1Role of “standards”

The main role of IT “standards” is to promote interoperability across different vendors' platforms. However, vendors are businesses who need to maintain competitive advantage through their own unique selling points. Therefore, successful standards are defined at a core layer in the information architecture below which most major vendors agree that the advantage of interoperability outweighs the need for competitive advantage.

As an example, for decades, character codes (i.e., ANSI X3.64 and later the Unicode character standards) have not provided competitive advantage and are now globally adopted and successful standards. More recently, document and data interchange formats have been standardised, as they no longer provide advantage. In some areas, such as computer graphics, even where individual formats have not yet been standardised, there are standards for the reference model, which defines the architecture in which they would exist.[1]

In the web and web services area, URL's, HTTP and XML are standardised, since the need for interoperability outweighs competitive advantage for these core technologies. The packaging technology of SOAP, and the Web Service Description Language (WSDL) are also examples of core technologies where the required functionality is agreed, and the need for interoperability outweighs the need for competitive advantage. In contrast, the directory language UDDI has been standardised since there is no clear need for competitive advantage, but there is no agreement in the community that it meets the required functionality.

Our initial assessment of the currently available standards relevant to TrustCoM – as outlined in Sect. 4 – reveals that higher up the stack there is no clear agreement on either the required functionality or the need for competitive advantage. Between 2001 and 2004 there have been about a dozen proposed web service composition languages from various vendors (e.g. WS-FL from IBM, CS-WS and WSCI from BEA, OMI from HP and WebMethods). One of these, BPEL4WS, has become a de facto standard and its authorship was agreed by several major vendors (i.e. IBM, Microsoft, SAP, BEA and Siebel), therefore making it a vendor group consortium recommendation. It has not passed through any de jure standardisation process though. There are also other composition languages which provide different functionality that are created by institutionalised standardisation consortia organisations (e.g. web services choreography description language (WS-CDL) - There is no agreement yet on the required functionality of these languages, or exactly on what should be standardised to maintain the competitive advantage. There are two possible arguments for this, which need to be balanced. On the one hand, for management and IT consultancy businesses, it is believed that the method of business process analysis, description and automation is where the competitive advantage lies today. On the other hand, a means to provide commonly agreed standards for trustworthy business process integration enables a competitive open market in the area (through supporting the ability to integrate processes developed using tools from different vendors in multi-organisational scenarios), and potentially increases the revenue of the stakeholders. What is clear is that in 2004, this is as high up in the architectural stack (see also Figure 2) as the balance between agreed functionality, business advantage and the need for interoperability has got.

3.1.2Different notions of “standard”

The term “standard” can cover different notions, ranging from a public specification issued by a set of companies, to a ‘real’ standard issued by a recognized standardisation body. We can distinguish between the following types of “standards”:

  1. De facto standards - a technology that is used by a vast majority of the users of a function. It may for example be in a product from a single supplier that dominates the market; or it may be a patented technology that is used in a range of products under license; etc. A de facto standard may be embraced by a standardisation initiative, and eventually become a consortium recommendation, or a de jure standard. The important thing is that it is very widely used, meets the needs for functionality, and supports interoperability. Products incorporating the technology must be widely adopted before something can be a de facto standard, so even though releases from research labs, or technologies in products may have strong early adoption they should not be called de facto standards, as they will not necessarily be adopted by a long-term stable community.
  2. De jure standards - standards from entities with a legal status in international or national law such the ISO, national standards bodies (e.g. BSI in the UK, ANSI in the US) or continental standards (e.g. European standards). These are strong in the health and safety related areas, in business quality measures and in long term IT areas. In IT these standards do not have to be implemented, or ever used; they just have to be agreed by the appropriate committee procedure - which can take many years.
  3. Consortium recommendations - Groups of companies agree that a technology is recommended by them to fulfil some functionality. This third type is a problematic one since the range of industrial consortia is so large, that the consensus behind the standard and its adoption can vary enormously. Such consortia vary in size from groups of a few large manufacturers (e.g. Microsoft, IBM and BEA), through OASIS and W3C to IETF. They also vary in the time it takes to establish a recommendation and the consensus that is behind it.[2]

For clarity, one can further divide the latter category into the following subcategories distinguishing between the formality (e.g. institutionalised or not) and rigour (e.g. public review, interoperability requirement test, etc.) of the process of producing a recommendation: