FI-WARE Standardization Plan (D.11.4.a) · FI-WARE-12-03-12 -WARE activities. FI-WARE...

FI-WARE Standardization Plan

Topics addressed: Overview of related standardisation and planning of FI

Editor: Lindsay Frost

e-mail: [email protected]

WARE Standardization Plan(D.11.4.a) FI-WARE-12-03-12

Overview of related standardisation and planning of FI-WARE activities

[email protected]

WARE Standardization Plan

WARE activities

FI-WARE Standardisation Plan

Contract No.: 285248

Strategic Objective: FI.ICT-2011.1.7 Technology foundation: Future Internet Core Platform

Project Document Number: ICT

Project Document Date: 12 March 2012 (due 31 Jan 2012)

Deliverable Type and Security:

Abstract: This deliverable provides an overview of standardisation areas relevant to FIspecific aspects likely to be either

Keyword list: FI-WARE, PPP, Future Internet Core Platform/TechnologSDOs, Internet of Services, Open APIs, Open Standards

Copyright notice: 2012 Participants listed below of project FIStandardization Organisations referenced in the text ma

Participant Organisation Name

TELEFÓNICA INVESTIGACION Y DESARROLLOSAP AG IBM ISRAEL - SCIENCE AND TECHNOLOGY LTDIBM RESEARCH GMBH THALES COMMUNICATIONS SATELECOM ITALIA S.P.A. FRANCE TELECOM SA NOKIA SIEMENS NETWORKS GMBH & CO. KGNOKIA SIEMENS NETWORKS TELEKOMMUNIKACIOS KERESKEDELMI ES SZOLGALTATONOKIA SIEMENS NETWORKS OYDEUTSCHE TELEKOM AG TECHNICOLOR R&D FRANCE SNCERICSSON AB ATOS ORIGIN SOCIEDAD ANONIMA ESPAÑOLAENGINEERING - INGEGNERIA INFORMATICA SPAALCATEL-LUCENT ITALIA S.P.A.ALCATEL-LUCENT DEUTSCHLAND AGSIEMENS AG INTEL PERFORMANCE LEARNING SOLUTIONS LIMITED

NEC EUROPE LTD

FRAUNHOFER-GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V.INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUEUNIVERSIDAD POLITECNICA DE MADRIDUNIVERSITAET DUISBURG-UNIVERSITA DEGLI STUDI DI ROMA LA SPIENZA

UNIVERSITY OF SURREY

Project Details

2011.1.7 Technology foundation: Future Internet Core Platform

ICT-2012-FI-285248-WP11-D11.4.a

2 March 2012 (due 31 Jan 2012)

Deliverable Type and Security: Public

s deliverable provides an overview of standardisation areas relevant to FIspecific aspects likely to be either used within FI-WARE or contributed to by FI-WARE work

WARE, PPP, Future Internet Core Platform/Technology Foundation, Standardisation, SDOs, Internet of Services, Open APIs, Open Standards

2012 Participants listed below of project FI-WARE. In selected cases the Standardization Organisations referenced in the text may hold copyright on quoted material.

Participant Organisation Name Short Name

TELEFÓNICA INVESTIGACION Y DESARROLLO TID SAP

SCIENCE AND TECHNOLOGY LTD IBM-IL IBM-CH

COMMUNICATIONS SA THALES TI FT

NOKIA SIEMENS NETWORKS GMBH & CO. KG NSN-G NOKIA SIEMENS NETWORKS TELEKOMMUNIKACIOS KERESKEDELMI ES SZOLGALTATO

NSN-H

NOKIA SIEMENS NETWORKS OY NSN-FI DT

TECHNICOLOR R&D FRANCE SNC TRDF EAB

ATOS ORIGIN SOCIEDAD ANONIMA ESPAÑOLA ATOS INGEGNERIA INFORMATICA SPA ENG

LUCENT ITALIA S.P.A. ALU-I LUCENT DEUTSCHLAND AG ALU-D

SIEMENS INTEL PERFORMANCE LEARNING SOLUTIONS

INTEL

NEC

GESELLSCHAFT ZUR FOERDERUNG DER ANGEWANDTEN FORSCHUNG E.V.

FRAUNHOFER

INSTITUT NATIONAL DE RECHERCHE EN INFORMATIQUE ET EN AUTOMATIQUE

INRIA

UNIVERSIDAD POLITECNICA DE MADRID UPM -ESSEN UDE

UNIVERSITA DEGLI STUDI DI ROMA LA SPIENZA UNIROMA1

UNIS

2011.1.7 Technology foundation: Future Internet Core Platform

s deliverable provides an overview of standardisation areas relevant to FI-WARE and of WARE work-packages.

y Foundation, Standardisation,

WARE. In selected cases the y hold copyright on quoted material.

Short Name Country

SPAIN GERMANY ISRAEL SWITZERLAND FRANCE ITALY FRANCE GERMANY

HUNGARY

FINLAND GERMANY FRANCE SWEDEN SPAIN ITALY ITALY GERMANY GERMANY

IRELAND

UNITED KINGDOM

FRAUNHOFER GERMANY

FRANCE

SPAIN GERMANY

ITALY UNITED KINGDOM


1 INTRODUCTION ................................

2 WP STANDARDIZATION N

2.1 INTRODUCTION ................................

2.2 WP3 APPLICATION AND

2.2.1 OpenMashup Enterprise Mashup Markup Language2.2.2 OpenAjax Alliance Mashup Standards and Security2.2.3 W3C Web Applications Specification2.2.4 W3C Semantic Web Services2.2.5 OMG Business Process Model and Notation2.2.6 OMG Service Oriented Architecture2.2.7 OASIS Service Description and Discovery2.2.8 Open Group SOA Ontology2.2.9 DIN Publicly Available Specification 1018

2.3 WP4 CLOUD HOSTING ................................

2.3.1 DMTF ................................2.3.2 OGF ................................2.3.3 OpenStack ................................2.3.4 OASIS ................................2.3.5 W3C ................................2.3.6 SNIA ................................

2.4 WP5 INTERNET OF THINGS

2.4.1 ETSI TC M2M (Machine to Machine)2.4.2 OMA Next Generation Service Interface Context Management2.4.3 OGC Sensor Web Enablement2.4.4 ISO Sensor Network Reference Architecture

2.5 WP 6 DATA/CONTEXT M

2.5.1 OMA NGSI & Content Delivery2.5.2 W3C ................................2.5.3 ISO-JPEG/MPEG ................................

2.6 WP7 INTERFACE TO THE

2.6.1 W3C ................................2.6.2 WAC ................................2.6.3 OMA Device Management2.6.4 OpenFlow ................................2.6.5 IETF ................................2.6.6 3GPP and ETSI-TISPAN2.6.7 HGI ................................

2.7 WP8 SECURITY, PRIVACY

2.7.1 OASIS XACML1 ................................2.7.2 OASIS SAML1 ................................2.7.3 IETF OAuth1 ................................2.7.4 OpenID Foundation ................................2.7.5 OVAL ................................2.7.6 NIST Common Vulnerability Scoring System (CVSS)2.7.7 IETF Intrusion Detection2.7.8 NIST Remediation (Security Content Automation Protocol)

3 WP GAP ANALYSIS ................................

3.1 INTRODUCTION ................................


3.2.1 W3C Semantic Web Services3.2.2 OMG Service Oriented Architecture3.2.3 OASIS Service Description and Discovery

3.3 WP4 CLOUD HOSTING ................................


3.4.1 ETSI TC M2M ................................3.4.2 OMA NGSI ................................

3.5 WP 6 DATA/CONTEXT M


3.6.1 W3C ................................

Table of Contents

................................................................................................................................

WP STANDARDIZATION NEEDS ................................................................................................

................................................................................................................................

PPLICATION AND SERVICES ECOSYSTEM ................................................................

OpenMashup Enterprise Mashup Markup Language ................................................................OpenAjax Alliance Mashup Standards and Security ................................................................W3C Web Applications Specification ................................................................................................W3C Semantic Web Services ................................................................................................OMG Business Process Model and Notation................................................................OMG Service Oriented Architecture ................................................................................................OASIS Service Description and Discovery ................................................................................................Open Group SOA Ontology ................................................................................................DIN Publicly Available Specification 1018 ................................................................

................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................................................................................................................................................

HINGS SERVICE ENABLEMENT ................................................................

ETSI TC M2M (Machine to Machine) ................................................................................................OMA Next Generation Service Interface Context Management ................................................................

nablement ................................................................................................ISO Sensor Network Reference Architecture ................................................................

MANAGEMENT SERVICES ................................................................

OMA NGSI & Content Delivery ................................................................................................................................................................................................................................

................................................................................................................................NTERFACE TO THE NETWORK AND DEVICES ................................................................

................................................................................................................................................................................................................................................................

OMA Device Management ................................................................................................................................................................................................................................

................................................................................................................................TISPAN ................................................................................................

................................................................................................................................RIVACY, TRUST ................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................NIST Common Vulnerability Scoring System (CVSS) ................................................................

Detection Message Exchange Format (IDMEF) ................................................................NIST Remediation (Security Content Automation Protocol) ................................................................

................................................................................................

................................................................................................................................


W3C Semantic Web Services ................................................................................................OMG Service Oriented Architecture ................................................................................................OASIS Service Description and Discovery ................................................................................................

................................................................................................


................................................................................................................................................................................................................................................................

MANAGEMENT SERVICES ................................................................

NTERFACE TO THE NETWORK AND DEVICES ................................................................

................................................................................................................................

..................................................... 5

........................................................ 8

............................................................ 8 ......................................................................... 8

.................................................................. 8 ................................................................... 8

......................................................... 9 .................................................................... 10

............................................................................. 10 ......................................................... 10

............................................... 11 ...................................................................... 11

.............................................................................. 11

.............................................................................. 11 ........................................................................ 12

........................................................................... 12 ................................................................. 12

....................................................................... 12 .......................................................................... 12 ......................................................................... 13

................................................................. 13 ...................................................... 13

............................................... 13 .................................................................. 14

............................................................................ 15 ..................................................................... 16

............................................................... 16 .......................................................................... 16

...................................................... 16 .................................................................. 17

.......................................................................... 17 ......................................................................... 17 ........................................................................ 17

.................................................................. 18 .......................................................................... 18 .......................................................................... 18 ............................................................................ 18

............................................................ 19 ....................................................... 19

.......................................................... 19 ............................................................. 19

................................................... 19 ........................................................................ 20

............................................................. 20 ............................................... 20

.................................................... 20

.............................................................................. 22

.......................................................... 22 ....................................................................... 22 .................................................................... 22

......................................................... 22 ............................................... 22

.............................................................................. 22 ................................................................. 23

.......................................................... 23 ............................................................... 24

..................................................................... 24 .................................................................. 24

.......................................................................... 24


3.6.2 OMA Device Management3.6.3 HGI ................................


4 WP STRATEGY: STANDAR

4.1 INTRODUCTION ................................


4.3 WP4 CLOUD HOSTING ................................


4.5 WP6 DATA/CONTEXT SERVICES



4.8 SUMMARY TABLE OF WP,

5 ANNEX: RELEVANT STAN

5.1 3GPP ................................

5.1.1 Introduction ................................5.2 DMTF ................................

5.2.1 Cloud Incubator ................................5.3 ETSI ................................

