Multi-Party Authorization for User-Managed Access (UMA) 2.0

1.1. Relationship to the Set

This document is an OPTIONAL extension of [U4ACore] and depends on [U4ATerms], [U4AFedAuthz] and [U4APolicy]. Its identifying URI is https://u4a.ai/spec/multiparty/1.0. An implementation MAY implement Part I, Part II, or both.¶

1.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Throughout, a policy unit is as defined in [U4APolicy] Section 2.¶

2.1. Parties

Organization:

A party that holds resources and shares administration of them with its members. It publishes a charter, answers a decision endpoint, and signs documents its members' authorization servers verify against keys it publishes.¶

Member:

A resource owner under [U4ACore] who has enrolled with an organization. Her authorization server is hers; the organization is a party it consults.¶

The organization and the member's user agent have no relationship, and this document does not invent one. Every message from the organization is addressed to the member's authorization server.¶

2.2. Discovery

An organization MUST publish a metadata document at the path /.well-known/u4a-organization under its issuer identifier. It is public: an authorization server whose owner is not a member has to be able to learn that a resource is claimed, and nothing in it is a member's. It carries:¶

issuer:

REQUIRED. The organization's issuer identifier, an https URL.¶

jwks_uri:

REQUIRED. The keys it signs membership credentials, notices, clearances and break-glass grants with.¶

enrolment_endpoint:

REQUIRED. Where a member's authorization server enrols her (Section 2.9).¶

envelope_endpoint:

REQUIRED. Where a member's authorization server reads the envelope in force (Section 2.5).¶

decision_endpoint:

REQUIRED. Where a member's authorization server asks about a request (Section 2.6).¶

introspection_endpoint, consumption_endpoint:

REQUIRED where the charter enables break-glass. Where an enforcement point introspects, and spends, a grant the organization signed (Section 2.10).¶

enrolment_preview_endpoint, invitation_endpoint, leave_endpoint,

¶

clearance_endpoint, compliance_endpoint, membership_endpoint, audit_endpoint:

REQUIRED. The remaining exchanges of Section 4.¶

claims:

REQUIRED. The charter's claims.¶

charter_version:

REQUIRED. The version of the charter in force.¶

2.3. The Charter

An organization MUST publish a charter, versioned, carrying:¶

claims:

REQUIRED. Patterns naming the resources the organization holds. A pattern MUST name a namespace: it MUST NOT place a wildcard in the segment that identifies whose resource it is, since such a claim would reach a member's own resources and jointly held ones alike.¶

roles:

REQUIRED. Named roles, each with grants (patterns within claims the role may reach) and delegation (Section 2.4).¶

envelope:

OPTIONAL. A ceiling on the terms a member may write over claimed resources (Section 2.5).¶

break_glass:

OPTIONAL. Whether and over which claimed resources the organization may reach past a member (Section 2.10).¶

The pattern language MUST be segment-wise, with a wildcard matching one segment and never crossing a separator, and MUST offer neither alternation nor a recursive wildcard. Four evaluators have to agree on what a pattern matches — the organization's service, the member's authorization server, the enforcement point, and any policy engine the organization runs — and a language small enough to be checked by reading is the only kind that can be.¶

2.4. Delegation

Each role MUST carry a delegation value, one of:¶

none:

The member may reach the resource herself. No agent acting for her may.¶

first-party-only:

An agent the member activated herself ([U4APolicy] Section 5) may be granted access under her terms. An agent somebody else runs may not, whatever her own terms say.¶

any-agent:

Any agent, subject to her terms and the charter.¶

delegation does not say what may be accessed. It says whose agent may do the accessing, on behalf of which person. That is a statement about parties rather than permissions, and it is only expressible because the member's authorization server can already distinguish an agent she activated from one somebody else operates.¶

2.5. The Envelope, Clamped on Write

An envelope MAY carry:¶

max_expires_in:

A member's expires_in over claimed resources comes down to this.¶

allowed_scopes:

Scopes not in it are removed from her terms.¶

require_prohibited:

Prohibitions missing from her terms are added.¶

always_ask:

Patterns over which her policy units are set to ask her every time.¶

require_clearance:

Claims the organization must be able to attest about the member before an agent may act on claimed resources, each naming the values that satisfy it. Combined with any requirement the member wrote by intersection, so the ceiling may add a claim and narrow an accepted value and MUST NOT remove a requirement she wrote. See [U4APolicy].¶

