# An Architecture for Trustworthy Open Data Services

Andrew Wong, Vicky Liu, William Caelli, Tony Sahama

## ► To cite this version:

Andrew Wong, Vicky Liu, William Caelli, Tony Sahama. An Architecture for Trustworthy Open Data Services. 9th IFIP International Conference on Trust Management (TM), May 2015, Hamburg, Germany. pp.149-162, 10.1007/978-3-319-18491-3_11. hal-01416221

HAL Id: hal-01416221

https://inria.hal.science/hal-01416221

Submitted on 14 Dec 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Architecture for Trustworthy Open Data Services

Andrew Wong, Vicky Liu, William Caelli, and Tony Sahama

Science and Engineering Faculty
Queensland University of Technology
Brisbane, Australia.

(jianwye.wong, v.liu, w.caelli, t.tony)@qut.edu.au

**Abstract.** This paper addresses the development of trust in the use of Open Data through incorporation of appropriate authentication and integrity parameters for use by end user Open Data application developers in an architecture for trustworthy Open Data Services. The advantages of this architecture scheme is that it is far more scalable, not another certificate-based hierarchy that has problems with certificate revocation management. With the use of a Public File, if the key is compromised; it is a simple matter of the single responsible entity replacing the key pair with a new one and re-performing the data file signing process. Under this proposed architecture, the Open Data environment does not interfere with the internal security schemes that might be employed by the entity. However, this architecture incorporates, when needed, parameters from the entity, e.g. person who authorized publishing as Open Data, at the time that datasets are created/added.

**Keywords:** Open Data, Integrity, REST, Security, Public File

## 1 Introduction

During the course of his doctoral study, Roy Fielding generalized the architectural principles that drove the Web conceived of by Tim Berners-Lee in the early 1990s and presented these principles as an architectural style which was underpinned by a framework of constraints. This framework was named Representational State Transfer (REST) [1] and systems which adhere to this framework are called “RESTful” systems or services. Because of the REST framework’s ease of use and deployment, it has since been used in a variety of other development methodologies, including web services and application programming interface (API) development, and has since become a serious rival to the use of the earlier Simple Object Access Protocol (SOAP) [2] which is a successor to the Remote Procedure Call (RPC) programming style. These SOAP and REST based APIs have been used to communicate data and information in many fields, most recently, Open Data.

Open Data is data that can be freely used, shared and built-on by anyone, anywhere for any purpose [3]. The recent global trends towards Open Data have organizations and governments relying on these APIs to communicate Open Data in a greater extent than before.
One of the key advantages of Open Data is that it increases the availability of data for consumers in decision making as well as providing potential for massive cost reduction through implicit outsourcing of information system development. At regional governmental level, a combination of Open Data with appropriate interrogation programs could possibly replace physical publication of such documents as guidebooks, listings, etc. The active interest and support by various national and international non-governmental organization as well as state and federal government sponsored ‘hackathons’ such as GovHack [4] and HealthHack [5] aiming to develop new applications that use Open Data also could lead to a strong upsurge in the use of Open Data in various fields.

As the capacity for acquiring and storing data increasing from year to year and with data analytics exerting greater influence on decision making than in years past, trust has to be placed in not just the processes and algorithms used to analyse data, but in the authenticity and integrity of data as well. There is now a fast developing trend for enterprises; both public and private, to incorporate Open Data with proprietary and private data collections in order to provide better decision making and other reports. However, how can users trust conclusions or decisions made on the basis of results obtained from largely, untrusted data?

An adversary, wishing to use any means necessary to cause disruption, may wish to misuse the Open Data movement to achieve this disruption within the society by:

1. Diverting Open Data requests to a fraudulent site containing fraudulent datasets

2. Insertion of a fraudulent dataset into a legitimate site

3. Deliberate modification of a legitimate dataset

4. Denial of Service should Open Data become an integral and essential part of a community service

Therefore, it becomes of vital significance to ensure the authenticity and integrity of Open Data in order to placing trust in decision making based on that same Open Data, for users, businesses, industry and government alike.

## 2 Paper Scope

Because of the nature of Open Data, methods such as encryption which is aimed at the confidentiality aspect of data may not be completely relevant in the broad philosophy of Open Data, but may be briefly discussed.

