From f9ffac46bcd5c323d7d415ad8998b90e244b6136 Mon Sep 17 00:00:00 2001
From: RiccardoAlbertoni
The DCAT vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents via qualified relations,
and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with cataloged Resources and Distributions.
These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[!ODRL-VOCAB]]. Implementations that produce, maintain, publish or
- consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.
+ consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level and transport level.
DCAT borrows the property DCAT borrows the property The development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored.
DCAT Profiles
Security and Privacy
+ Security and Privacy Considerations
spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. It is worth noting that the associated checksum will not provide the expected security protections if the integrity or authenticity of the DCAT metadata is also not guaranteed. Integrity and authenticity of DCAT metadata depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level. For example, they should ensure the integrity and authenticity of their API and download endpoints and make DCAT metadata files downloadable from authoritative origins. DCAT does not prescribe the manner of generating the checksum. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied. Development of a canonical method for the generation of a checksum overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored.
+spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied.
+It is worth noting that the associated checksum will not provide the expected security protections if the integrity or authenticity of the DCAT metadata is not also guaranteed. Integrity and authenticity of DCAT metadata depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints and make DCAT metadata files downloadable from authoritative HTTPS origins. Security and Privacy Considerations
These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[!ODRL-VOCAB]]. Implementations that produce, maintain, publish or
consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level and transport level.
DCAT borrows the property spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied.
+
DCAT borrows the property spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum, and different checksum algorithm might deployed. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied, in particular, indicating the adopted checksum algorithm.
It is worth noting that the associated checksum will not provide the expected security protections if the integrity or authenticity of the DCAT metadata is not also guaranteed. Integrity and authenticity of DCAT metadata depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints and make DCAT metadata files downloadable from authoritative HTTPS origins.
The development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored. +
Also, the development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored.
DCAT borrows the property spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum, and different checksum algorithm might deployed. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied, in particular, indicating the adopted checksum algorithm.
+
DCAT borrows the property spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum, and different checksum algorithm might be deployed. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied, in particular, indicating the adopted checksum algorithm.
It is worth noting that the associated checksum will not provide the expected security protections if the integrity or authenticity of the DCAT metadata is not also guaranteed. Integrity and authenticity of DCAT metadata depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints and make DCAT metadata files downloadable from authoritative HTTPS origins.
Also, the development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored. +
Checksums are applied on DCAT distribution, but they could also be explored at the level of the whole DCAT metadata as a further way to ensure the integrity and authenticity of DCAT metadata when this is not achieved differently. The development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored.
- The DCAT vocabulary supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents via qualified relations, - and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with cataloged Resources and Distributions. - These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[!ODRL-VOCAB]]. Implementations that produce, maintain, publish or - consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level and transport level. + The DCAT vocabulary supports the datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers and other parties or agents via qualified relations. + Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level and transport level.
-DCAT borrows the property spdx:checksum
from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. DCAT does not prescribe the manner of generating the checksum, and different checksum algorithm might be deployed. Publishers should provide the necessary detail for the user to reliably calculate the provided hash from the files supplied, in particular, indicating the adopted checksum algorithm.
-It is worth noting that the associated checksum will not provide the expected security protections if the integrity or authenticity of the DCAT metadata is not also guaranteed. Integrity and authenticity of DCAT metadata depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints and make DCAT metadata files downloadable from authoritative HTTPS origins.
Checksums are applied on DCAT distribution, but they could also be explored at the level of the whole DCAT metadata as a further way to ensure the integrity and authenticity of DCAT metadata when this is not achieved differently. The development of a canonical method for the generation of a checksum of DCAT metadata overlaps with the scope of the RDF Dataset Canonicalization and Hash Working Group, on which DCAT can build in the future. Moreover, the use of Verifiable Credentials Data Integrity [[?VC-DATA-INTEGRITY]] can be explored. +
Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification.
+ DCAT borrows the spdx:Checksum
class from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. Publishers may provide a checksum value (a hash) and the algorithm used to generate the hash for each resource in the distribution. A checksum must, however, be provided via a route that is separate from the data it sums. It may be included in metadata that is provided with the data (e.g., a tarfile that includes a file for the distribution and a file for the metadata that includes a checksum for the distribution file), but if so the checksum, or a checksum for the metadata, must also be provided separately to foil an attacker who would manipulate the checksum along with the data. A checksum provided in DCAT metadata will not provide the expected assurances if the integrity and authenticity of the metadata are not also guaranteed.
+
Integrity and authenticity of DCAT data ultimately depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints, make DCAT data and metadata files downloadable from authoritative HTTPS origins, and provide any checksums via a separate channel from the data they represent.
The DCAT vocabulary supports the datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers and other parties or agents via qualified relations. - Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level and transport level. + Implementers who produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed. Sensitive data and metadata must be stored securely and made available only to authorized parties, in accordance with the legal and functional requirements of the type of data involved. Detailing how to secure web content and authenticate users is beyond the scope of DCAT.
Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification.
DCAT borrows the
- The DCAT vocabulary supports the datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers and other parties or agents via qualified relations.
+ The DCAT vocabulary supports datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers and other parties or agents via qualified relations.
Implementers who produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed. Sensitive data and metadata must be stored securely and made available only to authorized parties, in accordance with the legal and functional requirements of the type of data involved. Detailing how to secure web content and authenticate users is beyond the scope of DCAT.
Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification.
From 466aa4543376b84088c79a34ce5698d67d6fba07 Mon Sep 17 00:00:00 2001
From: RiccardoAlbertoni
- The DCAT vocabulary supports datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers and other parties or agents via qualified relations.
+ The DCAT vocabulary supports datasets that may contain personal or private information. In addition, the metadata expressed with DCAT may itself contain personal or private information, such as resource creators, publishers, and other parties or agents described via qualified relations.
Implementers who produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed. Sensitive data and metadata must be stored securely and made available only to authorized parties, in accordance with the legal and functional requirements of the type of data involved. Detailing how to secure web content and authenticate users is beyond the scope of DCAT.
Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification.
From c45f14d555b76df13d6a0095d6aa1bd7564ae4f1 Mon Sep 17 00:00:00 2001
From: Riccardo Albertoni Some datasets require assurances of integrity and authenticity (for example, data about software vulnerabilities). For these, checksums can serve as a type of verification.
DCAT borrows the Integrity and authenticity of DCAT data ultimately depend on the trustworthiness of the source. DCAT providers should address integrity and authenticity at the application level and transport level. For example, they should ensure the integrity and authenticity of their API and download endpoints, make DCAT data and metadata files downloadable from authoritative HTTPS origins, and provide any checksums via a separate channel from the data they represent.
spdx:Checksum
class from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. Publishers may provide a checksum value (a hash) and the algorithm used to generate the hash for each resource in the distribution. A checksum must, however, be provided via a route that is separate from the data it sums. It may be included in metadata that is provided with the data (e.g., a tarfile that includes a file for the distribution and a file for the metadata that includes a checksum for the distribution file), but if so the checksum, or a checksum for the metadata, must also be provided separately to foil an attacker who would manipulate the checksum along with the data. A checksum provided in DCAT metadata will not provide the expected assurances if the integrity and authenticity of the metadata are not also guaranteed.
From c78c75dfe4a76d6b6936b88ef444aae790ffb2fb Mon Sep 17 00:00:00 2001
From: Riccardo Albertoni DCAT Profiles
Security and Privacy Considerations
DCAT Profiles
Security and Privacy Considerations
Security and Privacy Considerations
spdx:Checksum
class from [[!SPDX]] to ensure the integrity and authenticity of DCAT distributions. Publishers may provide a checksum value (a hash) and the algorithm used to generate the hash for each resource in the distribution. A checksum must, however, be provided via a route that is separate from the data it sums. It may be included in metadata that is provided with the data (e.g., a tarfile that includes a file for the distribution and a file for the metadata that includes a checksum for the distribution file), but if so the checksum, or a checksum for the metadata, must also be provided separately to foil an attacker who would manipulate the checksum along with the data. A checksum provided in DCAT metadata will not provide the expected assurances if the integrity and authenticity of the metadata are not also guaranteed.
-