Every envelope field moves a member's terms in one direction only. There MUST be no field that lengthens an expiry, adds a scope, removes a prohibition, or turns off an ask.¶

A member's authorization server MUST apply the envelope when a policy unit over a claimed resource is written, and again whenever the charter changes, by issuing a new version of the unit's terms document through the same path as one of her own edits. It MUST NOT apply the envelope only at grant time.¶

The clamp is applied on write so that the ceiling appears in the terms document the requesting side dereferences and signs, rather than being applied invisibly at the door. A terms document MUST state that a layer above the owner is in force over its resources, in its organization member ([U4ATerms] Section 2): an agent reads the document before it signs anything, and that is the only moment at which "these terms are not hers alone" is information it can act on.¶

An enforcement point MAY also check a grant over a claimed resource against the ceiling, as a second line behind the clamp. One that does refuses a grant that exceeds it with the refusal value organization_envelope_exceeded, status 403, which is terminal: the authority that answered is issuing more than the organization permits, and negotiating again reproduces that exactly.¶

2.6. The Decision

For each request over a resource the charter claims, the member's authorization server MUST ask the organization's decision endpoint once, presenting the facts of the request, and MUST fold the answer into its own. The facts are a JSON object carrying resource_id, the scopes attempted, the policy unit as tier, the expires_in, purpose, reason, mission and operation of the agreement, and the assurance and standing facts of [U4APolicy]; the member's authorization server presents its membership credential with them, as a POST to the organization's decision_endpoint.¶

The organization answers with a JSON object whose effect is allow, ask or refuse, whose because is an array of its reasons in sentences, and which carries governed (whether the charter claims the resource) and the charter_version it decided under. allow means the organization has no objection, not that the request is granted. The composition rule is one sentence: both layers must allow, and either may refuse. An organization's ask raises the member's auto to ask, and the member MUST be shown the organization's reasons separately from her own.¶

An organization's decision MUST NOT widen what the member's policy would decide. Where the organization cannot be reached, the member's authorization server MUST refuse requests over claimed resources; a ceiling nobody can read is not a ceiling.¶

A request over a resource the charter does not claim MUST NOT be sent to the organization.¶

2.7. What the Organization May See

An organization MAY be given a view of a member's pending requests, connections, operators and record, filtered by the member's authorization server to entries concerning resources the charter claims. It MUST NOT be able to read the member's policy; at most it may be told which of its envelope fields bound and whether her units are within the envelope.¶

The filtering is the member's authorization server's, applied before it answers, and is not the organization's to respect.¶

2.8. Acting for a Member

An organization MAY answer a pending request on a member's behalf, and MAY end an agent's reach to claimed resources. When it does:¶

• the record MUST name the organization's administrator, and MUST NOT record the decision as the member's ([U4APolicy] Section 8.4);¶

• an agent shut out by the organization loses its reach to claimed resources only, held in the membership record so that it ends when the membership does, and its standing with the member over her own resources is untouched;¶

• an introspection response for a grant so affected carries error of organization_revoked, which is terminal ([U4AFedAuthz] Section 5).¶

The organization conveys each such action to the member's authorization server as a short-lived JWT with typ of u4a-org-admin+jwt, signed by the organization, naming the member as sub, the organization as org and the acting administrator as admin. The member's authorization server verifies it against the keys of the organization she enrolled with, and refuses one that does not name her.¶

2.9. Enrolment and Leaving

A member's authorization server MUST NOT enrol her with an organization without her explicit agreement to a specific charter version, and MUST show her, before she agrees, what enrolling would change about terms she has already written. The enrolment request MUST name that version, and the organization MUST refuse one that names none or names a version no longer in force.¶

How a joiner is entitled to enrol is the organization's to decide, and the mechanisms differ in what they establish. An invitation addressed to one person, or the organization's own identity provider vouching for her, establishes who is joining. A code shared with a group establishes only that the joiner holds it: whoever does may enrol under any name not already enrolled. An organization offering one SHOULD offer it only for onboarding a group it trusts, and SHOULD NOT make it the only mechanism.¶

