AQUA - A Modular Authentication Quality Modeling Framework

Introduction

Security controls are central to securing software systems. They are countermeasures that protect a software system’s confidentiality, integrity, and availability [1]. Examples are authentication and Distributed Denial-of-Service (DDoS) prevention. The key design, architectural, and implementation choices made to realize a security control are known as a security solution [2].

Security solutions exhibit quality properties, such as usability and performance. However, they vary significantly depending on the security control they implement. For example, security solutions for authentication focus on how users can securely authenticate within a system [3]; security solutions for DDoS prevention focus on load balancing and blocking suspicious traffic [4]. Comparing the usability of an authentication solution with that of a DDoS-prevention solution makes little sense, as they depend on entirely different factors. To elaborate on the relationship between quality and security solutions, we thus need to focus on a specific class of security solutions. We focus on authentication, as it is one of the most widely used security controls [5]. Moreover, authentication failures rank 7th on the OWASP¹ Top Ten list [6], the de facto standard for security risks in web applications, underlining the need to understand what determines the quality of authentication solutions.

Background: Authentication is the process by which a subject—in the following referred to as the user—gives proof of the identity they claim using one or more authenticators [3]. An authenticator is the entity that a user controls and possesses to prove their identity, such as a password or fingerprint [5]. We refer to the key design, architectural, and implementation choices made to realize authentication as an authentication solution.

Authentication solutions, being security solutions, exhibit quality properties. For example, password-based authentication is less secure than passkey-based authentication [7], and multi-factor authentication (MFA) solutions are more secure but tend to be less usable than single-factor authentication solutions [8]. While such comparisons may seem obvious (MFA requires at least two authenticators, which implies a negative effect on usability), the root causes of these qualitative characteristics are less obvious. Some effects stem from using multiple authenticators, others from inherent properties of the authenticator (a passkey is more secure than a password because it prevents users from choosing weak passwords), and still others from the technical implementation (a solution that enforces a strong password is more secure than one without password-strength policies).

Problem Statement: Researchers have studied the relationship between authentication and quality extensively, but they use inconsistent terminology, a well-known problem in the security field [9]. For example, some examine the quality of authentication schemes [10], others that of authentication methods [11] or mechanisms [12], and still others that of authentication in general [13]. It remains unclear whether these refer to the same quality, since the differences between an authentication scheme, method, and mechanism, and how each relates to authentication in general, are not defined. This ambiguity makes results hard to compare across studies.

A second, deeper problem is that existing models do not distinguish whether a quality effect stems from the authenticator, from the way authenticators are employed, or from the concrete implementation. This makes it impractical to trace how quality propagates from the authenticators through their employment to the solution as a whole, and thus to explain why a solution has the quality it has. For example, how does the usability of an MFA solution that uses a fingerprint and a hardware one-time-password (OTP) token compare with one that uses a short PIN and voice recognition? Answering this requires knowing which effects come from each authenticator, which come from combining them, and which come from the technical realization. To assess such nuances, we need tailored quality models that capture the different facets of what makes an authentication solution and how each facet affects its quality. Such models could help architects make well-informed decisions, compare solution alternatives by their estimated quality, and allow automated quality assessment of authentication solutions in a system. To our knowledge, no such quality model exists.

Contribution: To close this gap, we developed AQUA, a modular quality modeling framework for authentication solutions. AQUA decomposes authentication into four interrelated concepts: the authenticator (the entity a user possesses or controls to perform authentication, e.g., a password), the authenticator employment (a composition scheme for authenticators), the authentication technique (the concrete composition of authenticators under an authenticator employment), and the authentication solution (the concrete design, architecture, and implementation that realizes a technique). This decomposition separates the three sources of quality effects identified above: the properties inherent to an authenticator, the effects of how authenticators are combined, and the effects of the concrete implementation.

