AAuth Mission Expiry

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 13 February 2027.¶

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

An AAuth mission is approved once and then relied on for as long as it stays active. The base protocol bounds token lifetimes but not the mission itself: absent explicit termination, an approval remains usable indefinitely through a stream of fresh short-lived tokens.¶

This extension gives a mission a lifetime the approver sees and consents to. Because expires_at sits inside the approved mission blob, it is part of what the Person approves, it is covered by the s256 content address, and it cannot be changed in place. Expiry adds no protocol state: a mission that reaches its deadline becomes terminated.¶

The extension changes Person Server behavior only. Agents, Resources, and Access Servers require no changes, and deployments that do not adopt it retain base AAuth behavior.¶

2. Conventions and Terminology

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

This document uses Person, Agent, Person Server (PS), Access Server (AS), Resource, Auth Token, mission, approved mission blob, mission proposal, and the {approver, s256} mission reference as defined by [I-D.draft-hardt-oauth-aauth-protocol].¶

3. The expires_at Member

This specification defines an OPTIONAL expires_at member of the approved mission blob. Its value is an RFC 3339 date-time [RFC3339], the internet profile of the ISO 8601 form AAuth uses for approved_at, and MUST identify an instant later than the blob's approved_at.¶

Because expires_at is in the approved mission blob, it is covered by s256 and cannot be changed in place. Changing an approved expiry requires proposing and approving a new mission, which carries a new s256 and therefore a new mission reference.¶

A mission whose approved blob has no expires_at member has no expiry under this extension.¶

Extending the blob is consistent with its definition: AAuth enumerates members the blob MUST include and members it MAY include and states no rule that closes the set, the blob is the PS's own approval response body, and a conforming Agent stores that body byte-exact whether or not it recognizes a member. The existing capabilities member already places PS-determined, session-specific information inside the committed bytes, and expires_at follows the same pattern. If a future AAuth revision defines expires_at or blob-member extensibility rules, that definition governs and this document will align with it.¶

4. Proposal and Approval

A mission proposal MAY include expires_at. The PS or the Person MAY add or change the value during clarification, before approval. The approved value is the one in the approved mission blob, and the Agent verifies and stores the approved response bytes exactly as AAuth requires.¶

Support is discovered from the approved blob itself: an Agent or deployment that requires a lifetime bound checks the approved blob and treats the member's absence according to its policy. AAuth does not specify how a PS that does not implement this extension handles an unrecognized proposal member, so a proposal is not a guarantee that the approved blob will carry the bound.¶

An Agent that does not implement this extension still preserves the member unmodified, because AAuth requires exact-byte storage of the approved blob. It simply gains no early warning of the deadline.¶

5. Enforcement

At or after expires_at, the PS MUST atomically transition an active mission to terminated before it processes any further request under that mission reference. A missed scheduler callback does not extend authority: every PS decision path MUST compare the current time with expires_at before treating the mission as active. A request under an expired mission is rejected exactly as under any terminated mission, with AAuth's mission_terminated error.¶

The PS SHOULD terminate promptly at the deadline so that status and logging reflect the transition, rather than waiting for the next request under the reference.¶

The PS MUST NOT issue an Auth Token whose exp is later than the mission's expires_at when the PS controls that expiry. In federation, the PS MUST verify that the returned Auth Token's exp is no later than the mission's expires_at; if it is later, absent, or cannot be verified, the PS MUST NOT return or otherwise make the token available to the Agent. The PS SHOULD NOT initiate federation when it already knows the AS cannot meet the bound.¶

6. Relationship to Other Specifications

The Mission Context Binding for AAuth [I-D.draft-mcguinness-mission-aauth] requires this extension and approves no mission without expires_at. Base AAuth deployments can adopt this extension independently of that binding.¶

A PS that also implements AAuth Mission Management [I-D.draft-mcguinness-mission-aauth-management] records the transition with termination reason expired, exposes the approved expiry through the status operation, and serializes automatic expiry with explicit termination as that document specifies.¶

7. Security Considerations

Clock synchronization, comparison precision, and tolerated clock skew MUST be documented by the deployment. An Agent SHOULD NOT schedule work that depends on completing near the deadline.¶

Expiry bounds duration; it does not end a mission early. A compromise discovered before the deadline still requires an explicit termination mechanism.¶

Already-issued Auth Tokens are the residual after expiry. The issuance bound in Section 5 keeps that residual inside the mission's lifetime: no token issued under the mission outlives expires_at.¶

Immutability defeats lifetime extension. An attacker who controls an Agent cannot stretch an approved mission's lifetime; a longer lifetime requires a new proposal and a new approval by the Person.¶

8. Privacy Considerations

expires_at is part of the private mission blob and is not disclosed to Resources or Access Servers. It adds no correlation surface beyond the blob itself.¶

9. IANA Considerations

This document requests no IANA registrations. The AAuth Protocol does not currently establish a registry for approved mission-blob members. If AAuth creates one before publication, this document will request registration of expires_at.¶

Acknowledgments

The AAuth protocol and its extension points are the work of Dick Hardt.¶

References

Author's Address