]> OmniArx

arun@advitlabs.com

Security attestation authorization WYSIWYS mobile agent This document defines the OASNT token, a compact JWS-based credential in which a hardware-bound device key attests that a specific human, on a device whose runtime integrity was assessed, authorized one specific action whose human-readable disclosure is cryptographically bound to the token (What You See Is What You Sign). Tokens are single-use, short-lived, and may additionally be bound to one concrete HTTP request.

Introduction Systems increasingly execute consequential actions on a person's behalf without that person present at the moment of execution. Autonomous agents move funds, change access, and modify records, carrying credentials that prove only who issued them and to whom. Such a credential does not record that any human saw the operation it is now being used to perform. Where a human approval step does exist, it is usually a server-side artifact: a flag on a session, a row in a table, a callback that fired. The approval and the executed operation are connected by application logic rather than by cryptography, so an incident review cannot establish what the approving person actually read. Nor can it establish anything about the device they read it on. This document defines the OASNT token, which addresses both gaps in a single signed object. A key held in device-resident secure hardware signs a digest of the action to be performed, a digest of the disclosure text as it was rendered to the user, and optionally a fingerprint of the one concrete request the approval authorizes. The signed object also carries the device's own assessment of its runtime integrity at the moment of signing. Binding the rendered disclosure, rather than only the operation, is the property this document treats as essential and is commonly called What You See Is What You Sign. Its absence is exploitable: a system that binds only the operation will accept a token whose operation digest was recomputed after the human approved something else. therefore requires the disclosure binding and forbids falling back to operation binding alone. OASNT is deliberately narrow. It expresses a single human authorization event as verifiable evidence. It does not describe delegation between components, policy evaluation, or how authority is attenuated as it passes through a system. Frameworks that address those concerns, including remote attestation procedures , can consume an OASNT token as the human-authorization evidence at the root of a chain they otherwise manage.

Relationship to Other Work Several active efforts address adjacent parts of this problem. This section states what they cover and what this document adds, so that the delta is explicit rather than implied. Descriptions reflect the versions available at the time of writing.

Human authorization receipts defines a signed receipt asserting that a named human, or an M-of-N quorum, authorized a specific operation before execution, together with transparency-log inclusion proofs and key directory material that this document does not attempt to duplicate. composes such receipts into a portable evidence graph with a replayable admissibility verdict, and treats human authorization as a distinct capability satisfied by artifacts of that kind. This document is written to interoperate with that work rather than to restate any part of it. Those receipts bind an action digest and a context digest, and require that the approver be shown a faithful human-readable rendering of the action. The signature covers the context digest rather than the rendered text. That is a deliberate scoping decision, and a defensible one: the receipt is designed to establish evidentiary exactness, and honouring the rendering requirement is left to the approving client, which in the general case is the only party positioned to do so. This document specifies the complementary piece for the case where that client is a mobile device. defines a digest over the rendered octets and requires it to match, which lets a relying party confirm the rendering requirement was honoured rather than rely on it having been. The binding is meaningful here because such a device renders the disclosure and holds the signing key within a single trust boundary, which is not true of authenticators generally; see . An OASNT token can therefore serve as the human-authorization artifact that a receipt of this kind carries or references, adding the display binding without altering the surrounding evidence model, its transparency machinery, or its quorum semantics.

Transaction confirmation in WebAuthn The txAuthSimple and txAuthGeneric extensions to were defined to carry a prompt for display on the authenticator, which is the same property provides. They were not implemented by browsers and have been proposed for removal as untestable. The obstacle is architectural rather than a lack of interest: a general-purpose authenticator has no display, so it cannot attest to what a user was shown. This document targets a class of device where the constraint does not hold. A modern mobile device renders the disclosure and holds the signing key inside the same trust boundary, which is what makes a binding over the rendered octets meaningful. states the limits of that assumption.

Agent identity, delegation and policy and establish workload identity for non-human callers. and address delegated authorization and token exchange. adds per-hop actor-signed evidence. defines policy envelopes, per-hop attestations and enforcement receipts, and admits device-bound approval strengths. These operate at a different layer, and deliberately so. Each constrains what an agent is permitted to do and records how authority moved between components. None sets out to establish what a human was shown before agreeing, which is the question this document takes up. The relationship is complementary: OASNT produces evidence for the root of a delegation chain that those mechanisms then carry and attenuate.

