diff --git a/libs/auth/src/angular/input-password/input-password.mdx b/libs/auth/src/angular/input-password/input-password.mdx
index e3cdcbf08b9..95a0bd25710 100644
--- a/libs/auth/src/angular/input-password/input-password.mdx
+++ b/libs/auth/src/angular/input-password/input-password.mdx
@@ -11,9 +11,7 @@ Specifically, it does the following:
 
 1. Displays form fields in the UI
 2. Validates form fields
-3. Generates cryptographic properties based on the form inputs (e.g. `newMasterKey`,
-   `newServerMasterKeyHash`, etc.)
-4. Emits the generated properties to the parent component
+3. Emits values to the parent component
 
 The `InputPasswordComponent` is central to our set/change password flows, allowing us to keep our
 form UI and validation logic consistent. As such, it is intended for re-use in different set/change
@@ -30,7 +28,6 @@ those values as needed.
 - [The InputPasswordFlow](#the-inputpasswordflow)
   - [Use Cases](#use-cases)
   - [HTML - Form Fields](#html---form-fields)
-  - [TypeScript - Credential Generation](#typescript---credential-generation)
   - [Difference between SetInitialPasswordAccountRegistration and SetInitialPasswordAuthedUser](#difference-between-setinitialpasswordaccountregistration-and-setinitialpasswordautheduser)
 - [Validation](#validation)
 - [Submit Logic](#submit-logic)
@@ -44,9 +41,9 @@ those values as needed.
 **Required**
 
 - `flow` - the parent component must provide an `InputPasswordFlow`, which is used to determine
-  which form input elements will be displayed in the UI and which cryptographic keys will be created
-  and emitted. [Click here](#the-inputpasswordflow) to learn more about the different
-  `InputPasswordFlow` options.
+  which form input elements will be displayed in the UI and which values will be emitted.
+  [Click here](#the-inputpasswordflow) to learn more about the different `InputPasswordFlow`
+  options.
 
 **Optional (sometimes)**
 
@@ -54,7 +51,7 @@ These two `@Inputs` are optional on some flows, but required on others. Therefor
 are not marked as `{ required: true }`, but there _is_ component logic that ensures (requires) that
 the `email` and/or `userId` is present in certain flows, while not present in other flows.
 
-- `email` - allows the `InputPasswordComponent` to generate a master key
+- `email` - allows the `InputPasswordComponent` to use the email as a salt (if needed)
 - `userId` - allows the `InputPasswordComponent` to do things like get the user's `kdfConfig`,
   verify that a current password is correct, and perform validation prior to user key rotation on
   the parent
@@ -87,8 +84,7 @@ These `@Inputs` are truly optional.
 ## The `InputPasswordFlow`
 
 The `InputPasswordFlow` is a crucial and required `@Input` that influences both the HTML and the
-credential generation logic of the component. It is important for the dev to understand when to use
-each flow.
+logic of the component. It is important for the dev to understand when to use each flow.
 
 ### Use Cases
 
@@ -156,22 +152,6 @@ which form field UI elements get displayed.
 
 <br />
 
-### TypeScript - Credential Generation
-
-- **`SetInitialPasswordAccountRegistration`** and **`SetInitialPasswordAuthedUser`**
-  - These flows involve a user setting their password for the first time. Therefore on submit the
-    component will only generate new credentials (`newMasterKey`) and not current credentials
-    (`currentMasterKey`).<br /><br />
-- **`ChangePassword`** and **`ChangePasswordWithOptionalUserKeyRotation`**
-  - These flows both require the user to enter a current password along with a new password.
-    Therefore on submit the component will generate current credentials (`currentMasterKey`) along
-    with new credentials (`newMasterKey`).<br /><br />
-- **`ChangePasswordDelegation`**
-  - This flow does not generate any credentials, but simply validates the new password and emits it
-    up to the parent.
-
-<br />
-
 ### Difference between `SetInitialPasswordAccountRegistration` and `SetInitialPasswordAuthedUser`
 
 These two flows are similar in that they display the same form fields and only generate new
@@ -183,7 +163,7 @@ credentials, but we need to keep them separate for the following reasons:
   and **thus an active account `userId`**:
 
 The presence or absence of an active account `userId` is important because it determines how we get
-the correct `kdfConfig` prior to key generation:
+the correct `kdfConfig`:
 
 - If there is no `userId` passed down from the parent, we default to `DEFAULT_KDF_CONFIG`
 - If there is a `userId` passed down from the parent, we get the `kdfConfig` from state using the
@@ -223,25 +203,16 @@ When the form is submitted, the `InputPasswordComponent` does the following in o
      checkbox)
    - Checks that the new password adheres to any enforced master password policies that were
      optionally passed down by the parent
-2. Uses the form inputs to create cryptographic properties (`newMasterKey`,
-   `newServerMasterKeyHash`, etc.)
-3. Emits those cryptographic properties up to the parent (along with other values defined in
-   `PasswordInputResult`) to be used by the parent as needed.
+2. Emits values up to the parent (along with other values defined in `PasswordInputResult`) to be
+   used by the parent as needed.
 
 ```typescript
 export interface PasswordInputResult {
   currentPassword?: string;
-  currentMasterKey?: MasterKey;
-  currentServerMasterKeyHash?: string;
-  currentLocalMasterKeyHash?: string;
-
   newPassword: string;
-  newPasswordHint?: string;
-  newMasterKey?: MasterKey;
-  newServerMasterKeyHash?: string;
-  newLocalMasterKeyHash?: string;
-
   kdfConfig?: KdfConfig;
+  salt?: MasterPasswordSalt;
+  newPasswordHint?: string;
   rotateUserKey?: boolean;
 }
 ```