The organization issues a membership credential to her authorization server at enrolment — a JWT with typ of u4a-membership+jwt, signed by the organization, naming the member as sub and the organization as org — and that server presents it as a bearer credential on every call to the organization. The organization MUST be able to end a membership and MUST notify the member's authorization server when it does, when her role changes, or when the charter changes. A notice is a JWT with typ of u4a-org-notice+jwt, signed by the organization and verified by the member's server against the keys it publishes, whose kind is one of membership_ended, role_changed, charter_changed, break_glass_opened, break_glass or break_glass_used.¶

Each notice MUST carry its own unique jti, and a member's authorization server MUST act on a given jti once. An identifier shared by several notices — the break-glass family of Section 2.10 is three notices about one override — MUST travel in a member of its own rather than in jti. Where the two are conflated, the second notice about one override is indistinguishable from a replay of the first, and the stage an owner most needs to be told about is the one that is silently dropped.¶

Leaving MUST withdraw the member's access to claimed resources and the ceiling over her, and MUST leave every narrowing the ceiling applied in place. Her terms were narrowed with her agreement and republished under a new version; undoing that would silently widen what agents holding agreements over those versions are held to.¶

2.10. Break-Glass

Where the charter enables it, the organization MAY reach a claimed resource without the member's authorization server, by issuing a grant it signs itself. Such a grant MUST be single-use, bound to a key, short-lived, bound to one operation, and over a resource the charter both claims and names for this purpose. The organization MUST compute the operation's params_s256 itself, as [U4ACore] defines it, over the tool and parameters the request names, and MUST refuse a request that names none. The enforcement point MUST recognise it by issuer and MUST introspect it with the organization rather than with the member's authorization server. It MUST honour it only at a resource the organization owns, and only for the member the introspection response names in owner; an enforcement point that also checks the organization's ceiling over an owner's own resources MUST NOT take that as licence to honour the organization's own grants there.¶

The grant is a JWT access token [RFC9068] with typ of at+jwt, signed with a key at the organization's jwks_uri. It carries iss (the organization's issuer identifier), sub and client_id (the thumbprint handle of the key in cnf), owner, aud, jti, iat, exp, cnf, permissions, single_use of true, operation, and break_glass: an object naming the org, the stated reason, what authorised_by it — a voucher an administrator opened, or an operator the charter lists — and the charter_version it was issued under. The enforcement point introspects it at the organization's introspection_endpoint, whose answers are those of [U4AFedAuthz] Section 5 with the grant's owner added, and spends it at the organization's consumption_endpoint, as the last step of [U4ACore] Section 8.2. Both are authenticated with the credential the organization provisioned for that enforcement point (Section 4).¶

The member MUST be notified at the moment the window opens, before any data moves. Break-glass cannot be a flag on an ordinary grant: it has to be a grant the organization signs, checked with the organization, bounded by a clause the member was shown before she joined, and unable to be quiet.¶

3.1. Parties

Holder:

A resource owner under [U4ACore] who holds a resource jointly with others. Each holder has her own authorization server.¶

Tally:

A party that publishes the mandate, folds the holders' terms into one document, collects verdicts, and issues a grant carrying them. It speaks the authorization-server surface of [U4ACore] to the client, which cannot tell it from an authorization server and does not need to.¶

With no party above the holders, the decision cannot be put anywhere without privileging the place it is put. The tally is that place, and the rest of Part II is what makes it unable to lie rather than trusted.¶

3.2. The Mandate

The tally MUST publish, for each jointly held resource, a mandate, at the URI its authorization server metadata names as u4a_mandate_endpoint — a template in which {account} names the jointly held account. The mandate carries:¶

resources:

REQUIRED. At least one resource identifier or pattern.¶

holders:

REQUIRED. At least two, each with owner, an https issuer naming her authorization server, and an integer weight of at least one. An owner MUST NOT appear twice.¶

rule:

REQUIRED. kind of all, any or threshold, normalised to a numeric threshold: the total weight for all, the lightest holder's weight for any, and a stated value between one and the total for threshold.¶

A holder's authorization server MUST store the mandate she agreed to, MUST re-ask her when the published mandate differs from it in holders, threshold or resources, and MUST refuse to count a holder who has written no terms over the resource.¶

A deployment MAY fix a floor below which no mandate's threshold may go. The interesting real-world version of this is not a group choosing its own quorum; it is a regulator or an account agreement fixing one, and a floor set from outside answers the question a self-chosen quorum cannot.¶

Authoring a mandate is where "who decides who decides" lives, and this document leaves it to configuration.¶