Therefore, our key contribution is not another security quality model, but a quality modeling framework that enables the development of tailored, modular quality models for authentication solutions by ensuring that the conceptual separation of key authentication concepts is maintained. It clearly distinguishes itself from related quality evaluation and modeling approaches [10, 11, 13], as no approach we know of accounts for this conceptual distinction.

We demonstrate AQUA through three initial quality models: AQUA-A for authenticators, AQUA-T for authentication techniques, and AQUA-S for authentication solutions. Moreover, we show how quality propagates from inherent authenticator properties, through their use in a technique, to their realization in a solution, using an example usability metric. The following research question underlies this study:

RQ: How can a quality modeling framework for authentication solutions be designed that captures how quality propagates from the authenticators through their employment to the solution?

Methodology & Outline

This is a Design Science Research (DSR) study [14], as we develop a research artifact (AQUA). The six DSR steps are mapped to our study as follows: (1) The problem was identified, and a solution was motivated as presented above. (2) The research objective is reflected by the research question. (3) We developed, verified, and refined the Aqua conceptual model step by step. To verify the model’s internal consistency and expressiveness, we formalized the concepts. This confirmed that the model can represent single-factor, multi-factor, and adaptive authentication, including nested compositions. (4) AQUA’s demonstration has two parts: First, we demonstrate each concept and how it relates to quality with comprehensive examples, including metrics. Second, we present three quality models for these concepts that we developed with AQUA. (5) Due to the early stage of this project, a comprehensive evaluation is missing; we address it in future work. (6) Communication is done via scientific publications.

Section 2 presents related work. In Section 3, the conceptual decomposition of authentication on which the AQUA framework is built is introduced. Next, Section 4 presents their relationship to quality, including demonstration examples. In Section 5 we demonstrate AQUA using initial quality models we built with it. Section 6 concludes this paper.

Related Work

Quality models are established for modeling security quality by hierarchically structuring security into more detailed factors and subfactors (e.g., [13, 15, 16]). Some studies also address specific quality factors in the context of authentication. Bonneau et al. [10] propose a comparison framework of web authentication schemes based on usability, deployability, and security. Furnell et al. [11] address the accessibility of authentication methods. Both studies provide important insights into the specificity of authentication-related quality as well as into possible approaches for evaluating these quality factors. Our approach differs from all approaches we know of because it holistically models authentication quality through a modular decomposition of authentication concepts. This makes it possible to trace the effects of various design decisions on quality back to the conceptual components of authentication.

AQUA builds on our prior work. In [17], we identified the relationships between the concepts on which AQUA is based and showed that these can be treated as distinct first-order concepts. In that paper, we also identified the quality dimension as a limitation and a direction for future work. In [18] we proposed an authentication pattern catalog. Patterns in software engineering encapsulate qualitative aspects through their forces and consequences. AQUA incorporates our insights from both papers and synthesizes them into a holistic quality modeling framework for authentication.

The Aqua Framework

As introduced above, AQUA decomposes authentication into four interrelated concepts. This modular decomposition enables flexible, adaptable authentication solutions based on the authenticators and how they are used. This section presents the decomposition. Figure 1 depicts AQUA’s concept model.

Vector (PDF)

Authenticator

An authenticator represents the most fundamental part of authentication. It is the entity a user possesses, controls, and uses to perform authentication. In AQUA, an authenticator denotes the type level, e.g., a password or a fingerprint; its instances are concrete authenticators.

Examples:

1. A password ($pw$), fingerprint ($fp$), iris ($ir$), PIN ($pin$) and one-time password ($otp$) are authenticators. These authenticator abbreviations will be used in the remainder of the paper.

2. Alice’s $pw$ “PWD123!” and Bob’s $fp$ are concrete authenticators.

Authenticator Employment

Many authentication solutions do not use a single authenticator, but compose several authenticators together. The way they are composed matters independently of which authenticators are used. For example, “first use a $pw$ then use a $fp$” and “first scan the $ir$, then use a $pin$” reveal the same structural feature: the sequential use of two different authenticators.

