Account-Holding Proofs Across Multiple Authorities from JWT-Derived Evidence Using RSA-Based Synchronized Aggregate Signatures

Abstract

This paper proposes a model for account-holding proofs across multiple authorities and presents a concrete construction from JWT-derived evidence, enabling a verifier to evaluate the resulting artifact under specified system assumptions and acceptance policies. Conventional account linkage approaches often depend on particular identity providers (IdPs) or linkage mechanisms and may expose or correlate more credential information than is necessary for the verifier’s policy. To address this, we formalize a scheme-agnostic abstract model and organize its security, disclosure-related, and deployment requirements. As a concrete instantiation, we apply an RSA-based synchronized aggregate signature scheme to encoded messages derived from the RS256 preprocessing step of JWT signing inputs. The resulting artifact is not a standard JWT and is not intended for direct verification by existing JWT/OIDC verifiers; rather, it provides a single aggregate signature component over multiple JWT-derived evidence items. Through analytical and prototype-based evaluation, we show that the signature-component data to be presented is reduced from n individual components to a single aggregate component and that the exponentiation applied to the presented signature component is reduced from $O\left(n\right)$ to $O\left(1\right)$, while the overall verification remains dominated by per-message public-key terms. The results of prototype implementation indicate that aggregate verification is not faster than ordinary RS256 JWT verification under the evaluated parameters; therefore, the construction is better suited to one-time or low-frequency account-holding proof scenarios in which the additional latency is tolerable.

1. Introduction

In recent years, a wide range of social and economic activities, including administrative procedures and financial transactions, have increasingly shifted online. Consequently, digital identities have become closely linked to individuals in the real world. In high-trust services, such as public and financial services, establishing user authenticity and accountability is a fundamental requirement for system design.

Specifically, the NIST SP 800-63 series published by the National Institute of Standards and Technology (NIST) in the United States and the eIDAS regulation of the European Union define frameworks for identity proofing and authentication in digital services from both technical and legal perspectives [1,2,3]. These standards and regulations provide common mechanisms for evaluating and implementing assurance levels in identity management within individual services. In other words, they enable service providers to verify, based on predefined criteria, that a user is a legitimate individual or meets the required eligibility for a given service.

However, these frameworks are primarily designed to address identity assurance for a single account or service context and do not, by themselves, provide a general mechanism for evaluating relationships among multiple accounts issued or managed by different authorities. In practice, users commonly maintain multiple accounts across different services, and there are situations in which a third party needs to evaluate whether evidence associated with these accounts can be treated as referring to the same underlying subject under predefined assumptions and acceptance policies. In such cases, it is not sufficient to verify the authenticity of each individual account in isolation. Rather, a mechanism is needed to support the presentation and verification of account-related evidence in a form that enables a verifier to make a policy-based evaluation across multiple authorities. In this paper, we use the term identity consistency to refer to a system-level interpretation that multiple accounts may be treated as attributable to the same underlying entity under the relevant issuance, binding, registration, and acceptance-policy assumptions. This interpretation is not asserted to follow from a single cryptographic operation alone.

As noted above, existing technical standards and legal frameworks mainly focus on identity verification at the level of individual accounts. When relationships among accounts must be evaluated across authorities, several structural challenges arise.

First, existing account linkage approaches, including federation-based mechanisms, often associate accounts according to specific Identity Providers (IdPs) or technical schemes. In such configurations, information that is not inherently necessary for the verifier’s acceptance policy may be shared during linking or presentation. Moreover, increased dependence on a particular IdP or linkage mechanism can raise concerns about operational flexibility, portability, and fault tolerance.

Second, when multiple accounts are linked or jointly evaluated, inconsistencies may arise in the assurance levels associated with each account. Operations that are intended to be performed under a high assurance level may effectively depend on an account or authentication result with a lower assurance level, thereby affecting the trust interpretation of the overall process. Although operational measures, such as restricting linkage targets or controlling operations and privileges on a per-action basis, can mitigate this issue, these measures are deployment-specific and do not by themselves define a scheme-agnostic presentation model for multi-authority evidence.

Third, handling multiple identifiers or authentication credentials in a linked manner can pose privacy and correlation risks. Even if each identifier or credential alone does not uniquely identify an individual, presenting or processing them in combination may enable identification, narrowing, or cross-service correlation of the user. Consequently, information beyond what is required by the verifier’s acceptance policy, such as user attributes, issuer relationships, or behavioral histories, may become linkable or traceable. For this reason, an account-evidence presentation mechanism should clearly distinguish between the information needed for policy evaluation and information that is unnecessarily exposed.

In summary, conventional account linkage mechanisms offer convenience but leave open the problem of how account-related evidence issued by multiple authorities can be presented to a third party as a unified artifact, while keeping the scope of the verifier’s evaluation explicit. The goal of this study is not to claim that cryptographic aggregation alone establishes real-world subject identity. Rather, the goal is to provide a model for account-holding proofs across multiple authorities, in which multiple pieces of account-related evidence can be evaluated under stated system assumptions and acceptance policies.

Partial solutions have been proposed for related aspects of this problem. To avoid dependence on specific IdPs, self-sovereign identity (SSI) management schemes have been advocated, in which users manage and present their identifiers and attribute information. In SSI models, the use of service-independent identifiers, such as Decentralized Identifiers (DIDs), can reduce dependence on a particular IdP. By employing a common identifier or credential framework across services, these models enable services to evaluate users under a shared identity-management context.

However, such identity verification is often performed based on identifiers or credentials held by the user, rather than directly on existing service-managed account evidence. Consequently, when the objective is to evaluate authentication results or account-related evidence already issued by existing services, challenges remain in preserving compatibility with current service architectures and in avoiding the presentation of complete tokens or credentials when only limited evidence is needed.

Regarding assurance level consistency, it is generally appropriate to select and implement assurance levels according to the characteristics of each service. When different assurance levels are assigned to different stages, such as identity proofing, authentication, and federation, the overall trust interpretation of a service may depend on the weakest relevant stage. Extending this principle to multi-authority account-evidence presentation implies that the verifier’s acceptance decision should be expressed as an explicit policy over the authorities, evidence objects, and assumptions involved. Thus, the issue is not only how to verify individual credentials, but also how to structure a presentation artifact that makes the verifier’s policy evaluation explicit.

Therefore, this study defines a model for account-holding proofs across multiple authorities, in which authentication or account-related evidence issued by different authorities can be handled as a unified presentation artifact. The model enables a third-party verifier to evaluate a presented artifact under a defined acceptance policy and stated system assumptions. Where supported by a concrete instantiation, the model may also reduce the direct exposure of token-level artifacts or credential contents; however, such disclosure reduction is treated as an instantiation-dependent property rather than as a universal privacy guarantee of the abstract model.

Table 1. Conceptual position of the proposed model.

Model	Input Granularity	Presented Object	Verification Handling
Conventional JWT	Single	Single	Single-object verification
VC/VP	Multiple	Multiple	Multi-object verification
Our model	Multiple	Single aggregated	Single aggregated-object verification

highlights the conceptual position of the proposed model. A conventional JSON Web Token (JWT) is essentially a single-to-single setting, in which a single token is used as both the input and the presented object for verification. Verifiable Credential/Verifiable Presentation (VC/VP) frameworks extend this setting to multiple credentials while maintaining multiple presented items and corresponding verification handling. By contrast, the proposed model also starts from multiple evidence objects but transforms them into a single aggregate artifact suitable for third-party policy evaluation while retaining the per-input information required to verify that artifact. Here, “object” refers to the unit presented to the verifier, such as a token, presentation, or aggregate proof artifact, depending on the model.

To clarify the design goals of this framework, this paper considers the following five service requirements, which are formalized in Section 4.

• Correctness: The ability to accept valid proof artifacts that satisfy the verifier’s acceptance policy.
• Soundness: The ability to reject verification when the provided evidence or artifact is invalid, malformed, or inconsistent with the acceptance policy.
• Unforgeability: The infeasibility of generating authentication evidence or an aggregate artifact that would be accepted as valid without authorization.
• Tamper Resistance: The infeasibility of altering verification-relevant components of a presented artifact without detection while preserving successful verification.
• Privacy: The restriction of disclosed information to what is required by the verifier’s acceptance policy.

The main contributions of this study are as follows.

• We define an abstract model for account-holding proofs across multiple authorities. The model enables a verifier to evaluate a presented artifact under specified system assumptions and acceptance policies, without relying on a specific IdP or authentication format.
• We formulate five service requirements for the proposed model. This provides a structured basis for discussing the design assumptions and evaluation criteria of account-holding proof presentations across multiple authorities.
• We present a construction from JWT-derived evidence using an RSA-based synchronized aggregate signature scheme. The construction demonstrates how multiple RS256-preprocessed signing inputs can be represented through a single aggregate signature component while clarifying that its privacy-related effect is limited to representation-level disclosure reduction and that it does not claim transparent interoperability with existing JWT/OIDC deployments, claim-level verification, or claim-level selective disclosure.

2. Preliminaries

2.1. JWT (JSON Web Token)

JSON Web Token (JWT) is a token format standardized by RFC 7519 [4] for securely transmitting a set of claims in JSON format. A JWT consists of three parts: header, payload, and signature. The header and payload are Base64URL-encoded and concatenated with a period. The signature value is generated by applying the selected signature algorithm to this concatenated string. An overview is presented in Figure 1.

JWT supports multiple signature schemes, including the Hash-based Message Authentication Code (HMAC)-SHA family and the Elliptic Curve Digital Signature Algorithm (ECDSA), and RFC 7519 specifies how these algorithms are designated and used. Among them, RSA-SHA256 (RS256) is widely used in practical applications. RS256 is defined in RFC 7518 [5], which specifies JSON Web Algorithms (JWA), as a signature scheme combining the RSA signature scheme RSASSA-PKCS1-v1_5 and the SHA-256 hash function.

2.2. PKCS (Public Key Cryptography Standards)

PKCS#1 specifies RSASSA-PKCS1-v1_5 as an RSA-based signature scheme [6]. In this scheme, after applying a hash function to an input message m, a value T is generated by Distinguished Encoding Rules (DER)-encoding the DigestInfo structure that contains the hash value and the identifier of the hash algorithm. Subsequently, a prescribed padding procedure is applied to T to construct an encoded message $EM$ of length k-bytes.