Regulatory requirements Strong customer authentication under requires that authentication codes be dynamically linked to a specific amount and payee, and that the payer be made aware of both. Electronic signature practice describes the same property as What You See Is What You Sign. These establish the requirement without defining an interoperable format for the resulting evidence. Deployed implementations are largely proprietary, frequently using dedicated hardware with a trusted display. This document specifies a claim format for the same property on general-purpose mobile hardware.

Conventions and Definitions 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 term "disclosure" refers to the human-readable text presented to a user on a display, in the form in which the user read it, immediately before that user authorized an action.

Architecture Three roles participate. The minter runs on the user's device. It holds the signing key in secure hardware, renders the disclosure, obtains the user's approval, and produces the token. It is the only role that observes the human. The enrollment service establishes, once per key, that the key is hardware-bound and belongs to the device it claims to. It records the key's thumbprint. specifies this. The verifier is the party about to execute the action. It holds the set of enrolled thumbprints, recomputes every binding from its own representation of what it is about to do, and accepts or refuses. specifies this. A typical exchange: | | |<--- enrolled ------------| | | | | -- action + disclosure -->| | | | renders disclosure | | | user approves | | | hardware key signs | |<------- token ------------| | | recompute adg, dsp, rqf | | | accept or refuse | | ]]> How the action reaches the device, and how the token returns, are out of scope. The token is self-contained and its verification does not depend on the channel that carried it. Two properties follow from this arrangement and are relied on throughout. First, the verifier never trusts the token for anything it can compute itself. Every digest is recomputed from the verifier's own view of the action and request. The token supplies only digests to compare against and a key identifier to look up. Second, the party that observes the human is the party that holds the key. The disclosure binding is meaningful only because rendering and signing happen inside the same trust boundary. states the limits of that assumption.

Token Format An OASNT token is a JWS in compact serialization.

JOSE Header The protected header MUST consist of exactly the members alg and typ, with the values shown: A verifier MUST reject a token whose alg is not ES256 or whose typ is not oasnt+jwt. Algorithm agility is deliberately not offered; see .

Signature The signature is ECDSA using P-256 and SHA-256, encoded as the concatenation R || S of two 32-octet big-endian integers (64 octets total), base64url encoded without padding per . A verifier MUST reject a signature whose decoded length is not exactly 64 octets.

Claims The JWS payload is a JSON object containing the following members. All digest-valued claims are base64url encoded without padding, over a SHA-256 digest.

Claim	Type	Presence	Binds
sub	string	REQUIRED	the subject the token was issued for
adg	string	REQUIRED	the action to be executed ()
dsp	string	REQUIRED	the disclosure the human read ()
rqf	string	OPTIONAL	one concrete request ()
int	string	REQUIRED	device runtime integrity at signing time
jti	string	REQUIRED	single-use nonce
iat	number	REQUIRED	issuance time, seconds since the epoch
exp	number	REQUIRED	expiry, seconds since the epoch
cnf	object	REQUIRED	key confirmation; contains jkt

cnf.jkt is the JWK thumbprint of the public key corresponding to the signing key. int takes exactly one of the values clean, compromised, or unknown. It is asserted by the device, not proven by the token; see . The payload is signed as serialized. Member order is at the minter's discretion and carries no meaning, because verification recomputes the signature over the octets as received and never re-serializes the payload. An implementation MUST NOT depend on member order. An OPTIONAL claim that is absent MUST be omitted entirely rather than included with an empty or null value. This distinction is load-bearing: requires a verifier to distinguish "not bound to a request" from "bound to a request that does not match".

Canonicalization Three canonical encodings are defined. Each is hashed with SHA-256 and base64url encoded to produce a claim value. None of them is ever parsed; they exist only to be produced deterministically and hashed.

Key ordering Wherever this document specifies that parameters are sorted, they MUST be sorted in ascending lexicographic order of the UTF-8 octet sequence of the parameter name. Implementations MUST NOT sort by UTF-16 code unit, which is the default string ordering in some languages and which differs from UTF-8 octet order for names containing characters outside the Basic Multilingual Plane. Two implementations disagreeing here will produce different digests for the same action and fail to interoperate. Parameter names MUST be unique within an action. A duplicate name MUST cause the minter to fail rather than resolve the duplicate.

Canonical action The canonical action is: (shown wrapped for width; the canonical string contains no line breaks) where parameters are ordered per , and escape() prefixes each occurrence of the four octets \, |, =, and & with a single \. Each input octet is classified exactly once; the escape prefix introduced for one octet is never itself re-escaped. The | separator is emitted even when there are no parameters. adg is the base64url encoding of the SHA-256 digest of this string. Escaping is what prevents a parameter value from impersonating a separator. Without it, the parameter pair (a, b&c=d) and the pair set {(a,b), (c,d)} would produce identical canonical strings and thus identical digests.

