Network Working Group A. Thallapelly Internet-Draft OmniArx Intended status: Standards Track 21 July 2026 Expires: 22 January 2027 OASNT: Attested Action Authorization Tokens draft-thallapelly-oasnt-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Thallapelly Expires 22 January 2027 [Page 1] Internet-Draft OASNT July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Relationship to Other Work . . . . . . . . . . . . . . . . . 4 2.1. Human authorization receipts . . . . . . . . . . . . . . 4 2.2. Transaction confirmation in WebAuthn . . . . . . . . . . 5 2.3. Agent identity, delegation and policy . . . . . . . . . . 5 2.4. Regulatory requirements . . . . . . . . . . . . . . . . . 6 3. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Token Format . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Signature . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Key ordering . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Canonical action . . . . . . . . . . . . . . . . . . . . 9 6.3. Canonical display . . . . . . . . . . . . . . . . . . . . 10 6.4. Request fingerprint . . . . . . . . . . . . . . . . . . . 10 7. Verification Procedure . . . . . . . . . . . . . . . . . . . 11 7.1. Reserve and commit . . . . . . . . . . . . . . . . . . . 12 7.2. Reporting refusal reasons . . . . . . . . . . . . . . . . 12 8. Enrollment and Key Attestation . . . . . . . . . . . . . . . 13 8.1. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Platform attestation . . . . . . . . . . . . . . . . . . 13 8.3. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.4. Deployment without attestation . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9.1. Signature algorithm . . . . . . . . . . . . . . . . . . . 14 9.2. The display trust boundary . . . . . . . . . . . . . . . 14 9.3. Device-asserted integrity . . . . . . . . . . . . . . . . 15 9.4. Canonicalization ambiguity . . . . . . . . . . . . . . . 15 9.5. Verifier-side recomputation . . . . . . . . . . . . . . . 15 9.6. Compromise of the enrollment path . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . 15 10.2. On the choice of adg . . . . . . . . . . . . . . . . . . 16 10.3. Media Types . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Thallapelly Expires 22 January 2027 [Page 2] Internet-Draft OASNT July 2026 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 20 A.1. Key . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 A.2. V1: canonical action and adg . . . . . . . . . . . . . . 21 A.3. V2: canonical display and dsp . . . . . . . . . . . . . . 21 A.4. V3: escaping . . . . . . . . . . . . . . . . . . . . . . 21 A.5. V4: request fingerprint and rqf . . . . . . . . . . . . . 22 A.6. V5: a complete token that verifies . . . . . . . . . . . 22 A.7. V6: refusal vectors . . . . . . . . . . . . . . . . . . . 23 A.7.1. R1: action mismatch . . . . . . . . . . . . . . . . . 23 A.7.2. R2: display mismatch . . . . . . . . . . . . . . . . 23 A.7.3. R3: request mismatch . . . . . . . . . . . . . . . . 24 A.7.4. R4: request binding absent . . . . . . . . . . . . . 24 A.7.5. R5: expired . . . . . . . . . . . . . . . . . . . . . 25 A.7.6. R6: replay . . . . . . . . . . . . . . . . . . . . . 25 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 1. 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. Thallapelly Expires 22 January 2027 [Page 3] Internet-Draft OASNT July 2026 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. Section 7 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 [RFC9334], can consume an OASNT token as the human-authorization evidence at the root of a chain they otherwise manage. 2. 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. 2.1. Human authorization receipts [I-D.schrock-ep-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. [I-D.schrock-ep-action-evidence-graph] composes such receipts into a portable evidence graph with a replayable admissibility verdict, and [I-D.rampalli-cross-org-delegation-mapping] 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. Thallapelly Expires 22 January 2027 [Page 4] Internet-Draft OASNT July 2026 This document specifies the complementary piece for the case where that client is a mobile device. Section 6.3 defines a digest over the rendered octets and Section 7 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 Section 2.2. 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. 2.2. Transaction confirmation in WebAuthn The txAuthSimple and txAuthGeneric extensions to [WEBAUTHN] were defined to carry a prompt for display on the authenticator, which is the same property Section 6.3 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. Section 9.2 states the limits of that assumption. 2.3. Agent identity, delegation and policy [I-D.ietf-wimse-arch] and [I-D.ni-wimse-ai-agent-identity] establish workload identity for non-human callers. [I-D.mishra-oauth-agent-grants] and [RFC8693] address delegated authorization and token exchange. [I-D.mcguinness-oauth-actor-proofs] adds per-hop actor-signed evidence. [I-D.nivalto-agentroa-route-authorization] 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. Thallapelly Expires 22 January 2027 [Page 5] Internet-Draft OASNT July 2026 2.4. Regulatory requirements Strong customer authentication under [PSD2-RTS] 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. 3. 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 [RFC2119] [RFC8174] 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. 4. 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. Section 8 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. Section 7 specifies this. A typical exchange: Thallapelly Expires 22 January 2027 [Page 6] Internet-Draft OASNT July 2026 verifier minter (device) enrollment service | | | | |---- attested key ------->| | |<--- 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. Section 9.2 states the limits of that assumption. 5. Token Format An OASNT token is a JWS [RFC7515] in compact serialization. 5.1. JOSE Header The protected header MUST consist of exactly the members alg and typ, with the values shown: {"alg":"ES256","typ":"oasnt+jwt"} 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 Section 9.1. Thallapelly Expires 22 January 2027 [Page 7] Internet-Draft OASNT July 2026 5.2. 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 [RFC7515]. A verifier MUST reject a signature whose decoded length is not exactly 64 octets. 5.3. Claims The JWS payload is a JSON object [RFC8259] containing the following members. All digest-valued claims are base64url [RFC4648] encoded without padding, over a SHA-256 [RFC6234] digest. +=======+========+==========+======================================+ | Claim | Type | Presence | Binds | +=======+========+==========+======================================+ | sub | string | REQUIRED | the subject the token was issued for | +-------+--------+----------+--------------------------------------+ | adg | string | REQUIRED | the action to be executed | | | | | (Section 6.2) | +-------+--------+----------+--------------------------------------+ | dsp | string | REQUIRED | the disclosure the human read | | | | | (Section 6.3) | +-------+--------+----------+--------------------------------------+ | rqf | string | OPTIONAL | one concrete request (Section 6.4) | +-------+--------+----------+--------------------------------------+ | 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 | +-------+--------+----------+--------------------------------------+ Table 1 cnf.jkt is the JWK thumbprint [RFC7638] 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 Section 9.3. Thallapelly Expires 22 January 2027 [Page 8] Internet-Draft OASNT July 2026 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: Section 7 requires a verifier to distinguish "not bound to a request" from "bound to a request that does not match". 6. 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. 6.1. 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. 6.2. Canonical action The canonical action is: escape(type) "|" escape(k1) "=" escape(v1) "&" escape(k2) "=" escape(v2) ... (shown wrapped for width; the canonical string contains no line breaks) where parameters are ordered per Section 6.1, 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. Thallapelly Expires 22 January 2027 [Page 9] Internet-Draft OASNT July 2026 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. 6.3. Canonical display The canonical display is the disclosure text, constructed as the type followed, for each parameter in the order of Section 6.1, by a line feed (0x0A), the parameter name, a colon, a space, and the parameter value: escape(type) LF escape(k1) ": " escape(v1) LF escape(k2) ": " escape(v2) ... (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 Section 9.2 for the boundary of that assertion. 6.4. Request fingerprint The request fingerprint binds a token to one concrete request. It is the base64url encoding of the SHA-256 digest of: method 0x00 path 0x00 org-id 0x00 scope 0x00 body-digest 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. Thallapelly Expires 22 January 2027 [Page 10] Internet-Draft OASNT July 2026 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. 7. 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 Section 7.2. 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 (Section 8). 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. Thallapelly Expires 22 January 2027 [Page 11] Internet-Draft OASNT July 2026 9. *Action binding.* adg MUST equal the digest recomputed per Section 6.2 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 Section 6.3 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 Section 6.4 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. 7.1. 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. 7.2. 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. Thallapelly Expires 22 January 2027 [Page 12] Internet-Draft OASNT July 2026 8. 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. 8.1. 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. 8.2. 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. Thallapelly Expires 22 January 2027 [Page 13] Internet-Draft OASNT July 2026 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. 8.3. Storage On success the service records the subject, the public key, and its thumbprint [RFC7638]. Verifiers look up keys by thumbprint alone. 8.4. 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. 9. Security Considerations 9.1. Signature algorithm ES256 is mandated rather than negotiated. The signing key is required to be hardware-bound (Section 8), 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. 9.2. 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. Thallapelly Expires 22 January 2027 [Page 14] Internet-Draft OASNT July 2026 9.3. 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 (Section 8) as the stronger signal. 9.4. Canonicalization ambiguity Both hashed encodings are injective over their inputs only because of the escaping rules in Section 6. 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 Section 6.1 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. 9.5. 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. 9.6. 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. 10. IANA Considerations 10.1. JSON Web Token Claims IANA is requested to register the following in the "JSON Web Token Claims" registry established by [RFC7519]. Thallapelly Expires 22 January 2027 [Page 15] Internet-Draft OASNT July 2026 +============+================+===================+================+ | Claim Name | Description | Change Controller | Reference | +============+================+===================+================+ | adg | Action digest | IETF | Section 6.2 of | | | | | this document | +------------+----------------+-------------------+----------------+ | dsp | Disclosure | IETF | Section 6.3 of | | | digest | | this document | +------------+----------------+-------------------+----------------+ | rqf | Request | IETF | Section 6.4 of | | | fingerprint | | this document | +------------+----------------+-------------------+----------------+ | int | Device runtime | IETF | Section 5.3 of | | | integrity | | this document | +------------+----------------+-------------------+----------------+ Table 2 None of these four names appears in the registry at the time of writing. 10.2. On the choice of adg The action digest is named adg, for action digest, rather than the more obvious act. act is unavailable: [RFC8693] 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 [RFC8693] 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 Section 7: an absent top-level claim is unambiguous in a way that an absent member of a present object is not. 10.3. Media Types IANA is requested to register the following in the "Media Types" registry. Thallapelly Expires 22 January 2027 [Page 16] Internet-Draft OASNT July 2026 +=========================+========================================+ | 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 | N/A | | considerations | | +-------------------------+----------------------------------------+ | Published specification | This document | +-------------------------+----------------------------------------+ | Applications that use | Applications requiring evidence that a | | this media type | human authorized a specific action | +-------------------------+----------------------------------------+ | Change controller | IETF | +-------------------------+----------------------------------------+ Table 3 The typ header parameter value oasnt+jwt is the subtype of this media type, following the convention [RFC9068] establishes with at+jwt. 11. References 11.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, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . Thallapelly Expires 22 January 2027 [Page 17] Internet-Draft OASNT July 2026 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 11.2. Informative References [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.mcguinness-oauth-actor-proofs] McGuinness, K., "OAuth Actor-Signed Hop Proofs", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor- proofs-00, 4 July 2026, . Thallapelly Expires 22 January 2027 [Page 18] Internet-Draft OASNT July 2026 [I-D.mishra-oauth-agent-grants] Kumar, S., "Delegated Agent Authorization Protocol (DAAP)", Work in Progress, Internet-Draft, draft-mishra- oauth-agent-grants-01, 2 March 2026, . [I-D.ni-wimse-ai-agent-identity] Yuan, N. and P. C. Liu, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse- ai-agent-identity-02, 28 February 2026, . [I-D.nivalto-agentroa-route-authorization] Michalak, J., "Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions", Work in Progress, Internet-Draft, draft-nivalto-agentroa-route-authorization-01, 15 April 2026, . [I-D.rampalli-cross-org-delegation-mapping] Karthik, R., "A Layered Requirements Mapping for Cross- Organization Agent Delegation", Work in Progress, Internet-Draft, draft-rampalli-cross-org-delegation- mapping-05, 6 July 2026, . [I-D.schrock-ep-action-evidence-graph] Schrock, I., "Action Evidence Graphs and Evidence Policy Replay for High-Risk Agent Actions (EP-AEG)", Work in Progress, Internet-Draft, draft-schrock-ep-action- evidence-graph-00, 3 July 2026, . [I-D.schrock-ep-authorization-receipts] Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock- ep-authorization-receipts-07, 19 July 2026, . Thallapelly Expires 22 January 2027 [Page 19] Internet-Draft OASNT July 2026 [PSD2-RTS] European Commission, "Commission Delegated Regulation (EU) 2018/389, regulatory technical standards for strong customer authentication and common and secure open standards of communication", 2018, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [WEBAUTHN] W3C, "Web Authentication: An API for accessing Public Key Credentials", 2026, . Appendix A. 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. A.1. Key { "kty": "EC", "crv": "P-256", "x": "P7Vp3OZi4XYii2VHo4T08zkjKrKhCt-gY-oAATkXaao", "y": "QNEaWqPG2EI5-2AdT8oX-S4odj8TH9wj_JW2I2ILBoc" } Thallapelly Expires 22 January 2027 [Page 20] Internet-Draft OASNT July 2026 Thumbprint (RFC 7638), used as cnf.jkt: xcDbc2-MsRIENQynAYGtJ0Vc0xPTBdfj_1iAeI9MMFo The private component is d = Y2j9oKoLsw3p24brNicuYCjBxv0LVUWLHSYc9Wzvy5A. It is published here so that implementers can reproduce signatures; it MUST NOT be used for anything else. A.2. V1: canonical action and adg Action type payment.transfer, parameters: { "amount": "100.00", "payee": "acct_9" } Canonical action string: payment.transfer|amount=100.00&payee=acct_9 adg = YlHp3M4JIWFPPZIVAwAmYOBOMfUyb2bjE6ve3AD2iaQ A.3. V2: canonical display and dsp Canonical display string (line feeds shown as \n): payment.transfer\namount: 100.00\npayee: acct_9 The same string as it appears to the user: payment.transfer amount: 100.00 payee: acct_9 dsp = uSEgOG9UC1IWGxzBalJv5cIbfxE8kxmoKF25yrRl1fs A.4. V3: escaping A parameter value containing every canonical-action delimiter, demonstrating that escaping prevents a value from impersonating a separator. { "note": "a=b&c|d\\e" } Thallapelly Expires 22 January 2027 [Page 21] Internet-Draft OASNT July 2026 Canonical action string: payment.transfer|note=a\\=b\\&c\\|d\\\\e adg = 3R0-FrNwSzXzvWmcFyDrQipdaJZmDUULlpX87bXParo A.5. V4: request fingerprint and rqf { "method": "POST", "path": "/v1/transfers", "orgId": "org_acme", "scope": "payments:write", "body": "{\"amount\":\"100.00\",\"payee\":\"acct_9\"}" } SHA-256 of the body, hex: 05be0ab936cd56cf971cc8b57f7132a690d4ed3bf63b37ac3cb81d6e289f847a Fingerprint pre-image, with marking a single 0x00 octet and the trailing 32 octets being the raw body digest above: POST/v1/transfersorg_acmepayments:write rqf = 1GL7CIg1JkKGaGfHgdF5_93rVx4FqfjoY0lYZ6xbjQ0 A.6. V5: a complete token that verifies Protected header: {"alg":"ES256","typ":"oasnt+jwt"} Payload: { "sub": "agent-1", "adg": "YlHp3M4JIWFPPZIVAwAmYOBOMfUyb2bjE6ve3AD2iaQ", "dsp": "uSEgOG9UC1IWGxzBalJv5cIbfxE8kxmoKF25yrRl1fs", "rqf": "1GL7CIg1JkKGaGfHgdF5_93rVx4FqfjoY0lYZ6xbjQ0", "int": "clean", "jti": "0123456789abcdef0123456789abcdef", "iat": 1800000000, "exp": 1800000060, "cnf": { "jkt": "xcDbc2-MsRIENQynAYGtJ0Vc0xPTBdfj_1iAeI9MMFo" } } Thallapelly Expires 22 January 2027 [Page 22] Internet-Draft OASNT July 2026 Compact serialization: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJycWYiOiIxR0w3Q0lnMUprS0dhR2ZIZ2RGNV85M3JWeDRGcWZ qb1kwbFlaNnhialEwIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.1rS6k1Yz9ZsYWpk51vTv0GDJX4VJ9vp3Qb9v 4ZNG1VjQQwvVvUpUjNao7ZA0hxmBqEOHPLv8NY5C_Jqjl-SJzA Verified at time 1800000000 against the action of V1 and the request of V4, with the key above enrolled, this token is accepted. A.7. 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. A.7.1. R1: action mismatch The token is minted for a different amount than the verifier is about to execute. Compact serialization: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiZHNNUHRxVkJHYjg5MHNfWEVNUDZ3XzZ6QVg2a1lEQ0JqYlo5Y3N HYkVYTSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJycWYiOiIxR0w3Q0lnMUprS0dhR2ZIZ2RGNV85M3JWeDRGcWZ qb1kwbFlaNnhialEwIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.jd0B7NW38g3hBK0YceD2eGRqgd0ApCm6eU_8 QlouotpXwLtOx9H9EB3bq8Dd1XJUybHr2Bheqwj_G_Pt2LPBLg Refused: action-mismatch A.7.2. 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: Thallapelly Expires 22 January 2027 [Page 23] Internet-Draft OASNT July 2026 eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6Ilg0OEc4THhNRUZwWlR3NjduWUw5dEh0OW9SSDV5YXI5RVR 3RVNkaWtZT1UiLCJycWYiOiIxR0w3Q0lnMUprS0dhR2ZIZ2RGNV85M3JWeDRGcWZ qb1kwbFlaNnhialEwIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.ybY-_yQxFfEoqxvXdRkBnhnNxLup39qmHv6T aznUIoHKt3RTmeuIDc8ebQqMsL4dbIhFGgdI3Og-2GEf0HuVmQ Refused: display-mismatch A.7.3. R3: request mismatch Same action, aimed at a different request path. Compact serialization: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJycWYiOiJWbDZfTV90RUJ3RXBOcExNbFo4WENDM0M3dHRCYWF pbElEWjZPWllEZnhJIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.ULJRBLA8zNugzy10VkRcIyh3GrL2naYG9mD4 LMChGuwxg1dYhAHHT1NEHIYvhEASJrX-sFs0hjk-pQVWdMG_Mw Refused: rqf-mismatch A.7.4. 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: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJpbnQiOiJjbGVhbiIsImp0aSI6IjAxMjM0NTY3ODlhYmNkZWY wMTIzNDU2Nzg5YWJjZGVmIiwiaWF0IjoxODAwMDAwMDAwLCJleHAiOjE4MDAwMDA wNjAsImNuZiI6eyJqa3QiOiJ4Y0RiYzItTXNSSUVOUXluQVlHdEowVmMweFBUQmR mal8xaUFlSTlNTUZvIn19.Cf08Diz2lvF-jncola2wVEwf40xC-lxnAMw6SjoewE ekr-s0q_p1pV98VrNzgZ1Eb7MhzojNGmIRBWT65DOLqw Refused: rqf-missing Thallapelly Expires 22 January 2027 [Page 24] Internet-Draft OASNT July 2026 A.7.5. R5: expired Verified one second after exp. Compact serialization: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJycWYiOiIxR0w3Q0lnMUprS0dhR2ZIZ2RGNV85M3JWeDRGcWZ qb1kwbFlaNnhialEwIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.5WJUcmpcgNE3GrVIMFIFxcyla40xvxn6tdUE prKYJvEGIXy_lCPu6xS0MM7Nz6bJbeZCysc1M3_wPzeZdZ5zTA Refused: expired A.7.6. R6: replay The jti has already been recorded by this verifier. Compact serialization: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hc250K2p3dCJ9.eyJzdWIiOiJhZ2VudC0 xIiwiYWRnIjoiWWxIcDNNNEpJV0ZQUFpJVkF3QW1ZT0JPTWZVeWIyYmpFNnZlM0F EMmlhUSIsImRzcCI6InVTRWdPRzlVQzFJV0d4ekJhbEp2NWNJYmZ4RThreG1vS0Y yNXlyUmwxZnMiLCJycWYiOiIxR0w3Q0lnMUprS0dhR2ZIZ2RGNV85M3JWeDRGcWZ qb1kwbFlaNnhialEwIiwiaW50IjoiY2xlYW4iLCJqdGkiOiIwMTIzNDU2Nzg5YWJ jZGVmMDEyMzQ1Njc4OWFiY2RlZiIsImlhdCI6MTgwMDAwMDAwMCwiZXhwIjoxODA wMDAwMDYwLCJjbmYiOnsiamt0IjoieGNEYmMyLU1zUklFTlF5bkFZR3RKMFZjMHh QVEJkZmpfMWlBZUk5TU1GbyJ9fQ.oEHHulmYbnSkZEyh8MYr4N_Qim6bxJL2JtB1 6V1CarsOf12wx77w_krvPz9CWajNoXrqUyTWz8WKplhaHi4xPw Refused: replay Acknowledgments The request-fingerprint construction in Section 6.4 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. Author's Address Arun Thallapelly OmniArx Email: arun@advitlabs.com Thallapelly Expires 22 January 2027 [Page 25]