The RSA signature primitive is applied to the integer representation of the encoded message $EM$. That is, in RSASSA-PKCS1-v1_5, the final signing target is not the input message m itself but rather the deterministically constructed encoded message $EM$. The detailed procedures for signature generation and verification are delegated to RFC 8017. An overview is presented in Figure 2.

2.3. OAuth 2.0 and OpenID Connect (OIDC)

OAuth 2.0 [7] is an authorization framework that enables the delegation of access privileges to Web APIs to third parties. A client can obtain an access token representing the access privileges to a resource server without directly handling the user’s credentials. This mechanism enables the secure delegation of authority across services.

In contrast, OAuth 2.0 is a framework intended for authorization and does not directly guarantee user authentication. The specification designed to complement this limitation is OpenID Connect (OIDC) [8]. OIDC extends OAuth 2.0 by introducing a mechanism in which an Identity Provider provides the client with an ID token representing the result of user authentication. The ID token is specified in OpenID Connect Core 1.0 to be represented in the JSON Web Token (JWT) format [8]. By verifying this token, the client can confirm that the user has been authenticated by a particular Identity Provider.

3. System Model

3.1. Entities and Terminology

This section defines the primary entities and related concepts that appear in the proposed model.

• User ($\mathit{U}$) An entity that holds multiple identifiers and credentials and uses various services.
• Authority ($\mathit{A}$) A set of entities that issue identifiers and credentials to users and perform authentication and verification. For any authority, we denote $A\in \mathcal{A}$.
• Verifier ($\mathit{V}$) An independent entity that evaluates whether the sealed proof $\widehat{P}$ presented by the user U satisfies its acceptance policy $\pi$ across multiple authorities.
• Trusted Third Party (TTP) An optional external entity that, if present, may perform limited roles such as aggregating proofs or adding guarantees while maintaining a neutral position.
• Identifier (${\mathit{I}}_{\mathit{A},\mathit{U}}$) A label assigned by an authority A to a user U. However, the identifier itself does not guarantee ownership correctness.
• Proof Token (${\mathit{P}}_{\mathit{A}}$) A proof token is account-related evidence issued by authority A after user U proves possession of the corresponding credential or identifier within the issuance procedure of A. Its contents, verification method, and concrete format are implementation-dependent.
• Aggregated Proof (${\mathit{P}}^{\ast }$) An aggregated proof is an intermediate representation generated by combining selected proof tokens ${\left\{P_A\right\}}_{A\in S}$ according to an aggregation procedure. The subset may be selected by the user or specified by the verifier’s acceptance policy $\pi$.
• Sealed Proof ($\widehat{\mathit{P}}$) A sealed proof is the verifier-facing artifact derived from an aggregated proof $P^{\ast }$. It provides integrity protection or external verifiability using signatures, hashes, zero-knowledge proofs, or other suitable mechanisms. The entity responsible for sealing is not fixed. If $P^{\ast }$ is already self-verifiable in a concrete instantiation, the sealing operation may be a no-operation and $\widehat{P}=P^{\ast }$.
• Policy ($\mathit{\pi }$) A set of acceptance conditions defined by the verifier V. The verifier accepts $\widehat{P}$ only if it satisfies $\pi$. The policy specifies the conditions under which account-related evidence is sufficient for the verifier’s intended evaluation.
• Attribute Space ($\mathcal{X}$) The collection of attributes and metadata that proof tokens issued by authorities may contain. Policies $\pi$ reference subsets of $\mathcal{X}$ to formulate the verification conditions.

In this paper, an account-holding proof denotes a model for presenting and verifying account-related evidence issued by multiple authorities. This notion should be distinguished from same-subject attribution or identity consistency. The account-holding proof is a proof-presentation and verification framework, whereas same-subject attribution is a system-level interpretation of an accepted artifact under the stated assumptions and the verifier’s acceptance policy. Accordingly, the model does not claim that a proof token, an aggregation operation, or a cryptographic verification result alone proves that the underlying accounts belong to the same real-world user.

3.2. Assumed Environment

The proposed model was designed under the following assumptions:

• Secure Communication Channel: Communication between the user, authorities, and the verifier is encrypted using Transport Layer Security (TLS) or equivalent technologies, making eavesdropping or tampering infeasible for attackers.
• Authority ($\mathit{A}$): Authorities follow correct procedures when issuing identifiers and authentication information. However, they may attempt to infer additional information about users. Thus, we assume an honest-but-curious model. The model does not assume leakage of internal secret keys or malicious token issuance.
• User ($\mathit{U}$): The user behaves honestly, stores private keys and credentials securely, and obtains proof tokens from the authorities via legitimate procedures. The user is not required to directly reveal the relationships among multiple accounts. Instead, the protocol defines how account-related evidence is presented and evaluated under the model assumptions and the verifier’s acceptance policy.
• Verifier ($\mathit{V}$): The verifier follows a semi-honest model: it abides by policy $\pi$ for acceptance decisions and does not attempt to infer unnecessary information. The final operational decision, such as whether to provide a service or grant privileges based on an accepted artifact, is determined by the verifier’s own policy and deployment context.
• Trusted Third Party (TTP): Optional; if present, it behaves honestly and performs limited tasks, such as signature aggregation or sealing.
• Adversary ($\mathsf{Adv}$): A computationally bounded adversary operates in probabilistic polynomial time. The adversary cannot compromise secure communication channels or access the internal secrets of the authorities. However, it may attempt the following attacks:

• Forge a proof token $P_A$ by impersonating another user.
• Tamper with an aggregated proof $P^{\ast }$ or sealed proof $\widehat{P}$ to illegitimately satisfy the acceptance policy $\pi$.
• Cause a verifier to accept a presented artifact as satisfying the acceptance policy even though the underlying account-related evidence does not validly support that policy under the stated system assumptions.

Therefore, even when the user behaves honestly, the relationship among multiple accounts is not inherently evident to third parties. The proposed model does not treat identity consistency or same-subject attribution as being guaranteed by a single cryptographic operation alone. Rather, it is interpreted at the system level through issuer-side issuance, holder binding, registration integrity, and the verifier’s acceptance policy.

3.3. Basic Algorithms

In this model, account-related evidence is processed in three stages: authority-issued evidence, aggregation, and verifier-facing presentation. Accordingly, we use the following three representations, as defined in Section 3.1:

• $P_A$: a proof token issued by an authority A,
• $P^{\ast }$: an aggregated proof created from selected proof tokens, and
• $\widehat{P}$: a sealed proof evaluated by the verifier.

These representations should not be used interchangeably. The verifier’s acceptance of $\widehat{P}$ means that the presented artifact satisfies the policy $\pi$ under the stated assumptions.

While each $P_A$ possesses integrity guarantees from its issuer A, its correctness may not be verifiable by an external third party (i.e., the verifier V). Likewise, the aggregated structure $P^{\ast }$ formed by combining several $P_A$ may not be self-contained for verification by a third party. Therefore, the model introduces a transformation operation $\mathsf{Seal}$, which converts $P^{\ast }$ into a form whose integrity and validity can be externally verified. The output of $\mathsf{Seal}$ is the object to which the verifier applies its acceptance policy. Consequently, the model focuses on artifact-level validity and policy satisfaction, while deployment-specific service decisions are handled by the verifier.

We now define eight abstract operations that generate and manipulate these three types of representations.

• System Setup. $Setup\left(1^{\lambda }\right)\to pp.$ Based on the security parameter $\lambda$, this operation generates the global public parameters $pp$ shared by the entire system.
• Credential Generation. $Ge{n}_{U,A}(1^{\lambda },pp)\to (I,\mathsf{cred},\mathsf{pub}).$ Given the public parameters $pp$, the authority A generates credential information associated with user U. The credentials consist of secret information $\mathsf{cred}$ (e.g., a password or private key) and the corresponding public information $\mathsf{pub}$ required for verification.
• Initial Registration. $Re{g}_{U,A}(I,\mathsf{pub})\to \mathsf{RegRecord}$. User U submits identifier $I_{A,U}$ and the public verification data $\mathsf{pub}$ to authority A, which stores them as registration records  $\mathsf{RegRecord}$.
• Authentication. $Aut{h}_{U,A}(I,\mathsf{cred},\mathsf{pub})\to P_A$. User U proves authenticity using the secret information $\mathsf{cred}$ and public data $\mathsf{pub}$. Authority A then issues a proof token $P_A$.
• Policy Definition. $Re{q}_V(\mathcal{U},\mathcal{A})\to \pi$. Verifier V defines an acceptance policy $\pi$ based on the user set $\mathcal{U}$ and the attribute space $\mathcal{X}$.
• Proof Aggregation. $Agg\left({\left\{P_A\right\}}_{A\in \mathcal{A}},\pi \right)\to P^{\ast }$. Multiple proof tokens $\left\{P_A\right\}$ are combined according to the acceptance policy $\pi$ to produce an aggregated proof, $P^{\ast }$.
• Seal/Guarantee. $Seal\left(P^{\ast }\right)\to \widehat{P}$. A sealing operation is applied to $P^{\ast }$ to provide integrity protection suitable for third party verification. This may involve attaching signatures, message authentication codes (MACs), hashes, or zero-knowledge proofs. If the proof tokens $P_A$ or the aggregated proof $P^{\ast }$ are already self-verifiable, $\mathsf{Seal}$ may act as a no-operation.
• Identity Verification. $Verif{y}_V(\widehat{P},\pi )\to \{0,1\}$. Verifier V evaluates the submitted proof $\widehat{P}$ (or $P^{\ast }$ when self-verifiable) by performing the following:

• integrity and well-formedness checks, and
• validation against the acceptance policy $\pi$.

If both conditions are satisfied, V outputs 1 (accept); otherwise, it outputs 0 (reject). This output represents acceptance of the presented artifact under $\pi$.

3.4. System Structure and Protocol

By integrating the entities and the eight abstract operations defined in the previous sections, the overall protocol in this model is as follows:

• The user U generates or obtains identifiers and credential information associated with each authority A and registers them when necessary.
• Each authority A verifies the authenticity of user U and issues a proof token $P_A$.
• User U aggregates the necessary proof tokens according to the acceptance policy $\pi$ defined by the verifier V, producing an aggregated proof $P^{\ast }$.
• A guarantee is applied to $P^{\ast }$ by the user, a TTP, or a third party, yielding a sealed proof $\widehat{P}$.
• The verifier V evaluates the submitted $\widehat{P}$ and accepts it only if it satisfies the acceptance policy $\pi$.

Through this sequence, multiple proof tokens can be combined into a presentation object that a verifier evaluates under an acceptance policy. The model provides an abstract framework for account-holding proofs across multiple authorities, while the concrete guarantees depend on the instantiation of each process and on the surrounding system assumptions. If the verifier accepts the presented artifact, it may treat the corresponding account-related evidence as supporting same-subject attribution under its policy. Whether such acceptance is sufficient for service provision, authorization, or eligibility approval remains a deployment-specific decision of the verifier. An overview of this study is presented in Figure 3.

4. Service Requirements

4.1. Model-Level Requirements

In this section, we define five model-level requirements for the account-holding proof model introduced in Section 3: correctness, soundness, unforgeability, tamper resistance, and privacy. These requirements are used to analyze whether a presented proof artifact satisfies the verifier’s acceptance policy $\pi$. They concern artifact generation, presentation, and verification, rather than independent determination of real-world subject identity.

As discussed in Section 3, same-subject attribution is treated as a system-level interpretation under the stated assumptions and the verifier’s acceptance policy. The cryptographic mechanism supports the validity and integrity of the presented proof artifact.

We define the set of sealed proofs that are validly generated and accepted under a given acceptance policy $\pi$ as

$$\mathcal{H}\left(\pi \right)=\left\{\widehat{P}|\begin{array}{cc}& \exists S\subseteq \mathcal{A},\exists {\left\{P_A\right\}}_{A\in S}:\hfill \\ & P^{\ast }=\mathsf{Agg}\left({\left\{P_A\right\}}_{A\in S}\right),\hfill \\ & \widehat{P}=\mathsf{Seal}\left(P^{\ast }\right),\hfill \\ & {\mathsf{Verify}}_V(\widehat{P},\pi )=1\hfill \end{array}\right\}.$$

The acceptance of a sealed proof should be distinguished from identity consistency. In this model, ${\mathsf{Verify}}_V(\widehat{P},\pi )=1$ means that the artifact satisfies the verifier’s policy under the stated assumptions. It does not, by itself, determine that the underlying accounts belong to the same real-world subject. Any subsequent service, authorization, or eligibility decision remains a verifier-side operational decision.

• Correctness. Correctness requires that the protocol accepts legitimately generated proof artifacts. Formally, for any set of authorities $S\subseteq \mathcal{A}$ and any proof tokens $P_A$ correctly generated by each $A\in S$, if the user computes

  $$P^{\ast }\leftarrow \mathsf{Agg}\left({\left\{P_A\right\}}_{A\in S}\right)$$

  correctly, and subsequently generates

  $$\widehat{P}\leftarrow \mathsf{Seal}\left(P^{\ast }\right)$$

  correctly, the verifier must accept

  $${\mathsf{Verify}}_V(\widehat{P},\pi )=1.$$
• Soundness. Soundness requires that malformed or improperly generated proof artifacts be rejected with respect to the verification predicate and the acceptance policy $\pi$ represented in the model. For any probabilistic polynomial-time adversary $\mathsf{Adv}$, let $P_{\mathsf{Adv}}^{\ast }$ be any aggregated proof output by $\mathsf{Adv}$, and let ${\widehat{P}}_{\mathsf{Adv}}$ denote the proof artifact obtained by applying the sealing procedure to $P_{\mathsf{Adv}}^{\ast }$. When the sealing procedure acts as a no-operation, ${\widehat{P}}_{\mathsf{Adv}}$ is identical to $P_{\mathsf{Adv}}^{\ast }$. If $P_{\mathsf{Adv}}^{\ast }$ does not belong to the set of aggregated proofs that could arise from valid execution of the protocol under $\pi$, then the verifier must reject:

  $${\mathsf{Verify}}_V({\widehat{P}}_{\mathsf{Adv}},\pi )=0.$$
• Unforgeability. Unforgeability requires that an adversary cannot generate an accepted sealed proof artifact outside the set $H\left(\pi \right)$ of legitimately generated and accepted proofs. Formally, for any polynomial-time adversary $\mathsf{Adv}$, the following probability must be negligible:

  $$\mathrm{Pr}[{\mathsf{Verify}}_V({\widehat{P}}_{\mathsf{Adv}},\pi )=1\wedge {\widehat{P}}_{\mathsf{Adv}}\notin H\left(\pi \right)]\le \mathsf{negl}\left(\lambda \right),$$

  where ${\widehat{P}}_{\mathsf{Adv}}$ is any sealed proof output by $\mathsf{Adv}(1^{\lambda },\pi )$. The adversary may freely access all public information and any legitimately generated proof tokens and may construct arbitrary candidate proofs.
• Tamper Resistance. For any valid aggregated proof $P^{\ast }$, let the set of all sealed proofs that can be legitimately produced from it be

  $$S\left(P^{\ast }\right)=\{\widehat{P}\mid \widehat{P}=\mathsf{Seal}\left(P^{\ast }\right)\}.$$

  This includes the case in which $\mathsf{Seal}$ acts as a no-operation and $\widehat{P}=P^{\ast }$. Tamper resistance requires that any polynomial-time adversary $\mathsf{Adv}$ cannot construct any modified proof artifact ${\widehat{P}}^{\prime }\notin S\left(P^{\ast }\right)$ that would nevertheless be accepted by the verifier, except with negligible probability. That is, the probability of the event

  $${\mathsf{Verify}}_V({\widehat{P}}^{\prime },\pi )=1\mathrm{and}{\widehat{P}}^{\prime }\notin S\left(P^{\ast }\right)$$

  must be negligible in the security parameter $\lambda$.
• Privacy. At the model level, privacy requires that the information disclosed by $\widehat{P}$ be limited to what is necessary for evaluating the acceptance policy $\pi$, to the extent supported by the concrete instantiation. A stronger instantiation may formalize simulator-based privacy, but the abstract model does not require every instantiation to achieve it. When such a formalization is not provided, privacy is evaluated by examining the information explicitly disclosed by the presented proof representation.

4.2. Attack Model and Defensive Processes

This section relates the five requirements to the eight abstract processes defined in Section 3.3: Setup, Gen, Reg, Auth, Req, Agg, Seal, Verify.

Table 2. Relationship Between Requirements and Processes.

Requirement	Setup	Gen	Reg	Auth	Req	Agg	Seal	Verify
Correctness	–	(o)	(o)	(*)	–	(*)	(o)	(*)
Soundness	–	–	(o)	(*)	(*)	–	(o)	(*)
Unforgeability	–	(*)	(o)	(*)	–	–	(*)	–
Tamper Resistance	–	–	–	–	–	–	(*)	(*)
Privacy	–	–	–	–	–	(*)	(o)	(*)

(*) = directly related; (o) = conditionally related; – = no direct relation.

identifies the processes relevant to each requirement. The symbol “(*)” denotes a directly related process, “(o)” denotes a conditionally related process, and “–” denotes no direct relation. The table indicates processes relevant for analysis; it does not assign complete guarantees to those processes.

• Correctness: Correctness requires that an aggregated proof $P^{\ast }$ that legitimately satisfies the policy $\pi$ always yields an accepted sealed proof $\widehat{P}$. In other words, the verification algorithm must never incorrectly reject a valid input. Under this requirement, Auth, Agg, and Verify are directly required. If any of these processes fail, correctness cannot be achieved. Although Gen, Reg, and Seal may also influence correctness when they malfunction, the model assumes secure key generation, registration consistency, and the extractability of Seal. Accordingly, these are treated as preconditions. In contrast, Req does not directly contribute to correctness.
• Soundness: Soundness requires that an aggregated proof $P^{\ast }$ that does not satisfy the policy $\pi$ never yield an accepted sealed proof $\widehat{P}$. In other words, the verification algorithm must not incorrectly accept an invalid input. Under this requirement, Auth, Req, and Verify are directly required. If any of these processes fail, soundness cannot be guaranteed. Although Reg and Seal may also affect soundness when they malfunction, the model assumes proper registration of public keys and identifiers and the integrity of the sealing process. Accordingly, these are treated as preconditions. In contrast, Gen and Agg do not directly contribute to soundness.
• Unforgeability: Unforgeability requires that an attacker without valid credentials be unable to generate a new sealed proof $\widehat{P}$ that passes verification. In other words, it must be computationally infeasible to construct a valid proof without executing a legitimate protocol. Under this requirement, Gen, Auth, and Seal are directly required. If any of these processes fail, an attacker may be able to forge a valid $\widehat{P}$. Although Reg may also affect unforgeability under certain inconsistencies, the model assumes the integrity of the registration infrastructure. Accordingly, it is treated as a precondition. In contrast, Req, Agg, and Verify do not directly contribute to unforgeability because they are not involved in proof generation.
• Tamper Resistance: Tamper resistance requires that any modification ${\widehat{P}}^{\prime }\ne \widehat{P}$ of a valid sealed proof never passes verification. Under this requirement, Seal and Verify are directly required. Seal provides integrity protection. Verify ensures that altered inputs are rejected. In contrast, Gen, Reg, Auth, Req, and Agg do not directly contribute to tamper resistance.
• Privacy: Privacy requires that the verifier learn no more from the presented proof than is necessary to decide whether the acceptance policy $\pi$ is satisfied. In other words, unnecessary identifiers, attributes, or metadata should not be disclosed through the presented proof. Under this requirement, Agg and Verify are directly required. Agg determines what information is carried into the aggregated proof $P^{\ast }$, and Verify determines whether that proof is sufficient for acceptance under $\pi$. Although Seal must not introduce unnecessary information beyond what is needed for third-party verifiability, the model treats this as a precondition. In contrast, Gen, Reg, Auth, and Req do not directly contribute to the privacy requirement.

5. Proposed Method

5.1. Construction of Account-Holding Proofs from JWT-Derived Evidence

