United Kingdom me@aovidi.com

This document specifies LIP-4D, an experimental, transport-independent JSON protocol for expressing and evaluating the intent of autonomous software agents. A LIP-4D exchange binds an authenticated agent to a requested action, purpose, execution context, rationale claims, evidence, time constraints, and an evolution history. A policy enforcement component can challenge the agent for additional evidence and, after evaluation, issue a short-lived intent-bound authorization grant or deny the request. LIP-4D does not replace workload identity, cryptographic authentication, OAuth, or other authorization frameworks. It supplies a structured intent and evidence layer that can be used with those systems. The protocol deliberately excludes private model chain-of-thought and instead carries concise, reviewable claims and verifiable evidence.

Introduction Autonomous agents frequently invoke tools, APIs, models, and other agents. Existing credentials normally identify a workload or convey a set of permissions, but they do not consistently express why a particular action is requested now, under which constraints it is acceptable, what evidence supports it, or how the request evolved from earlier steps. LIP-4D defines a signed intent envelope and a challenge-response authorization dialogue. The name "4D" refers to four groups of authorization context:

• Chronos: time, ordering, validity, and replay boundaries.
• Logos: a concise rationale, policy-relevant claims, and confidence metadata.
• Topos: operational context, trust domain, delegation, and resource scope.
• Physis: revision, mutation, retry, and decay of an intent over time.

An asserted intent is not proof that an actor is trustworthy. A receiver MUST authenticate the sender and evaluate the intent, evidence, and local policy before issuing a grant. LIP-4D is therefore an intent-bound authorization protocol, not an authentication mechanism based solely on natural-language intention. This document specifies version 0.3 of the protocol and is intended for experimentation and interoperability testing.

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. Agent: A software workload that selects or performs actions, potentially using a machine-learning model. Guardian: The policy decision and enforcement component that evaluates LIP-4D messages and issues challenges, grants, denials, or revocations. Resource: A tool, API, model, data object, or agent that is the target of an action. Intent: A structured statement of the action requested by an Agent, its purpose, constraints, and the four-dimensional context used for authorization. Evidence: A verifiable claim, attestation, approval, test result, or other object used by a Guardian to evaluate an Intent. Grant: A short-lived authorization decision bound to a specific Intent digest, Agent key, audience, and set of constraints. Private reasoning: Internal model deliberation, hidden chain-of-thought, prompts, or intermediate inference traces that are not required for protocol interoperability.

Design Goals and Non-Goals LIP-4D has the following goals:

• bind a requested action to purpose, context, evidence, and time;
• support a deterministic challenge-response policy dialogue;
• issue grants that are short-lived, audience-restricted, and non-portable;
• retain an auditable explanation of the authorization decision;
• interoperate with existing workload identity and authorization systems; and
• avoid requiring disclosure of private model reasoning.

LIP-4D does not define a workload identity system, credential provisioning system, policy language, evidence format, or universal trust score. It does not authorize an action merely because a rationale sounds plausible.

Protocol Architecture The protocol has three logical roles:

• The Agent creates and signs an `intent` message.
• The Guardian validates the message and either issues a `challenge`, `grant`, or `denial`.
• After receiving a `grant`, the Agent invokes the Resource while presenting the grant and the accepted Intent digest. The Guardian or Resource validates that the invocation remains within the grant constraints.

A Guardian MAY request one or more rounds of additional evidence. The normal state sequence is: Agent Guardian Resource | intent | | |----------------------------->| | | challenge | | |<-----------------------------| | | attestation | | |----------------------------->| | | grant or denial | | |<-----------------------------| | | invocation + grant + digest | | |------------------------------------------------------------>| | | validation / introspection | | |<---------------------------->| A deployment MAY combine the Guardian and Resource. Authentication and secure transport can be provided by mechanisms such as mutual TLS, HTTP Message Signatures, WIMSE credentials, OAuth client authentication, or another locally approved mechanism.

