]> MindGarden LLC

nickgamb@gmail.com

Venn Factory

Security UMA authorization federated resource registration discovery This document extends Federated Authorization for User-Managed Access (UMA) 2.0 in three places where the agent era exposes an assumption. Resource registration becomes declarative: the resource server publishes its structure in protected resource metadata and serves its owner-bound instances only to the owner's authorization server, which pulls rather than being pushed to. A resource server establishes its relationship with an owner's authorization server by signing as the origin it serves, rather than by a credential somebody had to provision at both ends. And the protection API's introspection response says why a token is inactive, so an enforcement point can tell a refusal that further negotiation might change from one it cannot.

Introduction separates the resource server from the authorization server so that the owner's policy can live with a party the resource server does not control. It then assumes the two are already acquainted: the resource server holds a protection API access token (PAT), pushes descriptions of the owner's resources under it, and asks it for permission tickets. Each of those assumptions holds when one operator runs both sides and stops holding when the authorization server is the owner's. Nobody can provision a secret at both ends when the two ends belong to different people. Pushing owner-bound resource descriptions requires the resource server to know, per owner, which authorization server to push to. And a resource server that has registered a resource with one owner's authority has published, to that authority, which resources that named person owns — which the resource server was in a position to know and the metadata document it publishes to the world must not be. This document keeps the direction chose — the authorization server is the owner's, and the resource server is its client — and specifies the three things it left to deployment.

Relationship to the Set This document extends and is REQUIRED to implement alongside . Its identifying URI is https://u4a.ai/spec/fedauthz/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.

Discovery in Two Layers Discovery is split by who may ask.

The Public Layer A resource server MUST publish protected resource metadata for each resource it serves. That document describes the structure of the resource: what operations it offers and with what scopes. It MUST NOT name which owners have instances behind it. This document adds two members to the metadata:

tool_surfaces:

OPTIONAL. An array of objects, each with a tool member naming an operation and a resource_scopes member listing the scopes that operation requires. Structural only.

owner_resources_endpoint:

REQUIRED. The URL of the protected listing of .

The document MUST carry signed_metadata as Section 2.1, signed by a key published at the resource's own jwks_uri, so that a relayed copy stays attributable to the resource. A resource server MAY publish the same structural facts in more than one encoding — for example the metadata of alongside — from one registry. The instance layer beneath them, and the permission ticket, do not change with the encoding.

The Protected Layer A resource server MUST serve, at owner_resources_endpoint, the owner-bound resource instances it holds for one owner — their identifiers, names, and scopes — and MUST serve them only to a request signed with by the authorization server that owner has named, verified against that authorization server's published keys. The signature profile is that of Section 6.1, with @authority taken from the resource server's configuration. This is the privacy split. The public document says what the resource is; whose things sit behind it is served only to the party the owner's own consent already connected. Publishing the second at an unauthenticated URI is a disclosure that push registration, for all its other costs, never made.

Declarative Registration An authorization server implementing this document MUST be able to learn what a resource server protects by fetching, and MUST NOT require the resource server to push resource descriptions. The classic resource registration endpoint of Section 3 remains conformant and MAY be offered alongside. To register a resource server's resources for an owner, the authorization server: fetches the resource server's protected resource metadata; verifies signed_metadata against the keys at the document's jwks_uri, and verifies that the signed claims name this resource as iss; sends a signed request to owner_resources_endpoint; materializes its registry for that owner from the response, and removes any registration from that source for that owner that the response no longer carries. One fetch replaces N registration calls, and there is one registry with one writer.

Staleness The registry the authorization server holds may lag what the resource server serves. When a permission request names a resource identifier the authorization server does not hold, it MUST attempt a fresh pull before answering invalid_resource_id. This is the mirror of what asked of the resource server — noticing invalid_resource_id after an authorization server restart and re-pushing — placed with the party that can act on it without a round trip.

Liveness The pull and its verification form a call cycle: the authorization server fetches from the resource server, and the resource server authenticates that fetch by dereferencing the authorization server's published keys. An authorization server MUST NOT condition its own readiness on the pull having completed, and a resource server verifying a signed request MUST either tolerate a live back-call to the authorization server or verify against keys it already holds. Gating readiness on "my registry is populated" deadlocks: the authorization server will not serve its keys until it has pulled, and the resource server will not serve the pull until it has the keys. The general form is that in a profile where two parties authenticate each other by dereference, neither party's liveness may be conditioned on the exchange completing.

Establishment Section 1.4 requires that the PAT be issued with the resource owner's authorization, and says nothing about how the resource server comes to be a client of the authorization server at all. Where one operator runs both sides, a provisioned client credential models that gap adequately. Where the authorization server is the owner's, nobody is in a position to configure both ends.

Registration by Origin A resource server MAY introduce itself to an owner's authorization server by sending a request naming the owner and the resource it serves, signed with using a key published at the origin of that resource. The request MUST carry a Content-Digest covered by the signature.

The authorization server MUST verify the signature by: fetching the protected resource metadata for resource_uri from that resource's own origin; refusing unless the document's resource equals resource_uri, its jwks_uri is same-origin with resource_uri, and its authorization_servers names this authorization server; fetching the keys at jwks_uri and verifying the signature against them. A resource server that cannot be reached, or whose document fails any of the three checks, MUST be refused. This is a deliberate departure from how an authorization server treats an operator's key directory, where an unreachable document leaves an agent's claim where it was. There, the document attests a claim already made by other means. Here, the document is the credential, and a credential that cannot be fetched has not been presented. A profile that reuses the attestation language here has specified an authentication that fails open.

The Answer Is the Owner's A verified signature settles who is asking and nothing else. On success the authorization server MUST respond 202 Accepted with a body carrying status of pending and error of authorization_pending, MUST record the resource server in the owner's registry as pending, and MUST issue no PAT until the owner has approved it.