Based on the generic model presented in Section 3, this section presents, as a concrete example, a construction of account-holding proofs from evidence derived from JWT signing inputs. The construction is motivated by settings in which authentication results issued by multiple services or authorities must be presented to a verifier as a unified artifact. The verifier then evaluates the presented artifact under a predefined acceptance policy and the system assumptions stated in the model. Figure 4 provides an overview of the signature generation and aggregation process in the proposed scheme. Conceptually, this construction is motivated by replacing the final RS256 signing step used in ID-token issuance with an aggregate-compatible RSA-based signing step. However, the concrete construction presented in this paper is not a drop-in JOSE/JWS algorithm for existing JWT/OIDC deployments. It requires issuer-side support for HW18-compatible signing, common period handling, and public-key resolution through an external public-key infrastructure or an equivalent key-management mechanism, and should therefore be understood as a JWT-derived aggregate-proof profile rather than as an ordinary ID token processed directly by existing JWT/OIDC verifiers.

The assumed use case is a setting in which a verifier needs to confirm that authentication-evidence items corresponding to multiple authorities are available within a common period. The verifier’s concern in this setting is not to inspect the full contents of each individual JWT but to verify the existence of valid signatures corresponding to the selected authentication results. In ordinary JWT-based presentation, each token is presented as an independent object and its signature is verified separately. Such presentation may expose token-level artifacts, including payload contents and independently reusable signature components, even when the verifier’s policy only requires evidence that valid authentication results exist.

Accordingly, the proposed construction aggregates the signature components corresponding to the selected JWT-derived encoded messages. The resulting artifact consists of the common period, a single aggregate signature component, the encoded messages, and metadata required for public-key resolution. Thus, the construction reduces the number of presented signature components while retaining the per-input information required for verification. It should not be interpreted as direct verification of standard JWTs, claim-level verification, or claim-level selective disclosure. More specifically, the encoded messages remain verification inputs for the aggregate-signature equation, and their inclusion limits the privacy effect of the construction to reducing the direct presentation of full JWTs and individual JWT signature values.

5.2. Concrete Scheme and Technical Construction

Various aggregate signature schemes have been proposed; in this study, we select a scheme based on practical requirements. Specifically, it is desirable to satisfy the following three conditions: (i) consistency with the fact that RS256 is widely used in practical deployments, (ii) avoidance of transferring individual ID tokens to the verifier as-is, and (iii) exclusion of mixtures of authentication results issued at different points in time. Based on these considerations, the proposed scheme adopts the RSA-based synchronized aggregate signature scheme proposed by Hohenberger and Waters, referred to here as HW18 [9]. The reasons for this choice are as follows. First, since the scheme is based on the hardness assumption of integer factorization, it facilitates maintaining consistency with the RSA-based cryptographic foundation assumed by RS256. Second, by restricting aggregation to signatures within the same period via a synchronization parameter, it can suppress mixing signatures issued at different times and can clarify that a presentation corresponds to a single period. In this implementation-oriented instantiation, we use the logarithmic-storage construction of HW18, specifically Method 1 in Section 6, for issuer-side signature generation rather than the base construction. This choice is made because the base construction incurs signing costs that grow linearly with the maximum number of periods T, whereas the logarithmic-storage construction reduces issuer-side signing time and private-key storage with respect to T. In this construction, HW18-compatible signing is positioned as a proof-oriented replacement of the final RS256 signing step; therefore, ordinary RS256 signature values contained in already issued JWTs cannot be reused as aggregate-signature components.

5.3. Technical Core and Signing Target

The technical core of the proposed scheme lies in retaining the RS256 preprocessing structure up to the construction of the PKCS#1 v1.5 encoded message $EM$ and then using $EM$ as the message input to an RSA synchronized aggregate signature scheme (HW18). In ordinary RS256 signing, $EM$ is the deterministic encoded message to which the final RSA signature primitive is applied. In the proposed construction, this preprocessing up to $EM$ is retained, while the final RS256 signature primitive is replaced by HW18-compatible signing for the proof-oriented aggregate construction.

Specifically, let $A_1,\dots ,A_n$ be the authentication authorities selected for the proof. For each authority $A_i$, the user U holds an encoded message $E{M}_i$ and an individual signature component ${\sigma }_i$ corresponding to the authentication result obtained from $A_i$. The public-key-resolution metadata corresponding to $A_i$ is denoted by ${\mathsf{meta}}_i$. Equivalently, $E{M}_i:=E{M}_{A_i}$, ${\sigma }_i:={\sigma }_{A_i}$, and ${\mathsf{meta}}_i:={\mathsf{meta}}_{A_i}$. The verifier V is not presented with the individual signature components ${\left\{{\sigma }_i\right\}}_{i=1}^n$. Instead, U presents the collection of encoded messages ${\left\{E{M}_i\right\}}_{i=1}^n$, the aggregate signature ${\sigma }_{\mathrm{agg}}$, and the metadata ${\left\{{\mathsf{meta}}_i\right\}}_{i=1}^n$ required for public-key resolution. Based on these inputs, the verifier performs aggregate verification to confirm that a valid signature corresponding to each $E{M}_i$ exists under the public key resolved for authority $A_i$.

In this setting, the presented artifact $P^{\ast }$ for $n\ge 2$ is a JWT-derived aggregate-proof artifact, not a standard ID token or a standard JWT compact serialization. The verifier evaluates aggregate-signature validity over the common period, the aggregate signature, the encoded messages, and the resolved issuer public keys, rather than performing ordinary per-token JWT/OIDC validation. Accordingly, the construction avoids presenting individual ID tokens as-is by defining a separate aggregate-proof artifact, not by preserving unmodified ID-token processing.

5.4. Algorithms

Building on the eight steps defined in Section 3.3, this section instantiates a synchronized aggregate signature scheme using JWTs as OIDC ID tokens, where the encoded messages obtained via RS256 preprocessing are used as inputs. The algorithms below describe a proof-oriented instantiation in which the RS256-derived encoded message is signed using HW18-compatible signing. They should not be read as an unmodified OIDC token-generation or token-verification workflow.

In the proposed scheme, an acceptance policy $\pi$ determines which proof tokens are included in the aggregation target. The subsequent aggregation operation $\mathsf{Agg}$ merely aggregates the selected signatures in a prescribed manner, and its computation does not change depending on the contents of $\pi$.

• System Setup. $Setup(1^{\lambda },1^T)\to pp$. Given the security parameter $\lambda$ and the maximum period T, the algorithm generates public parameters $pp$ shared system-wide.

First, it generates safe primes p and q such that $p-1=2p^{\prime }$ and $q-1=2q^{\prime }$. It then obtains the RSA modulus $N=pq$. Moreover, it chooses N so that the Euler totient $\phi \left(N\right)=(p-1)(q-1)$ satisfies $2^{\lambda }<\phi \left(N\right)<2^{\lambda +1}$. Let $Q{R}_N$ denote the quadratic residue group of order $p^{\prime }{q}^{\prime }$, and select its generator g uniformly at random.

Next, it deterministically derives a prime $e_t$ for each period $t\in [1,T]$. Let $F_{K^{\prime }}:[1,T]\times \{1,\dots ,{\lambda }^2+\lambda \}\to {\{0,1\}}^{\lambda }$ be a pseudorandom function. Let $K^{\prime }$ be a randomly chosen key for F, let $c\in {\{0,1\}}^{\lambda }$ be a random string, and let $e_{\mathsf{default}}$ be a prime chosen from the interval $[2^{\lambda },2^{\lambda +1})$. Set $K=(K^{\prime },c,e_{\mathsf{default}})$. Then, define a function $H_K\left(t\right)$ that takes a period $t\in [1,T]$ as input and outputs a prime as follows. For each period t, in the order $i=1,2,\dots ,{\lambda }^2+\lambda$, compute $y_i=c\oplus F_{K^{\prime }}(t,i)$ and $e=2^{\lambda }+y_i$; if e is prime, set $H_K\left(t\right)=e$. If no prime is obtained for any i, set $H_K\left(t\right)=e_{\mathsf{default}}$.

Using the resulting parameters ${\left\{e_t\right\}}_{t=1}^T$, it computes $E={\prod }_{t=1}^T{e}_{t}mod\phi \left(N\right)$ and then computes $Y=g^{E}modN$. Finally, it outputs the public parameters $pp=(T,N,g,Y,K)$.

• Credential Generation. $Ge{n}_A\left(pp\right)\to (s{k}_A,p{k}_A)$. An authentication authority A uses the public parameters $pp$ to generate its signing key material. It chooses random values $u_0,\dots ,u_k$ and defines the corresponding public key as $p{k}_A=(U_0,\dots ,U_k)$, where each component is given by $U_j=Y^{u_j}modN$ for $j=0,\dots ,k$.

In addition, the authority initializes the logarithmic-storage state used in Method 1 of HW18. Let ${\mathsf{st}}_A$ denote this state. The secret key of A is then defined as $s{k}_A=(u_0,\dots ,u_k,{\mathsf{st}}_A)$. The storage state ${\mathsf{st}}_A$ is maintained by the authority as part of its issuer-side signing state and is updated as the period advances. It is not included in the proof token presented to the verifier.

• Initial Registration. $Re{g}_{U,A}(I_A,pk)\to \mathsf{RegRecord}$. The authentication authority A registers its public key information $p{k}_A$ for signature verification in a trusted public registry, associating it with the issuer identifier $I_A$ (and, if necessary, a key identifier ${\mathsf{kid}}_A$). This enables third parties, including verifiers, to retrieve the corresponding public key $p{k}_A$ based on $I_A$ (and ${\mathsf{kid}}_A$). This registration step represents an external public-key infrastructure or equivalent key-management assumption of the construction.
• Authentication. $Aut{h}_{U,A}(I_{A,U},\mathsf{cred})\to P_A$. The authentication authority A deterministically constructs an encoded message $E{M}_A$ from the JWT signing input in accordance with the preprocessing in RS256 and uses it as the signing target. In the proof-oriented flow considered here, the issuer retains the RS256 preprocessing step up to $E{M}_A$, but the final signing operation is performed by the HW18-compatible signing procedure for the common period t. Next, $E{M}_A$ is partitioned into ℓ-bit blocks to obtain $(m_1,\dots ,m_k)$.

