Atlassian

lzhu3@atlassian.com

Web and Internet Transport HTTP header field task context workflow authorization This document defines the Task-Context HTTP field for propagating task execution context from an authorized workflow worker to downstream HTTP services. The field carries a compact, base64url-encoded JSON object that identifies the authorization mode, workflow type, and either task-based requestor and approver context or role-based execution context. The field is not a bearer credential and does not replace HTTP client authentication, service-to-service authorization, or resource-local policy checks. Its purpose is to let downstream services correlate requests with workflow task context and make service-local authorization and audit decisions using that context.

Introduction Modern automation systems often authorize a high-level workflow before any downstream API call occurs. The workflow engine can evaluate the full task intent, manifest, requestor, approver, policy evidence, and blast radius at the workflow boundary. Later, a workflow worker calls downstream HTTP APIs using its own service identity. Without a standard way to carry task context, those downstream services see an authenticated service call but cannot easily correlate that call to the human request, approval, or role that caused the workflow step. The Task-Context field provides a compact HTTP field for this correlation. It is designed for task context propagation, audit, and policy input. It is not designed as an authentication token, delegation token, or proof of approval by itself. The field name is intended for registration in the IANA Hypertext Transfer Protocol Field Name Registry. Registration avoids collisions with independently defined HTTP fields and avoids the historical "X-" prefix convention deprecated by . Private deployment aliases are outside the scope of this registration.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Task:

A unit of authorized work initiated through a workflow, job, or automation system.

Task context:

The metadata that links an HTTP request to the task that caused it.

Workflow worker:

The authenticated service component that executes workflow steps and calls downstream HTTP APIs.

Task-based authorization:

Authorization in which a workflow is approved based on a concrete requestor, approver, manifest, input, and policy evidence.

Role-based execution:

Execution in which the worker acts under an authorized role rather than a specific requestor/approver task approval.

The Task-Context HTTP Field The Task-Context field value is a base64url-encoded UTF-8 JSON object without padding. The decoded JSON object is called the task context object.

Task-Context field ABNF

Senders MUST NOT include more than one Task-Context field in a request. Recipients that receive multiple Task-Context fields for one request MUST reject the request or ignore all task context for that request. Recipients SHOULD impose an implementation limit on the field size. This document RECOMMENDS a maximum decoded JSON size of 4096 octets unless a deployment profile specifies a smaller limit.

Task Context Object The decoded task context object is a JSON object. Unknown members MUST be ignored unless a local policy requires strict validation. Senders MUST omit members with no value.

mode (required):

Either "task-based" or "role-based".

workflow_type (required):

The workflow or task executor type.

requestor (required when mode is "task-based"):

The principal that requested the task. Deployments MAY use an opaque subject identifier instead of an email address.

approver (optional for "task-based"):

The principal that approved the task when approval was required or obtained. A future revision can define support for multiple approvers.

ats_role (required when mode is "role-based"):

The role asserted by the upstream authorization system for role-based execution.

Sender Requirements

1. A sender MUST authenticate to the downstream HTTP service independently of Task-Context.
2. A workflow worker SHOULD send Task-Context only after the workflow start or task execution request has passed the applicable authorization checks.
3. A sender MUST use base64url encoding without padding over the UTF-8 JSON representation of the task context object.
4. A sender MUST include "mode" and "workflow_type".
5. For task-based authorization, a sender MUST include "requestor" and SHOULD include "approver" when an approval exists.
6. For role-based execution, a sender MUST include "ats_role".

Recipient Requirements

1. A recipient MUST authenticate the HTTP client before using task context.
2. A recipient MUST NOT grant access solely because a Task-Context field is present.
3. A recipient SHOULD validate that the authenticated caller is allowed to present task context for the requested API.
4. A recipient SHOULD log "mode", "workflow_type", and the task-based or role-based fields that are present.
5. A recipient MAY use the task context object as input to local authorization policy, audit, rate limiting, or abuse detection.
6. A recipient that forwards a request as part of the same task SHOULD propagate the original Task-Context unchanged. It MUST NOT modify requestor, approver, role, or workflow values unless it is acting as a new workflow worker for a new task.

Examples

Task-Based Authorization Decoded task context: HTTP request: Task-Context: eyJhcHByb3ZlciI6ImJvYkBhdGxhc3NpYW4uY29tIiwibW9kZSI6InRhc2stYmFzZWQiLCJyZXF1ZXN0b3IiOiJhbGljZUBhdGxhc3NpYW4uY29tIiwid29ya2Zsb3dfdHlwZSI6IlVwZGF0ZVNlcnZpY2VDb25maWdXb3JrZmxvdyJ9 Content-Type: application/yaml ... ]]>

Role-Based Execution Decoded task context: HTTP request: Task-Context: eyJhdHNfcm9sZSI6ImFtcC1zZXJ2aWNlLWNvbmZpZy1yZWFkZXIiLCJtb2RlIjoicm9sZS1iYXNlZCIsIndvcmtmbG93X3R5cGUiOiJSZWFkT25seUludmVudG9yeVdvcmtmbG93In0 ]]>

Relationship to Authentication and Authorization Task-Context is task context, not proof of identity. Deployments MUST continue to use their normal HTTP client authentication mechanism, such as OAuth access tokens, mutual TLS, service mesh identity, or platform-native service identity. Downstream services SHOULD combine the authenticated caller, requested resource, local policy, and task context when making authorization decisions. When a workflow worker calls downstream APIs, the downstream service can verify that the caller is an allowed worker, then use the decoded Task-Context value as local policy and audit input. If stronger integrity is required across an untrusted boundary, deployments SHOULD bind a cryptographic hash of the exact Task-Context field value into an integrity-protected service-authentication envelope or a companion signed assertion rather than relying on the unsigned header value alone.

Security Considerations Any HTTP client can construct a Task-Context value. Recipients MUST authenticate callers and MUST NOT treat the field as a bearer credential. Gateways and edge services SHOULD remove inbound Task-Context fields from untrusted clients unless the client is explicitly allowed to set task context. A copied field value can be replayed. Recipients that use task context for policy SHOULD bind decisions to the authenticated caller, target API, resource, and current policy state. Base64url encoding avoids control characters in the field value. Recipients MUST reject values that are not valid base64url, are not valid UTF-8 JSON after decoding, exceed local size limits, or decode to a non-object JSON value. A downstream service MUST avoid granting the worker broader access than the approved task allows. Task context is one policy input; resource-local authorization remains required. This document does not define a signature format. Deployments that need cryptographic integrity SHOULD sign the task context or carry the equivalent data in an existing signed token, while preserving Task-Context as the correlation field.

Privacy Considerations The task context object can contain personal data, including requestor and approver identifiers. Senders SHOULD minimize these values, prefer stable opaque subject identifiers where possible, and avoid putting sensitive ticket text, comments, or free-form justification in the header. Recipients SHOULD treat logs containing Task-Context as security and audit logs with appropriate retention and access controls.

IANA Considerations This document requests permanent registration of the "Task-Context" HTTP field name in the "Hypertext Transfer Protocol (HTTP) Field Name Registry".

• Field Name: Task-Context
• Status: permanent
• Structured Type: no
• Reference: this document
• Comments: Carries a base64url-encoded JSON task context object.

This registration is the collision-avoidance mechanism for the standards-track field name. Private deployment aliases are not registered by this document.

Normative References Informative References W3C