OAuth Bearer Session Credential Grant Type for the Agent Enrollment Protocol

Introduction The Agent Enrollment Protocol (AEP) defines Grant and Revoke commands for optional session credentials . Session credentials are an optimization for deployments that want to reuse existing authentication middleware after an Agent has proven possession of its AEP identity key. This document defines the oauth-bearer grant type. The grant type issues an OAuth Bearer access token through the AEP Grant command. Grant type request and response bodies are JSON objects carried over HTTP semantics as defined by AEP. This grant type does not redefine OAuth authorization grants, refresh tokens, token introspection, or token revocation. When a Service exposes standard OAuth token introspection or revocation endpoints, it advertises those endpoints as grant type configuration.

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 when, and only when, they appear in all capitals, as shown here.

Grant Type The grant type identifier is:

A Service that enables this grant type lists oauth-bearer in commands.grant_types and lists grant and revoke in commands.supported in its AEP Inspect document.

Inspect Configuration A Service MAY publish configuration under commands.grant_types_config.oauth-bearer:

access_token_formats is an array of strings. This document defines opaque and jwt as descriptive values. Agents MUST treat returned access tokens as opaque regardless of the advertised format. default_lifetime_seconds is an AEP-owned numeric value and is therefore represented as a JSON string. introspection_endpoint and revocation_endpoint, when present, are HTTPS URLs for standard OAuth operational tooling. AEP-aware Agents use AEP Revoke for AEP-issued session credentials. 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". Every successful Grant response includes credential_id. When this value is "true", the Service MUST support a Revoke request containing both grant_type and that credential_id. When this value is "false" or absent, the Agent MUST use grant-type or all-grant-types Revoke instead.

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

grant_type MUST be oauth-bearer. 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. token_format is OPTIONAL. The values defined by this document are opaque and jwt. A Service MAY ignore this preference.

Grant Response A successful Grant response is a JSON object:

access_token is REQUIRED and contains the Bearer token value. token_type is REQUIRED and MUST be Bearer. expires_at is REQUIRED and is an RFC 3339 timestamp for credential expiry. scopes is OPTIONAL and contains the granted scope strings when present. A missing or null value means the token has no scope-limited authorization. The Service MAY return an empty array with the same meaning. token_format, when present, describes the Service-selected format. credential_id is REQUIRED and is a stable Service-issued identifier for the issued OAuth Bearer credential. It follows the Service-wide uniqueness and non-reassignment requirements in the Core Grant command. It is not the access token and is not used for credential presentation. The Agent stores it with the credential and sends it only when targeting that credential in a Revoke request supported by the Service. This document does not define refresh tokens. Agents renew by invoking AEP Grant again with a fresh baseline client assertion.

Credential Presentation On later HTTP requests, the Agent presents the token using the Bearer authentication scheme:

On protected resources, the Agent MAY instead use the dedicated AEP carrier while preserving the Bearer field value:

Services implementing this grant type MUST accept both carriers on protected resources. Agents MUST use only one AEP carrier per request, and the ambiguity and precedence rules are defined by AEP core. Authenticated AEP command endpoints MUST continue to accept baseline AEP authentication.

Revoke The Agent invokes AEP Revoke using baseline Authorization: AEP <jwt> authentication with op equal to revoke. To revoke all OAuth Bearer session credentials of this type for the authenticated Agent:

When the Service advertises per-credential Revoke, the Agent can revoke one OAuth Bearer credential:

Revoke returns an empty JSON object on success. The Service MUST return success regardless of whether a matching token existed. To revoke all session credentials of every grant type, Agents use the core all_grant_types Revoke request.

Error Handling This grant type uses the AEP error vocabulary defined by the core protocol. A token that is expired, malformed, revoked, unknown, or bound to a different Agent fails as not_recognized.

IANA Considerations This document requests registration of oauth-bearer in the AEP Grant Types registry. Field Value Grant Type oauth-bearer Description OAuth Bearer access token issued through AEP Grant Reference This document

Security Considerations Bearer tokens are usable by any party that presents them. Services SHOULD issue short-lived tokens. Services MUST NOT log raw access token values, and Services MUST support AEP Revoke for every advertised grant type. Agents that suspect token disclosure SHOULD call AEP Revoke using baseline AEP authentication and then fall back to per-request signed client assertions until a new token is issued. Services MUST bind issued tokens to the authenticated AEP Agent identity. JWT access tokens SHOULD include an audience identifying the issuing Service. Services MUST reject tokens whose audience does not identify the receiving Service.

Privacy Considerations Bearer tokens can become correlation handles if reused outside the issuing Service. Agents MUST NOT present AEP-issued Bearer tokens to other Services. Services MUST NOT log raw access token values in ordinary logs or telemetry.