For period $t\in [1,T]$, the authority computes $e_t=H_K\left(t\right)$ and invokes the signing procedure of the logarithmic-storage construction of HW18, specifically Method 1 in Section 6, using its secret key $s{k}_A=(u_0,\dots ,u_k,{\mathsf{st}}_A)$. This procedure updates the storage state ${\mathsf{st}}_A$ consistently with the current period and produces an intermediate signing value corresponding to $Y^{1/e_t}$. Using this value, the authority generates a signature distributed as ${\sigma }_A={\left(U_0·{\prod }_{j=1}^k{U}_j^{m_j}\right)}^{1/e_t}modN.$ Here, the expression ${(·)}^{1/e_t}$ denotes the signature distribution realized by the HW18 logarithmic-storage signing procedure, rather than a direct inversion of $e_t$ by the issuer. Consequently, the resulting ${\sigma }_A$ is an HW18-compatible signature component over $E{M}_A$, not the ordinary RS256 signature component of a standard JWT.

The authority outputs a proof token $P_A=(t,E{M}_A,{\sigma }_A,{\mathsf{meta}}_A),$ where ${\mathsf{meta}}_A$ contains the information required for public-key resolution, such as the issuer identifier $I_A$ and, if necessary, the key identifier $ki{d}_A$. The metadata ${\mathsf{meta}}_A$ is later associated with $E{M}_A$ in the aggregate proof and should not be interpreted as the user identifier $I_{A,U}$.

• Policy Definition. $Re{q}_V(\mathcal{U},\mathcal{A})\to \pi .$ The verifier V defines an acceptance policy $\pi$ based on, e.g., the user set $\mathcal{U}$ and the attribute space $\mathcal{X}$. In the proposed scheme, the acceptance policy fixes or references a common period t, and only signatures issued for that period are eligible for aggregation.
• Proof Aggregation. $Agg({\left\{P_{A_i}\right\}}_{i=1}^n)\to P^{\ast }$. The user U selects, as aggregation targets, a set of proof tokens ${\left\{P_{A_i}\right\}}_{i=1}^n$ whose signatures were issued in the same period t, so as to satisfy the acceptance policy $\pi$ defined by the verifier V. For each selected authority $A_i$, let $P_{A_i}=(t,E{M}_i,{\sigma }_i,{\mathsf{meta}}_i)$, where $E{M}_i$, ${\sigma }_i$, and ${\mathsf{meta}}_i$ denote the encoded message, individual signature component, and public-key-resolution metadata corresponding to authority $A_i$, respectively. The metadata ${\mathsf{meta}}_i$ contains the information required for public-key resolution, such as the issuer identifier and, if necessary, a key identifier. For the selected set of signatures, the user computes the aggregate signature as ${\sigma }_{\mathrm{agg}}={\prod }_{i=1}^n{\sigma }_{i}modN.$ The aggregate proof token presented by the user to the verifier is defined as $P^{\ast }=\left(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathsf{meta}}_i)\right\}}_{i=1}^n\right).$ Here, each ${\mathsf{meta}}_i$ is used only to resolve the public key corresponding to $E{M}_i$ and does not denote a user identifier.
• Seal/Guarantee. $Seal\left(P^{\ast }\right)\to \widehat{P}$. In the proposed scheme, the synchronized RSA aggregate signature also serves as the guarantee mechanism, and no additional sealing procedure is required; thus, $\widehat{P}=P^{\ast }$. Accordingly, in this concrete instantiation, the sealed proof is realized by the aggregate-signature artifact itself, and the guarantee attributed to Seal is realized without introducing an additional transformation layer.
• Identity Verification. $Verif{y}_V\left(pp,P^{\ast }=(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathsf{meta}}_i)\right\}}_{i=1}^n),\pi \right)\to \{0,1\}$. Using each ${\mathsf{meta}}_i$, the verifier resolves the corresponding public key $p{k}_{A_i}=(U_{i,0},\dots ,U_{i,k})$.
• Here, ${\sigma }_{\mathrm{agg}}$ is denoted by $\sigma$ in the single-signature case. The algorithm returns 1 if the following conditions hold, and 0 otherwise.
• (i) Single verification ($n=1$): Let $E{M}_1=m_{1,1}\parallel \cdots \parallel m_{1,k}$. Then,

  $${\sigma }^{e_t}=U_0·{\displaystyle \prod _{j=1}^k}{U}_j^{m_{1,j}}(modN).$$
• (ii) Aggregate verification ($n\ge 2$): Let each $E{M}_i=m_{i,1}\parallel \cdots \parallel m_{i,k}$. Then,

  $${\sigma }_{\mathrm{agg}}^{e_t}={\displaystyle \prod _{i=1}^n}\left(U_{i,0}·{\displaystyle \prod _{j=1}^k}{U}_{i,j}^{m_{i,j}}\right)(modN).$$

5.5. Limitations

5.5.1. Relationship to Existing JWT/OIDC Environments and Deployment Assumptions

The proposed scheme is not intended to present and verify JWT-based OIDC ID tokens in their original form. Instead, it treats the encoded message $EM$, derived through the RS256 preprocessing step, as the signing target and applies a synchronized aggregate signature scheme to that value.

Accordingly, the artifact presented to the verifier differs from a standard JWT. It consists of $\left\{E{M}_i\right\}$, an aggregate signature, and related metadata. The proposed scheme therefore does not assume direct verification by existing RS256-based JWT verifiers. This is because the objective of the scheme is not transparent integration into existing OIDC deployments. Rather, the objective is to enable aggregate presentation and aggregate verification of multiple authentication results while preserving a signing-target structure that remains consistent with JWT processing.

The scheme also requires support at the issuer side. Each issuer must construct $EM$ in accordance with the RS256 preprocessing procedure and generate a signature value compatible with the synchronized aggregate signature scheme. Therefore, the scheme does not assume that existing issuer mechanisms can be used without modification. Some adaptation of the issuer-side signing process is required.

In addition, multiple signatures can be aggregated only when they belong to the same period parameter t. Accordingly, the relevant entities must share a mechanism by which a common period parameter can be referenced for synchronization. The specific method for realizing such period synchronization is outside the scope of this study. For these reasons, the construction is most naturally suited to controlled or semi-controlled deployment settings, such as financial-service eligibility assessment, administrative screening, compliance review, or corporate onboarding, where participating issuers and verifiers can agree in advance on signing parameters, public-key resolution, and period handling. It is not intended as an unmodified large-scale public authentication infrastructure or as a replacement for ordinary high-throughput login systems.

5.5.2. Stateful Signing Storage and Period-State Management

The proposed instantiation adopts the logarithmic-storage construction of HW18, specifically Method 1 in Section 6, for issuer-side signature generation. Accordingly, each issuer must maintain stateful signing storage in addition to its ordinary secret signing material. This storage state is updated as periods advance and must remain consistent with the period parameter used for signature generation.

This requirement introduces operational constraints that do not arise in ordinary stateless RS256 signing. In particular, deployments must prevent rollback or reuse of signing states, and multi-server issuer deployments require synchronization or serialization of signing operations. Key rotation, backup, and failure recovery procedures must also preserve the consistency of the current period and the corresponding storage state. A failure that causes period rollback, state reuse, or divergence among issuer instances may prevent correct signature generation or aggregation, although such failures do not change the aggregate verification equation itself. The detection and recovery procedures for such operational failures are deployment-level controls and are outside the cryptographic guarantee of the proposed scheme.

5.5.3. Limited Verification Scope and Non-Goals

Under the proposed scheme, the verifier directly checks only whether a valid signature exists for each presented $E{M}_i$. That is, the verifier confirms that signatures corresponding to multiple authentication results are held.

By contrast, the JWT body and the claims themselves are not included in the presented artifact. The scheme is therefore not intended, by itself, to support direct inspection or evaluation of claim contents. Its scope is limited to batch presentation and batch verification of signatures corresponding to multiple authentication results.

For the same reason, the scheme is not intended to verify the semantic content of claims. It is also not intended, by itself, to realize selective disclosure of attributes. Nor is it intended to compare or integrate credential contents in a detailed manner.

Moreover, the scheme operates on signatures corresponding to JWTs after issuance. It does not directly address the identity verification procedures adopted by each issuer or the design of authentication strength at the issuer side. Likewise, it does not directly resolve differences in assurance levels across issuers. The proposed scheme is not a mechanism for unifying issuer-side issuance processes or assurance levels. Rather, it should be understood as a mechanism for presenting and verifying in a bundled manner the existence of signatures associated with a given set of authentication results. In addition, because the presented artifact includes metadata ${\left\{{\mathsf{meta}}_i\right\}}_{i=1}^n$ for public-key resolution, issuer-related information may still be disclosed; therefore, the scheme should not be interpreted as achieving full minimum-attribute disclosure. In particular, the presented encoded messages are not privacy-preserving encodings. They are deterministically derived from the RS256 signing input for verification purposes and provide no hiding property comparable to selective-disclosure credentials, commitments, or zero-knowledge proofs. Thus, the construction should be described as providing limited disclosure reduction relative to presenting full JWTs, rather than as providing full privacy protection.

The scope of this construction is also limited to the cryptographic representation and verification of the presented proof artifact; it does not model external infrastructure availability or recovery, such as denial-of-service attacks, network partitions, regional service outages, or physical and environmental disruptions in application-specific domains. Nor does it model application-specific behavioral or economic assumptions that may affect a user’s decision to present or rely on a proof workflow in a concrete service. Interruptions on communication paths among users, issuers, verifiers, TTPs, or external registries may affect token issuance, aggregation, presentation, or verification in deployment, but such reachability, recovery, and application-level decision issues are deployment-level concerns rather than guarantees of the proposed cryptographic scheme.

5.5.4. Dependence on External Public Key Infrastructure

Verification in the proposed scheme assumes that the verifier can correctly obtain the public key of each issuer on the basis of the presented metadata. However, public key registration, distribution, update, and validation of the correctness of such registration are outside the scope of the cryptographic mechanism of the scheme itself.

