OIDC²: Open Identity Certification With OpenID Connect

OpenID Connect (OIDC) is a widely used authentication standard for the Web. In this work, we define a new Identity Certification Token (ICT) to enable end-to-end user authentication by using and extending OIDC’s native mechanisms. An ICT can be thought of as a JSON-based, short-lived user certificate for end-to-end user authentication without the need for cumbersome key management. A user can request an ICT from his OpenID Provider (OP) and use it to prove his identity to other users that trust the OP. We call this approach Open Identity Certification with OpenID Connect (OIDC2) and compare it to other well-known end-to-end authentication methods. Unlike certificates, OIDC2 does not require installation and can be easily used on multiple devices, making it more user-friendly. We outline protocols for implementing OIDC2 based on existing standards. We discuss the trust relationship between entities involved in OIDC2, propose a classification of OPs’ trust level, and propose authentication with multiple ICTs from different OPs. We explain how different applications such as video conferencing, instant messaging, and email can benefit from ICTs for end-to-end authentication and recommend validity periods for ICTs. To test OIDC2, we provide a simple extension to existing OIDC server software and evaluate its performance.


Introduction
In most communication services, users identify each other through account profiles in which they provide their own identity information.To make these profiles more trustworthy, social network operators such as Meta and X offer identity verification services for an additional fee that can only be used within their ecosystem.However, identity verification is often a cumbersome process that users may not want to repeat for each of their service platforms.Furthermore, users must still trust the service provider to sufficiently verify identities and not impersonate them.E2E user authentication mechanisms like X.509 certificates or Pretty Good Privacy (PGP) attempt to solve this problem, but often lack adoption due to poor usability caused by the necessity of manual key management.Therefore, reusing an account with a verified identity for E2E user authentication would be desirable.With modern Single Sign-On (SSO) services, users can reuse their existing accounts to log in to other services.The OIDC protocol, which is based on the OAuth 2.0 authorization framework, is widely used for this purpose.However, OIDC is designed for user-to-service authentication and does not address the purpose of E2E user authentication.
In this paper, we developed an OIDC extension for E2E user authentication which is (1) easy to implement and (2) easy to use.Therefore, we define a new ICT for OIDC.It is similar to the ID Token (IDT) which holds identity claims about a user, but also contains a verified public key of the user's client.As such, it can be thought of as a JSON-based, short-lived user certificate without the need for a revocation mechanism.The use of an ICT differs significantly from the use of an IDT.A user requests an ICT from his OP and presents it to another user's client to authenticate himself.

Introduction to OAuth 2.0 and OIDC
We introduce basics of OAuth 2.0 and OIDC, as they are the underlying technologies for OIDC².We discuss their trust relationship and explain how they facilitate SSO.In the following, we capitalize technical terms from the official OAuth 2.0 and OIDC terminology.For ease of understanding, we omit non-essential steps in the protocols and refer to the authoritative standards for details.

OAuth 2.0
The OAuth 2.0 authorization framework, as defined in RFC 6749 [2], is based on Hypertext Transfer Protocol (HTTP) (RFC 7231 [3]) and JSON (RFC 8259 [4]).It allows a user to grant his Client scoped access to his resources on a server, e.g., to only read emails.A Client can be a web application, or a native email client application.In OAuth 2.0, this server is called Resource Server (RS) because it protects the user's Protected Resources (PRs); the user is called the Resource Owner (RO).
Without OAuth 2.0, the RO would leave his credentials with his Client to log in directly to the RS.With OAuth 2.0, the RO logs in to an Authorization Server (AS) and tells the AS to authorize the Client to access a scoped set of PRs.To do this, the AS issues an Access Token (AT) to the Client.This AT allows the Client to access the PRs on the RS.In this way, OAuth 2.0 improves the security by granting Clients only a scoped access to the user's account without exposing the user's credentials to any of the Clients.
Figure 1a shows a simplified authorization request where the RO authorizes his Client to read email.First, the Client requests access to the Scope read email, which authorizes read-only access to the RO's emails (1).Then, the AS authenticates the RO (2) and the RO authorizes the Client for the requested Scope (3).Finally, the AS issues the AT and optionally a Refresh Token (RT) (4).This AT contains the authorized Scopes with a short validity period.It is signed with the AS's private key K − AS .The RT is like a revocable session ID that authorizes the Client to refresh an expired AT without further user interaction.
Figure 1b describes a Resource Request where the Client uses the AT to access PRs on the RS.First, the Client requests the PRs and provides the AT to prove authorization (1).Then, the RS verifies the AT for a sufficient Scope, its expiration date, and the validity of its signature with the AS's public key K + AS (2).Finally, the RS responds with the PRs (3).

