DOCSLIB.ORG

The Interoperability Framework for E-Government

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Office of the Government Chief Information Officer The Interoperability Framework for e-Government [S18] Version: 19.0 December 2020 The Government of the Hong Kong Special Administrative Region of the People’s Republic of China COPYRIGHT NOTICE © 2020 by the Government of the Hong Kong Special Administrative Region Unless otherwise indicated, the copyright in the works contained in this publication is owned by the Government of the Hong Kong Special Administrative Region. You may generally copy and distribute these materials in any format or medium provided the following conditions are met – (a) the particular item has not been specifically indicated to be excluded and is therefore not to be copied or distributed; (b) the copying is not done for the purpose of creating copies for sale; (c) the materials must be reproduced accurately and must not be used in a misleading context; and (d) the copies shall be accompanied by the words “copied/distributed with the permission of the Government of the Hong Kong Special Administrative Region. All rights reserved.” If you wish to make copies for purposes other than that permitted above, you should seek permission by contacting the Office of the Government Chief Information Officer. INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT DISTRIBUTION AND RELEASE Distribution of Controlled Copy Copy No. Holder 1 Government-wide Intranet (itginfo.ccgo.hksarg) 2 Internet (www.ogcio.gov.hk) Prepared By: Interoperability Framework Coordination Group Document Effective Date: 1 March 2021 i-1 INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT AMENDMENT HISTORY Amendment History Change Revision Description Pages Revision Date Number Affected Number Major updates to version 18.1 issued in 19.0 December February 2020 are as follows: 2020 1. Add “OpenAPI v3.0” as a recommended 7-2 standard to the interoperability area “Simple functional integration in an open environment” under Application Integration Domain. 2. Remove “ISO/TS 15000-2:2004” from name 7-3 of the Recommended Standard “ebMS v2 (ISO/TS 15000-2:2004)” from the interoperability area “Reliable message exchange between application systems in an open environment for business document- oriented collaboration” under Application Integration Domain. 3. Add “PDF/A-1a (ISO 19005-1 Level A)” and 7-4 “PDF/A-1b (ISO 19005-1 Level B)” as the recommended standards to the interoperability area “Document file type for receiving documents under ETO” under Information Access & Interchange Domain. 4. Update the remarks of interoperability area 7-7 “Removable storage media for receiving documents under the ETO” under Information Access & Interchange Domain. 5. Add “MPEG-4 (ISO 14496)” as a 7-8 recommended standard to the interoperability area “Audio / video streaming” under Information Access & Interchange Domain 6. Update the version of “GeoTIFF”of the 7-9 interoperability area “Digital Geographic Data Format” under Information Access & Interchange Domain 7. Update the version of “ISO 19111” of the 7-9 interoperability area “Digital Geographic Data Format” under Information Access & Interchange Domain ii-1 INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT AMENDMENT HISTORY Amendment History Change Revision Description Pages Revision Date Number Affected Number 8. Add “Geography JavaScript Object Notation 7-9 (GeoJSON - RFC 7946)” as a recommended standard to the interoperability area “Digital Geographic Data Format” under Information Access & Interchange Domain. 9. Add “S/MIME v4” as a recommended 7-10 standard to the interoperability area “Attachment of digital signature to electronic documents received under ETO” under Security Domain. 10. Add “S/MIME v4” as a recommended 7-10 standard to the interoperability area “E-mail security” under Security Domain. 11. Add “STIX v2.1” as a recommended standard 7-13 to the interoperability area “Cyber threat information sharing standards” under Security Domain. 12. Add “TAXII v2.1” as a recommended 7-13 standard to the interoperability area “Cyber threat information sharing standards” under Security Domain. 13. Remove the version of the standard “CTAP” 7-14 from the interoperability area “Authentication and authorisation with distributed identity” under Security Domain. 14. Add “HTTP/2” as a recommended standard to 7-14 the interoperability area “Hypertext transfer protocol” under Interconnection Domain. 15. Add “HTTP/2” as a recommended standard to 7-14 the interoperability area “File transfer” under Interconnection Domain. 16. Update the “Are the specifications relevant to 7-14 submissions under ETO ?” of interoperability area “File transfer” under Interconnection Domain. ii-2 INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT AMENDMENT HISTORY Amendment History Change Revision Description Pages Revision Date Number Affected Number 17. Add “Data Distribution Service (DDS)” as an 7-16 under observation standard (or emerging standard) to the interoperability area “Asynchronous message exchange between application systems” in the Application Integration Domain. 18. Remove the version of the standard “WS- 7-16 Addressing” from the interoperability area “Transport-neutral mechanisms to address Web Services and messages” under Application Integration Domain. 19. Remove the version of the standard “WS- 7-16 Policy” from the interoperability area “Grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web Services-based system” under Application Integration Domain. ii-3 INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT CONTENTS TABLE OF CONTENTS 1.EXECUTIVE SUMMARY ............................................................................................... 1-1 2.PURPOSE AND STRUCTURE OF DOCUMENT ........................................................ 2-1 3.OVERVIEW OF THE INTEROPERABILITY FRAMEWORK ................................ 3-1 3.1 THE NEED FOR AN INTEROPERABILITY FRAMEWORK .................................. 3-1 3.2 SCOPE OF THE INTEROPERABILITY FRAMEWORK ......................................... 3-1 3.3 IMPACT OF THE INTEROPERABILITY FRAMEWORK ....................................... 3-3 4.MANAGEMENT OF THE INTEROPERABILITY FRAMEWORK ........................ 4-1 4.1 KEY REQUIREMENTS FOR MANAGEMENT MECHANISM .............................. 4-1 4.2 MANAGEMENT OF TECHNICAL SPECIFICATIONS ........................................... 4-1 4.3 MANAGEMENT OF COMMON SCHEMAS ............................................................ 4-2 4.4 CHANGE MANAGEMENT ........................................................................................ 4-2 5.COMPLIANCE ................................................................................................................. 5-1 5.1 THE USE OF TECHNICAL SPECIFICATIONS AND COMMON SCHEMAS ....... 5-1 5.2 COMPLIANCE POLICY ............................................................................................. 5-1 5.3 COMPLYING TO NEW VERSIONS OF THE INTEROPERABILITY FRAMEWORK ...................................................................................................................................... 5-2 5.4 WHO NEEDS TO UNDERSTAND COMPLIANCE .................................................. 5-3 5.5 RESPONSIBILITIES .................................................................................................... 5-3 5.6 PROCEDURES FOR EXEMPTION FROM COMPLIANCE .................................... 5-3 6.PRINCIPLES UNDERLYING THE RECOMMENDATION OF TECHNICAL STANDARDS .............................................................................................................. 6-1 6.1 PRINCIPLES TO BE OBSERVED BY PROJECT TEAMS WITH REGARD TO THE USE OF THE IF TECHNICAL STANDARDS ........................................................... 6-1 6.2 PRINCIPLES FOR INCLUDING INTEROPERABILITY AREAS UNDER THE IF 6-2 6.3 PRINCIPLES FOR SELECTING TECHNICAL STANDARDS UNDER THE IF .... 6-3 7.SPECIFICATIONS UNDER THE INTEROPERABILITY FRAMEWORK ............ 7-1 7.1 OVERVIEW ................................................................................................................. 7-1 7.2 APPLICATION INTEGRATION DOMAIN ............................................................... 7-2 7.3 INFORMATION ACCESS AND INTERCHANGE DOMAIN .................................. 7-3 7.4 SECURITY DOMAIN ................................................................................................ 7-10 7.5 INTERCONNECTION DOMAIN ............................................................................. 7-14 7.6 OTHER SPECIFICATIONS UNDER OBSERVATION ........................................... 7-16 8.ABBREVIATIONS AND ACRONYMS ......................................................................... 8-1 iii-1 INTEROPERABILITY FRAMEWORK FOR E-GOVERNMENT EXECUTIVE SUMMARY 1. EXECUTIVE SUMMARY The Interoperability Framework (IF) supports the Government’s strategy of providing client-centric joined-up services by facilitating the interoperability of technical systems between Government departments, as well as between Government systems and systems used by the public (including citizens and businesses). The IF defines a collection of specifications aimed at facilitating the interoperability of Government systems and services. By bringing together the relevant specifications under an overall framework, IT management and developers can have a single point of reference when there is a need to identify the required interoperability specifications that should be followed for a specific project. By adopting these interoperability specifications, system designers can ensure
Recommended publications
  • Odata Services Company

    Odata Services Company

    PUBLIC 2021-03-09 OData Services company. All rights reserved. All rights company. affiliate THE BEST RUN 2021 SAP SE or an SAP SE or an SAP SAP 2021 © Content 1 SAP Cloud for Customer OData API..............................................4 2 New Features.............................................................. 13 2.1 What's New in OData API v2 Reference.............................................13 2.2 Add Public Solution Model (PSM) Fields to Standard OData Services........................15 2.3 Transport Custom OData Services with Transport Management............................16 2.4 Compatibility Mode for READ Operations........................................... 16 2.5 Support for User-Friendly IDs in Standard OData Services................................16 2.6 Constant Values to Function Imports...............................................17 3 OData API Reference.........................................................18 3.1 OData API v2 Reference........................................................18 3.2 OData API v1 Reference (Deprecated)..............................................20 Account Contact Relationship.................................................21 Account EntityType........................................................22 Appointment Entity Type....................................................40 BusinessPartner Entity Type..................................................46 CodeList Entity Type....................................................... 47 Contextual CodeList Entity Type...............................................48
  • Pyslet Documentation Release 0.6.20160201

    Pyslet Documentation Release 0.6.20160201

    Pyslet Documentation Release 0.6.20160201 Steve Lay February 02, 2016 Contents 1 What’s New? 1 2 Compatibility 7 3 IMS Global Learning Consortium Specifications 13 4 The Open Data Protocol (OData) 101 5 Hypertext Transfer Protocol (RFC2616) 207 6 Other Supporting Standards 247 7 Welcome to Pyslet 357 Python Module Index 359 i ii CHAPTER 1 What’s New? As part of moving towards PEP-8 compliance a number of name changes are being made to methods and class at- tributes with each release. There is a module, pyslet.pep8, which contains a compatibility class for remapping missing class attribute names to their new forms and generating deprecation warnings, run your code with “python -Wd” to force these warnings to appear. As Pyslet makes the transition to Python 3 some of the old names will go away completely. It is still possible that some previously documented names could now fail (module level functions, function arguments, etc.) but I’ve tried to include wrappers or aliases so please raise an issue on Github if you discover a bug caused by the renaming. I’ll restore any missing old-style names to improve backwards compatibility on request. Finally, in some cases you are encouraged to derive classes from those defined by Pyslet and to override default method implementations. If you have done this using old-style names you will have to update your method names to prevent ambiguity. I have added code to automatically detect most problems and force fatal errors at runtime on construction, the error messages should explain which methods need to be renamed.
  • Move Beyond Passwords Index

    Move Beyond Passwords Index

    Move Beyond Passwords Index The quest to move beyond passwords 4 Evaluation of current authentication method 6 Getting started with passwordless authentication 8 Early results to going passwordless 9 Common approaches to going passwordless 11 Email magic links 11 Factor sequencing 12 Webauthn 14 Planning for a passwordless future 16 Move Beyond Passwords 2 Introduction Traditional authentication using a username and password has been the foundation of digital identity and security for over 50 years. But with the ever-growing number of user accounts, there are a number of new issues: the burden on end users to remember multiple passwords, support costs, and most importantly, the security risks posed by compromised credentials. These new challenges are now outweighing the usefulness of passwords. The case for eliminating passwords from the authentication experience is getting more compelling every day. Emerging passwordless security standards, elevated consumer and consumer-like experience expectations, and ballooning costs have moved eliminating passwords from a theoretical concept to a real possibility. In this whitepaper, we will explore the case for going passwordless for both customer and employee authentication, and map out steps that organizations can take on their journey to true passwordless authentication. Move Beyond Passwords 3 The quest to move beyond passwords Understanding the need for passwordless authentication starts with understanding the challenges presented by passwords. The core challenges with passwords can be broken down into the following areas: Poor Account Security Passwords have spawned a whole category of security/identity-driven attacks — compromised passwords due to credential breaches, phishing, password spraying attacks, or poor password hygiene can result in account takeover attacks (ATO).
  • ISO/IEC JTC 1 Information Technology

    ISO/IEC JTC 1 Information Technology

    ISO/IEC JTC 1 Information technology Big data Preliminary Report 2014 Our vision Our process To be the world’s leading provider of high Our standards are developed by experts quality, globally relevant International all over the world who work on a Standards through its members and volunteer or part-time basis. We sell stakeholders. International Standards to recover the costs of organizing this process and Our mission making standards widely available. ISO develops high quality voluntary Please respect our licensing terms and International Standards that facilitate copyright to ensure this system remains international exchange of goods and independent. services, support sustainable and equitable economic growth, promote If you would like to contribute to the innovation and protect health, safety development of ISO standards, please and the environment. contact the ISO Member Body in your country: www.iso.org/iso/home/about/iso_ members.htm This document has been prepared by: Copyright protected document ISO/IEC JTC 1, Information technology All rights reserved. Unless otherwise Cover photo credit: ISO/CS, 2015 be reproduced or utilized otherwise in specified,any form noor partby anyof this means, publication electronic may or mechanical, including photocopy, or posting on the internet or intranet, without prior permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester: © ISO 2015, Published in Switzerland Case postale 56 • CH-1211 Geneva 20 Tel.ISO copyright+41 22
  • Haris Kurtagic, SL-King Jason Birch, City of Nanaimo Geoff Zeiss, Autodesk Tim Berners-Lee, in Government Data Design Issues, Proposes

    Haris Kurtagic, SL-King Jason Birch, City of Nanaimo Geoff Zeiss, Autodesk Tim Berners-Lee, in Government Data Design Issues, Proposes

    Haris Kurtagic, SL-King Jason Birch, City of Nanaimo Geoff Zeiss, Autodesk Tim Berners-Lee, in Government Data Design Issues, proposes ○ Geodata on the web in raw form. ○ Raw geodata must be searchable How do you find raw geospatial data ? Data Catalogs Wouldn’t it be nice if… And see.. Searchable Raw Geospatial Data www.georest.org Open Data Protocol “The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today.” www.odata.org ODATA HTTP Atom AtomPUB JSON HTTP://.../vancouver/libraries <feed xmlns=http://www.w3.org/2005/Atom … > <title type="text">libraries</title> <id>http://…/vancouver/libraries(10)</id> <title type="text"></title> <entry> <content type="application/xml"> <m:properties> <d:library_name>Britannia</d:library_name> <d:latitude m:type="Edm.Double">49.2756486</d:latitude> <d:longitude m:type="Edm.Double">-123.0737717</d:longitude> <d:address>1661 Napier St</d:address> </m:properties> …..</entry> <entry>…</entry></feed> HTTP://.../vancouver/libraries ?$format=JSON {"d":[{"library_name":"Britannia","latitude":" 49.2756486","longitude":"- 123.0737717","address":"1661 Napier St"} , {..}] } HTTP Header accept: application/json OData Example Live OData Service from Vancouver OData Producers SharePoint 2010, SQL Azure, IBM WebSphere, … GeoREST OData Live Services Netflix, Open Goverment Data Initiative (OGDI), Stack Overflow, Vancouver, Edmonton, … City of Nanaimo OData Consumers Browsers, Odata Explorer, Excel 2010,…
  • Cybersecurity in a Digital Era.Pdf

    Cybersecurity in a Digital Era.Pdf

    Digital McKinsey and Global Risk Practice Cybersecurity in a Digital Era June 2020 Introduction Even before the advent of a global pandemic, executive teams faced a challenging and dynamic environ- ment as they sought to protect their institutions from cyberattack, without degrading their ability to innovate and extract value from technology investments. CISOs and their partners in business and IT functions have had to think through how to protect increasingly valuable digital assets, how to assess threats related to an increasingly fraught geopolitical environment, how to meet increasingly stringent customer and regulatory expectations and how to navigate disruptions to existing cybersecurity models as companies adopt agile development and cloud computing. We believe there are five areas for CIOs, CISOs, CROs and other business leaders to address in particular: 1. Get a strategy in place that will activate the organization. Even more than in the past cybersecurity is a business issue – and cybersecurity effectiveness means action not only from the CISO organiza- tion, but also from application development, infrastructure, product development, customer care, finance, human resources, procurement and risk. A successful cybersecurity strategy supports the business, highlights the actions required from across the enterprise – and perhaps most importantly captures the imagination of the executive in how it can manage risk and also enable business innovation. 2. Create granular, analytic risk management capabilities. There will always be more vulnerabilities to address and more protections you can consider than you will have capacity to implement. Even companies with large and increasing cybersecurity budgets face constraints in how much change the organization can absorb.
  • SAP Analytics Cloud, Analytics Designer Developer Handbook

    SAP Analytics Cloud, Analytics Designer Developer Handbook

    SAP Analytics Cloud, analytics designer Developer Handbook Document Version: 5.1 – 2020-04-06 Table of Contents 1 Table of Contents Table of Contents ......................................................................................................................... 1 Figures .......................................................................................................................................... 7 1 About Analytics Designer .............................................................................................10 1.1 What Is an Analytic Application? .....................................................................................10 1.2 What Is Analytics Designer? ............................................................................................10 1.3 What Can You Do with Analytic Applications That You Can’t Do with Stories? ..............10 1.4 How Are Stories and Analytic Applications Related to Each Other? ...............................10 1.5 Why Do We Need Both Stories and Analytic Applications? ............................................11 1.6 What Is the Typical Workflow in Creating an Analytic Application? .................................11 1.7 What Are Typical Analytic Applications? .........................................................................12 1.8 How Does Scripting Work in Analytic Applications? ........................................................12 1.9 What’s the Scripting Language for Analytic Applications? ..............................................13 2 Getting
  • Catalogue Open Data Protocol (Odata API) User Guide

    Catalogue Open Data Protocol (Odata API) User Guide

    Catalogue Open Data Protocol (OData API) User Guide Content 1. Introduction .......................................................................................................................................... 3 1.1. Purpose......................................................................................................................... 3 1.2. Change register ............................................................................................................. 3 1.3. Structure of the document ............................................................................................. 3 1.4. Acronyms ...................................................................................................................... 4 1.5. Reference Documents ................................................................................................... 4 2. Open Data Protocol overview ............................................................................................................. 6 2.1. Entity Data Model concept ............................................................................................ 6 Entity Type ..................................................................................................................... 7 Entity Set ....................................................................................................................... 7 3. ONDA OData Entity Data Model ......................................................................................................... 8 3.1. ONDA Entity
  • Implementing a Web Application for W3C Webauthn Protocol Testing †

    Implementing a Web Application for W3C Webauthn Protocol Testing †

    proceedings Proceedings Implementing a Web Application for W3C WebAuthn Protocol Testing † Martiño Rivera Dourado 1,* , Marcos Gestal 1,2 and José M. Vázquez-Naya 1,2 1 Grupo RNASA-IMEDIR, Departamento de Computación, Facultade de Informática, Universidade da Coruña, Elviña, 15071 A Coruña, Spain; [email protected] (M.G.); [email protected] (J.M.V.-N.) 2 Centro de Investigación CITIC, Universidade da Coruña, Elviña, 15071 A Coruña, Spain * Correspondence: [email protected] † Presented at the 3rd XoveTIC Conference, A Coruña, Spain, 8–9 October 2020. Published: 18 August 2020 Abstract: During the last few years, the FIDO Alliance and the W3C have been working on a new standard called WebAuthn that aims to substitute the obsolete password as an authentication method by using physical security keys instead. Due to its recent design, the standard is still changing and so are the needs for protocol testing. This research has driven the development of a web application that supports the standard and gives extensive information to the user. This tool can be used by WebAuthn developers and researchers, helping them to debug concrete use cases with no need for an ad hoc implementation. Keywords: WebAuthn; authentication; testing 1. Introduction Authentication is one of the most critical parts of an application. It is a security service that aims to guarantee the authenticity of an identity. This can be done by using several security mechanisms but currently, without a doubt, the most common is the username and password method. Although this method is easy for a user to conceptually understand, it constitutes many security problems.
  • 8 Steps for Effectively Deploying

    8 Steps for Effectively Deploying

    8 Steps for Effectively Deploying MFA Table of Contents The value of MFA 3 1. Educate your users 4 2. Consider your MFA policies 5 3. Plan and provide for a variety of access needs 7 4. Think twice about using SMS for OTP 10 5. Check compliance requirements carefully 11 6. Plan for lost devices 12 7. Plan to deploy MFA to remote workers 14 8. Phase your deployment: Be prepared to review and revise 16 8 Steps for Effectively Deploying MFA 2 The value of MFA Multi-factor authentication (MFA) has never been more important. With the growing number of data breaches and cybersecurity threats—and the steep financial and reputational costs that come with them—organizations need to prioritize MFA deployment for their workforce and customers alike. Not doing so could spell disaster; an invitation for bad actors to compromise accounts and breach your systems. Adopting modern MFA means implementing a secure, simple, and context-aware solution that ensures that only the right people have access to the right resources. It adds a layer of security, giving your security team, your employees, and your customers peace of mind. Unfortunately, while the benefits are clear, implementing MFA can be a complex project. In our Multi-factor Authentication Deployment Guide, we’ve outlined eight steps that you can take to better enable your MFA deployment: Educate your users Consider your MFA policies Plan and provide for a variety of access needs Think twice about using SMS for OTP Check compliance requirements carefully Plan for lost devices Plan to deploy MFA to remote workers Phase your deployment: be prepared to review and revise In this eBook, we’ll take a deeper dive into each of these elements, giving you tactical advice and best practices for how to implement each step as you get ready to roll out Okta MFA.
  • Mfaproxy: a Reverse Proxy for Multi-Factor Authentication

    Mfaproxy: a Reverse Proxy for Multi-Factor Authentication

    Iowa State University Capstones, Theses and Creative Components Dissertations Fall 2019 MFAProxy: A reverse proxy for multi-factor authentication Alan Schmitz Follow this and additional works at: https://lib.dr.iastate.edu/creativecomponents Part of the Digital Communications and Networking Commons Recommended Citation Schmitz, Alan, "MFAProxy: A reverse proxy for multi-factor authentication" (2019). Creative Components. 425. https://lib.dr.iastate.edu/creativecomponents/425 This Creative Component is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Creative Components by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. MFAProxy: A reverse proxy for multi-factor authentication by Alan Schmitz A Creative Component submitted to the graduate faculty in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE Major: Information Assurance Program of Study Committee: Doug Jacobson, Major Professor The student author, whose presentation of the scholarship herein was approved by the program of study committee, is solely responsible for the content of this Creative Component. The Graduate College will ensure this Creative Component is globally accessible and will not permit alterations after a degree is conferred. Iowa State University Ames, Iowa 2019 Copyright c Alan Schmitz, 2019. All rights reserved. ii TABLE OF CONTENTS Page LIST OF FIGURES . iii ABSTRACT . iv CHAPTER 1. INTRODUCTION . .1 CHAPTER 2. BACKGROUND . .3 2.1 Passwords and PINs . .3 2.2 Short Message Service . .4 2.3 One-Time Passwords . .5 2.4 U2F and WebAuthn .
  • Deliverable D7.5: Standards and Methodologies Big Data Guidance

    Deliverable D7.5: Standards and Methodologies Big Data Guidance

    Project acronym: BYTE Project title: Big data roadmap and cross-disciplinarY community for addressing socieTal Externalities Grant number: 619551 Programme: Seventh Framework Programme for ICT Objective: ICT-2013.4.2 Scalable data analytics Contract type: Co-ordination and Support Action Start date of project: 01 March 2014 Duration: 36 months Website: www.byte-project.eu Deliverable D7.5: Standards and methodologies big data guidance Author(s): Jarl Magnusson, DNV GL AS Erik Stensrud, DNV GL AS Tore Hartvigsen, DNV GL AS Lorenzo Bigagli, National Research Council of Italy Dissemination level: Public Deliverable type: Final Version: 1.1 Submission date: 26 July 2017 Table of Contents Preface ......................................................................................................................................... 3 Task 7.5 Description ............................................................................................................... 3 Executive summary ..................................................................................................................... 4 1 Introduction ......................................................................................................................... 5 2 Big Data Standards Organizations ...................................................................................... 6 3 Big Data Standards ............................................................................................................. 8 4 Big Data Quality Standards .............................................................................................