These functions are delegated to existing public key infrastructure (PKI) and related key-distribution mechanisms, such as OpenID Connect Discovery, the metadata used to locate JSON Web Key Sets, Web PKI, or equivalent mechanisms. Therefore, the reliability of the proposed scheme does not depend solely on the aggregate-signature verification procedure. It also depends on the correct operation of the external PKI and related mechanisms that support public key resolution.

6. Evaluation of the Proposed Method

This section evaluates the extent to which the concrete instantiation in Section 5 realizes the model-level requirements defined in Section 4.1. The evaluation focuses primarily on the processes marked with “(*)” in Table 2 while treating issuer-side issuance, holder binding, registration integrity, public-key resolution, and the verifier’s acceptance policy as system-level preconditions where applicable.

6.1. Requirement Compliance Evaluation

This section evaluates how the proposed algorithm realizes the model-level requirements introduced in Section 4.1, from the viewpoints of algebraic structure, reduction to the underlying aggregate-signature scheme, and explicitly stated system assumptions.

6.1.1. Correctness

Correctness, for this instantiation, requires that a proof artifact legitimately generated through Auth, Agg, and the no-op Seal as specified in Section 5 be accepted by Verify. In the proposed method, each encoded message $E{M}_i$ is deterministically derived from the corresponding JWT signing input through the RS256 preprocessing step, and each individual signature ${\sigma }_i$ is generated for the common period t specified by the construction. The Agg process then computes the aggregate signature ${\sigma }_{\mathrm{agg}}$ as the product of the individual signatures modulo N. In this concrete instantiation, Seal introduces no additional transformation, i.e., $\widehat{P}=P^{\ast }$. Verify checks the corresponding RSA-based aggregate verification equation for the presented tuple.

This follows from the algebraic correctness of the underlying synchronized aggregate signature scheme. If each individual signature satisfies the corresponding verification equation for the same period t, then their product satisfies the aggregate verification equation used by Verify. Therefore, whenever Auth, Agg, and the no-op Seal are executed as specified in Section 5, the resulting aggregate-signature artifact is accepted by Verify.

Thus, the construction realizes correctness at the level of the presented aggregate-signature artifact. This statement concerns artifact validity and does not by itself establish same-subject attribution.

6.1.2. Soundness

Soundness, for this instantiation, is evaluated at the aggregate-signature-artifact level. In the concrete scheme of Section 5, the cryptographically supported part of this property is the rejection of artifacts that do not correspond to legitimately generated signatures under a common synchronized period t. Each individual signature is created using the exponent $e_t=H_K\left(t\right)$, and the aggregate verification equation is evaluated with the same period parameter. Consequently, signatures generated for different periods cannot be combined into a valid accepted aggregate under the stated construction.

This follows because Verify accepts only when the presented tuple satisfies the aggregate verification equation for the resolved public keys, the presented encoded messages, and the common period t. Under the assumptions of the underlying scheme, an artifact that lacks such algebraic consistency is rejected except with negligible probability. Accordingly, the concrete method supports sound rejection of cross-period aggregation and other algebraically inconsistent inputs. This statement concerns the artifact-level verification predicate and does not extend to claim-level or policy-level validity.

6.1.3. Unforgeability

Unforgeability requires that

$$\mathrm{Pr}[{\mathrm{Verify}}_V({\widehat{P}}_{\mathrm{Adv}},\pi )=1\wedge {\widehat{P}}_{\mathrm{Adv}}\notin H\left(\pi \right)]\le \mathrm{negl}\left(\lambda \right).$$

For this instantiation, $\widehat{P}=P^{\ast }$ because Seal is a no-operation. Thus, forging a sealed proof means producing an accepted aggregate-signature artifact

$$(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathsf{meta}}_i)\right\}}_{i=1}^n)$$

outside the adversary’s legitimate signing transcript. More precisely, the adversary may obtain legitimately generated proof tokens or signatures for adaptively chosen tuples $(A,t,EM)$, and an accepted aggregate artifact is considered a forgery only if it contains at least one tuple $(A_i,t,E{M}_i)$ for which the adversary has not obtained a legitimately generated signature from the corresponding issuer.

The JWT signing input is deterministically mapped to the encoded message $EM$ by the RS256 preprocessing step, and $EM$ is used as the message input to the RSA-based synchronized aggregate-signature scheme. Therefore, the relevant security claim is inherited from the unforgeability of the underlying synchronized aggregate-signature scheme. If an adversary produces a new aggregate artifact that Verify accepts for the presented encoded messages and period t while containing an unsigned tuple in the above sense, then such an adversary can be used to construct a forgery against the underlying synchronized aggregate-signature scheme.

This reduction is conditioned on the public-key registration and resolution assumptions stated for the construction; in particular, ${\mathsf{meta}}_i$ is assumed to resolve to the authentic public key of issuer $A_i$. It also assumes that the preprocessing from a JWT signing input to $EM$ is fixed and unambiguous as specified by the construction.

In this instantiation, each issuer’s secret key material consists of the coefficient vector $(u_0,\dots ,u_k)$ and the stateful logarithmic-storage state ${\mathsf{st}}_A$ used by HW18 Method 1. The coefficient vector binds the encoded-message chunks to the issuer’s public key, whereas ${\mathsf{st}}_A$ realizes the period-dependent signing value for the current period. The introduction of ${\mathsf{st}}_A$ does not change the public verification equation or the distributional form required by the underlying HW18 construction; rather, it is an issuer-side signing optimization that enforces period-ordered signing.

The message-space structure of the RS256-derived encoded message is compatible with the requirements of the HW18 security argument. In HW18, each message is represented as a sequence of k chunks $(m_1,\dots ,m_k)$, where each chunk satisfies $0\le m_j<2^{\mathcal{\ell }}$, and the decomposition must be unambiguous. In the proposed construction, each encoded message $E{M}_i$ is a fixed-length value produced by the deterministic PKCS#1 v1.5 padding procedure specified in RFC 8017. Given a fixed chunk size ℓ that divides the encoded-message length, the decomposition of $E{M}_i$ into chunks of exactly ℓ bits is unique. Therefore, the unambiguous-decomposition condition required by the HW18 construction is satisfied.

The PKCS#1 v1.5 padding restricts the effective message space to a structured subset of all bit strings of the encoded-message length, but this does not weaken the unforgeability reduction. The adversary’s choice of JWT signing inputs induces signing queries over a deterministic subset of the HW18 message space. Since the underlying unforgeability guarantee applies to adversarially chosen messages, restricting admissible messages to this deterministic subset does not strengthen the adversary.

Thus, the construction realizes unforgeability at the level of aggregate-signature artifacts over encoded messages $E{M}_i$. This statement concerns artifact-level unforgeability and does not by itself establish claim-level validity or JWT/OIDC-system security.

6.1.4. Tamper Resistance

Tamper resistance requires that a modified proof artifact be rejected by the verifier. In this instantiation, Seal is a no-operation, so $\widehat{P}=P^{\ast }$, and no additional sealing layer is introduced. Therefore, tamper resistance is provided by the self-verifiable aggregate-signature artifact and the Verify process.

Verify checks the algebraic consistency among ${\sigma }_{\mathrm{agg}}$, the presented encoded messages $\left\{E{M}_i\right\}$, the common period t, and the public keys resolved from the associated metadata. Any modification of these verification-relevant components changes the aggregate verification equation and causes verification to fail, except with negligible probability under the assumptions of the underlying scheme.

6.1.5. Privacy

For this instantiation, the privacy requirement is realized only in a limited representation-level sense. As in the other requirements evaluated above, the concrete artifact is assessed with respect to the processes used in Section 5. The $\mathsf{Agg}$ process combines the individual signature components into a single aggregate signature component, and $\mathsf{Seal}$ is a no-operation, so that $\widehat{P}=P^{\ast }$. The verifier then applies $\mathsf{Verify}$ to the presented aggregate-signature artifact rather than to the original JWTs.

Concretely, the presented artifact is

$$P^{\ast }=\left(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathsf{meta}}_i)\right\}}_{i=1}^n\right),$$

which is not a standard JWT for $n\ge 2$.

In this representation, the JWT bodies and individual JWT signature values are not directly presented to the verifier. The verifier performs aggregate verification over the encoded messages $E{M}_i$, the aggregate signature ${\sigma }_{\mathrm{agg}}$, the common period t, and the public keys resolved from the associated metadata. Thus, the construction reduces the direct presentation of full JWTs and individual JWT signature components.

This reduction, however, does not amount to full privacy protection. Each $E{M}_i$ remains included in the presented artifact as a verification input and is deterministically derived from the corresponding JWT signing input through the RS256 preprocessing step. Accordingly, $E{M}_i$ should not be interpreted as an encrypted claim, a hiding commitment, a zero-knowledge representation, or a selective-disclosure representation. The construction therefore does not provide claim-level selective disclosure, policy-based minimum disclosure, zero-knowledge privacy, or simulator-based privacy. In addition, the metadata ${\left\{{\mathsf{meta}}_i\right\}}_{i=1}^n$ required for public-key resolution may disclose issuer-related information.

6.2. Analytical Performance Evaluation

This subsection summarizes the asymptotic characteristics of the proposed construction, in comparison with ordinary individual JWT presentation. Let n be the number of authentication results to be presented, k be the number of message chunks obtained from each encoded message $E{M}_i$, and B be the size of one RSA signature component.

Table 3. Analytical comparison.

Item	Individual JWT Presentation	Proposed Construction
Presented artifact size	$O\left(n\right)$	$O\left(n\right)$
Raw signature component	$nB$	B
Verifier-side computation	$O\left(n\right)$	$O\left(1\right)+O\left(nk\right)$
Public key size per authority	$O\left(1\right)$	$O\left(k\right)$
Issuer-side signing	ordinary RS256 signing	HW18 Method 1 signing

n: the number of authentication results. B: the size of one RSA signature component. k: the number of chunks obtained from one encoded message $E{M}_i$.

summarizes the comparison.

In ordinary JWT presentation, the verifier receives n JWTs, and each JWT contains its own RSA signature component. Thus, the raw signature-component size is $nB$. In the proposed construction, the individual signature components are aggregated into a single aggregate signature ${\sigma }_{\mathrm{agg}}$, and the raw signature-component size is reduced to B.