Canonical display The canonical display is the disclosure text, constructed as the type followed, for each parameter in the order of , by a line feed (0x0A), the parameter name, a colon, a space, and the parameter value: (shown wrapped for width; LF marks the only line breaks the string contains) Here escape() replaces each \ with \\ and each line feed with the two characters \n, in that order, and performs no other transformation. dsp is the base64url encoding of the SHA-256 digest of this string. This string is what the human reads. A verifier that recomputes dsp is asserting that the octets displayed to the user are the octets the user's key signed. See for the boundary of that assertion.

Request fingerprint The request fingerprint binds a token to one concrete request. It is the base64url encoding of the SHA-256 digest of: where body-digest is the raw 32-octet SHA-256 digest of the request body, and the digest of the empty string is used when there is no body. The four text fields are UTF-8 encoded and MUST NOT contain a NUL octet; a minter or verifier encountering one MUST treat the input as invalid rather than attempt to encode it. The NUL separators make the encoding unambiguous for fields that may themselves contain any non-NUL octet. body-digest is appended raw rather than hex- or base64-encoded, and is fixed-length, so no separator follows it.

Verification Procedure A verifier MUST perform the following checks. Every failure is terminal: a token that fails any check MUST be refused, and MUST NOT be accepted on weaker terms. The order below is normative only where a later step depends on an earlier one having established its precondition. Implementations are RECOMMENDED to evaluate all applicable checks and report the complete set of failures, as this materially assists integration; see .

1. Structure. The token MUST consist of exactly three base64url segments separated by two . characters, and the first two MUST decode to well-formed JSON objects.
2. Header. alg MUST equal ES256 and typ MUST equal oasnt+jwt.
3. Key lookup. The verifier MUST look up cnf.jkt among keys that have completed enrollment (). A thumbprint that is absent, malformed, or not enrolled MUST be refused. The verifier MUST NOT accept a key supplied by the token itself.
4. Signature. The signature MUST verify under the enrolled public key over the octets BASE64URL(header) "." BASE64URL(payload) exactly as received.
5. Thumbprint confirmation. The verifier MUST recompute the JWK thumbprint of the enrolled key and confirm it equals cnf.jkt.
6. Expiry. exp MUST be a number and MUST be greater than or equal to the current time.
7. Issuance. iat MUST be a number and MUST NOT be more than a small tolerance in the future. Implementations SHOULD use 5 seconds.
8. Replay. jti MUST be present and MUST NOT have been seen before. See step 12 for when it is recorded.
9. Action binding. adg MUST equal the digest recomputed per over the action the verifier is about to execute. The verifier MUST recompute this from its own representation of that action and MUST NOT use any value carried in the token.
10. Intent binding. dsp MUST be present and MUST equal the digest recomputed per over that same action. A token lacking dsp MUST be refused rather than accepted as action-bound only.
11. Request binding. If the verifier is authorizing a concrete request, then rqf MUST be present and MUST equal the fingerprint recomputed per over that request. A token lacking rqf MUST be refused in this case. If the verifier is not authorizing a concrete request, rqf is ignored.
12. Integrity. int MUST equal clean.
13. Commit. Only if every preceding check passed, the verifier MUST record jti as seen.

Reserve and commit Step 13 is deliberately last. A verifier that records jti when it first observes the claim can be induced to consume the nonce of a legitimate token: an attacker who observes a token in flight may alter any octet and submit the result, which fails signature verification but, under a record-on-sight implementation, has already burned the nonce. The genuine token is then refused as a replay when it arrives. Recording the nonce only after full validation removes this. A token that fails any check leaves no trace, so an unforgeable copy cannot deny service to the token it was copied from.

Reporting refusal reasons Refusals are not interchangeable, and an integrator debugging a deployment needs to distinguish a clock problem from a replay from a downgrade attempt. Implementations are RECOMMENDED to return a distinguishable reason per failed check. Reasons SHOULD NOT be returned to an untrusted caller where doing so would reveal whether a given key is enrolled or whether a given nonce has been seen.

Enrollment and Key Attestation A verifier accepts a token only if cnf.jkt names a key that completed enrollment. Enrollment establishes, once, that the key is resident in device secure hardware and that the party presenting it controls it.