3.3. The Fold

When a client presents a ticket for a jointly held resource, the tally MUST obtain each holder's terms over it from her authorization server and MUST fold them into one terms document: the shortest expiry, the intersection of scopes, the union of prohibitions, and ask-me if any holder asks. It proffers that document under [U4ATerms], and the agent signs it once.¶

The fold is the clamp of Section 2.5 applied sideways: each holder's terms are a ceiling on the running document. An implementation SHOULD use one implementation of the narrowing for both, since two would be two chances to disagree about what "narrower" means in the two places where disagreeing is worst.¶

3.4. Verdicts

Each holder's authorization server, asked by the tally about one negotiation, MUST answer with a verdict: a JWS [RFC7515] signed by that server with a typ of u4a-verdict+jwt, carrying:¶

holder:

REQUIRED. The holder.¶

account:

REQUIRED. The jointly held resource.¶

negotiation:

REQUIRED. The negotiation identifier this verdict answers.¶

resource_id:

REQUIRED. The resource the negotiation is over, as the tally named it when it asked.¶

contract:

REQUIRED. The digest of the agreement the agent signed, as [U4ATerms].¶

effect:

REQUIRED. allow or refuse.¶

because:

OPTIONAL. Reasons, for a refusal.¶

exp:

REQUIRED. No earlier than the agreement the verdict is about would end, so that a grant within that lifetime can carry it.¶

cnf_jkt:

REQUIRED in an allow. jkt(k), as [U4ACore] defines it, of the key k that signed the agreement.¶

scope:

REQUIRED in an allow. The scopes the agreement carries.¶

expires_in:

REQUIRED in an allow. The lifetime the agreement carries.¶

operation:

REQUIRED in an allow whose agreement names an operation. Its tool and params_s256, as in the operation claim of [U4ACore].¶

mandate_s256:

REQUIRED in an allow. The digest of the mandate the holder agreed to, as Section 3.5.¶

consequence:

REQUIRED in an allow where the resource declares one for the operation. The consequence class of [U4ACore] the holder's authorization server read when it answered.¶

An allow verdict MUST carry cnf_jkt, scope, expires_in and mandate_s256, and MUST carry operation where the agreement names one and consequence where the resource declares one. The tally's grant MUST carry the most severe consequence any allow verdict it carries names. A verdict that said only "yes, to this agreement" could be carried inside any grant the tally chose to issue beside it, because the enforcement point checks verdicts against the grant and never sees the agreement. Stating the grant's material facts as the holder's authority verified them is what lets the enforcement point refuse a grant that is not the one agreed to.¶

A holder's authorization server that has recorded the owner's approval of one agreement MUST NOT issue an allow verdict about a different agreement, or a different resource, under the same negotiation. The tally asks again with whatever it holds, and matching on the negotiation alone would turn her approval of one document into an approval of any.¶

A verdict is bound to one negotiation and one agreement so that it cannot carry a later request. Before answering allow, a holder's authorization server MUST compare the folded document the agent signed against the terms she published, and MUST refuse on any difference in the direction of more: a longer expiry, an extra scope, a dropped prohibition. Differences in the direction of less are expected, since another holder's terms were folded in. This is what lets the folding party be untrusted.¶

{
  "iss": "https://alice-as.example",
  "holder": "alice",
  "account": "joint-brokerage-1",
  "negotiation": "fam_8f3aQ2Xc",
  "resource_id": "joint-brokerage-1/get_positions",
  "contract": "s256:RqgXOcbufB1e0ITn3oQ6fteUNc1EVRPk3VxOWsOV-0s",
  "effect": "allow",
  "cnf_jkt": "jkt:ESqNMeKw-z8gcDH-8y96ckX3h7TU6FtF9lqluDQ1Now",
  "scope": ["positions:read"],
  "expires_in": 3600,
  "mandate_s256": "s256:2Vm2OGY_mn3mY6G-N-Obxdgg49uzoxsK8brUPgw5_Gk",
  "iat": 1789430000,
  "exp": 1789430300
}

3.5. The Mandate Digest

The digest of a mandate is s256 as [U4ACore] defines it: s256: followed by the base64url encoding, without padding, of the SHA-256 hash of the [RFC8785] serialization of an object with exactly three members:¶

holders:

Each holder reduced to owner, issuer with any trailing slash removed, and weight, ordered by owner.¶