This reduction does not imply that the complete presented artifact becomes constant size. The proposed artifact has the form $P^{\ast }=(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathrm{meta}}_i)\right\}}_{i=1}^n)$. Therefore, the artifact still contains one encoded message and one metadata item per authority, and its complete size remains $O\left(n\right)$. The proposed artifact does not directly include the original JWT payload JSON. Instead, it includes the RS256-derived encoded message $E{M}_i$. This difference concerns the representation of the presented artifact and should not be interpreted as zero-knowledge privacy or claim-level selective disclosure. Thus, the benefit of the proposed construction should be interpreted narrowly. It reduces the raw signature component and changes the presentation format from multiple independently signed JWTs to a single aggregate-signature artifact, but it does not reduce all presentation data to constant size. The verifier still receives one encoded message and one metadata item per authority.

For verification, ordinary JWT presentation requires standard RS256 verification for each JWT and therefore scales as $O\left(n\right)$. In the proposed construction, the aggregate signature contributes one signature-side exponentiation. However, for each encoded message $E{M}_i=m_{i,1}\parallel \cdots \parallel m_{i,k}$, the verifier must also compute the public-key/message-dependent term $U_{i,0}·{\prod }_{j=1}^k{U}_{i,j}^{m_{i,j}}modN$. This requires k modular exponentiations per authentication result. Thus, the verifier-side computation is $O\left(1\right)+O\left(nk\right)$, and the $O\left(nk\right)$ term remains the dominant component. For RSA-2048 encoded messages and chunk size ℓ, the number of chunks is $k=2048/\mathcal{\ell }$. Thus, the choice of ℓ directly affects both verifier-side computation and public-key size.

On the issuer side, the proposed construction uses HW18 Method 1 signing rather than ordinary RS256 signing. Therefore, ordinary RS256 signatures cannot be reused as-is. HW18 Method 1 requires stateful logarithmic storage at the issuer, and its operational implications are discussed in Section 6.5.

6.3. Prototype Implementation and Experimental Setup

• Environment. The evaluation was conducted on macOS 26.3.1 with 64 GB RAM, an Intel x86-64 CPU, 8 physical cores, and 16 logical processors. The prototype was implemented in Python 3.12.13 using OpenSSL 3.5.5 and cryptography 48.0.0.
• Parameters. The prototype used RSA-2048. Each RS256-derived encoded message $E{M}_i$ therefore had length 2048 bits. The number of presented authentication results was set to $n\in \{1,2,4,8\}$. For verifier-side execution-time evaluation, the number of message chunks was set to $k\in \{8,16,32,64\}$. For the artifact-size evaluation, the JWT payload size was set to 512 bytes, one RSA signature component was 256 bytes, and one metadata item was 64 bytes. The range of n was chosen to reflect account-holding proof scenarios in which a verifier evaluates evidence from a small number of independent authorities.

Issuer-side signing in the proposed construction was implemented using HW18 Method 1. Thus, the prototype generated HW18-compatible signatures over RS256-derived encoded messages, rather than reusing ordinary RS256 signatures as-is. The aggregate verification equation was the HW18 verification equation applied to the derived encoded messages.

• Metrics. We measured the size of the presented artifacts, the raw signature-component size, and the verifier-side execution time. In this evaluation, the presented artifact size is also used as an application-layer estimate of the communication payload that must be sent to the verifier. This estimate does not include transport-layer overhead, HTTP headers, TLS framing, or deployment-specific serialization costs. For ordinary JWT presentation, we measured the total size of n RS256 JWTs and the time required to verify them individually. For the proposed construction, we measured the estimated size of $P^{\ast }=(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathsf{meta}}_i)\right\}}_{i=1}^n)$ and the time required for aggregate verification. The verifier-side timing evaluation was conducted under multiple k settings in order to examine the effect of the number of message chunks on aggregate verification overhead.

6.4. Prototype-Based Results

The prototype confirmed that correctly generated aggregate artifacts are accepted for RS256-derived encoded messages. It also rejected malformed artifacts, including tampered encoded messages, wrong-period aggregates, and public-key mismatches. We then evaluated the presentation size, signature-component size, and verifier-side execution time of the proposed construction. These checks were used only to confirm the consistency of the implemented artifact. The following evaluation focuses on artifact size and verifier-side overhead.

• Presentation artifact size. 

  Table 4. Presented artifact size and raw signature-component size for 512-byte JWT payloads.

  n	Presented Artifact Size [Bytes]		Raw Signature Component [Bytes]
  	Individual JWTs	Proposed Artifact	Individual JWTs	Proposed Artifact
  1	1063	580	256	256
  2	2126	900	512	256
  4	4252	1540	1024	256
  8	8504	2820	2048	256

  The individual-JWT artifact size is the total size of n complete RS256 JWTs. The proposed artifact size is estimated as one aggregate signature, n RS256-derived encoded messages, n metadata items, and the period value.

  reports two size-related comparisons: the total presented-artifact size and the raw signature-component size. The former provides an application-layer estimate of the communication payload required for presentation to the verifier, while the latter isolates the size of the cryptographic signature component. The table uses JWT payloads of 512 bytes and metadata items of 64 bytes. In ordinary JWT presentation, the verifier receives n complete JWTs. In the proposed construction, the verifier receives $P^{\ast }=(t,{\sigma }_{\mathrm{agg}},{\left\{(E{M}_i,{\mathrm{meta}}_i)\right\}}_{i=1}^n)$.

The proposed artifact was smaller than the ordinary multiple-JWT presentation under this experimental setting. However, the proposed artifact still includes one encoded message and one metadata item per authority. Therefore, this result should be interpreted as a reduction in the presented artifact size under the evaluated representation, not as a constant-size presentation. The complete artifact remains linear in n. Figure 5 visualizes the same comparison. Both presentations grow linearly in n, but the proposed artifact has a smaller slope under the evaluated representation because complete JWTs are not presented as-is and the n individual signature components are replaced by one aggregate signature component. For example, when $n=8$, the evaluated representation reduces the presented artifact size from 8504 bytes to 2820 bytes and the raw signature component from 2048 bytes to 256 bytes.

• Verifier-side execution time. 

  Table 5. Verifier-side execution time under multiple k settings.

  n	RS256 [ms]	Aggregate Verification [ms]
  		$\mathit{k}=\mathbf{8}$	$\mathit{k}=\mathbf{16}$	$\mathit{k}=\mathbf{32}$	$\mathit{k}=\mathbf{64}$
  1	0.039	29.483	34.566	36.164	53.273
  2	0.076	60.595	61.983	67.619	88.389
  4	0.149	121.145	124.021	131.048	177.050
  8	0.297	235.356	236.383	258.460	355.610

  shows the verifier-side execution time for ordinary RS256 JWT verification and aggregate verification under multiple k settings. Each verifier-side measurement was repeated 30 times after 10 warm-up executions, and the median execution time is reported.

The aggregate verifier becomes slower as n increases. This is consistent with the aggregate verification equation, because the verifier must evaluate public-key and message-dependent terms for each presented authentication result. The effect of k is also visible: larger values of k increase the number of chunk-dependent exponentiations, and $k=64$ shows the largest cost in all measured cases. The largest evaluated parameter setting was $n=8$ and $k=64$, for which aggregate verification required $355.610\mathrm{ms}$. By contrast, ordinary RS256 verification for $n=8$ required $0.297\mathrm{ms}$.

Thus, ordinary RS256 JWT verification remains substantially faster across all measured settings. The proposed construction should therefore not be interpreted as an acceleration technique for JWT verification. The result instead shows a tradeoff: the construction reduces the raw signature component and the presented artifact size under the evaluated representation but increases verifier-side execution time.

6.5. Discussion

Taken together, the analytical and prototype results show that the proposed construction is an artifact-level aggregation mechanism, not a speed-up method for ordinary JWT verification. Its main quantitative benefit is the reduction in the raw signature component from $nB$ to B. In the evaluated representation, the presented artifact size is also smaller than ordinary multi-JWT presentation. However, the complete artifact remains linear in the number of authorities, because each encoded message $E{M}_i$ and its metadata must still be included. The verifier-side cost also remains per-input in nature: although the signature-side exponentiation is reduced to a single aggregate-signature exponentiation, the public-key/message-dependent terms for each encoded message dominate aggregate verification time.

A representative use case is a third-party eligibility assessment in which an applicant must demonstrate that authentication results from several independent authorities are available within a common period. For example, a financial service provider may require an applicant to show that authentication results from three designated institutions are available as part of a screening process. In such a setting, the verifier’s concern is whether valid authentication results from the required set of authorities exist, rather than inspecting the contents of each individual JWT. The proposed construction addresses this setting by transforming the individual signature components into a single aggregate artifact. Compared with ordinary multi-JWT presentation, this reduces the raw signature-component data from $nB$ to B and avoids providing the verifier with the original JWTs or the individual per-token signature values that could be directly re-presented as standalone JWTs. This does not eliminate all replay or misuse risks, but it reduces the exposure of independently reusable token-level artifacts. This type of use case differs from everyday login or high-frequency authorization. It is better characterized as a low-frequency proof-presentation setting, such as eligibility assessment, administrative screening, compliance review, or corporate onboarding, where the verifier evaluates whether the required evidence exists under a predefined policy. In such settings, the value of the construction lies in the form of presentation and evidence aggregation, rather than in reducing authentication latency.

The verifier-side measurements in Section 6.4 show that aggregate verification is substantially slower than ordinary RS256 JWT verification, although it remains below one second in all evaluated settings. The largest measured aggregate-verification time was $355.610\mathrm{ms}$ for $n=8$ and $k=64$, whereas ordinary RS256 verification for $n=8$ required $0.297\mathrm{ms}$. This makes the construction unsuitable for high-frequency inline authentication or instant-response authorization that expects ordinary JWT-like latency. However, in low-frequency eligibility-assessment or proof-submission scenarios, where proof presentation occurs once per application or review, the overhead may be acceptable in exchange for aggregating evidence from multiple authorities. For high-frequency authentication or authorization flows, ordinary JWT verification remains more appropriate.

The deployment of the proposed construction requires HW18-compatible issuer-side signing. Since the construction uses HW18 Method 1, issuers must maintain stateful signing storage and manage period progression. In practical deployments, this requires preventing period reuse and rollback and maintaining state consistency across backup, key rotation, and multi-instance issuer deployments.