This paper addresses development of trust in the usage or adaptation of Open Data through the incorporation of appropriate authentication and integrity parameters for data included in end-user Open Data applications by developers. The principle here is that the average person would not normally access raw Open Data collections but would view them through the lens of an appropriate application. The user would therefore need to be able to trust both the authenticity and integrity of data supplied by the application.

The proposed architecture makes use of the Domain Name System Security Extensions (DNSSEC) for host/server verification. However, the full description of
DNSSEC functionality lies outside the scope of this paper, and will only be briefly discussed in relation to how it fits into the proposed architecture as a whole. It should be noted that DNSSEC does not use digital certificates but rather a public key hierar- chical registry.

The paper will also discuss the proposed architecture’s use of a public key hierar- chical registry and digital signatures instead of the traditional certificate authority for the authentication of data publishers and integrity of datasets.

# 3 Related Work

## 3.1 Trustworthy Open Data

Open Data, which at its core, is the idea that certain types of data should be freely accessible to the public has its roots in the concept of open access to scientific data in the 1950s [6]. In more recent years, researchers have indicated the potential benefits of using Open Data analytics for positive effect in various fields [1, 8, 8, 10, 11] and coupled with the rise of Open Government [12,13,14], the Open Data movement stands to make even greater impact in the near future. However there are certain chal- lenges that Open Data faces, not the least of which is ensuring data quality and foster- ing trust in Open Data [15]. Strong [16] and later Mazon [17] recognize “fitness for use” as being the definition of data quality and an important criterion for data analyt- ics and business intelligence, and security plays an important role in ensuring both data quality and trust.

A database search returned few works relating to on methods for Open Data securi- ty. Telikicherla and Chopella [18] propose a library for secure web application devel- opment as a means of preventing “frame busting” and other attacks in HTML5 based Open Data mashups. Eckert et al. [19] present a workflow model which preserves provenance for Linked Data and can be applied to Open Data. These approaches have their merits in the area of browser security and preserving provenance for data, how- ever, as Open Data depends on the ability to transmit data that can be verified as both coming from an authenticated source while retaining integrity through the transmis- sion process and therefore is trustworthy to the user, this issue still needs to be ad- dressed.

## 3.2 Security for REST

The United States, United Kingdom, Japan, and Australia among others, use a soft- ware called the Comprehensive Knowledge Archive Network (CKAN), an open source data management platform to manage and publish their Open Data [20]. CKAN's Action API is based on the RPC programming style. Another well-known Open Data Management Suite is Socrata. The Socrata Open Data API (SODA) pro- vides an open, standards-based REST API [21]. In the case of the United States, the wide variety of government services and organizations has led to the use of both CKAN [22] and SODA [23] at the state and federal government levels.
As APIs for Open Data is mostly disseminated through the platform of the World Wide Web (WWW), and the WWW is based on REST principles as coded by Fielding [1], in order for Open Data to be secure, REST also needs to be secure. In Fielding’s thesis, REST was designed to provide simplicity of implementation and scalability but has no pre-defined security protection mechanisms [24] when compared to SOAP, which uses the WS-Security [25] standard. In response to this, several authors have recently suggested mechanisms by which to provide security for REST:

Forsberg [26] proposed an approach where content protection was based on keys being delivered to clients via secure session. Forsberg’s approach eliminates the need for repeated SSL/TLS encryption of cached content. Forsberg further notes that their solution is adjusted to match better with caching for data that requires confidentiality protection. An approach which used extended HTTP headers to effect extended username tokens was proposed by Dunlu et al. [27] for user authentication. A secondary password for the username token was required in order to avoid leakage of user password. The approach proposed by Serme et al. [28] had some similarities to Dunlu et al. where they used extended HTTP headers, except that Serme’s approach uses the HTTP headers to convey digital certificate and encryption information.

Lee and Mehta [29], investigating some of the security threats to REST-based Web Services concluded that although message encryption by HTTPS was a costly protection method, HTTPS-based data transfer was the best method to ensure data confidentiality. Backere et al. [30] state that the best solution to the RESTful security problem, or the one most conforming to RESTful principles, is to differentiate between messages that need to be encrypted and those that do not, that a message is not-modifiable, and that replayed messages be avoided. They propose a login and REST resource access mechanism that leveraged these concepts.