Message Envelope Every LIP-4D message is a JSON object. Unless a message-type section states otherwise, the following members apply. The JSON data model is defined by . `lip_version`: REQUIRED. The string `0.3` for this specification. `message_type`: REQUIRED. One of `intent`, `challenge`, `attestation`, `grant`, `denial`, `revocation`, or `invocation`. `message_id`: REQUIRED. A globally unique URI. A UUID URN is RECOMMENDED. URI syntax is defined by . `in_reply_to`: REQUIRED for all messages except an initial `intent`. It identifies the preceding message. `issuer`: REQUIRED. A URI identifying the authenticated sender. `audience`: REQUIRED. A URI identifying the intended receiver or protected resource. `issued_at` and `expires_at`: REQUIRED RFC 3339 timestamps. The validity period SHOULD be measured in seconds or minutes. A receiver MUST reject an expired message. Timestamp syntax follows . `nonce`: OPTIONAL in an initial message and REQUIRED when responding to a challenge that supplied a nonce. The nonce MUST be unpredictable and encoded using the base64url alphabet without padding. Base64url encoding is defined by . `intent`: REQUIRED in `intent`, `attestation`, and `invocation` messages. It contains the requested action, resource, purpose, parameters, and constraints. `dimensions`: REQUIRED whenever `intent` is present. It contains the Chronos, Logos, Topos, and Physis objects defined below. `evidence`: OPTIONAL array of evidence descriptors. Evidence values SHOULD be references or compact attestations rather than unbounded data. `requirements`: REQUIRED in a `challenge`. It identifies required evidence, constraints, or approvals. `authorization`: REQUIRED in a `grant`, `denial`, or `revocation`. `proof`: REQUIRED. A detached JWS proof as specified in this document. Unknown members MUST be ignored unless local policy rejects extensions. A sender MUST NOT reuse a member name defined by this document with a different meaning.

The Intent Object The `intent` object contains: `action`: REQUIRED. A case-sensitive operation identifier. Globally reusable identifiers SHOULD use a URI or a reverse-domain name. `resource`: REQUIRED. The URI of the requested Resource. `purpose`: REQUIRED. A concise, policy-relevant purpose code or sentence. It MUST NOT contain private chain-of-thought. `parameters`: OPTIONAL object containing operation parameters that are material to authorization. Secrets MUST NOT be included. `constraints`: OPTIONAL object containing requested limits such as maximum uses, data classifications, monetary limits, rate limits, geographic restrictions, or a human-approval requirement. A Guardian MUST evaluate the action and resource independently of the free-text purpose. A natural-language purpose is an assertion, not authority.

The Four Dimensions

Chronos The `chronos` object describes time and ordering. It MUST contain `not_before`, `not_after`, and `sequence`. It MAY contain `prior_message_ids`, `max_clock_skew_seconds`, and a deadline. A receiver MUST reject an Intent outside its validity interval. A receiver SHOULD maintain a replay cache for at least the validity interval plus permitted clock skew.

Logos The `logos` object describes the policy-relevant rationale without exposing private reasoning. It MUST contain `rationale` and MAY contain:

• `claims`: short statements that can be checked against evidence or policy;
• `confidence`: a number from 0 through 1 representing the sender's self-reported confidence; and
• `policy_hints`: non-authoritative labels that may help route evaluation.

A Guardian MUST NOT treat `confidence` as a trust score. A Guardian MUST NOT require hidden chain-of-thought, raw prompts, model weights, or private deliberation as a condition of interoperability. Evidence SHOULD support material claims.

Topos The `topos` object describes operational and delegation context. It MUST contain `trust_domain` and MAY contain `tenant`, `environment`, `network_zone`, `subject`, `delegation_chain`, and `data_classification`. Context values can be privacy-sensitive. Senders SHOULD disclose only values necessary for the decision.

