| draft-oid4vc-security-and-trust-latest | March 2024 | |
| Fett & Lodderstedt | Standards Track | [Page] |
This specification describes the trust architecture in OpenID for Verifiable Credentials ([OpenID.VCI], [OpenID.VP], [OpenID.SIOPv2]), outlines security considerations and requirements for the components in an ecosystem, and provides an informal security analysis of the OpenID for VC protocols.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/vcstuff/oid4vc-security-and-trust.¶
Note: This document is a work in progress. The security and trust considerations described here are not yet complete and may change without notice. The security analysis has not yet been verified by formal methods.¶
TODO: Check if all of the following terms are actually used and aligned with latest drafts.¶
This specification uses the terms "Access Token", "Authorization Request", "Authorization Response", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Grant Type", "Response Type", "Token Request" and "Token Response" defined by OAuth 2.0 [RFC6749], the terms "End-User", "Entity", "Request Object", "Request URI" as defined by OpenID Connect Core [OpenID.Core], the term "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [RFC7519], the term "JOSE Header" and the term "Base64url Encoding" defined by JSON Web Signature (JWS) [RFC7515], and the term "Response Mode" defined by OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses].¶
This specification also uses the following terms defined in [OpenID.VP] and [OpenID.VCI].¶
Verifiable Credentials facilitate a model to obtain and present authoritative claims about a subject via a so-called Wallet (Issuer-Holder-Verifier Model).¶
TODO: add diagram¶
In this model, the Issuer (the entity making an authoritative claim) creates a Verifiable Credential and delivers it to the End-User (or her Wallet, respectively). The Wallet/End-User can then present the Verifiable Credential to a Verifier (the entity that needs to know the claim).¶
A Credential can be presented multiple times during its lifecycle and multiple Credentials can be presented to a Verifier in a single transaction. Subsets of the claims in one or more credentials can be presented.¶
The End-User then decides what Credential to use with which Verifier. The Verifier decides what Credential to accept from the End-User.¶
The involved parties need to access data about identifiers, keys, and Credentials as well as data about the acting parties themselves in order to securely implement the Credential exchange. The details of how this is achieved are defined in the Trust Model.¶
All parties communicate with each other using a set of protocols, or just "protocol" in the following. In the case of OpenID4VP, the protocols are OpenID for Verifiable Credential Issuance [OpenID.VCI] and OpenID for Verifiable Presentations [OpenID.VP], with an optional use of SIOP v2 [OpenID.SIOPv2].¶
Trust in the Issuer-Holder-Verifier Model means different things to different parties.¶
For Verifiers:¶
For Holders/End-Users:¶
For Issuers:¶
Depending on the use case, the Verifier needs to trust the End-User to be the legitimate holder of a certain Credential. Accepting a Credential from any bearer is a security risk:¶
So anyone getting in possession of a Credential, e.g. through a security breach, could pose as the legitimate End-User for a long time.¶
Therefore, Credentials are usually bound to the legitimate End-User, also known as "holder binding". There are three ways to bind the Credential to its legitimate holder:¶
It is often assumed that the Holder of a Credential is the subject of the Credential. Depending on the ecosystem and types of credentials, this might not always be the case, e.g., when a parent presents a child's birth certificate to a school. In this case, the Holder and legitimate possessor is the parent and the subject is the child.¶
At least in theory, a credential can also hold information about multiple subjects.¶
It is therefore important to distinguish between the information that the credential holds (about the subject) and the information that the credential is bound to (about the holder). For example, a given name and family name may be contained in a credential to be used for claim-based binding, even though the credential itself does not attest to the holder's identity.¶
When it is ensured that the credential is bound to the subject of the credential, and Holder Binding is enforced, Verifiers can trust that the presentation of a credential is done by the subject of the credential.¶
Cryptographic holder binding allows a Verifier to challenge the Holder to prove possession of the private key material. This is usually done by the Verifier sending a random nonce to the Holder and the Holder signing the nonce with the private key material. The Verifier can then verify the signature with the public key material contained in the Credential. The challenge must be augmented by the Verifier's identity to prevent replay attacks where an attacker, acting as a Verifier, can reuse a nonce from a session with a different Verifier running in parallel.¶
Note: The nonce challenge at the same time serves as a CSRF protection. However, if cryptographic holder binding is not used, the nonce challenge cannot serve this function. Details are described in Section 6.4.¶
Biometric holder binding requires the Verifier to compare the biometric traits of the presenter with the biometric traits contained in the Credential. There is no built-in mechanism to ensure that prevents replay attacks: An attacker can attempt to forward not only a stolen credential, but also the biometric information of the legitimate holder, e.g., by replaying a video of the legitimate holder. Out-of-band mechanisms must be used to prevent such attacks, for example, by only accepting biometric data from trusted platforms or by challenging users to perform specific actions.¶
Claim-based holder binding requires the Verifier to compare the claims contained in the Credential with claims form another source, usually a second credential or previously known information. As such, a credential that is only bound using claim-based information is not itself protected against replay attacks, but may be useless unless presented in conjunction with another credential that is holder-bound.¶
Verifiers MUST decide whether Holder Binding is required for a particular use case or not before verifying a credential. This decision can be informed by various factors including, but not limited to the following: business requirements, the use case, the type of binding between a Holder and its credential that is required for a use case, the sensitivity of the use case, the expected properties of a credential, the type and contents of other credentials expected to be presented at the same time, etc.¶
This can be showcased based on two scenarios for a mobile driver's license:¶
Scenario A: For the verification of the driver's license when stopped by a police officer for exceeding a speed limit, Holder Binding may be necessary to ensure that the person driving the car and presenting the license is the actual Holder of the license. The Verifier (e.g., the software used by the police officer) will ensure that a Holder Binding proof is present and signed with the Holder's private key. (Biometric or Claims-based Holder Binding may be used as well, e.g., by including a portrait image or a first name, last name and a date of birth that matches that of an insurance policy paper.)¶
Scenario B: A rental car agency may want to ensure, for insurance purposes, that all drivers named on the rental contract own a government-issued driver's license. The signer of the rental contract can present the mobile driver's license of all named drivers. In this case, the rental car agency does not need to check Holder Binding as the goal is not to verify the identity of the person presenting the license, but to verify that a license exists and is valid.¶
It is important that a Verifier does not make its security policy decisions based on data that can be influenced by an attacker or that can be misinterpreted. For this reason, when deciding whether Holder binding is required or not, Verifiers MUST NOT take into account whether an Holder Binding proof was presented or not, as an attacker can remove the Holder Binding proof from a Presentation and present it to the Verifier.¶
Open Question: Should a "presentation" always mean/require cryptographic holder binding? Should these use cases where it is not required covered by the protocol?¶
TODO: Link this better to the requirements above.¶
Wherever End-User data is stored, it represents a potential target for an attacker. This target can be of particularly high value when the data is signed by a trusted authority like an official national identity service. For example, in OpenID Connect, signed ID Tokens can be stored by Relying Parties. In the Issuer-Holder-Verifier model, Wallets have to store signed credentials and associated data, and Issuers and Verifiers may decide to store credentials or presentation as well.¶
Not surprisingly, a leak of such data risks revealing private data of End-Users to third parties. Signed End-User data, the authenticity of which can be easily verified by third parties, further exacerbates the risk. Leaked credentials or presentations may also allow attackers to impersonate Holders unless Holder Binding is enforced and the attacker does not have access to the Holder's cryptographic keys. Altogether, leaked credentials and presentations may have a high monetary value on black markets and a leak may have a severe impact on the affected users.¶
Due to these risks, systems implementing the Issuer-Holder-Verifier model SHOULD be designed to minimize the amount of data that is stored. All involved parties SHOULD store credentials or presentations only for as long as needed, including in log files.¶
Issuers SHOULD NOT store credentials after issuance.¶
Holders SHOULD store credentials and associated data only in encrypted form, and, wherever possible, use hardware-backed encryption in particular for private Holder Binding keys. Decentralized storage of data, e.g., on End-User devices, SHOULD be preferred for End-User credentials over centralized storage. Expired credentials and associated data SHOULD be deleted as soon as possible.¶
Verifiers SHOULD NOT store presentations after verification. It may be sufficient to store the result of the verification and any End-User data that is needed for the application.¶
To implement a secure trust chain, a number of Security and Privacy Requirements must be met. In the following, the Security Requirements are described along the trust chain from Verifier to Issuer, then separately from the view of the End-User. All requirements are numbered for reference and are prefixed with the respective party or component that needs to implement the requirement:¶
W: Wallet¶
CF: Credential Format¶
E: Ecosystem¶
P: Protocols (both for Issuance and Verification)¶
Ecosystem here refers to a network of Verifiers, Issuers, and Wallets and the design of relationships of parties with each other in this network, their roles and permissions, the verification of their real-world identities and the mechanisms selected and provided for key creation and distribution.¶
As a prerequisite for operating in an Verifiable Credential ecosystem, Verifier, Issuer and Wallet need to implement the protocols and the credential formats securely and correctly, that is, according to the respective specifications, respecting the security and privacy requirements of the specifications, and following the best practices for application security.¶
This includes, for example, the use of secure implementations of cryptographic algorithms, the proper verification of signatures and credentials wherever required by the protocols or credential formats, the use of secure random number generators, the secure use of hardware-based storage, and protection against injection attacks.¶
Security Requirement V-00: The Verifier must implement the protocol securely and correctly.¶
Security Requirement V-01: The Verifier must implement the credential format securely and correctly.¶
Security Requirement I-00: The Issuer must implement the protocol securely and correctly.¶
Security Requirement I-01: The Issuer must implement the credential format securely and correctly.¶
Security Requirement W-00: The Wallet must implement the protocol securely and correctly.¶
Security Requirement W-01: The Wallet must implement the credential format securely and correctly.¶
The Verifier receives a presentation that is cryptographically tied to a credential that itself is cryptographically tied to a specific Credential Issuer. One of the most basic security requirements is that the Verifier can verify that the presentation is tied to the correct Issuer.¶
Security Requirement CF-10/E-10: For any presentation, the credential format and trust framework must be designed such that there is a secure way to determine the Issuer and to check that the original credential was issued by this issuer. (E.g., by using a cryptographic signature.)¶
The data within the credential must be protected against tampering by an attacker. The Verifier must be able to verify that the data in the presentation is the same as the data in the original credential.¶
Security Requirement CF-20: For any presentation, the credential format must ensure that the data contained therein that is tied to the original credential cannot be not altered. (E.g., by using a cryptographic signature.)¶
The root of trust from the perspective of a Verifier is the Credential Issuer. The Verifier decides, based on policy, regulation, conformity assessment, and/or contracts, to trust a certain Issuer to issue Credentials of a certain type with the correct data to the legitimate End-Users. This requires that the Issuer is identified uniquely and unambiguously.¶
Security Requirement E-20: The trust framework must ensure that the identification of an Issuer is unique and unambiguous. If there are multiple instances of the same Issuer sharing the same key material, the Verifier must trust all instances equally.¶
For example, a mobile app as issuer which holds the key material in the app itself (as opposed to, e.g., a secure hardware storage) is most likely a bad idea - not all instances of this app are equally trustworthy, some might be hacked and the key material leaked to malicious parties.¶
While the way in which the Verifier determines the trustworthiness of the Issuer defined in the trust framework is out of scope of this specification, this decision must not be influenced by a malicious party.¶
Security Requirement E-30: The way in which the Verifier determines the trustworthiness of the Issuer defined in the trust framework must be secured from influence by a malicious party that can, for example, introduce untrustworthy entities into a directory.¶
Any information that is used by the Verifier to determine the trustworthiness of the Issuer must be kept up to date. When an Issuer leaves the ecosystem or key material needs to be revoked or rotated, appropriate mechanisms must be in place.¶
Security Requirement E-40: The trust framework must ensure that there is a way for Verifiers to keep their information on trusted Issuers up to date and that there is a way to revoke trust in an Issuer.¶
The Verifier trusts in the Authenticity of Claims as described above. This means:¶
Security Requirement I-10: The Issuer must authenticate/identify the End-User properly according to the requirements of the Verifier (which may be defined in a specification, trust framework, or by convention).¶
The Verifier trusts in the Integrity of Claims as described above. It is obvious that the Issuer must not issue false claims about the End-User.¶
Security Requirement I-20: The Issuer must only put correct and up-to-date (at the time of issuance) claims about the End-User into the Credential where verified data is expected.¶
(By convention, specification or trust framework, self-declared or otherwise "unverified" claims may be allowed in some places in some credentials.)¶
It must be ensured that credentials cannot be read by third parties during the issuance process. This ensures basic privacy of the End-User and prevents abuse of stolen credentials. While enforcing holder binding is a more secure option to prevent abuse of stolen credentials, it is not always desired to enforce holder binding.¶
Privacy/Security Requirement P-10: The protocol must ensure that no third party can read the credential issued by the Issuer (during or after issuance).¶
It must be ensured that an attacker cannot introduce credentials into a Wallet that are not intended for the End-User.¶
Security Requirement P-20: The protocol must ensure that no third party can interfere with the issuance process such that the Issuer issues Credentials for the third party to the End-User.¶
Finally, an Issuer that learns about potential abuse of a credential must be able to revoke it.¶
Security Requirement I-30: The Issuer must be able to revoke a Credential, in particular once the Issuer learns about potential abuse of the Credential.¶
The Verifier trusts in the Integrity of the Interaction with the Wallet, as described above. This means:¶
Security Requirement P-30: The protocol must ensure that the interaction between the Wallet and Verifier is protected such that no third party can interfere with the interaction by modifying the information transmitted.¶
An attacker could extract messages of the presentation process and forward them to an End-User. The End-User could be confused about the purpose of the interaction and complete the presentation process on the attacker's behalf, giving the attacker access to resources or a session that was authenticated using the End-Users identity.¶
Security Requirement P-40: The protocol must ensure that the interaction between an attacker and a Verifier cannot be forwarded to and successfully completed by a user (victim).¶
Likewise, an attacker interacting directly with a Verifier must not be able to re-use parts extracted from an End-User's session to successfully complete the interaction.¶
Security Requirement P-41: The protocol must ensure that an attacker cannot successfully forward an interaction between a Wallet and a Verifier to a Verifier under his own control.¶
If Holder Binding is required by the use-case of the Verifier (see open questions above), the Verifier must trust the Issuer to bind credentials to the End-User. This means:¶
Security Requirement I-40: The Issuer must only include holder-binding data into the credential that is tied to the actual End-User (and not, e.g., include a cryptographic key under control by a third party).¶
It must be ensured that during issuance, the correct holder-binding data ends up in the credential.¶
Security Requirement P-50: The protocol must ensure that third parties cannot interfere with the binding process.¶
For cryptographic holder binding, the security largely depends on the quality of the key management, e.g. whether private keys can be extracted from the user's device and copied to another device. So the Verifier needs to trust in the Wallet to implement the key management securely.¶
Security Requirement W-10: The Wallet must implement the key management for cryptographic holder binding securely such that only the legitimate Holder can use a credential.¶
The precise method to achieve this depends on the software and hardware choices available and the desired level of security and assurance. One way to achieve this is by using a secure enclave or similar technology.¶
Security Requirement CF-21: For cryptographic holder binding, the presentation format must allow requiring a Holder to prove possession of the private key that is bound to the credential, usually by signing over a challenge consisting of a nonce and an identifier for the Verifier.¶
Ensuring secure credential storage can be achieved in one of two ways:¶
Security Requirement V-10 (conditional): The Verifier must ensure that the credential was stored in a secure Wallet.¶
Assuming this trust can be established by way of conformity assessment of some sort, the Issuer needs to make sure that it issues Credentials into a Wallet it trusts and the Verifier needs to make sure that it accepts presentations only from wallets it trusts.¶
In order to make the life of Verifiers easier, this concept obliges the Issuer to only issue Credentials to trustworthy wallets and to make its requirements transparent to Verifiers via its policy so this becomes part of the rules a Verifier needs to understand and accept.¶
From the Verifier’s standpoint it is now sufficient to ensure it accepts Credentials from this Issuer since, by conclusion, if it gets presented a valid Credential issued by this Issuer it must have come from a trustworthy Wallet. This change significantly simplifies the protocol and fosters privacy since the presentation process does not need to authenticate the Wallet towards the Verifier.¶
Security Requirement I-50 (conditional): The Issuer must ensure that the credential was stored in a secure Wallet.¶
Then, the Verifier must check that the Issuer actually adheres to this policy.¶
Security Requirement V-20 (conditional): The Verifier must ensure that the credential was issued by an issuer that only issues credentials to trustworthy wallets.¶
The End-User trusts the Issuer, the Wallet, and the Verifier to treat her data securely and only exchange data as needed preserving her privacy. The End-User trusts the Wallet to validate the authenticity of Issuers and Verifiers and provide the End-User with trustworthy information about those.¶
Therefore, the Wallet must provide trustworthy information about Issuers:¶
Security Requirement W-20: The Wallet must provide trustworthy and complete information about Issuers to the End-User.¶
Even more important for Verifiers:¶
Security Requirement W-30: The Wallet must provide trustworthy and complete information about Verifiers to the End-User.¶
Credentials must not be used without the End-Users consent.¶
Privacy Requirement W-40: The Wallet must ask the End-User for meaningful consent before a Credential is used. The Wallet must provide the End-User the opportunity to review any data that is presented to a Verifier.¶
The credential format must allow selective disclosure of data.¶
Privacy Requirement CF-30: The Credential Format must ensure that there is a robust mechanism to ensure that data that is not to be released to a Verifier cannot be extracted by the Verifier (e.g., selective disclosure).¶
The End-User trusts the Issuer and the Wallet provider to protect her from abuse of her Credentials. This mainly means that the implementation of the selected key management and protocols must be secure, but specifically the communication protocols must be designed such that an attacker cannot read (see/exfiltrate) PII.¶
Security/Privacy Requirement P-60: The protocol must ensure that during an interaction with a Verifier, an attacker cannot read PII.¶
Security/Privacy Requirement P-70: The protocol must ensure that during an interaction with an Issuer, an attacker cannot read PII.¶
If an Issuer, Wallet, or Verifier is compromised, the risk for End-Users must be minimized.¶
Security/Privacy Requirement W-50: The Wallet must ensure that the credentials and private keys are protected from unauthorized access.¶
Since data leaks are hard to avoid completely in large ecosystems, the fallout of a compromise must be minimized.¶
Security/Privacy Requirement E-50: The Trust Framework must ensure that lifecycles of keys, certificates, and credentials are designed such that the impact of a compromise is minimized.¶
On the other hand, the End-User does not want the Issuer to learn where she uses the Credentials. This must be supported by the Issuer, the Wallet, and the Trust Framework.¶
Privacy Requirement P-80: The protocol, including the revocation mechanism, must ensure that the Issuer cannot learn where the End-User uses the Credential.¶
Privacy Requirement W-60: The Wallet must ensure that the Issuer cannot learn where the End-User uses the Credential.¶
Privacy Requirement E-60: The Trust Framework must ensure that the Issuer cannot learn where the End-User uses the Credential.¶
When using a Credential at multiple Verifiers, the End-User might not want that the Verifiers learn that the same End-User is using their services (correlation). The exception to this is when the End-Users shares data with the Verifiers that allow for a unique identification, e.g., a name and birth date, or a unique identifier, e.g., a social security number.¶
Privacy Requirement W-70: The Wallet must ensure that the Verifier cannot learn that the same End-User is using other Verifiers (unless desired by the End-User).¶
Privacy Requirement E-70: The Trust Framework must support correlation protection.¶
Privacy Requirement CF-40: The Credential Format must support correlation protection.¶
The following table lists the security and privacy requirements and how they can be fulfilled. Except for the protocol-related requirements, this document does not provide details on how the requirements can be met.¶
| Security Requirement | How to achieve |
|---|---|
| CF-10 | Requirement on the credential format |
| CF-20 | Requirement on the credential format |
| CF-21 | Requirement on the credential format |
| CF-30 | Requirement on the credential format |
| CF-40 | Requirement on the credential format |
| Security Requirement | How to achieve |
|---|---|
| E-10 | Selection of credential format |
| E-20 | Requirement on management of issuers |
| E-30 | Requirement on management of trust |
| E-40 | Requirement on management of trust |
| E-50 | Requirement on lifecycle management; also see Section 3.3 above. |
| E-60 | Requirement on lifecycle management and key distribution |
| E-70 | Requirement on lifecycle management and key distribution |
Note: The involved parties need to access data about identifiers, keys, and Credentials as well as data about the acting parties themselves in order to securely implement the Credential exchange. The way this works is out of scope for OpenID for Verifiable Credential Issuance.¶
| Security Requirement | How to achieve |
|---|---|
| P-10 | see Section 6.2 |
| P-20 | see Section 6.3 |
| P-30 | see Section 6.4 |
| P-40 | see Section 6.5 |
| P-41 | see Section 6.6 |
| P-50 | see Section 6.7 |
| P-60 | see Section 6.8 |
| P-70 | see Section 6.9 |
| P-80 | see Section 6.10 |
| Security Requirement | How to achieve |
|---|---|
| V-00 | Implementation requirement |
| V-01 | Implementation requirement |
| V-10 | TODO add more details in appropriate place |
| V-20 | TODO add more details in appropriate place |
| Security Requirement | How to achieve |
|---|---|
| W-00 | Implementation requirement |
| W-01 | Implementation requirement |
| W-10 | Out of scope |
| W-20 | Implementation and operation requirement |
| W-30 | Implementation and operation requirement |
| W-40 | Implementation and operation requirement |
| W-50 | Implementation and operation requirement (see Section 3.3) |
| W-60 | Implementation and operation requirement |
| W-70 | Implementation and operation requirement |
| Security Requirement | How to achieve |
|---|---|
| I-01 | Implementation requirement |
| I-00 | Implementation requirement |
| I-10 | Implementation and End-User authentication requirement |
| I-20 | Implementation and End-User authentication requirement |
| I-30 | Implementation and operation requirement |
| I-40 | Implementation and operation requirement |
| I-50 | TODO add more details in appropriate place |
OpenID for VC consists of three protocols:¶
The following analysis aims to show that OpenID for VC meets the security and privacy requirements defined in the previous section. This is an informal analysis that may be incomplete or contain mistakes. A formal analysis to confirm the results is yet to be done.¶
For this analysis, the Web Attacker and Network Attacker models defined as (A1) and (A2) in the OAuth Security BCP are assumed. In the context of this specification, the Web Attacker model in particular means that arbitrary Issuers, Wallets, and Verifiers can be under the control of an attacker. The security of all other participants must be ensured nonetheless. For example, the security of a non-compromised Wallet that interacts with multiple Issuers and Verifiers must not be affected by a single compromised Issuer or Verifier.¶
Special considerations are made where requests are forwarded between devices (cross-device) and between mobile apps on the same device (app-to-app).¶
Since it is assumed that the attacker can operate Issuers, the attacker can attempt to perform mix-up type attacks by configuring the credential issuer metadata (cf. Section 10.2. in OID4VCI) under their control according to the following list:¶
TODO: Deferred Credential Endpoint metadata needs to be defined in OID4VCI spec.¶
No Mix-Up:¶
credential_issuer: Attacker's Credential Issuer Identifier¶
authorization_server: Attacker's Authorization Server¶
credential_endpoint: Attacker's Credential Endpoint¶
batch_credential_endpoint: Attacker's Batch Credential Endpoint¶
Mix-Up Type 1:¶
credential_issuer: Attacker's Credential Issuer Identifier¶
authorization_server: Honest Issuer's Authorization Server¶
credential_endpoint: Attacker-controlled Credential Endpoint¶
batch_credential_endpoint: Attacker-controlled Batch Credential
Endpoint¶
TODO 1a, Variant of Type 1: Only deferred endpoint it attacker-controlled.¶
Mix-Up Type 2:¶
credential_issuer: Attacker's Credential Issuer Identifier¶
authorization_server: Attacker-controlled Authorization Server¶
credential_endpoint: Honest Issuer's Credential Endpoint¶
batch_credential_endpoint: Honest Issuer's Batch Credential Endpoint¶
Note that when an attacker-controlled Authorization Server is used, the
attacker can also perform regular OAuth Mix-Up attacks unless prevented by
the iss parameter according to [RFC9207].¶
These configurations will be used in the attack descriptions below.¶
Important: Not in all real-world ecosystems will attackers have enough control to set up configurations necessary for mix-up attacks. (For example, if there is only a single hard-coded Issuer in the ecosystem.)¶
The issuance protocol must ensure that no third party can read the credential issued by the Issuer.¶
On the network level, this is achieved by TLS encrypted connections.¶
On top of TLS, the protocol uses an OAuth 2.0 flow to authorize the release of a credential.¶
Credentials can be released at one of three issuance endpoints:¶
The deferred credential endpoint requires the use of an acceptance token as a bearer token. The acceptance token can be obtained only from the credential endpoint or batch credential endpoint. TODO Is the endpoint a protected resource? Can DPoP or MTLS be enforced? (see https://bitbucket.org/openid/connect/issues/1808/dpop-and-acceptance-tokens)¶
ATTACK: An attacker can configure Mix-Up 1a. The attacker receives an acceptance token from the Wallet's request to the deferred credential endpoint and uses it to obtain a credential from the deferred credential endpoint of the honest server. Potential solution: The credential endpoint and batch credential endpoint can only be accessed by using an access token. Can DPoP or MTLS be enforced for an acceptance token? Better to use access token instead.¶
ATTACK: With Mix-Up 1, the attacker can obtain a credential from the honest server by using the access token it receives via the call to its own credential endpoint. Solution: MTLS or DPoP must be used to prevent this kind of attack if Mix-Up configurations are a concern.¶
An access token can only be obtained from the token endpoint using one
of the existing OAuth grant types or the new grant type
urn:ietf:params:oauth:grant-type:pre-authorized_code defined in the
specification.¶
The protocol must ensure that no third party can interfere with the issuance process such that the Issuer issues Credentials for the third party to the End-User.¶
In order to receive credentials originally created for a different End-User, the Wallet would need to receive it from one of the issuance endpoints listed above.¶
If the Wallet is using a Credential Issuer identifier that is used by an honest party, it can be assumed that all endpoints used in the flow (authorization server, token endpoint, issuance endpoints) are provided by the same, honest party.¶
In this case, the latest point in the flow where an attacker can interfere with the process is the authorization response in the case of the authorization code flow and the pre-authorized code in case of the pre-authorized code flow.¶
In case the Wallet uses a Credential Issuer Identifier under the control of an attacker, the attacker can configure the endpoints of the Issuer as described in Section 6.1.1 above.¶
In the first case (No Mix-Up), the attacker has full control over the flow. The attacker can return, for example, a credential created for an End-User obtained from a completely different Issuer.¶
Recommendation: The Wallet MUST verify that the Issuer of the received credential is the expected Credential Issuer. This means that the credential format needs to encode sufficient information to allow the Wallet to verify this relationship. (New requirement on CF.)¶
In the second case (Mix-Up), other attacks are possible, but regarding interference with the issuance process, the same considerations as in the previous case apply. Using the iss parameter from RFC9207 should help to prevent standard OAuth mix-up attacks.¶
The protocol must ensure that the interaction between the Wallet and Verifier is protected such that no third party can interfere with the interaction by modifying the information transmitted.¶
The target of this attack is the user's device. The attacker needs to be able to inject a presentation into a flow between the user and a Verifier. For this to work, the user has to have started a flow with the Verifier. This means that the Verifier then expects a presentation with a specific audience and nonce.¶
Unless the attacker has access to the initial request between the Verifier and the Wallet, the attacker cannot know the nonce that is expected in the flow. This works similar to the state value in classic OAuth flows.¶
If the attacker does have access to the initial request, the attacker would be able to replay the request on his own device and capture the presentation. The attacker could then use this presentation to inject it into the flow between the user and the Verifier. Similar attacks can happen in classic OAuth flows and are not mitigated by the use of "nonce" or state. However, for this (relatively weak) attack to succeed, a (relatively strong) attacker with access to the communication between the Verifier and the Wallet is required. The likelihood of a successful attack can be reduced when, for the Wallet, claimed URLs are used and custom schemes and endpoints on localhost addresses are avoided.¶
Note: An additional encryption of the request to the Wallet at the application layer would not prevent this attack as the attacker could still replay the encrypted request to the Wallet.¶
PROBLEM: If no holder binding is used, right now, there is no way to
transport the nonce. I.e., an attacker might inject a presentation. In
direct post mode, the Verifier might not even find the session. Just
having an unsigned nonce would help here - i.e., state.¶
The protocol must ensure that the interaction between an attacker and a Verifier cannot be forwarded to and successfully completed by a user.¶
For this attack, an attacker starts a presentation flow with a Verifier. The Verifier generates an authentication request that the attacker can now forward to their victim. The victim might be tricked into thinking that the completion of the flow is necessary and the attacker may or may not impersonate the Verifier for this purpose. The victim authenticates, authorizes the request and a presentation is created and sent to the Verifier. Without further countermeasures, Verifier would accept the presentation and apply it to the session between the attacker and the Verifier. The attacker can now impersonate the Victim. TODO More details for description.¶
The countermeasures against this attack are different in the same-device flow and the cross-device flow.¶
In the same-device flow, the authentication response would be received by the Verifier in the victim's browser. The Verifier should maintain a mapping between user sessions and the nonce that is expected in the flow. The Verifier should only accept a presentation if the nonce in the presentation matches the nonce that is expected for the user session. With this countermeasure, the Verifier can detect if a presentation is sent that was not bound to the user's session or if no user session exists at all, preventing the attack.¶
RECOMMENDATION: While this is expected from OAuth implementations, the importance of this measure should be highlighted in the specification.¶
Note on web-to-app flows: In the case of web-to-app flows (i.e., the Verifier is a website, but the Wallet is an app), the authentication response needs to go back to the same browser where the user started the flow. This may require extra steps in the implementation.¶
In the cross-device flow, the authentication response cannot be sent back to the same browser where the Verifier runs. Instead, the authentication response is sent using the direct post mode in the backend. This means that no session context exists for the Verifier to assure the binding between the browser where the user started the flow and the presentation that is sent to the Verifier.¶
There is currently no widely-available, convenient way to fix this problem. A more detailed discussion including potential countermeasures can be found in the Cross-Device Security BCP.¶
The protocol must ensure that an attacker cannot successfully forward an interaction between a Wallet and a Verifier to a Verifier under his own control.¶
A prerequisite for a successful attack of this kind is that the attacker has access to some messages between the Wallet and the Verifier.¶
The attacker might have access to the authentication response. In this case, the attacker has access to the presentation contained in the VP Token.¶
The attacker can now start an interaction with the Verifier under his control. The attacker can then send the presentation to the Verifier instead of a presentation created by his own Wallet. The Verifier would then accept the presentation and apply it to the session between the attacker and the Verifier. The attacker can now impersonate the End-User.¶
This is prevented by the nonce contained in the authorization request and the presentation. The Verifier can verify that the nonce in the presentation matches the nonce in the authorization request. However, the Verifier must also check that the audience of the presentation matches the Verifier's identifier. Without this check, an attacker could convince the End-User to start a new, independent flow with a Verifier und the attacker's control and re-use the nonce from the original flow in the authentication request. By checking the audience, this attack is prevented.¶
(In the same-device flow, the Verifier usually associates the attacker's session with the selected nonce. In the cross-device flow, the nonce might be used as the single identifier for the flow to which a presentation belongs. In both cases, a nonce that is not the nonce the Verifier selected for the flow with the attacker would not work.)¶
TODO: Analyze -> Injection and -> MITM¶
The protocol must ensure that third parties cannot interfere with the binding process.¶
Open Question: Is the Wallet-provided nonce required?¶
TODO: Analyze -> MITM and the role of redirect URIs.¶
The protocol must ensure that during an interaction with a Verifier, an attacker cannot read PII.¶
As above, it can be assumed that all network connections are secured by TLS.¶
On the level of the OAuth-based protocol, the PII in the form of the presentation is transferred during the authentication response (or, based on an authorization code sent in the authentication response, later in the token response).¶
It is therefore important that the authentication response is not sent to an attacker-controlled endpoint.¶
The authentication response is sent to the redirect URI specified in the request to the Wallet.¶
There are two options for the verification of the redirect URI:¶
If the authorization code flow is used, it must be ensured that the token endpoint URL is authentic as well (i.e., belongs to the same Verifier).¶
TODO Is the above paragraph correct? Also check if the OID4VP spec ensures authenticity of the token endpoint URL.¶
The protocol must ensure that during an interaction with an Issuer, an attacker cannot read PII.¶
*TODO: Analyze -> Encryption, -> MITM, the role of redirect URIs.¶
The protocol must ensure that the Issuer cannot learn where the End-User uses the Credential.¶
The interaction between the Wallet and the Verifier is not inherently tied to any interaction between either the Wallet and the Issuer or the Verifier and the Issuer, with the following (potential) exceptions:¶
Recommendation: Wallets can be designed to avoid this by, for example, by refreshing credentials at a random point in time.¶
Recommendation: The Verifier can be designed to avoid this by, for example, by caching the data for a random period of time.¶
TODO To be discussed: Difference Same-Device Cross-Device where not discussed already.¶