There is a common consensus that it is necessary for appropriate security mechanisms to be employed in REST Web Services, however the means of accomplishing this as well as the security properties to be protected vary from approach to approach. Most of the solutions presented by these authors however, focus on authenticating the user or protecting the confidentiality of information held in RESTful systems while using certificate-based Secure Sockets Layer/Transport Layer Security (SSL/TLS). This however, begs the question: Is it necessary to protect the confidentiality of *publicly available* Open Data, or even to authenticate users of Open Data?

The answer to this question is: Open Data by its very nature is public data, therefore it should be viewable by the public and not restricted by confidentiality mechanisms. With this, authentication of the end user for read-only access to Open Data is not strictly necessary. Having said this, restricting access to the methods that can be used to alter Open Data resources to authenticated entities, such as the original publisher of the data, or other authorized parties is still required. An important quality that was brought up by Backere et al. [30] which relates to Open Data is that messages and content should be unmodifiable, which basically refers to the integrity of Open Data resources and collections even as they are transferred and cached over the Web.
### 3.3 Public Key Infrastructures

There are two aspects to Open Data; 1) the management of Open Data collections, one of which involves actions by an authoritative source like adding, modifying or deleting datasets, and, 2) the usage or modification of datasets post-addition. Both of these aspects require authentication that: 1) The host of the data is genuine, and, 2) the data has been published by an authentic source, and, 3) the data being transmitted itself is genuine and remains unchanged through the communication process. This authentication can be accomplished through the use of message digests and digital signatures. Binding

Diffie and Hellman [31] proposed a “public file” which could be used as a central authority for the binding of a specific identity to a particular public key for authentication purposes, thereby establishing a hierarchy of trust. Because of the technological limitations of the time, this approach has proven unfeasible when compared with the public key certificate concept proposed by Kohnfelder [32]. The public key certificate authentication scheme based on Kohnfelder’s thesis is now ubiquitous, however, despite the technological barrier for the use of the” public file” no longer being applicable and issues with public key certificate management that have been highlighted by Clarke [33], most notably complexity and the problems with certificate revocation mechanisms.

Rivest attempts to address the issue of certificate revocation by proposing that proper certificate infrastructure organization can allow a signer to present a collection of certificates as evidence of authenticity [34]. Another paper authored a few years later by McDaniels and Rubin [35] state that addressing PKI requirements in large, loosely coupled environments using certificate revocation lists is difficult and a web environment based on REST, as envisioned by Fielding, is designed to be a large, loosely coupled environment.

There have been recent attempts to address the problems with public key certificate based authentication and trust through initiatives that leverage the abilities of multiple certificate notaries, such as the Perspectives Project, [36] and Convergence [37]. The Perspectives Project and Convergence provide trust agility in which the user is given the ability to decide which party they wish to trust for authentication of certificates. In general, these initiatives provide trust that the certificate is genuine by leveraging multiple certificate notaries to provide additional trust perspectives on the Certificate in question.

However, in this emerging landscape of Open Data, a distributed trust model may not be the answer as usage of Open Data depends on whether or not a user trusts the owner or original creator of the Open Data. If that owner or creator is not a reputable source, or if the identity of said owner cannot be verified, then any data coming from that source is untrustworthy. In other words, an instance of a public key must be verified as belonging to a genuine entity, taking into account the threat of the addition of false identities and/or public keys, in order for data gleaned from that source to be considered trustworthy and/or having authenticity and integrity.
# 4 Proposed Solution

This paper proposes a Trustworthy Architecture for Open Data Systems (Fig. 1.) which would serve as a precaution against tampering, enabling users to know when a particular resource is genuine or has been tampered with, thus augmenting the REST framework. As mentioned in a previous section, the SSL/TLS level encryption of request-response messages represents an expenditure of processing resource which is not critical for communicating Open Data. However, measures to protect message integrity and authenticity to ensure trustworthiness are still required.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Trustworthy Architecture for Open Data Systems</figcaption></figure>

## 4.1 Key Components

The architecture proposed hinges on several key components, a Key Generation component, a Public Key File, DNSSEC and a Verifier Module which interfaces with regular REST framework activity as needed.