OpenID Connect (OIDC)
OIDC [5] is an authentication framework that allows users to be authenticated with an SSO identity through a third-party service, such as an email service.It extends OAuth 2.0 for this purpose.
Unlike the example in Section 2.1, the SSO identity has no relationship to the third-party service.
In OIDC, an End-User (EU) is authenticated by an OP.The EU grants OIDC-specific Scopes to the EU's intended service, e.g., to his email client, which is called the Relying Party (RP).This communication flow is supported by OAuth 2.0, where the EU corresponds to a RO, the OP to an AS, and the RP to a Client.The OP issues an IDT to the RP.This IDT contains claims about the authentication event which typically includes information about the EU, such as his name or address.Since this Authorization Request is for authentication, it is called an Authentication Request in OIDC.With this mechanism, an EU can be authenticated with his SSO identity by different services without providing his credentials.Instead, the OP passes profile information about the EU to the RP as identity claims in the IDT, but the EU controls which information is passed.
Figure 2a describes a simplified Authentication Request where the EU is authenticated by the RP via the OP.First, the RP requests access to the profile Scope.If the EU grants this Scope,

Authentication Response
Access Token, Refresh Token, ID Token  the RP is authorized to access the EU's profile information (1).Then, the EU is authenticated by the OP (2) and authorizes the RP for the requested Scope (3).Finally, the OP issues an IDT in addition to the AT and an optional RT (4).This IDT contains the identity claims related to the authorized profile Scope, such as the EU's name, profile picture, or date of birth, and is signed with the OP's private key K − OP .The RP can verify the signature of the identity claims with the OP's public key K + OP .

Trust Relationship
The following describes the resulting trust relationship between entities in OAuth 2.0 and OIDC as shown in Figure 2b.The Client/RP never sees any credentials from the RO/EU because the authentication process is performed solely by the AS/OP.Therefore, the Client/RP must rely on the AS/OP to correctly verify the identity of the RO/EU and that the AS/OP will issue the correct AT/IDT of the authenticated RO/EU.Once the Client/RP of the RO/EU receives the tokens, the RO/EU may not be able to verify what it is doing with them.The Client/RP may even leak the tokens, so the RO/EU must trust that it is working as intended.To minimize this risk, the RO/EU restricts the Client/RP's access to only the necessary PRs and identity claims.The RO/EU must also trust the AS/OP to protect his identity.This includes a secure login process and secure credential storage, but also that the AS/OP will not impersonate his account.Such impersonation would not even require any credentials since the AS/OP needs only its private key K − AS /K − OP to sign an AT/IDT.

Single Sign-On with OAuth 2.0 and OIDC
Today, many services require dedicated accounts, forcing users to remember multiple service-specific credentials.With SSO systems, users only need to remember the credentials for one account.They can use this SSO identity to log in to multiple service accounts.Logging in to a service account with this SSO identity is typically solved with a combination of OAuth 2.0 and OIDC, as depicted simplified in Figure 3. First, the Client initiates an OAuth Authorization Request to the service-specific AS (1).Instead of using service account credentials, the RO chooses to log in with his SSO identity via OIDC.To do this, the AS acts as a RP and initiates an OIDC Authentication Request to the OP (2).The EU is then authenticated by the OP with his credentials (3) and consents to the OP providing the RP with access to his profile information (4).Technically, this consent is an authorization in the sense of OAuth 2.0.The OP then responds with an IDT to the RP (5), which authenticates the EU to the AS and completes the OIDC-based authentication process.Now the authenticated RO authorizes the requested Scopes of the Client (6).Finally, the AS issues an AT and an optional RT to the Client (7).In an SSO environment, the trust relationship changes slightly.While the user has to trust the AS not to impersonate his service account, he also has to trust the OP not to impersonate any of his service accounts.This makes the OP very powerful because it could impersonate any of the user's service accounts.Therefore, EUs should only choose trusted OPs.

Related Technologies
We review related technologies for E2E authentication and compare them to OIDC².

Identity Providers and Certificates
In a PKI [6], a Certificate Authority (CA) verifies that an entity's real-world identity and long-term public key K + E belong together, records them in a document, signs it, and issues it in the common X.509 certificate format (RFC 5280 [7]).Such X.509 certificates are used, e.g., in the S/MIME standard (RFC 8551 [8]) to authenticate and encrypt email.However, the identity verification is cumbersome and users have to manage their own certificate files, an authentication concept that many people are still unfamiliar with, which is why only 2.50% of over 81 million emails examined in a study [1] were signed with S/MIME.
To simplify this process, Cisco proposed an expired Internet draft [9] where an Identity Provider (IdP) issues X.509 certificates to its users.According to their white paper [10], these certificates are used for challenge/response-based [11] E2E user authentication in the Webex video conferencing service where session partners trust each other's OP.The draft [9] is designed for the Security Assertion Markup Language 2 (SAML2) authentication standard [12], but OIDC performs better for mobile devices and cloud computing [13].This may be one reason why the design has not been adopted by other applications and IdPs.Conceptually, the presented approach is similar to OIDC²; we continue with the differences.X.509 is a binary format limited to a small set of standardized identity-related fields [8], while OIDC² uses the more flexible JSON-based JSON Web Token (JWT) (RFC 7519 [14]) format to represent claims about the user.These claims are signed by the IdP and their formats are standardized in the OIDC Core [5] and eKYC [15] specifications.In addition, longlived user certificates require key revocation mechanisms and error-prone manual key management by the user, whereas short-lived ICTs are issued spontaneously and only require the user to log in.This reduces security issues and improves the user experience.