resources:

The mandate's resources, sorted.¶

rule:

kind, and the numeric threshold that kind implies.¶

Holders' authorization servers and enforcement points MUST compute the digest this way. It covers what decides a count and nothing else, so a tally that publishes a summary beside the mandate, or lists holders in another order, publishes the same digest, while one that moves a weight, swaps an issuer or changes the rule does not.¶

Where the holder's policy asks her, the verdict is withheld until she answers, and the tally holds the negotiation pending as [UMAGrant] request_submitted.¶

3.6. Verdicts Are Not Claims

A verdict MUST travel from the holder's authorization server to the tally. It MUST NOT be gathered by the client and presented as a claim.¶

A claim the requesting party gathers is a claim it can decline to gather. A holder's refusal has to reach the decision point without the cooperation of the party it refuses, and claims-gathering cannot carry it. The general boundary: claims work when the requesting party is the only one who holds the fact, and fail when the fact may be adverse to it.¶

3.7. The Count

The tally MUST sum the weight of holders whose verdict is allow and compare it to the threshold. It MUST refuse the moment the weight still outstanding cannot carry the request over the threshold — under all, the first refusal ends it — rather than waiting for every holder. Silence and unreachability MUST both fail closed; only the record distinguishes them.¶

3.8. The Grant Carries the Verdicts

A grant the tally issues MUST carry a joint claim with:¶

account:

REQUIRED. The jointly held resource.¶

mandate:

REQUIRED. The mandate as the tally holds it.¶

verdicts:

REQUIRED. Every verdict received, as issued.¶

tally:

OPTIONAL. The tally's own count, for display.¶

The grant MUST also carry, as a family claim, the negotiation identifier its verdicts name, and the tally's introspection response MUST return it. Without it the enforcement point cannot establish which negotiation the grant was issued for, and a verdict about one negotiation would be as good as a verdict about any.¶

{
  "joint": {
    "account": "joint-brokerage-1",
    "mandate": {
      "holders": [
        {"owner": "alice", "issuer": "https://alice-as.example",
         "weight": 1},
        {"owner": "carol", "issuer": "https://carol-as.example",
         "weight": 1}
      ],
      "rule": {"kind": "all", "threshold": 2},
      "resources": ["joint-brokerage-1/*"]
    },
    "verdicts": ["eyJ0eXAiOiJ1NGEtdmVyZGljdCtqd3Qi...",
                 "eyJ0eXAiOiJ1NGEtdmVyZGljdCtqd3Qi..."],
    "tally": {"effect": "allow", "for": 2, "threshold": 2}
  }
}

3.9. Re-Verification at the Enforcement Point

An enforcement point protecting a jointly held resource MUST, before allowing a call under such a grant:¶

1. fetch the mandate from where the tally publishes it, and MUST NOT use the copy embedded in the grant, and refuse unless it covers the resource being accessed;¶

2. verify each verdict, including its exp, against the keys published by the authorization server the enforcement point is itself configured to know speaks for that holder, and refuse where the published mandate names a holder it knows no authorization server for, or names a different one;¶

3. establish that each verdict names this negotiation, this agreement and the resource being accessed;¶

4. establish, for each allow verdict, that its mandate_s256 is the digest of the published mandate, and that the grant is bound to the key cnf_jkt names, carries no scope beyond scope, lasts no longer than expires_in, declares no lighter consequence than the verdict names, and, where the verdict names an operation, is single-use and bound to that operation;¶

5. re-run the count of Section 3.7 and refuse unless it allows.¶

A refusal under this list carries the refusal value joint_mandate_unsatisfied, status 403, which is terminal. Where the mandate or a holder's keys cannot be fetched, the enforcement point answers temporarily_unavailable instead: that is a party it could not ask, not a decision anybody made.¶

The tally member of the grant is for display and MUST NOT be trusted.¶

An enforcement point protecting a jointly held resource MUST refuse a grant that carries no joint claim.¶

The holders' authorization servers come from the enforcement point's own configuration for the same reason the mandate does not come from the grant: the mandate is published by the tally, and a tally that could name the issuer each verdict is checked against could name issuers it controls, sign verdicts for holders it invented, and have every signature verify. The tally MUST NOT issue a grant that outlives any allow verdict it carries.¶

