Add linked description for a use case

README.md

@@ -16,7 +16,9 @@ This is the repository for Device Bound Session Credentials. You're welcome to
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 
 - [Introduction](#introduction)
-  - [Goals [or Motivating Use Cases, or Scenarios]](#goals-or-motivating-use-cases-or-scenarios)
+  - [Definitions](#definitions)
+  - [Goals](#goals)
+  - [Motivating use cases](#motivating-use-cases)
   - [Non-goals](#non-goals)
   - [What makes Device Bound Session Credentials different](#what-makes-device-bound-secure-credentials-different)
     - [Application-level binding](#application-level-binding)
@@ -41,11 +43,29 @@ DBSC offers an API for websites to control the lifetime of such keys, behind the
 
 DBSC is bound to a device with cryptographic keys that cannot be exported from the user’s device under normal circumstances, this is called device binding in the rest of this document. DBSC provides an API that servers can use to create a session bound to a device, and this session can periodically be refreshed with an optional cryptographic proof the session is still bound to the original device. At sign-in, the API informs the browser that a session starts, which triggers the key creation. It then instructs the browser that any time a request is made while that session is active, the browser should ensure the presence of certain cookies. If these cookies are not present, DBSC will hold network requests while querying the configured endpoint for updated cookies.
 
+### Definitions
+
+* `Session Credential` - The session cookie return from the service to the user's device. This session cookie represents sustained proof of user identity. It's purpose is to be used by the user's device to generate temporary access tokens so that requests from the user's device can be authenticated.
+* `Access Token` - A cookie or other token passed in a request body, url, or header which identifies the user. Must be a short lived token and is not protected by DBSC.
+
 ### Goals
 Reduce session theft by offering an alternative to long-lived cookie bearer tokens, that allows session authentication that is bound to the user's device. This makes the internet safer for users in that it is less likely their identity is abused, since malware is forced to act locally and thus becomes easier to detect and mitigate. At the same time the goal is to disrupt the cookie theft ecosystem and force it to adapt to new protections.
 
+### Motivating use cases
+The primary driving factor is dealing with the threat of malware installed by an attacker on a user's device. By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value. We think this will substantially reduce the success rate of cookie theft malware. Attackers would be forced to act locally on the device, which makes on-device detection and cleanup more effective, both for anti-virus software as well as for enterprise managed devices. [Source](https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html)
+
+A concrete example was the [Phishing campaign targets YouTube creators with cookie theft malware (article from 2021)](https://blog.google/threat-analysis-group/phishing-campaign-targets-youtube-creators-cookie-theft-malware/) where attackers attempted to phish and install malware on YouTube creators to exfiltrate their cookies. However, even after the malware has been removed the attacker still has access to the YouTube creators accounts.
+
+For the rest of the DBSC proposal, it is a requirement to explicitly handle the scenario where malware was installed on the user's device and has similar access to the browser or other installed applications, such as:
+* Access to any and all data saved by the browser
+* Direct access to call a TPM's public API
+
+Once the attacker is no longer resident on the user's device, the authentication session binding will prevent the attacker from further access to the user's session credentials.
+
 ### Non-goals
-DBSC will not prevent temporary access to the browser session while the attacker is resident on the user’s device. The private key should be stored as safe as modern desktop operating systems allow, preventing exfiltrating of the session private key, but the signing capability will still be available for any program running as the user on the user’s device. 
+DBSC will not prevent temporary access to the browser session while the attacker is resident on the user’s device. The private key should be stored as safe as modern desktop operating systems allow, preventing exfiltrating of the session private key, but the signing capability will still be available for any program running as the user on the user’s device.
+
+DBSC also will not prevent temporary access to derived credentials generated by the session credentials. The best solution for these has always been and will always be short lived access tokens generated by providing identity via the session credential.
 
 ### What makes Device Bound Session Credentials different
 DBSC is not the first proposal towards these goals, with a notable one being [Token Binding](https://en.wikipedia.org/wiki/Token_Binding). This proposal offers two important features that we believe makes it easier to deploy than previous proposals. DBSC provides application-level binding and browser initiated refreshes that can make sure devices are still bound to the original device.