Self-Sovereign Identity (SSI)
In SSI [16], participating entities generate their own asymmetric key pairs K ± .Entities are identified by their Decentralized Identifier (DID), which is linked to at least one public key K + .Entities store their private key K − in their digital wallet, e.g., an app on their smartphone.This can be used for E2E authentication with the key pair K ± .SSI describes three entities: the Issuer (I), the Holder (H), and the Verifier (V).The issuer knows or verifies the holder's credentials and issues them to the holder as a Verifiable Credential (VC).This VC is signed by the issuer with his private key K − I ; it contains the issuer's DID I and the credentials and DID H of the holder.The holder holds this VC in his wallet and presents it to a verifier as a Verifiable Presentation (VP).This VP is signed by the holder with his private key K − H ; it contains the VC and the verifier's DID V .The verifier verifies this VP by checking the issuer's signature on the VP and the issuer's signature on the VC.If the verifier accepts the issuer as a trusted authority for issuing the holder's credentials, then the verifier trusts that these credentials belong to the holder.
Early implementations of SSI made use of blockchain technology [17] and used a distributed public ledger [18] to store the mapping of a DID to its associated public keys.Modern approaches are based on OAuth 2.0 and OIDC, such as the mobile driving license in the United States standardized in ISO/IEC 18013-5:2021 [19].This approach implements the Self-Issued OpenID Provider Version 2 (SIOPv2) [20] draft in the wallet app for key management.Driving license offices provide OAuth 2.0 based interfaces defined in the OpenID for Verifiable Credential Issuance (OpenID4VCI) draft [21] to issue driving licenses as VCs in the World Wide Web Consortium (W3C) format [22].Drivers present these VCs as VPs to police officers using OAuth 2.0 based interfaces between smartphones defined in the OpenID for Verifiable Resentations (OpenID4VP) draft [23].Another OIDC draft describes the issuance of identity claims of the IDT as a VC [24].This is similar to our approach, but requires the full OpenID4VCI infrastructure to be deployed, which is currently rare.
Although SSI is now being adopted for some government use cases, there are still issues with usability [25][26] and identity recovery [27].These stem from manual key management by users who are unaware of their responsibilities, and the entirely new concept of operation.Since the private key is a long-term key that could be leaked during its lifetime, the system requires a key revocation list.But as argued by Ronald L. Rivest more than two decades ago [28], revocation lists should be avoided for security reasons.Modern technologies such as Hardware Security Module (HSM) or Trusted Platform Module (TPM) address this problem by protecting the private key inside the hardware.Here, the private key cannot be exported and can only be used for signing after the platform integrity has been verified and the user has been authenticated.This creates problems when a user wants to use VCs from other devices.Additionally, if the device is lost or broken, the user needs a recovery method for the private key and DID that must be configured in advance.
OIDC² does not have these problems.It uses short-lived ephemeral key pairs and ICTs that do not require a specific hardware or software platform.It also leverages existing account recovery capabilities and the familiar sign-in user authentication concept.Compared to SSI approaches, it does not require currently rarely deployed frameworks such as installed wallet apps, issued VCs, and a huge amount of implemented new standards.Instead, OIDC² requires a small extension of OPs to use existing OIDC accounts.In contrast, the ICT may also contain claims that the issuing OP is not a trusted source of, which will be discovered in Section 2.3.

OpenPubkey
BastionZero has developed OpenPubkey [29] which is very similar to OIDC².The RP of an EU can create a Client Instance Claim (CIC) that contains, among others, the RP's public key K + C .When requesting an IDT (see Figure 2a), the RP can optionally provide a nonce in the Authentication Request (1), which we omitted in Section 2.2.The OP will then insert this nonce into the IDT before issuing it (4).With OpenPubkey, the RP offers its hashed CIC as a nonce to be inserted into the IDT.After receiving the IDT, the RP appends the CIC and signs it with its private key K − C , resulting in a PubKey (PK) Token.The RP can use this PK Token to be authenticated with the EU's identity.
However, from our point of view, this approach has some security-relevant drawbacks.In an SSO context, the RP is often a login service (see the AS in Figure 3) that the EU usually authorizes to access his profile information.This RP may act malicious and request a PK Token with its own public key K + C to impersonate the EU without his knowledge.The authors' solution to this problem is to have the authenticating user only accept E2E authentications from trusted RPs, identified by their Client ID contained in the PK Token.First, this induces a high burden on the user, which is unacceptable since it is difficult for the user to identify trusted RPs.Second, the EU's trust in a service, such as an online store, may be sufficient to be authenticated by that store, but it may not be sufficient to allow the store to impersonate him.Third, in open communication systems such as email, there are many clients, and it is unlikely that all of them are trusted.This limits the use of OpenPubkey to a small set of explicitly trusted services and clients.We believe that these three problems may cause security vulnerabilities in the future.In contrast, with OIDC², the EU does not risk being impersonated when logging in to a malicious service.
OIDC² solves this problem by introducing the new ICT that can only be requested by an RP with sufficient scope for a specific E2E authentication context.This means that an EU can control whether to issue only an IDT or also an ICT.

