]> 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.

Executor-side processing models defines an executor-side processing model for consequential agent actions: native verification of each artifact, matching against a Canonical Action Identifier, satisfaction of an authorization evidence chain, atomic consumption of one-time authority, and closed effect outcomes. It deliberately defines no token format, and the artifacts it consumes retain their own semantics and verifiers. An OASNT token is designed to be consumed by such a model as a natively verified, attested per-action artifact, and the boundary between the two layers is clean. The token is independently verifiable: the verifier recomputes adg from its own representation of the action (), so the token means the same thing wherever it is evaluated, and a canonical action identifier can be derived from that same recomputation rather than from any value the token carries. Where a concrete request is authorized, rqf supplies the admissibility condition, and its absence is a refusal rather than a downgrade. Single use of jti is token-local (); coordinating consumption of authority across executors or trust domains is an executor-side concern, and a processing model of this kind is the natural place for it. A profile of this document is planned to fix the derivation of a canonical action identifier from adg, together with the semantics of the named-human binding, so that every executor checks one derivation rather than each integration defining its own.

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 ()
asl	string	OPTIONAL	assurance level of the approval ()
int	string	REQUIRED	result of a device runtime integrity assessment 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".

Assurance level asl conveys the assurance level of the approval that produced the token. Its value MUST be a string registered in the "OASNT Assurance Levels" registry (). The claim is OPTIONAL, and this document defines only what it means and how a verifier derives its effective value. Assurance floors, the age beyond which an assurance statement is no longer accepted, and the refusals that apply when either is not met are relying-party policy and are defined in . A threshold is not a property of the token.

Effective level asl is asserted by the device. Enrollment () separately establishes a ceiling: the strongest level the enrolled key's hardware and boot state can support. Where the two disagree, the weaker governs. A verifier deriving an effective level MUST take the lesser of the level named by asl and the ceiling recorded at enrollment for the key that verified the signature, and MUST evaluate any assurance requirement against that lesser value rather than against the claim. An over-claim therefore buys nothing. A token naming attested-display against a platform-key ceiling has an effective level of platform-key, and a requirement for attested-display still refuses it. A verifier SHOULD report the over-claim separately from the outcome. A minter claiming more than its hardware supports is a real signal, and it must remain visible once it has stopped being decisive. The lesser value is taken rather than the token being refused outright, because the two conditions are different findings. Refusing every over-claim conflates "this device is misreporting its tier" with "this device lacks the assurance this action requires", and it makes correct tiering unobservable: a device whose key properties genuinely support the stronger level, but whose boot state caps its ceiling below that, would be refused for an action the ceiling in fact satisfies.

Unrecognized and absent levels A verifier that does not recognize the value of asl MUST treat the token as carrying no assurance statement. It MUST NOT infer a level, and MUST NOT treat an unrecognized value as equivalent to the weakest registered one. To a relying party with an assurance requirement, an absent asl and an unrecognized asl are the same condition: neither can satisfy the requirement, and both refuse. They are distinguished in what is reported, not in what is decided. A relying party with no assurance requirement evaluates neither. This is deliberately stricter than treating an unknown level as the weakest registered one. The weakest registered level is a statement about an approval; an unrecognized string is the absence of any statement this verifier can evaluate, and a verifier that substitutes the former for the latter has manufactured evidence it does not have. The distinction is easy to lose because a weakest tier does exist, and defaulting to it is the right answer for a different question. Where enrollment recorded no assurance for a key, the ceiling of is the weakest registered level, because a ceiling is a bound this verifier derives and it must bind something. The claim is not a bound the verifier derives; it is an assertion the device either made or did not. Absent attestation at enrollment is a third case again, and refuses it rather than deriving any ceiling at all. Evidence that cannot be obtained is not weak evidence.

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. A minter SHOULD set exp no more than 120 seconds after iat. A verifier MUST additionally refuse a token whose exp exceeds its iat by more than a locally configured maximum, rather than accepting whatever interval the token declares. See for why this bound is the verifier's to set and not the minter's.
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 13 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. The seen-jti set is scoped to the verifier deployment that maintains it. This document does not define coordination of consumption across verifiers or trust domains; where one authorization must be consumed exactly once across several systems, that coordination belongs to the executor layer ().

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. The two claims are complementary and each is weaker alone: dsp commits to the octets that were shown, and int speaks to the integrity of the surface that showed them. A relying party evaluating a disclosure binding SHOULD consider both. Binding the rendered disclosure is a stronger property than requiring one. A specification can mandate that an approver be shown a faithful rendering, but unless a digest of the rendered octets is carried in the signature, a relying party cannot afterward confirm the requirement was met; it can only assume it. dsp is that digest, which makes the requirement verifiable rather than assumed. This is the property that separates binding what the human saw from merely requiring that they be shown it. 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.

