FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[Improvement] Add API credential lifecycle workflow pack by vinay-kumar-3574 · Pull Request #80 · FinanceFlash/unvibecode · GitHub

Repository navigation

Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension .md  (14) All 1 file type selected
Viewed files
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Unified
Split
Hide whitespace
Diff view
Unified
Split
Hide whitespace
1 change: 1 addition & 0 deletions prebuilt-workflow-paths/README.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,7 @@ No installation, generator, schema, or build step is required. Every workflow is
| [Fraud-risk Scoring, Step-up, Block, and Case Creation](fraud-risk-check-step-up-block-and-investigation/) | evaluates protected actions and may allow, challenge, hold, block, or investigate them |
| [Right-to-erasure and Account-data Deletion](account-data-deletion-and-right-to-erasure/) | verifies and executes deletion or anonymization requests across data stores and processors |
| [Scheduled Job Execution, Checkpoint, Retry, and Recovery](scheduled-job-execution-retry-and-recovery/) | runs scheduled work with leases, bounded input windows, checkpoints, retries, and repair |
| [API Credential Lifecycle Management](api-credential-lifecycle-management/) | creates, activates, rotates, expires, and revokes API credentials while enforcing scope, authorization, and recovery |

The navigation categories are only for discovery. Each workflow has its own clear start, end, stages, effects, permissions, and recovery boundary.

Expand Down
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
# Core 20 Scenarios

| # | Scenario | Must not happen |
|---:|---|---|
| 1 | Authorized credential creation | An unauthorized or incorrectly scoped credential becomes active |
| 2 | Unauthorized credential creation | A requester without sufficient permission receives an active credential |
| 3 | Invalid scope during creation | A credential becomes active with permissions beyond the approved scope |
| 4 | Credential activation | A credential becomes usable before required authorization and activation checks complete |
| 5 | Duplicate credential creation | A retry creates multiple active credentials for one logical creation request |
| 6 | First successful credential use | A credential belonging to another owner, application, service, or scope is accepted |
| 7 | Expired credential rejection | An expired credential continues to authorize protected API access |
| 8 | Credential nearing expiry | A credential reaches expiry without the expected lifecycle transition or actionable renewal indication |
| 9 | Planned credential rotation | Rotation leaves the system without a valid authorized credential when continuity is required |
| 10 | Controlled temporary overlap during rotation | Temporary overlap becomes indefinite or creates an uncontrolled number of active credentials |
| 11 | Old credential invalidation after rotation | The previous credential remains usable after completed rotation when it should be invalidated |
| 12 | Concurrent rotation attempts | Concurrent operations leave contradictory active credentials or corrupt lifecycle metadata |
| 13 | Credential revocation | The system reports revocation while the credential remains authorized for protected API access |
| 14 | Use after revocation | A revoked credential continues to provide protected API access |
| 15 | Emergency revocation of compromised credential | A known compromised credential remains active because the normal lifecycle process is still pending |
| 16 | Credential-generation dependency failure | A dependency failure leaves a partially provisioned credential incorrectly marked active |
| 17 | Partial rotation failure | A failed rotation is reported as complete when the replacement is unusable or the previous credential was incorrectly invalidated |
| 18 | Retry after incomplete lifecycle operation | A retry creates duplicate credentials or conflicting lifecycle states |
| 19 | Lifecycle change succeeds but audit recording fails | A lifecycle operation silently loses required audit evidence while being presented as fully traceable |
| 20 | Recovery and final-state reconciliation | Recovery leaves contradictory states or marks a credential healthy without verifying its actual state |

Full details are in [TESTING_GUIDE.md](TESTING_GUIDE.md).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# Engineering Guide

