# The eIDAS Regulation: A Survey of Technological Trends for European Electronic Identity Schemes
## 6 RQ4: OpenID Connect Implementation Choices
However,, in the case of request parameter, the object is directly included within the authorization request, in the case of request_uri, it is retrieved from the defined URL; **Token Binding (DPoP/mTLS)**: [59; 60]: indicates whether the eID means under analysis are using any techniques for binding the issued Access Tokens, such as: Demonstrating Proof of Possession (DPoP) or mutual TLS (mTLS) to avoid the misuse of a stolen Access Token by other SPs. DPoP is a JWT created by the SP and sent with an HTTP request using the DPoP header field to demonstrate to the IdP that the SP holds theprivate key that was used to sign the DPoP-proof JWT. DPoP enables IdP to bind issued Access Tokens to the corresponding public key. Furthermore, DPoP enables Resource Servers to verify the key-binding of Access Tokens that it receives, which prevents said tokens from being used by any entity that does not have access to the private key. mTLS is an alternative way to reach the same goal by using the application's mutual-TLS certificate. Such a binding is accomplished by associating the certificate with the Access Token in a way that the protected resource can access. One possible way of doing this is to embed the certificate hash in the issued Access Token. **claims**: [3]: indicates whether the eID means under analysis support the claims OIDC parameter, which enables the SP to explicitly request individual claims to be returned in the ID Token and/or userInfo response to satisfy data minimization. The top-level members of claims OIDC parameter JSON object are:  
userInfo: requests that the listed individual claims be returned from the userInfo endpoint. If present, the listed claims are being requested to be added to any claims that are being requested using the OIDC scope parameter. If not present, the claims being requested from the userInfo endpoint are only those requested using the values defined in the OIDC scope parameter;
**ID Token: requests that the listed individual claims be returned in the ID Token. If present, the listed claims are being requested to be added to the default claims in the ID Token. If not present, the default ID Token claims are requested. We report the main results per each eID means considering only the features implemented by the eID schemes under analysis within columns 4-12 of Table 3. From the results, we have that:  
* 76% of eID means support and mandate the usage of the PKCE within their solutions;
* Danish eID means (NemID) is the only solution that optionally supports the PKCE within its solution;
* 88% of the eID means under analysis support the usage of acr_values within their OIDC implementations;
* 94% of the eID means under analysis (for which we could find information) use the pairwise subject identifier;
* private_key_JWT and the client_secret are the two most widely used client authentication methods within eID means;
* None of the eID means support the mTLS client authentication method [59];
* 82% of eID means support either the request or request_uri OIDC parameters;
* 76% of the eID means under analysis (for which we could find information) support the usage of claim parameter within their solutions;
* None of the eID means under analysis support token binding methods based on DPoP [60] or mTLS [59]. As a final remark, in Figure 5, we provide an overview of OIDC profiles and OIDC implementation choices adopted by MSs.