OIDC²: Open Identity Certification with OIDC
This section describes the OIDC² concept in more detail and proposes a simple OIDC protocol extension to support it.

Concept of OIDC²
We define new terminology, introduce the Identity Certification Token (ICT), and explain how to use it.

Terminology
Consider a user of one application authenticating to a user of another application.The user authenticating himself is called the End-User (EU), his application is called the Client.The other user is called the Authenticating User (AU), and his application is called the Authenticating Party (AP).We also assume that the EU has an SSO identity provided by an OpenID Provider (OP) trusted by the AU.The terminology used for the EU, Client, and OP is consistent with the combined OAuth 2.0 and OIDC scenario described in Section 2.4.However, OIDC² does not require this scenario.

Identity Certification Token (ICT)
We introduce the ICT, which addresses the E2E authentication use case.The ICT contains the Client's verified public key K + C , an application-specific Scope, an expiration date, and a unique identifier of the EU's SSO identity.It may also contain other claims about the user which are not necessarily verified by the OP.

ICT Request
The Client uniquely requests an ICT from the OP for each E2E authentication process.Figure 4a simplifies the ICT request.

Authorization Response
Access Token, ID Token, Refresh Token  First, the Client performs an OAuth 2.0 Authorization Request as described in Section 2.1 (1-4) to obtain an AT for the ICT Request.For this purpose, the AT requires a Scope sufficient to access the EU's profile information, e.g., profile, and an E2E Scope, e.g., e2e auth email.The Client then uses the AT to authorize an OAuth 2.0 Resource Request for an ICT (5) from the OP, called an ICT Request.For this purpose, the Client uniquely generates a new public key K + C and presents it to the OP.The Client also presents a Proof of Possession (PoP) of the corresponding private key K − C , e.g., by signing a unique nonce.The OP verifies the validity of the AT and the PoP (6).If valid, the OP signs the ICT with its private key K − OP corresponding to its published public key K + OP and responds with the ICT (7).When the ICT expires and a new ICT is required, the Client repeats steps ( 5) to (7) to request a new ICT for a new key pair.

E2E Authentication with ICT
The Client uses the ICT to authenticate its EU to the AP's AU as shown in Figure 4b.First, the Client passes the ICT containing its public key K + C to the AP and provides a PoP for the corresponding private key K − C (1).To do this, the Client signs either a unique nonce provided by the AP or a unique session-specific identifier.Alternatively, the Client can prove the possession by establishing a secure channel based on the private key K − C .In Section 6, we show and explain use cases that take advantage of these three options.The AP then verifies the Client's PoP (2) using the public key K + C from the ICT and verifies the AU's trust relationship with the OP (3).This may require user interaction or the use of whitelists, discussed further in Section 2.3.If the AU trusts the OP, the AP checks the expiration date and verifies the signature of the ICT using the OP's public key K + OP (4).If successful, the EU has proven its SSO identity to the AU (5).

Security Considerations
First, we discuss how OIDC² shifts the burden of thorough authentication from service providers to identity providers.Then, we analyze the trust relationship between OIDC² entities and propose a trust classification for OPs.Finally, we propose authentication with multiple ICTs and discuss the correlation between the validity of an ICT and its corresponding key pair.

Service Provider vs. OpenID Provider
In most communication services, users must rely on the identity claims of their communication partners provided by the service provider, with no way to verify them.OIDC² allows users to verify each other's identities without having to trust the service provider.This only requires the Client to implement OIDC² and the protocol to provide a way to exchange the ICTs.The service provider does not need to implement OAuth 2.0 for the Client or provide an OP.This improves the overall security of the service and prevents privacy issues by eliminating the need for the service provider to collect sensitive information about its users.

Trust Relationship
Figure 5 shows an overview of the trust relationship between the entities of the OIDC² protocol.
On the proving side, the EU trusts his OP to protect his identity from impersonation attacks and not to impersonate him.This includes that the OP will only issue authorized ICTs.Furthermore, the EU trusts that his Client will operate as intended.This means that the Client will protect its private key K − C from third parties and use the ICT only for the intended authentication processes.To limit potential misuse by the Client, the ICT is scoped to a specific context.For example, this prevents an email client from misusing the ICT to sign contracts on behalf of the EU.
On the authentication side, the AU trusts the OP to protect the EU's identity and to sufficiently verify the Client's possession of its private key K − C .The AU also trusts the OP to certify sufficiently  trustworthy identity claims with the issued ICT, which we will discuss in more detail in Section 5.3.
To ensure that the authentication process is intended by the EU, the AU trusts the OP to issue only EU-authorized ICTs.The AU must also trust his AP to correctly verify the received ICT and PoP.
The AU needs to trust the OP.We offer two solutions that can be combined.First, the AP trusts a trusted identity federation such as the Global Assured Identity Network (GAIN) [30], which consists of international OPs such as banks, insurance companies, or government institutions, all of which manage fully verified real-world identities.Second, the AU maintains his own whitelist of OPs, such as social media platforms or his business partners.Not every OP has the same level of trustworthiness, so we classify them in the next section.

