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 23 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

AAuth defines expires_at as an OPTIONAL member of the approved mission blob: every Person Server (PS) decision path MUST compare the current time to it and treat a mission past it as terminated, and no token carrying mission_s256 may outlive it [I-D.draft-hardt-oauth-aauth-protocol]. This document profiles the member with the deltas in Section 3 and Section 4.¶

An AAuth mission is approved once and then relied on for as long as it stays active. Absent an expiry, an approval remains usable indefinitely through a stream of fresh short-lived tokens. 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.¶

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

AAuth defines expires_at as an OPTIONAL member of the approved mission blob [I-D.draft-hardt-oauth-aauth-protocol]. This profile adds one requirement of its own: under this profile, expires_at MUST be an RFC 3339 date-time [RFC3339], the internet profile of the ISO 8601 form AAuth's own text uses, 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, as AAuth specifies for every blob member. 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.¶

4. Enforcement

AAuth requires every PS decision path to compare the current time to expires_at and to treat a mission past it as terminated, and it caps every token carrying mission_s256 (person, resource, and auth) to that deadline [I-D.draft-hardt-oauth-aauth-protocol]. This profile adds only a promptness requirement: the PS SHOULD terminate at the deadline itself, rather than waiting for the next request under the reference, so that status and logging reflect the transition without delay.¶

5. 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 decoded blob bytes exactly as AAuth requires.¶

Support is discovered from the approved blob itself: a deployment that requires a lifetime bound checks the approved blob and treats the member's absence according to its policy. A proposal is not a guarantee that the approved blob will carry the bound.¶

6. Relationship to Other Specifications

The Mission Context Binding for AAuth [I-D.draft-mcguinness-mission-aauth] requires AAuth's native expires_at member and approves no mission without it. Base AAuth deployments get enforcement regardless of that binding: it is the base protocol's.¶

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

7. Conformance

An AAuth Person Server conforms to this profile when it:¶

1. requires expires_at, once present in the approved mission blob, to be an RFC 3339 date-time naming an instant later than approved_at (Section 3); and¶

2. documents its clock synchronization, comparison precision, and tolerated clock skew (Section 8).¶

Prompt termination at the deadline itself, rather than at the next request under the reference, remains a SHOULD (Section 4). Support for expires_at remains OPTIONAL, following the approved blob member it profiles.¶

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

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

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