5.3.1 Re-organisation of ETSI in progress5.3.2 ETSI TC GRID (TC CLOU5.3.3 ETSI TC M2M ................................5.3.4 ETSI TC TISPAN ................................5.3.5 ETSI TC SCP ................................

5.4 HGI (HOME GATEWAY

5.5 IEEE ................................

5.5.1 Introduction ................................5.6 IETF (INTERNET ENGINEERING

5.6.1 Introduction ................................5.6.2 IETF 6lowpan Working Group5.6.3 IETF Core Working Group5.6.4 IETF GEOPRIV Working Group5.6.5 IETF Light Weight Implementation Guidance5.6.6 IETF ROLL ................................5.6.7 IETF SIMPLE Working Group5.6.8 IETF IDMEF ................................

5.7 ISO/IEC JTC1................................

5.7.1 WG7 (Working Group on Sensor Net5.8 ITU-T ................................

5.8.1 Introduction ................................5.8.2 ITU-T Ubiquitous Senso

5.9 KANTARA INITIATIVE ................................

5.10 OASIS ................................

5.11 OGC (OPEN GEOSPATIAL

5.12 OGF (OPEN GRID FORUM

5.12.1 Introduction ................................5.12.2 OCCI (Open Cloud Computing Interface)5.12.3 OGF DCI-Fed (Distributed Compute Infrastructures

5.13 OMA ................................

5.13.1 Introduction ................................5.13.2 OMA Next Generation Service Interface

5.14 OSGI (OPEN SERVICES G

5.15 OPENAJAX ALLIANCE (G

5.16 OPEN MASHUP ALLIANCE

5.17 TELEMANAGEMENT FORUM

5.18 TNC (TRUSTED NETWORK

5.19 W3C ................................

5.19.1 Introduction ................................5.19.2 W3C HTML5 ................................5.19.3 W3C Geolocation API ................................5.19.4 W3C Semantic Sensor Network Incubator Group (SSN5.19.5 W3C Web Applications Working Group5.19.6 SSN-XG (Semantic Sensor Network Incubator Group)

5.20 WAC (WHOLESALE APPLICATION

5.21 NIST (NATIONAL INSTITUTE OF

A Device Management ................................................................................................................................................................................................................................

RIVACY, TRUST ................................................................................................

WP STRATEGY: STANDARDIZATION PLAN BY WORK PACKAGE ................................

................................................................................................................................


................................................................................................


ERVICES ................................................................................................

NTERFACE TO THE NETWORK AND DEVICES ................................................................

RIVACY, TRUST ................................................................................................

WP, SDO, PARTNER COMMENTS ................................................................

ANNEX: RELEVANT STANDARDIZATION BODIES ................................................................

................................................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................................................................................................................................................

organisation of ETSI in progress ................................................................................................ETSI TC GRID (TC CLOUD) ................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................ATEWAY INITIATIVE) ................................................................................................

................................................................................................................................

................................................................................................................................NGINEERING TASK FORCE) ................................................................

................................................................................................................................TF 6lowpan Working Group ................................................................................................

IETF Core Working Group................................................................................................IETF GEOPRIV Working Group ................................................................................................IETF Light Weight Implementation Guidance ................................................................

................................................................................................................................IETF SIMPLE Working Group ................................................................................................

................................................................................................................................................................................................................................................................

WG7 (Working Group on Sensor Networks) ................................................................................................................................................................................................

................................................................................................................................T Ubiquitous Sensor Networks ................................................................................................

................................................................................................................................

................................................................................................................................

PATIAL CONSORTIUM) ................................................................................................

ORUM) ................................................................................................

................................................................................................................................OCCI (Open Cloud Computing Interface) ................................................................................................

Fed (Distributed Compute Infrastructures – Federated) ................................................................................................................................................................

................................................................................................................................OMA Next Generation Service Interface ................................................................................................

GATEWAY INITIATIVE ALLIANCE) ................................................................

(GADGETS TASK FORCE) ................................................................

LLIANCE ................................................................................................

ORUM / IPSPHERE FRAMEWORK ................................................................

ETWORK CONNECT) ................................................................................................

................................................................................................................................

................................................................................................................................................................................................................................................................

................................................................................................................................W3C Semantic Sensor Network Incubator Group (SSN-XG) ................................................................W3C Web Applications Working Group ................................................................................................

XG (Semantic Sensor Network Incubator Group) ................................................................PPLICATION COMMUNITY) ................................................................

NSTITUTE OF STANDARDS & TECHNOLOGY) ................................

........................................................................ 24 ............................................................................ 24

............................................................ 25

....................................................... 26

.......................................................... 26 ....................................................................... 26

.............................................................................. 26 ................................................................. 26 ............................................................... 27

.................................................................. 27 ............................................................ 28 ........................................................... 29

.................................................... 33

......................................................................... 33 ............................................................... 33

....................................................................... 34 ......................................................... 34

.......................................................................... 34 ......................................................... 34

.................................................................. 34 .......................................................... 35

..................................................... 35 ............................................................ 35 ......................................................... 35

......................................................................... 35 ............................................................... 35

........................................................................ 36 ............................................................... 36

.................................................................. 36 ........................................................................ 36

.............................................................. 36 .......................................................................... 36

............................................................... 37 ................................................................. 37 ............................................................. 37 .......................................................... 37

............................................................................ 37 ........................................................................ 37

............................................................... 37 .......................................................... 38

................................................ 38 ....................................................................... 38

................................................. 39 ....................................................................... 39

............................................................... 39 ................................................. 39

........................................................................... 39 ......................................................................... 39

............................................................... 39 .................................................. 40

...................................................... 40 ...................................................................... 40

......................................................................... 40 ............................................................ 41

..................................................... 41 .......................................................................... 41

............................................................... 41 ............................................................ 42

............................................... 42 ................................................... 42 ................................................... 42

............................................................ 43 .................................................................... 43

.............................................................................. 43


1 IntroductionFI-WARE Project partners continually study the actual standards and consider when/how to contribute FIWARE research into new standards/protocols in order to (a) avoid "remost efficient use of past developments, and (c) help educate/move technology stateadvantages inherent in FI-WARE.

This document describes the status of the relevant parts of the global standardization landscape, and plans related to FI-WARE activities. It is a "living document" which will be updated as work progresses during the life of the project.

The high-level goal of the FI-WARE project is toPlatform, also referred to as the “FIdocument, has been proposed as an versatile digital services, providing high QoS and security guarantees. A basic description is available

publicly at http://forge.fi-ware.eu/plugins

To understand the broad range of topics coveredthe FI-WARE project is based on

• Service Delivery Framework

across their life cycle, addressing all technical and business aspects.

• Cloud Hosting – the fundamental layer which provides the computation, storaresources, upon which services are provisioned and managed.

• Data/Context Management Services

massive streams of data, and semantically classifying them into valuable knowled

• IoT Enablement – the bridge whereby FI services interface and leverage the ubiquity of heterogeneous, resource-constrained devices in the Internet of Things.

• Interface to the Network and

connectivity needs of services delivered across the platform.

• Security – the mechanisms which ensure that the delivery and usage of services is trustworthy and meets security and privacy requirements.

The set of strategic goals of the FI

• To specify, design, and develop a Core Platform (hereunder referred to as “FIflexible, trustworthy and scalable foundation, supporting the equations listed previously.

• Design extension mechanisms so as to enable taddressed in the context of the FIbusiness trends and their translation into WARE.

• To liaise between the project and relevant to-date with respect to the discussions in the contributions from the project in a coordinated way. The aspecifications leading to open

• To implement and validate the FIdevelop confidence for large scale investments in solutions and European level.

• To enable established players (telecoms, etc.) and emerging players in the services and application domains to tap into new business models by providing components, services, and platforms foemerging players to innovate.

Introduction WARE Project partners continually study the actual standards and consider when/how to contribute FI

o new standards/protocols in order to (a) avoid "re-inventing the wheel", (b) make the most efficient use of past developments, and (c) help educate/move technology state

WARE.

atus of the relevant parts of the global standardization landscape, and plans WARE activities. It is a "living document" which will be updated as work progresses during

WARE project is to build the Core Platform of the Future Internet. This Core Platform, also referred to as the “FI-WARE Platform” or simply “FI-WARE” throughout the rest of this document, has been proposed as an innovative infrastructure for cost-effective creation and deliversatile digital services, providing high QoS and security guarantees. A basic description is available

ware.eu/plugins/mediawiki/wiki/fiware/index.php/Overall_FI

To understand the broad range of topics covered, it is sufficient to note that the Core PlatformWARE project is based on enabler functions linked to the following main architectur

Service Delivery Framework – the infrastructure to create, publish, manage and consume FI services across their life cycle, addressing all technical and business aspects.

the fundamental layer which provides the computation, storaresources, upon which services are provisioned and managed.

Data/Context Management Services – the facilities for effective accessing, processing, and analyzing massive streams of data, and semantically classifying them into valuable knowled

the bridge whereby FI services interface and leverage the ubiquity of constrained devices in the Internet of Things.

Interface to the Network and Devices – open interfaces to networks and devices, providing theconnectivity needs of services delivered across the platform.

the mechanisms which ensure that the delivery and usage of services is trustworthy and meets security and privacy requirements.

The set of strategic goals of the FI-WARE project are:

pecify, design, and develop a Core Platform (hereunder referred to as “FIflexible, trustworthy and scalable foundation, supporting the equations listed previously.

Design extension mechanisms so as to enable to support for yet unforeseen Usage Areas not being addressed in the context of the FI-PPP. This requires a suitable extrapolation of current technology and business trends and their translation into the specific design and implementation principles

between the project and relevant standardization bodies in order to: a) to keep the project update with respect to the discussions in the standardization bodies; b) to support the submission of

contributions from the project in a coordinated way. The aim is to ensure active contribution of specifications leading to open standardized interfaces.

mplement and validate the FI-WARE approach in trials together with Use Case projects in order to develop confidence for large scale investments in solutions for smart future infrastructures on national

nable established players (telecoms, etc.) and emerging players in the services and application domains to tap into new business models by providing components, services, and platforms foemerging players to innovate.

WARE Project partners continually study the actual standards and consider when/how to contribute FI-inventing the wheel", (b) make the

most efficient use of past developments, and (c) help educate/move technology state-of-the-art towards the

atus of the relevant parts of the global standardization landscape, and plans WARE activities. It is a "living document" which will be updated as work progresses during

build the Core Platform of the Future Internet. This Core WARE” throughout the rest of this effective creation and delivery of

versatile digital services, providing high QoS and security guarantees. A basic description is available

/mediawiki/wiki/fiware/index.php/Overall_FI-WARE_Vision

it is sufficient to note that the Core Platform provided by linked to the following main architectural areas:

the infrastructure to create, publish, manage and consume FI services

the fundamental layer which provides the computation, storage and network

the facilities for effective accessing, processing, and analyzing massive streams of data, and semantically classifying them into valuable knowledge.

the bridge whereby FI services interface and leverage the ubiquity of

open interfaces to networks and devices, providing the

the mechanisms which ensure that the delivery and usage of services is trustworthy and

pecify, design, and develop a Core Platform (hereunder referred to as “FI-WARE”) to be a generic, flexible, trustworthy and scalable foundation, supporting the equations listed previously.

et unforeseen Usage Areas not being PPP. This requires a suitable extrapolation of current technology and

specific design and implementation principles of FI-

ation bodies in order to: a) to keep the project up-ation bodies; b) to support the submission of

im is to ensure active contribution of

WARE approach in trials together with Use Case projects in order to for smart future infrastructures on national

nable established players (telecoms, etc.) and emerging players in the services and application domains to tap into new business models by providing components, services, and platforms for these


• To support the development of a new ecosystem including agile and innovative service providers

consuming components and services from FIFI-WARE and associated Usage A

• To stimulate early market takePPP.

These fundamental goals are covered within a set of 11 Work Packages, and one project management work package, as shown in the following ta

Due to their focus, the following work packages are excluded from development of SDO monitoring or contributions:

• WP1 Project Management

• WP2 Global Technical Activities

• WP9 Developer Community and Tools

• WP10 Experimentation Support, Integrated Testing and Validation

• WP12 Communication, Collaboration and Dissemination

WP No

Work package title Type of

activity

1 Project Management

2 Global Technical Activities

3 Application and Services Ecosystem

4 Cloud Hosting

5 Internet of Things Service Enablement

6 Data/Context Management Services

7 Interface to the Network and Devices

8 Security, Privacy, Trust

upport the development of a new ecosystem including agile and innovative service providers consuming components and services from FI-WARE thereby building new business models based on WARE and associated Usage Areas.

To stimulate early market take-up by promoting project results jointly with the other projects in the FI

These fundamental goals are covered within a set of 11 Work Packages, and one project management work package, as shown in the following table from the FI-WARE Project description.

Due to their focus, the following work packages are excluded from development of SDO monitoring or

WP2 Global Technical Activities

WP9 Developer Community and Tools

rimentation Support, Integrated Testing and Validation

WP12 Communication, Collaboration and Dissemination

Type of

WP activity

WPL partic. No

WPL short name

WPA partic.No

WPA short name

MGT 1 TID 1 TID

RTD 1 TID 1 TID

RTD 2 SAP 2 SAP

RTD 3 IBM-IL

3 IBM-IL

RTD 7 FT 9 NSN-H

RTD 1 TID 1 TID

RTD 6 TI 11 DT

RTD 5 THALES

5 THALES

upport the development of a new ecosystem including agile and innovative service providers WARE thereby building new business models based on

up by promoting project results jointly with the other projects in the FI-

These fundamental goals are covered within a set of 11 Work Packages, and one project management work

Due to their focus, the following work packages are excluded from development of SDO monitoring or

PMs Start month

End month

77 1 36

202 1 36

387 1 36

468 1 36

589 1 36

533 1 36

626 1 36

519 1 36


9 Developer Community and Tools

10 Experimentation Support, Integrated Testing and Validation

11 Exploitation and Standardization

12 Communication, Collaboration and Dissemination

OTHER

Finally, WP11 "Exploitation and Standardizationstandardization work done in the WP 3 to WPintegration of standards or contributions to them. Instead, its main activities will be made visible in this and later update documents reporting FI

The main part of this document is divided into chapters as follows:

Chapter 2: WP Standardization Needs

• Survey the SDO landscape (see Annex)

• Identify relevant SDOs for each work package, (especially the architectural and tec

• Classify SDOs into "Will Monitor“, "Will Use", "Will Contribute“

Chapter 3: WP Gap Analysis

• for each Interface, and for each GE, analyze which standard (or open source specification or conspecification or published Web API, etc) is relevant and what are the gaps in functionality between the existing status and what is needed within FI

• Create action items within each WP designed to fill those gaps, by adapting/creating standards for purpose" within FI-WARE

Chapter 4: WP Strategy: Standardiz

• Define a WP Strategy by assigning the action items needed in each SDO to specific partners, taking account of existing partner resources within various SDOs

• Based on discussions between experts within each SDO, organize the action items into a timetable matching the pace of step-byof meetings of each SDO

Note: this standardization strategy chapter depends on many technical decisions in the project and will become fully developed approximately in the middle of the project.

Annex: Relevant Standardization Bodies

• Summarize general information about the relevant standardization bodies, for convenient reference and potentially as a public resource

RTD 15 ENG 15 ENG

RTD 15 ENG N.A. N.A.

RTD 14 ATOS N.A. N.A.

OTHER 1 TID N.A. N.A.

Exploitation and Standardization" is responsible for co-ordinating and reporting the standardization work done in the WP 3 to WP 8. As such, WP11 is not itself responsible for technical integration of standards or contributions to them. Instead, its main activities will be made visible in this and later update documents reporting FI-WARE partner activities.

ocument is divided into chapters as follows:

WP Standardization Needs

Survey the SDO landscape (see Annex)

Identify relevant SDOs for each work package, (especially the architectural and tec

Classify SDOs into "Will Monitor“, "Will Use", "Will Contribute“

for each Interface, and for each GE, analyze which standard (or open source specification or conspecification or published Web API, etc) is relevant and what are the gaps in functionality between the existing status and what is needed within FI-WARE

Create action items within each WP designed to fill those gaps, by adapting/creating standards WARE

WP Strategy: Standardization Plan by Work Package

Define a WP Strategy by assigning the action items needed in each SDO to specific partners, taking ccount of existing partner resources within various SDOs

Based on discussions between experts within each SDO, organize the action items into a timetable by-step development of functionalities within FI-WARE R&D and the pace

Note: this standardization strategy chapter depends on many technical decisions in the project and will become fully developed approximately in the middle of the project.

Relevant Standardization Bodies

Summarize general information about the relevant standardization bodies, for convenient reference and potentially as a public resource

218 1 36

434 4 36

147 1 36

48 3 36

ordinating and reporting the 8. As such, WP11 is not itself responsible for technical

integration of standards or contributions to them. Instead, its main activities will be made visible in this and

Identify relevant SDOs for each work package, (especially the architectural and technical WPs)

for each Interface, and for each GE, analyze which standard (or open source specification or consortia specification or published Web API, etc) is relevant and what are the gaps in functionality between the

Create action items within each WP designed to fill those gaps, by adapting/creating standards to be "fit

Define a WP Strategy by assigning the action items needed in each SDO to specific partners, taking

Based on discussions between experts within each SDO, organize the action items into a timetable WARE R&D and the pace

Note: this standardization strategy chapter depends on many technical decisions in the project and will

Summarize general information about the relevant standardization bodies, for convenient reference and


2 WP Standardization Needs

2.1 IntroductionPart of the FI-WARE project involves surveying and monitoring the standardization overview is provided in Annex: Relevant Standardization Bodies

In the sections below, Partners responsible for each Work Package have analysed the SDOs (Standards Development Organizations), especially those relevant to architectural and protocol issues, and classified them (or sub-working-groups) according to whether FIwithin them.

2.2 WP3 Application and Services Ecosystem

2.2.1 OpenMashup Enterprise MasNote: Open Mashup Alliance abbreviates its name to OMA, however in this document the abbreviation OpenMashup is used to avoid confusion with the older organization Open Mobile Alliance.

The OpenMashup EMML is an XML markup language for applications that consume and mash data from variety of sources, often performing logical or mathematical operations as well as presenting data. Mashed data produced by enterprise mashups are presented in graphical user interfaces as mashlets, widgets, or gadgets. EMML can also be considered a declarative mashup Domain Specific Language (DSL). A mashup DSL eliminates the need for complex, timeconsuming, and repeatable procedural programming logic to create enprovides a declarative language for creating visual tools for enterprise mashups.

The high-level EMML language features include:

• Filter and sort data coming from heterogeneous services.

• Join data across heterogeneous services an

• Group and aggregate data using assorted functions.

• Annotate original service data to enrich its semantic meaning.

• Merge multiple data streams into consolidated datasets.

• Split datasets to select individual data fields.

• Embedded scripting support for JavaScript, JRuby, Groovy, and XQuery.

• Web clipping to scrape data from HTML pages.

• Conditional statements - If/Then/Else, While, For Each.

• Parallel syntax for concurrent processing.

Summary: CONTRIBUTE

2.2.2 OpenAjax Alliance Mashup Standards and SecuThe OpenAjax Alliance's Gadget Taskforce is working on metadata standards for mashup technologies. The taskforce addresses the needs of the mashup community for an industry standard for mashup widgets. It provides:

• A formal language schema, expressed

• A client-side JavaScript implementation of an OpenAjax Widget loader

WP Standardization Needs

Introduction WARE project involves surveying and monitoring the standardization

Relevant Standardization Bodies.

In the sections below, Partners responsible for each Work Package have analysed the SDOs (Standards specially those relevant to architectural and protocol issues, and classified

groups) according to whether FI-WARE needs to "Monitor", "Use" or "Contribute"

WP3 Application and Services Ecosystem

OpenMashup Enterprise Mas hup Markup LanguageNote: Open Mashup Alliance abbreviates its name to OMA, however in this document the abbreviation OpenMashup is used to avoid confusion with the older organization Open Mobile Alliance.

is an XML markup language for creating enterprise mashups, which are software applications that consume and mash data from variety of sources, often performing logical or mathematical operations as well as presenting data. Mashed data produced by enterprise mashups are presented in

phical user interfaces as mashlets, widgets, or gadgets. EMML can also be considered a declarative mashup Domain Specific Language (DSL). A mashup DSL eliminates the need for complex, timeconsuming, and repeatable procedural programming logic to create enterprise mashups. EMML also provides a declarative language for creating visual tools for enterprise mashups.

level EMML language features include:

Filter and sort data coming from heterogeneous services.

Join data across heterogeneous services and data formats.

Group and aggregate data using assorted functions.

Annotate original service data to enrich its semantic meaning.

Merge multiple data streams into consolidated datasets.

Split datasets to select individual data fields.

pport for JavaScript, JRuby, Groovy, and XQuery.

Web clipping to scrape data from HTML pages.

If/Then/Else, While, For Each.

Parallel syntax for concurrent processing.

OpenAjax Alliance Mashup Standards and SecuThe OpenAjax Alliance's Gadget Taskforce is working on metadata standards for mashup technologies. The taskforce addresses the needs of the mashup community for an industry standard for mashup widgets.

A formal language schema, expressed in RelaxNG Compact Syntax

side JavaScript implementation of an OpenAjax Widget loader

WARE project involves surveying and monitoring the standardization landscape. A general

In the sections below, Partners responsible for each Work Package have analysed the SDOs (Standards specially those relevant to architectural and protocol issues, and classified

WARE needs to "Monitor", "Use" or "Contribute"


hup Markup Language Note: Open Mashup Alliance abbreviates its name to OMA, however in this document the abbreviation OpenMashup is used to avoid confusion with the older organization Open Mobile Alliance.

creating enterprise mashups, which are software applications that consume and mash data from variety of sources, often performing logical or mathematical operations as well as presenting data. Mashed data produced by enterprise mashups are presented in

phical user interfaces as mashlets, widgets, or gadgets. EMML can also be considered a declarative mashup Domain Specific Language (DSL). A mashup DSL eliminates the need for complex, time-

terprise mashups. EMML also

OpenAjax Alliance Mashup Standards and Secu rity The OpenAjax Alliance's Gadget Taskforce is working on metadata standards for mashup technologies. The taskforce addresses the needs of the mashup community for an industry standard for mashup widgets.


• Sample OpenAjax widgets

• A mashup authoring environment that includes the OpenAjax Widget loader (see previous bullet) and uses OpenAjax Hub 2.0 as its secure mashup framework, where widgets are isolated from each other into secure sandboxes

• API metadata converters, such as a tool that converts JavaScript files with JSDoc inline comments into the OpenAjax API Metadata

The Security Taskforce identifies keybe pursued by the alliance. It launched a new initiative around mashup authentication and authorization in 2009. It deals with following issues:

• Mashup_Authorization_Authentication_Requ

• Security Use Cases

• Ajax Security Resources

• Ajax Authentication : "AJAX (Re)authentication Signalling and Handling for SingleMulti-domain (mashup) applications"

• CSRF Protection: "The RequesterOrigin header: CSRF protection and beyond".

Summary: CONTRIBUTE

2.2.3 W3C Web Applications SpecificationThe W3C Web Applications (WebApps) Working Group is working on creating specifications that enable improved client-side application development on the Web, including specifications both for APIs for clside development and for markup vocabularies for describing and controlling clientbehaviour. The WG covers:

• Asynchronous DOM Mutation Notification (ADMN)

• Clipboard Operations for the Web 1.0: Copy, Paste, Drag and Drop (ClipOps)

• Database and Offline Application APIs

• Document Object Model (DOM)

• File API

• Progress Events

• Selectors API

• Server-Sent Events

• Secure Cross-Domain Resource Sharing

• Web Interface Definition Language (Web IDL)

• Web Messaging, Web Sockets API, Web Workers

• Widgets

• XML Binding Language (XBL2)

• XML Http Request (XHR)

The work being done by the W3C WebApps WG is relevant because it focuses on developing clientscript APIs and specification for widgets. Widgets are defined by the WebApps WG as fullside applications that are authored using technologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a client machine or device where they run not only as standapplications, but also embedded into Web pages andfunctionalities, to complex applications that pull data from multiple sources to be “mashedpresented to a user in some interesting and useful way.

Summary: CONTRIBUTE

A mashup authoring environment that includes the OpenAjax Widget loader (see previous bullet) and as its secure mashup framework, where widgets are isolated from each other

ters, such as a tool that converts JavaScript files with JSDoc inline comments into

The Security Taskforce identifies key Ajax security issues and investigating what related activities should be pursued by the alliance. It launched a new initiative around mashup authentication and authorization in 2009. It deals with following issues:

Mashup_Authorization_Authentication_Requirements

Ajax Authentication : "AJAX (Re)authentication Signalling and Handling for Singledomain (mashup) applications"

CSRF Protection: "The RequesterOrigin header: CSRF protection and beyond".

W3C Web Applications Specification The W3C Web Applications (WebApps) Working Group is working on creating specifications that enable

side application development on the Web, including specifications both for APIs for clside development and for markup vocabularies for describing and controlling client

Asynchronous DOM Mutation Notification (ADMN)

Clipboard Operations for the Web 1.0: Copy, Paste, Drag and Drop (ClipOps)

base and Offline Application APIs

Document Object Model (DOM)

Domain Resource Sharing

Web Interface Definition Language (Web IDL)

Web Messaging, Web Sockets API, Web Workers

L Binding Language (XBL2)

The work being done by the W3C WebApps WG is relevant because it focuses on developing clientscript APIs and specification for widgets. Widgets are defined by the WebApps WG as full

applications that are authored using technologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a client machine or device where they run not only as standapplications, but also embedded into Web pages and run in a Web browser. Widgets, range from simple functionalities, to complex applications that pull data from multiple sources to be “mashedpresented to a user in some interesting and useful way.

A mashup authoring environment that includes the OpenAjax Widget loader (see previous bullet) and as its secure mashup framework, where widgets are isolated from each other

ters, such as a tool that converts JavaScript files with JSDoc inline comments into

Ajax security issues and investigating what related activities should be pursued by the alliance. It launched a new initiative around mashup authentication and authorization in

Ajax Authentication : "AJAX (Re)authentication Signalling and Handling for Single-domain and

CSRF Protection: "The RequesterOrigin header: CSRF protection and beyond".

The W3C Web Applications (WebApps) Working Group is working on creating specifications that enable side application development on the Web, including specifications both for APIs for client-

side development and for markup vocabularies for describing and controlling client-side application

Clipboard Operations for the Web 1.0: Copy, Paste, Drag and Drop (ClipOps)

The work being done by the W3C WebApps WG is relevant because it focuses on developing client-side script APIs and specification for widgets. Widgets are defined by the WebApps WG as full-fledged client-

applications that are authored using technologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a client machine or device where they run not only as stand-alone

run in a Web browser. Widgets, range from simple functionalities, to complex applications that pull data from multiple sources to be “mashed-up” and


2.2.4 W3C Semantic Web ServicesThe W3C has standardized various languages for the description of Web Services (collectively known as WS-*), e.g., the Web Service Description Language. There are also many recommendations and working draft in the realm of Semantic Web Services such as

• SAWSDL Semantic Annotations for WSDL and XML Schema.

• SAREST Semantic Annotation of Web Resources.

• WADL Web Application Description Language.

• WSMO-Lite Lightweight Semantic Descriptions for Services on the Web.

Project results could contribute to existing recommenrespect to capturing business and operational aspects of services.

Summary: CONTRIBUTE

2.2.5 OMG Business Process Model and NotationOMG BPMN2 (BPMN Version 2) processes will be used in the Delivery Framework for workflowModelling Notation (BPMN) provides businesses with the capability of understanding their internal business procedures in a graphical notation. modelling applicable to business processes. Other types of modelling done by organizations for nonbusiness purposes are out of scope for BPMN. Examples of modelling excluded from BPMN include:

• Organizational structures

• Functional breakdowns

• Data models

Summary: MONITOR

2.2.6 OMG Service Oriented ArchitectureA significant related work stems from the OMG, viz., SoaML, which facilitates software/service engineering in model-driven environments. The provided speci

Non-normative introduction to the SoaML specification

• Resolution of UPMS RFP Mandatory and Optional Requirements

• Scope: specifies the scope of services modelling covered.

• Compliance: compliance with SoaML requires that the subset of UML implemented. This specifies the optional services modelling feature and their compliance levels.

• Normative References: References to other adopted specifications.

• Terms and Definitions: Formal definitions that are taken from other doc

• Symbols: Identification and definition of special symbols required to read this specification.

• SoaML UML Profile Specification: Describes the SoaML UML profile

• Classification: Describes the adaptation of RAS to model classification

• BMM Integration: Describes the integration with the Business Motivation Metamodel

• SoaML Metamodel: Describes the SoaML Metamodel

The rather technical SoaML could be complemented by project results in capturing business and operational aspects of service description and th

Summary: CONTRIBUTE

W3C Semantic Web Services W3C has standardized various languages for the description of Web Services (collectively known as *), e.g., the Web Service Description Language. There are also many recommendations and working

draft in the realm of Semantic Web Services such as

Semantic Annotations for WSDL and XML Schema.

SAREST Semantic Annotation of Web Resources.

WADL Web Application Description Language.

Lite Lightweight Semantic Descriptions for Services on the Web.

Project results could contribute to existing recommendations, and, especially, to working drafts with respect to capturing business and operational aspects of services.

OMG Business Process Model and Notation OMG BPMN2 (BPMN Version 2) processes will be used in the Application and Service

workflow-based composition of applications. The standard Business Process Modelling Notation (BPMN) provides businesses with the capability of understanding their internal business procedures in a graphical notation. BPMN is constrained to support only the concepts of modelling applicable to business processes. Other types of modelling done by organizations for nonbusiness purposes are out of scope for BPMN. Examples of modelling excluded from BPMN include:

OMG Service Oriented Architecture A significant related work stems from the OMG, viz., SoaML, which facilitates software/service

driven environments. The provided specifications include:

normative introduction to the SoaML specification

Resolution of UPMS RFP Mandatory and Optional Requirements

Scope: specifies the scope of services modelling covered.

Compliance: compliance with SoaML requires that the subset of UML implemented. This specifies the optional services modelling feature and their compliance levels.

Normative References: References to other adopted specifications.

Terms and Definitions: Formal definitions that are taken from other documents.

Symbols: Identification and definition of special symbols required to read this specification.

SoaML UML Profile Specification: Describes the SoaML UML profile

Classification: Describes the adaptation of RAS to model classification

Describes the integration with the Business Motivation Metamodel

SoaML Metamodel: Describes the SoaML Metamodel

The rather technical SoaML could be complemented by project results in capturing business and operational aspects of service description and their unification.

W3C has standardized various languages for the description of Web Services (collectively known as *), e.g., the Web Service Description Language. There are also many recommendations and working

dations, and, especially, to working drafts with

Application and Services Ecosystem and

of applications. The standard Business Process Modelling Notation (BPMN) provides businesses with the capability of understanding their internal

BPMN is constrained to support only the concepts of modelling applicable to business processes. Other types of modelling done by organizations for non-business purposes are out of scope for BPMN. Examples of modelling excluded from BPMN include:

A significant related work stems from the OMG, viz., SoaML, which facilitates software/service

Compliance: compliance with SoaML requires that the subset of UML required for SoaML is implemented. This specifies the optional services modelling feature and their compliance levels.

uments.

Symbols: Identification and definition of special symbols required to read this specification.

Describes the integration with the Business Motivation Metamodel

The rather technical SoaML could be complemented by project results in capturing business and


2.2.7 OASIS Service Description and DiscoveryOASIS also provides several standards in the realm of service description and discovery. Among them is the specification for UDDI as well as the SOA Reference Model or the Referenfor SOA. Relevant developments:

• UDDI

• SOA-RM

• RAF-SOA

OASIS is also defining an open standard for Content Management Interoperability Services (CMIS), which is relevant for the Repository.

Future version of OASIS reference models operational aspects of service descriptions.

Summary: CONTRIBUTE

2.2.8 Open Group SOA OntologyThe Open Group proposes the SOA Ontology as a reference model which is also related work in our context. The Open Group SOA Ontology is a formal definition of the concepts, terminology, and semantics of SOA in both business and technical terms. It was developed in order to aid understanding of SOA, and potentially contribute to model-driven SOA implementation.

It is a formal ontology, expressed in the Web Ontology Language (OWL), but with explanatory text including UML diagrams and examples. It covers concepts related to:

• System and Element

• Human Actor and Task

• Service, Service Contract, and Service Interface

• Composition

• Policy

• Event

Future version of the SOA Ontology could benefit from operational aspects of service descriptions.

Summary: MONITOR

2.2.9 DIN Publicly Available Specification 1018The Publicly Available Specificationprescribes an informal template for tendering puof formal service descriptions.

The project results could lead to a formalized version of DIN PAS 1018

Summary: MONITOR

2.3 WP4 Cloud HostingThe main goal of Cloud Hosting is to provision and mananetwork) which are used to run services hosted in the cloud. As of today, there are no mature standard in

OASIS Service Description and Discovery OASIS also provides several standards in the realm of service description and discovery. Among them is the specification for UDDI as well as the SOA Reference Model or the Reference Architecture Foundations for SOA. Relevant developments:

OASIS is also defining an open standard for Content Management Interoperability Services (CMIS), which

Future version of OASIS reference models could benefit from innovations in the realm of business and operational aspects of service descriptions.

Open Group SOA Ontology The Open Group proposes the SOA Ontology as a reference model which is also related work in our

e Open Group SOA Ontology is a formal definition of the concepts, terminology, and semantics of SOA in both business and technical terms. It was developed in order to aid understanding of SOA, and

driven SOA implementation.

It is a formal ontology, expressed in the Web Ontology Language (OWL), but with explanatory text including UML diagrams and examples. It covers concepts related to:

Service, Service Contract, and Service Interface

Future version of the SOA Ontology could benefit from innovations in the realm of business and operational aspects of service descriptions.

DIN Publicly Available Specification 1018 Publicly Available Specification (PAS) 1018 of the German Institute for Standardization (DIN)

prescribes an informal template for tendering public services. It can be seen a precursor for standardization

The project results could lead to a formalized version of DIN PAS 1018

WP4 Cloud Hosting The main goal of Cloud Hosting is to provision and manage virtualized resources (compute, storage, network) which are used to run services hosted in the cloud. As of today, there are no mature standard in

OASIS also provides several standards in the realm of service description and discovery. Among them is ce Architecture Foundations

OASIS is also defining an open standard for Content Management Interoperability Services (CMIS), which

in the realm of business and

The Open Group proposes the SOA Ontology as a reference model which is also related work in our e Open Group SOA Ontology is a formal definition of the concepts, terminology, and semantics

of SOA in both business and technical terms. It was developed in order to aid understanding of SOA, and

It is a formal ontology, expressed in the Web Ontology Language (OWL), but with explanatory text

in the realm of business and

(PAS) 1018 of the German Institute for Standardization (DIN) blic services. It can be seen a precursor for standardization

ge virtualized resources (compute, storage, network) which are used to run services hosted in the cloud. As of today, there are no mature standard in


Cloud Computing. In the context of FIspecifications are being considered

• Provisioning and life cycle management of individual virtualized resources: compute, storage, network. Standards being considered as relevant for this area are:

• Provisioning and life cycle management of multi

• Provisioning and life cycle management of objects and object containers:

2.3.1 DMTF Open Virtualization Format (OVFTelefonica and other FI-WARE partners are actively contributing to OVF.

Cloud Infrastructure Management Interface (virtualized resources in the cloud. IBM, Telefonica and other FIto CIMI, which is an emerging standard

Both standard areas are relevant for resources: compute, storage, network.

Summary: CONTRIBUTE

2.3.2 OGF Open Cloud Computing Interface (cycle management of virtualized resources in the cloud. Intel and other FIcontributing to OCCI. It is relevant for presources: compute, storage, network.

Summary: CONTRIBUTE

2.3.3 OpenStack OpenStack API is the open specification of OpenStack development for a cloud infrastructure stack, supported by leading IT vendorsDell, HP, AT&T, Citrix, NEC, NetApp and others.management of individual virtualized resources: compute, storage, network.

Summary: MONITOR

2.3.4 OASIS TOSCA is an emerging OASIS services. It is relevant for •provisioning and life cycle management of multi(services).

Summary: MONITOR

2.3.5 W3C RIF is a W3 standard for definition of rules (in the cloud covirtual appliances). It is relevant for appliances (services).

Summary: MONITOR

Cloud Computing. In the context of FI-WARE, there are three main areas in which standards or open ations are being considered, and the most relevant SDOs are addressed below

Provisioning and life cycle management of individual virtualized resources: compute, storage, network. Standards being considered as relevant for this area are:

life cycle management of multi-VM virtual appliances (services):

Provisioning and life cycle management of objects and object containers:

OVF): addressing packaging and deployment of virtual appliances. IBM, WARE partners are actively contributing to OVF.

Cloud Infrastructure Management Interface (CIMI): addressing provisioning and life cycle management of virtualized resources in the cloud. IBM, Telefonica and other FI-WARE partners are actively c

, which is an emerging standard.

Both standard areas are relevant for provisioning and life cycle management of individual virtualized resources: compute, storage, network.

Open Cloud Computing Interface (OCCI), an emerging OGF standard, addresscycle management of virtualized resources in the cloud. Intel and other FI-WARE partners are actively

It is relevant for provisioning and life cycle management of individual viresources: compute, storage, network.

the open specification of OpenStack and is the most noticeable emerging open source cloud infrastructure stack, supported by leading IT vendors such as Rackspace, Cisco,

Dell, HP, AT&T, Citrix, NEC, NetApp and others. It is relevant for provisioning and life cycle management of individual virtualized resources: compute, storage, network.

standard, addressing definition and life cycle management of composite rovisioning and life cycle management of multi

a W3 standard for definition of rules (in the cloud context -- rules for run. It is relevant for •provisioning and life cycle management of multi

WARE, there are three main areas in which standards or open , and the most relevant SDOs are addressed below:

Provisioning and life cycle management of individual virtualized resources: compute, storage, network.

VM virtual appliances (services):

): addressing packaging and deployment of virtual appliances. IBM,

): addressing provisioning and life cycle management of WARE partners are actively contributing

rovisioning and life cycle management of individual virtualized

standard, addresses provisioning and life WARE partners are actively

rovisioning and life cycle management of individual virtualized

the most noticeable emerging open source such as Rackspace, Cisco, rovisioning and life cycle

addressing definition and life cycle management of composite rovisioning and life cycle management of multi-VM virtual appliances

rules for run-time scaling of elastic rovisioning and life cycle management of multi-VM virtual


2.3.6 SNIA CDMI is a SNIA standard for management of cloud storage. It is rmanagement of objects and object containers:

Summary: MONITOR

2.4 WP5 Internet of Things Service Enablement

2.4.1 ETSI TC M2M (Machine to Machine)ETSI TC M2M Machine is an application agnostic standard for Machine to Machincontains an overall end to end M2M functional architecture, identifies the functional entities and the related reference points.

The high-level functional architecture consists of two main parts, the(Network) and the M2M Device Domainare basically devices that run applications using the service capabilities defined by the M2M standard. M2M Gateways are equipments using service capabilities to ensure interconnection to the Network and Application Domain.

A Service Capability is a central concept. It provides functions that are to be shared by different applications, expose functions through a set of open interfaces as well as development and deployment through hiding of network specificities. The following service capabilities are defined: Application Enablement (xAE), Generic Communication (xGC), Reachability, Addressing and Repository (xRAR), Communication Selection (xCS), Remote Enttity Management (xREM), SECurity (xSEC), History and Data Retention (xHDR), Transaction Management (xTM), Compensation Broker (xCB), Telco Operator Exposure (xTOE), Interworking Proxy (xIP). The ‘x’ in the abbreviatthat Service Capabilities are present at three levels: at the M2M Core Network (N), in the Gateway (G) and on the Device (D). Not all Service Capabilities may instantiated in all parts. A set of service capabilities form a Service Capability Layer (SCL).

The standard defines three reference pointsbetween the M2M core and applications and

All three uses a resource-oriented design with obvious RESTful bapplicable to a wide range of network technology, so when specific potential bindings are defined, these bindings should not limit the applicability to other networks (e.g., using different protocols).

The architecture of ETSI M2M is very symmetric: the gateways, devices and network contain the similar functionality. Thus the reference points are very similar, providing the following functionality:

• Registration of Device/Gateway or Network Application to the respective SCL.

• Request to Read/Write, subject to proper authorization, information in the Network, Gateway or Device SCL, GSCL.

• Subscription and notification to specific events.

• Request the creation, deletion and listing of group(s).

The mId also includes device management

Summary: CONTRIBUTE

2.4.2 OMA Next Generation Service Interface Context Manag ementThe OMA NGSI Context Management component provides the NGSIContext Information about Context Entities. Actual implementation and its internal structure of Context

CDMI is a SNIA standard for management of cloud storage. It is relevant for provisioning and life cycle management of objects and object containers:

WP5 Internet of Things Service Enablement

ETSI TC M2M (Machine to Machine) ETSI TC M2M Machine is an application agnostic standard for Machine to Machincontains an overall end to end M2M functional architecture, identifies the functional entities and the related

level functional architecture consists of two main parts, the Network and Applications domain M2M Device Domain containing M2M Gateways and M2M Devices

are basically devices that run applications using the service capabilities defined by the M2M standard. M2M Gateways are equipments using service capabilities to ensure Devices interworking and interconnection to the Network and Application Domain.

is a central concept. It provides functions that are to be shared by different applications, expose functions through a set of open interfaces as well as simply and optimise application development and deployment through hiding of network specificities. The following service capabilities are defined: Application Enablement (xAE), Generic Communication (xGC), Reachability, Addressing

Communication Selection (xCS), Remote Enttity Management (xREM), SECurity (xSEC), History and Data Retention (xHDR), Transaction Management (xTM), Compensation Broker (xCB), Telco Operator Exposure (xTOE), Interworking Proxy (xIP). The ‘x’ in the abbreviatthat Service Capabilities are present at three levels: at the M2M Core Network (N), in the Gateway (G) and on the Device (D). Not all Service Capabilities may instantiated in all parts. A set of service capabilities

Layer (SCL).

reference points: mId between the device/gateway and the M2M core, between the M2M core and applications and dIa between the device and gateway.

oriented design with obvious RESTful binding over HTTP. ETSI M2M is applicable to a wide range of network technology, so when specific potential bindings are defined, these bindings should not limit the applicability to other networks (e.g., using different protocols).

I M2M is very symmetric: the gateways, devices and network contain the similar functionality. Thus the reference points are very similar, providing the following functionality:

Registration of Device/Gateway or Network Application to the respective SCL.

quest to Read/Write, subject to proper authorization, information in the Network, Gateway or

Subscription and notification to specific events.

Request the creation, deletion and listing of group(s).

also includes device management actions (e.g. software upgrade, configuration management).

OMA Next Generation Service Interface Context Manag ementThe OMA NGSI Context Management component provides the NGSI-9 and NGSI

t Context Entities. Actual implementation and its internal structure of Context

elevant for provisioning and life cycle

WP5 Internet of Things Service Enablement

ETSI TC M2M Machine is an application agnostic standard for Machine to Machine Communications. It contains an overall end to end M2M functional architecture, identifies the functional entities and the related

Network and Applications domain

M2M Devices. M2M Devices are basically devices that run applications using the service capabilities defined by the M2M standard.

Devices interworking and

is a central concept. It provides functions that are to be shared by different simply and optimise application

development and deployment through hiding of network specificities. The following service capabilities are defined: Application Enablement (xAE), Generic Communication (xGC), Reachability, Addressing

Communication Selection (xCS), Remote Enttity Management (xREM), SECurity (xSEC), History and Data Retention (xHDR), Transaction Management (xTM), Compensation Broker (xCB), Telco Operator Exposure (xTOE), Interworking Proxy (xIP). The ‘x’ in the abbreviated names hints that Service Capabilities are present at three levels: at the M2M Core Network (N), in the Gateway (G) and on the Device (D). Not all Service Capabilities may instantiated in all parts. A set of service capabilities

vice/gateway and the M2M core, mIa between the device and gateway.

inding over HTTP. ETSI M2M is applicable to a wide range of network technology, so when specific potential bindings are defined, these bindings should not limit the applicability to other networks (e.g., using different protocols).

I M2M is very symmetric: the gateways, devices and network contain the similar functionality. Thus the reference points are very similar, providing the following functionality:

Registration of Device/Gateway or Network Application to the respective SCL.

quest to Read/Write, subject to proper authorization, information in the Network, Gateway or

actions (e.g. software upgrade, configuration management).

OMA Next Generation Service Interface Context Manag ement 9 and NGSI-10 interfaces to manage

t Context Entities. Actual implementation and its internal structure of Context


Management component are out of scope. Through these interfaces, a Context Management component will provide its context management services to actors outside of a single netwo

A Context Entity is any principal and object, which has a state. This state can be described using Context Information. Context Entities could be users, devices, places, buildings, and many others (including virtual objects). Context Information is anEntity. Context Information can be measured by sensors, manually set by humans, derived from operations on handsets or terminals, inferred from other information, or requested from

Architecture definition is out of scope, only the Context Management Component is described: it provides the NGSI interfaces to manage Context Information about Context Entities.

The two abstract interfaces contain the following operations:

NGSI9 – Context Entity Discovery Interface

• Register Context Entity: Component.

• Discover Context Entity Operation:

attributes.

• Subscribe and Notify based Context Entity Discovery

Entity registrations, i.e. when a new Context Entity is registered, gets an update.

NGSI10 – Context Information Interface

• Update Context Operation:

Information to the Context Management component.

• Query Operation: applicationsexplicitly listed Context Entities using their Context Entity id or Context Entities which are specified by patterns of entity id and/or attributes.

• Subscription and Notification Operation

Context Management Component in ovalues. The application can change or cancel existing subscriptions. As the result of the subscription the Context Management component sends notifications to the receiving application

Summary: CONTRIBUTE

2.4.3 OGC Sensor Web EnablementSWE services are designed to enable discovery of sensor assets and capabilities, access to those resources and data retrieval, as well as subscription to alerts, and tasking of sensors to control observations.

SWE does not have an architecture in a strict sense. It defines more collaboration scenarios for the interfaces, languages and protocols it defines. These are the following:

• Sensor Model Language (SensorML): standasystems and processes; provides information needed for discovery of sensors, location of sensor observations, processing of low

• Observation & Measurements Schema (O&M): standard models and XML Schemaobservations and measurements from a sensor, both arc

• Transducer Model Languages (TMS): Conceptual approach and XML Schema for supporting realstreaming of data to and from sensor systems.

• Sensor Observation Service (retrieving observations and sensor system information

• Observation Offering

Management component are out of scope. Through these interfaces, a Context Management component will provide its context management services to actors outside of a single network.

A Context Entity is any principal and object, which has a state. This state can be described using Context Information. Context Entities could be users, devices, places, buildings, and many others (including virtual objects). Context Information is any volatile or persistent information, which describes a state of a Context Entity. Context Information can be measured by sensors, manually set by humans, derived from operations on handsets or terminals, inferred from other information, or requested from databases.

Architecture definition is out of scope, only the Context Management Component is described: it provides the NGSI interfaces to manage Context Information about Context Entities.

The two abstract interfaces contain the following operations:

Context Entity Discovery Interface

the application registers Context Entities at the Context Management

Discover Context Entity Operation: the application discovers available Context Entities and their

bscribe and Notify based Context Entity Discovery: the application can subscribe to Context Entity registrations, i.e. when a new Context Entity is registered, and then the subscribed application

Context Information Interface

e Context Operation: an application acting as a context producer provides or updates Context Information to the Context Management component.

applications, acting as context consumers, query for Context Information of text Entities using their Context Entity id or Context Entities which are specified

by patterns of entity id and/or attributes.

Subscription and Notification Operation: enables an application to issue a subscription to the Context Management Component in order to receive notifications for changes of context attribute values. The application can change or cancel existing subscriptions. As the result of the subscription the Context Management component sends notifications to the receiving application

OGC Sensor Web Enablement SWE services are designed to enable discovery of sensor assets and capabilities, access to those resources and data retrieval, as well as subscription to alerts, and tasking of sensors to control observations.

architecture in a strict sense. It defines more collaboration scenarios for the interfaces, languages and protocols it defines. These are the following:

Sensor Model Language (SensorML): standard models and XML Schema for destems and processes; provides information needed for discovery of sensors, location of sensor

observations, processing of low-level sensor observations, and listing taskable properties

Observation & Measurements Schema (O&M): standard models and XML Schemaobservations and measurements from a sensor, both arc-hived and real-time

Transducer Model Languages (TMS): Conceptual approach and XML Schema for supporting realstreaming of data to and from sensor systems.

Sensor Observation Service (SOS): standard web service interface for requesting, filtering, and retrieving observations and sensor system information

Management component are out of scope. Through these interfaces, a Context Management component rk.

A Context Entity is any principal and object, which has a state. This state can be described using Context Information. Context Entities could be users, devices, places, buildings, and many others (including virtual

y volatile or persistent information, which describes a state of a Context Entity. Context Information can be measured by sensors, manually set by humans, derived from operations

databases.

Architecture definition is out of scope, only the Context Management Component is described: it provides

the application registers Context Entities at the Context Management

the application discovers available Context Entities and their

: the application can subscribe to Context the subscribed application

an application acting as a context producer provides or updates Context

query for Context Information of text Entities using their Context Entity id or Context Entities which are specified

: enables an application to issue a subscription to the rder to receive notifications for changes of context attribute

values. The application can change or cancel existing subscriptions. As the result of the subscription the Context Management component sends notifications to the receiving application

SWE services are designed to enable discovery of sensor assets and capabilities, access to those resources and data retrieval, as well as subscription to alerts, and tasking of sensors to control observations.

architecture in a strict sense. It defines more collaboration scenarios for the

rd models and XML Schema for describing sensors stems and processes; provides information needed for discovery of sensors, location of sensor

level sensor observations, and listing taskable properties

Observation & Measurements Schema (O&M): standard models and XML Schema for encoding

Transducer Model Languages (TMS): Conceptual approach and XML Schema for supporting real-time

SOS): standard web service interface for requesting, filtering, and


• SensorML for sensor descriptions, O&M for observation and measurement data

• Sensor Planning Service (SPS): standarand observations, to (re-)calibrate a sensor or to task a sensor network

• Sensor Alert Service (SAS): standard web service interface for publishing and subfrom sensors

• Uses XMPP

• Web Notification Service (WNS): standard web service interface for asynchronous delivery of messages or alerts from any other web service

• Sensor Web Registry (SWR): catalog service, but in early testing phase.

It is important to emphasize that Sensoeverything; from the information model to the protocol definitions the various services are accessed.

Summary: MONITOR

2.4.4 ISO Sensor Network Reference ArchitectureIt is important to note that this stafollows:

• committee stage / CD study, ballot initiated

- General overview and requirements,

- Vocabulary and Terminology,

- Interoperability Guidelines

• preparatory stage / close of comm

- Reference architecture views,

- Entity models,

- Interface Definitions,

- Application Profiles

From the above list, only the committee stage parts are available to the general public. The most important parts, i.e. Interface Definitions and Refere

The architecture consists of four types of nodes:

• Sensor network gateway: sensor network element that connects a sensor network to any other network, permitting information exchange between them

• Sensor Node: sensor network element that includes at least one sensor and optionally actuators with communication capabilities and data processing capabilities

• Sensor Network Service Provider: entity that offers services to users involving the use of sensor network resources

• User: individual or agent that directly invokes the services provided by a sensor network

There are three apparent differences to the other analysed standards.

• Sensors form a distributed sensor network where they communicate with each other. In ETSI M2devices/sensors may not communicate with each other directly, only through the backend. In OGC SWE the sensors may not communicate at all. In neither case do they form an autonomous distributed network.

• Sensors are not passive devices, but can have communication capabilities. The conceptual difference is important here, as this definition fits devices in ETSI M2M.

SensorML for sensor descriptions, O&M for observation and measurement data

Sensor Planning Service (SPS): standard web service interface for requesting user)calibrate a sensor or to task a sensor network

Sensor Alert Service (SAS): standard web service interface for publishing and sub

Web Notification Service (WNS): standard web service interface for asynchronous delivery of messages or alerts from any other web service

Sensor Web Registry (SWR): catalog service, but in early testing phase.

It is important to emphasize that SensorML is the central element of the SWE. It contains almost everything; from the information model to the protocol definitions the various services are accessed.

ISO Sensor Network Reference Architecture It is important to note that this standard is incomplete. It consists of seven parts, the status of

committee stage / CD study, ballot initiated

General overview and requirements,

Vocabulary and Terminology,

Interoperability Guidelines

preparatory stage / close of comment period

Reference architecture views,

Interface Definitions,

Application Profiles

From the above list, only the committee stage parts are available to the general public. The most important parts, i.e. Interface Definitions and Reference architecture views, are not available.

The architecture consists of four types of nodes:

Sensor network gateway: sensor network element that connects a sensor network to any other network, permitting information exchange between them

sor network element that includes at least one sensor and optionally actuators with communication capabilities and data processing capabilities

Sensor Network Service Provider: entity that offers services to users involving the use of sensor

User: individual or agent that directly invokes the services provided by a sensor network

There are three apparent differences to the other analysed standards.

Sensors form a distributed sensor network where they communicate with each other. In ETSI M2devices/sensors may not communicate with each other directly, only through the backend. In OGC SWE the sensors may not communicate at all. In neither case do they form an autonomous distributed

Sensors are not passive devices, but can have an application layer that uses their data processing or communication capabilities. The conceptual difference is important here, as this definition fits devices

SensorML for sensor descriptions, O&M for observation and measurement data

d web service interface for requesting user-driven acquisitions

Sensor Alert Service (SAS): standard web service interface for publishing and sub-scribing to alerts

Web Notification Service (WNS): standard web service interface for asynchronous delivery of

rML is the central element of the SWE. It contains almost everything; from the information model to the protocol definitions the various services are accessed.

ndard is incomplete. It consists of seven parts, the status of which is as

From the above list, only the committee stage parts are available to the general public. The most important nce architecture views, are not available.

Sensor network gateway: sensor network element that connects a sensor network to any other network,

sor network element that includes at least one sensor and optionally actuators with

Sensor Network Service Provider: entity that offers services to users involving the use of sensor

User: individual or agent that directly invokes the services provided by a sensor network

Sensors form a distributed sensor network where they communicate with each other. In ETSI M2M the devices/sensors may not communicate with each other directly, only through the backend. In OGC SWE the sensors may not communicate at all. In neither case do they form an autonomous distributed

an application layer that uses their data processing or communication capabilities. The conceptual difference is important here, as this definition fits devices


• Gateways are not “adapting” proxies but connection points between the sensor netwo

networks.

These attributes make this standard extremely interesting for IoT standardisation. Unfortunately at this point the documents themselves warn the reader that nothing is final as it is a draft we are reading. Drawing any kind of conclusion would not be wise at this point.

Summary: MONITOR

2.5 WP 6 Data/Context Management ServicesWP6 envisions the concept of "Data Element" as a virtual resource or structure which is able to represent data, metadata (contextual attributes) or events. Thus, gathering, processing and analyzing any information provided as Data Elements.

The following subsections introduce the main standardization needs as a snapshot of the ones identified so far within Data/Context chapter.

2.5.1 OMA NGSI & Content DeliverySimilarly, as described in the previous section related to IoT, binding of Publish/Subscribe Generic Enabler to a technology within NGSI (Next Generation Service Interface) would significantly enhaproviding standard interfaces and operations. However, current NGSI specadopted/implemented by the industry and therefore there are a number of open issues to be solved. WP6 participants will work together, firstthe spirit of the original standard (OMA NGSI)WARE conclusions. Once a "FI-the team will focus on contributing to OMA

Additionally, as long as FI-WAREnetworks, the team will follow OMA Content Delivframework for brokerage of the Social Networks and for enabling Augmented Reality.

Summary: CONTRIBUTE

2.5.2 W3C Following the interaction with the Social networks described above, "W3C Federated Social Wworking group dealing with Social Networks interoperability is expected to provide methods and mechanisms suitable for data collection/retrieving.

Other topics and working groups within W3Cneeded by WP6, are: (a) "POI Working Group", dealing with the specification of description of Points of Interests (POI) on the Web and (b) applications access in a standard and seamless wayaccelerometer etc.

Summary: MONITOR

2.5.3 ISO-JPEG/MPEGFI-WARE Multimedia analysis GE is able to detect patterns in MPEG streams and therefore tracking MPEG and JPEG groups is relevant for WP6. Topics where spare: Query Formats (mainly MPQF and JPSearch) and MPEG Storage formats (i.e., file formats), query formats.

Gateways are not “adapting” proxies but connection points between the sensor netwo

These attributes make this standard extremely interesting for IoT standardisation. Unfortunately at this point the documents themselves warn the reader that nothing is final as it is a draft we are reading. Drawing

usion would not be wise at this point.

WP 6 Data/Context Management ServicesWP6 envisions the concept of "Data Element" as a virtual resource or structure which is able to represent data, metadata (contextual attributes) or events. Thus, assets within this chapter are mainly in charge of gathering, processing and analyzing any information provided as Data Elements.

The following subsections introduce the main standardization needs as a snapshot of the ones identified so

OMA NGSI & Content Delivery as described in the previous section related to IoT, binding of Publish/Subscribe Generic Enabler

to a technology within NGSI (Next Generation Service Interface) would significantly enhaproviding standard interfaces and operations. However, current NGSI specificationadopted/implemented by the industry and therefore there are a number of open issues to be solved. WP6

firstly on a "FI-WARE NGSI" specification keeping as much as possible the spirit of the original standard (OMA NGSI), but also adapting and evolving aspects as required by

-WARE NGSI" implementation is defined and assessedthe team will focus on contributing to OMA through modification proposals to the previous standard.

WARE is considering techniques to collect and exploit data shared in Social networks, the team will follow OMA Content Delivery group, particularly in the topic of definition of the framework for brokerage of the Social Networks and for enabling Augmented Reality.

wing the interaction with the Social networks described above, "W3C Federated Social Wworking group dealing with Social Networks interoperability is expected to provide methods and mechanisms suitable for data collection/retrieving.

Other topics and working groups within W3C, which are expected to provide methods/spec"POI Working Group", dealing with the specification of description of Points of

(b) "Device API WG" working on Standard APIs definition to applications access in a standard and seamless way to device functionalities like file system, camera,

JPEG/MPEG Multimedia analysis GE is able to detect patterns in MPEG streams and therefore tracking

MPEG and JPEG groups is relevant for WP6. Topics where specification alignmentare: Query Formats (mainly MPQF and JPSearch) and MPEG Storage formats (i.e., file formats), query

Gateways are not “adapting” proxies but connection points between the sensor network and other

These attributes make this standard extremely interesting for IoT standardisation. Unfortunately at this point the documents themselves warn the reader that nothing is final as it is a draft we are reading. Drawing

WP 6 Data/Context Management Services WP6 envisions the concept of "Data Element" as a virtual resource or structure which is able to represent

assets within this chapter are mainly in charge of

The following subsections introduce the main standardization needs as a snapshot of the ones identified so

as described in the previous section related to IoT, binding of Publish/Subscribe Generic Enabler to a technology within NGSI (Next Generation Service Interface) would significantly enhance its value by

ifications have not been widely adopted/implemented by the industry and therefore there are a number of open issues to be solved. WP6

keeping as much as possible of but also adapting and evolving aspects as required by FI-

assessed within the project, modification proposals to the previous standard.

is considering techniques to collect and exploit data shared in Social ery group, particularly in the topic of definition of the

framework for brokerage of the Social Networks and for enabling Augmented Reality.

wing the interaction with the Social networks described above, "W3C Federated Social Web Support" working group dealing with Social Networks interoperability is expected to provide methods and

expected to provide methods/specifications "POI Working Group", dealing with the specification of description of Points of

king on Standard APIs definition to enable Web device functionalities like file system, camera,

Multimedia analysis GE is able to detect patterns in MPEG streams and therefore tracking alignment/progress are needed

are: Query Formats (mainly MPQF and JPSearch) and MPEG Storage formats (i.e., file formats), query


An expected contribution from WP6 team to this SDO is the improvement of query formats.

Summary: CONTRIBUTE

2.6 WP7 Interface to the Network and DevicesA number of activities concerned with accessing device capabilities are emerging from various standards organizations, and these have an impact on the CDI GE specifications. A clear trend towards platform independent, Web technology-based APIs and open source operating systems can be

2.6.1 W3C W3C Device API: The mission of the the development of Web Applications that interact with device hardware, services and applications such as the camera, microphone, system sensors, native address books, calendars and native messaging applications. The scope of this Working Group is creation of API specifications for acan be exposed to Web applications. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

W3C Geolocation API: The objective olocation information via a standardized interface or interfaces

Both WGs have implications on the activity carried on about the FIDevice Generic Enabler specifications.

It is therefore extremely important to follow the activities of the WGs, consider adopting existing APIs and contribute to their extension with the outcomes from this FI

Summary: CONTRIBUTE.

2.6.2 WAC It is moreover to be recognised that some of activities in the W3C WGs mentioned above have relationships with other groups (in some cases with overlaps). [WAC] is an organization that is creating a unified and open platform to allow mobile soto more easily write applications usable on a variety of devices, operating systems and networks. The Mobile Terminal Platform [OMTP] technology has moved into WAC and Innovation Lab [JIL] also lately merged specifications of the WAC initiative.

Summary: MONITOR.

2.6.3 OMA Device ManagementThe OMA Device management specificationas mobile phones, PDAs, etc, and include the possibility to the device including first time usechange to its settings and parametersfixes, including applications and systemthe device, query about status of device

This has relevance for the remote management APIs of Connected



WP7 Interface to the Network and DevicesA number of activities concerned with accessing device capabilities are emerging from various standards

have an impact on the CDI GE specifications. A clear trend towards platform based APIs and open source operating systems can be

The mission of the Device APIs Working Group is to create clientcations that interact with device hardware, services and applications such as

the camera, microphone, system sensors, native address books, calendars and native messaging applications. The scope of this Working Group is creation of API specifications for acan be exposed to Web applications. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

The objective of this Geolocation WG charter is to enable Web access to the user's ardized interface or interfaces.

Both WGs have implications on the activity carried on about the FI-WARE interfaces of the Connected specifications.

It is therefore extremely important to follow the activities of the WGs, consider adopting existing APIs and contribute to their extension with the outcomes from this FI-WARE work package.

ognised that some of activities in the W3C WGs mentioned above have relationships with other groups (in some cases with overlaps). The Wholesale Applications Community

is an organization that is creating a unified and open platform to allow mobile soto more easily write applications usable on a variety of devices, operating systems and networks. The

[OMTP] launched the initiative in 2008, and from July 2010, BONDI technology has moved into WAC and is being developed further within that organization. The

also lately merged with WAC. It is therefore important to consider the evolution of specifications of the WAC initiative.

Device Management specifications are designed for management of small

, and include the possibility to support the provisioningthe device including first time use, enabling and disabling features), the configuration of d

settings and parameters), the upgrade of Software (e.g. providing pplications and system software), and finally fault management (e.g. r

the device, query about status of device)

This has relevance for the remote management APIs of Connected Device GE.


WP7 Interface to the Network and Devices A number of activities concerned with accessing device capabilities are emerging from various standards

have an impact on the CDI GE specifications. A clear trend towards platform based APIs and open source operating systems can be seen.

is to create client-side APIs that enable cations that interact with device hardware, services and applications such as

the camera, microphone, system sensors, native address books, calendars and native messaging applications. The scope of this Working Group is creation of API specifications for a device’s services that can be exposed to Web applications. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

f this Geolocation WG charter is to enable Web access to the user's

WARE interfaces of the Connected

It is therefore extremely important to follow the activities of the WGs, consider adopting existing APIs and WARE work package.

ognised that some of activities in the W3C WGs mentioned above have Wholesale Applications Community

is an organization that is creating a unified and open platform to allow mobile software developers to more easily write applications usable on a variety of devices, operating systems and networks. The Open

launched the initiative in 2008, and from July 2010, BONDI developed further within that organization. The Joint It is therefore important to consider the evolution of

designed for management of small mobile devices such provisioning (i.e. configuration of

onfiguration of devices (i.e. new software and/or bug (e.g. reporting errors from


2.6.4 OpenFlow Concerning the FI-WARE GE "NetIC", a possible implementation of those specifications is for the control of virtual (software defined) networks. A standard control interface for virtual network is OpenFlow, defined by Open Networking Foundation.

OpenFlow enables networks to evolve by giving a remote controller the power to modify the behaviour of network devices, through a wellnow includes routers, switches, virtual switches, and access points from a range of vendors.

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switcwireless access points – and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being implemented by major vendors, with OpenFlow

OpenFlow enables easy deployment offor applications such as virtual machine mobility, highmobile networks.

To extend the control for any access technology, the OpenFlow standard must be extended to support circuit switched networks. NSN plans to


2.6.5 IETF RFC 4208 specifies the Generalized Multiresources and to provide network survivability using protection and restoration techniques. GMPLS extends MPLS to encompass timespatial switching (e.g. incoming port or fibre to outgoing port or fibre). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signalling and the routing part of that control plane.

In the FI-WARE NetIC interface, the resource reservation part of the functionality is already supported by GMPLS UNI.

It is also planned to use the already exis(Resource Reservation Protocol switched paths (LSPs) in MPLS (Multi

Summary: USE.

2.6.6 3GPP and ETSIThe S3C GE specifications are based on further development of EPC and IMS. The extension of S3C will be considered for contribution to the two standardisation bodies (or followis planned to monitor and if possibl

Summary: MONITOR (possibly CONTRIBUTE)

2.6.7 HGI Home Gateway Initiative (HGI) developed a number of requirements for those home gateways which are able to support a software execution environment (SWEX). In thatcreate modular software applications, Moreover, modular software applications must run in a dedicate

"NetIC", a possible implementation of those specifications is for the control of virtual (software defined) networks. A standard control interface for virtual network is OpenFlow,

y Open Networking Foundation.

OpenFlow enables networks to evolve by giving a remote controller the power to modify the behaviour of network devices, through a well-defined "forwarding instruction set". The growing OpenFlow ecosystem

switches, virtual switches, and access points from a range of vendors.

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switc

and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being

, with OpenFlow-enabled switches now commercially available.

ment of innovative routing and switching protocols in the network. It is used for applications such as virtual machine mobility, high-security networks and next genera

To extend the control for any access technology, the OpenFlow standard must be extended to support circuit switched networks. NSN plans to contribute the necessary extensions to the OpenFlow specification.

RFC 4208 specifies the Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fibre to outgoing port or fibre). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding

nes. The intention is to cover both the signalling and the routing part of that control plane.

WARE NetIC interface, the resource reservation part of the functionality is already supported by

It is also planned to use the already existing RSVP-TE functionalities as much as possible. RSVP – RFC 3209), including all the necessary extensions, establishes label

switched paths (LSPs) in MPLS (Multi-Protocol Label Switching – RFC 3031).

TSI-TISPAN The S3C GE specifications are based on further development of EPC and IMS. The extension of S3C will be considered for contribution to the two standardisation bodies (or follow-on organizations). Therefore it is planned to monitor and if possible to provide input towards 3GPP and ETSI-TISPAN.

Summary: MONITOR (possibly CONTRIBUTE)

Home Gateway Initiative (HGI) developed a number of requirements for those home gateways which are able to support a software execution environment (SWEX). In that approach, operators or third parties may create modular software applications, while the operator controls the remote deployment onto the devices. Moreover, modular software applications must run in a dedicated virtual execution environment, which

"NetIC", a possible implementation of those specifications is for the control of virtual (software defined) networks. A standard control interface for virtual network is OpenFlow,

OpenFlow enables networks to evolve by giving a remote controller the power to modify the behaviour of defined "forwarding instruction set". The growing OpenFlow ecosystem

switches, virtual switches, and access points from a range of vendors.

OpenFlow is an open standard that enables researchers to run experimental protocols in the campus networks we use every day. OpenFlow is added as a feature to commercial Ethernet switches, routers and

and provides a standardized hook to allow researchers to run experiments, without requiring vendors to expose the internal workings of their network devices. OpenFlow is currently being

enabled switches now commercially available.

innovative routing and switching protocols in the network. It is used security networks and next generation IP based

To extend the control for any access technology, the OpenFlow standard must be extended to support the necessary extensions to the OpenFlow specification.

Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. GMPLS

T/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fibre to outgoing port or fibre). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding

nes. The intention is to cover both the signalling and the routing part of that control plane.

WARE NetIC interface, the resource reservation part of the functionality is already supported by

TE functionalities as much as possible. RSVP ), including all the necessary extensions, establishes label-

The S3C GE specifications are based on further development of EPC and IMS. The extension of S3C will on organizations). Therefore it TISPAN.

Home Gateway Initiative (HGI) developed a number of requirements for those home gateways which are perators or third parties may

the operator controls the remote deployment onto the devices. d virtual execution environment, which


avoids conflicts and interferences with the natively installed software.requirements valid for any modular execution platform as well as technologycurrently for OSGi technology. applications and supporting use cases defined by HGI (currently, home energy management scenarios).

Summary: MONITOR

2.7 WP8 Security, Privacy, Trust

2.7.1 OASIS XACMLThe eXtensible Access Control Markup Language (XACML)declarative access control policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defined in policies.

Summary: USE

2.7.2 OASIS SAML 1

The Security Assertion Markup Language (SAML) is anauthentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

Summary: USE

2.7.3 IETF OAuth 1 OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.

OAuth allows users to hand out tokens instead of credentials to their data hosted by a given service provider. Each token grants access to a specific site for specific resources and for a defined duration. This allows a user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.

Summary: USE

2.7.4 OpenID FoundationOpenID is an open standard that describes how userseliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, anduse those accounts as the basis for signing on to any website which accepts OpenID authentication.

The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandfor approaches ranging from the common to the novel.

Summary: USE

conflicts and interferences with the natively installed software. The HGI requirements valid for any modular execution platform as well as technology

Developments are ongoing to study specific APIs to be offered to the applications and supporting use cases defined by HGI (currently, home energy management scenarios).

WP8 Security, Privacy, Trust

XACML1 ess Control Markup Language (XACML) is an OASIS standard

declarative access control policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defined in policies.

1 Assertion Markup Language (SAML) is an OASIS open standard for exchanging

authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).

OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out

s, typically username and password.

OAuth allows users to hand out tokens instead of credentials to their data hosted by a given service provider. Each token grants access to a specific site for specific resources and for a defined duration. This

user to grant a third party site access to their information stored with another service provider, without sharing their access permissions or the full extent of their data.

Foundation OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, anduse those accounts as the basis for signing on to any website which accepts OpenID authentication.

The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common to the novel.

documents reflect generic requirements valid for any modular execution platform as well as technology-specific requirements,

o study specific APIs to be offered to the applications and supporting use cases defined by HGI (currently, home energy management scenarios).

standard, which defines a declarative access control policy language implemented in XML and a processing model describing how to

open standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a

OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out

OAuth allows users to hand out tokens instead of credentials to their data hosted by a given service provider. Each token grants access to a specific site for specific resources and for a defined duration. This

user to grant a third party site access to their information stored with another service provider,

can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication.

The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither ate a specific means by which to authenticate users, allowing


2.7.5 OVAL Open Vulnerability and Assessment Language (OVAL®) is an international, information security, community standard to promotetransfer of this information across the entire spectrum of security tools and services. OVAL includes a language used to encode system details, and an assortment of content repositories community. The language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, conThe repositories are collections of publicly available and open content that utilize the language.

Summary: USE

2.7.6 NIST Common Vulnerability Scoring System (CVSS)CVSS is a vulnerability scoring system designed to provide an open and standardized method for rating IT vulnerabilities. CVSS helps organizations prioritize and coordinate a joint response to security vulnerabilities by communicating the base, temporal and environmental p

Summary: USE but also MONITOR keen interest in security vulnerabilities and use CVSS in their daily work.

Summary: MONITOR

2.7.7 IETF IntrusionIDMEF (Intrusion Detection Message Exchange Format) was designed and validated by IETF under an RFC to share information of interest for intrusion detection & protection systems.

Summary: USE

2.7.8 NIST RemediationThe Security Content Automation Protocol (SCAP, pronounced "essby leveraging a suite of individual standards intended to support the standardization of security measurement and expression to promote interoperseven standards (CVE, CCE, CPE, XCCDF, OVAL, OCIL and CVSS).

Currently the standards contained within SCAP focus on capabilities for the detection, description, scoring, and reporting of flaws, miscostandardization of actions to take in response to these vulnerability indicators. Standardizing remediation actions has recently become a topic of significant interest. NIST initiated this epublished IR-7670: “Proposed Open Specifications for an Enterprise Remediation Automation Framework”. This overview maps out several constituent standards:

• Common Remediation Enumeration (CRE) set of actions one could take in order to address a vulnerability, violation. Descriptions will be in prose (humanBecause any given vulnerability, etc., mimultiple CREs associated with any given issue. CRE describes the data that is required to support the technical use cases identified; it does not prescribe a database format, schema or presentation m

• CRE Data Exchange Format (CRE

metadata. This transport format allows the exchange of either the standard CRE list or organizationspecific CREs. The CRE data exchange format is envisioned as a lig

Open Vulnerability and Assessment Language (OVAL®) is an international, information security, community standard to promote open and publicly available security content, and to standardize the transfer of this information across the entire spectrum of security tools and services. OVAL includes a language used to encode system details, and an assortment of content repositories community. The language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified machine state (vulnerability, configuration, patch state, etc.); and reporting the results of this assessment. The repositories are collections of publicly available and open content that utilize the language.

Common Vulnerability Scoring System (CVSS)bility scoring system designed to provide an open and standardized method for rating IT

vulnerabilities. CVSS helps organizations prioritize and coordinate a joint response to security vulnerabilities by communicating the base, temporal and environmental properties of a vulnerability.

MONITOR through CVSS-SIG a group of security professionals who have a keen interest in security vulnerabilities and use CVSS in their daily work.

Intrusion Detection Message Exchang e Format (IDMEF)IDMEF (Intrusion Detection Message Exchange Format) was designed and validated by IETF under an RFC to share information of interest for intrusion detection & protection systems.

Remediation (Security Content Automation The Security Content Automation Protocol (SCAP, pronounced "ess-cap") is a broad program implemented by leveraging a suite of individual standards intended to support the standardization of security measurement and expression to promote interoperability of security products. The SCAP content leverages seven standards (CVE, CCE, CPE, XCCDF, OVAL, OCIL and CVSS).

Currently the standards contained within SCAP focus on capabilities for the detection, description, scoring, and reporting of flaws, misconfigurations, and attacks. However, to date there has been little standardization of actions to take in response to these vulnerability indicators. Standardizing remediation actions has recently become a topic of significant interest. NIST initiated this e

7670: “Proposed Open Specifications for an Enterprise Remediation Automation Framework”. This overview maps out several constituent standards:

Common Remediation Enumeration (CRE) – An enumeration where each entry willset of actions one could take in order to address a vulnerability, a wrong configuration, or violation. Descriptions will be in prose (human-comprehensible vs. machineBecause any given vulnerability, etc., might be dealt with in multiple ways, there will likely be multiple CREs associated with any given issue. CRE describes the data that is required to support the technical use cases identified; it does not prescribe a database format, schema or presentation m

CRE Data Exchange Format (CRE-DEF) – An exchange format for CRE entries and related metadata. This transport format allows the exchange of either the standard CRE list or organizationspecific CREs. The CRE data exchange format is envisioned as a lightweight, XML based schema that

Open Vulnerability and Assessment Language (OVAL®) is an international, information security, open and publicly available security content, and to standardize the

transfer of this information across the entire spectrum of security tools and services. OVAL includes a language used to encode system details, and an assortment of content repositories held throughout the community. The language standardizes the three main steps of the assessment process: representing configuration information of systems for testing; analyzing the system for the presence of the specified

figuration, patch state, etc.); and reporting the results of this assessment. The repositories are collections of publicly available and open content that utilize the language.

Common Vulnerability Scoring System (CVSS) bility scoring system designed to provide an open and standardized method for rating IT

vulnerabilities. CVSS helps organizations prioritize and coordinate a joint response to security roperties of a vulnerability.

a group of security professionals who have a

e Format (IDMEF) IDMEF (Intrusion Detection Message Exchange Format) was designed and validated by IETF under an

Security Content Automation Protocol) cap") is a broad program implemented

by leveraging a suite of individual standards intended to support the standardization of security ability of security products. The SCAP content leverages

Currently the standards contained within SCAP focus on capabilities for the detection, description, scoring, nfigurations, and attacks. However, to date there has been little

standardization of actions to take in response to these vulnerability indicators. Standardizing remediation actions has recently become a topic of significant interest. NIST initiated this effort and in April 2011

7670: “Proposed Open Specifications for an Enterprise Remediation Automation

An enumeration where each entry will describe one configuration, or a policy

comprehensible vs. machine-comprehensible) format. ght be dealt with in multiple ways, there will likely be

multiple CREs associated with any given issue. CRE describes the data that is required to support the technical use cases identified; it does not prescribe a database format, schema or presentation model.

An exchange format for CRE entries and related metadata. This transport format allows the exchange of either the standard CRE list or organization-

htweight, XML based schema that


serves as the standard import, export, and exchange format for basic remediation information as provided by CRE.

• Extended Remediation Information (ERI) Examples of relevant data could include references to CPEs, CVEs, and CCEs; prerequisites for the remediation action; extended descriptions of the remediation stepssuccessful and failed attempts to apply the remediation. ERI does not prescribe a database format or schema or any other presentation model. It simply identifies the additional data that may be required to support the identified technical use cases, beyond the base CRE entries.

• Extended Remediation Data Exchange Format (ERI

Information Data Exchange Format is proposed as a means of enabling efficient interchange of ERI data. The ERI data exchange format is envisioned as an XMLschema, allowing ERI documents to refer to the CRE entries they extend by CRE ID alone, or to contain the full contents of the CRE entry.

• Remediation Policy Specification (RPS) associate particular remediations with various classes or types of IT assets. Such a capability allows organizations to specify allowed, preferred, or required remediations for specified collections of IT assets. For example, RPS might filter CREs based on platform type, software inventory, vulnerability presence, configuration states, and functional or organizational categories.

• Remediation Tasking Language (RTL)

enact specific remediations on specific assets. RTL documents represent the output of the remediation decision process, and function as a standardized input format for remediation tools. Similar in concept to PLARR, RTL would be used to initiateshould be performed.

• Remediation Results – A language to encapsulate the results of a remediation attempt. Remediation Results convey the outcome (e.g., success/failure/error) of attempted remediatthe remediation tool. Remediation Results also enable rollsituational awareness.

This initial list of proposed standards and their contents is preliminary and may change as either the overall architecture or each standard is further refined.

Summary: MONITOR

serves as the standard import, export, and exchange format for basic remediation information as

Extended Remediation Information (ERI) – A dictionary with additional data about each CRE. Examples of relevant data could include references to CPEs, CVEs, and CCEs; prerequisites for the remediation action; extended descriptions of the remediation steps; and followsuccessful and failed attempts to apply the remediation. ERI does not prescribe a database format or schema or any other presentation model. It simply identifies the additional data that may be required to

ified technical use cases, beyond the base CRE entries.

Extended Remediation Data Exchange Format (ERI-DEF) – The Extended Remediation Information Data Exchange Format is proposed as a means of enabling efficient interchange of ERI

nge format is envisioned as an XML-based schema that extends the CRE schema, allowing ERI documents to refer to the CRE entries they extend by CRE ID alone, or to contain the full contents of the CRE entry.

Remediation Policy Specification (RPS) The Remediation Policy Specification defines how to associate particular remediations with various classes or types of IT assets. Such a capability allows organizations to specify allowed, preferred, or required remediations for specified collections of IT

For example, RPS might filter CREs based on platform type, software inventory, vulnerability presence, configuration states, and functional or organizational categories.

Remediation Tasking Language (RTL) – provides a standardized format to direct complianenact specific remediations on specific assets. RTL documents represent the output of the remediation decision process, and function as a standardized input format for remediation tools. Similar in concept to PLARR, RTL would be used to initiate remediations and control where and how those remediations

A language to encapsulate the results of a remediation attempt. Remediation Results convey the outcome (e.g., success/failure/error) of attempted remediatthe remediation tool. Remediation Results also enable roll-up reporting and provide enhanced

This initial list of proposed standards and their contents is preliminary and may change as either the overall rchitecture or each standard is further refined.

serves as the standard import, export, and exchange format for basic remediation information as

A dictionary with additional data about each CRE. Examples of relevant data could include references to CPEs, CVEs, and CCEs; prerequisites for the

; and follow-up actions for both successful and failed attempts to apply the remediation. ERI does not prescribe a database format or schema or any other presentation model. It simply identifies the additional data that may be required to

The Extended Remediation Information Data Exchange Format is proposed as a means of enabling efficient interchange of ERI

based schema that extends the CRE schema, allowing ERI documents to refer to the CRE entries they extend by CRE ID alone, or to

iation Policy Specification defines how to associate particular remediations with various classes or types of IT assets. Such a capability allows organizations to specify allowed, preferred, or required remediations for specified collections of IT

For example, RPS might filter CREs based on platform type, software inventory, vulnerability

provides a standardized format to direct compliant tools to enact specific remediations on specific assets. RTL documents represent the output of the remediation decision process, and function as a standardized input format for remediation tools. Similar in concept

remediations and control where and how those remediations

A language to encapsulate the results of a remediation attempt. Remediation Results convey the outcome (e.g., success/failure/error) of attempted remediation actions as reported by

up reporting and provide enhanced

This initial list of proposed standards and their contents is preliminary and may change as either the overall


3 WP Gap Analysis

3.1 IntroductionIn the previous chapter, the general suitability of various standardisation efforts in various SDOs was evaluated in terms of stable standards which can be USEdMONITORed and areas where FI

In the sections below, the FI-WARE requirements for each Interface, and for each GE, are analyzed to determine which standard (or openetc) is most relevant and what are the gaps in functionality between the existing status and what is needed within FI-WARE.

Based on that analysis, a number of action items will be creastandardization gaps, by adapting/creating standards to be "fit for purpose" within FI

This section can only be partially completed in Version 1Interfaces are closely defined towards the middle of the life of the project then this section can be made more comprehensive.

3.2 WP3 Application and Services Ecosystem

3.2.1 W3C Semantic Web ServicesThe most obvious candidate for standardizationto be limited regarding the direct benefit for the project. Some preliminary activities as preparation of later standardization might appear to be feasible. They include:

• The establishment of a community for beststandardization

• Provision of USDL in a living spec

Further activities are possible but have to be considered later in the project.

3.2.2 OMG Service Oriented ArchitectureDepending on the project results new insights in capturing business and operational aspects of service descriptions might become available for standardization. These would supplement the technical side of SoaML.

3.2.3 OASIS Service Description and DiscoveryThe business and operational aspects of service descriptions that are to be developed in the project might open up new insights for future versions of the OASIS reference models. However, the specific contributions are not yet clear.

3.3 WP4 Cloud HostingThe main concern in terms of standardization in the Cloud area is the lack of mature standards which can be expected to be widely adopted by the industry.that it makes no sense to list them for all SDOs.

Gap Analysis

Introduction In the previous chapter, the general suitability of various standardisation efforts in various SDOs was

in terms of stable standards which can be USEd, developing standards which need to be MONITORed and areas where FI-WARE partners are already active in CONTRIBUT

WARE requirements for each Interface, and for each GE, are analyzed to determine which standard (or open source specification or consortia specification or published Web API, etc) is most relevant and what are the gaps in functionality between the existing status and what is needed

Based on that analysis, a number of action items will be created within each WP, defined to fill those standardization gaps, by adapting/creating standards to be "fit for purpose" within FI

This section can only be partially completed in Version 1 of this document, but as Generic Enablers and osely defined towards the middle of the life of the project then this section can be made


W3C Semantic Web Services for standardization is USDL. However, activities rela

regarding the direct benefit for the project. Some preliminary activities as preparation of later standardization might appear to be feasible. They include:

The establishment of a community for best-practice, consisting of USDL

a living specification to prepare later standardization

Further activities are possible but have to be considered later in the project.

OMG Service Oriented Architecture on the project results new insights in capturing business and operational aspects of service

descriptions might become available for standardization. These would supplement the technical side of

Service Description and Discovery and operational aspects of service descriptions that are to be developed in the project might

open up new insights for future versions of the OASIS reference models. However, the specific

WP4 Cloud Hosting in terms of standardization in the Cloud area is the lack of mature standards which can

be expected to be widely adopted by the industry. There are so many "gaps" in the meaning of this chapter that it makes no sense to list them for all SDOs.

In the previous chapter, the general suitability of various standardisation efforts in various SDOs was , developing standards which need to be

WARE partners are already active in CONTRIBUT(E)ing.

WARE requirements for each Interface, and for each GE, are analyzed to source specification or consortia specification or published Web API,

etc) is most relevant and what are the gaps in functionality between the existing status and what is needed

ted within each WP, defined to fill those standardization gaps, by adapting/creating standards to be "fit for purpose" within FI-WARE.

, but as Generic Enablers and osely defined towards the middle of the life of the project then this section can be made


activities related to this topic are likely regarding the direct benefit for the project. Some preliminary activities as preparation of later

isting of USDL users as a precursor to

on the project results new insights in capturing business and operational aspects of service descriptions might become available for standardization. These would supplement the technical side of

and operational aspects of service descriptions that are to be developed in the project might open up new insights for future versions of the OASIS reference models. However, the specific

in terms of standardization in the Cloud area is the lack of mature standards which can There are so many "gaps" in the meaning of this chapter


It should be noted, however, when considering specific gaps of the standards outlined above, the following areas are of particular importance:

• Advanced resource management capabilities, such as QoS and placement considerations. While some of these capabilities are going to be included in the next version of OVF (placement and scaling considerations), they are immature and are still missing in the more recent and relevant specifications such as CIMI, OCCI and OpenStack API.

• Support for life cycle management of multiscaling. This support can be achieved either by extending an existing specification that deals with individual resources (such as CIMI, OCCI or OpenStack), or by adopting an additional standard designed to address this particular need (such as TOSCA).

In conclusion, standardization for Cloud Hosting is at an early phase and is too dynamic to allow a gap analysis at the time of writing of this report (January 2012). Many SDOs and protocols need to be monitored as summarized in the table in the Annex.

3.4 WP5 Internet of Things Service Enablement Standardization for IoT Service Enablement is at a midOMA NGSI, with a rather stable set of architectures and protocoare not yet suitable for all use cases. WP5 members will need to contribute significantly in both SDOs. Other SDOs will be monitored, as summarized in the Annex.

3.4.1 ETSI TC M2M The current version of ETSI M2M

• Devices

• Gateways

• Core Network or Backend

Some improvements are expected for a physical architecture using several layers of gateways and direct communication device-device or gateway

The current release of ETSI M2M is mainly focussed on data transport, while the data containers are considered as black boxes. However, in order to enable ETSI M2M systems that are intelligent brokers on an open market of M2M data, such M2M systems must be able to understand the data and know what are the types of the available devices.

The overall goal of this standardization activity is that M2M applications can run in any environment without the need for configuration. This imposes three new requirements on the ETSI M2M standard:

1. The contents of the data containers must be understandable for the M2M system

2. Discovery of M2M devices by semantic description must be supported

3. support for direct modelling of physic

In the current release, no semantic services are defined to simplify relationships between families of things which are in several vertical business areas. To fulfil areas represented by 8 Use Cases projects, some recommendations would be provided by partners involved into the ETSI M2M TC. More details would be available after the first implementation and testbed involving the Generic Enablers of “Internet of Thing

, when considering specific gaps of the standards outlined above, the following importance:

Advanced resource management capabilities, such as QoS and placement considerations. While some ing to be included in the next version of OVF (placement and scaling

considerations), they are immature and are still missing in the more recent and relevant specifications such as CIMI, OCCI and OpenStack API.

Support for life cycle management of multi-VM virtual appliances, including performancescaling. This support can be achieved either by extending an existing specification that deals with individual resources (such as CIMI, OCCI or OpenStack), or by adopting an additional standard

ed to address this particular need (such as TOSCA).

andardization for Cloud Hosting is at an early phase and is too dynamic to allow a gap analysis at the time of writing of this report (January 2012). Many SDOs and protocols need to be

nitored as summarized in the table in the Annex.

WP5 Internet of Things Service Enablement Standardization for IoT Service Enablement is at a mid-term phase in several SDOs, like ETSI M2M and OMA NGSI, with a rather stable set of architectures and protocols being available in some cases, but which are not yet suitable for all use cases. WP5 members will need to contribute significantly in both SDOs. Other SDOs will be monitored, as summarized in the Annex.

ETSI M2M technical specifications takes into account three

Some improvements are expected for a physical architecture using several layers of gateways and direct device or gateway-gateway which are suitable in a distributed environment.

The current release of ETSI M2M is mainly focussed on data transport, while the data containers are considered as black boxes. However, in order to enable ETSI M2M systems that are intelligent brokers on

of M2M data, such M2M systems must be able to understand the data and know what are the types of the available devices.

The overall goal of this standardization activity is that M2M applications can run in any environment iguration. This imposes three new requirements on the ETSI M2M standard:

The contents of the data containers must be understandable for the M2M system

Discovery of M2M devices by semantic description must be supported

support for direct modelling of physical entities as a higher abstraction layer

, no semantic services are defined to simplify relationships between families of things which are in several vertical business areas. To fulfil FI-WARE objectives to support all vertical businareas represented by 8 Use Cases projects, some recommendations would be provided by partners involved

More details would be available after the first implementation and testbed involving the Generic Enablers of “Internet of Things Service Enablement”.

, when considering specific gaps of the standards outlined above, the following

Advanced resource management capabilities, such as QoS and placement considerations. While some ing to be included in the next version of OVF (placement and scaling

considerations), they are immature and are still missing in the more recent and relevant specifications

M virtual appliances, including performance-driven auto-scaling. This support can be achieved either by extending an existing specification that deals with individual resources (such as CIMI, OCCI or OpenStack), or by adopting an additional standard

andardization for Cloud Hosting is at an early phase and is too dynamic to allow a gap analysis at the time of writing of this report (January 2012). Many SDOs and protocols need to be

WP5 Internet of Things Service Enablement term phase in several SDOs, like ETSI M2M and

ls being available in some cases, but which are not yet suitable for all use cases. WP5 members will need to contribute significantly in both SDOs.

three physical layers:

Some improvements are expected for a physical architecture using several layers of gateways and direct h are suitable in a distributed environment.

The current release of ETSI M2M is mainly focussed on data transport, while the data containers are considered as black boxes. However, in order to enable ETSI M2M systems that are intelligent brokers on

of M2M data, such M2M systems must be able to understand the data and know what are

The overall goal of this standardization activity is that M2M applications can run in any environment iguration. This imposes three new requirements on the ETSI M2M standard:


al entities as a higher abstraction layer

, no semantic services are defined to simplify relationships between families of things objectives to support all vertical business

areas represented by 8 Use Cases projects, some recommendations would be provided by partners involved More details would be available after the first implementation and testbed


3.4.2 OMA NGSI Focusing on OMA NGSI 9 and 10,

and the Data & Context Management Chapter reveal the need to define a RESTful binding for both NGSI 9 and 10. A requirement of the IoT chapter in particular is to make use of the resource concept in order to define simple convenience functions for basic interactions like getting or setting single attribute values

3.5 WP 6 Data/Context Management ServicesNGSI 10 and NGSI 9 are not suand therefore significant progress is needed. The WP6 members have set up some internal workshops and a mailing list in order to work out a soassess potential modifications of the standard by including it as a cornerstone of the FIin software development and in testbed trials. As a result, proposals for potential modification to the standard are envisaged.

BigData is not considered per-se as a standalone topic within SDOs. However, the WP6 team will continue monitoring to identify partnerships/initiatives in this regard during the project lifetime. In the event that a cooperation project/initiative relateand potential contributions.

3.6 WP7 Interface to the Network and DevicesSpecification of FI-WARE S3C and NetIC GEs are currently based on standard tracks. For the time being no extra action is planned, however this might change in the lifebecome specified in more detail.

3.6.1 W3C In FI-WARE Connected Device GEalready defined by W3C specifications. Indeed, this is one of the expected goals for Connected Devices GE specifications.

For instance, the API to provide QoS/QoE and mobility management are missing from the standard, and are expected to be contributed.

3.6.2 OMA Device ManagementConcerning the specifications of FIinterface, although its evolution plans to support it. To this extent, adoption in the CDI GE specs would favour the introduction of such API in that SDO.

3.6.3 HGI Currently, HGI defined generic requirements for the execution environment and some more specifically for a single implementation, based on OSGi framework. While the general objective of the forum is to define functional requirements only, the current status needs soresults towards the actual implementation. The ongoing activity on APIs for home energy management is a possible example of this, but this kind of additional development should be extended to other use cases apossible applications, independently of the “place” where applications are deployed (on the home gateway, in the cloud etc).

Focusing on OMA NGSI 9 and 10, technical bindings are not defined up to now. Both the IoT chapter and the Data & Context Management Chapter reveal the need to define a RESTful binding for both NGSI 9

the IoT chapter in particular is to make use of the resource concept in order to define simple convenience functions for basic interactions like getting or setting single attribute values

WP 6 Data/Context Management ServicesNGSI 10 and NGSI 9 are not sufficient to develop and implement the concepts envisioned by FIand therefore significant progress is needed. The WP6 members have set up some internal workshops and a mailing list in order to work out a so-called "FI-WARE NGSI implementation definitiassess potential modifications of the standard by including it as a cornerstone of the FIin software development and in testbed trials. As a result, proposals for potential modification to the

se as a standalone topic within SDOs. However, the WP6 team will continue monitoring to identify partnerships/initiatives in this regard during the project lifetime. In the event that a cooperation project/initiative related to BigData standardization arises, the team will consider membership

WP7 Interface to the Network and DevicesWARE S3C and NetIC GEs are currently based on standard tracks. For the time being

ion is planned, however this might change in the life-time of the project as the implementations

Connected Device GE, the specification of further APIs is plannedcifications. Indeed, this is one of the expected goals for Connected Devices GE

For instance, the API to provide QoS/QoE and mobility management are missing from the standard, and

Device Management ning the specifications of FI-WARE CDI GE, currently OMA DM does not provide a RESTful

interface, although its evolution plans to support it. To this extent, adoption in the CDI GE specs would favour the introduction of such API in that SDO.

HGI defined generic requirements for the execution environment and some more specifically for a single implementation, based on OSGi framework. While the general objective of the forum is to define functional requirements only, the current status needs some more development in order to provide useful results towards the actual implementation. The ongoing activity on APIs for home energy management is a possible example of this, but this kind of additional development should be extended to other use cases apossible applications, independently of the “place” where applications are deployed (on the home gateway,

up to now. Both the IoT chapter and the Data & Context Management Chapter reveal the need to define a RESTful binding for both NGSI 9

the IoT chapter in particular is to make use of the resource concept in order to define simple convenience functions for basic interactions like getting or setting single attribute values

WP 6 Data/Context Management Services fficient to develop and implement the concepts envisioned by FI-WARE

and therefore significant progress is needed. The WP6 members have set up some internal workshops and a WARE NGSI implementation definition". The project will

assess potential modifications of the standard by including it as a cornerstone of the FI-WARE architecture, in software development and in testbed trials. As a result, proposals for potential modification to the

se as a standalone topic within SDOs. However, the WP6 team will continue monitoring to identify partnerships/initiatives in this regard during the project lifetime. In the event that a

d to BigData standardization arises, the team will consider membership

WP7 Interface to the Network and Devices WARE S3C and NetIC GEs are currently based on standard tracks. For the time being

time of the project as the implementations

is planned, compared to those cifications. Indeed, this is one of the expected goals for Connected Devices GE

For instance, the API to provide QoS/QoE and mobility management are missing from the standard, and

WARE CDI GE, currently OMA DM does not provide a RESTful interface, although its evolution plans to support it. To this extent, adoption in the CDI GE specs would

HGI defined generic requirements for the execution environment and some more specifically for a single implementation, based on OSGi framework. While the general objective of the forum is to define

me more development in order to provide useful results towards the actual implementation. The ongoing activity on APIs for home energy management is a possible example of this, but this kind of additional development should be extended to other use cases and possible applications, independently of the “place” where applications are deployed (on the home gateway,


3.7 WP8 Security, Privacy, TrustIn the context of the Security area a number of relevant standards have been outlined as per SectioAccording to the analysis the Security Team conducted so far (i.e. in view of requirements known) it appears that no major gap has been detected for what concerns most of the Security GEs (including core GEs aka IdM, Privacy and Data Handling). Thistandards needed for each of these GEs. Of course this doesn’t presume from the fact that additional requirements may come from UC projects highlighting some gaps to be covered.

One interesting finding that came out of our analysis is that even in the field of Cyber Security there is initiative to close major gaps. This is especially true of the NIST initiative aiming a completing the SCAP standards focusing on capabilities for the detection, descriptiomisconfigurations, and attacks by a set of additional ones targeting the standardization of actions to take in response to the vulnerability indicators.remediations actions is a hot topic in the context of the Security Monitoring we are aiming at within FIWARE. Complementary to this we also have identified the following gaps for which we will monitor relevant SDOs activities:

• Taking account of new vulnera

• Taking account in CVSS of business impact in the scoring of vulnerabilities

One other gap that would be covered but here resulting from a joint work between WP3 and WP8 would be to develop Security extension to

WP8 Security, Privacy, Trust In the context of the Security area a number of relevant standards have been outlined as per SectioAccording to the analysis the Security Team conducted so far (i.e. in view of requirements known) it appears that no major gap has been detected for what concerns most of the Security GEs (including core GEs aka IdM, Privacy and Data Handling). This mainly due to level of maturity reached by relevant standards needed for each of these GEs. Of course this doesn’t presume from the fact that additional requirements may come from UC projects highlighting some gaps to be covered.

that came out of our analysis is that even in the field of Cyber Security there is initiative to close major gaps. This is especially true of the NIST initiative aiming a completing the SCAP

focusing on capabilities for the detection, description, scoring, and reporting of flaws, misconfigurations, and attacks by a set of additional ones targeting the standardization of actions to take in response to the vulnerability indicators. This is a work we will monitor being said that standardization of emediations actions is a hot topic in the context of the Security Monitoring we are aiming at within FIWARE. Complementary to this we also have identified the following gaps for which we will monitor

Taking account of new vulnerabilities in CVE (e.g. ones issued from IoT),

Taking account in CVSS of business impact in the scoring of vulnerabilities

One other gap that would be covered but here resulting from a joint work between WP3 and WP8 would be to develop Security extension to USDL (Unified Service Description Language).

In the context of the Security area a number of relevant standards have been outlined as per Section B2.7. According to the analysis the Security Team conducted so far (i.e. in view of requirements known) it appears that no major gap has been detected for what concerns most of the Security GEs (including core

s mainly due to level of maturity reached by relevant standards needed for each of these GEs. Of course this doesn’t presume from the fact that additional

that came out of our analysis is that even in the field of Cyber Security there is initiative to close major gaps. This is especially true of the NIST initiative aiming a completing the SCAP

n, scoring, and reporting of flaws, misconfigurations, and attacks by a set of additional ones targeting the standardization of actions to take in

This is a work we will monitor being said that standardization of emediations actions is a hot topic in the context of the Security Monitoring we are aiming at within FI-WARE. Complementary to this we also have identified the following gaps for which we will monitor

One other gap that would be covered but here resulting from a joint work between WP3 and WP8 would be


4 WP Strategy: StandardizPackage

4.1 IntroductionThe goal of this section is to definespecific partners, taking account of existin

Based on discussions between experts within each SDO, the action items will be organized into a timetable matching the pace of step-by-step development of functionalities within FImeetings of each SDO.

At the time of writing the first version of this report, only general plans can so far be presented.

4.2 WP3 Application and Services EcosystemGenerally, the standardization strategy of WP3 consists in monitoring the specified standardization initiatives and constantly checking the available project results for possible contributions. Regarding our focus on standardization of USDL the following proceeding is possible:

• Establishing a community of USDL users (as currently started on linked

• Supporting communities to conduct show cases, apps and mashups (providing the basic infrastructure for USDL apps such as repository, discovery, editors,...);

• Building USDL into products/services and solutions at SAP and other partners;

• Finding industrial/commercial users (big companies), which support a standardization,

• Identifying the right standardization body or create one and facilitate standardization process

4.3 WP4 Cloud Hosting As mentioned in previous sectionsindustry over time as it matures. We will monitor the advancements in the relevant standardization activities mentioned above -- all of which are already actively promoted by our companies. In the first release of FI-WARE, we will focus on contribution to OpenStack API, OCCI and CDMI. However, based on developments in this emerging area, we may adapt our strategy accordingly towards the second and the third releases.

4.4 WP5 Internet of Things Service EnablementAs identified in the Gap Analysis sections, the work in the IoT chapter seeks to enable an intelligent broker of M2M/IoT information. In order to achieve this, an IoT/M2M systems must be able to understand the data and know the types of the available devices. In order to achiepackage (NEC, TI, Orange, with support from other ETIS members) have started a study item in ETSI TC M2M called “Study on Semantic support for M2M Datareference: PWI_M2M_20120105_1_v1)

For clarification: in ETSI standardisation work, every new topic is given a name and ID starting with "Work Item" or WI. Furthermore, a WI is usually classified according to the phase of the work: Study Item or Feasibility Study is Phase 0 (i.e. discusis phase 2, and a WI for clearly defining protocols or testing is phase 3.

WP Strategy: Standardiz ation Plan by Work

Introduction define a WP Strategy by assigning the action items needed in each SDO to

specific partners, taking account of existing partner resources within various SDOs

Based on discussions between experts within each SDO, the action items will be organized into a timetable step development of functionalities within FI-WARE R&D and the pace of

the first version of this report, only general plans can so far be presented.

WP3 Application and Services EcosystemGenerally, the standardization strategy of WP3 consists in monitoring the specified standardization

iatives and constantly checking the available project results for possible contributions. Regarding our focus on standardization of USDL the following proceeding is possible:

Establishing a community of USDL users (as currently started on linked-usdl.org);

Supporting communities to conduct show cases, apps and mashups (providing the basic infrastructure for USDL apps such as repository, discovery, editors,...);

Building USDL into products/services and solutions at SAP and other partners;

commercial users (big companies), which support a standardization,

Identifying the right standardization body or create one and facilitate standardization process

WP4 Cloud Hosting in previous sections, it is still not clear which standards will be adopted by the Cloud

industry over time as it matures. We will monitor the advancements in the relevant standardization all of which are already actively promoted by our companies. In the first

ll focus on contribution to OpenStack API, OCCI and CDMI. However, based on developments in this emerging area, we may adapt our strategy accordingly towards the second and the

WP5 Internet of Things Service EnablementGap Analysis sections, the work in the IoT chapter seeks to enable an intelligent broker

of M2M/IoT information. In order to achieve this, an IoT/M2M systems must be able to understand the data and know the types of the available devices. In order to achieve this, members from the IoT work package (NEC, TI, Orange, with support from other ETIS members) have started a study item in ETSI TC

Study on Semantic support for M2M Data” (WI Reference: reference: PWI_M2M_20120105_1_v1). #

For clarification: in ETSI standardisation work, every new topic is given a name and ID starting with "Work Item" or WI. Furthermore, a WI is usually classified according to the phase of the work: Study Item or Feasibility Study is Phase 0 (i.e. discussion); a Requirements WI is phase 1, an Architecture description is phase 2, and a WI for clearly defining protocols or testing is phase 3.

ation Plan by Work

a WP Strategy by assigning the action items needed in each SDO to g partner resources within various SDOs

Based on discussions between experts within each SDO, the action items will be organized into a timetable WARE R&D and the pace of

the first version of this report, only general plans can so far be presented.

WP3 Application and Services Ecosystem Generally, the standardization strategy of WP3 consists in monitoring the specified standardization

iatives and constantly checking the available project results for possible contributions. Regarding our

usdl.org);

Supporting communities to conduct show cases, apps and mashups (providing the basic infrastructure

Building USDL into products/services and solutions at SAP and other partners;

commercial users (big companies), which support a standardization,

Identifying the right standardization body or create one and facilitate standardization process

ill be adopted by the Cloud industry over time as it matures. We will monitor the advancements in the relevant standardization

all of which are already actively promoted by our companies. In the first ll focus on contribution to OpenStack API, OCCI and CDMI. However, based

on developments in this emerging area, we may adapt our strategy accordingly towards the second and the

WP5 Internet of Things Service Enablement Gap Analysis sections, the work in the IoT chapter seeks to enable an intelligent broker

of M2M/IoT information. In order to achieve this, an IoT/M2M systems must be able to understand the ve this, members from the IoT work

package (NEC, TI, Orange, with support from other ETIS members) have started a study item in ETSI TC ” (WI Reference: DTR/M2M-00017, PWI

For clarification: in ETSI standardisation work, every new topic is given a name and ID starting with "Work Item" or WI. Furthermore, a WI is usually classified according to the phase of the work: Study Item

sion); a Requirements WI is phase 1, an Architecture description


The overall goal of this standardization activity is that M2M applications can run in any environment without the need for configuration. This imposes three new requirements on the ETSI M2M standard:

1. The contents of the data containers must be understandable for the M2M system

2. Discovery of M2M devices by semantic description must be supported

3. Support for direct modellin

The WI has been discussed in the September and November meetings of ETSI M2M. It was approved in the ETSI TC M2M meeting in January. FI

FI-Ware WP5 and WP6 has identified the OMA NGSI Context API (short: NGSIimportant APIs for their work packages, either as internal working APIs or as an API exposed to application developers. One of the identified actions for standardisation is tAPI (which is currently missing). Furthermore, the WPs already identified ambiguities and missing features. They will carefully analyze whether it makes sense to bring these enhancements to standardization. A joint standardiinvolved OMA members.

4.5 WP6 Data/Context ServicesAs described in the previous chapter, there is an ongoing task to harmonize IoT GEs and Data GEs communications by the means of REST bindiand NGSI-10 standards. The current proposed chapter a potential evolution of OMAbe developed and assessed by various GEs within FIsuccessful and provide also a better consortium will consider to promote this in OMA and push for

Some specific Data/Context GEs based on existing assets, such as the Multimedia Analysis GE contributions to ISO JPEG/MPEG WGs, have already considered in their FIcontribution to standards (whenever the partnproject). In this specific case, those partners will keep on contributing as they were, thereby including the architecture evolution obtained as a result of their tasks in FIthem will also include requirements needed for the interaction with other GEs and the overall coreplatform.

Regarding BigData, the strategy plan is to keep our eyes open to identify potential standard tracks or working groups dealing with this specific topic and to then consider participating and/or contributing.

4.6 WP7 Interface to the Network and DevicesAlthough for some of activities concerning the interfaces to the Network and Devices it is not fully definedfor those cases where a more mature direction is already undertaken, the strategy to contribute to SDOs is based on three steps.

First of all, the gaps identified in the standard specifications with respect to the FIfunctionality will be considered; in a second steppartners to the relevant SDO will be evaluated; finally a bring the actual contribution to the attention of SDOs.

In some cases, the work package(e.g. W3C for device API), and one option under analysis is to join the effort (and the partners) to maximise the probability to succeed in presenting updates to current standards.

The overall goal of this standardization activity is that M2M applications can run in any environment ed for configuration. This imposes three new requirements on the ETSI M2M standard:


Discovery of M2M devices by semantic description must be supported

Support for direct modelling of physical entities as a higher abstraction layer

The WI has been discussed in the September and November meetings of ETSI M2M. It was approved in the ETSI TC M2M meeting in January. FI-Ware output will be directly influencing this study item.

P5 and WP6 has identified the OMA NGSI Context API (short: NGSIimportant APIs for their work packages, either as internal working APIs or as an API exposed to application developers. One of the identified actions for standardisation is to define a REST binding for the API (which is currently missing). Furthermore, the WPs already identified ambiguities and missing features. They will carefully analyze whether it makes sense to bring these enhancements to standardization. A joint standardization proposal is possible, but would need an early alignment of the

WP6 Data/Context Services As described in the previous chapter, there is an ongoing task to harmonize IoT GEs and Data GEs communications by the means of REST bindings for the NGSI API, which are currently absent in NGSI

10 standards. The current proposed strategy within WP6 is to investigate together with IoT chapter a potential evolution of OMA-NGSI, something that we would call "FI-WARE NGSI" specs and

by various GEs within FI-WARE testbed trials. If those specifications are and provide also a better communication with FI-WARE customers, then the FI

consortium will consider to promote this in OMA and push for standardization.

Some specific Data/Context GEs based on existing assets, such as the Multimedia Analysis GE contributions to ISO JPEG/MPEG WGs, have already considered in their FI-WARE tasks a strategy for the contribution to standards (whenever the partners were involved in such activities prior to the kickproject). In this specific case, those partners will keep on contributing as they were, thereby including the architecture evolution obtained as a result of their tasks in FI-WARE. However, them will also include requirements needed for the interaction with other GEs and the overall core

Regarding BigData, the strategy plan is to keep our eyes open to identify potential standard tracks or with this specific topic and to then consider participating and/or contributing.

WP7 Interface to the Network and Devicesfor some of activities concerning the interfaces to the Network and Devices it is not fully defined

more mature direction is already undertaken, the strategy to contribute to SDOs is

the gaps identified in the standard specifications with respect to the FIfunctionality will be considered; in a second step, the possibilities to contribute through the FIpartners to the relevant SDO will be evaluated; finally a consultation amongst bring the actual contribution to the attention of SDOs.

work package partners are aware of other initiatives providing updates to specific SDOs (e.g. W3C for device API), and one option under analysis is to join the effort (and the partners) to maximise the probability to succeed in presenting updates to current standards.

The overall goal of this standardization activity is that M2M applications can run in any environment ed for configuration. This imposes three new requirements on the ETSI M2M standard:


g of physical entities as a higher abstraction layer

The WI has been discussed in the September and November meetings of ETSI M2M. It was approved in Ware output will be directly influencing this study item.

P5 and WP6 has identified the OMA NGSI Context API (short: NGSI-9 and NGSI-10) as important APIs for their work packages, either as internal working APIs or as an API exposed to

o define a REST binding for the API (which is currently missing). Furthermore, the WPs already identified ambiguities and missing features. They will carefully analyze whether it makes sense to bring these enhancements to

zation proposal is possible, but would need an early alignment of the

As described in the previous chapter, there is an ongoing task to harmonize IoT GEs and Data GEs ngs for the NGSI API, which are currently absent in NGSI-9

within WP6 is to investigate together with IoT WARE NGSI" specs and to

WARE testbed trials. If those specifications are WARE customers, then the FI-WARE

Some specific Data/Context GEs based on existing assets, such as the Multimedia Analysis GE WARE tasks a strategy for the

ers were involved in such activities prior to the kick-off of the project). In this specific case, those partners will keep on contributing as they were, thereby including the

WARE. However, at some point some of them will also include requirements needed for the interaction with other GEs and the overall core-

Regarding BigData, the strategy plan is to keep our eyes open to identify potential standard tracks or with this specific topic and to then consider participating and/or contributing.

WP7 Interface to the Network and Devices for some of activities concerning the interfaces to the Network and Devices it is not fully defined,

more mature direction is already undertaken, the strategy to contribute to SDOs is

the gaps identified in the standard specifications with respect to the FI-WARE added the possibilities to contribute through the FI-WARE

the relevant partners will

are aware of other initiatives providing updates to specific SDOs (e.g. W3C for device API), and one option under analysis is to join the effort (and the partners) to


4.7 WP8 Security, Privacy, TrustAs mentioned in previous sectionsthe Security (focusing on Core GEs). In the meantime we relevant standardization activities mentioned abovebe to use and/or monitor standards we identified as relevant and adapt our strategy for third releases in case new needs would appear

rity, Privacy, Trust in previous sections, we plan to use a number of existing standards meeting the core needs of

the Security (focusing on Core GEs). In the meantime we will also monitor the advancements in the ities mentioned above. Our strategy for the first release of FI

be to use and/or monitor standards we identified as relevant and adapt our strategy for in case new needs would appear.

we plan to use a number of existing standards meeting the core needs of monitor the advancements in the

. Our strategy for the first release of FI-WARE will thus be to use and/or monitor standards we identified as relevant and adapt our strategy for the second and the


4.8 Summary Table of WP, SDO, Work

Package

Task(s) Partner for

this Task

Relevant major research or implementation goals in this WP and Task:

2 • Global High Level Architecture • Interfaces between GEs (west-bound, south-bound)• Interfaces exposed by GEs to outside stake holders. (north bound)• Security by design for the FI-WARE platform• Give input to the Standardization task (T11.4) as to the architecturastandardized. • Follow up the work performed by the research and development work packages (WP3WP09) to ensure compliance of components and ease integration phase• A special deliverable on state-of-the-art emerging technologies wilyear. The R&D centres will be in charge of this task

3 Role of Partners: • EAB: Composition engine for run-time selection of MACs and eventcreation/modification of orchestrations. • DT: Provision of a Mashup Studio for easy service creation.• THALES: Data, protocol, and process mediation for highly dynamic cases like service discovery at execution time. • TI: Provision of a modular platform (e.g. OSGiservices and service composition engines. A SCA based service composition engine based on Service oriented paradigms and standards exposing infrastructural services and Telco Capabilities, supporting the deployment in the clo• SAP: Process Modelling and Language Extensions for IoT.• ATOS: Component for the adaptive parametric automation of common modelling tasks at design time. That component will automate some prone to error and consuming modelling tasks performed by end-users using FI-WARE Instance modOryx web based collaborative process modelling editor. Additionally, Linked Open Services best practices and technologies developed by SOA4All will be reused and extended. • UPM: Provision of a mashup platform and a gadget dcentred gadget/mashup creation and execution. UPM will bring both expertise and results in this area.

3 3.1 UPM Mashup and Gadget Description Languages

3 3.1 UPM Mashup and Gadget Description Languages

3 3.1 Thales Data, protocol, and process mediation for highly dynamic cases like service discovery at execution time.

4 4 All IBM; Role of partners: • INTEL: Leads this task in close partnership with other task partners. They will bring key experience with securing virtual stacks, implementing mstandardisation and engaging industry initiatives.• INRIA: will contribute expertise in Type 1 hypervisors (bare metal) XenServer, HyperxVM Server, VMware ESX/ESXi, Xen OSS and Type 2 hypervisors (hosted) Virtualbox, VMware Server, KVM • IBM-IL: will provide a virtualization performance analysis and tuning tool based on the monitoring system to allow performance testing of the running system

4 4.2 IBM-IL

4 4.4 IBM-IL 4 4.4 IBM-IL 4 4.4 IBM-IL

SDO, Partner Comments

Relevant major research or implementation goals in this WP and Task: Relevant SDO Relevant work

group or specific

interface or protocol

Main overlap of WG with Task R&D

bound) • Interfaces exposed by GEs to outside stake holders. (north bound)

WARE platform • Give input to the Standardization task (T11.4) as to the architectural specifications to be

• Follow up the work performed by the research and development work packages (WP3-WP09) to ensure compliance of components and ease integration phase

art emerging technologies will be produced every year. The R&D centres will be in charge of this task

time selection of MACs and event-driven

for easy service creation. • THALES: Data, protocol, and process mediation for highly dynamic cases like service

• TI: Provision of a modular platform (e.g. OSGi-based) for hosting various kinds of ion engines. A SCA based service composition engine based

on Service oriented paradigms and standards exposing infrastructural services and Telco Capabilities, supporting the deployment in the cloud and enabling PaaS scenarios

Language Extensions for IoT. • ATOS: Component for the adaptive parametric automation of common modelling tasks at design time. That component will automate some prone to error and consuming modelling

WARE Instance modelling editors, in particular a Oryx web based collaborative process modelling editor. Additionally, Linked Open Services best practices and technologies developed by SOA4All will be reused and

• UPM: Provision of a mashup platform and a gadget development studio for end-user-centred gadget/mashup creation and execution. UPM will bring both expertise and results in

OpenAjax Alliance Gadgets Task Force / Security Task Force

The OpenAjax Alliance's Gadget TF is working on Metadata standards for mashup technology. The Security TF launched in 2009 a new initiative around mashup authentication an authorization.

Open Mashup Alliance Interest Group

EMML is an initiative towards the development of a Declarative Domain Specific Language designed specifically for mashups

Data, protocol, and process mediation for highly dynamic cases like service discovery at OMG BPMN2 OMG BPMN2 processes will be used in the Application and Services Ecosystem and Delivery Framework for workflowProcess Modelling Notation (BPMN) provides businesses with the capability their internal business procedures in a graphical notation

• INTEL: Leads this task in close partnership with other task partners. They will bring key experience with securing virtual stacks, implementing monitoring systems, API design,

and engaging industry initiatives. • INRIA: will contribute expertise in Type 1 hypervisors (bare metal) XenServer, Hyper-V, xVM Server, VMware ESX/ESXi, Xen OSS and Type 2 hypervisors (hosted) Virtualbox,

IL: will provide a virtualization performance analysis and tuning tool based on the monitoring system to allow performance testing of the running system

IBM (Management of virtualized resources and workloads in a Cloud environme

SNIA CDMI CDMI is the emerging standard for managing storage services, including object storage (which we offer as a service).

DMTF OVF OVF is the main standard used to package and deploy virtual appliances in a cloud DMTF CIMI CIMI is the emerging standard for provisioning and life cycle of cloud resourcesOGF OCCI OCCI is the emerging cloud interoperability API


nAjax Alliance's Gadget TF is working on Metadata standards for mashup technology. The Security TF launched in 2009 a new initiative around mashup authentication

EMML is an initiative towards the development of a Declarative Domain Specific Language designed specifically for mashups

OMG BPMN2 processes will be used in the Application and Services Ecosystem and Delivery Framework for workflow-based composition of applications. Indeed, a standard Business Process Modelling Notation (BPMN) provides businesses with the capability of understanding their internal business procedures in a graphical notation IBM (Management of virtualized resources and workloads in a Cloud environment)

CDMI is the emerging standard for managing storage services, including object storage (which

OVF is the main standard used to package and deploy virtual appliances in a cloud CIMI is the emerging standard for provisioning and life cycle of cloud resources OCCI is the emerging cloud interoperability API


Work

Package

Task(s) Partner for

this Task


4 4.4 IBM-IL 4 4.4 IBM-IL

4 4.4 IBM-IL 4 4.5 IBM-IL 4 4.5 IBM-IL 5 5 All France

Telecom – Orange Telecom Italia NSN NEC

5 5 All France Telecom – Orange

5 5 All Ericsson 5 5.1 Telecom

Italia Design and implementation of a Connection Protocol Adapter for the Fronton the standard ZigBee Gateway Specification for the connectivity between the IoT Services Enablement Platform and the Cloud Edge defined in WP7 (Interface to Networks and Devices).

5 5.1 Telecom Italia

Design and implementation of a Connection Protocol Adapter for ton the standard ETSI M2M (not fully compliant).

5 5.1 NSN Device/gateway communication, asset management5 5.1 Telecom

Italia

5 5.1 France Telecom – Orange

5 5.1 Ericsson Design and implementation of a Connection Protocol Adapter for the IoT gateway Frontend GE based on CoAP

5 5.1 Ericsson Design and implementation of a Communication Abstract Protocol Definition5 5.1 Ericsson 5 5.2 NSN Configuration Management 5 5.2 NEC Design and implementation of Mechanism for Management, discovery, and resolution of

(virtual representations of) real-world things. 5 5.3 NEC (Actuation) 5 5.3 France

Telecom – Orange

(Actuation)


5 5.3 NSN Message handling, data and event processing

5 5.4 NSN Message handling, data and event processing


Implementation of High-level Interface for accessing IoT information.

5 5.4 NEC Implementation of High-level Interface for accessing IoT information.

6 6 All Telecom Italia




group or specific



OGF OCCI OCCI is the emerging cloud interoperability APISNIA CDMI CDMI is the emerging standard for managing storage services, including object storage (which

we offer as a service). OASIS TOSCA TOSCA is the emerging standard dealing with definition and life cycle of composite servicDMTF OVF OVF is the main standard used to package and deploy virtual appliances in a cloud DMTF CIMI CIMI is the emerging standard for provisioning and life cycle of cloud resourcesETSI M2M FT (Technical Specifications which are stable should provide southbound and northbound

interfaces to federate some existing vertical standards. The first implementations of these interfaces should provide an interoperable layNetwork and Gateway side, also suitable for management tasks); TI, NSN, NEC (Interface between the Platform/Backend and the Gateway or IoT Compliant Devices side. It is also suitable for management tasks);TI (Work Item 14: Interworking between the M2M Architecture and M2M Area Network technologies); NSN (Network to Device/Gateway interfaces and resource model)

ETSI M2M The subset of ETSI M2M restful binding is under discuss

ETSI M2M mId ETSI M2M Interface between Network and Gateway side,Design and implementation of a Connection Protocol Adapter for the Front-end GE based

pecification for the connectivity between the IoT Services Enablement Platform and the Cloud Edge defined in WP7 (Interface to Networks

ZigBee Alliance

Design and implementation of a Connection Protocol Adapter for the Front-end GE based on the standard ETSI M2M (not fully compliant).

ZigBee Alliance

Device/gateway communication, asset management

ZigBee Alliance TI (ZigBee Gateway Specification and ZigBee Clusters Definitconnect Home Automation Networks to the IoT)

3GPP M2M FT (Some evolutions of standards are required especially to integrate lowinto 4G releases. This should be evaluated b

Design and implementation of a Connection Protocol Adapter for the IoT gateway Front- IETF CoRE Embedded web services for IoT devices

ication Abstract Protocol Definition IETF ROLL RPL

Design and implementation of Mechanism for Management, discovery, and resolution of

OMA NGSI NGSI-9./10 OMA NGSI NGSI-10 FT (OMA NGSI-10 has been agreed inside FI

applications especially to collect all evenand that could be stored in a generic way and for huge amount of data.)

OMA NGSI FT (RESTful binding specification)

OMA NGSI NSN (RESTful binding specification)

level Interface for accessing IoT information.

l Interface for accessing IoT information. OMA NGSI NEC (OMA NGSI-10 has been agreed inside FIapplications and between WP5/WP6 (Data and Context Management) )

OMA Content Delivery TI (Definition of the framework for brokerage of the Social Networks and for enabling Augmented Reality)

W3C Federated Social Web TI (Support for interoperable Social Networks)

W3C POI Working Group TI (Specification of description of Points of Interests (POI) on the Web)


OCCI is the emerging cloud interoperability API CDMI is the emerging standard for managing storage services, including object storage (which

TOSCA is the emerging standard dealing with definition and life cycle of composite services OVF is the main standard used to package and deploy virtual appliances in a cloud CIMI is the emerging standard for provisioning and life cycle of cloud resources FT (Technical Specifications which are stable should provide southbound and northbound interfaces to federate some existing vertical standards. The first implementations of these interfaces should provide an interoperable layer fruitful for several usages areas (between Network and Gateway side, also suitable for management tasks); TI, NSN, NEC (Interface between the Platform/Backend and the Gateway or IoT Compliant Devices side. It is also suitable for management tasks); (Work Item 14: Interworking between the M2M Architecture and M2M Area Network

NSN (Network to Device/Gateway interfaces and resource model) The subset of ETSI M2M restful binding is under discussion till end of January 2012

ETSI M2M Interface between Network and Gateway side,

TI (ZigBee Gateway Specification and ZigBee Clusters Definitions give a set of interfaces to connect Home Automation Networks to the IoT) FT (Some evolutions of standards are required especially to integrate low-power constraints into 4G releases. This should be evaluated based on ETSI M2M implementation)

Embedded web services for IoT devices

10 has been agreed inside FI-Ware as the high-level interface towards applications especially to collect all events and context elements issued from connected things and that could be stored in a generic way and for huge amount of data.) FT (RESTful binding specification)

NSN (RESTful binding specification)

10 has been agreed inside FI-Ware as the high-level interface towards applications and between WP5/WP6 (Data and Context Management) )

nition of the framework for brokerage of the Social Networks and for enabling

TI (Support for interoperable Social Networks)

tion of description of Points of Interests (POI) on the Web)


Work

Package

Task(s) Partner for

this Task


6 6 All Thales Localisation server 6 6.1 France

Telecom – Orange


Binding of Publish/Subscribe GE to a technology within NGSI




6 6.1 Siemens Query Formats (mainly MPQF and JPSearch) 6 6.2 Telecom

Italia Definition of an efficient content meta-data tagging for a content delivery

6 6.2 IBM-IL Complex event processing 6 6.3 Siemens Query Formats (mainly MPQF and JPSearch) 6 6.3 France

Telecom – Orange

6 6.3 Siemens 6 6.3 France

Telecom – Orange



Binding of Publish/Subscribe GE to a technology within NGSI


Definition of an efficient content meta-data tagging for a content delivery





Specification and implementation of interfaces to device functionality for Connected devices



Specification, implementation and testing of a software execution environment in the cloud proxy/home gateway



7 7.3 NSN Virtual network control 7 7.3 NSN

7 7.3 NSN 7 7.3 ALU-D Mechanisms for discovery and abstraction of network information

GEs and potentially also fi-ware and other UCP applications.8 8.1 Thales Visualisation and remediation for Security;

Risk analysis: collection and exploitation of new vuln(IOT, Services..); Risk analysis: The vulnerability scoring is used prioritizing these vulnerabilities and remediate those that pose the greatest risk.; Risk analysis: A topological network information capture allows building a model of the network, in terms of relevant security attributes.;


group or specific



ISO/IEC MPEG FT( Storage formats (i.e., file formats), query formats)

GE to a technology within NGSI OMA NGSI

OMA NGSI TI (Binding of the NGSI to a specific technology)

W3C Device API WG TI (Standard APIs definition to let Web applications to access in device functionalities like file system, camera, accelerometer etc.)


ISO/IEC MPEG S (Storage formats (i.e., fidata tagging for a content delivery

ISO/IEC MPEG S (Storage formats (i.e., file formats), query formats)ISO/IEC MPEG FT (Storage formats (i.e., file formats), query formats)

ISO/IEC JPEG S (JPSearch) ISO/IEC MPEG FT (Improvement of query formats)

W3C Device API WG TI (Standard APIs definition to let Web applications to access in a standard and seamless way device functionalities like file system, camera, accelerometer etc.)

ublish/Subscribe GE to a technology within NGSI

data tagging for a content delivery


W3C Device API WG TI (Standard APIs definition to let Web applications to access in a standard and seamless way device functionalities like file system, camera, accelerometer etc.)

3GPP M2M FT (Some evolutions of sinto 4G relesases. This should be evaluated based on ETSI M2M implementation)

Specification and implementation of interfaces to device functionality for Connected

OMA Device Management (DM)

TI (Specification of Remote Management functionality for Connected Devices)

Specification, implementation and testing of a software execution environment in the cloud

HGI TWG, Energy TF TI (HGI defined and is going to revise requirements for the execution environment and periodically organises test

BBF BBHome TI (BBHome defined mechanisms for the remote management of software modules)

Open Networking Foundation

OpenFlow NSN (Standard interface for separated control plane and forwarding plane, used in virtual (software defined) networks) NSN (Extension of OpenFlow to support any transport networks)

IETF GMPLS NSN (Plan to reuse GMPLS UNI in NetIC interface as much as possible)Mechanisms for discovery and abstraction of network information to be provided for other

ware and other UCP applications. IETF SDNP Activity deals with new interfaces between applications, data centers and networks

ion and exploitation of new vulnerabilities from various enablers

Risk analysis: The vulnerability scoring is used prioritizing these vulnerabilities and

ork information capture allows building a model of the network, in terms of relevant security attributes.;

Mitre.org; NIST; W3C; JAVA;

OVAL; CVSS; XML; JMS;

Mitre.org ( If specific vulnerabiliaccount for the risk analysis Open Vulnerability and Assessment Language (OVAL™) standardize the transfer of vulnerability information across the security tools (scanners) and the attack path engine. NIST National Vulnerability Database Common Vulnerability Scoring System provides an


FT( Storage formats (i.e., file formats), query formats)

TI (Binding of the NGSI to a specific technology)

TI (Standard APIs definition to let Web applications to access in a standard and seamless way device functionalities like file system, camera, accelerometer etc.) TI (Binding of the NGSI to a specific technology)

S (Storage formats (i.e., file formats), query formats)

formats (i.e., file formats), query formats) FT (Storage formats (i.e., file formats), query formats)

f query formats)

TI (Standard APIs definition to let Web applications to access in a standard and seamless way device functionalities like file system, camera, accelerometer etc.)

TI (Binding of the NGSI to a specific technology)

TI (Standard APIs definition to let Web applications to access in a standard and seamless way device functionalities like file system, camera, accelerometer etc.) FT (Some evolutions of standards are required especially to integrate low-power constraints into 4G relesases. This should be evaluated based on ETSI M2M implementation)

TI (Specification of Remote Management functionality for Connected Devices)

TI (HGI defined and is going to revise requirements for the execution environment and test events to test new functionalities)

ome defined mechanisms for the remote management of software modules)

NSN (Standard interface for separated control plane and forwarding plane, used in virtual are defined) networks);

NSN (Extension of OpenFlow to support any transport networks) NSN (Plan to reuse GMPLS UNI in NetIC interface as much as possible) Activity deals with new interfaces between applications, data centers and networks

Mitre.org ( If specific vulnerabilities are authenticated from other enablers and can be taken in analysis, a contribution of WP may be considered.)

y and Assessment Language (OVAL™) standardize the transfer of vulnerability information across the security tools (scanners) and the attack path engine.

NIST National Vulnerability Database Common Vulnerability Scoring System provides an


Work

Package

Task(s) Partner for

this Task


Security Monitoring Enabler: Exchange formats must be used to capture and exchange security information with other FI-WARE enablers.

8 8.2 Thales Access Control & AAA 8 8.2 NSN Identity and Privacy Management

8 8.2 Thales Possible extension for Access Control work 8 8.2 NSN Identity and Privacy Management

8 8.2 IBM Design and implementation of privacy enhancing cryptographic protocol stacks to add privacy to the Identity management and Data Control IDEMIX - Privacy Enhancing Cryptography. IBM work has included developing a new profile for attribute predicates – a way of minimising data that needs to be exchanged

8 8.4 Thales Content-based Security 11 11.4 Telecom

Italia


group or specific



Security Monitoring Enabler: Exchange formats must be used to capture and exchange WARE enablers.

IETF; NIST;

IDMEF; RTL;

open framework for communicating the characteristics and impacts of IT vulnerabilities. The standardized vulnerability scormanagement policy and prioritize their remediation. NIST RTL (Identification of existing snetworking. Analysis of their applicability in the scope of Remediation Tasking Language.) XML syntax offers a stable format. It is used by a SIEM (Security Information and Event Management) to write directiva correlation computation. XML is also used for easy parsing of the information by attack path engines. The XML output references an XSL stylebe used to format the results as HTML. JMS is the standard messaging API for passing data between components and allowing exchanges in heterogeneous environments. IDMEF Security Exchange Formats are relevant to monitoring and visualisation of security incidents

OASIS SAML NSN (Standard interface for secure Authentication and Authorization

monitor) OASIS XACML IETF OAuth NSN (Standard interface for secure Authentication and Authorization

monitor) Design and implementation of privacy enhancing cryptographic protocol stacks to add

acy to the Identity management and Data Control – Security Generic Enablers. = Privacy Enhancing Cryptography. IBM work has included developing a new

a way of minimising data that needs to be exchanged

OASIS SAML SAML is a principle method for transferring attributes about people for identification. SAML v2 - Attribute Predicates for privacy IBM is editor of the attribute predicate profileattribute exchange. Framework for Security Information Exchange

ETSI M2M TI (Work Item 14: Interworking between the M2M Architecture and M2M Area Network

technologies) TI (Work Item 10: mIa, dIa and mId interfacTI (Work Item 2: Functional architecture , stage 2)


r communicating the characteristics and impacts of IT vulnerabilities. The standardized vulnerability scoring (emerging standard) allows leveraging on vulnerability management policy and prioritize their remediation.

NIST RTL (Identification of existing standards in the scope of autonomic / resilient networking. Analysis of their applicability in the scope of Remediation Tasking Language.)

XML syntax offers a stable format. It is used by a SIEM (Security Information and Event Management) to write directives, defining conditions that will meet by the incoming events, in a correlation computation. XML is also used for easy parsing of the topological network

by attack path engines. The XML output references an XSL style sheet which can format the results as HTML.

JMS is the standard messaging API for passing data between components and allowing exchanges in heterogeneous environments.

IDMEF Security Exchange Formats are relevant to monitoring and visualisation of security

NSN (Standard interface for secure Authentication and Authorization. Stds complete, only

NSN (Standard interface for secure Authentication and Authorization. Stds complete, only

SAML is a principle method for transferring attributes about people for identification. SAML Attribute Predicates for privacy

attribute predicate profile which increases privacy compared to standard

ork for Security Information Exchange

TI (Work Item 14: Interworking between the M2M Architecture and M2M Area Network

TI (Work Item 10: mIa, dIa and mId interfaces) TI (Work Item 2: Functional architecture , stage 2)


5 Annex: Relevant Standardization BodiesFI-WARE requires monitoring of standards deployed in the PPP deviates from standards or makes extare involved, they should be introduced intorequires long-term planning and then requirements, then architecture documentation, then protocols and data

5.1 3GPP

5.1.1 Introduction http://www.3gpp.org

Goal. 3GPP prepares, approves and maintains the necessary set of TechnicaReports for an evolved 3rd Generation and beyond Mobile System. 3GPP focus on the access network and core network layers of a telecommunication system. 3GPP is constantly looking at service to network interfaces, as well as modern network features including security, network features, and application level signalling. After TS22.868, 3GPP is now discussing special considerations facilitate M2M traffic from a business and connectivity perspective.

• 3rd Generation Partnership Pr

• 3GPP TS22868: http://www.3gpp.org/ftp/Specs/2007

In Telco-originated identity management solutions, the c(i.e. the original scope is much narrower than in the case of InternetIMS distinguishes between the private IMPI (IP Multimedia Private Identity) that is typically onlby the user’s home operator and the public IMPU (IP Multimedia Public Identity) that is given to services (i.e. Application Servers), potentially different IMPUs to different services. Authentication is typically performed by means of a tamperIdentification Module; SIM, USIM, ISIM). Convergence of Telcooriginated solutions started with the introduction of the GAA (Generic Authentication Architect3GPP, of which the core element is GBA (Generic Bootstrapping Architecture). GBA is used for establishing a shared secret (based upon the long(User Equipment) and any service provider (called theshared secret is then used for different purposes such as end user authentication (HTTP Digest, PSKor provisioning PKI certificates (SSC i.e. Support for Subscriber Certificates).

FI-WARE relevance. As FI-WAREis limited to networking and maybe IoT issues.

Relevant Standardization Bodiesmonitoring of standards as well as providing of contributions

deployed in the PPP deviates from standards or makes extensions or profiling necessary. are involved, they should be introduced into SDOs at an early stage. Successful contributing to SDOs

term planning and adaptation to the specific SDO cycle (for example, first feasibility studiethen requirements, then architecture documentation, then protocols and data-models, and finally testing).

. 3GPP prepares, approves and maintains the necessary set of Technical Specifications and Technical Reports for an evolved 3rd Generation and beyond Mobile System. 3GPP focus on the access network and core network layers of a telecommunication system. 3GPP is constantly looking at service to network

odern network features including security, network features, and application level signalling. After TS22.868, 3GPP is now discussing special considerations facilitate M2M traffic from a business and connectivity perspective.

3rd Generation Partnership Project (3GPP): http://www.3gpp.org/

http://www.3gpp.org/ftp/Specs/2007-03/Rel-8/22_series/22868

originated identity management solutions, the central notions are: identifiers and authentication (i.e. the original scope is much narrower than in the case of Internet-originated solutions). For instance, IMS distinguishes between the private IMPI (IP Multimedia Private Identity) that is typically onlby the user’s home operator and the public IMPU (IP Multimedia Public Identity) that is given to services (i.e. Application Servers), potentially different IMPUs to different services. Authentication is typically performed by means of a tamper-resistant smartcard and the SIM application running on it (Subscriber Identification Module; SIM, USIM, ISIM). Convergence of Telco-originated solutions to Internetoriginated solutions started with the introduction of the GAA (Generic Authentication Architect3GPP, of which the core element is GBA (Generic Bootstrapping Architecture). GBA is used for establishing a shared secret (based upon the long-term master secret in the xSIM card) between the UE (User Equipment) and any service provider (called the NAF i.e. Network Application Function). This shared secret is then used for different purposes such as end user authentication (HTTP Digest, PSKor provisioning PKI certificates (SSC i.e. Support for Subscriber Certificates).

WARE is focusing on the higher level protocol stack, the relevance of 3GPP is limited to networking and maybe IoT issues.

Relevant Standardization Bodies contributions whenever the technology

ensions or profiling necessary. If new concepts Successful contributing to SDOs

to the specific SDO cycle (for example, first feasibility studies, models, and finally testing).

l Specifications and Technical Reports for an evolved 3rd Generation and beyond Mobile System. 3GPP focus on the access network and core network layers of a telecommunication system. 3GPP is constantly looking at service to network

odern network features including security, network features, and application level signalling. After TS22.868, 3GPP is now discussing special considerations facilitate M2M traffic from a

8/22_series/22868-800.zip

entral notions are: identifiers and authentication originated solutions). For instance,

IMS distinguishes between the private IMPI (IP Multimedia Private Identity) that is typically only known by the user’s home operator and the public IMPU (IP Multimedia Public Identity) that is given to services (i.e. Application Servers), potentially different IMPUs to different services. Authentication is typically

stant smartcard and the SIM application running on it (Subscriber originated solutions to Internet-

originated solutions started with the introduction of the GAA (Generic Authentication Architecture) by 3GPP, of which the core element is GBA (Generic Bootstrapping Architecture). GBA is used for

term master secret in the xSIM card) between the UE NAF i.e. Network Application Function). This

shared secret is then used for different purposes such as end user authentication (HTTP Digest, PSK-TLS)

is focusing on the higher level protocol stack, the relevance of 3GPP


5.2 DMTF

5.2.1 Cloud Incubatorhttp://www.dmtf.org/about/cloud

Goal. DMTF’s Open Cloud Standards Incubator focuses on standardizing interactions between cloud environments by developing cloud resource management protocols, packaging formats and security mechanisms to facilitate interoperability. CIMI is the emerging standard for pcloud resources.

FI-WARE relevance. These standards are highly relevant for the “Cloud Hosting” area of FI

5.3 ETSI

5.3.1 Re-organisation of ETSI in progresshttp://www.etsi.org/

ETSI is a key body for both architecture and protocols in telecommunications and will be a reference in particular with respect to convergence and new directions towards Cloud. As the only European Standards Organisation which covers Future Internet topics, bringing FIwould assure wide accessibility and continuity. The ETSI structure also allows an "early adoption" mechanism, through the creation of an Industry Standardization Group, and it is intended to explore this possibility.

However, a number of ETSI technical committees such as MCD, TISPAN, GRID, ATTM, DECT and others began discussions in mid-to contribute are currently uncertain. The topics of contributiorelevant technical body may well change in the near to mid

5.3.2 ETSI TC GRID (TC CLOUD)ETSI TC GRID changed its name to TC CLOUD, however it has markedly reduced its activities since the conception of the FI-WARE project and is no longer considered as a suitable source of material or place for FI-WARE to contribute.

1 INTEL has a chair position in the DMTF’s Open Cloud Standards Incubator

Cloud Incubator 1 http://www.dmtf.org/about/cloud-incubator

Open Cloud Standards Incubator focuses on standardizing interactions between cloud environments by developing cloud resource management protocols, packaging formats and security mechanisms to facilitate interoperability. CIMI is the emerging standard for provisioning and life cycle of

These standards are highly relevant for the “Cloud Hosting” area of FI

organisation of ETSI in progress

dy for both architecture and protocols in telecommunications and will be a reference in particular with respect to convergence and new directions towards Cloud. As the only European Standards Organisation which covers Future Internet topics, bringing FI-WARE successes into ETSI specifications would assure wide accessibility and continuity. The ETSI structure also allows an "early adoption" mechanism, through the creation of an Industry Standardization Group, and it is intended to explore this

owever, a number of ETSI technical committees such as MCD, TISPAN, GRID, ATTM, DECT and -2011 to re-organize and re-focus. Therefore the best places for FI

to contribute are currently uncertain. The topics of contribution in this sub-section will remain, but the relevant technical body may well change in the near to mid-term.

ETSI TC GRID (TC CLOUD) ETSI TC GRID changed its name to TC CLOUD, however it has markedly reduced its activities since the

E project and is no longer considered as a suitable source of material or place for

DMTF’s Open Cloud Standards Incubator

Open Cloud Standards Incubator focuses on standardizing interactions between cloud environments by developing cloud resource management protocols, packaging formats and security

rovisioning and life cycle of

These standards are highly relevant for the “Cloud Hosting” area of FI-WARE.

dy for both architecture and protocols in telecommunications and will be a reference in particular with respect to convergence and new directions towards Cloud. As the only European Standards

RE successes into ETSI specifications would assure wide accessibility and continuity. The ETSI structure also allows an "early adoption" mechanism, through the creation of an Industry Standardization Group, and it is intended to explore this

owever, a number of ETSI technical committees such as MCD, TISPAN, GRID, ATTM, DECT and focus. Therefore the best places for FI-WARE

section will remain, but the

ETSI TC GRID changed its name to TC CLOUD, however it has markedly reduced its activities since the E project and is no longer considered as a suitable source of material or place for


5.3.3 ETSI TC M2M Goal. ETSI TC M2M is devoted to machine1 was completed at the end of 2011will contain necessary details and will likely be completed in late 2012 or midlarger organisation for M2M which includes many other global SDOs.

FI-WARE relevance. Part of the additional functionality is closely related to FIextensions for annotated/meaningful/semantic data, enhanced discoverability of resources and thinginteraction.

5.3.4 ETSI TC TISPANTISPAN is currently (1st quarter of 201(provisionally) E2NA, however the work continues. Architectural contributions from FImost important aspect. In addition, ETSI PLUGTESTS may provide an opportunity to test pagainst standards and specifications, also with the goal of enhancing the quality of specifications.

NEC raised in October 2011 at TISPAN Plenary the issue of coand there was a warm reception of the idea,

5.3.5 ETSI TC SCP Goal. The group discusses protocols for mobile terminals and to M2M based on use of embedded UICCs (SIMs).

FI-WARE relevance. Many existing M2M and IoT solutions rely on the security, authorization addressing functionality provided by SIMpoint. Development of SIM-cards with RFC capability may even extend the usefulness of this technology for IoT. FI-WARE needs to monitor trends here.

5.4 HGI (Home Gateway Initiative) http://www.homegatewayinitiative.org

Goal: The HGI publishes requirements for digital home building blocks, i.e. hardware and software in the digital home that connect consumernetwork devices. HGI projects are triggered by the services vision of the group members, and build on the technical collaboration of all the HGI participants. The members represent the entthe broadband home area. Currently there is an emphasis on Energy and Cloud projects.

FI-WARE relevance: Highly relevant for the “Cloud Proxies” and connected devices area.

5.5 IEEE

5.5.1 Introduction http://standards.ieee.org

Goal. The IEEE Standards Association (IEEEdeveloping, integrating, sharing, and applying knowledge about electrosciences. In particular, IEEE 802 refers to a family of IEEE standards dealing with local area networks and metropolitan area networks.

ETSI TC M2M is devoted to machine-to-machine infrastructure architecture and protocols. Release

1 was completed at the end of 2011 but it was not comprehensive enough to allow deployments. Release 2 will contain necessary details and will likely be completed in late 2012 or midlarger organisation for M2M which includes many other global SDOs.

Part of the additional functionality is closely related to FIextensions for annotated/meaningful/semantic data, enhanced discoverability of resources and thing

ETSI TC TISPAN quarter of 2012) being subsumed into a different ETSI technical committee named

(provisionally) E2NA, however the work continues. Architectural contributions from FImost important aspect. In addition, ETSI PLUGTESTS may provide an opportunity to test pagainst standards and specifications, also with the goal of enhancing the quality of specifications.

NEC raised in October 2011 at TISPAN Plenary the issue of co-operation in PLUGTESTS with FP projects and there was a warm reception of the idea, especially in relation to Internet of Things.

. The group discusses protocols for mobile terminals and to M2M based on use of embedded UICCs

Many existing M2M and IoT solutions rely on the security, authorization addressing functionality provided by SIM-cards. SIM-cards are also currently the most ubiquitous end

cards with RFC capability may even extend the usefulness of this technology WARE needs to monitor trends here.

I (Home Gateway Initiative) http://www.homegatewayinitiative.org

: The HGI publishes requirements for digital home building blocks, i.e. hardware and software in the digital home that connect consumers and services. They include home gateways, home networks, and home network devices. HGI projects are triggered by the services vision of the group members, and build on the technical collaboration of all the HGI participants. The members represent the entthe broadband home area. Currently there is an emphasis on Energy and Cloud projects.

: Highly relevant for the “Cloud Proxies” and connected devices area.

. The IEEE Standards Association (IEEE-SA) promotes the engineering process by creating, developing, integrating, sharing, and applying knowledge about electro- and information technologies and

802 refers to a family of IEEE standards dealing with local area networks and

machine infrastructure architecture and protocols. Release but it was not comprehensive enough to allow deployments. Release 2

will contain necessary details and will likely be completed in late 2012 or mid-2013 within a new and

Part of the additional functionality is closely related to FI-WARE, namely adding extensions for annotated/meaningful/semantic data, enhanced discoverability of resources and thing-level

2) being subsumed into a different ETSI technical committee named (provisionally) E2NA, however the work continues. Architectural contributions from FI-WARE will be the most important aspect. In addition, ETSI PLUGTESTS may provide an opportunity to test prototypes against standards and specifications, also with the goal of enhancing the quality of specifications.

operation in PLUGTESTS with FP projects especially in relation to Internet of Things.

. The group discusses protocols for mobile terminals and to M2M based on use of embedded UICCs

Many existing M2M and IoT solutions rely on the security, authorization and cards are also currently the most ubiquitous end-

cards with RFC capability may even extend the usefulness of this technology

: The HGI publishes requirements for digital home building blocks, i.e. hardware and software in the s and services. They include home gateways, home networks, and home

network devices. HGI projects are triggered by the services vision of the group members, and build on the technical collaboration of all the HGI participants. The members represent the entire spectrum of players in the broadband home area. Currently there is an emphasis on Energy and Cloud projects.


SA) promotes the engineering process by creating, and information technologies and

802 refers to a family of IEEE standards dealing with local area networks and


FI-WARE relevance. IEEE is strongly focusing on networking standards, mainly in the physical and link layer. As such, it is highly relevant for new nimpact on the higher layers, e.g. Wi

5.6 IETF (Internet Engineering Task Force)

5.6.1 Introduction http://www.ietf.org

The mission of the IETF is make the Interndocuments that influence the way people design, use, and manage the Internet. Many working groups in IETF are of relevance to the FI-WARE project. IETF is discussing context services, mainly in tand GEOPRIV working groups. For IoT, the IETF 6lowpan and CoRE working group focuses on including sensor nodes on transport and service level.

5.6.2 IETF 6lowpan Working Grouphttp://www.ietf.org/html.charters/6lowpan

Several protocol standards will be needed as reference, and IETF drafts may be initiated in case of extensions. Completely new protocols will be unlikely as output of FI

5.6.3 IETF Core Working Grouphttps://datatracker.ietf.org/wg/core/charter/

Goal. Constrained RESTful Environments (CoRE) is providing a framework for resourceapplications intended to run on constrained IP networks. A consmay exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time.

FI-WARE relevance. The charter of CoRE overlaps the use cases and endWARE so the monitoring of trends in this group is advisable. The following drafts are relevant: Constrained Application Protocol (CoAP) (draftlink-format-10), Group Communication for CoAP (draftCoAP (draft-ietf-core-observe-03), Blockwise transfers in CoAP (draftConfiguration of Constrained Devices

5.6.4 IETF GEOPRIV Working Grouphttp://www.ietf.org/html.charters/geopriv

5.6.5 IETF Light Weight Implementation Guidancehttp://datatracker.ietf.org/wg/lwig/charter/

Goal. Guidance for Light-Weight Implementations of the Internet Protocol Suite focuses on helping the implementers of the smallest devices. The goal is to be able to build minimal yetdevices for the most constrained environments (embedded in buildings, bridges, mobile platforms, etc). Some implementations can exist in as few as a couple of kilobytes. The output of this work is a document that describes implementation techniques for reducing complexity, memory footprint, or power usage. The

. IEEE is strongly focusing on networking standards, mainly in the physical and link layer. As such, it is highly relevant for new network technologies. Some of these will have in the future impact on the higher layers, e.g. Wi-Fi Direct.

IETF (Internet Engineering Task Force)

The mission of the IETF is make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Many working groups in

WARE project. IETF is discussing context services, mainly in tand GEOPRIV working groups. For IoT, the IETF 6lowpan and CoRE working group focuses on including sensor nodes on transport and service level.

IETF 6lowpan Working Group ww.ietf.org/html.charters/6lowpan-charter.html

Several protocol standards will be needed as reference, and IETF drafts may be initiated in case of extensions. Completely new protocols will be unlikely as output of FI-WARE.

Working Group https://datatracker.ietf.org/wg/core/charter/

. Constrained RESTful Environments (CoRE) is providing a framework for resourceapplications intended to run on constrained IP networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time.

harter of CoRE overlaps the use cases and end-devices considered in FIWARE so the monitoring of trends in this group is advisable. The following drafts are relevant: Constrained Application Protocol (CoAP) (draft-ietf-core-coap-08), CoRE Link Format (draf

10), Group Communication for CoAP (draft-ietf-core-groupcomm-00), Observing Resources in 03), Blockwise transfers in CoAP (draft-ietf

Configuration of Constrained Devices - (New work proposal by FI-WARE member)

IETF GEOPRIV Working Group http://www.ietf.org/html.charters/geopriv-charter.html

IETF Light Weight Implementation Guidance http://datatracker.ietf.org/wg/lwig/charter/

Weight Implementations of the Internet Protocol Suite focuses on helping the implementers of the smallest devices. The goal is to be able to build minimal yet interoperable IPdevices for the most constrained environments (embedded in buildings, bridges, mobile platforms, etc). Some implementations can exist in as few as a couple of kilobytes. The output of this work is a document

ntation techniques for reducing complexity, memory footprint, or power usage. The

. IEEE is strongly focusing on networking standards, mainly in the physical and link etwork technologies. Some of these will have in the future

et work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Many working groups in

WARE project. IETF is discussing context services, mainly in the SIMPLE and GEOPRIV working groups. For IoT, the IETF 6lowpan and CoRE working group focuses on including

Several protocol standards will be needed as reference, and IETF drafts may be initiated in case of

. Constrained RESTful Environments (CoRE) is providing a framework for resource-oriented trained IP network has limited packet sizes,

may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered off at any point in time but periodically "wake up" for brief periods of time.

devices considered in FI-WARE so the monitoring of trends in this group is advisable. The following drafts are relevant:

08), CoRE Link Format (draft-ietf-core-00), Observing Resources in ietf-core-block-07), Basic

member)

Weight Implementations of the Internet Protocol Suite focuses on helping the interoperable IP-capable

devices for the most constrained environments (embedded in buildings, bridges, mobile platforms, etc). Some implementations can exist in as few as a couple of kilobytes. The output of this work is a document

ntation techniques for reducing complexity, memory footprint, or power usage. The


topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF

FI-WARE relevance. The charter of LWIG WARE so the monitoring of trends in this group is advisable. The output document may contain many examples of devices relevant to FI

5.6.6 IETF ROLL http://datatracker.ietf.org/wg/roll/charter/

Goal. Routing Over Low power and Lossy networks Group

FI-WARE relevance. The following drafts are relevant: RFC 5548 (draftRouting Requirements for Urban LowRouting Protocol for Low power and Lossy Networks, RFC 5826 (draftAutomation Routing Requirements in Low

5.6.7 IETF SIMPLE Working Grouphttp://www.ietf.org/html.charters/simple

5.6.8 IETF IDMEF http://www.ietf.org/rfc/rfc4765.txt

Goal. IDMEF (Intrusion Detection Message Exchan RFC to share information of interest for intrusion detection & protection systems.

FI-WARE relevance. Although this WG is completed, Security Exchange Formats are relevant to monitoring and visualisation of security incidents.

5.7 ISO/IEC JTC1

5.7.1 WG7 (Working Group on Sensor Networks)Goal: Standardization in the area of generic solutions for sensor networks and applicationnetworks including (a) standardization of terminology. (b) developof reference architectures, (d) development of guidelines for interoperability.

FI-WARE relevance: Especially for the IoT area as well as for the context part.

5.8 ITU-T

5.8.1 Introduction http://www.itu.int/itu-t

topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF

The charter of LWIG overlaps the use cases and end-devices considered in FIWARE so the monitoring of trends in this group is advisable. The output document may contain many examples of devices relevant to FI-WARE platforms.

http://datatracker.ietf.org/wg/roll/charter/

. Routing Over Low power and Lossy networks Group

. The following drafts are relevant: RFC 5548 (draft-ietfRouting Requirements for Urban Low-Power and Lossy Networks, draft-ietfRouting Protocol for Low power and Lossy Networks, RFC 5826 (draft-ietf-roll-homeAutomation Routing Requirements in Low-Power and Lossy Networks.

IETF SIMPLE Working Group http://www.ietf.org/html.charters/simple-charter.html

http://www.ietf.org/rfc/rfc4765.txt

. IDMEF (Intrusion Detection Message Exchange Format) was designed and validated by IETF under an RFC to share information of interest for intrusion detection & protection systems.

Although this WG is completed, Security Exchange Formats are relevant to ation of security incidents.

ISO/IEC JTC1

WG7 (Working Group on Sensor Networks) : Standardization in the area of generic solutions for sensor networks and application

networks including (a) standardization of terminology. (b) development of a taxonomy. (c) Standardization of reference architectures, (d) development of guidelines for interoperability.

e: Especially for the IoT area as well as for the context part.

topics for this working group will be chosen from these protocols: IPv4, IPv6, UDP, TCP, ICMPv4/v6, MLD/IGMP, ND, DNS, DHCPv4/v6, IPsec, 6LOWPAN, COAP, RPL, SNMP and NETCONF protocols.

devices considered in FI-WARE so the monitoring of trends in this group is advisable. The output document may contain many

ietf-roll-urban-routing-reqs) ietf-roll-rpl-19 RPL: IPv6 home-routing-reqs) Home

ange Format) was designed and validated by IETF under an RFC to share information of interest for intrusion detection & protection systems.

Although this WG is completed, Security Exchange Formats are relevant to

: Standardization in the area of generic solutions for sensor networks and application‐oriented sensor ment of a taxonomy. (c) Standardization


The ITU is a UN based organization founded 1865 to achieve consensus on technologies and services, with a sub-body ITU-T for telecommunications and recently services and internetRecommendations are created on topics ranging from core network functionality and broadband to services. The most relevant group is Study Group 13 on future networks.

5.8.2 ITU-T Ubiquitous Sensor NetworksITU-T Ubiquitous Sensor Networks is a group working on defining a standard for s

FI-WARE relevance. ITU-T is highly relevant for worldworking groups are related to the Fioften political and when relevant often limited. Nevertheless, work here should be monitored to check if some areas maz turn out to be relevant after all.

5.9 Kantara InitiativeGoal. Kantara is a body with the goal of harmonization and intopen identity specifications. It is not a standards organisation and technical specifications developed must be submitted elsewhere. Kantara output is called a recommendation. Frameworks, guidelines and interoperability testing procedures are the main Kantara focus and maintained by it alone.

FI-WARE relevance. This body can be of importance in the area of identity management because of its coordinating role and because it could become the place for working on frameWARE.

5.10 OASIS www.oasis-open.org

Goal. OASIS is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society, producing WS

OASIS has a “Identity in the Cloud TC”.

For identity management, the most relevant standardization activities take place in OASIS and Kantara. OASIS develops among others SAML (Security Assertion Markup Language), which allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. Kantara develops among others the ID-WSFwhich standardize common functionality that developers can use in incorporating identityapplication features, including: authentication, message protection, privacy protection, service discovand addressing, policy, data access and management, social identity, and transport protocols. Loosely linked to these specifications are the soMicrosoft: WS-Trust defines extensions to WSand issue security tokens and to manage trust relationships. This one is particularly the main basis for the new Infocard paradigm, demonstrated both by Microsoft CardSpace and Higgins Open Source IdFramework. A relevant and recently formed technical committee has been formed inside OASIS: the Identity Metasystem Interoperability (IMI) TC. The Web2.0 open ecosystem has also developed a couple of lightweight identity-related specifications: Openmanagement, and OAuth, an open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications.

FI-WARE relevance. OASIS drives standards in the Web and XMSecurity (e.g. SAML2.0), workflows, as well as specific information models. The Identity subbe interesting for the Cloud and Security

The ITU is a UN based organization founded 1865 to achieve consensus on technologies and services, with T for telecommunications and recently services and internet-

ted on topics ranging from core network functionality and broadband to services. The most relevant group is Study Group 13 on future networks.

T Ubiquitous Sensor Networks T Ubiquitous Sensor Networks is a group working on defining a standard for s

T is highly relevant for world-wide international standards. As such, many working groups are related to the Fi-Ware project. Compared to other SDO’s , ITUoften political and when relevant often follows other bodies, so the relevance for FIlimited. Nevertheless, work here should be monitored to check if some areas maz turn out to be relevant

Kantara Initiative Goal. Kantara is a body with the goal of harmonization and interoperability through the development of open identity specifications. It is not a standards organisation and technical specifications developed must

Kantara output is called a recommendation. Frameworks, guidelines and ility testing procedures are the main Kantara focus and maintained by it alone.

WARE relevance. This body can be of importance in the area of identity management because of its coordinating role and because it could become the place for working on frame

profit consortium that drives the development, convergence and adoption of open standards for the global information society, producing WSs standards.

OASIS has a “Identity in the Cloud TC”.

For identity management, the most relevant standardization activities take place in OASIS and Kantara. OASIS develops among others SAML (Security Assertion Markup Language), which allows business

s to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. Kantara

WSF (Identity Web Services Framework, started in the Liberty Alliance) functionality that developers can use in incorporating identity

application features, including: authentication, message protection, privacy protection, service discovand addressing, policy, data access and management, social identity, and transport protocols. Loosely

specifications are the so-called WS-* specifications stack originally driven by IBM and Trust defines extensions to WS-Security (now part of OASIS security services) to request

and issue security tokens and to manage trust relationships. This one is particularly the main basis for the new Infocard paradigm, demonstrated both by Microsoft CardSpace and Higgins Open Source IdFramework. A relevant and recently formed technical committee has been formed inside OASIS: the Identity Metasystem Interoperability (IMI) TC. The Web2.0 open ecosystem has also developed a couple

related specifications: OpenID, an open, decentralised, free framework for identity management, and OAuth, an open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications.

. OASIS drives standards in the Web and XML area. Among them are protocols for Security (e.g. SAML2.0), workflows, as well as specific information models. The Identity subbe interesting for the Cloud and Security-related work in FI-WARE.

The ITU is a UN based organization founded 1865 to achieve consensus on technologies and services, with -related standards. ITU-T

ted on topics ranging from core network functionality and broadband to

T Ubiquitous Sensor Networks is a group working on defining a standard for sensor networks.

wide international standards. As such, many Ware project. Compared to other SDO’s , ITU-T standardization is

follows other bodies, so the relevance for FI-WARE might be limited. Nevertheless, work here should be monitored to check if some areas maz turn out to be relevant

eroperability through the development of open identity specifications. It is not a standards organisation and technical specifications developed must

Kantara output is called a recommendation. Frameworks, guidelines and ility testing procedures are the main Kantara focus and maintained by it alone.

WARE relevance. This body can be of importance in the area of identity management because of its coordinating role and because it could become the place for working on frameworks developed in FI-

profit consortium that drives the development, convergence and adoption of open

For identity management, the most relevant standardization activities take place in OASIS and Kantara. OASIS develops among others SAML (Security Assertion Markup Language), which allows business

s to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application. Kantara

Web Services Framework, started in the Liberty Alliance) functionality that developers can use in incorporating identity-based

application features, including: authentication, message protection, privacy protection, service discovery and addressing, policy, data access and management, social identity, and transport protocols. Loosely

* specifications stack originally driven by IBM and ecurity (now part of OASIS security services) to request

and issue security tokens and to manage trust relationships. This one is particularly the main basis for the new Infocard paradigm, demonstrated both by Microsoft CardSpace and Higgins Open Source Identity Framework. A relevant and recently formed technical committee has been formed inside OASIS: the Identity Metasystem Interoperability (IMI) TC. The Web2.0 open ecosystem has also developed a couple

ID, an open, decentralised, free framework for identity management, and OAuth, an open protocol to allow secure API authorisation in a simple and standard

L area. Among them are protocols for Security (e.g. SAML2.0), workflows, as well as specific information models. The Identity sub-group might


5.11 OGC (Open Geospatial Consortium)Goal: The Open Geospatial Consortium, Inc (OGC) is an international industry consortium of companies, government agencies and universities participating in a consensus process to develop publicly available interface standards. OpenGIS® StandardsWeb, wireless and location-based services, and mainstream IT. The standards empower technolodevelopers to make complex spatial information and services accessible and useful with all kinds of applications.

FI-WARE relevance: GeolocationInternet-of-Things enablement.

5.12 OGF (Open Grid Forum)

5.12.1 Introduction Goal: OGF is an open community committed to driving the rapid evolution and adoption of applied distributed computing. Applied Distributed Computing is critical to developing new, innovative and scalable applications and infrastructures that are essential to productivity in the enterprise and within the science community. OGF accomplishes its work through open forums that build the community, explore trends, share best practices and consolidate these best practices into standar

5.12.2 OCCI (Open Cloud Computing Interface)http://occi-wg.org

Goal. The OCCI working Group will deliver an API specification for remote management of cloud computing infrastructure, allowing for the development of interoperadeployment, autonomic scaling and monitoring. It is primarily aimed at the IaaS domain, however the core model is extensible such that extensions can be developed in order to express PaaS and potentially SaaS concepts.

FI-WARE relevance. These standards are highly relevant for the “Cloud Hosting” area of FI

5.12.3 OGF DCI-Fed (Distributed Compute Infrastructures Federated)

Provides for the development and spreadbetween different types of Distributed Computing Infrastructures in a secure, SLAparticular interest to FI-WARE Cloud Hosting GEs is the federation aspect of workloads between domains.

FI-WARE relevance: Highly relevant for the “Clou

5.13 OMA

5.13.1 Introduction http://www.openmobilealliance.org

Goal. "The mission of the Open Mobile Alliance is to facilitate global user adoption of mobile data services by specifying market driven mobdevices, geographies, service providers, operators, and networks while allowing businesses to compete

OGC (Open Geospatial Consortium) Geospatial Consortium, Inc (OGC) is an international industry consortium of

companies, government agencies and universities participating in a consensus process to develop publicly OpenGIS® Standards support interoperable solutions that "geobased services, and mainstream IT. The standards empower technolo

developers to make complex spatial information and services accessible and useful with all kinds of

: Geolocation-related standards are important for the Context enabler as well as for

Open Grid Forum)

Goal: OGF is an open community committed to driving the rapid evolution and adoption of applied distributed computing. Applied Distributed Computing is critical to developing new, innovative and

structures that are essential to productivity in the enterprise and within the science community. OGF accomplishes its work through open forums that build the community, explore trends, share best practices and consolidate these best practices into standards.

OCCI (Open Cloud Computing Interface)

. The OCCI working Group will deliver an API specification for remote management of cloud computing infrastructure, allowing for the development of interoperable tools for common tasks including deployment, autonomic scaling and monitoring. It is primarily aimed at the IaaS domain, however the core model is extensible such that extensions can be developed in order to express PaaS and potentially SaaS

These standards are highly relevant for the “Cloud Hosting” area of FI

Fed (Distributed Compute Infrastructures

Provides for the development and spread-out of a practical set of protocols and formats to interfabetween different types of Distributed Computing Infrastructures in a secure, SLA

WARE Cloud Hosting GEs is the federation aspect of workloads between domains.

WARE relevance: Highly relevant for the “Cloud Hosting” area.

http://www.openmobilealliance.org

. "The mission of the Open Mobile Alliance is to facilitate global user adoption of mobile data services by specifying market driven mobile service enablers that ensure service interoperability across devices, geographies, service providers, operators, and networks while allowing businesses to compete

Geospatial Consortium, Inc (OGC) is an international industry consortium of 404 companies, government agencies and universities participating in a consensus process to develop publicly

solutions that "geo-enable" the based services, and mainstream IT. The standards empower technology

developers to make complex spatial information and services accessible and useful with all kinds of

ed standards are important for the Context enabler as well as for

Goal: OGF is an open community committed to driving the rapid evolution and adoption of applied distributed computing. Applied Distributed Computing is critical to developing new, innovative and

structures that are essential to productivity in the enterprise and within the science community. OGF accomplishes its work through open forums that build the community, explore

. The OCCI working Group will deliver an API specification for remote management of cloud ble tools for common tasks including

deployment, autonomic scaling and monitoring. It is primarily aimed at the IaaS domain, however the core model is extensible such that extensions can be developed in order to express PaaS and potentially SaaS

These standards are highly relevant for the “Cloud Hosting” area of FI-WARE.

Fed (Distributed Compute Infrastructures –

out of a practical set of protocols and formats to interface between different types of Distributed Computing Infrastructures in a secure, SLA-managed manner. Of

WARE Cloud Hosting GEs is the federation aspect of workloads between domains.

. "The mission of the Open Mobile Alliance is to facilitate global user adoption of mobile data ile service enablers that ensure service interoperability across

devices, geographies, service providers, operators, and networks while allowing businesses to compete


through innovation and differentiation." Generally the OMA specifies application interfacside and on the user device end, while recommunication, which should work over all mobile networks or even be network agnostic. Key areas are device management, messaging, personalized

5.13.2 OMA Next Generation Service InterfaceOMA NGSI RD v1.0 is defining REST and SOAPlike advanced multimedia conferences, content sharing and content delivery,management. Further API definitions include federation and management of identities within/across domains, sophisticated media control (e.g. support for media control scripts, providing multimedia guidance). Of high importance multimedia services in particular use of context and preference information to enrich user experience in Communication Services. Partners from FImanagement, and context area. If needed, FINGSI.

FI-WARE relevance. OMA is a standardizing many enablers which are relevant for the FIarchitecture, e.g. IdM, User Profile, Conte

5.14 OSGi (Open Services Gateway Initiative Alliance)http://www.osgi.org/Main/HomePage

Goal: The OSGi Alliance provides specifications and reference implementations that enable the modular assembly of software built with Java technology. OSGi facilitates the componentization of software modules and applications and assures interoperability of applications and services over a variety of networked devices.

FI-WARE relevance: Highly relevant for t

5.15 OpenAjax Alliance (Gadgets Task Force)http://www.openajax.org,

Goal: The OpenAjax Alliance's Gadget TF is working on Metadata standards for mashup technology. The Security TF launched in 2009 a new initiative around mashup authentication an authorization. The Gadget TF has been contacted with a detailed Gadgets TF only schedules meetings when new open is

FI-WARE relevance: Highly relevant for the “

5.16 Open Mashup Alliancehttp://www.openmashup.org

Goal: The Open Mashup Alliance (OMA) is a consortium of individuals and orsuccessful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability. Enterprise Mashups combine and remix data from databases, spreadsheets, websites, Web Services, RSS/Atom feeds, and unstructured sources.

FI-WARE relevance: EMML is an initiative towards the development of a Declarative Domain Specific Language designed specifically for mashups. OMA has been contacted by FIexpression of interest.

through innovation and differentiation." Generally the OMA specifies application interfacside and on the user device end, while re-using as much as possible existing protocols for the communication, which should work over all mobile networks or even be network agnostic. Key areas are

, messaging, personalized services and Web 2.0 application integration.

OMA Next Generation Service Interface OMA NGSI RD v1.0 is defining REST and SOAP-based service interfaces for Rich Multimedia Services like advanced multimedia conferences, content sharing and content delivery, as well as conference member management. Further API definitions include federation and management of identities within/across domains, sophisticated media control (e.g. support for media control scripts, providing multimedia

for FI-WARE is the Context and Personalization APIs with focus on multimedia services in particular use of context and preference information to enrich user experience in Communication Services. Partners from FI-WARE have been active in the conferencing, management, and context area. If needed, FI-WARE will promote its service interfaces towards OMA

. OMA is a standardizing many enablers which are relevant for the FIarchitecture, e.g. IdM, User Profile, Context, Location, etc.

OSGi (Open Services Gateway Initiative Alliance)http://www.osgi.org/Main/HomePage

: The OSGi Alliance provides specifications and reference implementations that enable the modular embly of software built with Java technology. OSGi facilitates the componentization of software

modules and applications and assures interoperability of applications and services over a variety of


OpenAjax Alliance (Gadgets Task Force)

: The OpenAjax Alliance's Gadget TF is working on Metadata standards for mashup technology. The y TF launched in 2009 a new initiative around mashup authentication an authorization. The Gadget

TF has been contacted with a detailed expression of interest and a open issue proposal. At this moment, the Gadgets TF only schedules meetings when new open issues are identified, i.e. on an as

Highly relevant for the “Application and Services Ecosystem

Open Mashup Alliance

: The Open Mashup Alliance (OMA) is a consortium of individuals and organizations dedicated to the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability. Enterprise Mashups combine and remix data from

s, Web Services, RSS/Atom feeds, and unstructured sources.

: EMML is an initiative towards the development of a Declarative Domain Specific Language designed specifically for mashups. OMA has been contacted by FI

through innovation and differentiation." Generally the OMA specifies application interfaces on the server-using as much as possible existing protocols for the

communication, which should work over all mobile networks or even be network agnostic. Key areas are services and Web 2.0 application integration.

based service interfaces for Rich Multimedia Services as well as conference member

management. Further API definitions include federation and management of identities within/across domains, sophisticated media control (e.g. support for media control scripts, providing multimedia

WARE is the Context and Personalization APIs with focus on multimedia services in particular use of context and preference information to enrich user experience in

active in the conferencing, security, service WARE will promote its service interfaces towards OMA

. OMA is a standardizing many enablers which are relevant for the FI-WARE

OSGi (Open Services Gateway Initiative Alliance)

: The OSGi Alliance provides specifications and reference implementations that enable the modular embly of software built with Java technology. OSGi facilitates the componentization of software

modules and applications and assures interoperability of applications and services over a variety of

he “Cloud Proxies” and connected devices area.

OpenAjax Alliance (Gadgets Task Force)

: The OpenAjax Alliance's Gadget TF is working on Metadata standards for mashup technology. The y TF launched in 2009 a new initiative around mashup authentication an authorization. The Gadget

of interest and a open issue proposal. At this moment, the sues are identified, i.e. on an as-needed basis.

Application and Services Ecosystem” area.

ganizations dedicated to the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability. Enterprise Mashups combine and remix data from

s, Web Services, RSS/Atom feeds, and unstructured sources.

: EMML is an initiative towards the development of a Declarative Domain Specific Language designed specifically for mashups. OMA has been contacted by FI-WARE with a detailed


5.17 Telemanagement Forum / IPsphere Frameworkhttp://www.tmforum.org/IPsphere/6214/home.html

Goal: The IPsphere Framework delivers a business layer for rapid service delivery, incsupport for IP services. Using the principles of a serviceFramework defines mechanisms to automate offers, purchase and provision service components among multiple stakeholders, enabling providers

FI-WARE relevance: Highly relevant for the “Interfaces to Networks and Devices” area.

5.18 TNC (Trusted Network Connect)Goal: The TNC is a working group of the Trusted Computing Group, an incorporated industry working group aimed at making computers more secure. It has defined and released an open architecture and a growing set of standards for endpoint integrity. The TNC architecture enables network operators to enforce policies regarding endpoint integrity at or after interoperability across a wide variety of endpoints, network technologies, and policies.

FI-WARE relevance: The standard is highly relevant for networking areas in FI

5.19 W3C

5.19.1 Introduction http://www.w3.org

Goal: W3C defines the standard for an open and interoperable Web. As many areas of FItop of Web technologies, W3C activities are of high relevance. In the following we list important working groups.

Privacy protection cannot be implemented by only relying on technology measures: legislation is an important aspect of the picture, though creative contribution to it is outside the scope of this project. P3P (Platform for Privacy Preferences Project) from in a standard format that can be retrieved automatically and interpreted easily by user agents, which will allow users to be informed of site practices (in both machinedecision-making based on these practices when appropriate, therefore users need not read the privacy policies at every site they visit. P3P work is suspended in W3C since specifications having reached a final state). PLING (Policy Languages requirements and related needs for integrating and computing the results when different policy languages used together, for example, OASIS XACML, IETF Common Policy, and P3P. OASIS (eXtensible Access Control Markup Language) is a comprehensive access control policy language in XML, together with a conceptual framework and a processing model. It is now considered to be a widelyaccepted industry standard. It can also be used forattention in this project. A more sophisticated approach of policyon semantic policy languages such as SWRL (Semantic Web Rule Language). Another approaprotection is to rely on cryptographic solutions that make it practically impossible to leak sensitive information during a transaction. This area of security research is commonly referred to as PETs (Privacy Enhancing Technologies), and one many interesting cryptographic solutions were developed until recently such as zerokinds of privacy-enhancing signature schemes, anonymous browsing, secure multiprivate information retrieval, etc, but these techniques are still not in wide use.

Telemanagement Forum / IPsphere Frameworkhttp://www.tmforum.org/IPsphere/6214/home.html

: The IPsphere Framework delivers a business layer for rapid service delivery, incsupport for IP services. Using the principles of a service-oriented architecture (SOA), the IPsphere Framework defines mechanisms to automate offers, purchase and provision service components among multiple stakeholders, enabling providers to optimize flexibility and efficiency.

: Highly relevant for the “Interfaces to Networks and Devices” area.

TNC (Trusted Network Connect) : The TNC is a working group of the Trusted Computing Group, an incorporated industry working

roup aimed at making computers more secure. It has defined and released an open architecture and a growing set of standards for endpoint integrity. The TNC architecture enables network operators to enforce policies regarding endpoint integrity at or after network connection. The standards ensure multiinteroperability across a wide variety of endpoints, network technologies, and policies.

: The standard is highly relevant for networking areas in FI-

: W3C defines the standard for an open and interoperable Web. As many areas of FItop of Web technologies, W3C activities are of high relevance. In the following we list important working

rivacy protection cannot be implemented by only relying on technology measures: legislation is an important aspect of the picture, though creative contribution to it is outside the scope of this project. P3P (Platform for Privacy Preferences Project) from W3C enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents, which will allow users to be informed of site practices (in both machine- and human readable formats) a

making based on these practices when appropriate, therefore users need not read the privacy policies at every site they visit. P3P work is suspended in W3C since specifications having reached a final state). PLING (Policy Languages Interest Group) has recently been established to discuss interoperability, requirements and related needs for integrating and computing the results when different policy languages used together, for example, OASIS XACML, IETF Common Policy, and P3P. OASIS (eXtensible Access Control Markup Language) is a comprehensive access control policy language in XML, together with a conceptual framework and a processing model. It is now considered to be a widelyaccepted industry standard. It can also be used for handling privacy policies; hence it receives distinguished attention in this project. A more sophisticated approach of policy-based access control is to define and rely on semantic policy languages such as SWRL (Semantic Web Rule Language). Another approaprotection is to rely on cryptographic solutions that make it practically impossible to leak sensitive information during a transaction. This area of security research is commonly referred to as PETs (Privacy Enhancing Technologies), and one of the most prominent fora these days is the annual PET Symposium: many interesting cryptographic solutions were developed until recently such as zero

enhancing signature schemes, anonymous browsing, secure multiprivate information retrieval, etc, but these techniques are still not in wide use.

Telemanagement Forum / IPsphere Framework

: The IPsphere Framework delivers a business layer for rapid service delivery, including advanced oriented architecture (SOA), the IPsphere

Framework defines mechanisms to automate offers, purchase and provision service components among

: Highly relevant for the “Interfaces to Networks and Devices” area.

: The TNC is a working group of the Trusted Computing Group, an incorporated industry working roup aimed at making computers more secure. It has defined and released an open architecture and a growing set of standards for endpoint integrity. The TNC architecture enables network operators to enforce

network connection. The standards ensure multi-vendor interoperability across a wide variety of endpoints, network technologies, and policies.

WARE

: W3C defines the standard for an open and interoperable Web. As many areas of FI-WARE build on top of Web technologies, W3C activities are of high relevance. In the following we list important working

rivacy protection cannot be implemented by only relying on technology measures: legislation is an important aspect of the picture, though creative contribution to it is outside the scope of this project. P3P

W3C enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents, which will

readable formats) and to automate making based on these practices when appropriate, therefore users need not read the privacy

policies at every site they visit. P3P work is suspended in W3C since specifications having reached a final Interest Group) has recently been established to discuss interoperability,

requirements and related needs for integrating and computing the results when different policy languages used together, for example, OASIS XACML, IETF Common Policy, and P3P. OASIS XACML (eXtensible Access Control Markup Language) is a comprehensive access control policy language in XML, together with a conceptual framework and a processing model. It is now considered to be a widely-

handling privacy policies; hence it receives distinguished based access control is to define and rely

on semantic policy languages such as SWRL (Semantic Web Rule Language). Another approach to privacy protection is to rely on cryptographic solutions that make it practically impossible to leak sensitive information during a transaction. This area of security research is commonly referred to as PETs (Privacy

of the most prominent fora these days is the annual PET Symposium: many interesting cryptographic solutions were developed until recently such as zero-knowledge proofs, all

enhancing signature schemes, anonymous browsing, secure multi-party computation,


5.19.2 W3C HTML5 Goal: The goal of HTML 5 is to bring the web into maturity as a fullstandard video, sound, images, and animationthe current draft, existing browser (Firefox 3.5, Internet Explorer 8, Safari 4, Chrome 2 and Opera 10) have already implemented parts of the specification and demonstrated many advanced featureused to be provided by external browser extensions.

The Future Internet as build by FITherefore, FI-WARE will tightly monitor W3C HTML5 and related standards. Currently, accontributions from the project are not envisioned due to the highly business driven activities in W3C HTML5.

5.19.3 W3C Geolocation APILocation-awareness is one element of the Context enabler. The W3C Geolocation WG is created in response to requests from the community for W3C to develop a standardized, secure and privacyinterface so that Web applications may gain access to location information. The objective of this Geolocation WG charter is to enable Web access to the user's location informationinterface or interfaces.

5.19.4 W3C Semantic Sensor Network Incubator Group (SSNGoals: The group has two main objectives. The first aim is developing an ontology to describe sensors and their device, system and platform related attributemark-up and to recommend methods to use ontology to describe the data available based on the existing models such as the Open Geospatial Consortium's (OGC) Sensor Web Enablement (SWE) standards.

FI-WARE relevance: W3C is defining the standards for the Web, which is an important part of today’s and tomorrow’s Internet. Therefore, the mentioned standards are highly relevant to several of FIworkpackages. UniSurrey (SSN sensor ontology) will be used amodel for the sensing resources in FI

5.19.5 W3C Web Applications Working Grouphttp://www.w3.org/2008/webapps/

Goals: The W3C Web Applications (WebApps) Working Group isenable improved client-side application development on the Web, including specifications both for APIs for client-side development and for markup vocabularies for describing and controlling clientapplication behaviour. The WebApps WG is part of the Rich Web Clients Activity in the W3C Interaction Domain.

FI-WARE relevance: The work being done by the W3C WebApps WG is relevant to FIWARE, and more specifically to WP3 because it focuses on developing clientWidgets are defined by the WebApps WG as fulltechnologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a client machine or device where they run not only as standpages and run in a Web browserpull data from multiple sources to be “mashedway.

: The goal of HTML 5 is to bring the web into maturity as a full-fledged application platform with standard video, sound, images, and animations. The whole specification is still being worked on. Based on the current draft, existing browser (Firefox 3.5, Internet Explorer 8, Safari 4, Chrome 2 and Opera 10) have already implemented parts of the specification and demonstrated many advanced featureused to be provided by external browser extensions.

The Future Internet as build by FI-WARE will definitely incorporate HTML5WARE will tightly monitor W3C HTML5 and related standards. Currently, ac

contributions from the project are not envisioned due to the highly business driven activities in W3C

W3C Geolocation API awareness is one element of the Context enabler. The W3C Geolocation WG is created in

he community for W3C to develop a standardized, secure and privacyinterface so that Web applications may gain access to location information. The objective of this Geolocation WG charter is to enable Web access to the user's location information

W3C Semantic Sensor Network Incubator Group (SSN: The group has two main objectives. The first aim is developing an ontology to describe sensors and

their device, system and platform related attributes. The second aim is to providing a report on semantic up and to recommend methods to use ontology to describe the data available based on the existing

models such as the Open Geospatial Consortium's (OGC) Sensor Web Enablement (SWE) standards.

W3C is defining the standards for the Web, which is an important part of today’s and tomorrow’s Internet. Therefore, the mentioned standards are highly relevant to several of FIworkpackages. UniSurrey (SSN sensor ontology) will be used and extended in defining the information model for the sensing resources in FI-WARE.

W3C Web Applications Working Group http://www.w3.org/2008/webapps/

: The W3C Web Applications (WebApps) Working Group is working on creating specifications that side application development on the Web, including specifications both for APIs

side development and for markup vocabularies for describing and controlling clientehaviour. The WebApps WG is part of the Rich Web Clients Activity in the W3C Interaction

The work being done by the W3C WebApps WG is relevant to FIWARE, and more specifically to WP3 because it focuses on developing client-side script APIs and specification for widgets. Widgets are defined by the WebApps WG as full-fledged client-side applications that are authored using technologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a

machine or device where they run not only as stand-alone applications, but also embedded into Web pages and run in a Web browser. Widgets, range from simple functionalities, to complex applications that pull data from multiple sources to be “mashed-up” and presented to a user in some interesting and useful

fledged application platform with s. The whole specification is still being worked on. Based on

the current draft, existing browser (Firefox 3.5, Internet Explorer 8, Safari 4, Chrome 2 and Opera 10) have already implemented parts of the specification and demonstrated many advanced features that in the past

WARE will definitely incorporate HTML5-based Web applications. WARE will tightly monitor W3C HTML5 and related standards. Currently, active

contributions from the project are not envisioned due to the highly business driven activities in W3C

awareness is one element of the Context enabler. The W3C Geolocation WG is created in he community for W3C to develop a standardized, secure and privacy-sensitive

interface so that Web applications may gain access to location information. The objective of this Geolocation WG charter is to enable Web access to the user's location information via a standardized

W3C Semantic Sensor Network Incubator Group (SSN -XG) : The group has two main objectives. The first aim is developing an ontology to describe sensors and

s. The second aim is to providing a report on semantic up and to recommend methods to use ontology to describe the data available based on the existing

models such as the Open Geospatial Consortium's (OGC) Sensor Web Enablement (SWE) standards.

W3C is defining the standards for the Web, which is an important part of today’s and tomorrow’s Internet. Therefore, the mentioned standards are highly relevant to several of FI-WARE

nd extended in defining the information

working on creating specifications that side application development on the Web, including specifications both for APIs

side development and for markup vocabularies for describing and controlling client-side ehaviour. The WebApps WG is part of the Rich Web Clients Activity in the W3C Interaction

The work being done by the W3C WebApps WG is relevant to FIWARE, and more script APIs and specification for widgets. side applications that are authored using

technologies such as HTML, then packaged for distribution and, typically, downloaded and installed on a alone applications, but also embedded into Web

. Widgets, range from simple functionalities, to complex applications that up” and presented to a user in some interesting and useful


5.19.6 SSN-XG (Semantic Sensor Network Incubator Group)The SSN-XG (Semantic Sensor Network Incubator Group) SSN sensor ontology will be used and extended in defining the information model for the sensing resources in FI

5.20 WAC (Wholesale Application Community)http://www.wholesaleappcommunity.com/default.aspx

Goal: WAC will provide the commercial enablers which will allow the developer to be paid for the applications which are then sold through any associated application store.

FI-WARE relevance: Highly relevant for

5.21 NIST (National Institute of Standards & Technology)http://www.nist.gov/index.html

Goal: The NIST is a federal technology agency that works with industry to develomeasurements, and standards.

FI-WARE relevance: Highly relevant for Security Chapter and more precisely for what concerns Security monitoring. Main interest relies here on the Security Content Automation Protocol (SCAP,) a broad program implemented by leveraging a suite of individual standards intended to support the standardization of security measurement and expression to promote interoperability of security products. The SCAP content leverages seven standards (CVE, CCE, CPE, XCCDF

XG (Semantic Sensor Network Incubator Group)ensor Network Incubator Group) SSN sensor ontology will be used and extended

in defining the information model for the sensing resources in FI-WARE)

WAC (Wholesale Application Community)/www.wholesaleappcommunity.com/default.aspx

: WAC will provide the commercial enablers which will allow the developer to be paid for the applications which are then sold through any associated application store.

: Highly relevant for the “Application and Services Ecosystem” area.

NIST (National Institute of Standards & Technology)

is a federal technology agency that works with industry to develo

: Highly relevant for Security Chapter and more precisely for what concerns Security monitoring. Main interest relies here on the Security Content Automation Protocol (SCAP,) a broad

gram implemented by leveraging a suite of individual standards intended to support the standardization of security measurement and expression to promote interoperability of security products. The SCAP content leverages seven standards (CVE, CCE, CPE, XCCDF, OVAL, OCIL and CVSS)..

XG (Semantic Sensor Network Incubator Group) ensor Network Incubator Group) SSN sensor ontology will be used and extended

WAC (Wholesale Application Community)

: WAC will provide the commercial enablers which will allow the developer to be paid for the

the “Application and Services Ecosystem” area.

NIST (National Institute of Standards & Technology)

is a federal technology agency that works with industry to develop and apply technology,

: Highly relevant for Security Chapter and more precisely for what concerns Security monitoring. Main interest relies here on the Security Content Automation Protocol (SCAP,) a broad

gram implemented by leveraging a suite of individual standards intended to support the standardization of security measurement and expression to promote interoperability of security products. The SCAP

, OVAL, OCIL and CVSS)..

FI-WARE Standardization Plan (D.11.4.a) · FI-WARE-12-03-12 -WARE activities. FI-WARE...

Documents

Transcript of FI-WARE Standardization Plan (D.11.4.a) · FI-WARE-12-03-12 -WARE activities. FI-WARE...