text:
\section*{Acknowledgment}
     The work behind this paper was partially conducted within the project DaSKITA, supported under grant no. 28V2307A19 by funds of the Federal  Ministry of Justice and Consumer Protection (BMJV) based on a decision of the Parliament of the Federal Republic of Germany via the Federal Office for Agriculture and Food (BLE) under the innovation support program.

\bibliographystyle{IEEEtran}

\section{Requirements \& General Approach}\label{sec:approach}

From the above givens and %
their interplay in current, real world information systems engineering, we can distill a couple of requirements which shall be laid out in brief before delineating our general approach to address them. %

\subsection{Legal Transparency Obligations}\label{sec:legal_req}

As sketched in~sec.~\ref{sec:background:sub:dp_principle}, the GDPR codifies numerous transparency obligations throughout Art. 13--15. In addition, overlapping requirements concerning the maintenance of a \emph{record of processing activities} are introduced in Art. 30.
These articles therefore define which information must be provided to the data subject.

Since we aim at collecting transparency information inside distributed systems comprised of numerous microservices, we differentiate between two \emph{categories} of transparency information here. %
First, we relate comparably static information regarding the whole system as well as the company-wide implementation of GDPR requirements -- such as contact information %
of a data protection officer -- to the \emph{system (SYS)} category. %
Complementarily,
we introduce the \emph{service (SVC)} category, covering %
all information regarding the collection of data or the processing thereof by a particular service's implementation -- such as the disclosure of personal data to specific recipients. %
Only this information is subject to the continuous change introduced by agile DevOps practices and needs to be determined dynamically by the technical mechanism to be developed while system-wide transparency information can be maintained separately (see sec.~\ref{sec:thub}).

An in-depth analysis of GDPR articles regarding transparency and said records-keeping obligations reveals
recurring patterns of information requirements. %
For instance, all examined articles (Art. 13-15 and 30) require the specification of processing purpose(s), a declaration regarding the recipients of personal data, or storage periods. %
Other aspects such as covered data categories or the origins of held data only apply in certain settings. All of these are, however, %
indispensable for legally sufficient provision of transparency information and must, therefore, be captured on a per-service level. Based on our analysis, a summary of required information %
is provided in table~\ref{tab:information-categories}.

\input{sections/table-reqs}

\subsection{Technical Requirements}\label{sec:tech_req}

While privacy (and, thus, transparency) is typically considered a non-functional requirement from the perspective of modern information systems engineering, we herein formulate our requirements from the perspective of the transparency mechanism to be developed. Like for other endeavors of privacy engineering aimed at practically applicable, and re-usable technical mechanisms (e.g. \cite{pallas-ea-2020-al-pbac,gruenewald2021}), requirements regarding the actual provision of transparency information in RESTful architectures are thus referred to as ``functional'' (FR) ones herein while those referring to other factors that influence, for instance, practical applicability are categorized as ``non-functional'' (NFR). %

On the functional side, the technical mechanism to be proposed must, first and foremost, be capable of expressing all legally required information (Req. 1, FR). The expressiveness of our mechanism is therefore explicitly aligned to the requirements from the GDPR identified above. %
In addition, we explicitly aim for a mechanism that smoothly integrates into above-mentioned, agile DevOps practices. In line with these, it is the developer of a given service who knows best what personal data the service collects, for which purposes, etc. Consequently, we strive for a service-focused approach (Req. 2, FR) that allows to harness ''service-local knowledge'' from developers in a bottom-up fashion and to integrate these into a comprehensive representation later on. For the latter, in turn, it must be possible to dynamically integrate and aggegate respective transparency information across hierarchies of decoupled and complexly intertwined services into an overall view (Req. 3, FR). %
In the light of the dynamically changing service implementations and interdependencies that characterize agile DevOps practices, this needs to be possible in an automated fashion.

Non-functional requirements, in turn, primarily regard the well-known challenge of ensuring practical applicability and fieldability of PETs ~\cite{doTheyMatch, kaminski2020recent}. In line with other work directed at comparable goals (esp. \cite{pallas-ea-2020-al-pbac, gruenewald2021}), we can at least identify the following ones: To foster practical adoption, %
the %
mechanism to be developed must integrate with well-established development practices and toolchains as coherently %
as possible (Req. 4, NFR). For similar reasons, the mechanism must be developer-friendly and raise low implementation and integration overheads (Req. 5, NFR). While developers will avoid %
hard-to-integrate technical mechanisms, %
easily usable ones will face lower refusal and may even be used out of developers' intrinsic motivation or mere curiosity \cite{pallas-ea-2020-al-pbac}.\footnote{In addition, lowering implementation overhead also works towards making the adoption of a technical mechanism legally mandatory under the GDPRs ``Privacy / Data Protection by Design'' concept \cite{edpbPbD}.} %
Finally, the required functionality should be provided in the form of re-usable artifacts (Req. 6, NFR) that encapsulate required functionality as far as possible, foster broad and consistent adoption, and ease the integration into real-world information systems \cite{pallas-ea-2020-al-pbac, gruenewald2021}. %

\subsection{Approach \& Sample Application}\label{sec:approach_approach}\label{ssec:running-example}

For fulfilling these requirements, we propose a novel approach that hooks into one of the core mechanisms and associated practices of agile, service-oriented information systems engineering: the structured description of RESTful service interfaces according to the OpenAPI standard. Such service descriptions cover a service's interface as well as it's behavior at a level of detail that allows different teams to use each other's services merely by \enquote{programming to an interface}  \cite{gamma1994design}. Our approach builds upon these OpenAPI-based capabilities for self-description and extends them to transparency-related properties of single services. This allows to grasp superior knowledge from a service's developers in a decentralized fashion (see Req. 2). Developers, in turn, do not have to adapt to paradigmatically new tools or techniques but rather stay within their well-known practice of OpenAPI-based service descriptions (see Reqs. 4 and 5).

\begin{figure}[!t]
	\begin{center}
		\includegraphics[width=0.45\textwidth]{img/application_final.pdf}
		\caption[Overview of architectural components]
		{
		    Architectural overview of components, for which each interface is equipped with an OpenAPI specification. The red arrow, as an example, indicates the CI pipeline, which registers each version of the spec within the \textit{TransparencyHub}
		    (see sec.~\ref{sec:thub}). Third parties' service specifications can be registered manually (yellow arrow).
		    %
		}
		\label{fig:example-architecture}
	\end{center}
	\vspace{-0.5cm}
\end{figure}

Utilizing OpenAPI descriptions for the purpose of transparency does, however, require to introduce a respective OpenAPI extension and accompanying specifications particularly tailored to the GDPR's requirements (Req. 1). This %
will be done in section~\ref{sec:vocab_apispec}. Operationalizing respective descriptions in practice, in turn, requires further technical mechanisms for consolidating them into an aggregated and always up-to-date view comprising multiple services (Req. 3) and for coherently integrating respective tasks (such as notifications in case of major changes) into broadly employed CI/CD pipelines (see again Req. 4). Respective tools building upon our fundamental OpenAPI extension are briefly presented in section~\ref{sec:thub}. %

For illustrating our considerations, we assume %
a fitness application that is developed in an agile fashion, employing a multitude of paradigmatically different state of the art technologies tied together through REST interfaces. In particular, we assume activity recordings (which are to be considered personal data) to be sent from fitness-tracking devices to a RESTful API, forwarded to a publish-subscribe broker, and retrieved from there by serverless functions for validation and sanitization. Afterwards, they are inserted into a PostgreSQL database, from where they are accessed and processed by a \enquote{main application} providing a user-facing web interface etc. In addition, data might be sent to external parties (like social networks) through respective interfaces. Besides serving illustrative purposes,
we also implemented this architecture based on well-established components, allowing us to successfully validate our technical contributions (see figure~\ref{fig:example-architecture}).%

\section{Background \& Related Work}\label{sec:bg_motiv}

Since our work is mainly motivated by the interplay between legal requirements, technical measures to fulfill them
and the actual givens of current software architectures and development practices,
these areas shall thus be briefly elaborated on.%

\subsection{Privacy, Transparency \& Technical Measures}%

\label{sec:background:sub:dp_principle}
Born as \emph{Openness Principle} in the OECD Guidelines on the Protection of Privacy in 1980~\cite{_oecd_1980}, %
transparency finds its latest incarnation as one of the core principles to which data controllers are obligated under the %
GDPR~\cite{cit_gdpr}. %
The concept of transparency in the GDPR %
aims at empowering data subjects %
regarding information asymmetries towards parties processing personal data~\cite{cit:wp29_transparency}.

Consequently, the GDPR requires numerous %
information to be provided to data subjects. %
The respective categories are distributed across Art. 13--15 GDPR and will be examined in more detail in~sec.~\ref{sec:legal_req}.
Following the concept of \emph{Data protection by design and by default}~\cite[Art. 25]{cit_gdpr}, the GDPR also obligates data controllers to establish appropriate technical measures to implement privacy principles like transparency, which
implies the need for \emph{Transparency Enhancing Technologies (TETs)}.

Early definitions of TETs characterized them based on their means to 1) provide information about data collection, 2) act in the data subject's name to access personal data or 3) provide capabilities to lower the risk of
profiling activities~\cite{hedbom2008survey}. %
Subsequent classification frameworks distinguish TETs %
in matters of their span width or quality of parameters such as data types presented, delivery mode, scope, or application time~\cite{cit:tet_cat_zimmermann}. %
However, there still
exists
a gap between legal transparency obligations
and
available technical measures to satisfy them,
especially concerning
modern, real-world information systems ~\cite{spagnuelo2019accomplishing,riva2020}.%

