]> MindGarden LLC

nickgamb@gmail.com

Venn Factory

Security UMA authorization AAuth agents binding proof-of-possession This document binds the UMA 2.0 profile for autonomous agents to the AAuth protocol: the agent credential AAuth issues is the identified-agent credential of the profile, AAuth's HTTP message signature conventions are its proof of possession, the requesting party token is an AAuth authorization token, and a resource may publish its structure in AAuth's resource metadata beside RFC 9728. AAuth's four-party access mode is the topology the profile runs.

Introduction defines agent identity bound to a session key, a signature convention over HTTP requests, and four access modes, of which the fourth — federated, where an authorization server the resource names decides — is the topology of . What AAuth leaves to the authorization server is how it knows the owner's policy. That is what the profile supplies. The two compose without either bending. AAuth's resource token and UMA's permission ticket are the same object minted on opposite sides — both produced at a refused access, both naming what was attempted, both a pointer to the authority that could grant it. The difference is where the state sits: AAuth's is minted by the resource, UMA's by the owner's authorization server when the resource registers the attempt. For a grant that can wait on an absent owner, only the second has anywhere to keep the pending request, and this binding uses it.

Relationship to the Set This document is a binding of in the sense of its Section 1.3. Its identifying URI is https://u4a.ai/spec/aauth/1.0.

Notational Conventions 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.

The Identified Agent A requesting agent presenting itself at the identified level of Section 5.1 under this binding carries an AAuth agent credential — a JWT with typ of aa-agent+jwt — in the agent_token header of the agreement JWS of Section 4.1. The authorization server MUST: refuse a credential whose iss does not use the https scheme; resolve the issuer's keys through the agent server metadata AAuth publishes at /.well-known/aauth-agent.json under the issuer, following its jwks_uri, and verify the credential against them, selecting by kid where one is present; refuse a credential carrying no cnf.jwk; treat cnf.jwk as the key that signed the agreement and that the grant is confirmed to. The connection handle is the credential's sub, qualified by the host of its iss as sub@host, and MUST NOT be derived from the key. AAuth binds a fresh key per session; the subject is what persists. Where the credential carries an act claim naming another agent's subject, an authorization server implementing reads it as that document's Section 2.2 specifies. Nothing further is defined.

Proof of Possession The message signature profile of Section 6.1 — over @method, @authority, @path and authorization — is AAuth's convention as describes it, with two constraints this binding adds. The signature label MUST be sig1. The alg parameter MUST be ed25519, and every key this binding mints or verifies is an Ed25519 key in OKP form; an implementation MAY accept other algorithms from third-party issuers whose keys it fetches, choosing the permitted algorithms from the key's type and never from the token's own header.

The Grant The requesting party token of Section 7.1 is issued as an AAuth authorization token: a JWT with typ of aa-auth+jwt, its cnf.jwk naming the agent's key, and the permissions, owner and contract claims the profile requires. sub is the agent credential's sub, or the literal aauth:pseudonymous-agent for an agent at the pseudonymous level.

An enforcement point verifies possession against cnf.jwk as returned by introspection, as Section 8.2 step 3.

Resource Metadata A resource MAY publish, at /.well-known/aauth-resource.json, the same structural facts its document carries, in AAuth's encoding:

resource:

The resource identifier, as .

access_mode:

four-party.

access_servers:

The authorization servers the owner names; the same array as authorization_servers.

jwks_uri:

The resource's keys, as .

r3_vocabularies:

An array of vocabularies, each with format, an operations array naming each operation and its resource_scopes, and a digest that is s256 over the canonical serialization of operations with keys sorted.

owner_resources_endpoint:

The protected listing of Section 2.2. The same URL as in the RFC 9728 document.

signed_metadata:

A JWT over the document with typ of aauth-resource+jwt, signed by a key at jwks_uri.

Both documents MUST be generated from one registry of the resource's operations. The instance layer beneath them, and the permission ticket, do not change with the encoding: owner_resources_endpoint points at one listing. The content digest gives the operation surface a stable identifier that no owner's instances appear in. A vocabulary describes what the resource's operations are; the owner's terms describe what she permits; they compose, and neither absorbs the other.

The Challenge This binding uses the HTTP challenge of Section 3.2 unchanged. AAuth's own challenge header is not used; the permission ticket already carries what AAuth's resource token would, minted on the side that can hold a pending request.

Security Considerations The considerations of and apply.

Issuers Are Trusted by Dereference resolves an issuer over TLS and believes the keys it publishes. Section 5.1 requires a deployment to say which issuers it will believe, and this binding does not relieve it of that.

Algorithms Come From the Key . A verifier that lets a token's header choose the algorithm it is verified with has let the token choose whether it is verified.

Privacy Considerations The considerations of apply. An agent credential names its subject to every authorization server it is presented to, which is the identified level's purpose; an agent that does not wish to be named presents at the pseudonymous level and this binding changes nothing about that.

IANA Considerations This document makes no request of IANA. The media types aa-agent+jwt, aa-auth+jwt and aauth-resource+jwt are defined by .

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. Hellō This document defines the AAuth authorization protocol for agent-to- resource authorization and identity claim retrieval. The protocol supports four resource access modes — identity-based, resource- managed (two-party), PS-managed (three-party), and federated (four- party) — with agent governance as an orthogonal layer. It builds on the HTTP Signature Keys specification ([I-D.hardt-httpbis-signature-key]) for HTTP Message Signatures and key discovery. Hellō Cloudflare This document defines five HTTP header fields for use with HTTP Message Signatures as defined in RFC 9421. The Signature-Key request header distributes public keys used to verify signatures, with eight initial key distribution schemes: pseudonymous inline keys (hwk), self-issued key delegation via JWK Thumbprint JWTs (jkt-jwt), identified signers with JWKS URI discovery (jwks_uri), direct JWKS fetch (jwks), JWT-based delegation (jwt), self-issued JWTs (self- jwt), X.509 certificate chains (x509), and references to previously cached assertions (cached). The Accept-Signature-Scheme and Accept- Signature-Alg response headers state the schemes and algorithms a server accepts, so a client can select both before it signs. The Signature-Error response header provides structured error information when signature verification fails, and the Signature-Key-Cache response header issues a cache identifier by which a caller can reference a previously presented assertion instead of resending it. Together, these mechanisms enable flexible trust models ranging from privacy-preserving pseudonymous verification to horizontally-scalable delegated authentication and PKI-based identity chains. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.

Implementation Status This section records the status of known implementations in the sense of , and is to be removed before publication as an RFC. The reference implementation runs this binding against the AAuth reference person server, pinned at a fixed upstream revision, for its identified-agent path, and serves both metadata encodings of from one registry. A check runs the same negotiation at both identity levels and asserts that the terms, the grant and the authority named are identical across them.

Acknowledgments supplied the agent identity and signature conventions this binding composes with, and the observation that a resource token and a permission ticket are one object minted on opposite sides.