Huawei

jiangyuning2@h-partners.com

Huawei

lilun20@huawei.com

Huawei

songyurong1@huawei.com

Huawei

liufei19@huawei.com

Security Web Authorization Protocol OAuth intent AI agents admission control consent workload identity In agentic systems, an intent expressed by a user, application, or agent may be forwarded to a remote system that triggers high-impact actions. If the originator of an intent is not authenticated, is not authorized to request the targeted action, or has not obtained the required consent, the receiving system may act on a forged or unauthorized intent. This document defines the Intent Admission Assertion (IAA): a signed, verifiable artifact by which an admission point authenticates an intent originator, authorizes the request against a permission policy, gates consent-required actions on explicit consent from the user or resource owner, and conveys the result to a downstream execution endpoint that re-verifies it before acting. The IAA is a JSON Web Token whose admission decision is expressed using Rich Authorization Requests (RFC 9396).

Introduction In agentic systems, intents are produced by users, applications, and agents and forwarded to systems that may trigger high-impact actions, such as purchases, data disclosure, or changes to account or device state. At the point where an intent enters such a system, the receiver often cannot tell whether the intent truly came from the claimed originator, whether that originator is permitted to request the action, or whether the user or resource owner consented. A co-resident malicious application can fabricate an intent that appears to come from the user; an originator running unattended in the background can trigger a high-impact action without consent. This document defines the Intent Admission Assertion (IAA), a signed and verifiable artifact that an admission point produces after authenticating the originator, evaluating a permission policy, and (when the policy requires it) obtaining explicit consent from the user or resource owner. The IAA carries the admission decision to the execution endpoint, which re-verifies it before performing the requested action. The design captures these signals at the earliest point at which they are verifiable (the admission point) and enforces them again at a non-bypassable point (the execution endpoint), so that intermediaries that forward the intent need not be trusted. The IAA reuses existing building blocks rather than introducing new cryptography. It is a JSON Web Token following JWT best current practices ; the admission decision is expressed as a Rich Authorization Requests authorization detail ; proof of possession binds the IAA to an authorized presenter; and the JSON Canonicalization Scheme provides a stable representation for binding to a JSON intent. An IAA MAY be conveyed as, or alongside, a transaction token or its agent profile ; related profiles include the agent-to-agent OAuth profile and agentic JWT . A fuller threat model and the security requirements that motivate this profile are described in and ; maps the behavior defined here onto those requirements.

Conventions and Terminology 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 terms Intent, Intent Originator, and Admission Control are used as in . This document additionally uses:

Intent:

A declarative request, produced by an Intent Originator, for a targeted action or service.

Intent Originator:

The entity that produces an intent, e.g., an application, an operating system component, or an agent.

Intent Admission Assertion (IAA):

The verifiable artifact defined by this document, issued by an Admission Point upon admitting an intent.

Admission Point (AP):

The entity that authenticates the originator, evaluates the permission policy, obtains consent where required, and issues an IAA. It MAY act as, or interact with, an OAuth authorization server or assertion issuer.

Execution Endpoint (EE):

The entity that re-verifies an IAA and performs, or refuses, the requested action; it acts as an OAuth resource server.

Permission Policy:

Policy determining which originators may request which actions, and which actions require consent.

Policy Authority:

The entity that maintains the Permission Policy.

Overview Three roles participate in admitting and acting on an intent. The Intent Originator produces the intent and holds an identity credential. The Admission Point sits where the intent enters the system: it authenticates the originator, decides whether the request is permitted, obtains consent when the policy requires it, and, on a positive decision, issues an IAA. The Execution Endpoint performs the action; before doing so it verifies the IAA. A Policy Authority maintains the policy the Admission Point and Execution Endpoint apply. Originator identity is established by an identity credential. For workload originators, such as cloud agents or services, deployments can use WIMSE workload credentials , with the identifiers and terminology of and . Local originators, such as on-device applications or operating system components, can instead use a platform identity, application attestation, or a device-bound key; not every originator is a WIMSE workload. Request-level proof of possession can reuse WIMSE request protection .

