{"id":11373,"date":"2026-06-29T10:16:11","date_gmt":"2026-06-29T10:16:11","guid":{"rendered":"https:\/\/wetransform.to\/?post_type=news-and-events&p=11373"},"modified":"2026-06-29T10:16:11","modified_gmt":"2026-06-29T10:16:11","slug":"sensitive-location-data-full-potential","status":"publish","type":"news-and-events","link":"https:\/\/wetransform.to\/de\/news-and-events\/sensitive-location-data-full-potential\/","title":{"rendered":"Using Sensitive Location Data to its Full Potential \u2013 a Pragmatic, Full-Spectrum Approach"},"content":{"rendered":"

Note:<\/em><\/strong> Should you prefer reading this article as a PDF, it is available for download here.<\/a><\/p>\n

Table of contents<\/h4>\n
    \n
  1. From Basic Authentication to Data Spaces<\/a><\/li>\n
  2. The State Today: Standards and Islands<\/a>\n
      \n
    1. Access Control in Modern GIS Systems<\/a>\n
        \n
      1. Authorization: Role-Based Access Control (RBAC)<\/a><\/li>\n
      2. The Problems<\/a><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n<\/li>\n
      3. The Future of Access and Usage Control: Data Space Protocols<\/a>\n
          \n
        1. An Intro to Data Spaces<\/a><\/li>\n
        2. Location Data Policies for the Data Plane<\/a><\/li>\n
        3. Basic Location Data Policy types<\/a>\n
            \n
          1. LDP1: Access within a spatially well-defined area<\/a><\/li>\n
          2. LDP2: Share location, but remove or degrade sensitive attributes<\/a><\/li>\n
          3. LDP3: Share attributes, but remove location<\/a><\/li>\n
          4. LDP4: Share attributes, but pseudonymise location<\/a><\/li>\n
          5. LDP5: Reduce positional accuracy of location<\/a><\/li>\n
          6. LDP6: Aggregate data into a larger spatial unit of a defined minimum size<\/a><\/li>\n<\/ol>\n<\/li>\n
          7. Expressing Location Data Policies in ODRL<\/a>\n
              \n
            1. Example 1<\/a><\/li>\n
            2. Example 2<\/a><\/li>\n<\/ol>\n<\/li>\n
            3. Implementing the policies: The Location Privacy Proxy<\/a><\/li>\n<\/ol>\n<\/li>\n
            4. Making all that easy<\/a>\n
                \n
              1. Becoming a Participant<\/a><\/li>\n
              2. Sharing an asset as a data provider<\/a><\/li>\n
              3. Using the shared asset<\/a><\/li>\n<\/ol>\n<\/li>\n
              4. Conclusions<\/a>\n
                  \n
                1. Want to try any of this out?<\/a><\/li>\n<\/ol>\n<\/li>\n
                2. Acknowledgements<\/a><\/li>\n<\/ol>\n

                  From Basic Authentication to Data Spaces <\/a><\/h2>\n

                  In the past years, it has become increasing clear that not all location data can become open data. Data on critical infrastructure, protected species, personal information, proprietary business data and many other categories will remain access and usage controlled.<\/p>\n

                  There have been approaches to try and standardise methods for location specific access control, such as GeoXACML, but none of these gained substantial adoption. Today, security for location data services uses a wide range of proprietary protocols and architectures. <\/p>\n

                  The main challenges remain on the client side. Many portals and desktop GIS have very limited mechanisms to authenticate users \u2013 some don\u2019t allow for any form of authentication; some only allow HTTP Basic Authentication with Username and Password. Adding a WMS or WFS that needs an authentication bearer token delivered via a header is often not possible.<\/p>\n

                  Consequently, there is no one size fits all approach to different types of data and security requirements. We have thus in the past years worked to implement a spectrum of security measures that enable providers to provide data securely to authenticated and authorised users.<\/p>\n

                  This spectrum goes from simple Username\/Password mechanisms to full blown high-security processes, built on modern standards: The Data Space Protocol, Verifiable Credentials, eIDAS and more.<\/p>\n

                  We firmly believe that the GIS world should spent effort to rapidly implement such modern standards across the board. This will enable all stakeholders to securely work with highly sensitive data and thus will increase the value of such data massively.<\/p>\n

                  Users of the hale\u00bbconnect infrastructure can thus now use it to also deploy highly sensitive data sets and pick the right technical and organisational measures for their desired level of security.<\/p>\n

                  But first, let\u2019s have a detailed look at the current state of controlled access to sensitive location data.<\/p>\n

                  The State Today: Standards and Islands <\/a><\/h2>\n

                  Access Control in Modern GIS Systems <\/a><\/h3>\n

                  Access control in GIS platforms has evolved from application-specific user accounts and dataset permissions toward standards-based identity management integrated with enterprise IT infrastructure. Today, most WebGIS, desktop GIS, server platforms, and cloud-native offerings support a combination of standardised authentication protocols and role-based authorization models.<\/p>\n

                  \"A

                  Figure 1: A spectrum of authentication methods and frameworks. Today's GIS applications range from options 1 to 10.<\/p><\/div>\n

                  \n

                   <\/p>\n

                  OAuth 2.0 and OpenID Connect (OIDC) have become the dominant mechanisms for authenticating users in web-based GIS applications. ArcGIS Online and ArcGIS Enterprise natively support OAuth 2.0 for web, desktop, and mobile applications, and ArcGIS Enterprise also supports OIDC integration with external identity providers such as Microsoft Entra ID, Okta, and Google. FOSS desktop GIS tools such as QGIS also provide built-in OAuth2 authentication capabilities, allowing secure access to protected resources.<\/p>\n

                  SAML 2.0 also remains relatively well-supported, especially in large organizations with established identity infrastructures. SAML is mature and has widespread adoption in government and enterprise environments, but is more complex and has an architecture that is less suitable for API-driven applications.
                  \nThe main advantage of OAuth, OIDC and SAML is that GIS systems can leverage existing enterprise identity providers, enabling single sign-on (SSO), multi-factor authentication, centralized user lifecycle management, and reduced password proliferation. <\/p>\n

                  However, OAuth and OIDC primarily solve authentication and delegated authorization; they do not by themselves define or enforce fine-grained access policies. Their implementation can also be complex, particularly when integrating legacy GIS components or desktop workflows. In our experience, legacy WebGIS systems and Desktop apps are the weakest link in the implementation of data access policies.<\/p>\n

                  Authorization: Role-Based Access Control (RBAC) <\/a><\/h4>\n

                  For authorization, Role-Based Access Control (RBAC) is by far the most common model across GIS platforms. Many products organize permissions around users, groups, and predefined or custom roles that control access to services, datasets, editing capabilities, administrative functions, and content sharing. Such approaches exist in ArcGIS, hale\u00bbconnect, GeoServer, cloud GIS offerings, and other spatial data infrastructure solutions, though there is no widely adopted standard for defining RBAC. The following listing gives an example RBAC definition for hale\u00bbconnect:<\/a><\/p>\n

                  {\n  "user": {\n    "extends": "anonymous",\n    "label": {\n      "en": "Registered user"\n    },\n    "resources": {\n      "User": {\n        "read": true,\n        "edit": ["self"]\n      },\n      "Organisation": {\n        "read": true\n      }\n    }\n  },\n  "dataManager": {\n    "extends": "user",\n    "label": {\n      "en": "Data manager"\n    },\n    "resources": {\n      "Bucket": {\n        "create": ["organisation"],\n        "read": ["organisation"],\n        "edit": ["organisation"],\n        "delete": ["organisation"]\n      },\n      "Theme": {\n        "read": ["organisation", "parentOrg"]\n      },\n      "Schema": {\n        "read": ["organisation", "parentOrg"]\n      },\n      "TransformationProject": {\n        "read": ["organisation", "parentOrg"]\n      }\n    }\n  }\n}\n<\/code><\/pre>\n
                  Listing 1: Configuration of RBAC in hale\u00bbconnect<\/p>\n
                  \n
                    <\/p>\n
                  RBAC provides a practical balance between security and manageability. Permissions can be assigned to roles such as Viewer, Editor, Publisher, or Administrator and inherited by large groups of users. This greatly simplifies administration in organizations with hundreds or thousands of users. The drawback is that RBAC can become difficult to manage when access requirements become highly granular, leading to "role explosion" where many specialized roles have to be created.<\/p>\n
                  Some GIS platforms supplement RBAC with dataset-level permissions, group-based sharing, and service-level security. In some cloud environments, GIS systems also rely on underlying cloud IAM frameworks (AWS IAM, Azure RBAC, Google Cloud IAM) to enforce multi-level access controls.<\/p>\n
                  The emerging trend is toward federated identity using OAuth\/OIDC combined with RBAC for operational permissions. While attribute-based and policy-based access control models exist and are gaining interest for cross-organizational data sharing, RBAC remains the dominant authorization mechanism in production GIS deployments today due to its broad vendor support and relative simplicity.<\/p>\n
                  The Problems <\/a><\/h4>\n
                  While a lot of solutions exist for authentication and access control, there are still unresolved problems:<\/p>\n
                    \n
                  1. While there are usually standards-based organisation-wide solutions for Authentication available that GIS and SDI applications can plug in to, there are no interoperable, widely deployed authentication infrastructures that work across a wide range of actors available. This creates authentication islands,<\/strong> with the tokens only being accepted inside a specific organisation\u2019s systems. This will hopefully change with wider adoption of eIDs, e.g. through eIDAS and the EU Business Wallets.<\/li>\n
                  2. Most RBAC approaches only work within a single homogeneous deployment, where all components are built on the same technology. Claims or credentials rarely use compatible, standardised schemas, which again creates single-system or single-organisation authorisation islands.<\/strong> This problem could be resolved by using standardised schemas for Verifiable Credentials.<\/li>\n
                  3. Support for token-based authorisation (Levels 5+ in Figure 1<\/a>) is still patchy in the installed base of Desktop and WebGIS systems<\/strong> out there, and there are sometimes limitations on token length, security of token storage (we even found one system which stored received tokens in clear text in log files\u2026), or simply user-unfriendly processes of obtaining and updating tokens. This sometimes requires fallback solutions, such as using tokens or even token hashes as passwords.<\/li>\n<\/ol>\n
                    The Future of Access and Usage Control: Data Space Protocols <\/a><\/h2>\n
                    An Intro to Data Spaces <\/a><\/h3>\n
                    As outlined, modern GIS systems increasingly support enterprise-grade authentication and authorization mechanisms such as OAuth, OpenID Connect, and Role-Based Access Control (RBAC). However, as used today, these approaches are no good match for an open, distributed data infrastructure. Also, once data has been shared, the data provider often loses visibility and control over how it is subsequently used.<\/p>\n
                    Data Spaces, as defined by the International Data Spaces Association (IDSA) introduce a standardised technical and organisational framework for trusted data access and usage between independent organisations. Rather than merely granting access to datasets, IDSA-compliant Data Spaces enable participants to define and enforce usage policies that govern what recipients may do with the data after access has been granted. Examples include restrictions on redistribution, limitations to specific purposes, requirements for attribution, or obligations to delete data after a defined period. Of course, technical means can only be enforced as long as the data is stored and processed \u201cinside\u201d the data space \u2013 once the data is outside the controlled environment, the enforcement of policies lies in the legal domain.<\/p>\n
                    This enables a standardised way to express technical and organisational measures to ensure data and IT infrastructure security that works across organisational borders. Especially in the context of implementing IT solutions for the public sector, this would enable far better, more reuseable and more efficient IT security concepts and their implementation.<\/p>\n
                    For GIS and SDI environments, Data Spaces can be understood as a standardised access and usage control layer. <\/p>\n
                    Data Spaces provide interoperable mechanisms for expressing, negotiating, and enforcing data-sharing agreements across organisational boundaries. This is particularly relevant for geospatial ecosystems involving public authorities, infrastructure operators, research institutions, and private-sector actors, where sensitive spatial data must be shared securely while maintaining control over its permitted use.<\/p>\n
                    Data Spaces have two layers: <\/p>\n
                      \n
                    1. a control plane on which conditions for data exchange are negotiated <\/li>\n
                    2. and a data plane on which the actual transfer of data takes place.<\/li>\n<\/ol>\n
                      \"Control
                      Figure 2: Control Plane and Data Planes in a Data Space Architecture<\/p><\/div> Source: Making the Dataspace Protocol an international standard<\/a>, International Data Spaces Association (IDSA)<\/a><\/p>\n
                      \n
                        <\/p>\n
                      The core component of such a data space is the so-called Connector. The connector enables data discovery using metadata, it authorizes previously authenticated participants, negotiates usage agreements, and enforces data usage policies. <\/p>\n
                      Most projects and operational data spaces use connectors built on the Eclipse Data Space Components (EDC) \u2013 as does wetransform. In the following sections, we will explain in greater detail how we designed and implemented a Connector aimed at optimally supporting location data in data spaces through specific policies and their implementation.<\/p>\n
                      Location Data Policies for the Data Plane <\/a><\/h3>\n
                      The standard EDC implements the Data Spaces Protocol for contract negotiation. It has good support for general access policies, such as requiring an authenticated user who can present certain credentials. It comes with very little support for more fine-grained policies tailored to domain-specific protocols \u2013 that is typically where domain-specific extensions are developed. These domain-specific extensions are mostly built on top of the EDC and use custom mechanisms.<\/p>\n
                      To build the Forest Data Space and to integrate with SAGE, our ambition was to use an extension pattern that could become widely adopted. The EDC has a mechanism that allows to define the scope in which a policy is to be applied. Such scopes are, for example, during contract negotiation (contract.negotiation<\/code>) and during data transfer (transfer.process<\/code>). The policies we propose here mostly come into play during transfer, so the contract negotiation has already taken place \u2013 the consuming participant principally has presented sufficient authorisation to be able to proceed.<\/p>\n
                      Basic Location Data Policy types <\/a><\/h3>\n
                      To design our EDC extension, we started by analysing a wide range of Data Sensitivity Analyses (\u201cSchutzbedarfsanalysen\u201d) across several use cases ranging from forest inventory, wind park planning to contamination cadastres. On this basis, we found that the following set of location data-specific policies (LDPs) would address typical requirements when handling sensitive data.<\/p>\n
                      LDP1: Access within a spatially well-defined area <\/a><\/h4>\n
                      Users acting on behalf of a participant may only access data from within the areas belonging to the participant.<\/p>\n
                      Example: Data retrieval is limited to the stands belonging to a forest owner.<\/em><\/p>\n
                      LDP2: Share location, but remove or degrade sensitive attributes <\/a><\/h4>\n
                      Here, sensitivity comes from the combination of an attribute with a location. The location itself is not problematic, not is the attribute by itself problematic.<\/p>\n
                      Example: The combination of timber volume and the true location is sensitive, so remove the attribute.<\/em><\/p>\n
                      LDP3: Share attributes, but remove location <\/a><\/h4>\n
                      The location by itself is sensitive, either due to the context of the data or to the possibility of constructing sensitive information from it, but the attributes can be used by others, e.g. for statistical analyses.<\/p>\n
                      Example: Data of sightings of rare species<\/em><\/p>\n
                      LDP4: Share attributes, but pseudonymise location <\/a><\/h4>\n
                      Keep the object representative and useable as if it was the true and complete object, but use a robust method of obscuring the true location such as changing form (beyond adding noise) and location or creating a synthetic geometry that retains topology.<\/p>\n
                      Example: Synthetic Orthoimagery annotated with tree species labels that cannot be registered back to a true location but was made from true images and locations.<\/em><\/p>\n
                      LDP5: Reduce positional accuracy of location <\/a><\/h4>\n
                      Hide sensitive information by reducing resolution or scale, or by adding noise to a geometry.<\/p>\n
                      Example: Reduce resolution of orthoimages from 10cm\/pixel to 50cm\/Pixel.<\/em><\/p>\n
                      LDP6: Aggregate data into a larger spatial unit of a defined minimum size <\/a><\/h4>\n
                      Aggregate attributes from multiple objects, either those within some sufficiently large extent, or from a sufficiently larger number of objects, into single objects.<\/p>\n
                      Example: Population statistics aggregated into a standard statistical grid, selected in such a way that k-anonymity is guaranteed.<\/em><\/p>\n
                      \"Progressively
                      Figure 3: Progressively smaller units of aggregation<\/p><\/div>\n
                      \n
                        <\/p>\n
                      Expressing Location Data Policies in ODRL <\/a><\/h3>\n
                      In this section, we will use two examples to show how such policies can be encoded in ODRL, the standardised policy language that the EDC uses.<\/p>\n
                      Example 1<\/strong> encodes LDP1 (Access within a spatially well-defined area) and describes how a forest owner can be limited to retrieving data only from their forest stands.<\/p>\n
                      Example 2<\/strong> encodes LDP6 (Aggregate data) and describes how the individual object values can be obscured by aggregation.<\/p>\n
                      For all policies, we evaluated multiple methods of extending both the EDC and ODRL itself and decided to refrain from implementing special operators such as lp:within<\/code>.<\/p>\n
                      Example 1 <\/a><\/h4>\n
                      Contract Negotiation Scope<\/em><\/strong><\/p>\n
                      For the contract negotiation phase in example 1 to succeed, the forest owner participant needs to present a valid participant geofence credential. The participant geofence defines the area from which any user acting on behalf of the participant may receive data for specific types of data.<\/p>\n
                      The participant geofence is stored as two verifiable credentials:<\/p>\n