Network Working Group L. Zhu Internet-Draft Atlassian Intended status: Standards Track 5 June 2026 Expires: 7 December 2026 Task-Context HTTP Field for Task Context Propagation draft-zhu-httpbis-task-context-00 Abstract 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. 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. Zhu Expires 7 December 2026 [Page 1] Internet-Draft Task-Context HTTP Field June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. The Task-Context HTTP Field . . . . . . . . . . . . . . . . . 3 4. Task Context Object . . . . . . . . . . . . . . . . . . . . . 4 5. Sender Requirements . . . . . . . . . . . . . . . . . . . . . 4 6. Recipient Requirements . . . . . . . . . . . . . . . . . . . 4 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Task-Based Authorization . . . . . . . . . . . . . . . . 5 7.2. Role-Based Execution . . . . . . . . . . . . . . . . . . 5 8. Relationship to Authentication and Authorization . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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. Zhu Expires 7 December 2026 [Page 2] Internet-Draft Task-Context HTTP Field June 2026 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 / "-" / "_" ) Figure 1: 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. Zhu Expires 7 December 2026 [Page 3] Internet-Draft Task-Context HTTP Field June 2026 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. Zhu Expires 7 December 2026 [Page 4] Internet-Draft Task-Context HTTP Field June 2026 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 7.1. Task-Based Authorization Decoded task context: { "mode": "task-based", "workflow_type": "UpdateServiceConfigWorkflow", "requestor": "alice@atlassian.com", "approver": "bob@atlassian.com" } HTTP request: POST /v1/objects HTTP/1.1 Host: config-registry.example.net Authorization: Bearer Task-Context: eyJhcHByb3ZlciI6ImJvYkBhdGxhc3NpYW4uY29tIiwibW9kZSI6InRhc2stYmFzZWQiLCJyZXF1ZXN0b3IiOiJhbGljZUBhdGxhc3NpYW4uY29tIiwid29ya2Zsb3dfdHlwZSI6IlVwZGF0ZVNlcnZpY2VDb25maWdXb3JrZmxvdyJ9 Content-Type: application/yaml ... 7.2. Role-Based Execution Decoded task context: Zhu Expires 7 December 2026 [Page 5] Internet-Draft Task-Context HTTP Field June 2026 { "mode": "role-based", "workflow_type": "ReadOnlyInventoryWorkflow", "ats_role": "amp-service-config-reader" } HTTP request: GET /v1/inventory HTTP/1.1 Host: inventory.example.net Authorization: Bearer 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. Zhu Expires 7 December 2026 [Page 6] Internet-Draft Task-Context HTTP Field June 2026 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. 12. References 12.1. Normative References Zhu Expires 7 December 2026 [Page 7] Internet-Draft Task-Context HTTP Field June 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, . [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 8259, December 2017, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", RFC 9110, June 2022, . 12.2. Informative References [Trace-Context] Consortium, W. W. W., "Trace Context", November 2021, . Author's Address Larry Zhu Atlassian Email: lzhu3@atlassian.com Zhu Expires 7 December 2026 [Page 8]