Physis The `physis` object describes the lifecycle of an Intent. It MUST contain `intent_id` and `revision`. It MAY contain `parent_intent_id`, `mutation_reason`, `retry_count`, and a `decay` policy. When an Agent materially changes an action, resource, purpose, parameter, constraint, or dimension, it MUST increment `revision` and obtain a new grant. A grant for an earlier revision MUST NOT authorize a later revision.

Evidence Each evidence descriptor contains:

• `type`: REQUIRED URI or namespaced identifier;
• `format`: REQUIRED media type or token format;
• exactly one of `value` or `uri`;
• `digest`: RECOMMENDED when `uri` is used; and
• `expires_at`: OPTIONAL expiry time.

A Guardian MUST validate evidence according to the rules of its format and issuer. Merely including an evidence descriptor does not make the evidence valid. Evidence obtained from untrusted content, including model-generated text or retrieved documents, MUST be treated as untrusted until independently validated.

Message Types and Processing

Intent An Agent sends an `intent` message to request authorization. The message MUST contain the full Intent and dimensions. The Guardian MUST authenticate the issuer, validate the proof, check time and replay constraints, and evaluate local policy. The Guardian responds with a `challenge`, `grant`, or `denial`.

Challenge A `challenge` identifies missing evidence or stricter constraints. It MUST include a fresh `nonce` and a `requirements` object. The requirements can include accepted evidence types, required approval, maximum risk, or a narrowed action scope. A challenge MUST NOT request private chain-of-thought. It MAY request a concise explanation, verifiable claim, test result, human approval, remote attestation, or other evidence.

Attestation An `attestation` responds to a challenge. It MUST copy the challenge nonce and include `in_reply_to`. It MUST include the current Intent and dimensions, including any revision made to satisfy the challenge. A Guardian MUST verify that evidence is bound to the current Intent, issuer, audience, and nonce where the evidence format permits that binding.

Grant A `grant` authorizes a specific Intent. Its `authorization` object MUST contain:

• `status` with value `granted`;
• `grant_id`, a globally unique URI;
• `intent_digest`, computed as defined below;
• `expires_at`;
• `audience`;
• `constraints`, including any limits imposed by the Guardian; and
• `confirmation`, identifying the Agent key or credential to which the grant is bound.

A grant MAY carry an OAuth access token, capability token, or an opaque reference in `authorization.credential`. The security and presentation rules of that credential format continue to apply.

Denial A `denial` MUST set `authorization.status` to `denied` and SHOULD include machine-readable `reason_codes`. It MUST NOT reveal sensitive policy internals that would materially assist an attacker.

Revocation A `revocation` invalidates a grant before expiry. It MUST identify the `grant_id`, `intent_digest`, effective time, and reason code. Deployments requiring immediate revocation MUST provide a push, introspection, or equivalent status mechanism; delivery of a standalone message cannot by itself guarantee immediate enforcement.

Invocation An `invocation` binds a resource call to an accepted Intent. It MUST contain the final `intent`, `dimensions`, `authorization.grant_id`, and `authorization.intent_digest`. It MUST present the grant credential using the method required by that credential format. The Resource or Guardian MUST verify the grant signature or introspection result, audience, expiry, confirmation key, constraints, and Intent digest before performing the action.

Intent Digest The Intent digest binds a grant to the final authorization input. The digest input is a JSON object containing exactly these members copied from the accepted message: { "issuer": "https://agent.example", "audience": "https://api.example", "intent": {}, "dimensions": {} } The object is canonicalized using the JSON Canonicalization Scheme (JCS). SHA-256 is applied to the resulting octets. The digest value is encoded as `sha-256:` followed by unpadded base64url. JCS is specified by . A receiver MUST compare digest values using an implementation that does not leak useful timing information.