**Certification Authority vs Public Key Registry.** Effective key management is essential for the smooth operation of cryptographic systems. In regular circumstances, a trusted Certification Authority is responsible for issuing digital certificates and maintaining certificate revocation lists, and is also responsible for the generation of cryptographic key pairs and digital signatures. If a certificate model is to be used then this
would be the normal procedure, however, given that Open Data is of its own essence,
"open", proposing a complex certificate architecture including certificate revocation
should be unnecessary. Moreover, access to confidentiality/privacy services and
mechanisms is not required. It would seem reasonable, then, that each Open Data
publishing entity could maintain its own public key, relevant to verification of data
integrity alone, in an appropriately managed and controlled public key registry (PKR)
file similar to the Diffie-Hellman concept of the "public file", in line with the design
philosophy of DNSSEC.

**Public Key File.** The Public Key File is a central location where public keys associat-
ed with recognized identities may be retrieved. It is proposed that any entity wishing
to publish Open Data generates a cryptographic key pair and submit the public key to
the Open Data Public Key File maintained by this Registry (using the Key Generation
and Signing Module). Users of Open Data will then be able to retrieve the appropriate
public key to verify a signature from this central location.

**Key Generation and Signing Module (KENNEL).** For ease of explanation the Key Generation and Signing module will be referred to as KENNEL. To become an Open Data Publisher, owners of Open Data first need to use KENNEL to generate a cryptographic key pair. This local generation of the key pair eliminates the need to securely transmit the private key over network channels and just exposes the public key, which is what the public key is designed for. The module then submits the generated Public Key to the Registry along with sufficient proof of identity over a secure channel (Fig. 2.). This information will be the basis of a record in the Public Key File. (Fig. 3.)

<figure><img src="image_3.png" /><figcaption>Fig. 2. Open Data Publisher Process using KENNEL</figcaption></figure>
<table><caption>**Table 1.** Process of Fig. 2. Open Data Publisher Process using KENNEL</caption><thead><tr><td>Steps</td><td>Description</td></tr></thead><tbody><tr><td>1</td><td>DNS resolution request</td></tr><tr><td>2</td><td>DNS resolution response</td></tr><tr><td>3</td><td>DNSSEC verification using zone signing key</td></tr><tr><td>4</td><td>KENNEL computes cryptographic key pair, retains private key</td></tr><tr><td>5</td><td>Public key sent with identification documents securely</td></tr><tr><td>6</td><td>Public key bound with identity and stored securely</td></tr><tr><td>7</td><td>KENNEL signs Open Data using private key</td></tr><tr><td>8</td><td>Signed Open Data stored</td></tr></tbody></table>

<figure><img src="image_4.png" /><figcaption>**Fig. 3.** Role of the Open Data Certificate Authority in relation to the Open Data Publisher</figcaption></figure>

The Open Data Publisher is responsible for maintaining the secrecy of its Private Key, and uses this key in conjunction with a cryptographic one-way hashing function to generate a Digital Signature.

**Verifier Module (HOUND).** For ease of reference, the Verifier will be referred to as HOUND. After address resolution with DNSSEC implemented is accomplished, a request for resources reaches the server and the server responds with the appropriate resource which is digitally signed. At the client-side, HOUND reads the server response, extracting signer's identity, retrieves the matching public key from its Public Key Record and verifies the digital signature.

A message digest is recovered by decrypting the digital signature with a valid public key and is compared to a message digest computed at the recipient end of the communication. If both digests are identical, then the response is considered to be authentic and retains its integrity. The operation of the verifier terminates and the content is then passed to the Renderer and is displayed in whichever format is applicable. If the digests are not identical, then the recipient is alerted to the fact that the resource may be fraudulent or has been altered in transit.
**DNSSEC.** The Internet Engineering Task Force has developed RFC3833 [38] the Domain Name System Security Extension specification to resolve various threats to the DNS using public-key cryptography to establish a chain of trust, which in practice each zone has a public key which is deposited in the parent domain for authentication purposes. Therefore, DNSSEC does not make use of digital certificates but rather a public key hierarchical registry.

In order for DNSSEC to be incorporated, the domain host first needs to have DNSSEC enabled on the server-side and the client needs to install a DNSSEC validat-
tor which can read verification information from the server.

## 4.2 Use Case Scenario

**Communication without the proposed architecture.** A request for data to a server follows a standard request-response paradigm. This is an example of a standard HTTP request for a resource without the use of the proposed architecture:

Address Resolution is performed after the initial request is made by the Domain Name System. DNS uses Root or Authoritative Name Servers which are heavily supplemented by DNS caches as a workaround to reduce DNS traffic and increase efficiency. Caching DNS request-response records reduces load on individual servers but is vulnerable to DNS cache poisoning and other interception attacks.

After the 200 OK response, there is no further communication from hosting server and there is no provision for integrity verification. Content is then displayed. It is difficult to place confidence in the data because, as mentioned previously, without any security or integrity-checking mechanism in place, the file is still vulnerable to accidental corruption and interception attacks.

**Communication using the proposed architecture.** The following example illustrates use of the proposed architecture from the perspective of the end user:
<figure><img src="image_5.png" /><figcaption>Fig. 2. Open Data User Case Illustration</figcaption></figure>

<table><caption>Table 2. Process of Fig. 4. Open Data User Case</caption><thead><tr><td>Steps</td><td>Description</td><td>Process</td></tr></thead><tbody><tr><td>1</td><td>DNS Resolution Request</td><td rowspan="3">DNSSEC enabled<br>Address Resolution</td></tr><tr><td>2</td><td>DNS Resolver Response</td></tr><tr><td>3</td><td>Verified using zone public key</td></tr><tr><td>4</td><td>Open Data request</td><td rowspan="3">Open Data Resource<br>Lookup</td></tr><tr><td>5</td><td>Digitally signed Open Data response</td></tr><tr><td>6</td><td>Signature Verifier begins operations</td></tr><tr><td>7</td><td>Request for Public Key</td><td rowspan="3">HOUND Integrity<br>Verification Process</td></tr><tr><td>8</td><td>Public file responds with signer's public key</td></tr><tr><td>9</td><td>Verifier extracts message digest from signature using signer's public key and verifies integrity of Open Data file</td></tr></tbody></table>

In communication with the end-user, the proposed architecture does not change the request-response format of HTTP communication, but rather augments it with the previously mentioned security components.

At this stage, as before, address resolution is performed, incorporating DNSSEC to authenticate the DNS Server and provide defence against cache poisoning or man-in-the-middle attacks. As mentioned in a previous section, a DNSSEC validator is installed on the client-side and validates the incoming content.
After the address resolution is performed successfully, communications proceed as per normal and a response from the hosting server is received. As per RFC2616 [39], a successful request should contain a 2xx or a 3xx status code depending on the HTTP method used. If an error on the client-side is perceived, the server should return a 4xx status code but if an error occurs on the server-side a 5xx status code should be returned to the client.

In this case, the response contains a status code and the actual message which is digitally signed and accompanied by a digital certificate. The verifier module is then called to verify the integrity and authenticity of the received message. At the end of verifier module process, the message or content should be displayed if both the certificate and signature pass verification. The following is pseudocode describing the functioning of the verifier module:

```pascal
#VERIFIER-PSEUDOCODE
GET DownloadedContent
READ Digital_Sign from DownloadedContent
EXTRACT KeyFileNumber from Digital_Sign

GET PublicKeyFile matching KeyFileNumber
RETRIEVE PublicKey from PublicKeyFile
CALL Decrypt_Sign with PublicKey and Digital_Sign
RETURNING decrypt_result
STORE decrypt_result in hash1

CALL hashnet compute with DownloadedContent
RETURNING hash_result
STORE hash_result in hash2

IF hash1 = hash2 THEN
    SHOW message: integrity and authenticity verified
    DISPLAY DownloadedContent
ELSE
    SHOW message: failed integrity check
    TERMINATE
END IF
END
```

This procedure assumes DNSSEC is enabled. However, should DNSSEC not be available, HOUND should use HTTPS as a minimum for integrity to retrieve the appropriate public key from the Public Key File at the Registry for signature verification.

**REST URI Interface with proposed architecture.** Each dataset may contain one or more resource files, which is linked to a particular digital signature file and is associated with the identity and public key of the dataset owner/creator at the Registry.
<figure><img src="image_6.png" /><figcaption>**Table 3.** URI interface</figcaption></figure>