Intent admission flow | - authenticate origin | | (app / OS | | - authorize request | | / agent) | | - obtain consent | +------------+ | (when required) | +-----------+-----------+ | Intent Admission Assertion (signed JWT) v [ relay / network ] | v +-----------------------+ | Execution Endpoint | | - verify the IAA | | - act, or refuse | +-----------------------+ ]]>

The intent and the IAA may pass through relays, gateways, or other intermediaries that are not trusted to preserve them. The IAA is therefore self-protecting: it is signed, bound to the intent, and bound to an authorized presenter, so that an intermediary can forward it but cannot forge or repurpose it, and the Execution Endpoint can verify it independently of any transport-layer protection.

The Intent Admission Assertion

Format An IAA is a JWT protected as a JWS, and MUST follow . It contains the following registered claims:

iss:

Identifier of the Admission Point that issued the IAA.

aud:

The intended Execution Endpoint(s). An Execution Endpoint MUST reject an IAA whose "aud" does not include it.

iat, exp:

Issuance and expiry. The validity period SHOULD be short.

jti:

A unique identifier used for replay detection.

cnf:

A confirmation claim identifying the key of the authorized presenter (). When the "jkt" (JWK SHA-256 Thumbprint) confirmation method is used, it follows .

The admission decision is carried as an authorization detail (). A CBOR Web Token / COSE encoding may be defined by a future profile and is out of scope for this document.

Proof of Possession and Presentation Modes Because an IAA may traverse relays and gateways, the party that presents it to the Execution Endpoint is not necessarily the Originator. The "cnf" claim therefore binds the IAA to the key of the authorized presenter, according to the presentation mode:

Direct presentation:

The Originator presents the IAA directly to the Execution Endpoint, the "presenter" member () has "mode" of "direct", and "cnf" binds the Originator's key.

Delegated presentation:

An authorized presenter (for example, the Admission Point, a gateway, an agent runtime, or a relay) presents the IAA on the Originator's behalf. The "presenter" member identifies that presenter with "mode" of "delegated", "cnf" binds the authorized presenter's key, and the IAA retains the authenticated Originator identity in the "originator" member.

The Execution Endpoint MUST verify the "cnf" proof against the key of the actual presenting party, and MUST verify that the presenting party is the authorized presenter identified by the "presenter" member.

The "intent_admission" Authorization Detail The admission decision is a single Rich Authorization Requests authorization detail object with "type" set to "intent_admission", carried in the "authorization_details" claim of the IAA. The value "intent_admission" MAY be used where the type namespace is local to the issuer; deployments requiring cross-issuer interoperability SHOULD use a collision-resistant type value, such as a URI under their administrative control. Following , the common data fields "actions", "locations", and "datatypes" appear at the top level of the object. The object has the following members:

intent_ref (REQUIRED):

A binding to the admitted intent (): a JSON object with members "hash_alg", "digest" (base64url), and "canonicalization".

originator (REQUIRED):

A JSON object describing the authenticated originator, with members "id" (the originator identity, e.g., a WIMSE identifier), "class" (e.g., "application", "os_component", or "agent"), "execution_context" (where available, one of "foreground", "unattended", "delegated_background", or "scheduled"), and OPTIONAL "attestation" (a reference to attested application/workload state). Raw behavioral history is not included ().

presenter (REQUIRED):

A JSON object identifying the party authorized to present the IAA: "id" (the presenter identity), "mode" ("direct" or "delegated"), and OPTIONAL "cnf_ref" (the confirmation method in "cnf" bound to this presenter, e.g., "jkt"). In "direct" mode, "id" equals the originator's "id".

actions, locations, datatypes:

The admitted action(s), resource location(s), and data type(s), using the common data fields of .

decision (REQUIRED):

The admission outcome. This profile defines only the value "admit"; rejected or escalated intents do not yield an IAA. The member is retained for audit clarity.

consent_required (REQUIRED):

A boolean indicating whether the Permission Policy requires explicit consent for this request ().

consent (REQUIRED when "consent_required" is true):

Evidence of consent ().

constraints (OPTIONAL):

A constraint envelope carried for downstream constraint or semantic checks.

