Description
A security assumption is an implicit or explicit fact or condition upon which the API security relies. These conditions or facts are expected to be true for the API to operate securely. If these assumptions prove false, they can introduce vulnerabilities.
These are the assumptions relating to Platform/OS we have identified.
1. Trusted User Agent
It is assumed that the browser, the system Credential Manager, and the wallet (which together form the user-agent environment) are all trusted.
Specifically:
- The browser enforces web security policies - Same-Origin Policy (SOP), Content Security Policy (CSP), and Cross-Origin Resource Sharing (CORS) - operates in a secure context (HTTPS) and requires a genuine user gesture for all DC API calls (e.g., navigator.credentials.get(…) and cross-device interactions).
- The system Credential Manager presents a native, non-forgeable picker UI for users to select credentials.
- The wallet displays a native, non-forgeable approval UI (e.g., PIN or biometric prompt) to confirm requester identity and requested data before signing the Verifiable Presentation (e.g., vp_token).
Suppose any component—browser, Credential Manager, wallet, or underlying operating system—is subverted or executes malicious code (e.g., via malware, exploits, or root access). The DC API’s security guarantees cannot be upheld in that case.
2. Trusted Credential Providers
It is assumed that only wallet applications explicitly registered their credentials and match with the system Credential Manager are ever invoked. Unregistered or unauthorized apps cannot supply credential descriptors or intercept DC API requests, and any rogue provider could otherwise forge or tamper with descriptors.
3. Secure Network and Transport
It is assumed that all DC API interactions—between user page (e.g., running RP JavaScript) and Credential Manager (e.g., same-device IPC), between Credential Manager and Wallet (e.g., same-device IPC), during cross-device BLE handshakes (e.g., CTAP 2.2 over BLE LE Secure Connections), and between the user agent and RP (e.g., HTTPS with TLS 1.3+)—use protected transports. Confidentiality and integrity cannot be ensured if any IPC isn’t sandboxed or BLE/TLS is misconfigured.
4. Correct Cryptographic Registration
It is assumed that Relying Parties have registered the public keys they use to sign each DigitalCredentialGetRequest (for example, via a JWKS in client_metadata as in OpenID4VP) and that Wallets hold those up-to-date keys to verify requests. It is also assumed that each Verifiable Presentation provides the Wallet’s public key (e.g., either embedded as a JWK or referenced via a DID so that Relying Parties can verify the VP’s signature. If registered keys are stale, mismatched, or revoked, signature validation (for request or response) may fail or be bypassed, breaking authenticity checks.
5. Robust Operating Environment
It is assumed that the device’s operating system and browser processes are not already compromised by malware capable of exfiltrating or manipulating in-memory state. In a fully compromised environment, even the strongest DC API mitigations (signatures, encryption, nonce binding) cannot prevent credential theft or tampering.
[@Sh-Amir and @ZAnsaroudi]