To capture this structural composition, we define the authenticator employment. An authenticator employment is a composition scheme for authenticators. To stay independent of concrete authenticators, it is built on “slots”. A slot is a place that awaits exactly one authenticator. An employment specifies how many slots there are (cardinality) and how they are used together (mode and order). The authentication technique, defined in § 3.3, determines which authenticator goes into which slot.

An employment’s cardinality is the number of slots it specifies; its order is the position of each slot from left to right. The simplest employment specifies exactly one slot, i.e., has a cardinality of one. We refer to it as single employment. A single employment models single-factor authentication [19]. Employments with cardinality $> 1$ are multi employments. In addition, they define a mode. The mode specifies how the authenticators assigned to its employment slots are used together.

We distinguish between three modes that multi employments can specify:

• Sequential employment ($E_{seq}$): All slots are used, one after the other, in a fixed order. Common MFA solutions use this mode [19].

• Simultaneous ($E_{sim}$): All slots are used at the same time. This is a common mode for many inherence-based techniques [17].

• Conditional ($E_{cond}$): Exactly one slot is used. The choice depends on a condition, such as the user’s environment or choice. Adaptive authentication uses this mode [20].

Nesting: The above modes can model all basic compositions of authenticators that use single employments. However, employments can also be nested. For example, the following models a valid composition: “authenticate first with a $pw$, then with either a $fp$ or a $pin$”.

We can achieve this by extending the mode concept with recursion. For each mode, we allow its arguments to be slots or, recursively, other multi employments, which we refer to as sub-employments. The modes then apply to arguments instead of slots: sequential and simultaneous employments use all arguments, and a conditional employment uses exactly one argument, which may itself be a sub-employment comprising several slots. We can model the above with a sequential employment that specifies a slot in its first position, followed by a conditional sub-employment with two slots.

Notation: We introduce the following formal notation for these concepts:

• We denote a slot by $\varepsilon$ and an arbitrary employment by $E$. A single employment, i.e., an employment with exactly one slot, is $E(\varepsilon)$.

• Let $X_1,\ldots,X_n$ with $n \ge2$ be slots or employments and $\mathit{mode} \in\{seq, sim, cond\}$. Then $E_{\mathit{mode}}(X_1,\ldots,X_n)$ is an employment. Those $X_i$ that are employments are its sub-employments. Its slots are the slots among the $X_i$ and the slots of the sub-employments, ordered from left to right.

• The cardinality $|E|$ is the number of slots $E$ specifies. $|E(\varepsilon)| = 1$, and the cardinality of $E_{\mathit{mode}}(X_1,\ldots,X_n)$ is the sum over its arguments, where each slot counts as one and each sub-employment $X_i$ counts as $|X_i|$.

Examples:

1. $E = E_{seq}(\varepsilon,\varepsilon)$ is a sequential employment with two slots, i.e., $|E| = 2$.

2. The aforementioned composition is modeled by $E = E_{seq}(\varepsilon,E_{cond}(\varepsilon,\varepsilon))$. $E$ has one slot and one sub-employment $E_{cond}$ with 2 slots, i.e., $|E| = 3$.

Authentication Technique

An employment specifies slots. These are independent of authenticators, i.e., each slot can be assigned an arbitrary authenticator. The authentication technique defines the concrete assignment of which authenticator is assigned to which slot. The authenticators are then used in the mode and order that the employment specifies.

For example, consider the employment $E_{seq}(\varepsilon,\varepsilon)$, specifying the sequential use of two authenticators. Assigning a $pw$ to the first slot and a $fp$ to the second slot yields the technique “first use a $pw$, then scan a $fp$”. Assigning a $pin$ and an $ir$ scan yields a different technique, “first $pin$, then $ir$”, conforming to the same employment.

Notation: $A$ denotes the set of authenticators, $a \in A$ an authenticator. Formally, an authentication technique is a pair $T=(E,(a_1,\ldots,a_k))$, where $E$ is an employment with cardinality $k$ and $a_i \in A$ is the authenticator assigned to the $i$-th slot of $E$.

