# The eIDAS Regulation: A Survey of Technological Trends for European Electronic Identity Schemes
## 6 RQ4: OpenID Connect Implementation Choices  
In this section, we investigate the OIDC implementation choices adopted by the eID means under analysis. We identify the following features:  
\begin{table}
\begin{tabular}{c c c c c c c c c c c c} \hline \hline \multicolumn{1}{c}{**MS**} & \multicolumn{1}{c}{**ID**} & \multicolumn{1}{c}{**OIDC**} & \multicolumn{1}{c}{**OIDC Implementation Choices**} & \multicolumn{1}{c}{**OIDC**} & \multicolumn{1}{c  
**Proof Key for Code Exchange (PKCE)**: [32]: indicates whether the eID means support PKCE. This extension was created to secure the OIDC implementations against several attacks such as code interception in the OIDC authorization code flow [3]. In simple words, code interception attack refers to scenarios in which the attacker can obtain the authorization code somehow and then sends it to an IdP to exchange it for an Access Token. An attacker may use several available ways to steal the code (Section 4 in OAuth Security BCPs [33]). To mitigate this attack, the PKCE extension introduced three query parameters to provide a way for the SP to prove to the IdP that the authorization code belongs to the SP, namely: (i) code_verifier, (ii) code_challenge, and (iii) code_challenge_method. The code_verifier is a dynamically created cryptographically random key, which is unique per request. The code_challenge is a transformation of the code_verifier by using the method that is declared in code_challenge_method (e.g., Plain or S256). Thus, an attacker needs to know the value of the code_verifier for the intercepted request to be able to exchange the authorization code for an Access Token, which is not as simple as code interception; **acr_values**: [3]: indicates whether the eID means under analysis support acr_values to define the level of assurance within the authentication context, where acr_values enabling SPs to request IdPs strong authentication methods to harden intrusion attempts against users by mandating additional authentication factors; **subject identifier (sub) = pairwise**: [30]: indicates whether the eID means under analysis adopt the pairwise value for the subject identifier, where the subject identifier is an attribute within the IdP for the User. The sub claim is returned from the IdP to SP either directly in the ID Token or as a response from the userInfo endpoint; **client authentication method**: [3]: indicates the client authentication method used by the SP at the IdP token endpoint to authenticate the SP and avoid releasing Access/ID Tokens to a not legitimate SP. This feature can have the following values: **client secret**: SP uses the client_secret received from the IdP during the registration phase to perform the client authentication; **client secret JWT**: SP creates a JSON Web Token (JWT) using an HMAC SHA algorithm, which uses the client_secret issued by the IdP during the registration phase for the HMAC calculation that is used for the client authentication; **private key JWT**: SP creates a JWT using asymmetric algorithms and signs the JWT with its private key to perform the client authentication; **mTLS**: [59] SP provides a mechanism for authentication to the IdP using mutual TLS based on either self-signed certificates or public key infrastructure (PKI). **request**: [3]: indicates whether the eID means under analysis support the request OIDC parameter. It provides a way to encapsulate all the authorization request query parameters inside a single object which can be signed and optionally encrypted to provide integrity; **request_uri**: [3]: indicates whether the eID means under analysis support the request_uri OIDC parameter. In the same way as the OIDC request parameter, it provides a way to encapsulate all the authorization request query parameters inside a single object which can be signed and optionally encrypted to provide integrity.