The interval between approval and execution Approval and execution are separate events, and a token that was correct at the first remains verifiable at the second. Every check in is a check on the token and on the action the verifier is about to execute. None of them is a check on the world. That is a deliberate scope boundary. OASNT binds intent, not state. The canonical display () is a deterministic function of the action: its type and its parameters, and nothing else. There is no free-text member and no context member in which a minter, a broker or an application could place a narrative assertion about the world. A disclosure therefore states what is about to be done, which does not cease to be true while the token is in flight. One case escapes that argument, and implementers should be warned of it. A deployment may place in an action parameter a value that is a snapshot of mutable state: an account balance, an exchange rate, an eligibility flag. It is then part of the disclosure the human read, and is bound by adg and dsp like any other parameter. But step 9 requires the verifier to recompute the digest from its own representation of the action rather than from a fresh reading of the underlying state, so a value that has since changed still matches exactly and every check passes. The binding is faithful and the fact is stale. A digest match is evidence about what was displayed and approved. It is not evidence that the displayed value is still correct. A relying party MUST NOT treat a verified token as a substitute for the preconditions the executing system would otherwise enforce, and a system whose correctness depends on a value being current MUST revalidate that value at execution. This document defines no mechanism for carrying such a condition in the token. The width of the interval is therefore a security parameter, which is why step 6 places its upper bound with the verifier. exp is chosen by the minter, and the minter runs on the user's device, which is the component this document trusts least (). A verifier that accepts whatever interval a token declares has delegated the width of its own exposure to that component. A verifier that imposes its own ceiling has not. This document defines no revocation mechanism, which is deliberate rather than missing. A single-use token with a short and verifier-bounded lifetime, whose nonce is recorded only on acceptance (), reaches the same place as revocation for this class of credential without placing a status service on the execution path.

Device-asserted integrity int conveys the result of a runtime integrity assessment performed on the device: a measurement of the execution environment, reduced to one of clean, compromised, or unknown. It is asserted by software on the device and is not a proof. A device whose runtime is fully compromised may defeat the assessment and assert clean. Within that limit, the weight a relying party can place on int depends on the assessment that produced it, and a relying party is entitled to distinguish the two. An int value backed by a runtime integrity assessment that measures the execution environment and can be updated as new evasion techniques appear is a materially different input from a bare self-asserted flag with no measurement behind it. The former raises the cost and skill required to forge clean and records an auditable verdict; neither makes int a guarantee. This distinction is why int carries an assessment result rather than a boolean. Relying parties SHOULD treat int as one input to a risk decision rather than as a guarantee, SHOULD prefer platform attestation () as the stronger signal for admitting a key, and MAY require, as a matter of local policy, that int be backed by a specified class of runtime assessment. A relying party that treats int as dispositive on its own has misplaced the trust boundary.

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
asl	Approval assurance level	IETF	of this document
int	Device runtime integrity	IETF	of this document

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

OASNT Assurance Levels IANA is requested to create a new registry, "OASNT Assurance Levels", within a new "OASNT" registry group. The registration policy is Specification Required (). Each entry has four fields.

• Value. The string as it appears in the asl claim. Values are case-sensitive and match [a-z][a-z0-9-]*.
• Rank. A non-negative integer. Levels are compared by rank and a larger rank is stronger. Ranks are unique and need not be contiguous.
• Description. What the level asserts about the approval.
• Reference. The specification defining the level.

Initial contents:

Value	Rank	Description	Reference
software	10	The approval was collected by software, with no hardware-backed statement about the signing key or the display path	of this document
platform-key	20	The signing key is hardware-bound and the platform attests to it. No statement is made about the display path	of this document
attested-display	30	As platform-key, and the platform additionally attests to the integrity of the path that presented the disclosure	of this document

The initial ranks are spaced so that a level may later be registered between two existing ones without renumbering. Guidance for the designated expert:

• A registration MUST state a rank and justify it against every existing entry. A level that cannot be placed in this ordering does not belong in this registry. It is a different claim and should be registered as one.
• A registration MUST state what the level asserts about the approval. Vendor names, product names and platform names are not assurance levels; the level names the property established, not the thing that established it.
• A registered rank MUST NOT be changed after registration. Deployments compare against it, and a rank that moves silently changes the meaning of every policy expressed in terms of it. A level whose meaning changes requires a new value.
• The expert SHOULD reject a registration whose description could be satisfied without the level below it also being satisfied, because the ordering would then not be an ordering.

A total order is deliberate rather than incidental. requires a verifier to refuse an assurance requirement it cannot evaluate, which is only fail-closed if "stronger than" is decidable from the registry alone. The cost is that genuinely incomparable properties cannot be expressed here, which is the reason the first item of expert guidance above sends them elsewhere.

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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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 OmniArx This document profiles the enforcement of OASNT tokens at the point of execution. It defines the OASNT-Token HTTP field, the rules by which an enforcement point derives the observed request from the octets it will itself forward, a verification procedure for relying parties that hold no request-to-action mapping, uniform refusal behavior, and the set of refusals a conforming enforcement point is required to produce. An enforcement point conforming to this profile makes a human approval a precondition of execution for the requests it fronts, without any change to the protected service. 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, shared authorization instance, per-signoff 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. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. 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. EMILIA Protocol, Inc. Consequential agent actions can cross identity, transport, authorization, policy, and execution systems. Each system can produce a valid artifact while the executor still lacks a safe rule for joining the artifacts to the exact effect, consuming one-time authority, and handling an uncertain outcome. This document defines the Action Evidence Boundary (AEB), an executor-side processing model for that lifecycle. AEB requires native artifact verification, Canonical Action Identifier (CAID) matching, Authorization Evidence Chain (AEC) satisfaction, a separate local authorization decision, durable atomic consumption or reservation, invocation, closed effect outcomes, and authenticated reconciliation. It defines no receipt or token format, no policy language, no universal evidence taxonomy, and no new registry. Native workload credentials, message signatures, attested per-action tokens, permit records, authorization receipts, and status mechanisms retain their own semantics and verifiers. 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

Change Log RFC Editor: please remove this section before publication. Since -01:

• New defines the asl claim, the derivation of an effective level as the lesser of the claim and the enrollment ceiling, and the requirement that an unrecognized level be treated as no statement rather than as the weakest registered one. New creates the "OASNT Assurance Levels" registry that the claim's values are drawn from, under Specification Required, with a rank field so that "stronger than" is decidable from the registry alone. Thresholds are deliberately not defined here; assurance floors and staleness are relying-party policy and belong to . -01 carried no assurance claim at all, so no profile could refuse on one normatively.
• New states the scope boundary between approval and execution. It records that the canonical display is a deterministic function of the action and carries no free-text member, so a disclosure cannot assert a fact about the world unless that fact is an action parameter; that a parameter holding a snapshot of mutable state is bound but never revalidated, because step 9 recomputes from the verifier's representation of the action rather than from live state; and that a relying party MUST NOT read a digest match as a freshness check. As published, -01 warned of none of this. Raised in executor-implementer review.
• step 6 now bounds the token lifetime. A minter SHOULD set exp no more than 120 seconds after iat, and a verifier MUST refuse a token declaring a longer interval than its own configured maximum. -01 required and checked exp but bounded it nowhere, so the abstract's "short-lived" had nothing normative behind it and the width of the approval window was left to the least trusted component in the system.

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. Iman Schrock asked what happens to a token whose disclosure was true at approval and is no longer true at execution. The scope boundary in , the warning about parameters carrying mutable state, and the lifetime bound in step 6 are all answers to that question.