Intent Binding The IAA is bound to the specific intent it admits, so that it cannot be replayed against a different intent. The "intent_ref" member carries a digest of the admitted intent together with the parameters needed to reproduce it. If the admitted intent is a JSON object, the digest input MUST be the JSON Canonicalization Scheme representation of that object, and "canonicalization" MUST be "jcs". If the admitted intent is not JSON, the digest input MUST be the exact octet sequence received by the Admission Point, and "canonicalization" MUST be "none". The hash algorithm identifier is carried in "hash_alg"; implementations MUST support "sha-256" and MUST NOT use MD5 or SHA-1.

Consent Evidence When "consent_required" is true, the "consent" object MUST be present; its presence indicates that consent was obtained, since an IAA is not issued when required consent is refused or absent. The object provides evidence of consent and does not define user-interface behavior. Its members are:

method (REQUIRED):

How consent was obtained, e.g., "user_confirmation", "prior_grant", or "step_up".

time (REQUIRED):

The time consent was obtained.

scope_ref (REQUIRED):

A reference binding the consent to this admitted intent and scope. The value MUST be derived from, or otherwise uniquely reference, the admitted intent, the admitted action/resource scope, and any constraints that were presented for consent.

evidence_ref (OPTIONAL):

A reference to evidence retained locally or by the Admission Point. It MUST NOT expose raw user-interface content, behavioral history, or a full user profile.

Issuing an Intent Admission Assertion An Admission Point admits an intent, and issues an IAA, only after the following steps succeed.

Authenticating the Origin The Admission Point MUST authenticate the Originator and verify the binding between the intent and the Originator identity. The originator authentication mechanism MUST cover, or be bound to, the submitted intent or an unambiguous digest of it, so that an originator credential cannot be paired with a different intent; the specific mechanism (e.g., an HTTP Message Signature, a DPoP-like proof, an attestation-bound request, or a local OS-mediated call) is not specified here. An intent whose origin cannot be verified MUST NOT be admitted.

Authorizing the Request The Admission Point evaluates the authenticated Originator against the Permission Policy, using risk-relevant originator attributes such as identifier, class, execution context, attested state, or locally maintained risk signals. The Admission Point MUST NOT admit the intent if the requested action is not permitted for that originator by the policy, if the originator is not permitted by the policy, or if the originator's execution context is one the policy disallows (for example, unattended background execution).

Obtaining Consent This document does not define a global taxonomy of high-impact actions. Whether an action requires consent is determined by the Permission Policy, which may mark a service, action, data type, amount, target resource, or execution context as requiring explicit consent from the user or resource owner. When the policy so requires, the Admission Point sets "consent_required" to true, MUST obtain and verify explicit consent, and MUST include the corresponding "consent" evidence in the IAA. If consent is absent or refused, the intent MUST NOT be admitted.

Constructing the IAA On admission, the Admission Point constructs the IAA per , binds it to the intent () and to an authorized presenter key (), signs it, and returns it for forwarding.

Verifying an Intent Admission Assertion Before performing a requested action, the Execution Endpoint MUST:

1. verify the JWS signature and that "iss" is a trusted Admission Point;
2. verify "aud" includes this Execution Endpoint and that the IAA is within its validity period;
3. verify the "cnf" proof of possession against the actual presenting party's key, and verify that the presenting party is the authorized presenter identified by "presenter" ();
4. detect replay using "jti";
5. verify "intent_ref" matches the intent being acted upon ();
6. verify that the requested action and all action parameters are within the admitted action/resource scope (the "actions", "locations", and "datatypes") and any applicable "constraints"; if a constraint carried in the IAA cannot be interpreted or enforced, the Execution Endpoint MUST refuse the action unless local policy explicitly permits ignoring that constraint;
7. when "consent_required" is true, verify that valid "consent" evidence is present.

These checks are the authoritative gate: the Execution Endpoint enforces them so that no side path can bypass them. If any check fails, the Execution Endpoint MUST refuse the action and SHOULD record audit evidence. For defense in depth, an Execution Endpoint may independently evaluate the Originator and the requested action against its own copy of the Permission Policy, applying the conditions of and , rather than relying solely on the Admission Point's decision. Where the policy indicates that additional originator information is required, or the action is of a predetermined sensitive type, the Execution Endpoint SHOULD request an updated or re-issued IAA carrying the required minimized attributes, rather than relying on ad hoc attributes obtained outside the assertion.

