<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Bridging eIDAS 2.0 Legal Requirements and Technical Solutions</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Giuseppe De Marco</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Francesco Antonio Marino</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Andrea De Maria</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department for Digital Transformation of the Presidency of the Council of Ministers</institution>
          ,
          <addr-line>Rome</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Italian Government Printing Ofice and Mint</institution>
          ,
          <addr-line>Rome</addr-line>
          ,
          <country country="IT">Italy</country>
        </aff>
      </contrib-group>
      <fpage>18</fpage>
      <lpage>30</lpage>
      <abstract>
        <p>In the evolving landscape of digital identity, the Italian Digital Wallet (IT-Wallet) stands out as a pioneering initiative that exemplifies a holistic approach to integrating legal requirements with innovative technical solutions. This paper aims to explore the comprehensive strategy behind the IT-Wallet, focusing on how it meets the legal frameworks provided by the new eIDAS regulation. The eIDAS regulation has been instrumental in establishing trust and security for electronic transactions across the European Union. The IT-Wallet project goes a step further by analyzing these legal requirements and translating them into technical solutions that enhance security and privacy. We will delve into a specific example such as Person Identification Data (PID) Issuance, showcasing the technical implementations that address these legal mandates.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;eIDAS 2</kwd>
        <kwd>0</kwd>
        <kwd>Regulation</kwd>
        <kwd>IT-Wallet</kwd>
        <kwd>Digital Identity</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        In this paper, we have analyzed the delta of changes that the Parliament legislative resolution