Challenge The enrollment service MUST issue a random challenge of at least 32 octets, bound to the subject enrolling, with a bounded lifetime. Implementations SHOULD use 300 seconds. A challenge MUST be single-use. It MUST be consumed on first presentation whether or not enrollment subsequently succeeds, so that a failed attempt cannot be retried against the same challenge. A challenge that is unknown, already consumed, or expired MUST cause enrollment to fail.

Platform attestation The enrolling party presents a platform attestation over the challenge. The service MUST verify, at minimum:

1. that the attestation chains to a trusted root for the claimed platform;
2. that the challenge inside the attestation equals the challenge issued;
3. that the attested key is hardware-backed;
4. that the attested public key equals the key being enrolled.

Check 4 is what prevents an attacker from presenting a genuine attestation obtained elsewhere while enrolling a key they control. The service MUST compare the thumbprint of the attested key with the thumbprint of the presented key and MUST refuse on any difference. For Android Key Attestation, the security level recorded in the attestation extension MUST indicate a trusted execution environment or a dedicated secure element. An attestation reporting a software-only security level MUST be refused. For Apple App Attest, the service MUST verify the attestation object's certificate chain to the Apple root, that the nonce extension equals SHA-256(authenticatorData || SHA-256(challenge)), and that the relying-party identifier hash in the authenticator data equals SHA-256 of the expected application identifier.

Storage On success the service records the subject, the public key, and its thumbprint . Verifiers look up keys by thumbprint alone.

Deployment without attestation A deployment may record a key without verifying a platform attestation, for example where an enrollment service has not been configured with trusted roots. Such a deployment does not provide the properties this document describes. Every guarantee here reduces to the enrollment check, and a key admitted without attestation is not known to be hardware-bound. Implementations SHOULD make this mode impossible to enable in a production configuration.

Security Considerations

Signature algorithm ES256 is mandated rather than negotiated. The signing key is required to be hardware-bound (), and P-256 is the curve available across the mobile secure elements this document targets. In particular, at the time of writing, the iOS Secure Enclave supports P-256 and does not support Ed25519, so a specification mandating Ed25519 for this purpose could not be satisfied by a hardware-bound key on that platform. Offering algorithm agility in the header would also reintroduce the algorithm-substitution attacks that a fixed alg forecloses.

The display trust boundary The dsp claim binds the octets that were rendered. It does not, and cannot, prove that a human read them, that the rendering was legible, or that the operating system's display path was honest. WYSIWYS holds only to the extent that the platform's rendering and input path is intact, which is precisely what the runtime integrity assessment behind int exists to assess. A verifier MUST NOT interpret a valid dsp as proof of comprehension or consent in any legal sense. It proves that the signing key signed a digest of specific displayed octets.

Device-asserted integrity int is asserted by software on the device. A device whose runtime is fully compromised may assert clean. The claim raises the cost of an attack and records a verdict for audit; it is not a proof. Relying parties SHOULD treat int as one input to a risk decision rather than as a guarantee, and SHOULD prefer platform attestation () as the stronger signal.

Canonicalization ambiguity Both hashed encodings are injective over their inputs only because of the escaping rules in . An implementation that omits escaping, or that escapes in a different order, will admit distinct actions with identical digests, which defeats action binding entirely. The ordering requirement in is a correctness requirement, not a style preference. Two implementations that disagree will fail to interoperate; because verification is fail-closed, they will refuse valid tokens rather than accept invalid ones, but the deployment will be broken.

Verifier-side recomputation A verifier MUST recompute every digest from its own representation of the action and request. Using any plaintext carried alongside the token, or reflecting values from the token into the recomputation, reduces the binding to a self-consistency check and provides no security.

Compromise of the enrollment path The security of every token reduces to the enrollment of its key. A verifier that accepts an unattested key, or that admits a key whose attestation chains to an untrusted root, gains nothing from the remaining machinery.

IANA Considerations

JSON Web Token Claims IANA is requested to register the following in the "JSON Web Token Claims" registry established by .

Claim Name	Description	Change Controller	Reference
adg	Action digest	IETF	of this document
dsp	Disclosure digest	IETF	of this document
rqf	Request fingerprint	IETF	of this document
int	Device runtime integrity	IETF	of this document

None of these four names appears in the registry at the time of writing.