## Trace the implementation
1. Credential creation, rotation, revocation, expiry, activation, and recovery entry points
2. Requester, owner, service identity, permission, scope, environment, and assignment checks
3. Credential generation, metadata, lifecycle state, expiry, replacement, and invalidation logic
4. Application or service credential loading and protected API authentication checks
5. Rotation coordination, old/new credential overlap, activation, and superseded-credential invalidation
6. Revocation, emergency compromise handling, expiry enforcement, and downstream authorization checks
7. Idempotency keys, uniqueness constraints, concurrency controls, checkpoints, retry, reconciliation, and recovery
8. Audit events, security monitoring, lifecycle notifications, metrics, administrative tools, and tests

## Rules the code should protect
- Only an authorized actor or service may create, rotate, or revoke a credential
- Credential ownership, assignment, environment, scope, and lifecycle state must remain bound to the intended target
- A credential must not become usable before required authorization and activation checks complete
- Credentials must not receive permissions beyond their approved scope
- Expired and revoked credentials must not authorize protected API access
- Completed rotation must leave the previous credential invalidated according to the defined rotation policy
- Temporary credential overlap must be bounded and must not become an unintended permanent state
- Retries and concurrent lifecycle operations must not create duplicate or contradictory credential states
- Partial lifecycle operations must remain identifiable and recoverable rather than being reported as completed
- Lifecycle actions and recovery outcomes must remain traceable through protected audit evidence

## Build or change safely
1. Confirm credential policy, authorization, scope, expiry, rotation, and revocation decisions before relying on framework or provider defaults.
2. Follow the repository's existing authorization, state-management, secret-handling, logging, monitoring, and testing conventions.
3. Bind every lifecycle action to the authoritative actor, credential, owner, application or service, scope, environment, version, and current state.
4. Enforce authorization, scope, uniqueness, lifecycle-state, expiry, concurrency, and revocation rules at the point where they have material effect.
5. Never expose credential secrets through logs, audit records, generated reports, error messages, or test fixtures.
6. Make creation, rotation, revocation, and recovery retries safe after partial failure or lost responses.
7. Keep lifecycle decisions, state transitions, downstream authorization effects, and inconsistencies visible and repairable.
8. Add or update tests covering the core 20 scenarios.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
name: implement-api-credential-lifecycle
description: Implement or modify API Credential Lifecycle Management. Use when adding or changing credential validation, authorization, scope, lifecycle state, activation, expiry, rotation, revocation, external effects, retries, recovery, audit, security controls, monitoring, or tests.
---

# Implement API Credential Lifecycle

Confirm:
- Who may create, rotate, revoke, or recover a credential and what authorization is required
- Which owners, applications, services, environments, and tenants a credential may be assigned to
- Which permission scopes are allowed and how excessive scope is rejected
- Which credential lifecycle states exist and which transitions are permitted
- When credentials become active and when they expire
- Whether old and replacement credentials may overlap during rotation and when the old credential must be invalidated
- How emergency revocation works for compromised credentials
- How duplicate requests, concurrent operations, lost responses, and partial lifecycle operations are handled
- Which credential-generation, activation, API, audit, and other dependencies are in scope
- What lifecycle evidence must be recorded and what credential secrets or sensitive information must never be exposed

Follow project conventions and protect:
- Only an authorized actor or service may create, rotate, or revoke a credential
- Credential ownership, assignment, environment, scope, and lifecycle state must remain bound to the intended target
- Credentials must not become usable before required authorization and activation checks complete
- Credentials must not receive permissions beyond their approved scope
- Expired and revoked credentials must not authorize protected API access
- Completed rotation must leave the previous credential invalidated according to the defined rotation policy
- Temporary credential overlap must remain bounded and must not become an unintended permanent state
- Retries, replays, concurrent operations, and lost responses must not create duplicate or contradictory credential states
- Partial lifecycle operations must remain identifiable and recoverable rather than being reported as completed
- Credential secrets, privileged lifecycle data, and audit evidence must remain protected

Add or update all relevant core tests and summarize decisions, files, lifecycle state changes, recovery, audit and security controls, and remaining gaps.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Paths and Edge Cases

