Internet-Draft AEP Basic June 2026
Kavian Expires 29 December 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-kavian-aep-basic-session-credential-00
Published:
Intended Status:
Standards Track
Expires:
Author:
N. Kavian
Jarwin, Inc. (InFlow)

Basic Session Credentials for the Agent Enrollment Protocol

Abstract

This document defines a Basic session-credential extension for the Agent Enrollment Protocol (AEP). The extension lets an AEP Service issue an HTTP Basic credential through the AEP Grant command for deployments that already integrate with Basic authentication middleware.

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 29 December 2026.

Table of Contents

1. Introduction

AEP session credentials allow a Service to issue a stateful credential after an Agent authenticates with a baseline AEP client assertion [AEP-CORE]. This document defines the basic grant type for Services that want to reuse HTTP Basic authentication [RFC7617] while preserving AEP key possession as the issuance root. Extension request and response bodies are JSON objects [RFC8259] carried over HTTP semantics [RFC9110] as defined by AEP.

This extension does not replace baseline AEP authentication. Services that implement this extension MUST continue to accept baseline AEP authentication on authenticated AEP commands.

2. Requirements Language

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.

3. Grant Type

The grant type identifier is:

basic

A Service that supports this extension lists basic in commands.grant_types and lists grant and revoke in commands.supported in its AEP Inspect document.

4. Inspect Configuration

A Service MAY publish configuration under commands.grant_types_config.basic:

{
  "commands": {
    "grant_types": ["basic"],
    "grant_types_config": {
      "basic": {
        "default_lifetime_seconds": "86400",
        "realm": "api.example.com",
        "scopes_supported": ["read", "write"],
        "supports_per_credential_revoke": "true"
      }
    },
    "supported": ["enroll", "grant", "inspect", "revoke", "status"]
  }
}

default_lifetime_seconds is an AEP-owned numeric value and is therefore represented as a JSON string.

realm, when present, identifies the HTTP Basic realm associated with credentials issued by this extension.

scopes_supported, when present, lists Service-defined scope strings an Agent can request.

supports_per_credential_revoke is a string boolean. If absent, the default is "false". A Service that returns credential_id in a Grant response MUST support Revoke with that credential_id. A Service that does not support per-credential Revoke MUST omit credential_id from Grant responses.

5. Grant Request

The Agent invokes AEP Grant using baseline Authorization: AEP <jwt> authentication with op equal to grant.

{
  "grant_type": "basic",
  "label": "legacy-basic-prod",
  "requested_scopes": ["read"]
}

grant_type MUST be basic.

label is OPTIONAL and is an Agent-provided display label. Services MAY ignore it.

requested_scopes is OPTIONAL. A Service MAY grant fewer scopes than requested. Unsupported requested scopes MAY be omitted from the response scopes array. If the Service cannot issue a useful credential for the requested scopes, it MUST return invalid_request.

The Agent does not submit a password. The Service generates the username and password, or generates the password for a Service-owned username, and returns the credential in the Grant response.

6. Grant Response

A successful Grant response is a JSON object:

{
  "credential_id": "bas_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "expires_at": "2026-12-01T00:00:00Z",
  "password": "s3cr3tExample",
  "realm": "api.example.com",
  "scopes": ["read"],
  "username": "aep_agent_abc123"
}

username and password are REQUIRED. Agents MUST treat password as an opaque secret. Services MUST generate values that can be encoded according to RFC 7617 without lossy transformation. Generated passwords MUST contain at least 128 bits of entropy. Generated usernames and passwords MUST NOT contain control characters.

expires_at is REQUIRED and is an RFC 3339 [RFC3339] timestamp for credential expiry.

realm, when present, identifies the associated HTTP Basic realm.

scopes is REQUIRED and contains the granted scope strings. The Service MAY return an empty array when the Basic credential has no scope-limited authorization.

credential_id, when present, is a stable identifier for per-credential Revoke. If present, the Service MUST support Revoke with this value.

The response does not include the base64-encoded Authorization value. Agents construct that value locally from username ":" password according to RFC 7617.

7. Credential Presentation

On later HTTP requests, the Agent presents the credential using HTTP Basic authentication:

Authorization: Basic YWVwX2FnZW50X2FiYzEyMzpzM2NyM3RFeGFtcGxl

The encoded value is standard base64 of username ":" password as defined by RFC 7617. This encoding is not AEP's base64url binary convention.

Authenticated AEP command endpoints MUST continue to accept baseline AEP authentication.

8. Revoke

The Agent invokes AEP Revoke using baseline Authorization: AEP <jwt> authentication with op equal to revoke.

To revoke all Basic credentials of this type for the authenticated Agent:

{
  "grant_type": "basic"
}

To revoke one Basic credential when the Service returned credential_id:

{
  "credential_id": "bas_01HZY8W7Q2F8J7D3P9G9Z1N6TT",
  "grant_type": "basic"
}

Revoke returns an empty JSON object on success. The Service MUST return success regardless of whether a matching credential existed.

To revoke all session credentials of every grant type, Agents use the core all_grant_types Revoke request.

9. Error Handling

This extension uses the AEP error vocabulary defined by the core protocol. A Basic credential that is expired, malformed, revoked, unknown, or bound to a different Agent fails as not_recognized.

10. IANA Considerations

This document requests registration of basic in the AEP Grant Types registry.

Table 1
Field Value
Grant Type basic
Description HTTP Basic credential issued through AEP Grant
Reference This document

11. Security Considerations

Basic credentials are bearer secrets once encoded into the Authorization header. Services MUST store passwords using strong password-storage controls. Services MUST NOT log raw passwords or Authorization header values, and Services MUST support AEP Revoke for every advertised grant type. Agents that suspect credential disclosure SHOULD call AEP Revoke using baseline AEP authentication and then fall back to per-request signed client assertions until a new credential is issued.

Services SHOULD use a distinct realm or credential store for AEP-issued Basic credentials when the Service also supports human-facing Basic credentials.

12. Privacy Considerations

Basic credentials can become correlation handles if reused outside the issuing Service. Agents MUST NOT present AEP-issued Basic credentials to other Services. Services MUST NOT log raw passwords or Authorization header values in ordinary logs or telemetry.

13. Normative References

[AEP-CORE]
Kavian, N., "The Agent Enrollment Protocol", Work in Progress, Internet-Draft, draft-kavian-agent-enrollment-protocol-00, , <https://datatracker.ietf.org/doc/draft-kavian-agent-enrollment-protocol/>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3339]
Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, , <https://www.rfc-editor.org/rfc/rfc3339>.
[RFC7617]
Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, , <https://www.rfc-editor.org/rfc/rfc7617>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8259]
Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/rfc/rfc8259>.
[RFC9110]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/rfc/rfc9110>.

Author's Address

N. Kavian
Jarwin, Inc. (InFlow)