Classification of OpenID Providers
When working with OIDC², we suggest three classes of OPs to consider.

Insecure OpenID Provider (IOP)
OPs can be considered insecure for a variety of reasons.They may not be able to sufficiently protect their users' credentials, or they may be untrustworthy for political or economic reasons.For example, they may certify potentially false or insufficiently verified claims.If an AU considers an OP insecure, his AP will not accept any ICTs issued by that OP.

Authoritative OpenID Provider (AOP)
We classify an OP as an AOP for specific claims, if the AU accepts the OP as an authority for those claims and trusts the OP to protect managed identities.For example, an email server's OP is authoritative for email addresses within its own domain.Because an OP issues a unique subject identifier for each SSO identity by specification, an OP is always authoritative for its associated sub claim.
This makes AOPs sufficient for scenarios where an EU wants to be authenticated with specific claims.For example, if the AU knows the EU's email address, the EU uses an ICT issued by his email provider's OP to authenticate on a social media platform.However, AOPs are only sufficient to certify identity claims for which they are an authority.To certify real-world identity claims such as names or addresses, the AOP must typically be the OP of a trusted government organization.

Verifying OpenID Provider (VOP)
There is not always an AOP for every claim the EU wants to be authenticated with.Instead, the EU can use a third-party service that the AU trusts to sufficiently verify his identity claims and protect his account.We call the OP of this third-party service a VOP.This VOP could check the EU's passport to verify his name, or send him a verification code via SMS to verify his phone number.
There are already OP such as banks or insurance companies that are required by law to verify their customers' claims.However, such verification processes are often costly, which is why VOPs often do not verify all claims or offer it as an optional service, such as the social media platforms Facebook and X.Both can be AOPs at the same time.For example, banks are VOPs for the name of an EU, but also AOPs for bank account numbers.

Authentication with Multiple ICTs
The classification of an OP is up to the AU, i.e., the AU may not accept ICTs from certain OPs.Since an EU may not know the AU's classification in advance, the EU can present ICTs from different OPs and the corresponding PoPs to increase the likelihood of successful authentication by the AU.However, this requires more work for the EU as he has to log in to all these OPs to receive ICTs.If the AP receives multiple ICTs, it presents them to the AU, which then selects the most trusted issuer or rejects them all.Furthermore, the EU must be aware that presenting multiple ICTs also exposes all his presented accounts to the AU.

Validity of ICTs and Client Key Pairs
An ICT contains the public key K + C of the Client.By issuing this ICT, the acop certifies that the corresponding EU authorized the Client for E2E authentication with the contained identity claims.An attacker trying to impersonate the EU needs the corresponding private key of the ICT.We minimize this potential misuse of the ICT by a leaked private key by making the ICT short-lived and limited in scope.Since a few minutes are sufficient for most use cases (see Section 6), we recommend setting the ICT validity period to no more than 1 hour.
We propose that an ephemeral and unique key pair K ± C expires along with its associated ICT, eliminating the need for key revocation mechanisms.However, Sections 6.2 and 6.3 show that longterm key pairs are useful in some cases.Therefore, we further propose that an ICT may also contain a long-term public key, which must be indicated by providing the key revocation server of the key.Such a key is valid until revoked and is associated with the claims in the ICT.Some services control the lifetime of public keys by associating them with user profiles.An example of this approach is the Signal protocol (see Section 6.2).In such applications, a user can be authenticated with a public key received from an ICT as long as the public key contained in it is associated with the profile.In any case, an active session can remain valid even after the underlying key pair K ± C expires (see Section 6.1).

Use of OIDC² in Applications
We explain how E2E authentication is currently implemented in video conferencing, IM, and email, and how it can be improved by OIDC².The use of OIDC² is not limited to these applications, they were just selected to illustrate different application patterns.In addition, we recommend validity periods for ICTs depending on these applications.

Video Conferencing
Most video conferencing systems do not utilize any E2E authentication.Instead, users must rely on the identities of their communication partners provided by the service's IdP.Identifying a communication partner just by its video does not suffice.New technologies like deep fakes make this unreliable as demonstrated by an incident in 2022 [31].We explain how video conferencing services use OAuth 2.0 and OIDC and how they can benefit from OIDC².

E2E Authentication in Video Conferencing
In video conferencing, users log in to the service provider's OAuth 2.0 AS either directly with their credentials, or through the OP with their OIDC identity, as explained in Section 2.4.After authentication, the video conferencing service provider's AS obtains an IDT from the OP.After authorization, the Client gets an AT from the AS.The Client proves its authorization to the video conferencing server with the AT.The video conferencing server retrieves the EU's service account ID from the AT and provides the corresponding service profile to the communication partner.Note that the EU's service profile may be different from his OIDC identity.
In addition, the clients of both communication partners generate an ephemeral asymmetric key pair.They sign their public keys and key negotiation messages and exchange them via the video conferencing server.This enables an E2E encrypted communication channel, but users cannot rely on their communication partner's identity for two reasons.First, the service profile may not reflect the partner's real-world identity.Second, the service provider may provide a fake profile.