Reading the mandate from the grant would let the party being checked supply the standard it is checked against: a single genuine verdict beside a rewritten threshold would pass with every signature verifying. Reading it from where the tally publishes it is safe only because every verdict names the digest of the mandate its holder agreed to; a published mandate with a different electorate is one no verdict was given under. The tally issues its grant from the agreement, bounded by the folded terms, so that an honest grant is always one step 4 can re-derive. Carrying the verdicts in the grant and re-verifying them at the resource is what makes the tally an ordinary service rather than a ledger — there is no ordered history here to agree on and no long-lived state a fork could damage.¶

3.10. No Organization Reaches a Jointly Held Resource

A charter claim MUST NOT match a jointly held resource, and a holder's authorization server MUST refuse to apply an organization's envelope or decision to one regardless. A jointly held resource MUST NOT share a policy unit with any other resource, since a ceiling applies to a whole unit once it reaches any resource in it. A holder's authorization server MUST compare a resource against the mandate's resources as patterns, as it compares charter claims.¶

The protection runs one way. A holder's authorization server MUST refuse to agree to a mandate covering a resource an organization she belongs to claims, and MUST NOT treat such a mandate as taking that resource out of the organization's reach: otherwise a member could lift her organization's ceiling off its own resource by joining a mandate any party could publish.¶

Peers compose horizontally; an authority above them clamps vertically. The two are orthogonal rather than rival, and this document keeps them apart.¶

4.1. Member's Authorization Server to Organization

