improvement(credentials): hold unsaved keyless subjects so trust policies applied later still match

Author: waleedlatif1

apps/docs/content/docs/cli/credentials.mdx

@@ -97,7 +97,9 @@ The printed audience is the default. To have Sim sign tokens for your own audien
 
 Step 2: add those values to keylessConfig and pass it to `sim credentials create <providerId> --credentials @file`.
 
-The proof expires after 24 hours and works only for the user who requested it, with the same providerId. If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
+The proof expires after 24 hours and works only for the user who requested it, with the same providerId. Sim holds the subject for you for 30 days until a credential saves it, so a trust configuration that takes longer to apply still works: renew the proof with `sim credentials keyless-subject <providerId> --subject <subject>`. The subject stays the same, and each renewal restarts the 30 days. Sim holds your 20 newest unsaved subjects per provider in a workspace; issuing more drops the oldest.
+
+If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, renew the proof and retry. If it reports WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
 
 **Examples**
 
@@ -351,7 +353,7 @@ API request and response schemas: [deleteCredential](/api-reference/credentials/
 OAuth login or personal API key required.
 
 ```bash
-sim credentials keyless-subject <providerId>
+sim credentials keyless-subject <providerId> [options]
 ```
 
 **Arguments**
@@ -364,6 +366,16 @@ sim credentials keyless-subject <providerId>
 
 </CommandTable>
 
+**Options**
+
+<CommandTable>
+
+| Option | Required | Description |
+| --- | --- | --- |
+| `--subject <subject>` | No | Renew the proof for a subject Sim issued to you earlier, instead of issuing a new one. |
+
+</CommandTable>
+
 Keyless (workload identity) credentials take two steps.
 
 Step 1: run `sim credentials keyless-subject <providerId> --output json` and configure your cloud to trust the printed issuer, audience, and subject. Its requiredConfigFields lists the values your provider's keylessConfig still needs.
@@ -372,7 +384,9 @@ The printed audience is the default. To have Sim sign tokens for your own audien
 
 Step 2: add those values to keylessConfig and pass it to `sim credentials create <providerId> --credentials @file`.
 
-The proof expires after 24 hours and works only for the user who requested it, with the same providerId. If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
+The proof expires after 24 hours and works only for the user who requested it, with the same providerId. Sim holds the subject for you for 30 days until a credential saves it, so a trust configuration that takes longer to apply still works: renew the proof with `sim credentials keyless-subject <providerId> --subject <subject>`. The subject stays the same, and each renewal restarts the 30 days. Sim holds your 20 newest unsaved subjects per provider in a workspace; issuing more drops the oldest.
+
+If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, renew the proof and retry. If it reports WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
 
 **Examples**
 

apps/docs/content/docs/cli/reference.mdx

@@ -784,7 +784,9 @@ The printed audience is the default. To have Sim sign tokens for your own audien
 
 Step 2: add those values to keylessConfig and pass it to `sim credentials create <providerId> --credentials @file`.
 
-The proof expires after 24 hours and works only for the user who requested it, with the same providerId. If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
+The proof expires after 24 hours and works only for the user who requested it, with the same providerId. Sim holds the subject for you for 30 days until a credential saves it, so a trust configuration that takes longer to apply still works: renew the proof with `sim credentials keyless-subject <providerId> --subject <subject>`. The subject stays the same, and each renewal restarts the 30 days. Sim holds your 20 newest unsaved subjects per provider in a workspace; issuing more drops the oldest.
+
+If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, renew the proof and retry. If it reports WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
 
 **Examples**
 
@@ -801,7 +803,7 @@ API request and response schemas: [createServiceAccountCredential](/api-referenc
 Issue the subject and proof for a new keyless (workload identity) credential (OAuth login or personal API key required)
 
 ```bash
-sim credentials keyless-subject <providerId>
+sim credentials keyless-subject <providerId> [options]
 ```
 
 **Arguments**
@@ -814,6 +816,16 @@ sim credentials keyless-subject <providerId>
 
 </CommandTable>
 
+**Options**
+
+<CommandTable>
+
+| Option | Required | Description |
+| --- | --- | --- |
+| `--subject <subject>` | No | Renew the proof for a subject Sim issued to you earlier, instead of issuing a new one. |
+
+</CommandTable>
+
 Keyless (workload identity) credentials take two steps.
 
 Step 1: run `sim credentials keyless-subject <providerId> --output json` and configure your cloud to trust the printed issuer, audience, and subject. Its requiredConfigFields lists the values your provider's keylessConfig still needs.
@@ -822,7 +834,9 @@ The printed audience is the default. To have Sim sign tokens for your own audien
 
 Step 2: add those values to keylessConfig and pass it to `sim credentials create <providerId> --credentials @file`.
 
-The proof expires after 24 hours and works only for the user who requested it, with the same providerId. If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
+The proof expires after 24 hours and works only for the user who requested it, with the same providerId. Sim holds the subject for you for 30 days until a credential saves it, so a trust configuration that takes longer to apply still works: renew the proof with `sim credentials keyless-subject <providerId> --subject <subject>`. The subject stays the same, and each renewal restarts the 30 days. Sim holds your 20 newest unsaved subjects per provider in a workspace; issuing more drops the oldest.
+
+If creation reports WORKLOAD_IDENTITY_PROOF_EXPIRED, renew the proof and retry. If it reports WORKLOAD_IDENTITY_PROOF_INVALID, WORKLOAD_IDENTITY_SUBJECT_REQUIRED, WORKLOAD_IDENTITY_SUBJECT_IN_USE, run step 1 again, trust the new subject, and retry.
 
 **Examples**
 

apps/docs/content/docs/integrations/aws-credentials.mdx

@@ -61,12 +61,12 @@ aws iam add-client-id-to-open-id-connect-provider \
 A provider holds up to 100 audiences. Once no role relies on `sts.amazonaws.com` any more, you can remove it from the provider. Reconnecting the credential keeps its audience; clearing the field returns it to the default.
 
 <Callout type="info">
-The subject is unique to the credential. Reconnecting a keyless credential keeps its subject by default, so the role's trust policy keeps working; choose **Issue a new subject** only if you also update the trust policy.
+The subject is unique to the credential once it is saved. Reconnecting a keyless credential keeps its subject by default, so the role's trust policy keeps working; choose **Issue a new subject** only if you also update the trust policy.
 </Callout>
 
 ### From the API or CLI [#keyless-api-cli]
 
-Run `sim credentials keyless-subject aws-service-account`, trust the printed subject as above, then add `roleArn` (optionally `stsRegion`, `sessionDurationSeconds`, and `audience`) to its `keylessConfig` and pass it to `sim credentials create aws-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it.
+Run `sim credentials keyless-subject aws-service-account`, trust the printed subject as above, then add `roleArn` (optionally `stsRegion`, `sessionDurationSeconds`, and `audience`) to its `keylessConfig` and pass it to `sim credentials create aws-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. Sim holds an unsaved subject for you for 30 days, so a trust configuration that takes longer to apply still works: reopening the connect dialog offers the same subject, and `--subject <subject>` renews its proof from the CLI.
 
 ## Use access keys
 

apps/docs/content/docs/integrations/databricks-credentials.mdx

@@ -50,7 +50,7 @@ Databricks accepts any non-empty audience; Sim takes up to 255 letters, digits,
 
 ### From the API or CLI [#keyless-api-cli]
 
-Run `sim credentials keyless-subject databricks-service-account`, trust the printed subject as above, then add `host` and `clientId` (and optionally `audience`) to its `keylessConfig` and pass it to `sim credentials create databricks-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it.
+Run `sim credentials keyless-subject databricks-service-account`, trust the printed subject as above, then add `host` and `clientId` (and optionally `audience`) to its `keylessConfig` and pass it to `sim credentials create databricks-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. Sim holds an unsaved subject for you for 30 days, so a trust configuration that takes longer to apply still works: reopening the connect dialog offers the same subject, and `--subject <subject>` renews its proof from the CLI.
 
 ## Self-hosted deployments
 

apps/docs/content/docs/integrations/google-service-account.mdx

@@ -247,7 +247,7 @@ Self-hosted deployments need `WORKLOAD_IDENTITY_SIGNING_KEY` set and an `https`
 
 ### From the API or CLI [#keyless-api-cli]
 
-Run `sim credentials keyless-subject google-service-account`, trust the printed subject as above, then add `projectNumber`, `poolId`, `providerId`, and `serviceAccountEmail` (and optionally `audience`) to its `keylessConfig` and pass it to `sim credentials create google-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. For domain-wide delegation, also add `"delegation": {"user": "alice@yourcompany.com", "services": ["gmail", "google-drive"]}`, listing any of `gmail`, `google-drive`, `google-docs`, `google-sheets`, and `google-calendar`.
+Run `sim credentials keyless-subject google-service-account`, trust the printed subject as above, then add `projectNumber`, `poolId`, `providerId`, and `serviceAccountEmail` (and optionally `audience`) to its `keylessConfig` and pass it to `sim credentials create google-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. Sim holds an unsaved subject for you for 30 days, so a trust configuration that takes longer to apply still works: reopening the connect dialog offers the same subject, and `--subject <subject>` renews its proof from the CLI. For domain-wide delegation, also add `"delegation": {"user": "alice@yourcompany.com", "services": ["gmail", "google-drive"]}`, listing any of `gmail`, `google-drive`, `google-docs`, `google-sheets`, and `google-calendar`.
 
 ### Keyless domain-wide delegation [#keyless-domain-wide-delegation]
 

apps/docs/content/docs/integrations/microsoft-app-credentials.mdx

@@ -75,7 +75,7 @@ An app can have up to 20 federated credentials. Each Sim credential has its own
 
 ### From the API or CLI [#keyless-api-cli]
 
-Run `sim credentials keyless-subject microsoft-app-service-account`, trust the printed subject as above, then add `tenantId` and `clientId` (optionally `environmentUrl`, `cloud` as `usgov`, `usgov_dod`, or `china`, and `audience` for a [custom audience](#custom-audience)) to its `keylessConfig` and pass it to `sim credentials create microsoft-app-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it.
+Run `sim credentials keyless-subject microsoft-app-service-account`, trust the printed subject as above, then add `tenantId` and `clientId` (optionally `environmentUrl`, `cloud` as `usgov`, `usgov_dod`, or `china`, and `audience` for a [custom audience](#custom-audience)) to its `keylessConfig` and pass it to `sim credentials create microsoft-app-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. Sim holds an unsaved subject for you for 30 days, so a trust configuration that takes longer to apply still works: reopening the connect dialog offers the same subject, and `--subject <subject>` renews its proof from the CLI.
 
 ## Use a client secret or certificate
 

apps/docs/content/docs/integrations/snowflake-service-account.mdx

@@ -58,7 +58,7 @@ Snowflake requires each issuer and subject pair to be unique in an account, and
 
 ### From the API or CLI [#keyless-api-cli]
 
-Run `sim credentials keyless-subject snowflake-service-account`, trust the printed subject as above, then add `host` (and `audience`, if you listed one in `OIDC_AUDIENCE_LIST`) to its `keylessConfig` and pass it to `sim credentials create snowflake-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it.
+Run `sim credentials keyless-subject snowflake-service-account`, trust the printed subject as above, then add `host` (and `audience`, if you listed one in `OIDC_AUDIENCE_LIST`) to its `keylessConfig` and pass it to `sim credentials create snowflake-service-account`. See [the CLI credentials reference](/cli/credentials) for the full two-step example; the proof expires after 24 hours and works only for the user who requested it. Sim holds an unsaved subject for you for 30 days, so a trust configuration that takes longer to apply still works: reopening the connect dialog offers the same subject, and `--subject <subject>` renews its proof from the CLI.
 
 ### Self-hosted deployments