E2E Authentication with OIDC²
We propose that the EU is authenticated by his communication partner (AU) with his ICT that the EU's Client requested from the OP.After a mutual ICT exchange, the Client and the AP use the contained verified public keys to establish a secure channel, as shown in Figure 6.First, Client A generates an ephemeral key pair K ± A and requests an ICT for its public key K + A from the EU's OP (1).The Client signs this ICT and some unique session context, e.g., including timestamps and ephemeral public keys, with its private key K − A .The latter serves as a PoP.The Client sends the ICT and the PoP to the AP via the video conferencing server (2).If the AU trusts the EU's OP, it validates the ICT and verifies the PoP.Then Client B generates its own ephemeral key pair K ± B (3) and requests an ICT for its public key K + B from the AU's OP (4).The AP signs its ICT and the unique session context with its private key K − B (PoP) and responds to Client A via the video conferencing server (5).If the EU trusts the AU's OP (6) an the validation of the ICT and the PoP are successful, then the Client and the AP have successfully performed mutual authentication, which enables them to establish a securely E2E authenticated and encrypted channel (7).

Discussion
When video conferencing is improved with OIDC², users do no longer need to trust their service provider to display the correct service profiles of the participants in a video session.While the service profiles may not reflect the true identities of the participants, the users can rely that verifying OPs have thoroughly checked the participants' identity when they registered.We recommend a validity period of 5 minutes for video conferencing services as starting a video conference takes only a few seconds.Within that time a user has joined a call, and that duration is also long enough to compensate for clock drifts on end systems.When the ICT expires, an active secure channel remains valid until it is closed.

Instant Messaging (IM)
Secure E2E authentication in IM requires a prior secure exchange of public keys which is mostly achieved by face-to-face meetings.We suggest an OIDC²-based authentication method for IM which does not require such a prior secure exchange of public keys.

E2E Authentication in Signal
In the Signal protocol [32], users are identified by their phone number and public key K + .Both phone number and public key K + are verified and published by Signal while the corresponding longterm private key K − remains on the user's device.To establish an E2E encrypted communication channel, a user requests from Signal the public key of the communication partner.The public keys of both users are leveraged for an authenticated Diffie-Hellman key exchange to establish an encrypted communication channel between the partner.Over this channel, they may authenticate each other with their public keys.However, at this point the public keys are not yet reliable as this method requires trust in Signal and its verification method for phone numbers and public keys.When the partners meet in presence, they can mutually verify each other's public keys by exchanging them via a secure side channel, e.g., by presenting them as a Quick-Response (QR) code in a face-to-face meeting.When the partners communicate again, they can rely on the verified public keys and trust in Signal is no longer needed.This mechanism is a strong but also cumbersome.

E2E Authentication with OIDC²
We propose an E2E authentication method for IM based on OIDC².It is illustrated in Figure 7.
We assume that the IM clients have already established an E2E encrypted channel that is mutually authenticated by each other's public keys K ′+ .The mutual authentication method based on OIDC² works as follows.The IM client requests an ICT from its EU's OP for his public key K + and sends the ICT over the secure channel to the AP.If the AU trusts the EU's OP, the AP verifies the received ICT and compares the contained public key K + with the one that was used to establish the secure channel.The implicit PoP consists of the fact that both users can communicate over the secure channel, i.e., they possess the corresponding private keys.

Discussion
The presented approach shows that existing key management systems like the one of Signal can be extended with OIDC² as an authentication layer.It does not use any Signal-specific features and can therefore be applied to any other IM service while preserving all security-related features such as ratchet-based E2E encryption or forward secrecy.As a particularity, the ICT's key is not ephemeral but an existing long-term key.Moreover, the method demonstrates that a secure channel may be set up with non-verified public keys with subsequent key verification based on OIDC².Probably, this pattern can also be applied to other applications.We recommend a validity period of 5 minutes for ICTs in an IM context because messages are delivered to the receiving client very quickly.If the ICT is transmitted when the AP is offline, the verification process must be repeated.

Email
S/MIME and PGP are common standards for email authentication for almost three decades.However, probably due to their complex key management, signed emails are still the exception [1] with 2.8%.We briefly describe S/MIME and PGP and their shortcomings, explain how PGP can be enhanced with OIDC² for better authentication, and the limitations of that approach.

E2E Authentication with S/MIME and PGP
S/MIME and PGP utilize a long-term asymmetric key pair K ± to sign emails.S/MIME leverages X.509 certificates issued by a CA so that receivers of a signed email can validate its signature with the enclosed public key after validation of the public key and checking its associated Certificate Revocation List (CRL).Obtaining such a certificate may be a cumbersome and expensive process for the user unless it is provided by his employer.PGP requires that the receiver of an email has obtained a fingerprint of the sender's public key via some side channel.Mostly, the communication partners have exchanged the fingerprints of their public keys in a face-to-face meeting.This is also a cumbersome process and does not allow for signed communication before having known the receiver of the email.To facilitate revocation of a key pair, the public key is published on a key server.The key server maintains a key revocation list which needs to be checked by the receiver of an email.S/MIME and PGP also support email encryption.To that end, the sender encrypts an email with a symmetric key, encrypts this key with the receiver's public key K + , and attaches it to the email.The receiver uses his private key K − to decrypt the symmetric key for decryption of the email.
Both S/MIME and PGP suffer from the fact that they require complex key management.First, the user must protect his private key K − .Second, the user must securely synchronize his key pair K ± across his devices if he wants to use them all for signed and encrypted email communication.
And third, the sender must revoke compromised key pairs K ± , and the receiver must check CRLs to validate the validity of a received public key K + .