## Supported paths
- Authorized credential creation and activation
- Credential use with approved owner, application, service, and scope
- Planned credential rotation with controlled old/new credential overlap
- Expiry and renewal handling
- Credential revocation and emergency revocation
- Duplicate request handling, idempotency, reconciliation, and recovery
- Dependency failure, partial lifecycle completion, and manual repair

## Normal paths
- An authorized actor creates a credential with an approved scope and assigns it to the intended application or service
- An active credential successfully accesses the protected API within its permitted scope
- An authorized rotation provisions and activates a replacement before invalidating the previous credential according to policy
- An authorized revocation invalidates the credential and records the completed lifecycle action

## Denied paths
- Requester lacks permission to create, rotate, or revoke the credential
- Requested scope exceeds the requester's or application's allowed permissions
- Credential assignment targets an unauthorized application, service, environment, or owner
- Expired or revoked credentials attempt to access the protected API
- Emergency lifecycle action is attempted without the required authority

## Timing, concurrency, and boundaries
- Two credential creation requests for the same logical operation execute together
- Two rotation operations target the same credential concurrently
- A credential reaches expiry exactly during an API request or rotation
- Old and replacement credentials overlap at the rotation boundary
- A credential becomes compromised while a normal rotation is already in progress
- Credential generation succeeds but activation or state update fails
- A lifecycle operation succeeds but its response or audit record is lost
- Different lifecycle components disagree about the credential's current state
- A retry occurs after a partially completed creation, rotation, or revocation
- Recovery runs after a dependency timeout or incomplete lifecycle operation

Cover valid, invalid, duplicate, stale, replayed, repeated, simultaneous, partially completed, unauthorized, expired, revoked, compromised, and recovery outcomes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Permission and Abuse Guide

## Permission boundaries
- Only an authorized credential owner, service operator, administrator, or approved security actor may create, rotate, or revoke a credential
- Credential lifecycle actions must bind the intended owner, application or service, environment, credential, scope, and current lifecycle state
- Requested permissions must remain within the actor's and target application's allowed scope
- Credential assignment must not cross owner, application, service, environment, or tenant boundaries
- Emergency revocation must require the authority defined for compromised-credential response
- Temporary credential overlap during rotation must be policy-bound, time-bounded, and auditable
- Lifecycle state changes must not be performed solely from an untrusted credential identifier or request identifier
- Recovery and reconciliation must preserve the authoritative ownership, scope, and lifecycle state

## Misuse paths
- Unauthorized credential creation — An actor obtains an active credential without sufficient authority
- Excessive credential scope — A credential receives permissions beyond the approved application or business purpose
- Credential misassignment — A credential is associated with another owner, application, service, environment, or tenant
- Stale credential access — An expired or revoked credential continues to authorize protected API access
- Rotation abuse — Repeated or concurrent rotation creates unnecessary active credentials or contradictory lifecycle states
- Compromised credential exposure — A known compromised credential remains active while normal lifecycle processing is pending
- Lifecycle-state manipulation — An actor changes credential state or ownership without the required authorization
- Audit-evidence exposure — Credential secrets, privileged lifecycle data, or sensitive audit information reaches unsafe logs or tools

Protect actor identity, owner and tenant scope, credential identifiers, permission scope, lifecycle state, privileged tools, secrets, and audit records. Deny uncertain identity, ownership, scope, or authority.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# Product and Business Guide

## Boundary
Starts when an authorized person or service requests creation, rotation, or revocation of an API credential. Ends when the requested lifecycle action reaches a verified state: the credential is activated, denied, rotated with the previous credential invalidated, revoked, expired, or remains explicitly incomplete with evidence and recovery work recorded.

## People and systems
- Credential owner or authorized service operator
- Platform administrator or security operator
- Credential management service
- Application or service that uses the credential
- Protected API or API gateway
- Audit and security monitoring systems
- Notification or lifecycle-management systems where applicable

## Things created or changed
- API credential and credential identifier
- Credential owner, assigned application or service, and permission scope
- Credential lifecycle state, creation time, expiry time, and rotation history
- Credential activation, rotation, and revocation records
- Audit record for lifecycle actions and their outcomes
- Recovery or reconciliation record for incomplete lifecycle operations
- Expiry or lifecycle notification state where applicable