The client_id of a resource server registered this way is its origin. Registration reaches an owner; it MUST NOT create one. The signature proves control of an origin and says nothing about whether the owner named beside it exists. An authorization server that seeds an owner on demand has turned an unauthenticated endpoint into unbounded state.

Obtaining the PAT Once the owner has approved, the resource server obtains a PAT with the client_credentials grant and scope of uma_protection, as Section 1.5, authenticating in the same way it registered: by an signature over the token request, verified against keys at the origin it registered as. Which authentication applies — a provisioned secret or an origin signature — is a property of the stored registration, so that a resource server registered by signature cannot later fall back to guessing a secret. While the owner has not answered, the token endpoint MUST respond 403 with error of authorization_pending. After the owner has revoked the resource server, it MUST respond 403 with error of access_denied.

Withdrawal The owner MUST be able to revoke a resource server, and on revocation the authorization server MUST stop honouring that resource server's PAT on every protection API call, from every replica, at once. A resource server that registers again after being revoked MUST land in the pending state, not the active one. A second request is not a reversal of the owner's first decision, and re-registration MUST NOT be a way to undo a withdrawal.

Introspection Reasons An authorization server MUST include, in an introspection response whose active member is false, an error member. The following values are defined:

expired:

The token's lifetime has passed.

invalid_signature:

The token did not verify.

unknown_token:

The token was not issued by this authorization server, or its record is gone.

already_consumed:

A single-use token has been spent.

connection_revoked:

The owner has ended the standing relationship under which this token was issued. See Section 9.

Of these, connection_revoked is terminal: an enforcement point receiving it MUST refuse without issuing a fresh challenge, because renegotiation cannot change an outcome the owner has settled. The others MAY be answered with a fresh challenge. An extension MAY define further values. defines organization_revoked.

Non-Consuming by Default Introspection MUST NOT consume a single-use token. Consumption is a separate operation, taken by the enforcement point as the last step of enforcement, as Section 8.2. An authorization server MUST offer that operation at the URL it advertises as consume_endpoint in its metadata, MUST require the protection API access token on it as on introspection, and it MUST report to its caller whether that caller was the one that consumed the token. The request carries the token as introspection does; the response is a JSON object with a consumed member. true means this caller spent the token; false means it was already spent, or was not a single-use token, and MUST be accompanied by an error member saying which.

Reporting Allowed Access An enforcement point SHOULD report each call it allows to the authorization server, naming the negotiation it was made under and what was reached, so that the owner's record holds what was done alongside what was promised. An enforcement point MUST NOT be told, and MUST NOT report, the identity handle of the requesting agent. The authorization server resolves it from the negotiation. The enforcement point is the resource server's component, and the owner's record of which agent did what is not the resource server's to hold.

Security Considerations The considerations of Section 7 apply.

An Endpoint That Dereferences Will Dereference What It Is Told carries no credential the authorization server issued; the signature checked against the origin's own published document is the credential. Any caller can therefore cause an outbound fetch to a host they name. An authorization server MUST bound the response size it will read, MUST NOT follow redirects, MUST require https, and SHOULD keep a short memory of resources that did not check out so that a flood of registrations is not a flood of fetches. The bound this document deliberately does not require is an address blocklist. A resource server legitimately sits on a private range whenever it is deployed near its owner's authority, so refusing those would break the honest case and not the dishonest one. Naming the hosts an authorization server may reach is an egress policy and belongs to the deployment.

The Owner's Policy Is Not on the Protection API The protection API is scoped to the PAT, and it carries no operation that returns the owner's policy. An implementation SHOULD be able to demonstrate that the enforcement point is refused the owner's policy and is allowed her published keys, on the same origin.

Revocation Reads the Store requires that a revoked PAT stop working on every replica at once, which means the resource server's status MUST be read on each protection API call rather than cached in process. A revocation that reached only the replica that served the request would leave the others honouring a credential the owner had just withdrawn.

Privacy Considerations The considerations of Section 8 apply. The split in exists because the alternative is a disclosure. A public document listing the resources a named person owns is readable by anyone who can guess its URL, and a resource server serving many owners has published a directory of them. The structural layer says nothing about any person; the instance layer is served only to the authority that person named, and that authority already knew.

IANA Considerations

OAuth Protected Resource Metadata Registration IANA is asked to register the following in the "OAuth Protected Resource Metadata" registry established by .

Metadata Name:

tool_surfaces

Metadata Description:

Operations the resource offers, each with the scopes it requires

Change Controller:

IETF

Specification Document(s):

of this document

Metadata Name:

owner_resources_endpoint

Metadata Description:

URL of the protected listing of owner-bound resource instances

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Authorization Server Metadata Registration IANA is asked to register the following in the "OAuth Authorization Server Metadata" registry established by .

Metadata Name:

consume_endpoint

Metadata Description:

URL of the operation that spends a single-use requesting party token

Change Controller:

IETF

Specification Document(s):

of this document

OAuth Token Introspection Response Registration IANA is asked to register the following in the "OAuth Token Introspection Response" registry established by .

Name:

error

Description:

Why an inactive token is inactive; see of this document

Change Controller:

IETF

Specification Document(s):

of this document

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. 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 document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. 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. 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. 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. 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 implements this document in full. Both registration methods — declarative pull and the classic push endpoint of — were built against an otherwise identical stack and measured before push was retired to a preserved branch. The deadlock of and the fail-open reading that warns against were both found by running it.

Acknowledgments This document rests on , whose separation of resource server from authorization server is the arrangement everything here depends on. supplied the public half of discovery, and the observation that a resource may name its authorization servers is what made the split in possible.