When a GET request is called for a dataset, e.g. GET /datasets/sampleddataset, the server returns a listing of resource files and their URIs. From the information in that list, a GET request may then be sent for an individual resource, e.g. GET /datasets/sampleddataset/resource1, which should retrieve both the resource file and the associated digital signature. All the information is then used in the signature value with the algorithm described in Section 3.2. See Appendix 1 for a previously existing implementation sample of a signature verifier in concrete code.

**4.3 Conclusion and Future Work**

This paper proposes an architecture that uses digital signatures in conjunction with an associated public key file with the main goal to protect the integrity of Open Data communicated over the Web. This is a simplification of current public key certificate structures which use large revocation lists for certificate currency and have demonstrated problems in scalability and “certificate authority” trust.

The key element of this architecture is that it is based on DNSSEC, which is more appropriate to the new world of IPv6. The advantages of this architecture scheme is that it is far more scalable, not another certificate authority hierarchy with massive dispersion of key certificates which has of late become too widespread and unmanageable. With the use of a Public Key File, if the key is compromised; it is a simple matter of the single responsible entity replacing the key pair with a new one and performing the data file signing process.

Responsibility for authenticating Open Data is separated from any other certificate authority that might be used by the publishing entity. Under this proposed architecture, the Open Data environment does not interfere with the internal security schemes that might be employed by the entity. However, this architecture incorporates, when needed, parameters from the entity, e.g. person who authorized publishing as Open Data, at the time that datasets are created/added.
Future work will include the building of a proof-of-concept system using the archi-
tecture in this paper and performing benchmarking against regular systems in con-
junction with penetration testing. An interesting philosophical question which may be
studied in further papers is: what responsibility does an entity, whether private or
public, take on when it makes Open Data available? Further study on the issue of
Open Data and governance requirements must be done.

5 References

1. Fielding, R. T. "Architectural styles and the design of network-based software architectures" Doctoral dissertation, University of California, Irvine (2000).

2. Don Box, Gopal Kavivaya, Andrew Layman, Satish Thatte, Dave Winer, "SOAP: Simple Object Access Protocol", in Internet Draft draft-box-http-soap-01, November (1999).

3. Defining Open Data (2013) Open Knowledge Foundation Blog. http://blog.okfn.org/2013/10/03/defining-open-data/

4. GovHack. http://www.govhack.org/

5. HealthHack. http://www.healthhack.com.au/

6. The Open Definition. http://opendefinition.org/

7. Arzberger, P. W., Schroeder, P., Beaulieu, A., Bowker, G. C., Casey, K., Laaksonen, L., ... & Wouters, P. (2004). Promoting Access to Public Research Data for Scientific, Economic, and Social Development. *Data Science Journal*,3(29), 135-152.

8. Davies, T. (2010). Open data, democracy and public sector reform. *A look at open gov-ernment data use from data.gov.uk*

9. Molloy, J. C. (2011). The open knowledge foundation: open data means better science. *PLoS biology*, *9*(12), e1001195.

10. Samwald M, Jentzsch A, Bouton C, Stie Kallesøe C, Willighagen E, et al. (2011) Linked open drug data for pharmaceutical research and development. J Cheminform 3: 19. doi:10.1186/1758-2946-3-19.

11. Zuiderwijk, A. M. G., Jeffery, K. G., & Janssen, M. F. W. H. A. (2012). The potential of metadata for linked open data and its value for users and publishers. *JeDEM-e-Journal of e-Democracy and Open Government, 4* (2) 2012.

12. Janssen, M., Charalabidis, Y., & Zuiderwijk, A. (2012). Benefits, adoption barriers and myths of open data and open government. *Information Systems Management, 29*(4), 258-268.

13. Kassen, M. (2013). A promising phenomenon of open data: A case study of the Chicago open data project. *Government Information Quarterly*, *30*(4), 508-513.

14. Zuiderwijk, A., & Janssen, M. (2014). Open data policies, their implementation and impact: A framework for comparison. *Government Information Quarterly*,31(1), 17-29.

15. Jaakkola, H., Makinen, T., & Etelaaho, A. (2014). Open data: opportunities and chal-lenges. Paper presented at the Proceedings of the 15th International Conference on Computer Systems and Technologies, Ruse, Bulgaria. D. M. Strong, Y. W. Lee, and R. Y. Wang. (1997) 10 potholes in the road to information quality. IEEE Computer, 30(8):38–46, 1997.