Message Proof Every message MUST carry a detached JSON Web Signature (JWS) in `proof`. The JWS payload is the JCS canonical representation of the complete message after removing the `proof` member. JWS is specified by . The `proof` object contains: { "type": "jws-detached", "jws": "BASE64URL(PROTECTED)..BASE64URL(SIGNATURE)" } The protected header MUST contain `alg`, `kid`, and `typ`. The `typ` value MUST be `application/lip+json`. The `alg` value `none` MUST NOT be used. Algorithm acceptance and key resolution are deployment policy. Implementations SHOULD prefer algorithms that provide at least 128 bits of security. The proof authenticates the message but does not by itself authorize the action. The key identified by `kid` MUST be validated as belonging to the authenticated issuer using the deployment's workload identity or credential system.

HTTP Binding A LIP-4D HTTP endpoint is configured out of band in this version. The Agent sends an HTTPS POST request with `Content-Type: application/lip+json` and an `Accept` header that includes the same media type. HTTP semantics are defined by . TLS 1.3 SHOULD be used. Implementations MUST validate the server identity and MUST NOT silently continue after certificate validation failure. TLS 1.3 is specified by . Recommended HTTP status mappings are:

• `200` for a `grant`, `denial`, or successful protocol response;
• `202` for a `challenge` requiring a later response;
• `400` for malformed JSON or a schema failure;
• `401` for failed sender or message authentication;
• `403` for a policy denial;
• `409` for replay, state mismatch, or stale revision;
• `422` for a syntactically valid but semantically invalid message; and
• `429` for rate limiting.

The body of any protocol-level response SHOULD be a signed LIP-4D message. HTTP authentication, OAuth, mutual TLS, or HTTP Message Signatures MAY additionally protect the transport request.

Integration with Existing Authorization Systems LIP-4D is designed to complement established systems.

• A WIMSE or SPIFFE-style workload identity can authenticate the Agent and resolve the signing key.
• OAuth can issue and present the grant credential. The LIP-4D object can be conveyed as authorization context, including through Rich Authorization Requests where appropriate. OAuth 2.0 is defined by ; Rich Authorization Requests and Resource Indicators provide related authorization-context mechanisms.
• Sender-constrained OAuth tokens, such as mutual-TLS-bound or DPoP-bound tokens, can implement the confirmation binding. Relevant mechanisms include mutual TLS and DPoP .
• Token introspection can provide grant status and revocation checks for opaque credentials. OAuth token introspection is specified by .

A deployment SHOULD reuse an existing authorization framework rather than inventing a new bearer token. LIP-4D adds the intent, evidence, challenge, and audit semantics.

Example Intent The following example omits a real signature. { "lip_version": "0.3", "message_type": "intent", "message_id": "urn:uuid:018f4c90-7df1-7b4a-92fb-88ab9c730001", "issuer": "spiffe://example.org/agent/profile-assistant", "audience": "https://api.example.org/profile", "issued_at": "2026-07-30T16:00:00Z", "expires_at": "2026-07-30T16:02:00Z", "intent": { "action": "org.example.profile.read", "resource": "https://api.example.org/users/123/profile", "purpose": "Display the user's requested profile", "parameters": { "fields": [ "display_name", "avatar" ] }, "constraints": { "max_uses": 1, "data_classification": [ "public-profile" ] } }, "dimensions": { "chronos": { "not_before": "2026-07-30T16:00:00Z", "not_after": "2026-07-30T16:02:00Z", "sequence": 1 }, "logos": { "rationale": "The authenticated user opened the profile view.", "claims": [ "session-authenticated", "fields-low-risk" ], "confidence": 0.92 }, "topos": { "trust_domain": "example.org", "tenant": "tenant-42", "environment": "production", "subject": "urn:example:user:123" }, "physis": { "intent_id": "urn:uuid:018f4c90-7df1-7b4a-92fb-88ab9c730000", "revision": 1, "retry_count": 0 } }, "evidence": [ { "type": "urn:example:evidence:user-session", "format": "application/jwt", "value": "eyJ..." } ], "proof": { "type": "jws-detached", "jws": "eyJhbGciOiJFZERTQSJ9..c2ln" } }