While this notation is formally correct, as it defines which authenticator is assigned to which slot of an employment, it is not very readable. Thus, we introduce the substitution form of an authentication technique. In substitution form, an authentication technique $T$ is expressed as a term of an employment $E$ in which the $i$-th slot $\varepsilon$ is substituted by the $i$-th authenticator $a$ that $T$ assigns. For example, for $E=E_{seq}(\varepsilon,\varepsilon)$ and $T=(E,(pw,fp))$, we write

and read “technique $T$ authenticates a user using a $pw$ and a $fp$ in sequential order”. If the same authenticator is assigned to several slots, we mark the further occurrences with primes, e.g., $T := E_{seq}(pw,pw')$: both authenticators are the same, but can be instantiated by a different concrete authenticator.

Examples:

1. $T := E_{seq}(pw,fp)$ conforms to a sequential employment $E_{seq}(\varepsilon,\varepsilon)$, assigning a $pw$ first, then a $fp$.

2. $T := E_{cond}(pw,fp)$ conforms to conditional employment $E_{cond}(\varepsilon,\varepsilon)$, assigning a $pw$ for the first condition and a $fp$ for the second.

3. Consider the following setting: In a known environment, a user must first use a $pw$ and then either scan a $fp$ or use a $pin$. In an unknown environment, the user must first use a $pw$, then scan their $ir$, and then either type a $pin$ or provide an $otp$. The following employment $E$ models this:

and the following technique $T$ conforms to $E$:

Authentication Solution

The authentication technique reflects the conceptual approach for how authentication is performed: which authenticators are used, and in which mode and order. Its technical realization is an authentication solution. We align its definition with that of security solutions by NIST [2] as the key design, architectural, and implementation choices made to realize authentication. One such key design and architectural decision is what authentication technique an authentication solution implements.

For example, consider the two authentication techniques $T_1 := E_{seq}(pw,fp)$ and $T_2 := E_{seq}(pw,otp)$. The decision to implement $T_1$ rather than $T_2$ is a central design decision that significantly affects the overall authentication design and architecture: a secure password-based authentication solution must be designed [21]; users must have access to a fingerprint sensor; if necessary, appropriate sensors must be purchased, deployed, and maintained, etc. [22]. In contrast, choosing $T_2$ requires designing secure password-based authentication, along with a proper client-side or server-side OTP mechanism [23], and secret management and enrollment processes that differ from those required by a fingerprint solution [24]. In conclusion, the authentication technique reflects the conceptual solution, while the design decisions for password-based, fingerprint-based, and OTP-based authentication are made at the authentication solution level.

Notation: A solution implements a technique together with authenticator constraints and solution-specific design and implementation decisions. An example of a constraint is a minimum password length. Constraints are not within the scope of this paper and remain for future work. For design and implementation decisions, we omit a formal notation, as they are open-ended. Instead, we capture their consequences at the metric level. This will be described in detail in Section 4.3. We therefore only name the technique a solution $S$ implements, and write “$S$ implements $T$”.

Examples:

1. A single-factor authentication solution that uses a password for authentication implements $T := E(pw)$.

2. An MFA solution that uses a password as first factor and a client-side OTP as second factor implements $T := E_{seq}(pw, otp)$. The solution’s OTP mechanism is a design decision; we do not model it in this notation, but we capture its consequences at the metric level.

3. Two solutions can implement the same technique. For $T := E_{seq}(pw, fp)$, a solution $S_1$ implements $T$ as an Android app and a solution $S_2$ as a desktop app. They are different solutions that implement the same technique because they realize the technique on different platforms.

Quality Relationships

As shown in Figure 1, authenticators, authentication techniques, and authentication solutions have qualitative properties. These properties propagate from the authenticator, which resembles the atomic concept, to authentication techniques and then to authentication solutions. This is indicated by the depends on relationships. We illustrate this using the quality factor usability, focusing on a specific subfactor: the Ease of Use (EoU). It expresses the degree to which it is easy for a user to successfully authenticate with an authentication solution.

Authenticator Quality

To evaluate a solution’s EoU, we must first assess the authenticator’s EoU, since the authenticator is what a user uses to authenticate. Consequently, part of a solution’s EoU depends on the authenticators it employs.

For an authenticator, we define the EoU as “the degree of how easy an authenticator can be inherently used by a human for authentication purposes.” For illustration, we define a simple counting metric for EoU as the number of user interactions with an input device that an authenticator inherently requires to successfully authenticate a user. We divide 1 by this number to obtain a value on the scale $[0, 1]$, and interpret the metric such that the higher the value, the better the EoU:

Examples:

1. $\operatorname{EoU}(fp) = 1$, as it inherently enables authentication through a single touch.

2. $\operatorname{EoU}(pw) = 1/\ell_{pw}$, since without tool support such as key management tools, a $pw$ requires at least as many user interactions with an input device as the number of characters it consists of.

Authentication Technique Quality

An authentication technique influences a solution’s EoU through the authenticators and their employment. We define a technique’s EoU as “the degree to which all authenticators used can be easily utilized by a human for authentication purposes.” The fundamental quality depends on the authenticators. The employment determines the technique’s quality, since how the authenticators are used together affects the overall quality. To evaluate the technique’s quality, we must therefore examine how each employment influences that quality.

Single employments: The EoU of a single employment is simply that of the authenticator employed:

Sequential and simultaneous employments: The user must use all authenticators either sequentially or simultaneously. Since EoU counts interactions, not time effort, the number of user interactions adds up in both modes. As we divide 1 by the number of user interactions, we sum the reciprocals. A slot filled with an authenticator $a$ has the EoU of $a$. For slots or sub-employments $X_1,\ldots,X_n$:

This ensures that the result is always equal to or lower than the EoU of the least usable sub-employment; adding an authenticator can only worsen a technique’s EoU. This aligns with the common perception that MFA negatively affects usability [8].

Conditional employments: The user uses one sub-employment. Thus, the EoU of a conditional employment is that of the sub-employment used. For slots or sub-employments $X_1,\ldots,X_n$:

Examples:

1. For a technique $T := E(fp)$, it is $\operatorname{EoU}(T)=1$.

2. For a technique $T := E_{\mathrm{seq}}(pw,fp)$, it is $\operatorname{EoU}(T)=\frac{1}{1/\operatorname{EoU}(pw)+1/\operatorname{EoU}(fp)}=\frac{1}{\ell_{pw}+1}$.

   When $T$ is used with a concrete $pw$ with length $\ell_{pw}=9$, it yields $\operatorname{EoU}(T)=1/10=0.1$. When $T$ is used with a concrete $pw$ with length $\ell_{pw}=19$, it yields $\operatorname{EoU}(T)=1/20=0.05$. Thus, its EoU decreases with longer passwords, as expected.

3. For a technique $T := E_{\mathrm{cond}}(pw,fp)$, it is

4. For the nested technique $T$ from Example 3 in § 3.3,

We evaluate this bottom-up. Assume $\operatorname{EoU}(fp)=\operatorname{EoU}(ir)=1$, as both are biometric authenticators that allow authentication with a single interaction [18].

Moreover, assume $\ell_{pw}=9$, $\ell_{pw'}=19$, $\ell_{pin}=\ell_{pin'}=4$, and $\ell_{otp}=6$, treating PINs as short passwords and OTPs as single-use passwords [18]. Then, the innermost conditional employments yield:

Next, the sequential employments sum the interactions, and the outermost conditional employment selects one of them:

Thus, $T$ has four values, one for each combination of selected alternatives. The best case is more than twice as easy to use as the worst case, which a single number for the technique would hide.

Authentication Solution Quality

On the solution level, we define the EoU as “the degree to which the authentication solution as a whole can be easily used by a human for authentication purposes”. It is essentially determined by the EoU of the technique $T$ it implements, but the solution’s design and implementation decisions still affect the final value. Consider the technique $T := E_{\mathrm{seq}}(pw,fp)$ and two solutions implementing it: MFA-1 for an Android or iOS app; MFA-2 for a desktop app. For illustration, we assume that autofill and pasting of passwords are disabled.

Although both solutions implement $T$, their EoU differs. For MFA-1, the fingerprint sensor is integrated into the smartphone, so both authenticators are used on the same device. However, entering a password on a touchscreen is cumbersome and thus reduces usability [25]. For MFA-2, the $pw$ is entered on a standard keyboard, but most keyboards lack a fingerprint sensor, so the user must switch to another device. This affects the quality, as context switches reduce usability [26].

To account for such solution-specific factors, we introduce two variables analogous to effort multipliers in estimation models such as COCOMO [27]:

input factor $f_{in}$: reflects factors that simplify or complicate how authenticators are entered. Without such factors, $f_{in}=1$; simplifying factors give $f_{in}>1$, complicating factors $f_{in}<1$.

context switch disruption ($f_{cs}$): reflects how much usability is impaired by context switches. We rank them by: $f_{cs}=0$ no context switch required; $f_{cs}=0.1$ user must switch the application but not the device; $f_{cs}=0.2$ if the user must switch devices.

The EoU of a solution $S$ implementing $T$ can then be calculated by the formula on the scale $[0,1]$:

Examples: Consider $T := E_{seq}(pw, f_p)$, with $\operatorname{EoU}(T) = \frac{1}{\ell_{pw}+1}$, and two passwords $pw_A$ with $\ell_{pw_A} = 9$, $pw_B$ with $\ell_{pw_B} = 19$.

1. For MFA-1, we choose $f_{in} = 0.9$, due to the complicated password input, and $f_{cs} = 0$, as there is no context switch. It is $\operatorname{EoU}(\mathrm{MFA}\text{-}1) = \operatorname{EoU}(T) \cdot0.9$. For $pw_A$ it is 0.09; for $pw_B$ it is 0.045.

2. For MFA-2, we choose $f_{in} = 1$, as no input is complicated, and $f_{cs} = 0.2$, as the user must change devices. It is $\operatorname{EoU}(\mathrm{MFA}\text{-}2) = \operatorname{EoU}(T) \cdot0.8$. For $pw_A$ this yields 0.08; for $pw_B$ it is 0.04.

Given these illustrative metrics, MFA-1 has a better EoU than MFA-2. Note that this conclusion depends on the chosen values of $f_{in}$ and $f_{cs}$.

Summary: We showed by example that each first-order concept in the AQUA framework directly relates to quality, and that this quality propagates from the authenticator to the technique that employs it to the solution it implements: An authenticator affects a solution’s quality through its inherent properties; the technique affects it through the aggregation rules of the employment it conforms to; the solution affects it through design decisions made at the solution level. Lastly, the EoU example also shows that subfactors can be shared across concepts, with slightly different meanings. However, the sets of quality factors and subfactors are not equal. For example, privacy and its subfactors are defined at the solution level, as these qualities are affected by how a solution processes data.

Demonstration: Creating Quality Models with AQUA

To demonstrate the AQUA framework’s modeling capabilities, we developed initial, non-exhaustive quality models for authenticators, authentication techniques, and authentication solutions. To this end, we iteratively analyzed the qualitative properties of each concept, starting with the authenticator and ending with the authentication solution. We sought to describe each concept using a set of comprehensible quality properties specific to that concept. They were documented and structured based on the ISO SQuaRE model [28] into quality factors and subfactors. In this course, we focused on usability and security, given the extensive body of knowledge in these areas [10]. When defining the subfactors, we consistently verified whether each subfactor was inherent to the concept or to another.

The results are three interrelated quality models: AQUA-A for authenticators, AQUA-T for techniques, and AQUA-S for solutions. All models are definitional quality models, i.e., they do not include metrics. Moreover, they are not exhaustive and should be seen as clearly preliminary results. However, they illustrate the structure of quality models built in AQUA and the quality dependencies between them.

Figure 2 shows the three quality models at the quality factor level and the dependent quality factors. Figure 2 depicts the subfactors. The colors indicate which quality model the factors and subfactors belong to: red for AQUA-A; green for AQUA-T; blue for AQUA-S. As the dependent factors and subfactors read similarly, we do not depict most of them and share only the subfactors of AQUA-T’s security factor for illustration. The complete documentation of all AQUA models, including reasoning and an example for each subfactor, can be found on the AQUA webpage².

Vector (PDF)

Conclusions

This paper presents the AQUA framework. AQUA is a modular framework for modeling authentication quality. It decomposes authentication into four interrelated concepts: the authenticators; composition schemes for them through authenticator employments; their concrete employments through authentication techniques; their implementation through authentication solutions. This decomposition forms the basis for a modular approach to modeling authentication quality and is presented using a formal notation we developed, along with comprehensive examples that illustrate their relationships to quality. To demonstrate, we developed initial definitional quality models for authenticators, authentication techniques, and authentication solutions, and deployed them as an interactive web application.

Vector (PDF)

Limitations

This study is subject to certain limitations. It elaborates on the inherent quality properties of authenticators—that is, how authenticators, by their very nature, influence the overall quality of an authentication solution. To illustrate this, we accepted a clear limitation: we did not allow users to copy and paste or autofill passwords. However, this limitation was necessary to highlight the qualitative nature underlying the authenticators. Our interpretation of an authenticator’s ease of use, i.e., counting the number of required user interactions with an input device to use an authenticator for authentication, implies for passwords that they require $n$ user inputs, one per character. This is a property inherent to a password. However, tools such as password managers mitigate this drawback by letting users copy and paste passwords. Using a password manager does, however, not mean that the inherent property of the password is thereby rendered obsolete. Rather, password managers owe their very existence to the fact that passwords are, among other things, poorly usable for authentication.

Next, because of their qualitative nature, both the decomposition underlying the AQUA framework and the AQUA models may have been influenced by subjectivity. We tried to minimize this threat by making decisions only after the authors agreed. Moreover, we verified AQUA’s internal consistency and expressiveness by formalizing the concepts.

Furthermore, although the three AQUA models are substantial results on their own, they are limited to a small number of factors and subfactors. Given the project’s early stage, this limitation is acceptable. Moreover, we developed them for demonstration purposes and therefore do not claim they are comprehensive. Expanding these factors is part of future work. Lastly, the EoU metrics are purely illustrative, based on our experience, and have not yet been evaluated.

Future Work

AQUA opens up many important future directions. As mentioned in the limitations, we plan to extend the AQUA models with additional quality factors and subfactors. We also plan to extend AQUA with assessment and prediction models; the metrics we used for demonstration already capture some of our ideas. Such models will also support a comprehensive evaluation, which we consider another central direction for future work.

Next, we consider AQUA as a foundation for effective automated quality prediction and assessment in authentication solutions. Future studies could investigate how to use AQUA for these purposes. Moreover, future work can focus on establishing quality profiles with AQUA. The AQUA models we designed allow us to define quality profiles for authenticators and authentication techniques. For example, separate profiles for generated and self-chosen passwords can be defined, where the generated-password profile ranks memorability lower but threat sensitivity higher than the self-chosen profile.

Declaration on Generative AI

The authors used: 1) Claude to test the formal notation for errors and inconsistencies; 2) Claude, Grammarly, and DeepL for grammar and spelling checks, and to improve writing style. After use, the authors reviewed and edited the content as needed. They take full responsibility for the paper’s content.