16. Mazon, J. N., Zubcoff, J. J., Garrig, I., Espinosa, R., . . . guez. (2012). Open business intel-ligence: on the importance of data quality awareness in user-friendly data mining. Paper presented at the Proceedings of the 2012 Joint EDBT/ICDT Workshops, Berlin, Germany.

17. Telikicherla, K. C., & Choppella, V. (2014). Enabling the development of safer mashups for open data. Paper presented at the Proceedings of the 1st International Workshop on In-
clusive Web Programming - Programming on the Web with Open Data for Societal Appli-
cations, Hyderabad, India.

18. Eckert, K., Ritze, D., Baierer, K., & Bizer, C. (2014). RESTful open workflows for data provenance and reuse. Paper presented at the Proceedings of the companion publication of the 23rd international conference on World wide web companion, Seoul, Korea.

19. CKAN instances around the world. http://ckan.org/instances/

20. Socrata Open Data Portal. https://opendata.socrata.com/

21. CKAN Multisite Draft Proposal. https://usopendata.org/2014/12/08/ckan-multisite/

22. Socrata Open Data API. http://www.socrata.com/industries/open-data-state-local-government/

23. Comerford, C., & Soderling, P. "Why REST security doesn't exist" . http://www.computerworld.com/s/article/9161699/Why_REST_securityDoesn_t_exist

24. OASIS, "Web Services Security: SOAP Message Security 1.1," (2006). http://www.oasis-open.org/committees/wss

25. Forsberg, D. "RESTful Security." In Web 2.0 Security & Privacy 2009 in conjunction with 2009 IEEE Symposium on Security and Privacy.(2009)

26. Dunlu Peng; Chen Li; Huan Huo, "An extended UsernameToken-based approach for REST-style Web Service Security Authentication," In Computer Science and Information Technology, 2009. ICCSIT 2009. 2nd IEEE International Conference on, vol., no., pp.582,586, 8-11 Aug. 2009 doi: 10.1109/ICCSIT.2009.5234805

27. Serme, G.; de Oliveira, A.S.; Massiera, J.; Roudier, Y., "Enabling Message Security for RESTful Services," In Web Services (ICWS), 2012 IEEE 19th International Conference on, vol., no., pp.114,121, 24-29 June 2012 doi: 10.1109/ICWS.2012.94

28. Lee, H., & Mehta, M. R. "Defense against REST-based web service attacks for enterprise systems." In Communications of the IIMA, 13(1), 57-68. (2013). http://search.proquest.com/docview/1518604854?accountid=13380

29. De Backere, E.; Hanssens, B.; Heynssens, R.; Houthooft, R.; Zuliani, A.; Verstichel, S.; Dhoedt, B.; De Turck, F., (2014) "Design of a security mechanism for RESTful Web Service communication through mobile clients," Network Operations and Management Symposium (NOMS), 2014 IEEE, vol., no., pp.1,6, 5-9 May 2014 doi: 10.1109/NOMS.2014.6838308

30. Diffie, W., and Hellman, M.E. (1976) "New Directions in Cryptography," in IEEE Trans. On Info. Theory, Vol. IT-22, Nov. 1976, pp. 644-654

31. Kohnfelder, L.M. (1978) "Towards a practical public-key cryptosystem." PhD diss., Massachusetts Institute of Technology (1978).

32. Clarke, Roger. "Conventional public key infrastructure: An artefact ill-fitted to the needs of the information society." In Proceedings of the 9th European Conference on Information Systems. (2001)

33. Rivest, Ronald L. "Can we eliminate certificate revocation lists?" In Financial Cryptography, pp. 178-183. Springer Berlin Heidelberg, (1998).

34. McDaniel, Patrick, and Aviel Rubin. "A response to "Can we eliminate certificate revocation lists?"." In Financial Cryptography, pp. 245-258. Springer Berlin Heidelberg, (2001).

35. Wendlandt, D., Andersen, D. G., Perrig, A. (2008). Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing. Proceedings of the USENIX 2008 Annual Technical Conference.

36. Marlinspike, M. (2011) SSL and the Future of Authenticity. BlackHat USA.

37. RFC3833. https://tools.ietf.org/html/rfc3833

38. RFC2616. https://www.ietf.org/rfc/rfc2616.txt