WEB / WEB-20.S03
Service identity and asynchronous context propagation
Carry service identity, user delegation and correlation context separately.
1. Core · Mechanism
Read every scenario without motion
Read allowed
- Job context ready
The API has copied a fixed approved field projection into a new job object; its trace alias is not identity proof.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Queue waiting; no delivery
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached queue
The queue records completed arrival of the own job; a receipt does not state the worker’s current permission result.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Owned job received; worker delivery pending
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Worker job ready
Local queue scheduling prepares the same approved job for worker delivery; this step is not a network transfer.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached worker
The context arrives with the completed job at the worker; workload/provenance verification is a declared model input.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Job received; current recipient/purpose/time pending
- Public note store
- note-A unchanged; no read
- Current gate allow
The worker accepted its audience/purpose/time/action/object gates; only now is a store read prepared.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Current workload/context/resource allow; read ready
- Public note store
- note-A unchanged; no read
- Read reached store
The store sees completed arrival of the approved public-note read; its local read-only projection remains pending.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Current workload/context/resource allow; read ready
- Public note store
- Approved note-A read received; title pending
- Title prepared
The store prepares the Tea & Bread title projection with a local read-only operation; mutation remains false.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Current workload/context/resource allow; read ready
- Public note store
- Tea & Bread title body ready; mutation=false
- Worker received body
The body reaches the worker at completed arrival; API/browser return, queue ACK and cloud IAM enforcement are not modeled.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Received title=Tea & Bread; read-only success
- Public note store
- Tea & Bread title body ready; mutation=false
Purpose mismatch
- Job context ready
The API has copied a fixed approved field projection into a new job object; its trace alias is not identity proof.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Queue waiting; no delivery
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached queue
The queue records completed arrival of the own job; a receipt does not state the worker’s current permission result.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Owned job received; worker delivery pending
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Worker job ready
Local queue scheduling prepares the same approved job for worker delivery; this step is not a network transfer.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached worker
The context arrives with the completed job at the worker; workload/provenance verification is a declared model input.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Job received; current recipient/purpose/time pending
- Public note store
- note-A unchanged; no read
- Context evaluated
The worker separately examines current recipient, purpose and lifetime; missing context is distinct from a known denial.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Current gate denied
- Public note store
- note-A unchanged; no read
- Read stopped
Because the required context gate was not accepted, no message is delivered to the store and no title body is created.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Resource delivery=0; protected title body absent
- Public note store
- note-A unchanged; no read
- Diagnostic separated
The local diagnostic separates missing context from purpose/time denial; a continued trace creates no permission.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Known purpose/time denial; mutation=false
- Public note store
- note-A unchanged; no read
Context missing
- Job context ready
The API has copied a fixed approved field projection into a new job object; its trace alias is not identity proof.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Queue waiting; no delivery
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached queue
The queue records completed arrival of the own job; a receipt does not state the worker’s current permission result.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Owned job received; worker delivery pending
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Worker job ready
Local queue scheduling prepares the same approved job for worker delivery; this step is not a network transfer.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached worker
The context arrives with the completed job at the worker; workload/provenance verification is a declared model input.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Job received; current recipient/purpose/time pending
- Public note store
- note-A unchanged; no read
- Context evaluated
The worker separately examines current recipient, purpose and lifetime; missing context is distinct from a known denial.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Context evidence unknown
- Public note store
- note-A unchanged; no read
- Read stopped
Because the required context gate was not accepted, no message is delivered to the store and no title body is created.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Resource delivery=0; protected title body absent
- Public note store
- note-A unchanged; no read
- Diagnostic separated
The local diagnostic separates missing context from purpose/time denial; a continued trace creates no permission.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Unknown context; safe deny; mutation=false
- Public note store
- note-A unchanged; no read
Context expired
- Job context ready
The API has copied a fixed approved field projection into a new job object; its trace alias is not identity proof.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Queue waiting; no delivery
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached queue
The queue records completed arrival of the own job; a receipt does not state the worker’s current permission result.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Owned job received; worker delivery pending
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Worker job ready
Local queue scheduling prepares the same approved job for worker delivery; this step is not a network transfer.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Worker waiting; protected body absent
- Public note store
- note-A unchanged; no read
- Job reached worker
The context arrives with the completed job at the worker; workload/provenance verification is a declared model input.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Job received; current recipient/purpose/time pending
- Public note store
- note-A unchanged; no read
- Context evaluated
The worker separately examines current recipient, purpose and lifetime; missing context is distinct from a known denial.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Current gate denied
- Public note store
- note-A unchanged; no read
- Read stopped
Because the required context gate was not accepted, no message is delivered to the store and no title body is created.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Resource delivery=0; protected title body absent
- Public note store
- note-A unchanged; no read
- Diagnostic separated
The local diagnostic separates missing context from purpose/time denial; a continued trace creates no permission.
- Notes API
- Approved field copy; own job ready
- Owned queue
- Approved copied job ready for worker
- Notes worker
- Known purpose/time denial; mutation=false
- Public note store
- note-A unchanged; no read
ACTORS · STATE · DATA FLOW
A workload and an end user are different actors
A service’s identity is different from the actions it may perform for an end user. Accepting Notes API as a workload at the Queue does not permit it to read every tenant’s data for Duru. Service connection identity is verified against appropriate trust roots/issuers and recipient profiles; user delegation is separately bound to subject, tenant, purpose, audience, action and object. SPIFFE defines workload identity and the SVID used to prove it; permission for a particular SPIFFE ID to read notes remains application policy. This lesson contains no credential or SVID bytes. WorkloadVerifiedDeclared is an independent fixture input, not a claimed result of actual TLS or token verification. Recognizing the sender, trusting its user assertion and permitting the resource remain three distinct questions.
Queue delay changes how context must be evaluated
An asynchronous job may be admitted when enqueued, yet execute later under a different clock value or policy revision. Its context must therefore travel with trusted provenance, and the worker must evaluate audience, purpose, time and action for its own operation. The artifact binds public-note-read to the notes-worker audience and note-A object. At validUntil=200, now=200 is invalid; this equality rule belongs to the selected profile. A different purpose with the correct user and tenant still cannot send a read to the store. Missing context is recorded as permissionUnknown and leads to a safe deny. A queue receipt or ACK is not business success; it records arrival. Retries and idempotency grant no permission either: controlling repeated processing is a different problem from validating actor and purpose.
Correlation context is not identity
Trace context correlates the same work across components. W3C traceparent and tracestate fields serve correlation; sensitive user claims do not belong in them. The artifact uses trace-A only as a readable teaching alias, not actual traceparent syntax. A matching alias proves neither workload identity, subject nor permission. Authentication and tracing contexts need separate fields, provenance and retention rules. A local copy projects only approved job fields into a new object; retaining the original request object by reference can mix another job’s state. Runtime tools such as AsyncLocalStorage help retain context through asynchronous continuations within one process. They do not create an identity assertion across a network or queue boundary. A recipient must perform its own validation before considering deserialized context trustworthy.
Serverless execution reuse and least privilege
Serverless does not mean that each invocation receives a new process. An execution environment may be reused, so reusable SDK clients or static resources must be separated from request-specific actor and context state. AWS Lambda’s function-code guidance recommends avoiding stored user data and security-sensitive event state across invocations. The local two-context check keeps Duru/job-A and Ece/job-B in separate async stores and copies; it is not an actual Lambda isolation test. A workload’s platform permissions also require a minimal service role; user delegation does not replace that role. Even a queue consumer with a readNotes role must not produce note-A’s body when current context is invalid. Deployment platforms, token exchange, actual clock synchronization and revocation propagation remain external dependencies without assumed evidence.
2. Red · Trust & Impact
Read every scenario without motion
Purpose denied
- The workload predicate is positive
The wrong-purpose row supplies workloadVerifiedDeclared=true and assertionIssuerTrustedDeclared=true. Neither grants the job resource-action permission.
- Workload / job
- workloadVerifiedDeclared=true
- Worker decision
- assertionIssuerTrustedDeclared=true
- Trust boundary
- Resource decision not inspected yet
- Context exists with a different purpose
ContextPresent=true, subject=Duru and tenant=tenant-A are supplied, but purpose=note-export does not match selected public-note-read.
- Workload / job
- subject=Duru / tenant=tenant-A
- Worker decision
- purpose=note-export
- Trust boundary
- Expected purpose public-note-read
- Resource allowed is insufficient alone
ResourceAllowedDeclared=true does not repair the mismatched purpose. Current gates are evaluated together.
- Workload / job
- resourceAllowedDeclared=true
- Worker decision
- purpose mismatch
- Trust boundary
- Purpose is separately required
- The worker did not admit the job
ExpectedAllowed=false, expectedBody=null and expectedResourceDelivery=false retain purpose denial despite the trusted workload predicate.
- Workload / job
- expectedAllowed=false
- Worker decision
- expectedBody=null
- Trust boundary
- No store-body delivery
- Do not expand service roles
Notes-api enqueue and queue delivery roles do not bypass the worker’s current read gate. A hop’s role is not the next hop’s resource decision.
- Workload / job
- notes-api: enqueue
- Worker decision
- notes-worker: current context gate
- Trust boundary
- Each boundary owns its decision
- Report purpose for the same job
This branch stops at purpose rather than workload verification. Another job’s correct purpose cannot complete this record.
- Workload / job
- workload declared=true
- Worker decision
- purpose=note-export / allowed=false
- Trust boundary
- Known purpose denial
Time boundary
- Context identity and scope are present
The expired row supplies Duru, tenant-A, public-note-read and notes-worker. Matching fields do not replace the time gate.
- Workload / job
- subject=Duru / audience=notes-worker
- Worker decision
- purpose=public-note-read
- Trust boundary
- Time gate not inspected yet
- Now equals the boundary
Now=200 and validUntil=200 fail the example’s now < validUntil condition; equality is not admission.
- Workload / job
- now=200
- Worker decision
- validUntil=200
- Trust boundary
- 200 < 200 is false
- Other positive fields do not extend validity
ResourceAllowedDeclared=true and policyRevision=notes-policy-3 do not change validUntil.
- Workload / job
- resourceAllowedDeclared=true
- Worker decision
- now=validUntil
- Trust boundary
- Current-time condition is separate
- The expired job receives no body
ExpectedAllowed=false and expectedResourceDelivery=false prevent producing successful title delivery from store to worker for this row.
- Workload / job
- expectedAllowed=false
- Worker decision
- expectedResourceDelivery=false
- Trust boundary
- expectedBody=null
- Enqueue time is not current admission
A job may wait in a queue. Earlier-valid context must still satisfy the time condition when the worker receives it.
- Workload / job
- now=200 / validUntil=200
- Worker decision
- current time gate failed
- Trust boundary
- A current decision is required
- Expiry and revocation differ
The record demonstrates a selected expiry comparison. ActualRevocation=false prevents extending it to real identity-service revocation enforcement.
- Workload / job
- time predicate=false
- Worker decision
- actualRevocation=false
- Trust boundary
- Only the selected time gate
ASSUMPTION · BOUNDARY · CONTROL
Assuming an internal sender establishes user context
The assumption to inspect gives an internal connection or familiar service name authority over every user assertion. Such a failure requires loss of the sender’s assertion privileges or the recipient’s validation policy. Workload authentication concerns the sender; an assertion that it acts for Duru on public-note-read may need a different issuer and delegation trust decision. In the wrong-purpose branch the workload is recognized and user context is present, but purpose does not match the notes-worker profile. This is no token alteration or bypass attempt: a supplied policy row safely closes for the wrong purpose. Internal hostnames, queue names, trace aliases and successful receipts do not open that gate. Without inspection of actual connection identity, there is no claim of attack success; workload verification remains an explicit declared dependency.
Distinguish delayed context from missing evidence
Context admitted into a queue may no longer be acceptable when the worker executes. The impact arises if execution uses an old admission result instead of current time or policy gates. The expired row contains a known time mismatch; the context-missing row contains insufficient evidence of actor delegation. Both safely yield resource delivery=0 and body=null, while keeping different diagnostic meanings. A continued trace does not imply continued identity. Sharing the same mutable object across jobs is also a runtime-state problem; this lesson observes positive isolation only for approved copied contexts. This perspective asks which supplied conditions are necessary. It performs no privilege operation or credential use on an actual queue. The finite model supplies no evidence of real distributed replay or retry behavior.
3. Blue · Secure development & defense
Read every scenario without motion
Context missing
- The workload input is still positive
The local Node AsyncLocalStorage check measures separate jobId and subject values in two async scopes. Worker-policy rows are produced from purpose, audience and validUntil inputs; they are not queue logs, signature verification or IAM evidence. The context-missing row still supplies workloadVerifiedDeclared=true. This service-level input does not establish user-context presence.
- Job observation
- workloadVerifiedDeclared=true
- Context / store outcome
- assertionIssuerTrustedDeclared=true
- Evidence boundary
- User context examined separately
- Subject and tenant are missing
ContextPresent=false, subject=null and tenant=null remain missing instead of being filled from the normal row’s Duru and tenant-A.
- Job observation
- contextPresent=false
- Context / store outcome
- subject=null / tenant=null
- Evidence boundary
- User permission knowledge UNKNOWN
- Resource true does not create context
ResourceAllowedDeclared=true does not repair missing subject/tenant binding; the row explicitly records permissionEvidence=unknown.
- Job observation
- resourceAllowedDeclared=true
- Context / store outcome
- permissionEvidence=unknown
- Evidence boundary
- Context binding is required
- The model stops fail closed
ExpectedAllowed=false and expectedBody=null fail closed without converting unknown user context into known denial for a specific user.
- Job observation
- expectedAllowed=false
- Context / store outcome
- expectedBody=null
- Evidence boundary
- Missing context is the stopping reason
- Trace is not identity
Correlation.traceAlias=trace-A has identityEvidence=false and permissionEvidence=false. A correlation alias establishes neither subject identity nor permission.
- Job observation
- traceAlias=trace-A
- Context / store outcome
- identityEvidence=false / permissionEvidence=false
- Evidence boundary
- Correlation retains its own scope
- Name the required context
This job needs verified subject/tenant binding and current gate evidence. Queue delivery or a trace alias cannot supply the missing fields.
- Job observation
- subject / tenant evidence missing
- Context / store outcome
- permissionEvidence=unknown
- Evidence boundary
- Current context is needed for the same job
Worker receipt
- The normal row scope is specified
The local Node AsyncLocalStorage check measures separate jobId and subject values in two async scopes. Worker-policy rows are produced from purpose, audience and validUntil inputs; they are not queue logs, signature verification or IAM evidence. The normal row identifies Duru, tenant-A, notes.read and note-A. The examined result concerns this job’s public-title read.
- Job observation
- subject=Duru / tenant=tenant-A
- Context / store outcome
- action=notes.read / noteId=note-A
- Evidence boundary
- One job’s scope
- The current gate admitted it
Purpose and audience match with now=150 and validUntil=200. The row has expectedAllowed=true without borrowing another job’s decision.
- Job observation
- now=150 < validUntil=200
- Context / store outcome
- expectedAllowed=true
- Evidence boundary
- Selected gate admission
- The body is a worker receipt outcome
ExpectedResourceDelivery=true and expectedBody.title=Tea & Bread establish the stated store-to-worker body outcome.
- Job observation
- expectedBody.title=Tea & Bread
- Context / store outcome
- deliveryBoundary=store-to-worker
- Evidence boundary
- Worker receipt
- Read-only delivery is not mutation
ExpectedMutation=false separates title reading from note writes or permission for another action.
- Job observation
- expectedResourceDelivery=true
- Context / store outcome
- expectedMutation=false
- Evidence boundary
- Read and write differ
- API and browser return are absent
DeliveryBoundary explicitly excludes API/browser return. Worker receipt does not prove Duru saw the result in a browser.
- Job observation
- store-to-worker body observed
- Context / store outcome
- no API/browser return
- Evidence boundary
- Browser receipt UNKNOWN
- Report the completed hop accurately
The known result is read-only store-body delivery to the worker after the current gate. Correlation does not add downstream receipt or retry guarantees.
- Job observation
- worker body=Tea & Bread
- Context / store outcome
- actualRetryGuarantee=false
- Evidence boundary
- Delivery scope ends at the worker
IMPLEMENTATION · SECURITY CONTROL · VERIFICATION
Every recipient owns its gate
The local Node AsyncLocalStorage check measures separate jobId and subject values in two async scopes. Worker-policy rows are produced from purpose, audience and validUntil inputs; they are not queue logs, signature verification or IAM evidence. Separate service roles for Notes API, Queue and Worker: enqueue, dequeue and notes.read are not the same permission. User context travels as a minimal approved field projection; downstream recipients validate their own audience, purpose, lifetime and resource scope. Even a valid signature must be bound to an issuer authorized to assert that context; no signature is executed here. Where another recipient needs context, design a delegation or exchange profile appropriate to its purpose and audience rather than blindly copying ID tokens or user bearer material. The success scene brings the store’s read-only title projection to the worker; it claims no delivery to the API or final browser. Separate telemetry outcomes for service verification, user delegation and resource permission make failure causes visible.
Isolation and the consequences of failure
The local runtime check gives two Promise continuations separate AsyncLocalStorage.run scopes and observes each job ID and subject. That is actual context behavior within Node, not another process’s trust decision. Changing a copied job’s title or trace field must not alter its original request or a second job. Policy fixtures require no message to reach the store, no mutation and no protected title body for wrong-purpose, expiry and missing context. Unknown context is not merged into known-deny evidence. Production designs need separate integrations for retries, revocation, key rotation and current policy revision; an idempotency key is not a permission document. With serverless execution reuse, request state remains per invocation. The deterministic scene is not presented as a queue ACK, actual token validation or cloud IAM enforcement test.
NOW APPLY IT TO THE CASE
Do trusted workload and correlation replace current user permission?
Duru requests the public note-A title. Notes-api, queue and notes-worker have distinct roles; the worker reevaluates purpose, audience, time and resource context when receiving the job.
Read accepted, delivery and committed-effect records at their respective owners. Do not rename unknown caller outcome as business rollback.
Open the related case file ↗READ THE EXAMPLE TOGETHER
Atlas Notes — decision ledger
Select a field and examine what it supports and where the evidence ends.
Read the raw artifact and field explanations
{
"profile": {
"actor": "Duru",
"tenant": "tenant-A",
"action": "notes.read",
"noteId": "note-A",
"title": "Tea & Bread",
"purpose": "public-note-read",
"audience": "notes-worker",
"now": 150,
"validUntil": 200,
"policyRevision": "notes-policy-3",
"apiWorkload": "notes-api",
"workerWorkload": "notes-worker",
"actualNetwork": false,
"actualIdentityVerification": false
},
"rows": [
{
"case": "normal",
"workloadVerifiedDeclared": true,
"assertionIssuerTrustedDeclared": true,
"contextPresent": true,
"subject": "Duru",
"tenant": "tenant-A",
"purpose": "public-note-read",
"audience": "notes-worker",
"action": "notes.read",
"noteId": "note-A",
"now": 150,
"validUntil": 200,
"policyRevision": "notes-policy-3",
"resourceAllowedDeclared": true,
"expectedAllowed": true,
"expectedBody": {
"title": "Tea & Bread"
},
"expectedResourceDelivery": true,
"expectedMutation": false,
"permissionEvidence": "declared-known"
},
{
"case": "wrong-purpose",
"workloadVerifiedDeclared": true,
"assertionIssuerTrustedDeclared": true,
"contextPresent": true,
"subject": "Duru",
"tenant": "tenant-A",
"purpose": "note-export",
"audience": "notes-worker",
"action": "notes.read",
"noteId": "note-A",
"now": 150,
"validUntil": 200,
"policyRevision": "notes-policy-3",
"resourceAllowedDeclared": true,
"expectedAllowed": false,
"expectedBody": null,
"expectedResourceDelivery": false,
"expectedMutation": false,
"permissionEvidence": "declared-known"
},
{
"case": "context-missing",
"workloadVerifiedDeclared": true,
"assertionIssuerTrustedDeclared": true,
"contextPresent": false,
"subject": null,
"tenant": null,
"purpose": "public-note-read",
"audience": "notes-worker",
"action": "notes.read",
"noteId": "note-A",
"now": 150,
"validUntil": 200,
"policyRevision": "notes-policy-3",
"resourceAllowedDeclared": true,
"expectedAllowed": false,
"expectedBody": null,
"expectedResourceDelivery": false,
"expectedMutation": false,
"permissionEvidence": "unknown"
},
{
"case": "expired",
"workloadVerifiedDeclared": true,
"assertionIssuerTrustedDeclared": true,
"contextPresent": true,
"subject": "Duru",
"tenant": "tenant-A",
"purpose": "public-note-read",
"audience": "notes-worker",
"action": "notes.read",
"noteId": "note-A",
"now": 200,
"validUntil": 200,
"policyRevision": "notes-policy-3",
"resourceAllowedDeclared": true,
"expectedAllowed": false,
"expectedBody": null,
"expectedResourceDelivery": false,
"expectedMutation": false,
"permissionEvidence": "declared-known"
}
],
"serviceRoles": [
{
"service": "notes-api",
"permission": "enqueue public-note-read"
},
{
"service": "owned-queue",
"permission": "deliver approved jobs"
},
{
"service": "notes-worker",
"permission": "read own public note after current context gate"
}
],
"copiedContextFields": [
"jobId",
"subject",
"tenant",
"purpose",
"audience",
"action",
"noteId",
"validUntil",
"policyRevision"
],
"correlation": {
"traceAlias": "trace-A",
"actualTraceparent": false,
"identityEvidence": false,
"permissionEvidence": false
},
"deliveryBoundary": "Store-to-worker body only; no API/browser return",
"boundaries": {
"actualQueue": false,
"actualToken": false,
"actualSPIFFE": false,
"actualCloudIAM": false,
"actualRevocation": false,
"actualRetryGuarantee": false
}
}- rows
- Declared workload/provenance inputs and current purpose/audience/time/resource gates.
- copiedContextFields
- Approved context projection only; no credential material is carried.
- correlation
- A trace alias is neither identity nor permission evidence.
- deliveryBoundary
- Success is only a read-only body from store to worker.
Owned synthetic queue ledger and local copied-context observations; no actual identity service, queue, token, SPIFFE or cloud deployment.
Two reality checks
A recognized service has all the user’s permissions.
Workload identity, user delegation and resource permission are separate gates.
A matching trace ID proves identity.
Tracing serves correlation; trusted identity context needs separate validation.
YOUR TURN
Work through this story.
Predict the outcome, find the evidence boundary, and explain it in your own words.
The worker workload is verified, but contextPresent=false and subject=null. Is the note body released?
- Yes. A trusted service can act without limits for any subject.
- No. Permission evidence is unknown and delivery is withheld.
Read the explained answer
No. Permission evidence is unknown and delivery is withheld. — A verified workload does not invent missing user/tenant context. expectedBody stays null.
The job was enqueued and has a traceAlias. At now=validUntil=200, may the worker rely on the old permission?
Selected lesson artifact fields; teaching example
- rows[3].now
- 200
- rows[3].validUntil
- 200
- rows[3].expectedAllowed
- false
- correlation
- {"traceAlias":"trace-A","actualTraceparent":false,"identityEvidence":false,"permissionEvidence":false}
- No. Expired context is rejected; trace is not permission.
- Yes. A trace ID or job ID is a permanent authorization credential.
Read the explained answer
No. Expired context is rejected; trace is not permission. — The current-time gate closes at equality. Correlation has identityEvidence=false and permissionEvidence=false; a trace alias does not replace those checks.
Copied context contains purpose, audience, noteId, validUntil and policyRevision. Why is copying it neither verified delegation nor browser delivery?
Read the explained answer
The worker checks issuer/workload provenance, subject/tenant binding, purpose/audience/action and current permission. Copied fields alone establish no authority. This scene shows body delivery from store to worker, with no API/browser return. No actual queue, token, SPIFFE, IAM or revocation runs. An async context carrier is not an identity verifier.
□ I did not replace trusted provenance with copied context.
□ I separated worker receipt from API/browser delivery.
Open the application console · request / response / browser
Also open request, URL, cookie and DOM examples
Sources and scope
- OWASP Identity Propagation Patterns Cheat SheetValidation at Each Boundary · Simple Service-Level Identity Forwarding; Token Exchange; Privacy and Recommendation
- SPIFFE ConceptsWorkload; SPIFFE ID; Trust Domain; SVID; Trust Bundle
- W3C Trace Context§6 Privacy Considerations: correlation-only fields; §6.1/6.2 · §7 Security Considerations
- AWS Lambda Best practicesFunction code: execution environment reuse, security-sensitive state isolation and idempotency
- Node.js v24.13.0 Asynchronous context trackingClass AsyncLocalStorage; run(store, callback); getStore(); usage with async/await