On the choice of adg The action digest is named adg, for action digest, rather than the more obvious act. act is unavailable: Section 4.1 registers it as the "Actor" claim, a JSON object identifying the acting party in a delegation chain. The conflict would have been substantive rather than cosmetic. The registered claim is an object and this one is a string, so a general-purpose JWT implementation that understands could mis-handle a token defined by this document, and a relying party processing both could not disambiguate them. A nested object holding all three digests under one registered name was also considered. Three top-level claims were chosen instead because rqf is OPTIONAL, and its presence or absence is load-bearing in : an absent top-level claim is unambiguous in a way that an absent member of a present object is not.

Media Types IANA is requested to register the following in the "Media Types" registry.

Field	Value
Type name	application
Subtype name	oasnt+jwt
Required parameters	N/A
Optional parameters	N/A
Encoding considerations	binary; a JWS in compact serialization
Security considerations	See the Security Considerations of this document
Interoperability considerations	N/A
Published specification	This document
Applications that use this media type	Applications requiring evidence that a human authorized a specific action
Change controller	IETF

The typ header parameter value oasnt+jwt is the subtype of this media type, following the convention establishes with at+jwt.

References Normative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. This specification defines a method for computing a hash value over a JSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. Federal Information Processing Standard, FIPS This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. 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. 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. Informative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. 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 specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. EMILIA Protocol, Inc. The standards landscape now produces many signed artifacts about an AI agent's action: workload identity credentials, delegation and grant tokens, call-chain transaction tokens, runtime attestation results, pre-execution policy permits, named-human authorization receipts, post-execution action records, and transparency-log inclusion receipts. No specification defines how a relying party decides whether a collection of such artifacts is SUFFICIENT to rely on for a given purpose: releasing a payment, honoring a trade, satisfying an auditor, or paying an insurance claim. This document defines three things that together fill that layer: the Action Evidence Graph (EP-AEG), a portable, content-addressed graph of references to signed artifacts about one action, whose identity is independent of how much of it is disclosed; Evidence Policy Replay, a deterministic, offline evaluation of a graph against a RELYING-PARTY- supplied evidence policy, yielding one of five closed verdicts (admissible, missing_evidence, stale, conflicted, unverifiable) with a replay digest that lets any third party recompute the decision; and the Reliance Result (EP-RELIANCE-RESULT), the verdict as a signed artifact, making the reliance decision itself auditable evidence. Six policy packs profile the mechanism for concrete irreversible action classes. A verdict is evidence of sufficiency under a stated policy; it is not adjudication, and the graph never carries its own sufficiency bar. Glyphzero, Inc. This document records a comparative mapping of two evidence layers for cross-organization AI agent delegation: a per-hop delegation chain (PEDIGREE) and a named-human authorization root (the EMILIA Protocol binding and evidence-graph drafts), evaluated against the nine requirements of draft-reece-wimse-cross-org-delegation under a no-shared-operator assumption. It also records a verifier-facing composition model in which key possession, delegated authority, and pre-execution human authorization are diagnostically separate inputs with independent failure behavior, joined by action digest. The mapping was developed on the WIMSE mailing list; corrections continue there. Nivalto, Inc. This document specifies the Agent Route Origin Authorization (AgentROA) framework, a cryptographic policy enforcement model for governing the actions of autonomous AI agents. AgentROA introduces three core protocol objects: the Agent Route Origin Authorization (ROA) envelope, the Agent Route Attestation (ARA) per-hop receipt, and the Agent Execution Receipt (AER). Together these objects enable: (1) cryptographic binding of an agent's authorized action scope to a signed policy envelope at session initialization, (2) per-hop attestation across multi-agent delegation chains with monotonic scope-narrowing semantics (no policy envelope may be expanded by a downstream delegation), and (3) cryptographic receipts produced intrinsically by the enforcement decision at each capability invocation boundary. The framework is modeled on the BGP Route Origin Authorization (ROA) concept from RPKI (RFC 6480) applied to the AI agent execution domain. The Border Gateway enforcement model positions a cryptographic enforcement process at a capability invocation boundary — external to the agent's execution context — reducing the risk that governance decisions are influenced by the governed agent by placing enforcement in a separate process boundary. The Border Gateway model is topology-independent: it may be deployed as a protocol- specific proxy in front of Model Context Protocol (MCP) servers, as a service mesh enforcement component covering all inter-service calls, as a network egress gateway covering all outbound capability invocations regardless of protocol, or as a domain-specific execution boundary. The protocol objects defined herein function identically across all deployment topologies. This document establishes the architectural model, protocol object schemas, and enforcement semantics for the AgentROA framework. Independent This document defines OAuth Actor-Signed Hop Proofs, an optional companion profile for delegated OAuth tokens that conform to the OAuth Actor Profile for Delegation. It introduces the actor_proofs claim, a signed per-hop proof chain in which the actor added at each visible hop signs its own participation and the target binding it authorized for that hop. Proofs are linked into a hash chain, are validated against actor verification keys resolved through pre- established trust, and optionally cross-reference sibling actor receipts. This document also defines a token request parameter for conveying proofs at issuance, and metadata and introspection parameters for advertising and consuming actor-proof support. Grantex Artificial intelligence (AI) agents increasingly take autonomous actions -- submitting forms, initiating payments, and sending communications -- on behalf of human users across third-party services. This document defines the Delegated Agent Authorization Protocol (DAAP), an open, model-neutral, framework-agnostic protocol that specifies: cryptographic agent identity using Decentralized Identifiers (DIDs); a human-consent-based grant authorization flow modelled on OAuth 2.0; a signed JSON Web Token (JWT) grant token format with agent-specific claims; a revocation model with online verification; a hash-chained append-only audit trail; a policy engine for automated authorization decisions; a multi-agent delegation model with cascade revocation; budget controls for spending limits; real- time event streaming; a credential vault for secure secret storage; and external policy backend integration with OPA and Cedar. DAAP fills a gap unaddressed by existing OAuth 2.0 extensions: verifying that a specific human authorized a specific AI agent to perform a specific action, revoking that authorization in real time, and producing a tamper-evident record of what the agent did. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Huawei Huawei This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. W3C European Commission