Deployment Considerations

Permission Policy This document does not define a policy language. A conforming deployment is able to determine, for a given authenticated originator, requested action, execution context, and consent requirement, whether an IAA may be issued. Binding to a specific policy language or engine is out of scope.

Logging and Policy Update Admission Points and Execution Endpoints may emit log records associated with an originator and/or an action, supporting auditability and policy-driven response. Such records carry the same privacy obligations as IAAs (): raw behavioral history is not exported, and reported attributes are minimized. The transport, cadence, aggregation, and policy-update mechanism for such records are deployment-specific and out of scope.

Security Considerations The IAA is a sensitive artifact. Proof of possession ("cnf") is REQUIRED to prevent a stolen IAA from being presented by an unauthorized party; the proof binds to the authorized presenter per the presentation mode (). Short validity, "jti"-based replay detection, and audience restriction further limit misuse. Because the IAA may traverse untrusted intermediaries, its integrity and binding do not rely on transport security. Admission Point compromise: a compromised Admission Point can issue IAAs for arbitrary originators. Admission Point signing keys MUST be protected, rotated, and revocable, and Execution Endpoints SHOULD constrain the set of trusted issuers and the originators an issuer may assert. Intent binding: without "intent_ref", an IAA could be replayed against a different intent. The canonicalization and hash requirements of prevent rebinding; algorithm agility allows migration away from weakened hashes. Algorithm downgrade: Execution Endpoints MUST reject IAAs that use disallowed signature or hash algorithms, and MUST NOT accept "alg":"none". Attestation freshness: where "attestation" is used, Execution Endpoints SHOULD verify its freshness, as stale attestation can mask a changed originator state. Replay detection SHOULD be scoped at least by ("iss", "jti") and retained until the IAA expires. If an IAA has multiple audiences, replay-detection state is maintained consistently across the relevant audiences, or the IAA is audience-restricted to a single Execution Endpoint. Confidentiality: a JWS-protected IAA provides integrity but not confidentiality. If an IAA contains deployment-sensitive or privacy-sensitive attributes, deployments SHOULD use encryption (e.g., a JWE), an opaque reference, or an end-to-end protected channel between the Admission Point and the Execution Endpoint.

Privacy Considerations An IAA SHOULD avoid exposing raw local state or behavioral history to downstream entities. Originator attributes are minimized to those relevant to the admission decision, and coarse-grained decisions or policy references are preferred over detailed originator profiles. Consent evidence references () MUST NOT expose raw user-interface content, behavioral history, or a full user profile.

IANA Considerations This document does not request any IANA actions. The "authorization_details" JWT claim is already registered by . This document defines a new authorization details type value, "intent_admission", for use by deployments supporting this profile. As does not establish a central registry for authorization details type values, "intent_admission" is a deployment-local value; deployments requiring cross-issuer interoperability use a collision-resistant value as described in .

Normative References Informative References

Examples This appendix is informative. Whitespace is added for readability; long values are abbreviated with an ellipsis.

An "intent_admission" authorization detail

The IAA is a JWS-signed JWT. Its decoded payload carries the registered claims and the authorization detail above:

Decoded payload of an Intent Admission Assertion

The JWS header (not shown) carries the signing algorithm and a reference to the Admission Point's key; the compact serialization concatenates the header, payload, and signature.

Relationship to the Intent Security Requirements This appendix is informative. It maps the behavior defined in this document onto the security requirements of , for readers familiar with that document. Mapping to requirements

Behavior in this document	Requirement
Authenticating the origin ()	R8 (Origin Authentication)
Authorizing the request and obtaining consent (, )	R9 (Originator Authorization and Consent-Gated Admission)
Verifying the IAA as a non-bypassable gate ()	R5 (Non-Bypass Enforcement)
Logging and policy update ()	R6, R7 (Observability; Policy-Driven Response)

Acknowledgments TODO