Finally, as discussed in Section 5.5.3 and Section 6.1.5, the privacy benefit of the construction is limited to representation-level disclosure reduction. The proposed artifact avoids presenting the original JWTs and individual JWT signature values, but it still includes RS256-derived encoded messages and metadata. Therefore, the construction should not be interpreted as providing claim-level selective disclosure, policy-based minimum disclosure, zero-knowledge privacy, or simulator-based privacy.

7. Related Work

This section reviews prior studies and standardization efforts relevant to this study. In particular, we examine the literature from three perspectives: (1) account federation and the use of ID tokens, (2) VC/VP and selective disclosure techniques, and (3) the development of multisignature and aggregate-signature schemes. To clarify the position of the present study,

Table 6. Comparison of representative models and our system model.

Model Approach	Primary Objective	Input EvidenceGranularity	Presented Granularity	Verification Handling
Conventional JWT	Single-token presentation	Single	Single	Single-object verification
SD-JWT	Selective disclosure for tokens	Single	Single	Single-object verification
VC/VP	Multi-credential presentation	Multiple	Multiple	Multi-object verification
Batch verification	Faster signature verification	Multiple	Multiple	Batched multi-object verification
Our system model	Aggregated proof for third-party verification	Multiple	Single aggregated	Single aggregated- object verification

compares representative models in terms of the granularity of the evidence handled by the user, the granularity of what is ultimately presented to the verifier, and the corresponding verification handling. Table 6 is intended as a model-level and conceptual comparison. It does not assign concrete cryptographic instantiations or scheme-specific performance values to all models. Such values depend on the parameters and deployment assumptions of each concrete scheme. The quantitative evaluation of the concrete construction in this paper is therefore provided separately in Section 6.4.

In this paper, a proof token does not denote a new concrete credential format intended to replace JWTs or VCs. Rather, it serves as a generic term for a basic evidence object issued by an authority to a user. The principal aim of our system model is not to enumerate multiple received credentials individually but to enable the user to construct a single aggregated presentation proof by selecting and aggregating such received objects according to an acceptance policy and, when necessary, applying sealing so that a third party can evaluate policy-based account-evidence evaluation conditions while reducing direct disclosure where the concrete construction supports it.

7.1. Account Federation and the Use of ID Tokens

For OAuth 2.0 and OpenID Connect (OIDC), a substantial body of research has accumulated through formal analyses and implementation-oriented validation studies [10,11,12]. By contrast, the setting considered in this study, namely, presenting authentication results issued by multiple IdPs (e.g., ID tokens) to a third party, has received comparatively limited systematic treatment. In this setting, the main issues include excessive disclosure, dependence on specific IdPs, including the concentration of trust and single points of failure, and the need to support policy-based evaluation of account-related evidence under disclosure constraints while maintaining practical verification efficiency.

To mitigate IdP dependence, several single sign-on (SSO) schemes have been proposed that distribute or thresholdize issuance functionality [13,14]. However, their primary concern is the decentralization of the issuance infrastructure rather than disclosure-limited third-party presentation or aggregate verification of evidence objects.

The balance between minimal disclosure and accountability has also been studied in related areas. Prior studies have discussed the limitations, requirements, post-quantum extensions, and cloud-based deployment of anonymous and two-factor authentication [15,16,17,18]. In distributed ledger and Web3 settings, zero-knowledge-based schemes have been proposed to support verification with limited disclosure [19,20,21,22].

Simultaneously, only a limited number of studies have explored the integration of OAuth/OIDC with other mechanisms in new application settings [23,24], while the IETF has standardized Selective Disclosure for JSON Web Tokens (SD-JWT) as RFC 9901 [25]. In decentralized identity and Web3 contexts, account linkage methods intended to balance anonymity and accountability have also been proposed. Examples include approaches that combine anonymity and uniqueness using zero-knowledge proofs or linkable signatures [26], as well as schemes that link Web3 accounts based on Web2 certificates or account abstraction [27,28,29].

From the perspective of Table 6, the conventional JWT is a single to single model. A user handles a single token as input and presents that single token to a verifier, with verification likewise performed on a single-item basis. This model is well-suited for conveying a single authentication result, but when multiple authentication results must be handled together, the presentation and verification remain essentially separate for each token. SD-JWT may be understood as an extension of this model with selective disclosures. Its basic evidence granularity remains single at both the input and presentation stages, and verification is still performed on a single-item basis. Accordingly, SD-JWT advances disclosure minimization in token-based presentations, but it is not primarily intended to change the granularity of presentation or verification across many credentials.

7.2. VC/VP and Selective Disclosure Techniques

From the perspective of presenting and verifying multiple credentials under disclosure constraints, VC/VP and selective disclosure techniques constitute the most closely related lines of work. In the W3C Verifiable Credentials Data Model, a holder can construct a Verifiable Presentation (VP) that bundles multiple Verifiable Credentials (VCs), and a VP may include a cryptographic proof [30,31]. As selective disclosure techniques, BBS+ and SD-JWT have been proposed, and BBS-family schemes are being standardized as cryptosuites for VCs [25,32,33].

Simultaneously, the verification of a VP is typically performed on a per-VC or per-proof basis [30], and the verification cost may therefore increase with the number of presented items [34,35]. In particular, proofs derived based on BBS+ are, in principle, verified independently for each proof [32,33].

Related studies have also examined how limited disclosure can be combined with accountability through tracing or revocation, for example, in traceable or revocable attribute-based cryptography and conditional privacy-preserving authentication [36,37]. These approaches are important for accountability, but they do not directly address the increase in verification costs caused by many proofs within a VP. Thus, VC/VP and selective disclosure techniques are highly effective for privacy minimization and flexible presentation design, although efficiency may still become a practical concern when many credentials or proofs are presented simultaneously.

In terms of problem setting, the present work is closest to the VC/VP model, as both consider how a user may handle and present multiple credentials that may be evaluated under a common acceptance context. As shown in Table 6, VC/VP is a multiple-to-multiple model in which multiple evidence objects are carried into the presentation, and verification remains multi-item in nature. However, the primary emphasis of the present study is not identical. Whereas VC/VP principally provides a presentation model with strong support for privacy-preserving disclosure, our system model is designed to transform multiple input evidence objects into a single aggregated presented object and to treat signature-component aggregation and artifact-level presentation as explicit design objectives, in addition to bundled presentation. More specifically, our model allows multiple proof tokens to be selected according to an acceptance policy, aggregated into a single presentation proof, and, when necessary, transformed into a sealed proof that is suitable for third party verification. Accordingly, the contribution of the present work is not to supersede VC/VP but to provide a system-level account-holding-proof architecture in which multi-credential input is combined with a single aggregated presentation and corresponding verification handling. This verification still includes per-item encoded-message and public-key terms and therefore should not be understood as eliminating all per-item verification inputs.

7.3. Signature Aggregation and Batch Verification

Cryptographic techniques for handling many signatures can be broadly divided into two directions. The first is signature-aggregation techniques, including aggregate signatures and related multisignature schemes, which represent multiple signatures or signers through a compact signature representation. The second is batch verification, which keeps individual signatures intact while accelerating their verification.

Aggregate-signature and multisignature research has largely developed through work on bilinear-map-based constructions and related aggregation models [38,39,40,41]. RSA-based aggregate signatures are comparatively less common, but several constructions and related variants have been proposed under RSA-based or trapdoor-permutation-based settings [9,42,43,44,45]. Lysyanskaya et al. gave an early trapdoor-permutation-based sequential aggregate-signature construction [42]. Ahn et al. introduced synchronized aggregate signatures, in which only signatures generated within a common period can be aggregated [41]; this line was later realized under the RSA assumption by Hohenberger and Waters [9].

Batch verification addresses a different problem. It reduces the cost of verifying many signatures, but the signatures and corresponding evidence objects remain individually represented [46,47]. Recent applications continue to use batch-verification techniques in protocol and communication settings [48,49].

The proposed model is closer to the aggregate-signature direction because it aims to transform multiple authority-issued evidence objects into a single verifier-facing presentation artifact. In the concrete JWT-derived construction, aggregate signatures are used to avoid presenting multiple individual JWT signatures as separate signature components while allowing the verifier to evaluate the resulting artifact under its acceptance policy.

8. Conclusions

This study considered two issues in conventional account linkage: dependence on a specific IdP or linkage mechanism and the exposure of more information than is required for a verifier’s acceptance policy. To address these issues, we formalized a model for account-holding proofs across multiple authorities. The model supports third-party evaluation of a presented artifact under specified system assumptions and acceptance policies while distinguishing such evaluation from a cryptographic proof of real-world subject identity. As a concrete example, we presented a construction from JWT-derived evidence using RSA-based synchronized aggregate signatures applied to the signing target obtained through RS256 preprocessing of JWTs, thereby enabling aggregate verification of signatures corresponding to multiple authentication results.

From a theoretical and prototype-based perspective, we showed that the raw signature-component data to be presented can be reduced from $nB$ to B. We also showed that the exponentiation applied to the presented signature component is reduced to one aggregate-signature exponentiation, while the overall verifier-side computation remains dominated by per-encoded-message public-key terms. These results should not be interpreted as showing faster verification than ordinary RS256 JWT verification; rather, the construction is suited to one-time or low-frequency proof-presentation scenarios where additional verifier-side latency is acceptable.

Simultaneously, the proposed scheme does not assume a setting in which ID tokens in existing JWT/OIDC environments are presented and verified without modification. Its application requires each IdP to generate signatures in a manner compatible with synchronized aggregate signatures and multiple IdPs to align their handling of the period parameter t. Moreover, the proposed scheme directly handles only the verification of signatures corresponding to the authentication results. Accordingly, the evaluation of JWT claim contents and mechanisms for disclosing only the necessary attributes are outside the scope of the proposed scheme alone. In addition, the validity of public-key registration is delegated to existing PKI.

Future work includes developing operational methods for aligning the handling of the period parameter t across multiple IdPs, reconsidering how the validity of public-key registration should be confirmed, and integrating claim-level or policy-based selective disclosure techniques.