Test Vectors The key, clock and nonce used below are fixed (iat = 1800000000), so every canonical string, digest and signing input here is byte-reproducible. An implementation that agrees with this document computes exactly these values. The signatures are not reproducible. ECDSA draws a fresh random value for each signature, so signing an identical input again yields a different and equally valid signature. Verify the signatures in these vectors; do not compare them octet-wise against your own output. Backslash and line feed are shown escaped as \\ and \n so the exact octets are unambiguous on the page.

Key Thumbprint (RFC 7638), used as cnf.jkt: The private component is d = Y2j9oKoLsw3p24brNicuYCjBxv0LVUWLHSYc9Wzvy5A. It is published here so that implementers can reproduce signatures; it MUST NOT be used for anything else.

V1: canonical action and adg Action type payment.transfer, parameters: Canonical action string: adg = YlHp3M4JIWFPPZIVAwAmYOBOMfUyb2bjE6ve3AD2iaQ

V2: canonical display and dsp Canonical display string (line feeds shown as \n): The same string as it appears to the user: dsp = uSEgOG9UC1IWGxzBalJv5cIbfxE8kxmoKF25yrRl1fs

V3: escaping A parameter value containing every canonical-action delimiter, demonstrating that escaping prevents a value from impersonating a separator. Canonical action string: adg = 3R0-FrNwSzXzvWmcFyDrQipdaJZmDUULlpX87bXParo

V4: request fingerprint and rqf SHA-256 of the body, hex: Fingerprint pre-image, with <NUL> marking a single 0x00 octet and the trailing 32 octets being the raw body digest above: /v1/transfersorg_acmepayments:write ]]> rqf = 1GL7CIg1JkKGaGfHgdF5_93rVx4FqfjoY0lYZ6xbjQ0

V5: a complete token that verifies Protected header: Payload: Compact serialization: Verified at time 1800000000 against the action of V1 and the request of V4, with the key above enrolled, this token is accepted.

V6: refusal vectors Each vector below alters exactly one thing relative to V5 and is refused. The reasons shown are those an implementation of this document produces. The names are not normative; the fact of refusal is.

R1: action mismatch The token is minted for a different amount than the verifier is about to execute. Compact serialization: Refused: action-mismatch

R2: display mismatch adg binds the executing action, so action binding alone would accept. dsp carries the digest of a different disclosure, which is what the human read. Compact serialization: Refused: display-mismatch

R3: request mismatch Same action, aimed at a different request path. Compact serialization: Refused: rqf-mismatch

R4: request binding absent The rqf claim is omitted entirely while the verifier is pinning a request. The token MUST be refused rather than accepted as action-bound only. Compact serialization: Refused: rqf-missing

R5: expired Verified one second after exp. Compact serialization: Refused: expired

R6: replay The jti has already been recorded by this verifier. Compact serialization: Refused: replay

Acknowledgments The request-fingerprint construction in was shaped by published work on per-request, action-bound authentication for autonomous agents, and by discussion of human-authorization binding on the WIMSE mailing list.