## Stages
- Request: requested → authorization pending → approved, denied, or cancelled
- Provisioning: generation pending → generated → activation pending → active or failed
- Active credential: active → nearing expiry → expired, rotating, or revoked
- Rotation: requested → replacement provisioning → replacement active → old credential invalidated → completed, or partial/incomplete
- Revocation: requested → authorized → revoked, or failed/incomplete
- Recovery: inconsistent or incomplete → reconciliation pending → verified final state

## Product decisions
- Who may create, rotate, or revoke a credential and what authorization is required
- Which applications, services, environments, and permission scopes a credential may be assigned to
- Whether credentials have mandatory expiry periods and when expiry warnings begin
- Whether old and new credentials may temporarily overlap during rotation
- When the previous credential must become invalid after successful rotation
- Whether emergency revocation has a separate authorization or execution path
- How compromised credentials are identified, contained, and invalidated
- How duplicate requests and retries are identified and handled
- What lifecycle evidence must be recorded for creation, rotation, expiry, and revocation
- How incomplete or inconsistent lifecycle operations are detected and recovered
- What happens when credential-generation or activation dependencies fail
- Which lifecycle states are authoritative when multiple systems disagree

## Happy paths
- An authorized owner creates a credential with an approved scope, assigns it to the intended service, and activates it successfully
- An authorized rotation creates and activates a replacement credential before the previous credential is invalidated according to the defined rotation policy
- An authorized revocation invalidates the credential and records the completed lifecycle action

## Negative paths
- The requester lacks permission to create, rotate, or revoke the credential
- The requested permission scope is outside the requester's allowed policy
- The credential is assigned to an unauthorized application or service
- An expired or revoked credential attempts to access the protected API
- Credential generation or activation fails before the lifecycle operation completes

## Edge cases
- A client retries a creation request after losing the original response
- Two rotation requests target the same credential concurrently
- The replacement credential is generated but activation or state update fails
- Old and new credentials overlap longer than the defined migration window
- A credential is compromised while a normal rotation is already in progress
- Revocation succeeds but the audit record cannot be written
- Different lifecycle components disagree about the credential's current state

## Acceptance criteria
1. Only an authorized actor or service may create, rotate, or revoke a credential
2. Credential ownership, assignment, scope, and lifecycle state must remain consistently bound
3. A credential must not become usable before required authorization and activation checks complete
4. A credential must not receive permissions beyond the approved scope
5. Expired or revoked credentials must not authorize protected API access
6. A completed rotation must leave the previous credential invalidated according to the defined policy
7. Temporary credential overlap must have a defined purpose, boundary, and termination condition
8. Repeated or concurrent lifecycle requests must not create unintended duplicate or contradictory credential states
9. Partial lifecycle operations must remain identifiable and recoverable rather than being reported as completed
10. Lifecycle actions and recovery outcomes must remain traceable through protected audit evidence

## Business risks
| Risk | Business consequence |
|---|---|
| Unauthorized credential access | Weak authorization allows an actor to obtain or control credentials they should not manage |
| Excessive credential scope | A credential grants access beyond the intended application or business purpose |
| Stale credential access | Expired or revoked credentials continue to access protected APIs |
| Failed rotation | A replacement credential is unusable or the previous credential is invalidated prematurely |
| Credential duplication | Retries or concurrent operations create unnecessary active credentials |
| Compromised credential exposure | A known compromised credential remains active longer than necessary |
| Inconsistent lifecycle state | Different systems disagree about whether a credential is active, revoked, or replaced |
| Missing audit evidence | Lifecycle changes cannot be reliably traced during security or operational investigation |
| Recovery failure | An incomplete operation leaves the credential in an unknown or contradictory state |
| Credential misassignment | A credential is associated with the wrong application, service, owner, or environment |
Loading

Back | FazBrowse Home | New Git URL