Task-Context HTTP Field for Task Context Propagation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [RFC6648]. Private deployment aliases are outside the scope of this registration.¶

2. 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 [RFC2119] [RFC8174] 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.¶

3. 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 = 1*( ALPHA / DIGIT / "-" / "_" )

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.¶

4. 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.¶

5. 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".¶

6. 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.¶

7. Examples

{
  "mode": "task-based",
  "workflow_type": "UpdateServiceConfigWorkflow",
  "requestor": "alice@atlassian.com",
  "approver": "bob@atlassian.com"
}

POST /v1/objects HTTP/1.1
Host: config-registry.example.net
Authorization: Bearer <service-token>
Task-Context: eyJhcHByb3ZlciI6ImJvYkBhdGxhc3NpYW4uY29tIiwibW9kZSI6InRhc2stYmFzZWQiLCJyZXF1ZXN0b3IiOiJhbGljZUBhdGxhc3NpYW4uY29tIiwid29ya2Zsb3dfdHlwZSI6IlVwZGF0ZVNlcnZpY2VDb25maWdXb3JrZmxvdyJ9
Content-Type: application/yaml

...

{
  "mode": "role-based",
  "workflow_type": "ReadOnlyInventoryWorkflow",
  "ats_role": "amp-service-config-reader"
}

GET /v1/inventory HTTP/1.1
Host: inventory.example.net
Authorization: Bearer <service-token>
Task-Context: eyJhdHNfcm9sZSI6ImFtcC1zZXJ2aWNlLWNvbmZpZy1yZWFkZXIiLCJtb2RlIjoicm9sZS1iYXNlZCIsIndvcmtmbG93X3R5cGUiOiJSZWFkT25seUludmVudG9yeVdvcmtmbG93In0

8. 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.¶

9. 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.¶

10. 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.¶

11. 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.¶

Author's Address