- This section is a work in progress as this document evolves. + This section is a work in progress as this document evolves.
+This section lists the use scenarios for the API - in other words, information about its expected use.
+The Digital Credentials API is part of and integrated into a broader ecosystem related to digital credentials. + Therefore, this section does not specify all security considerations, threats, and mitigations of the ecosystem, but + only those related to, directly linked to, or influenced by the Digital Credentials API.
+It is important to note that the Digital Credentials API was created to mitigate other possible approaches to + presenting digital credentials on the web, such as customs schemes + [[concerns-with-custom-schemes-for-identity-presentment]], and that Digital Credentials are also an alternative to + sending paper documents (e.g., scanned government documents) over the web.
+The Digital Credentials API mediates the communication of the presentation from a verifier using a web application to the + [=holder=], and the issuance of the credential to the [=holder=] when the issuer uses a web + application.
+Presentation Workflow
+The section lists the external dependencies on other entities that can impact the security. These dependencies + contain assumptions made about the usage or behaviour of those other components or products. External + dependencies are requirements levied on systems outside the API.
+Therefore, the Threat Model for Digital Credentials API - and the resulting Security considerations - depends to + other Threat Models:
+Other dependencies relate to the ecosystem, in particular: supported protocols, credential format, and revocation + methods used.
+Finally, another important aspect relates to the security posture of the verifier application, which, even if + legitimate, could have vulnerabilities e.g., Cross Site Scripting (XSS), Cross-Site Request Forgery (CSRF) or + otherwise be compromised.
+This section describes the security assumptions, 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.
+The browser assumes the role of a trusted entity. It enforces its security features - such as same-origin policies + (SOP), executes Content Security Policy (CSP) and Cross-Origin Resource Sharing (CORS) checks, presents a secure, + non-forgeable UI that users can trust, and avoids containing or executing malicious third-party scripts or malicious + extensions.
+The browser is responsible for mediating the flow and preventing unauthorized access to credentials, and has a + trusted relationship with the Wallet.
+Given that the API acts as a mediator in the presentation of credentials, which are the asset to be protected, and + contains a registry of a series of protocols, it assumes that some threats are handled by the protocols and that, + being Internet protocols, they MUST comply with the provisions of RFC 3552 [[RFC3552]].
+The protocols need to consider and mitigate at least for the following attacks: eavesdropping, replay, message + insertion, deletion, modification, and man-in-the-middle.
+Furthermore, if they include query languages, they must be protected against injection vulnerabilities.
+- The documents listed below outline initial security considerations - for Digital Credentials, both broadly and for presentation on the - web. Their contents will be integrated into this document gradually. + The documents listed below outline initial security considerations for the Digital Credentials API. Their contents will be integrated into this document gradually.