The enrolment request carries owner (REQUIRED), as_uri (REQUIRED, the member's authorization server, to which notices and administrator actions will be sent), charter_version (REQUIRED, Section 2.9), and whichever of code and assertion the organization's enrolment path requires. The response carries membership_token, the membership credential, beside the members of an envelope document.¶

An envelope document carries org, name, issuer, charter_version, published_at, the envelope fields of Section 2.5 in force for this member, and her role as role, role_name, grants and delegation. The preview and envelope exchanges answer with one.¶

A decision request carries the facts of Section 2.6, at least resource_id. The answer carries effect (allow, ask or refuse), because (an array of sentences the member is shown), governed (whether the charter claims the resource) and charter_version.¶

A clearance answer carries clearance, a JWT with typ of u4a-clearance+jwt ([U4APolicy]), and expires_in. Where the organization holds no attestation for the member it MUST answer 404, which her authority treats as unmet rather than as an error.¶

A compliance report carries charter_version, resources_governed, tiers_governed, clamped_fields (the names of the envelope fields that narrowed her terms) and within. It MUST NOT carry any value from her policy.¶

4.2. Organization to Member's Authorization Server

A notice is POSTed to the member's authorization server's org_notice_endpoint (/org/notice) as {"notice": <JWT>}, a signed message with typ of u4a-org-notice+jwt carrying sub (the member), org, jti, an exp no more than five minutes after iat, and kind:¶

The member's authorization server MUST act on a notice's jti once until its exp, across every replica, and MUST answer 409 to a second presentation. A kind it does not recognise it MUST accept without acting on it.¶

An administrator's action (Section 2.8) is sent to org_admin_endpoint (/org/admin) followed by /{owner}/ and one of pending, pending/{family}/decision, connections, connections/revoke, connections/restore, operators, operators/{action} or ledger, with a signed message of typ u4a-org-admin+jwt as the bearer token. It carries sub (the member), org, admin and an exp no more than two minutes after iat. The bodies and answers are those of the owner's own API for the same operation ([U4AOwner]), narrowed to what Section 2.7 allows.¶

4.3. Enforcement Point to Organization

Each is authenticated with the enforcement point credential. A membership answer is {"member": false}, or "member": true with since and the members of an envelope document. A consumption answer carries consumed and, where false, error from the vocabulary of [U4AFedAuthz] Section 5.¶

4.4. Tally to Holder's Authorization Server

The tally asks with a signed message of typ u4a-tally-req+jwt, POSTed as {"request": <JWT>}. Every request carries owner (the holder, as her authorization server names her) and account.¶

A quote, at joint_quote_endpoint (/joint/quote), adds resource_id. The answer carries owner, tier_id and tier (her terms over the resource as Section 3.3 reads them), or tier of null with because where she has written none.¶

A verdict request, at joint_verdict_endpoint (/joint/verdict), adds negotiation, resource_id, contract (the agreement's digest) and agreement (the agreement JWS, so that her authority verifies it itself). The answer carries verdict, a verdict as Section 3.4, or pending of true with family while she has not answered.¶

A holder's authorization server MUST refuse a request from a tally other than the one the mandate she agreed to names, and MUST answer about her alone.¶

5.1. A Layer Above May Only Narrow

See Section 2.5 and Section 2.6. The one-directionality of every envelope field and of the decision's effect on the member's own result is the property the whole of Part I rests on. An implementation SHOULD be able to demonstrate over its full envelope that no combination of envelope and terms produces wider terms than it started with.¶

5.2. Reach Stops at the Claim

See Section 2.7 and Section 2.8. Everything the organization can see or do stops at the resources its charter claims, and the scoping is applied by the member's authorization server before it answers. An organization given a member's whole record because it is easier has been given her relationships with parties that have nothing to do with it.¶

5.3. An Administrator's Decision Is Not the Owner's

See Section 2.8. "The owner personally approved" may relax a rule under [U4APolicy]; a decision taken for her must not produce that fact.¶

5.4. The Mandate Is Read Where It Is Published

See Section 3.9. This is the single check that makes the tally untrusted.¶

5.5. Silence Is Not Consent

See Section 3.7. A holder who has not answered and a holder who cannot be reached both count for nothing.¶

5.6. Break-Glass Is Loud

See Section 2.10. An emergency path that can be exercised quietly is an ordinary path with a better name.¶

6.1. Members Are Not Visible to Each Other

Under Part I, an organization's view of one member is filtered to claimed resources and says nothing about any other member. Under Part II, a holder's authorization server MUST NOT expose another holder's pending queue, decisions or record; each holder sees her own verdicts and the count.¶

6.2. The Ceiling Is Disclosed to the Agent

Section 2.5 requires that a terms document state when a layer above the owner is in force. That discloses to the requesting side that the owner is a member of some organization, which is a fact about her. The alternative — a ceiling applied invisibly — asks the agent to sign terms that are not the terms it will be held to, and this document prefers the disclosure.¶

8.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.

[U4ACore]

Gamb, N. and E. Maler, "User-Managed Access (UMA) 2.0 Profile for Autonomous Agents", Work in Progress, Internet-Draft, draft-gamb-uma4agents-core-00, 2026, <https://u4a.ai/spec/draft-gamb-uma4agents-core-00.html>.

[U4AFedAuthz]

Gamb, N. and E. Maler, "Federated Authorization for Autonomous Agents", Work in Progress, Internet-Draft, draft-gamb-uma4agents-fedauthz-00, 2026, <https://u4a.ai/spec/draft-gamb-uma4agents-fedauthz-00.html>.

[U4AOwner]

Gamb, N. and E. Maler, "The Resource Owner's API for User-Managed Access (UMA) 2.0", Work in Progress, Internet-Draft, draft-gamb-uma4agents-owner-00, 2026, <https://u4a.ai/spec/draft-gamb-uma4agents-owner-00.html>.

[U4APolicy]

Gamb, N. and E. Maler, "Owner Policy, Assurance and Attention for User-Managed Access (UMA) 2.0", Work in Progress, Internet-Draft, draft-gamb-uma4agents-policy-00, 2026, <https://u4a.ai/spec/draft-gamb-uma4agents-policy-00.html>.

[U4ATerms]

Gamb, N. and E. Maler, "Owner-Proffered Terms for User-Managed Access (UMA) 2.0", Work in Progress, Internet-Draft, draft-gamb-uma4agents-terms-00, 2026, <https://u4a.ai/spec/draft-gamb-uma4agents-terms-00.html>.

[UMAGrant]

Maler, E., Machulak, M., and J. Richer, "User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization", Kantara Recommendation, 7 January 2018, <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html>.

8.2. Informative References

[PP2PI]

Lush, N., Ed. and Kantara Initiative User-Managed Access Work Group, "Solving Data Sharing Challenges with UMA: The Julie Adams Healthcare Use Case from PP2PI", Kantara Editors' Draft Report, March 2023, <https://kantara.atlassian.net/wiki/spaces/uma/pages/4850258/Notes+drafts+and+WIP>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

[U4ALAB]

Gamb, N. and E. Maler, "UMA for Agents: a reference implementation", 2026, <https://github.com/nickgamb/uma4agents>.