Task-Context HTTP Field for Task Context Propagation
draft-zhu-httpbis-task-context-00

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 <service-token>
   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 <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.

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [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,
              <https://www.rfc-editor.org/info/rfc6648>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC9110]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
              Semantics", RFC 9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

12.2.  Informative References

   [Trace-Context]
              Consortium, W. W. W., "Trace Context", November 2021,
              <https://www.w3.org/TR/trace-context/>.

Author's Address

   Larry Zhu
   Atlassian
   Email: lzhu3@atlassian.com

Zhu                      Expires 7 December 2026                [Page 8]