E2E Authentication with PGP and OIDC²
We propose to combine PGP with the key verification method of OIDC², but do not touch any security properties of PGP.We have implemented this concept in a prototype which is published on GitHub1 .
Figure 8 shows how emails are sent with PGP and OIDC².The sender (EU) authorizes his email client (Client) for E2E authentication in the email context.Then the Client requests an ICT EU for its stored PGP key K ± PGP , attaches both the public PGP key K + PGP and the obtained ICT EU to the email, and signs the email with the private PGP key K − PGP .The receiver (AU) opens the email with his client (AP).The AP first validates the ICT EU , i.e., it checks whether it trusts the issuing OP of the ICT and it validates the ICT's signature.This can be done offline as the public keys of trusted OPs are typically cached for a moderate time.Then, the AP verifies the email's integrity by verifying its signature with the ICT's contained public key.The integrity of the mail serves as a PoP to prove that the sender of the email is also the owner of the key in the ICT EU .Now, the sender of the email is identified with the identity provided in the ICT EU .

Discussion
The email is sufficiently authenticated when it was validated before the expiration of the ICT EU .Then, checking a possibly available CRL of the sender's PGP key is not needed, as the validity of the key is already given by the ICT EU .When receiving signed emails with conventional PGP or S/MIME, the key's CRL must be checked so that the CRL must be reachable.Conversely, OIDC²-based PGP requires that the OP is reachable to issue the ICT EU when sending the email.
The PGP key pair in the presented method can be either the sender's long-term PGP key pair, or a short-term key pair just generated by the Client.We first assume that a long-term public PGP key is attached to the email and the contained ICT EU references a key server that is reliable in the sense that it adds information reliably to the CRL.The information about the public key on the key server equals the one in the ICT EU and that this information predates the issuing time of the ICT EU .These preconditions seem comprehensive but are mostly fulfilled.We can argue that the OP confirmed the mapping of key and identity, which was equal to the information on the key server at that time, so that this information on the key server is also reliable as long as the key is valid, i.e., until it expires or it is revoked.Therefore we can retain two advantages of long-term keys as long as the key is valid.First, the message may be even validated after the ICT EU expired.Second, the key may be stored as an authenticated public PGP key of the sender.Thus, the proposed procedure may be used to securely exchange a long-term PGP key, and this key may be used to send encrypted emails to the key's owner.
We now consider the use of short-lived keys.They do not need to be stored so that no complex key management is required.This is unlike for long-term keys and greatly improves the usability of email authentication.However, short-lived keys come with two drawbacks.First, sending encrypted emails is not possible without long-term keys.Second, an email can be successfully verified only as long as the ICT EU is valid, which may be too short when the email is received late by the AP.This problem can be solved if the EU can trust his mail server so that the AP can rely on the inbox timestamp.Then an email can be considered valid if it was received within the validity period of the attached ICT.As most emails are received within a few minutes by the inbox on the mail server, we recommend an expiration date of at most one hour.

Implementation
We present a simple extension for any OIDC server to handle ICT Requests including a PoP for the verification of the Client's public key.The implementation is available on GitHub2 .However, we recommend it only for testing purposes.
To request a token, a Client sends a Token Request to the so-called /token Endpoint of the OP.That is a special path in the URL of the OIDC server.Moreover, there is also a /userinfo Endpoint that returns information about the user upon a Userinfo Request.
Many services are not directly reachable on the Internet but via a reverse proxy.A reverse proxy is an HTTP server that resides in the same network as the server, terminates the TLS connection between client and server, and relays data to and from the application server from and to the client.
We propose the generic extension to an OIDC server in Figure 9 so that the OIDC server can handle ICT Requests.We define a novel /ict Endpoint which runs as a microservice separately from the OIDC server.The /ict Endpoint and the OIDC server operate behind a reverse proxy.The reverse proxy forwards any conventional OIDC requests to the OIDC server and ICT Requests to the /ict Endpoint.The /ict Endpoint expects an AT with Scopes for identity claims, e.g., profile for name and birth date, and a scoped context for E2E authentication, e.g., e2e auth email for the email context, in the ICT Request.It extracts the AT, and includes it in a Userinfo Request to the OIDC server.After receiving user information, the /ict Endpoint checks whether the EU possesses the private key K − C for the public key K + C contained in the ICT request, which is explained later.If the check was successful, the /ict Endpoint issues an ICT with appropriate information and signs it with the private key K − OP of the OP.Thus, K − OP must be available to the /ict Endpoint.This is a reason why we recommend this simple prototype only for testing purposes but not for production.Finally, the /ict Endpoint returns the ICT to the Client.
To save communication overhead between the /ict Endpoint and the Client, we propose the following PoP.The Client chooses a nonce, concatenates it with a timestamp, signs the concatenation with its private key K − C , and includes concatenation and signature in the ICT Request.The /ict Endpoint verifies the signature with the public key K + C and caches the nonce for 30 seconds.To counter replay attacks, the /ict Endpoint accepts only ICT Requests with timestamps in the concatenation that deviate at most 15 seconds from its own time and whose nonce is not in the cache.