made on the eIDAS Regulation, also approved by the European Council considering:
• The European Parliament legislative resolution of 29 February 2024 [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ].
• The Regulation of the European Parliament and of the Council amending Regulation (EU)
No 910/2014 as regards establishing the European Digital Identity Framework of 13 March
2024 [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>In Section 2 we provide an analysis of the Legislative text and a methodology to classify
the Legal text into requirements. Therefore, in Section 3 we focus on the PID Issuance phase
extracting a subset of items that are relevant to PID Issuance. Then, we provide an overview of
the Italian PID Issuance Flow in Section 4 highlighting how the Italian implementation profile
aligns with the relevant regulatory framework. Finally, in Section 5, we summarize the main
results.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Analysis and Classification of Legislative text</title>
      <p>
        The new eIDAS 2.0 regulation is composed of three main parts, these are:
Recitals. They provide the background, rationale, and objectives behind the eIDAS Regulation
[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. They explain the context and reasons for the provisions that follow. Recitals are used to
interpret and understand the intentions of the legislature and the scope of the normative
provisions within the legal act1. In particular, we found one new Recital at position 67, and 70
updated Recitals upon 78.
      </p>
      <p>Articles. They outline the obligations, rights, and procedures for Member States, entities, and
individuals. We found very important changes (3 Deleted, 10 Replaced, 24 Amended, and 33
Inserted) as summarized in Table 1.</p>
      <p>Annexes. They include practical details necessary for compliance with the regulation. Delving
into the Annexes we found a few changes in the first four annexes and, in addition to these,
four new Annexes (see Table 2). In particular:
• “Annex V ”, provides requirements for Qualified Electronic Attestation of Attributes (EAAs).
• “Annex VI ”, contains the list of the required user attributes to be implemented.
• “Annex VII ”, contains requirements for EAAs issued by or on behalf of a Public Body
responsible for an Authentic Source.
• “Annex To The Legislative Resolution” contains two statements, one containing
considerations for web browser vendors and another one about the untraceability of wallet users,
that aims to prevent data collection by wallet providers.
1The distinction between normative and informative elements in EU legislation, including the role of recitals, is a
well-established aspect of EU legal doctrine. This understanding is derived from the jurisprudence of the Court of
Justice of the European Union (CJEU) and the practices of legal interpretation within the EU. The CJEU often refers
to recitals when interpreting the provisions of EU legislation to understand the intentions of the legislature and the
context of the laws.</p>
      <sec id="sec-2-1">
        <title>2.1. Classification</title>
        <p>After reviewing all the articles and annexes, we categorized them by items and classified each
item according to its related subject and scope. Subjects we identified are: European Commission,
EUDI Wallets, Member States, and Relying Parties. The scopes we defined are: Governance,
Issuance, Presentation, and Wallet Solution.</p>
        <p>In our matrix, we also included additional elements (e.g. requirements currently fulfilled,
planned in the roadmap, project constraints, and additional notes) to better manage our national
wallet implementation and our national milestones. This work resulted in the analysis of the
delta of changes in the eIDAS regulation from an implementation perspective and also a
selfassessment matrix that aims to guide us in our developments about the national wallet solution.
An extract of this classification matrix is given in Table 3 where for the sake of simplicity we
omitted elements related to our national wallet implementation.</p>
      </sec>
      <sec id="sec-2-2">
        <title>2.2. Results</title>
        <p>The classification of the items has clarified the distribution of normative elements across the
distinct domains of the wallet ecosystem. As depicted in the pie chart in Figure 1, a significant
proportion is attributed to the governance of the ecosystem. Within the scope of Governance,
we have further delineated sub-categories encompassing general aspects related to certification
and accreditation procedures and roles, wallet provisioning, and the security framework, among
others. Additionally, we have identified items related to the characteristics of the wallet solution,
the issuance of digital credentials, and the presentation of digital credentials.</p>
        <p>In Appendix A, Tables 6, 7 and 8, we summarize the relevant requirements extracted by the
regulation and related to Issuance, Presentation and Wallet Solution, respectively.</p>
        <p>European Digital Identity Wallets shall be provided in one
or more of the following ways: (a) directly by a Member
State; (b) under a mandate from a Member State; (c)
independently of a Member State but recognised by that
Member State.</p>
        <p>Member State shall inform users, without delay, of any
security breach that could have entirely or partially
compromised their European Digital Identity Wallet or its
contents, in particular, if their European Digital Identity Wallet
has been suspended or revoked pursuant to Article 5e.</p>
        <p>European Digital Identity Wallets shall, in particular: (a)
support common protocols and interfaces: [. . . ] (i) for
issuance of person identification data, qualified and non
qualified electronic attestations of attributes or qualified
and non-qualified certificates to the European Digital
Identity Wallet;
European Digital Identity Wallets shall, in particular: (a)
support common protocols and interfaces: [. . . ] (ii) for
relying parties to request and validate person identification
data and electronic attestations of attributes;</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3. Understanding the Regulatory Framework for PID Issuance</title>
      <p>This section delves into the process of identifying and translating legal requirements into
technical specifications for the PID issuance phase. The starting point was a comprehensive
analysis of the European Digital Identity Wallet regulation, specifically Article 5(a). From this
extensive set of provisions, a subset of items directly relevant to PID issuance was carefully
extracted.</p>
      <p>The identified legal requirements, outlined in Table 4, form the foundation for the technical
development of the Italian PID issuance process. These requirements encompass essential
aspects such as:
• Security and Selective Disclosure: Ensuring user control over personal identification data
and enabling selective disclosure.
• Protocols and Interfaces: Supporting standardized protocols and interfaces for PID
issuance.
• User Onboarding: Facilitating secure user onboarding using electronic identification
means.
• User Identification and Association: Guaranteeing the unique representation of the user
and linking their identity to the European Digital Identity Wallet.</p>
      <p>By focusing on these core elements, the subsequent Sections aimed to develop technical
solutions that efectively address the legal mandates while implementing the PID issuance
process for Italian citizens.</p>
    </sec>
    <sec id="sec-4">
      <title>4. Overview of the Italian PID Issuance Process</title>
      <p>
        This Section examines how the Italian implementation profile of the Wallet [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] aligns with the
relevant regulatory framework, with a particular focus on the issuance phase. By dissecting
the process into its constituent sub-phases, this Section aims to provide a comprehensive
understanding of the mechanisms employed to ensure user identification, data protection, and
security.
      </p>
      <sec id="sec-4-1">
        <title>4.1. Data Format</title>
        <p>
          Selective Disclosure JWT (SD-JWT) [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ] is a specification that introduces conventions to support
selective disclosure for JWTs: for an SD-JWT document, a Holder can decide which claims to
release (within bounds defined by the Issuer). SD-JWT-based Verifiable Credentials specification
(SD-JWT-VC) [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ] uses SD-JWT and the well-established JWT content rules and extensibility
model as basis for representing Verifiable Credentials with JSON payloads, and it is one of
the data format of the Italian Personal Identification (PID) system, designed to meet specific
regulatory requirements while ensuring data privacy and security. This section delves into how
this format addresses requirements R1 and R4.
        </p>
        <p>Requirement R1 mandates that European Digital Identity Wallets enable users to securely
request, obtain, and control their personal identification data, allowing for selective disclosure.
The SD-JWT-VC format directly supports this by:
• Selective Disclosure: The data model allows for granular control over which attributes
within the PID are revealed in a given presentation. This ensures that only necessary
information is released, protecting sensitive data from unnecessary exposure.
European Digital Identity Wallets shall enable the user, [. . . ], Art. 5a(4)(a)
to securely request, obtain, [. . . ], under the sole control of
the user, person identification data [. . . ], while ensuring
that selective disclosure of data is possible
European Digital Identity Wallets shall support common
protocols and interfaces for issuance of person
identification data, qualified and non-qualified electronic
attestations of attributes or qualified and non-qualified certificates
to the European Digital Identity Wallet;
European Digital Identity Wallets shall support common
protocols and interfaces to securely onboard the user by
using an electronic identification means in accordance with
Article 5a(24)
European Digital Identity Wallets shall ensure that the
person identification data, which is available from the
electronic identification scheme under which the European
Digital Identity Wallet is provided, uniquely represents the
natural person, legal person or the natural person
representing the natural or legal person, and is associated with
that European Digital Identity Wallet
• Cryptographic Key Binding: Each PID is bound to a specific Wallet Instance through a
cryptographic key. This binding mechanism provides a strong guarantee of possession,
as it ensures that only the rightful holder of the corresponding private key can present
the PID.
• Data Minimization: The requirement for a minimum dataset reduces the amount of
personal data collected and stored, aligning with data protection principles.</p>
        <p>Requirement R4 stipulates that the PID data uniquely represents the user and is
associated with the European Digital Identity Wallet (EUDIW). The SD-JWT-VC format fulfills this
requirement through:
• Unique Identification: The data model includes attributes that collectively and uniquely
identify the user, ensuring that each individual has a distinct digital identity within the
system.
• Association with EUDIW: The cryptographic key binding ties the PID to a specific Wallet
Instance, efectively linking the user’s identity to their EUDIW. This association is crucial
for maintaining data integrity and preventing identity fraud.</p>
        <p>In conclusion, the SD-JWT-VC data format for the Italian PID efectively addresses the
core aspects of requirements R1 and R4. By providing mechanisms for selective disclosure,
cryptographic key binding, and unique user identification, this format contributes to a secure,
privacy-preserving, and reliable PID issuance.</p>
      </sec>
      <sec id="sec-4-2">
        <title>4.2. Issuance Flow</title>
        <p>
          1. Registration with Federation API Endpoints [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ]: The process begins with the PID Provider,
Wallet Provider, and Registration Service registering with the Federation API Endpoints.
This step ensures that these entities are evaluable as trustworthy according to the trust
framework in use.
2. Attestation Service Registration: Following the initial registration, the Attestation Service
provides the Wallet Attestation to the Wallet Instance. This step is crucial for establishing
the authenticity and genuineness of the Wallet Instance and the compliance with the
security requirements related to both the Hardware and the Software.
3. Metadata Exchange and Trust establishment: This step involves the exchange of metadata
to facilitate trust and interoperability between these entities. The PID Provider checks
that the Wallet Instance is authentic and valid, and the Wallet Provider is a trusted entity.
        </p>
        <p>The Wallet Instance checks that the PID Provider is a trusted entity.
4. User Requests PID: The user initiates the process by requesting a PID.
5. User Authentication: This step ensures that the user’s identity is verified through the
national digital identity system.
6. PID Issuance: Finally, this step completes the process by providing the Wallet Instance
with a valid user’s PID.</p>
        <p>This flowchart highlights the intricate interactions between various systems to provide a
streamlined and secure identity verification process. It underscores the importance of user
privacy and data integrity at each stage of authentication and registration.</p>
        <p>
          Focusing on steps 4, 5 and 6, we go into more technical details regarding the protocol used
for the issuance of PIDs (see Figure 3). It follows the OpenID for Verifiable Credential Issuance
specification (OID4VCI) [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ], with the following main reference standards/specifications on top:
• The OAuth 2.0 Authorization Framework – RFC 6749 [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ], recommended in [7, Section 3].
• Pushed Authorization Requests (PAR) – RFC 9126 [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ], recommended in [7, Section 5].
• Proof Key for Code Exchange (PKCE) – RFC 7636 [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ], recommended in [7, Section 5].
• JWT Authorization Requests (JAR) – RFC 9101 [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ].
• JWT Authorization Response Modes (JARM) [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ].
• Rich Authorization Requests (RAR) – RFC 9396 [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ].
• OAuth 2.0 Attestation-Based Client Authentication [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ].
        </p>
        <p>
          • OpenID Federation 1.0 [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ].
        </p>
        <p>
          The process is designed to be secure and eficient, ensuring that users can obtain their digital
identities with minimal friction. Key steps in the PID issuance process can be summarized as:
• Authorization Phase, in which the Wallet sends a Push Authorization Request (PAR) to
the PID Provider. It authenticates the client through the Wallet Attestation and establishes
trust by building the Federation Trust Chain related to the Wallet Provider. These checks
are crucial in preventing fraudulent activities and ensuring the integrity of the digital
identity ecosystem. PKCE [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ] is also used as a security best current practice in the
Authorization Code Flow. The adoption of common and secure protocols and interfaces
covers the items we identified with R1 (the security part of the requirement) and R2.
• User Identification Phase , where the user is identified by the PID Provider, which now
acts as a Relying Party and authenticates the user with the national IdP using one of the
available national schemes notified under eIDAS. This covers the item we identified with
R3 about user onboarding and part of R4 regarding user identification.
• Credential Request/Issuance Phase, where the Wallet Instance requests the credential.
        </p>
        <p>
          To do this, it rfist obtains a DPoP sender-constrained Access Token [
          <xref ref-type="bibr" rid="ref15">15</xref>
          ] and uses it on
the protected resource (the credential endpoint) by sending a proof JWT containing a
public key to which the PID must be bound (Holder Key Binding). This proves that the
corresponding private key is under the User’s control, ensuring that only the legitimate
owner can use the PID during the presentation. This binding is achieved through the use of
cryptographic techniques within the JWT. It is worth noting that the Wallet can generate
a new fresh key pair with each PID request, improving user privacy (user unlinkability).
This again covers the security part of the item R1 and part of R4 related to the association
with the Wallet.
        </p>
      </sec>
      <sec id="sec-4-3">
        <title>4.3. Mapping Requirements</title>
        <p>The comprehensive mapping of technical solutions to legal requirements, as presented in
Table 5, underscores the critical alignment between technological advancements and regulatory
frameworks. This alignment is essential for ensuring the security, privacy, and trustworthiness
of digital identity systems.</p>
        <p>The table highlights several key contexts, such as security and data protection, transparency
support, and user onboarding, each associated with specific legal references like the eIDAS
Regulation and GDPR. The technical mechanisms demonstrate compliance with these legal
requirements, ensuring robust and secure digital identity verification processes.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>5. Conclusion</title>
      <p>This paper has presented a detailed examination of the Italian Digital Wallet (IT-Wallet) initiative,
showcasing how it successfully bridges the gap between the legal requirements set forth by the
eIDAS 2.0 regulation and innovative technical solutions. Through a meticulous analysis of the
regulatory framework and its implementation, several key findings emerge:
1. Comprehensive Regulatory Analysis: The study’s classification of legislative text
provides valuable insights into the distribution of normative elements across the wallet
ecosystem, with a significant proportion attributed to governance. This classification
serves as a crucial tool for policymakers and implementers to ensure comprehensive
compliance.
2. Efective Technical Implementation : The IT-Wallet’s approach to Personal
Identification Data (PID) issuance demonstrates a robust alignment with key regulatory
requirements. The adoption of the SD-JWT-VC data format and the implementation of a secure
issuance flow, leveraging protocols such as OpenID for Verifiable Credential Issuance
(OID4VCI), showcase how technical solutions can efectively address legal mandates.
3. Privacy and Security Focus: The implementation details reveal a strong emphasis on
user privacy and data security. Features such as selective disclosure, cryptographic key
binding, and user-controlled data management align closely with the eIDAS 2.0 principles
of data minimization and user empowerment.
4. Interoperability and Standardization: The IT-Wallet’s adherence to common protocols
and interfaces, as mandated by eIDAS 2.0, contributes to the broader goal of creating an
interoperable digital identity ecosystem across the European Union.</p>
      <p>The IT-Wallet initiative serves as a prime example of how regulatory compliance can drive
innovation in digital identity solutions. By carefully mapping technical mechanisms to legal
requirements, the project demonstrates the feasibility of creating a secure, privacy-preserving,
and user-friendly digital identity wallet that meets the stringent standards set by eIDAS 2.0.</p>
      <p>Future research could explore the practical implications of widespread adoption of such
wallets, including user acceptance, cross-border interoperability challenges, and the evolving
landscape of digital identity threats. Additionally, comparative studies with other national
implementations could provide valuable insights into best practices and areas for further
harmonization across the EU.</p>
      <p>In conclusion, the Italian Digital Wallet project ofers valuable lessons for policymakers,
technologists, and identity providers across the EU. It exemplifies how a thoughtful approach to
regulatory compliance can result in technical solutions that not only meet legal requirements
but also advance the state of the art in digital identity management.</p>
    </sec>
    <sec id="sec-6">
      <title>Acknowledgments</title>
      <p>This work was conducted within the framework of the IT-Wallet Government Initiative, a project
of national significance aimed at advancing digital identity solutions in Italy. The authors would
like to express their sincere gratitude to all the stakeholders involved in this ambitious endeavor.
Special acknowledgment goes to our collaborators at Fondazione Bruno Kessler (FBK) for their
invaluable technical expertise and research contributions. Their insights have significantly
enhanced the robustness and eficacy of the IT-Wallet solution. We also wish to thank PagoPA
S.p.A. for their crucial role in this project. The synergy between governmental bodies, research
institutions, and public-service companies exemplified in this project demonstrates the power
of collaborative eforts in addressing complex challenges in digital identity management. This
cooperation has been essential in bridging theoretical concepts with practical implementations,
ultimately contributing to the advancement of digital services for Italian citizens.</p>
    </sec>
    <sec id="sec-7">
      <title>A. Highlighted Articles</title>
      <p>Wallet shall enable the user to generate pseudonyms and store them encrypted and locally within the
Wallet
Issuance of person identification data, qualified and non qualified electronic attestations of attributes or
qualified and non-qualified certificates to the European Digital Identity Wallet
Possibility of implementing electronic attestation of attributes with embedded disclosure policies to be
applied when interacting with RPs (the Wallet must support)
Person Identification Data (PID) uniquely represents the natural person, legal person or the natural person
representing the natural or legal person, and is associated with that European Digital Identity Wallet
PID/EAA Providers are not allowed in tracking user behaviour or knowledge of transactions of the user
privacy preserving techniques which ensure unlinkability, where the attestation of attributes does not
require the identification of the user</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>European</given-names>
            <surname>Parliament</surname>
          </string-name>
          and
          <article-title>Council of the European Union, Regulation (EU)</article-title>
          <year>2024</year>
          /1183, in:
          <source>Oficial Journal of the European Union</source>
          ,
          <year>2024</year>
          . URL: http://data.europa.eu/eli/reg/2024/1183/.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>European</given-names>
            <surname>Parliament</surname>
          </string-name>
          and
          <article-title>Council of the European Union</article-title>
          ,
          <source>European Parliament legislative resolution of 29 February</source>
          <year>2024</year>
          ,
          <year>2024</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>G.</given-names>
            <surname>De Marco</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Marino</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Grauso</surname>
          </string-name>
          , et al.,
          <source>The Italian EUDI Wallet Implementation Profile</source>
          ,
          <year>2024</year>
          . URL: https://italia.github.io/eudi-wallet
          <string-name>
            <surname>-</surname>
          </string-name>
          it-docs/
          <year>v0</year>
          .8.0/en/, draft 0.8.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>D.</given-names>
            <surname>Fett</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Yasuda</surname>
          </string-name>
          , B. Campbell,
          <article-title>Selective Disclosure for JWTs (SD-JWT), Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-12,</article-title>
          <string-name>
            <surname>IETF</surname>
          </string-name>
          ,
          <year>2024</year>
          . URL: https://datatracker.ietf.org/ doc/draft-ietf
          <article-title>-oauth-</article-title>
          <string-name>
            <surname>selective-</surname>
          </string-name>
          disclosure-jwt/12/, Work in Progress.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>O.</given-names>
            <surname>Terbu</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Fett</surname>
          </string-name>
          , B. Campbell,
          <article-title>SD-JWT-based Verifiable Credentials (SD-JWT VC), Internet-Draft draft-ietf-oauth-sd-jwt-vc-05,</article-title>
          <string-name>
            <surname>IETF</surname>
          </string-name>
          ,
          <year>2024</year>
          . URL: https://datatracker.ietf.org/ doc/draft-ietf
          <article-title>-oauth-</article-title>
          <string-name>
            <surname>sd-</surname>
          </string-name>
          jwt-vc/05/, Work in Progress.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>R.</given-names>
            <surname>Hedberg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Jones</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Solberg</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Bradley</surname>
          </string-name>
          ,
          <string-name>
            <surname>G. De Marco</surname>
          </string-name>
          , V. Dzhuvinov,
          <source>OpenID Federation 1.0</source>
          ,
          <year>2024</year>
          . Draft 36.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>T.</given-names>
            <surname>Lodderstedt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            <surname>Yasuda</surname>
          </string-name>
          , T. Looker, OpenID for Verifiable Credential Issuance,
          <year>2024</year>
          . Draft 13.
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>D.</given-names>
            <surname>Hardt</surname>
          </string-name>
          ,
          <source>The OAuth 2.0 Authorization Framework, RFC 6749</source>
          ,
          <year>2012</year>
          . doi:
          <volume>10</volume>
          .17487/ RFC6749.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>T.</given-names>
            <surname>Lodderstedt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Campbell</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Sakimura</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Tonge</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Skokan</surname>
          </string-name>
          , OAuth
          <volume>2</volume>
          .0
          <string-name>
            <given-names>Pushed</given-names>
            <surname>Authorization</surname>
          </string-name>
          <string-name>
            <surname>Requests</surname>
          </string-name>
          , RFC
          <volume>9126</volume>
          ,
          <year>2021</year>
          . doi:
          <volume>10</volume>
          .17487/rfc9126.
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>N.</given-names>
            <surname>Sakimura</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Bradley</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Agarwal</surname>
          </string-name>
          ,
          <article-title>Proof Key for Code Exchange by OAuth Public Clients</article-title>
          , RFC
          <volume>7636</volume>
          ,
          <year>2015</year>
          . doi:
          <volume>10</volume>
          .17487/rfc7636.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>N.</given-names>
            <surname>Sakimura</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Bradley</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. B.</given-names>
            <surname>Jones</surname>
          </string-name>
          ,
          <source>The OAuth 2</source>
          .0
          <string-name>
            <given-names>Authorization</given-names>
            <surname>Framework: JWTSecured Authorization</surname>
          </string-name>
          <article-title>Request ( JAR)</article-title>
          ,
          <source>RFC 9101</source>
          ,
          <year>2021</year>
          . doi:
          <volume>10</volume>
          .17487/rfc9101.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>T.</given-names>
            <surname>Lodderstedt</surname>
          </string-name>
          , B. Campbell,
          <source>JWT Secured Authorization Response Mode for OAuth 2</source>
          .0 (
          <issue>JARM</issue>
          ),
          <year>2022</year>
          . URL: https://openid.net/specs/oauth-v2-jarm.html.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>T.</given-names>
            <surname>Lodderstedt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Richer</surname>
          </string-name>
          , B. Campbell, OAuth
          <volume>2</volume>
          .0
          <string-name>
            <given-names>Rich</given-names>
            <surname>Authorization</surname>
          </string-name>
          <string-name>
            <surname>Requests</surname>
          </string-name>
          , RFC
          <volume>9396</volume>
          ,
          <year>2023</year>
          . doi:
          <volume>10</volume>
          .17487/RFC9396.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>T.</given-names>
            <surname>Looker</surname>
          </string-name>
          , P. Bastian, OAuth
          <volume>2</volume>
          .
          <article-title>0 Attestation-Based Client Authentication, Internet-Draft draft-ietf-oauth-attestation-based-client-auth-03,</article-title>
          <string-name>
            <surname>IETF</surname>
          </string-name>
          ,
          <year>2024</year>
          . URL: https://datatracker.ietf. org/doc/draft-ietf
          <article-title>-oauth-attestation-</article-title>
          <string-name>
            <surname>based-</surname>
          </string-name>
          client-auth/03/, Work in Progress.
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>D.</given-names>
            <surname>Fett</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Campbell</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Bradley</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Lodderstedt</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M. B.</given-names>
            <surname>Jones</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Waite</surname>
          </string-name>
          , OAuth
          <volume>2</volume>
          .
          <article-title>0 Demonstrating Proof of Possession (DPoP)</article-title>
          ,
          <source>RFC 9449</source>
          ,
          <year>2023</year>
          . doi:
          <volume>10</volume>
          .17487/RFC9449.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>