With
regard to microservice architectures, related work includes formalizing privacy-preserving constraints in the domain of health care \cite{formalising,theorem}. In a similar vein, specialized APIs for data transparency were proposed, that reveal \enquote{one's own user data} held by services in use \cite{theprivacyapi}.
Besides these, however, TETs explicitly addressing RESTful microservice architectures and the interplay of multi-service environments are %
underrepresented in scientific literature.

Referring to Privacy Enhancing Technologies in general,
the importance to build tools that include an ecosystem for their effective application and incentivize data controllers to actually use them in practice is emphasized~\cite{hansen2016data}.
This does, of course, also apply to the particular category of TETs.
Therefore,
solutions
that smoothly integrate and
align with established practices of modern information systems engineering and developers' daily routines are needed. %

\subsection{APIs, DevOps \& RESTful Architectures}
\label{sec:agile}

Currently,
businesses increasingly adopt agile development practices, which leverage short development cycles and significantly relax on %
regimented practices, documentation, and detailed planning in favor of \textit{agile processes}.
These emphasize the importance of iterative improvement and promote greater autonomy and ownership to smaller, %
cross-functional teams \cite{estler_AgileVsStructured_2014}.

Agile development typically goes hand in hand with DevOps practices, a set of technical and cultural measures that shorten the time between committing a change and moving it to production \cite{bass_DevOpsBook_2015}.
This reduction is enabled by continuous integration and delivery (CI/CD) pipelines that automate many software development steps, from build and test automation to automated deployment. %

Together, these practices have created an environment where updates occur at an increasing frequency and where some
of these updates may
also
modify existing or introduce new activities of collection, processing, or even transfer of personal data.
Even if privacy requirements have so far played a minor role in the context of agile development %
\cite{agile_turn, secdevops},
this %
introduces the need to dynamically align
provided transparency information to the continuously changing \textit{actual} %
state of the overall system.

Technology-wise, agile and DevOps-oriented practices are typically complemented by RESTful architectures comprising
dozens or even hundreds
of microservices \cite{zimmermann_microservicesREST_2016}. %
These microservices -- %
developed and operated by the rather independent teams mentioned above -- typically expose %
APIs for representational state transfer via HTTP (so-called REST APIs). Such standardized APIs allow for
independent development of services and the loose coupling between them required in agile practices.

To facilitate the understanding and usability of services' APIs, especially across different teams, REST APIs are typically described and documented using OpenAPI specifications\footnote{See \url{https://github.com/OAI/OpenAPI-Specification}} %
that allow each path of a REST service to be annotated with the available methods and required parameters, as well as data in- and output schemas.
This is
usually done by service developers
in a standardized, well-structured manner directly within the program code or in accompanying specification files. %
Besides the functionality covered by the standard specification, OpenAPI can also be used for extra functionality through
an extension mechanism\footnote{See \url{https://swagger.io/docs/specification/openapi-extensions}}
that we will employ
for specifying transparency information within a particular service.%

\section{Discussion \& Conclusion}
\label{sec:conclusion}

In this paper, we presented TIRA, a toolbox for achieving GDPR-related transparency in RESTful application architectures developed and operated following agile, DevOps-oriented practices and paradigms. Our contribution comprises, first, an OpenAPI extension and respective vocabularies specifically tailored to the GDPR's transparency requirements. Second, TIRA also includes a set of higher-order tools for collecting and aggregating respective transparency information from the descriptions of multiple, interdependent services %
and for integrating our approach into established CI/CD-pipelines. %
Tightly interwoven with each other, these components allow to harness transparency information in a bottom-up, developer- and service-focused manner. The so-generated transparency information pave the way for novel approaches for fulfilling regulatory transparency requirements in line with the widely established givens
of modern, real world information systems engineering.

Our approach significantly differs from other proposals made so far in various respects. First and foremost, TIRA is based on an exhaustive analysis of legal transparency requirements and explicitly tailored to these from ground up. Insofar, it significantly distinguishes from other approaches %
(e.g., \cite{cranor2002web, prime}) which often lack the explicit alignment to legally mandatory transparency requirements \cite{gerl2018critical, dark}. Second, we consciously follow an annotation-based approach instead of employing, for instance, information flow control \cite{pasquier2016information} or static code analysis \cite{hjerppe2019annotation} for determining what personal data a service consumes or exposes, how long it is stored, etc. Here, we consciously take an \enquote{optimistic} stance on developers and data controllers -- which we aim to support in fulfilling their duties instead of trying to prevent misbehavior -- and explicitly value practical applicability over tamper- or concealment-proofness. In matters of integrating the procedural and organizational givens of agile, DevOps-based information systems engineering from the outset and rigidly translating them into corresponding technical mechanisms, in turn, our approach is -- %
to the best of our knowledge -- quite unique in the domain of privacy engineering so far. We do, however, foresee more such activities dedicatedly integrating organizational givens %
into the design of technical privacy mechanisms to gain traction in the future.

Of course, our approach is currently still subject to some limitations. In particular, TIRA is so far confined to RESTful APIs with respective OpenAPI specifications. Even though components without such specifications could be encapsulated with additional wrappers
, doing so will not be viable in many real-world enterprise systems. Alternative service specification mechanisms -- such as the RESTful API Modeling Language (RAML),
API Blueprint,
GraphQL schemas,
or Docker Compose
service configurations -- should thus also be integrated into TIRA in the future. Another line of desirable future extensions regards capabilities for reflecting and expressing advanced concepts such as, for instance, hierarchical vocabularies of data- or purpose-categories \cite{pandit2019creating, bonatti2018data}. Finally, integrating TIRA with recently proposed formats for representing and communicating transparency information across organizational boundaries  \cite{gruenewald2021, Gerl2018} is also an obvious target for future activities.

Apart from these current limitations, however, TIRA provides a paradigmatically novel approach for fulfilling transparency obligations in line with privacy regulations as well as the realities and givens of modern information systems engineering in practice. It is explicitly designed to lower data controllers' efforts and heightens their capabilities to fulfil their transparency-related duties.

Last but not least, TIRA thereby consciously works towards data controllers' obligation to actually apply technical transparency measures like the ones presented herein under legal provisions for privacy / data protection by design, such as Art. 25 of the GDPR. Beyond introducing a novel technical approach in and by itself, TIRA thus also demonstrates the wider prospects of applied privacy engineering beyond anonymization and security.

\section{Introduction}

Privacy regulations such as the GDPR %
prescribe several privacy principles to be complied with. One of these is the principle of transparency, which obligates controllers to inform data subjects about what data is collected, for which purposes, etc.
Only with the appropriate information can users make well-informed and self-sovereign decisions about what information to reveal to which services.

Today, such transparency information is mostly provided in lengthy privacy policies which are typically written in legalese, hard to understand language and therefore barely read or understood by users \cite{rudolph2018}. %
In addition, information about the processing of data is kept purposely vague, to allow for flexibility regarding the implementation \cite{ThePrivacyPolicyLandscapeAftertheGDPR}.
In their current state, most privacy policies do thus not fulfill the goal of enabling well-informed decisions and their vagueness is increasingly being challenged by authorities\footnote{See, e.g., \url{https://www.cnil.fr/en/cnils-restricted-committee-imposes-financial-penalty-50-million-euros-against-google-llc}}. As possible countermeasures, different technical approaches for providing transparency -- so called \textit{Transparency Enhancing Technologies (TETs)} -- have been proposed.
These comprise a broad variety of mechanisms, from machine-readable representations \cite{gruenewald2021, Gerl2018} to function-rich user-facing dashboards \cite{bier, Raschke2018}.

However, none of these mechanisms addresses the challenge of %
gathering the underlying transparency information within an organization in a manner that is systematic and specific enough to fulfill legal requirements. This challenge is especially relevant with the adoption of agile processes. %
Here, updates occur at an increasing frequency, are carried out by independent teams for a multitude of decoupled microservices, and are subject to a comparably low level of centralized coordination, leading to an overall system architecture that is in constant flux.

Regarding the fulfillment of legal transparency obligations, this raises the question as to how the required %
information can be collected across relevant services in a way that reflects the actual implementation of personal data processing and how this information can be integrated into a single, %
always up-to-date view that is subsequently provided to data subjects.
Established, rather manual and centrally coordinated ``inventory'' practices paradigmatically conflict with the %
goals behind agile DevOps here. %

Data controllers therefore currently face a dual challenge with regard to the provision of adequate privacy-related transparency information: First, they must be able to gather and inventory transparency-related information about the processing of personal data within their systems in line with the requirements from privacy regulations like the GDPR. Second, respective approaches must also integrate well with established principles and practices of agile, DevOps-focused engineering of complex information systems comprising a multitude of decoupled, yet interdependent microservices.%

To counter this dual challenge in real-world information systems engineering, we herein present TIRA, an OpenAPI extension and toolbox to technically address legal transparency requirements %
that consciously incorporates the givens of agile DevOps practices and RESTful architectures. In particular, we provide: %

\begin{itemize}
    \item An \textbf{OpenAPI 3 extension}, comprising a GDPR-aligned transparency vocabulary and %
    a schema extension specifying how to express %
    transparency information on a per-service basis, and %
    \item A a \textbf{set of higher-order tools} for collecting and aggregating respective information across multiple, interdependent services and for %
    integrating our approach into automated CI/CD-pipelines.%
\end{itemize}

With these contributions, we aim to %
help \textit{service providers} in capturing the processing and flow of personal data within their distributed, ever-changing systems, which is a necessary precondition for employing novel approaches that help overcome above-mentioned shortcomings of current privacy policies. Our motivation is thus to build a TET that acts from the \textit{perspective of service providers} and their developers and is actually usable to \textit{those}. This shall be done by integrating into their development routines and consciously adapting to the tools and methods employed in modern information systems engineering, imposing as little additional effort as possible. In particular, our approach closely integrates into the de-facto standard of RESTful service engineering and allows developers to easily attribute single services of a larger RESTful architecture with transparency information. On this basis, we envision the semi-automatic generation of transparency information spanning multiple services, business domains, or even companies involved in the processing of personal data %
without heavily impairing agile development routines and practices.   %

The remainder of the paper is structured as follows: we present
relevant background and related work (sec.~\ref{sec:bg_motiv}), distill requirements and delineate our general approach (sec.
\ref{sec:approach}) first. With this foundation, we introduce our transparency-related OpenAPI extension and vocabulary (sec.~\ref{sec:vocab_apispec}) and present our higher-order tools %
(sec.~\ref{sec:thub}). %
Sec.~\ref{sec:conclusion} briefly discusses our approach and concludes.
\section{A Transparency Extension and Vocabulary for OpenAPI}\label{sec:vocab_apispec}

As outlined in sec.~\ref{sec:approach_approach} above, we propose a bottom-up approach to the generation of system-wide transparency information that harnesses developers' superior knowledge about their individual services. In particular, we intend to do so through developer-provided transparency information within the respective services' OpenAPI specifications. For this purpose, we introduce a dedicated extension for OpenAPI as well as an accompanying vocabulary below, allowing to provide \emph{service-level} %
transparency information in line with the requirements from the GDPR identified in sec.~\ref{sec:legal_req}. \emph{System-wide} transparency information, in turn, are subsequently addressed in sec.~\ref{sec:thub}. We publish our contributions along with extensive documentation as open source software.\footnote{See \url{https://github.com/PrivacyEngineering/tira}}

\subsection{Personal Data in OpenAPI specifications}
\label{sec:openapi_structure}

An OpenAPI specification describes a RESTful API as a whole, including many details unrelated to the processing of personal data. Hence, the first step towards a transparency-specific OpenAPI extension consists of identifying where and how personal data becomes relevant and where respective transparency information is thus to be incorporated in an OpenAPI specification document. %
We refer to those parts of the specification that describe consumed or exposed personal data as \emph{PD indicators} herein.\footnote{For the sake of understanding and clarity: The OpenAPI specifications may under no circumstances contain personal data records (\enquote{Jane Doe}), but only \emph{PD indicators} (\enquote{Name}).}

The most relevant part with regards to \emph{PD indicators} is the \texttt{paths} section.
All routes and requests provided by the described service are listed here.
In the paths object, instances of \texttt{pathItem} can be defined, describing a single URL a service accepts requests for.
Such a \texttt{pathItem} can consist of several \texttt{operations} (GET, POST, etc.) that map to HTTP request methods.
For each operation, in turn, all entities that make up a request and its response can be described.
These include request bodies, responses, headers, cookies and parameters, whereas OpenAPI consolidates path parameters (e.g. \lstinline|domain.tld/{user_id}|), query parameters (e.g \lstinline{/path?user_id=123}), headers and cookies under the \texttt{Parameter} class. All these may possibly specify the consumption or exposure of personal data and are therefore candidates for \textit{PD indicators}.\footnote{For more details see \url{https://github.com/PrivacyEngineering/tira/blob/main/docs/PD_INDICATORS.md}}

\subsection{Extending OpenAPI}\label{ssec:extending-openapi}
Having identified the locations where \emph{PD indicators} may reside, we introduce a custom extension for OpenAPI documents. Implementing such an extension is a prerequisite for actually expressing transparency information via a vocabulary. This vocabulary will be embedded into the extension and will be covered in detail in sec.~\ref{sec:vocabulary}. Our extension enables developers to:

\begin{itemize}
    \item[\circled{1}] Declare data fields processed by a RESTful service as personal data indicator as such
    \item[\circled{2}] Further annotate personal data indicators with transparency information regarding the processing done by the documented service
    \item[\circled{3}] Annotate properties of the service itself that are relevant with regards to transparency obligations
\end{itemize}

OpenAPI extensions can be of all primitive types, \texttt{null}, an \texttt{array} or an \texttt{object}, allowing for versatile custom extensions. We will use %
them to enrich the existing documents with transparency-related information. Moreover, in order to allow several extension types and for preventing overlaps with other arbitrary extensions, we define a namespace called \texttt{x-tira}. %
Hereafter, we describe how we leverage the extension to fulfill the tasks mentioned above.

To \circled{1} \textbf{declare any data field as personal data indicator} using \texttt{x-tira}, it is sufficient to include an \texttt{x-tira} extension instance of any form inside the corresponding \texttt{schema}.
The recommended way is to set the custom boolean \texttt{x-tira} to \texttt{true} inside a \texttt{schema}. %
If a whole \texttt{schema} is marked this way, no specific \textit{PD indicators} inside the given \texttt{schema} would need to be declared. %
If transparency information is declared at higher hierarchical levels of the document, a subordinate \texttt{schema} will automatically inherit the given property or can possibly override it. Listing~\ref{lst:personal-data-weight-x-tira-only} exemplifies the declaration of \textit{PD indicators} in the context of our application scenario, describing the API endpoint the fitness devices %
communicate with.

Alternatively, an \texttt{x-tira} object may also be declared at the root level of a document. Then, declared transparency information refers to the whole API endpoint. This may be useful when, for example, the hosting situation of the service itself has an influence on transparency obligations -- e.g. when the service is hosted outside of the EU jurisdiction or is provided by a third party (see the two gray-colored service providers in our application scenario).
Complementary attributes or properties of a \texttt{schema} for which the declaration shall not apply can be exempted by invoking \texttt{x-tira-ignore} (see listing~\ref{lst:personal-data-weight-x-tira-only}).

\begin{lstlisting}[
    language=yaml,
    basicstyle=\tiny,
    frame=single,
    float=tp,
    caption={
        [A schema indicating personal data being processed.]
        {
        An OpenAPI \texttt{schema} definition of the object \texttt{Weight} which is marked as \textit{PD indicator}.}
        },
    captionpos=b,
    label={lst:personal-data-weight-x-tira-only}
]
components:
  schemas:
    Weight:
      x-tira: true             # Declared as PD indicator
      type: "object"
      required:
        - weight
        - day
      properties:
        weight:
          type: "number"
          format: "float"
        submission:
          type: "string"
          format: "dateTime"
        log-level:
          type: "string"
          x-tira-ignore: true   # Excluded from marking (not personal data)
\end{lstlisting}

\begin{lstlisting}[
    language=yaml,
    basicstyle=\tiny,
    frame=single,
    float=t,
    caption={
        Example of the \texttt{RetentionTime} vocabulary element:  A
        time-span is defined by setting values for years, months and days.
        When storage is volatile or has no explicit limit, this is also configurable.
        Whether a review is happening -- as imposed by the GDPR -- and in which frequency it is performed can also be defined.
        This example shows a storage period of ten years whose compliance is controlled daily.
    },
    captionpos=b,
    label={lst:vocab:retention_time}]
x-tira:
  retention_time:
    days: null
    months: null
    years: 10
    # volatile: true
    # no_limit: true
    periodic_review: true
    review_frequency:
      days: 1
      # months: null
      # years: null
\end{lstlisting}

\subsection{Transparency vocabulary} \label{sec:vocabulary}

Having established how \textit{PD indicators} can be declared as such in an OpenAPI specification, we will now continue with how \circled{2} \textbf{further transparency-relevant information can be  expressed} in line with requirements from to the GDPR. For this purpose, we introduce a transparency vocabulary that is integrated into OpenAPI documents via the presented \texttt{x-tira} extension.
Doing so allows developers to annotate %
data processing activities of a given microservice. By design, the vocabulary closely relates to the legal requirements from the GDPR, which were laid out in sec.~\ref{sec:legal_req} (see Req.~1). The vocabulary represents all information that realistically can be expressed by developers (see Reqs.~2 and 5), hence representing their perspective. %

If a schema (see listing~\ref{lst:personal-data-weight-x-tira-only}) is marked as \textit{PD indicator}, our extension will instantiate a \texttt{Tira::PersonalDatum} object related to it. Attached to this object can be instances of \texttt{Tira::TransparencyProperty} which have a type. Each of these, in turn, represents one vocabulary entity, which is represented by a subclass of the \texttt{Tira::TransparencyProperties} class. In general, \texttt{TransparencyProperties} can be attached to a \textit{PD indicator} in several ways within an OpenAPI document: Either they are incorporated directly by extending the schema or they might as well be integrated on a higher level, e.g. for operations or pathItems, in which personal data is obtained or passed on. Alternatively, at document level, \circled{3} \textbf{transparency properties of a whole service are annotated}, e.g. for external services (see Reqs. 2 and 3). %

To illustrate how the vocabulary is used in practice, we recall our application scenario (see sec.~\ref{ssec:running-example}). We might want to further annotate the API specification of our PostgreSQL database to show exemplary behaviour. In listing~\ref{lst:vocab:retention_time} we show how a \textit{storage period} can be expressed fully compliant with table~\ref{tab:information-categories}. First of all, the storage period itself can be set. Developers can then express for how long the documented endpoint saves data via \texttt{days}, \texttt{months}, and \texttt{years} fields. If the storage is volatile or unlimited in time, this can also be set in respective fields. Moreover, the GDPR also allows storage time limits to be ensured by periodic reviews (see Recital 39). Whether these reviews are taking place and, if that is the case, in which frequency %
can also be set in the storage period vocabulary element. Taken as whole, the extended API specification effectively communicates the required transparency information with regards to storage periods.

For now, we took the vocabulary element of \texttt{RetentionTime} as an extensive example.
Beyond this, we also introduce vocabulary elements for \texttt{Recipients}, \texttt{Third Country Transfers}, \texttt{Special Category} (Art. 9 GDPR), \texttt{Profiling}, and \texttt{Purposes} (here we integrated YaPPL \cite{cite_yappl}).
All of these vocabulary elements consist of curated fields for declaring \textit{all} relevant information according to table~\ref{tab:information-categories} (see Req.~1) along with \textit{PD indicators}. Eventually, all vocabulary items are managed by the \textit{TransparencyHub} for further aggregation. Due to space constraints, %
a more extensive explanation of each item is given in our documentation.\footnote{See \url{https://github.com/PrivacyEngineering/tira/blob/main/docs/VOCABULARY.md}}

\subsection{Continuous Integration and Delivery of transparency information}
\label{sec:ci-cd}

To seamlessly integrate the practical application of our approach into modern, agile development practices and the respective tooling  (Req.~4), we provide a pipeline component that automatically %
processes transparency-enhanced service specifications %
with as little manual developer effort as possible.
For this purpose, we provide a CI component that informs the \textit{TransparencyHub} about changes to services processing personal data.

We chose an integration into Git-based version control systems\footnote{We chose \textit{GitLab} for our implementation -- analogous functionalities are present for \textit{Github}, \textit{Bitbucket}, and \textit{Gitea}, among others.}. Therefore, we implemented an endpoint accepting and processing Git \texttt{push} events, which can be configured via Git webhooks present in all service repositories.
If a repository is yet unknown, the \textit{TransparencyHub} will automatically create a service representation, otherwise it continuously registers whether existing OpenAPI documents have been added (e.g., new \textit{PD indicators}) or changed (e.g., updated purpose definitions).%

Through this functionality, it is possible to configure all services of an organization to use the introduced technologies and enable a transparency-aware system via just one initial setting.

\section{Managing system-wide transparency information with \textit{TransparencyHub}}
\label{sec:thub}
As laid out above, the transparency information provided via our OpenAPI extension on a per-service level also need to be integrated into a single, overall view comprising all relevant services and their interdependencies.
In addition, they also need to be enriched with system-wide information (see table \ref{tab:information-categories}) for being able to fulfill all transparency requirements of the GDPR. These functionalities are provided by the \textit{TransparencyHub} we propose alongside our OpenAPI extension.

The \textit{TransparencyHub} implements an endpoint for a CI  workflow, that accepts and processes transparency-enhanced RESTful service descriptions (integrative functionalities),
analyzes and aggregates these (analytical functionalities), and
offers a transparency administration interface

(management functionalities).
The \textit{TransparencyHub} was built using the popular \textit{Ruby on Rails} web-application framework, with the OpenAPI extension and vocabulary being implemented as separate modules each. %
We will now elaborate on the workflows provided by the \textit{TransparencyHub}.

\subsection{Aggregating transparency information}
\label{subs:thub:displaying_transparency_properties}

In essence, the \textit{TransparencyHub} collects and processes the transparency information provided via services' OpenAPI documents and translates these into consolidated representations and views, accessible via multiple dashboards:
First, an index view for all registered internal and external services is created.
One can, at a glance, check whether an OpenAPI specification is present and valid,
access an interactive \textit{SwaggerUI} representation\footnote{See \url{https://swagger.io/tools/swagger-ui/}} -- as \textit{Swagger} utilizes the OpenAPI format --
and view a history of specification changes and compare older versions (commit log).
Services that do not process personal data can be viewed but reside in a separate index view.

\begin{figure}[t]
		\includegraphics[width=1\columnwidth]{img/thub_stepcount_schema.png}
		\caption[\textit{TransparencyHub} -- Aggregated Transparency Information for one Personal Datum]
		{
		    One of the generated dashboards: Aggregated transparency information for a \textit{PD indicator}
		    (here: \enquote{Stepcount} from a health data device).
		  It provides an overview of services the data are processed by and all properties incorporated via the transparency vocabulary in OpenAPI documents are shown.
		  Via the `Ref-Link', the respective reference in an OpenAPI document can be copied. All named services relate to our application scenario (see figure~\ref{fig:example-architecture}).
 		}
		\label{fig:thub-stepcount}
		\vspace{-0.3cm}
\end{figure}

Secondly, we provide a schema index including all entities that were marked as \textit{PD indicators} (see sec.~\ref{ssec:extending-openapi}).
Such an aggregated view (see figure~\ref{fig:thub-stepcount}) accurately displays the gathered transparency information that were expressed via the vocabulary about \textit{PD indicators} and entire services.
To actually aggregate the distributed transparency information, \textit{TransparencyHub} uses aggregation functions to combine vocabulary elements of the same type regarding each \textit{PD indicator}.\footnote{E.g., the storage periods seen in figure~\ref{fig:thub-stepcount} were aggregated to an \enquote{unlimited} value based on the arithmetic maximum used as suitable aggregation function.}

In the same way, a comparable dashboard is present for all purposes that are present throughout all OpenAPI specifications. All purpose/service and purpose/\textit{PD indicator} dependencies become visible in there.
Analogously, a dashboard is generated for all data recipients or utilizers and respective categories thereof.

\subsection{Managing transparency information}\label{subs:thub:express_transparency_info}

From both a systems engineering and a legal perspective
not all transparency-related information that need to be expressed may directly relate to RESTful APIs. In addition, it would not be viable to have developers alone being responsible for specifying \emph{all} relevant transparency information. %
The \textit{TransparencyHub} hence does not only aggregate gathered transparency information, but also acts as transparency administration interface for the data controller (or data protection officer) and the entire system.

To begin with, the \textit{TransparencyHub} allows to keep track of OpenAPI documents of arbitrary services.
Therefore, services -- internal or external ones -- can either be registered manually (by uploading the description) or be added automatically via our CI/CD pipeline integration (see sec.~\ref{sec:ci-cd}).
After services have been registered, their interconnections can be edited, defining all \textit{n:m} relations with regard to sending and receiving personal data.
This will reveal the data flows within the system on a high level -- which is also displayed as a graph structure -- supporting a possible processing inventory.
If third parties would also make use of extended OpenAPI documentations, %
these can be integrated in the analysis just as any internal service -- allowing to achieve \enquote{transitive transparency} across multiple %
companies and business domains.

Additionally, the \textit{TransparencyHub} serves as administration point for system-wide transparency information such as contact information, data protection officers, etc., which are required for fulfilling legal %
obligations (see table~\ref{tab:information-categories}). %
Also the legal bases, for which we provide templates, and Art. 9 processing scenarios can be edited and described further.
Besides, all utilizers and purposes can each be grouped if they concern the same processing activity.
For a future version, we also consider directed acyclic graph structures for linking and building hierarchies between these entities and categories thereof such as described in related work \cite{cite_yappl}.

redpajama_set_name: RedPajamaArXiv


text:
\section{Introduction}

TeV $\gamma$ ray s propagating from distant extragalactic sources suffer from attenuation due to the pair production in interactions with the extragalactic background light (EBL). The pair production effect leads to the deposition of electron-positron pairs in the intergalactic medium. These pairs lose their energy via inverse Compton scattering of cosmic microwave background (CMB) photons and in this way produce a secondary $\gamma$-ray\ flux which could be detected as extended and time-delayed $\gamma$-ray\ ``glow'' around extragalactic TeV $\gamma$-ray\ sources \citep{aharonian_coppi}. Properties of this secondary $\gamma$-ray\ flux are sensitive to weak magnetic fields present in the intergalactic medium \citep{plaga95,neronov07,NeronovSemikoz09,Neronov_Elyiv_10}. This provides us an opportunity to measure such weak magnetic fields using $\gamma$-ray\ observation techniques.

Non-detection of extended or delayed GeV band emission from several extragalactic TeV sources has been previously used to derive a lower bound on the intergalactic magnetic field (IGMF) strength. Indeed, the lower bound on IGMF represents the minimum magnetic field strength needed to suppress the cascade emission in the GeV domain making it negligible with respect to the source emission. The bound on long-correlation-length magnetic field, $\mathrm{B>10^{-16}}$~G~\citep{Neronov10,Tavecchio11} has been derived under the assumption that the present day measurements of the TeV $\gamma$-ray\ flux from selected blazars (a class of active galactic nuclei -- AGNs -- with the jet pointing towards the observer) are representative for the entire AGN duty cycle period of the order of 10~Myr. A weaker bound of $\mathrm{B>10^{-17}}$~G was derived after relaxing this assumption and assuming instead that the selected TeV sources were active only during the historical TeV $\gamma$-ray\ observation time span~\citep{dermer11,Taylor11,Vovk12}. An update of this approach yielding a lower bound $\mathrm{B>3\times 10^{-16}}$~G on long-correlation-length magnetic fields has been reported by \citet{fermi_limit}, based on 7.5 years of the \textit{Fermi}/LAT\  telescope data~\citep{FermiLAT}. This updated analysis was also based on the unverified assumption of stability of the TeV band flux on a decade time span.  Limits on extended emission around bright blazars Mrk~421 and Mrk~501 were also derived from the MAGIC telescope data \citep{MAGIC_extended} at energies above 300~GeV, excluding IGMF strengths in the range $\mathrm{4\times10^{-15}~\mathrm{G} - 1.3\times10^{-14}~\mathrm{G}}$, under a strong assumption of existence of persistent intrinsic source flux above 20 TeV. Several other blazars were observed by the H.E.S.S. telescopes~\citep{HESS_IGMF}, yielding similar results -- IGMF strengths in the range $\mathrm{(0.3-3)\times10^{-15}}$~G were excluded, under similar assumptions regarding (unmeasured) intrinsic source fluxes above 20 TeV.

In what follows we report a significant improvement upon these previous results. We use the data of systematic long-term GeV-TeV band monitoring data on a specific source providing the most stringent IGMF lower limits to date, 1ES~0229+200, owing to its distance~\citep[redshift of $\mathrm{z\approx 0.14}$,][]{1ES0229_redshift}, hard GeV-TeV spectrum and apparent absence of the high-energy cut-off~\citep{HESS_1ES0229}. The data collected over more than a decade time span allow to substantially relax assumptions about the intrinsic source flux properties over that period. The TeV band monitoring data allow us to make precise prediction of the cascade flux timing properties at lower energies, i.e. those accessible to the \textit{Fermi}/LAT\  telescope. The combination of the imaging atmospheric telescope and \textit{Fermi}/LAT\  measurements allows us to test the model prediction against the data. We show that non-detection of delayed cascade emission in \textit{Fermi}/LAT\  data yields a robust lower bound on IGMF strength and correlation length, free of the assumptions above.

This paper is organized as follows. In Section~\ref{sect::data_analysis} we describe the reduction of the MAGIC and \textit{Fermi}/LAT\  data, followed by the numerical modelling of the time-delayed cascade emission. In Section~\ref{sect::analysis_results} we assess the 1ES~0229+200\ variability and apply the developed model to evaluate the corresponding bounds on IGMF strength. Finally in Section~\ref{sect::discussion} we discuss the implications of this measurement for the IGMF origin and outline prospects for its further improvements with future observations.

\section{Data analysis}
\label{sect::data_analysis}

\subsection{MAGIC data analysis}

MAGIC is a stereoscopic system of two 17 m diameter Imaging Atmospheric Cherenkov Telescopes (IACT). It is located at 2200 m a.s.l. in the observatory of the Roque de los Muchachos, on the Canary island of La Palma, Spain. It can register $\gamma$ ray s from about 50~GeV to more than 50~TeV. For low-zenith angle observations, the sensitivity of the telescopes for point sources reaches 0.7\% of the Crab Nebula flux above 220 GeV in 50~hr of exposure~\citep{MAGIC_performance}.

MAGIC observations of the 1ES~0229+200\, were conducted during the period September 2013 -- December 2017\footnote{The spectral energy distribution  obtained processing the data sample from 2013 to January 2017 has been already published by MAGIC coll. \citep{Acciari2020}. Here we added the data taken in 2017 showing also the overall lightcurve.}. The data set used in our analysis has 145.5~hr of accumulated exposure with zenith angle below 50 degrees, where the MAGIC energy threshold is lower.

The data were analysed using the standard MAGIC software MARS~\citep{zanin_mars_2013}. Standard event cuts are used to improve the signal-to-background ratio as described in~\citet{MAGIC_performance}.
We use standard MAGIC angular cuts to select the source events in the field of view as for time delays shorter than ~$\mathrm{\sim 10}$~years, discussed below, no significant cascade emission is expected to extend beyond the MAGIC point spread function (PSF).

\subsection{\textit{Fermi}/LAT\  data analysis}
\label{sect:lat_analysis}

Our analysis of \textit{Fermi}/LAT\  data is based on the {\tt P8R3 SOURCE} type $\gamma$-ray\ event selection in the energy range 100~MeV to 200~GeV collected between August 2008 and September 2020. We have processed the data using the Fermitools package and FermiPy framework\footnote{\url{https://fermi.gsfc.nasa.gov/ssc/data/analysis/}} v0.17.3~\citep{fermipy} as described in FermiPy documentation\footnote{\url{https://fermipy.readthedocs.io/}}.

To extract the source spectrum we have considered the events in the $\mathrm{25^\circ}$-wide region-of-interest around the source position, collected under the zenith angles below $\mathrm{90^\circ}$. We have accounted for the galactic ({\tt gll\_iem\_v07.fits}) and extragalactic ({\tt iso\_P8R3\_SOURCE\_V2\_v1.txt}) diffuse backgrounds and included other sources from the \textit{Fermi}/LAT\ fourth source catalogue~\citep[4FGL,][]{4FGL}. The shapes of the sources' spectra were taken from the 4FGL~catalogue with their normalisation left free. We constructed likelihood components separately for each of the four \textit{Fermi}/LAT\  PSF classes (event types 4, 8, 16 and 32) and used them jointly in the fit, accounting for the instrument's energy dispersion. The spectra and lightcurves were extracted using two complementary techniques: the binned likelihood analysis and the aperture photometry (for the latter a smaller ~$\mathrm{5^\circ}$ region and ``source'' event type 3 selection was used). The consistency of the results was verified via the crosscheck of the spectra and lightcurves obtained with these two techniques.

We restrict the aperture photometry analysis to the energy range 1-200~GeV (the highest energy photon from the source direction has the energy $\mathrm{E\simeq 180}$~GeV). All over this energy range, the diffuse background event count becomes comparable or lower than that of the source only in the narrow angular bin range $\mathrm{0<\theta<0.25^\circ}$. Taking this into account, we choose the region of extraction of the source signal $\mathrm{\theta<0.25^\circ}$ in the aperture photometry method of spectral extraction. Given that the 95\% containment radius of the \textit{Fermi}/LAT\  PSF\footnote{http://www.slac.stanford.edu/exp/glast/groups/\newline /canda/lat\_Performance.htm} above 2~GeV is $\mathrm{\approx 1.5^\circ}$, we use the {\it gtexposure} tool with parameter {\tt apcorr=y} which assures that the source flux estimate from small region of $\mathrm{\theta<0.25^\circ}$ is properly corrected for the source flux fraction contained in this circle.

\subsection{Numerical modelling}
\label{sect:numeric_modelling}

Propagation of $\gamma$ ray s through the intergalactic medium leads to the development of electromagnetic cascades initiated by pair production of the highest energy $\gamma$ ray s on the far-infrared photons of the extragalactic background light. The cascade emission appears as a delayed $\gamma$-ray\ emission following an intrinsic flare of a $\gamma$-ray\ source. To model the delayed emission signal, we have used two fully 3D Monte Carlo codes which trace the development of the cascade in the intergalactic medium: the \texttt{CRPropa} v3.1.7 code \citep{CRPropa} and the \texttt{CRbeam} code developed in~\citet{Berezinsky:2016feh}, also tested via comparison with the alternative cascade simulations~\citep{Taylor11,Kalashev:2014xna,Kachelriess:2011bi}. Detailed comparison of these codes has been performed in~\citet{CRbeam}, where it was shown that simulations with CRPropa and CRbeam agree with each other with an accuracy of the order of 10\% for relatively nearby sources with $z < 0.3$; for the modelling below we have fixed the issue with the inverse Compton interaction rate in CRPropa, identified there.
We use these codes to calculate the cascade signal
$G(E_{\gamma, 0},E_\gamma,t,\tau, B,\lambda_B)$
at the  energy $\mathrm{E_\gamma}$ produced by propagation of primary $\gamma$ ray s of energy $\mathrm{E_{\gamma,0}}$, injected instantaneously by the source and arriving at the time $\mathrm{t}$. The codes give the estimate of the cascade signal as a function of the time delay $\mathrm{\tau}$. The cascade "Green's function" $\mathrm{G}$ depends on the strength $\mathrm{B}$ and correlation length $\mathrm{\lambda_B}$ of IGMF and, in principle, also on the spatial-domain power spectrum of the Fourier expansion of $\mathrm{B}$. Throughout the paper we assume all of the IGMF power is concentrated in a single mode at $\mathrm{k=1/\lambda_B}$ scale.

The cascade flux at an energy $\mathrm{E_\gamma}$ in the observer's frame, based on the known flux variability pattern $\mathrm{F_{s}(E_{\gamma,0},t)}$ can be then expressed as follows:
\begin{equation}
    F_{c}(E_\gamma,t)=
    \int_0^\infty\int_{E_\gamma}^\infty G(E_{\gamma,0},E_\gamma,t-\tau,\tau) F_s(E_{\gamma,0},t-\tau) \dd{E_{\gamma,0}}  \dd{\tau}
\end{equation}

In our calculations we parametrized the intrinsic source light curve (namely the variability pattern) $\mathrm{F_s}$ as 14 steps (bins) in the time interval MJD~53000 -- MJD~59000, covering all of the IACTs and \textit{Fermi}/LAT\  observations. The step size is chosen so that to suppress the appearance of the bins with no observations counterparts while still matching the observed source variability (see Sect.~\ref{sect::analysis_spectrum_lightcurve} below). Combined contribution of these time bins (as described by the ``Green's function'' above) was used to estimate both primary and delayed fluxes in each time and energy bin.

As available data do not reveal any variability of the 1ES~0229+200\ spectral shape in the $\mathrm{\gtrsim 100}$~GeV energy range, when converting $\mathrm{F_s}$ to primary/secondary flux estimates, we have made a simplifying assumption that the intrinsic source spectrum follows the power law shape with an exponential cut-off
\begin{equation}
    \frac{dN}{dE} = A \left(\frac{E}{E_0}\right)^{-\Gamma} \exp\left(-\frac{E}{E_{cut}}\right)
\end{equation}
and varies only in normalisation (see Sect.~\ref{sect:minimal_cascade} for the details on the chosen spectral shape parameters).

To simulate the secondary emission for 1ES~0229+200\ with CRPropa we have assumed the source distance of $\mathrm{D_s = 580}$~Mpc (corresponding to the sources' redshift of $\mathrm{z\approx0.14}$) and recorded all photons injected within a $\mathrm{10^\circ}$ cone, arriving to the sphere of the same radius $\mathrm{r=D_s}$ and centered on the source. CMB and the far infrared backgrounds~\cite[model from][]{Franceschini08} served as the target fields for both $\gamma$-ray\ photon absorption and Inverse Compton scattering of the created secondary $\mathrm{e^+ / e^-}$ pairs. All particles were traced with the required relative integration step accuracy of $\mathrm{\epsilon = 10^{-12}}$ and a minimal step size of $\mathrm{\Delta d = 10^{14}}$~cm, which are sufficient to reproduce time delays with an accuracy better than 1~day.

\section{Analysis results}
\label{sect::analysis_results}

\subsection{Spectrum and light curve}
\label{sect::analysis_spectrum_lightcurve}

Spectral energy distribution and light curves of 1ES~0229+200\ in the GeV-TeV energy range, obtained here, are shown in Fig.~\ref{fig:spectrum} and Fig.~\ref{fig:lightcurve} (see Sect.~\ref{sect:lightcurve_modelling} for full description), respectively, along with the archival measurements from H.E.S.S.~\citep{HESS_1ES0229} and VERITAS~\citep{VERITAS_1ES0229}.

The joint \textit{Fermi}/LAT\  and MAGIC spectrum is well described by a simple EBL-absorbed power law with cut-off model  ($\mathrm{\chi^2=2.5 / 8~\mathrm{d.o.f.}}$) with best-fit intrinsic values of $\mathrm{\Gamma = 1.72 \pm 0.05}$ and $\mathrm{E_{cut} > 2.6}$~TeV at 95\% confidence level.
In general, MAGIC, H.E.S.S. and VERITAS spectra in the $\mathrm{0.1-10}$~TeV energy range agree well with each other in shape, though differ in normalisation. The joint spectrum (including \textit{Fermi}/LAT\  measurements) is still described well with the same simple spectral model  ($\mathrm{\chi^2=14.2 / 22~\mathrm{d.o.f.}}$) with a compatible spectral index $\mathrm{\Gamma = 1.74 \pm 0.07}$ and a larger cut-off energy  ($\mathrm{E_{cut} > 10}$~TeV at 95\% confidence level).

\begin{figure}
    \includegraphics[width=\linewidth]{spectrum}
    \caption{Spectral energy distribution of 1ES~0229+200\ in the 100~MeV -- 100~TeV energy range. \textit{Fermi}/LAT\  and MAGIC data were obtained here; H.E.S.S and VERITAS measurements are taken from \citet{HESS_1ES0229} and \citet{VERITAS_1ES0229} correspondingly.}
    \label{fig:spectrum}
\end{figure}

The source's light curve below $\mathrm{\sim 100}$~GeV from \textit{Fermi}/LAT\  data does not indicate any significant time variability of the flux. On the contrary, the TeV band measurements from H.E.S.S., VERITAS and MAGIC suggest a notable variations with respect to the mean flux by a factor of $\mathrm{\sim 2}$. The flux is variable on the time scales of $\mathrm{\sim 500}$~days with several brightening and dimming episodes identifiable. The significance of this variability was assessed from a joint $\mathrm{\chi^2}$ fit of H.E.S.S., VERITAS and MAGIC light curves, using an EBL-absorbed power law with cut-off spectral model to compute the fluxes in the respective energy bins. The parameters of the model were left free in the fit. In addition, a 11\% point-to-point systematical uncertainly, characteristic for MAGIC~\citep{MAGIC_performance}, and a 25\% inter-instrument calibration uncertainty (corresponding to a typical $\mathrm{\sim 15\%}$ uncertainty on the IACT energy scale and a power law source spectrum with the measured index $\mathrm{\Gamma=2.6}$ -- similar to that of 1ES~0229+200\, after absorption on EBL) were also accounted for. This joint fit results in $\mathrm{\chi^2 = 47/11}$~d.o.f., which rejects the constant flux assumption at the $\mathrm{4.8\sigma}$ level. MAGIC data alone, with monthly binning, hint the variability at a marginal $\mathrm{2.7\sigma}$ level  ($\mathrm{\chi^2 = 14.2 / 4~\mathrm{d.o.f.}}$) when the measurement systematical uncertainty is taken into account. Estimated fractional variability and corresponding $\mathrm{\chi^2}$ contributions to the joint fit are given in Tab.~\ref{tab::variability_summary}.

\begin{table}
    \centering
    \begin{tabular}{ccccc}
        \hline
        Name & $\mathrm{\chi^2}$ & $\mathrm{F_{var}}$ & $\mathrm{N_{points}}$ & Scale \\
        \hline
        H.E.S.S. & 22.0 & $\mathrm{0.31 \pm 0.04}$ & 8 & $\mathrm{0.85 \pm 0.23}$ \\
        MAGIC & 16.7 & $\mathrm{0.43 \pm 0.07}$ & 5 & $\mathrm{1.00}$ (fixed) \\
        VERITAS & 8.6 & $\mathrm{0.35 \pm 0.11}$ & 3 & $\mathrm{1.27 \pm 0.18}$ \\
        \hline
    \end{tabular}
    \caption{Summary of the variability study with IACT data, estimated from their joint fit with the exponentially cut off power law model. $\mathrm{F_{var}}$ denotes the fractional variability~\citep{Fvar_definition}, $\mathrm{N_{points}}$ is the corresponding light curve points counts, ``Scale'' represents the scaling parameter applied to the flux values in order to account for the possible inter-instrument systematics (arbitrarily fixed to unity for MAGIC data). Best-fit spectral parameters were $\mathrm{\log_{10}A=-22.51 \pm 0.24~\mathrm{dex(1/(eV~cm^2~s))}}$, $\mathrm{\Gamma = 1.25 \pm 0.29}$, $\mathrm{E_0=100~\mathrm{GeV}}$, $\mathrm{\log_{10}E_{cut}=13.99 \pm 1.50~\mathrm{dex(eV)}}$. Note that these parameters were determined without an account for the measured source SED shape (using only flux measurements in the corresponding energy bins) and thus differ from those using in the cascade emission modelling performed further.
    See Sect.~\ref{sect::analysis_spectrum_lightcurve} for details.}
    \label{tab::variability_summary}
\end{table}

\begin{figure}
    \includegraphics[width=\linewidth]{lightcurve_l=1e+00_Mpc_b=1e-16_G_v2.pdf}
    \caption{Light curve of 1ES~0229+200\ in several energy bands along with an exemplary fit with IGMF of strength of $\mathrm{B=10^{-16}}$~G and coherence scale of $\mathrm{\lambda_B = 1}$~Mpc. Top panel represents the best-fit model light curve (along with its uncertainties), used to make the predictions in the energy bands where the measurements were taken (the panels below). \textit{Fermi}/LAT\  and MAGIC data are reported in the text; H.E.S.S. and VERITAS measurements are taken from~\citet{HESS_VERITAS_lightcurves} and~\citet{VERITAS_1ES0229} correspondingly. The primary, cascade and total source fluxes are denoted with green triangles, orange squares and red circles correspondingly. Solid and dashed lines represent calculations with CRPropa~\citep{CRPropa} and CRbeam~\citep{Berezinsky:2016feh} Monte Carlo codes respectively; the latter use the small point-like markers to distiguish themselves.}
    \label{fig:lightcurve}
\end{figure}

\subsection{Minimal expected cascade estimate}
\label{sect:minimal_cascade}

Following the arguments of \citet{Neronov10}, a conservative lower bound on the IGMF strength should be based on the minimal  possible cascade contribution allowed by the data -- e.g. the softest intrinsic spectrum with the lowest cut-off
\begin{equation}
\frac{dN}{dE} = A \left(\frac{E}{E_0}\right)^{-\Gamma_{low}} \exp\left(-\frac{E}{E_{cut}^{low}}\right).
\end{equation}
In order to estimate the values of $\mathrm{\Gamma_{low}}$ and $\mathrm{E_{cut}^{low}}$ we fitted the GeV-TeV spectrum of the source, scanning the $\mathrm{\Gamma-E_{cut}}$ space by means of $\mathrm{\chi^2}$. In the scan we have combined the GeV data from \textit{Fermi}/LAT\  and TeV measurements of MAGIC, H.E.S.S. and VERITAS. Each spectrum was allowed to have a different normalisation during the fit, accounting for variability of the source. For each combination of $\mathrm{\Gamma-E_{cut}}$ we also computed the expected cascade power in terms of the total absorbed flux. This allows us to select the intrinsic spectrum parameters that lead to the minimal possible cascade contribution in the $\mathrm{\lesssim 100}$~GeV energy band.

The outcome of this scan is shown in Fig.~\ref{fig:Ecut_scan}. The best $\mathrm{\chi^2}$ values correspond to $\mathrm{E_{cut} \gg 10}$~TeV and a hard spectrum with $\mathrm{\Gamma \approx -1.70}$. Still, at a 90\% confidence level the lowest cascade flux is provided by the intrinsic source spectrum with $\mathrm{\Gamma_{low} \approx -1.72}$ and $\mathrm{E_{cut}^{low} \approx 6.9}$~TeV (in the observer reference frame, otherwise it should be corrected for the source redshift by a factor of $\mathrm{[1+z]}$).

\begin{figure}
\includegraphics[width=\linewidth]{1ES0229_Ecut_scan}
\caption{The scan of the cascade power in the $\mathrm{\Gamma-E_{cut}}$ parameter space along with the 68\% and 90\% confidence contours from the $\mathrm{\chi^2}$ fit. At 90\% confidence level the minimal cascade, marked with the yellow dashed lines, corresponds to $\mathrm{\Gamma \approx 1.72}$ and $\mathrm{E_{cut} \approx 6.9}$~TeV.}
\label{fig:Ecut_scan}
\end{figure}

\subsection{Light curve modelling with account of IGMF}
\label{sect:lightcurve_modelling}

To model the GeV-TeV light curves, we used the model introduced in Sect.~\ref{sect:numeric_modelling}. For each IGMF configuration (i.e. strength and coherence length) we performed a fit of all H.E.S.S., VERITAS, MAGIC and \textit{Fermi}/LAT\  light curves together. This combination of TeV and GeV data allowed to self-consistently estimate the ``primary'' and ``delayed'' flux contribution in each time and energy bin.

In our "minimal cascade" modelling we assumed zero intrinsic source flux before $\mathrm{\mathrm{MJD} = 53000}$ (just before the first H.E.S.S. flux data point in Fig.~\ref{fig:lightcurve}). Non-zero flux at $\mathrm{\mathrm{MJD}~<~53000}$ would produce extra cascade flux during the observation time span $\mathrm{\mathrm{MJD}~>~53000}$. In addition, we have used the $\mathrm{\Gamma}$ and $\mathrm{E_{cut}}$ values that minimize the expected delayed contribution, estimated in Sect.~\ref{sect:minimal_cascade}. The constructed model is the most conservative with respect to the IGMF constraints.

The "minimal cascade" model is not free from uncertainties e.g. on the source jet orientation and opening angle. The characteristic delay of the off-centre emission of 1ES~0229+200\ is $\mathrm{T_{d} \simeq 1 \left( \theta / 10^{-3}~\mathrm{deg} \right)^2~\mathrm{yr}}$ (with $\mathrm{\theta}$ being the offset angle); this value is set by the geometry of the $\mathrm{e^+ / e^-}$ pairs deflection and is independent from the IGMF configuration. For the time delays allowed to be probed by the data at hand -- below $\mathrm{\approx 16}$~years -- the characteristic off-centre angle of the delayed secondary emission would be $\mathrm{\lesssim 4 \times 10^{-3}}$~deg -- much less than PSF of the considered instruments or a typical opening angle of AGN jets.

The result of the IGMF strength scan, assuming a randomly oriented IGMF with a coherence scale in the range $\mathrm{\lambda_B=10^{-3} - 1}$~Mpc, is shown in Fig.~\ref{fig:igmf_scan}. For IGMF strengths below $\mathrm{\sim 10^{-18}}$~G the secondary emission suffers minimal lag (below $\mathrm{\sim 1}$~yr), so that there is almost no suppression due to the time delay. For IGMF stronger than $\mathrm{\sim 10^{-16}}$~G the time delay is large enough to suppress the secondary emission well below the expected primary one, so that the model light curves at GeV energies start to simply mirror the variability at higher-energy, TeV spectrum end. The minimal $\mathrm{\chi^2}$ value here represents the ability of the constructed model to reproduce the short time scale  ($\mathrm{< 400}$~days) variability of 1ES~0229+200, suggested by the data points in Fig.~\ref{fig:lightcurve}.
\begin{figure}
    \includegraphics[width=\linewidth]{IGMF_strength_scan_v2.pdf}
    \caption{IGMF strength scan for several different assumed coherence lengths $\mathrm{\lambda_B}$. The scan is performed via a simultaneous fit of GeV-TeV observations at hand. Calculations with both CRPropa~\citep{CRPropa} and CRbeam~\citep{Berezinsky:2016feh} Monte Carlo codes are presented. Lines of different colors depict the $\mathrm{\chi^2}$ values estimated for different non-zero IGMF strengths. Black solid line represents the case of zero IGMF, in case of which secondary emission dominates in the \textit{Fermi}/LAT\  energy range; black dashed line represent the reference fit with the cascade contribution disabled.}
    \label{fig:igmf_scan}
\end{figure}

This scan in Fig.~\ref{fig:igmf_scan} indicates that with very few assumptions made here, the IGMF is constrained to have strength $\mathrm{B \gtrsim 1.8\times 10^{-17}}$~G at 95\% confidence level (corresponding to $\mathrm{\Delta \chi^2 \approx 2.71}$ from the the minimal $\mathrm{\chi^2}$ value).

The scaling of the above constraint with the IGMF correlation length is set by the cooling distance of the injected electrons and positrons and for randomly oriented IGMF cells can be derived analytically~\citep{NeronovSemikoz09}. The cooling distance of $\mathrm{e^+ / e^-}$ pairs (due to radiative loss through inverse Compton scattering) is
\begin{equation}
  l_{IC}\simeq 160\left[\frac{E_{IC}}{3\mbox{ GeV}}\right]^{-1/2}\mbox{ kpc}
\end{equation}
for electrons and positrons up-scattering CMB photons to the energy $\mathrm{E_{IC}}$. The scan performed above is most sensitive to the delayed emission contribution in the lowest energy 1-10~GeV light curve. This suggests that the derived lower limit holds for IGMF coherence scales $\mathrm{\lambda_B > 0.2~\mathrm{Mpc}}$ and scales for shorter correlation lengths as $\mathrm{\lambda_B^{1/2}}$, so that it can be summarised as:
\begin{equation}
    B \gtrsim \left\{
    \begin{array}{lr}
        1.8 \times 10^{-17}~\mathrm{G} &, \lambda_B > 0.2~\mathrm{Mpc} \\
        1.8 \times 10^{-17} \left( \lambda_B / 0.2~\mathrm{Mpc} \right)^{-1/2}~\mathrm{G} &, \lambda_B < 0.2~\mathrm{Mpc} \\
    \end{array}
    \right.
    \label{eq::igmf_limit}
\end{equation}
This conclusion is supported by the scan of the simulated $\mathrm{\lambda_B~<~1}$~Mpc cases that we performed.

Worthy to note that the presented analysis does not favour a specific value of $\mathrm{B}$ or $\mathrm{\lambda_B}$ as every IGMF satisfying the limit in Eq.~\ref{eq::igmf_limit} would result in the same secondary flux time delay. This degeneracy, in principle, can be broken if an accurate measurement of the cascade flux time evolution is obtained~\citep{Neronov13}; in the absense of such a firm detection, we are not in a position to do this here.

\subsection{Effect of the possible spectral variations}

The assumption of the fixed source spectral shape, used here, may not be justified if 1ES~0229+200\, spectral shape varies over the 14 years of \textit{Fermi}/LAT\, observations. However, no indications for its change have been found in earlier H.E.S.S. and VERITAS data with possible spectral index variations $\mathrm{\Delta \Gamma \lesssim 0.2}$~\citep{HESS_1ES0229, VERITAS_1ES0229}; we have not found such indications in the MAGIC data either. Such small variations do not have a noticeable impact on the derived IGMF bound value.

Still, given the lower source flux during the MAGIC observations~(see Fig.~\ref{fig:lightcurve}), the cut-off energy is poorly constrained for time period MJD~$56500-58000$ and may be substantially lower than the assumed $\mathrm{E_{cut}^{low} \approx 6.9}$~TeV. Conservatively assuming that no detectable cascade was thus generated during the MAGIC observations, we have found that lower limit on IGMF strength is relaxed to $\mathrm{B\gtrsim 6\times 10^{-18}}$~G for $\mathrm{\lambda_B > 0.2~Mpc}$.

\section{Discussion and conclusions}
\label{sect::discussion}

A range of lower bounds on the IGMF strength has been previously reported based on non-observation of delayed emission in the 1-100 GeV band, assuming that the TeV sources remain active on year-to-decade time scales \citep{dermer11,Taylor11,Vovk12,fermi_limit}\footnote{Note that the difference between the lower bounds derived by \citet{dermer11} and \citet{Taylor11}, $\mathrm{10^{-18}}$~G and $\mathrm{10^{-17}}$~G is due to more precise modelling of the cascade emission by \citet{Taylor11} (Monte Carlo) compared to  \citet{dermer11}  (approximate analytic model).}. An important limitation of all previously reported bounds is that none of the previously reported analyses used strictly contemporaneous monitoring of the source in the 1-100 GeV and TeV bands.

The bound derived in the present paper is based on a combination of long-term simultaneous monitoring  of 1ES~0229+200\ in the 1-100 GeV energy range with \textit{Fermi}/LAT\  and in the $\mathrm{E>200}$~GeV range with Cherenkov telescopes: H.E.S.S., VERITAS and MAGIC. This combination alleviates for the first time the dependence of the bound on an uncertainty related to possible variability of the TeV band source flux. This makes the bound more robust and almost free from uncertainties of the intrinsic primary source flux variability.

We would like to note that a certain fraction of the deposited electron-positron power may be carried away via plasma instabilities, developing as a result of interaction between the generated particle stream and the intergalactic medium~\citep{broderick12}. Such instabilities may mimic the effect of IGMF, reducing the expected cascade flux. Presently there is no self-consistent description of the problem given the large density gradient between the stream and surrounding plasma, so that conclusions on its importance for the IGMF measurements vary substantially depending on the assumptions adopted~\citep{broderick12, miniati13, chang14, shalaby18, vafin18, vafin19, batista19, perry21}. Furthermore, the instability development may be affected by the source emission lifetime~\citep{broderick12} and by IGMF itself~\citep{alawashra22}. Given these uncertainties, a quantitative analysis of this issue is beyond the scope of this work.

Fig.~\ref{fig:exclusion} puts our bound in the context of other measurements and theoretical models of IGMF. The cosmological evolution of magnetic fields which might have been present in the Early Universe drives the field strength and correlation length toward
\begin{equation}
    B_{\mathrm{cosmological}}\simeq 10^{-8}\left(\frac{\lambda_B}{1\mbox{ Mpc}}\right)\mbox{ G}
    \label{eq::cosmological_igmf}
\end{equation}
shown by the inclined orange band in Fig.~\ref{fig:exclusion} \citep{banerjee, Durrer13}. Non-observation of Faraday rotation of the radio waves polarization from distant active galactic nuclei and of magnetic field imprint on the cosmic microwave background constrains the IGMF strength from above for large $\mathrm{\lambda_B}$ \citep{kronberg, Durrer13}. $\gamma$-ray\ observations reported here constrain the field from below. For the particular case of cosmological magnetic field, equating Eqs.~\ref{eq::igmf_limit} and~\ref{eq::cosmological_igmf} we find
\begin{equation}
    B_{\mathrm{cosmological}} \gtrsim 10^{-14}\mbox{ G.}
\end{equation}

The bound derived here (Eq.~\ref{eq::igmf_limit}) is weaker than that reported by \citet{fermi_limit} based on the stacking analysis of a number of blazars. However one should note that the effect of the IACT and \textit{Fermi}/LAT\  energy scale calibration uncertainties relaxes that bound threefold~\citep{fermi_limit}. Moreover, the IGMF limit presented here is based on a prior conservative estimate of the intrinsic 1ES~0229+200\ spectrum, aimed at minimizing the expected cascade regardless of IGMF. Finally, the bound of  \citet{fermi_limit} was relying on a strong assumption about properties of the TeV band $\gamma$-ray\ fluxes of the stacked sources, rather than on real measurements of the TeV flux. In contrast, the bound reported here is free from this assumption. Instead, it relies on precise measurements of the flux history of the source in the GeV-TeV energy range.

The robust lower bound on IGMF strongly constrains a range of testable models of cosmological magnetogenesis -- and specifically the models of magnetic field production at / before the electroweak phase transition (EWPT) in the hot Universe at the temperature close to $\mathrm{T\sim 100}$~GeV, during the first nano-second after the Big Bang~\citep[see][and references therein]{NeronovSemikoz09,Durrer13}.  These models are particularly interesting in the context of the problem of the origin of baryon asymmetry of the Universe (BAU). It is possible that the BAU has been generated through the transfer of hypermagnetic helicity to the baryon number at the moment of EWPT~\citep{shaposhnikov98,fujita16,kamada16}. If this is the case, the hypermagnetic field should have been present in the Universe before the EWPT, when the temperature was still higher. This is possible, for example, through the ``chiral dynamo'' magnification of thermal fluctuations of hypermagnetic field at temperatures $\mathrm{T>80}$~TeV \citep{joyce,neronov20}. Estimates of possible initial parameters of the cosmological hypermagnetic field at the moment of chiral dynamo action are shown by the red stripe in Fig.~\ref{fig:exclusion}. At the moment of the EWPT the chiral dynamo field parameters fall into a range of fields needed for successful BAU generation~\citep{fujita16,kamada16}. Subsequent evolution of the field to the present epoch results in the cosmological fields with strength from $\mathrm{\sim 10^{-15}}$~G to $\mathrm{\sim 5\times 10^{-14}}$~G, close to the lower bound derived here.

The analysis presented above indicates that the chiral dynamo magnetic field, possibly responsible for BAU, can be measured using the technique of the search of time-delayed emission in the signal of extragalactic sources of TeV $\gamma$ ray s. In the specific case of sources at the redshift $\mathrm{z\sim 0.1}$ similar to that of 1ES~0229+200, detection of the $\mathrm{\sim 10}$~yr delayed signal requires systematic monitoring of the sources in both the TeV and in 1-100~GeV bands.

Shorter time delays are expected at higher energies, because the delay time shortens as $\mathrm{1/E_\gamma^2}$~\citep{NeronovSemikoz09}. In the specific case of 1ES~0229+200\ it goes down to $\mathrm{\sim 1}$~yr at $\mathrm{100}$~GeV. This opens a possibility of detection of the BAU-related magnetic field through regular monitoring of source variability at intra-year time scale with Cherenkov telescopes. Detection of a specifically energy-dependent ``afterglow'' of a bright short pronounced flare of the source would be a ``smoking gun'' of the effect in question. Unfortunately, 1ES~0229+200\ does not exhibit intense flaring episodes. Other candidate sources could be considered for this approach. A necessary condition is that the candidate sources should have strong intrinsic luminosity above 10~TeV~\citep[the energy of primary $\gamma$ ray s which induce cascade emission at 100~GeV, ][]{NeronovSemikoz09}. Measurement of such time delays through long-term monitoring is challenging, but not impossible with existing and planned $\gamma$-ray\ observation facilities including \textit{Fermi}/LAT\ ~\citep{FermiLAT}, CTA~\citep{cta} and HERD~\citep{herd}.

\begin{figure}
\includegraphics[width=\linewidth]{IGMF_constraints.pdf}
\caption{Lower bound on IGMF strength derived from \textit{Fermi}/LAT\  and Cherenkov telescope data sets (thick blue curve and red data points). Green dot-dashed and dashed curves show previous \textit{Fermi}/LAT\  limits derived for the full source sample and 1ES~0229+200\ only~\citep{fermi_limit}. Light-grey shaded upper bound shows previously known limits on the IGMF strength and correlation length from radio telescope data  \citep{kronberg} and CMB~\citep{planck} analysis as well as from theoretical estimates~\citep{Durrer13}. Inclined orange stripe shows the locus of end points of evolution of cosmological magnetic fields~\citep{banerjee}. Red stripe marks possible range of magnetic field produced by the chiral dynamo~\citep{joyce,neronov20}. Dark green stripe denotes the range of electroweak phase transition magnetic fields which might explain the observed baryonic asymmetry of the Universe ~\citep{shaposhnikov98,fujita16,kamada16}. Filled vertical green and violet boxes show favored regions of IGMF generated by a frozen-in magnetic field, originating from AGN outflows~\citep{Furlanetto:2001} or galactic winds~\citep{Bertone:2006} as labelled in the figure.}
\label{fig:exclusion}
\end{figure}

\begin{acknowledgements}
We would like to thank the Instituto de Astrof\'{\i}sica de Canarias for the excellent working conditions at the Observatorio del Roque de los Muchachos in La Palma. The financial support of the German BMBF, MPG and HGF; the Italian INFN and INAF; the Swiss National Fund SNF; the ERDF under the Spanish Ministerio de Ciencia e Innovaci\'on (MICINN) (PID2019-104114RB-C31, PID2019-104114RB-C32, PID2019-104114RB-C33, PID2019-105510GB-C31,PID2019-107847RB-C41, PID2019-107847RB-C42, PID2019-107847RB-C44, PID2019-107988GB-C22); the Indian Department of Atomic Energy; the Japanese ICRR, the University of Tokyo, JSPS, and MEXT; the Bulgarian Ministry of Education and Science, National RI Roadmap Project DO1-400/18.12.2020 and the Academy of Finland grant nr. 320045 is gratefully acknowledged. This work was also supported by the Spanish Centro de Excelencia ``Severo Ochoa'' (SEV-2016-0588, SEV-2017-0709, CEX2019-000920-S), the Unidad de Excelencia ``Mar\'{\i}a de Maeztu'' (CEX2019-000918-M, MDM-2015-0509-18-2) and by the CERCA program of the Generalitat de Catalunya; by the Croatian Science Foundation (HrZZ) Project IP-2016-06-9782 and the University of Rijeka Project uniri-prirod-18-48; by the DFG Collaborative Research Centers SFB823/C4 and SFB876/C3; the Polish National Research Centre grant UMO-2016/22/M/ST9/00382; and by the Brazilian MCTIC, CNPq and FAPERJ.
\end{acknowledgements}

{
    \tiny
    \noindent \textit{Author contributions}
    Ie.Vovk: methodology, simulations, Fermi/LAT and MAGIC data reduction/analysis, statistical analysis;
    A.Neronov: methodology;
    P. Da Vela: MAGIC data analysis;
    A.Stamerra: project supervision, coordination of MAGIC observations, MAGIC data analysis;
    D.Semikoz: interpretation;
    A.Korochkin: simulations, statistical analysis.
    The rest of the authors have contributed in one or several of the following ways: design, construction, maintenance and operation of the MAGIC telescopes; preparation and/or evaluation of the observation proposals; data acquisition, processing, calibration and/or reduction; production of analysis tools and/or related Monte Carlo simulations; discussion and approval of the contents of the draft.

}