Evaluation
We evaluate the performance of the provided /ict Endpoint, written in Go, compared to the /token Endpoint of the Keycloak 22.0.1 and Authentik 2023.6.1 OIDC server software to estimate the additional costs for an OP.
We conduct the following two experiments.(A) A Client sends a Refresh Token to the /token Endpoint of the OIDC server and obtains an IDT, an RT, and an AT.(B) A Client generates a PoP, sends an AT to the new /ict Endpoint, and obtains an ICT.Both experiments are conducted over one minute, i.e., a token is requested, returned, and then the next request is sent.We ran each experiment 20 times and computed mean requests per minute including confidence intervals with a confidence level of 95% (CI 0.95 ) using the Student's t-distribution.We automate this process with the help of a web application ) could be served.Thus, the tested version of Keycloak is more efficient than the tested version of Authentik.Moreover, the provided /ict Endpoint is as efficient as the built-in /token Endpoint or even more efficient.
We compare the work done by the /token Endpoint and the /ict Endpoint.(A) The /token Endpoint validates the RT, creates an IDT, and signs the AT and the IDT with its private key.The integrity of the RT is secured differently8 .(B) The /ict Endpoint validates the PoP for the Client's public key, and requests user information using an AT from the /userinfo Endpoint, which validates the AT.Then the /ict Endpoint creates and signs the ICT.
The effort for creating and signing an IDT in (A) and an ICT in (B) is possibly similar, as both require RT/AT validation, a database request, and a token signature.Thus, creating an RT and AT, and signing the AT in (A) is apparently equal or more time consuming than creating the PoP at the Client and validating the PoP at the /ict Endpoint in (B).
The cost of providing ICTs scales with the frequency ICTs are requested, which depends on the adoption of OIDC² by applications and by EUs.However, ICTs are typically requested by EUs' Clients before sending an email, when being authenticated by a new IM communication partner, and when joining a video conferencing session.Such user-triggered actions may not exceed 10 ICT requests per hour in normal workloads.Inactive EUs do not request any ICTs.In contrast, ATs are recommended to be renewed every hour to comply with RFC 6749 [2]'s expiration time guidance.This is needed for every running Client, even if the EU is inactive.Therefore, our predicted usage of ICTs after full adoption is in a similar order of magnitude as the recommended need for ATs.

Conclusion and Future Work
This paper introduced OIDC², which allows EUs to request a verifiable ICT from an OP.An ICT contains claims about an EU and a public key chosen by the EU.AUs can authenticate EUs with an ICT if they trust his issuing OP.We compared OIDC² to existing E2E authentication methods and found that OIDC² is easier to use and improves security by eliminating the need for revocation lists.We suggested how OIDC² can be implemented based on the OIDC framework.We discussed security considerations for and general improvements with OIDC²: the trust relationship among its entities, a classification of OPs and their utilization with OIDC², authentication with multiple ICTs to increase the likelihood of successful authentication, as well as appropriate (short) validity periods for ICTs.Furthermore, we proposed how OIDC² can be used for simple and user-friendly E2E authentication for video conferencing, email, and IM.Finally, we provided a simple, opensource extension for OIDC server software to support OIDC² for testing purposes.We proved its compatibility with Authentik and Keycloak and the performance of the new /ict Endpoints is comparable to or better than the performance of the existing /token Endpoints.
To demonstrate the feasibility of OIDC² for E2E authentication, we plan to integrate OIDC² for video conferencing based on the open WebRTC protocol, for IM based on the open Matrix protocol, and for email communication based on the PGP standard.
Trust relationship among involved entities in OAuth 2.0 and OIDC.

Figure 2 :
Figure 2: OpenID Connect Authentication Flow and trust relationship.

Figure 3 :
Figure 3: Simplified authentication to an AS with OIDC and authorization of a Client with OAuth 2.0.

Figure 9 :
Figure 9: Simple extension to an OIDC server to handle ICT Requests.
3. The OIDC server, its user database based on PostgreSQL 15.2, and the new /ict Endpoint run in separate Docker containers4.The host is a Lenovo ThinkPad T14s with a 2.1 GHz AMD Ryzen 5 PRO 4650U processor, 16 GB RAM, and a 512 GB SSD with Windows 11 22H2 x64, and running the Docker engine 5 24.0.2 in WSL 26.While Authentik can import and export any private keys, Keycloak cannot export private keys and it can import only RSA keys.Therefore, we chose RS256 for signatures, i.e., a 2048 bit RSA key with the SHA-256 hashing algorithm to make experiments with different server software comparable.