Versioning and Extensibility The `lip_version` value identifies the protocol version. A receiver that does not support the major semantic version MUST reject the message. This document uses the exact value `0.3`; future documents can define compatible version negotiation. Extensions SHOULD use URI or reverse-domain names for new message fields, action identifiers, evidence types, and reason codes. Extensions MUST NOT weaken signature, replay, audience, or expiry requirements.

Security Considerations

Intent Is Not Authentication An attacker can state a benign purpose. Guardians MUST authenticate issuers and validate evidence. Policy MUST be based on enforceable constraints and trusted signals, not persuasive prose.

Replay and Freshness Short validity intervals, unique message IDs, nonces, sequence values, and replay caches are required. A message accepted once MUST NOT be accepted again when the action is non-idempotent unless the grant explicitly permits multiple uses.

Confused Deputy and Audience Substitution Every message and grant is audience-bound. A Resource MUST reject a grant issued for another audience. Intermediaries MUST NOT rewrite the resource, audience, or Intent after signature verification.

Intent Mutation A grant is valid only for the exact Intent digest and revision. Material changes require a new decision. Implementations MUST compare the final digest at invocation time.

Evidence and Prompt Injection Agent-produced text, retrieved documents, tool descriptions, and model output can contain adversarial instructions. Evidence validators MUST separate data from control instructions and MUST NOT allow untrusted text to alter verification policy.

Credential and Grant Theft Grants SHOULD be sender-constrained and short-lived. Bearer credentials SHOULD be avoided for high-risk actions. Logs MUST redact credential values while retaining grant IDs and Intent digests.

Policy Oracle Risk Challenges and denial reasons can reveal policy. Guardians SHOULD use bounded reason codes and avoid disclosing thresholds or internal rules that enable systematic probing.

Algorithm and Downgrade Attacks The JWS `alg` header MUST be verified against an explicit allow-list. `none` is forbidden. A receiver MUST NOT accept an older or unknown LIP version merely because another layer authenticated the connection.

Human Approval Where policy requires human approval, the approval evidence MUST be bound to the action, resource, constraints, subject, and expiry. A generic approval or prior conversation is insufficient.

Privacy Considerations Intent context can expose user identities, locations, business purpose, relationships, and behavioral history. Senders and Guardians MUST minimize collection and retention. Free-text rationale SHOULD be concise and SHOULD avoid personal data when a code or claim is sufficient. Private chain-of-thought, raw prompts, and unrelated conversation history MUST NOT be required or logged as protocol evidence. Confidence values and rationale text can reveal model behavior and SHOULD be disclosed only when necessary. Cross-domain deployments SHOULD use pairwise or scoped identifiers where possible. Audit logs SHOULD retain digests and decision metadata rather than full evidence values unless a legal or operational requirement justifies retention.

IANA Considerations IANA is requested to register the media type `application/lip+json` in the "Media Types" registry with the following information: Type name: application Subtype name: lip+json Required parameters: none Optional parameters: none Encoding considerations: binary; the representation is UTF-8 JSON Security considerations: See the Security Considerations section of this document. Interoperability considerations: Implementations must support the message envelope and version rules in this document. The representation uses JSON and JCS canonicalization for signatures and digests. Published specification: this document Applications that use this media type: autonomous agents, policy decision points, authorization servers, API gateways, and protected resources Fragment identifier considerations: none Additional information:

• Deprecated alias names for this type: none
• Magic number(s): none
• File extension(s): `.lip.json`
• Macintosh file type code(s): none

Person and email address to contact for further information: Angelo Ovidi, me@aovidi.com Intended usage: COMMON Restrictions on usage: none Author: Angelo Ovidi Change controller: IETF

Normative References Informative References

Acknowledgments The initial LIP-4D concept and version 0.2 repository were created by Angelo Ovidi. This version restructures that work as an interoperable intent-bound authorization protocol and aligns it with established Internet security mechanisms.

Change Log draft-ovidi-lip-4d-00: Initial Internet-Draft version.