LIP-4D: An Intent Context and Authorization Dialogue Protocol for Autonomous Agents
draft-ovidi-lip-4d-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Angelo Ovidi | ||
| Last updated | 2026-07-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ovidi-lip-4d-00
Network Working Group A. Ovidi
Internet-Draft 30 July 2026
Intended status: Experimental
Expires: 31 January 2027
LIP-4D: An Intent Context and Authorization Dialogue Protocol for
Autonomous Agents
draft-ovidi-lip-4d-00
Abstract
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.
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 31 January 2027.
Ovidi Expires 31 January 2027 [Page 1]
Internet-Draft LIP-4D July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Design Goals and Non-Goals . . . . . . . . . . . . . . . . . 4
4. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 5
5. Message Envelope . . . . . . . . . . . . . . . . . . . . . . 5
6. The Intent Object . . . . . . . . . . . . . . . . . . . . . . 7
7. The Four Dimensions . . . . . . . . . . . . . . . . . . . . . 7
7.1. Chronos . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. Logos . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Topos . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.4. Physis . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Message Types and Processing . . . . . . . . . . . . . . . . 9
9.1. Intent . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.2. Challenge . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3. Attestation . . . . . . . . . . . . . . . . . . . . . . . 9
9.4. Grant . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.5. Denial . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.6. Revocation . . . . . . . . . . . . . . . . . . . . . . . 10
9.7. Invocation . . . . . . . . . . . . . . . . . . . . . . . 10
10. Intent Digest . . . . . . . . . . . . . . . . . . . . . . . . 10
11. Message Proof . . . . . . . . . . . . . . . . . . . . . . . . 11
12. HTTP Binding . . . . . . . . . . . . . . . . . . . . . . . . 11
13. Integration with Existing Authorization Systems . . . . . . . 12
14. Example Intent . . . . . . . . . . . . . . . . . . . . . . . 13
15. Versioning and Extensibility . . . . . . . . . . . . . . . . 14
16. Security Considerations . . . . . . . . . . . . . . . . . . . 14
16.1. Intent Is Not Authentication . . . . . . . . . . . . . . 14
16.2. Replay and Freshness . . . . . . . . . . . . . . . . . . 15
16.3. Confused Deputy and Audience Substitution . . . . . . . 15
16.4. Intent Mutation . . . . . . . . . . . . . . . . . . . . 15
16.5. Evidence and Prompt Injection . . . . . . . . . . . . . 15
Ovidi Expires 31 January 2027 [Page 2]
Internet-Draft LIP-4D July 2026
16.6. Credential and Grant Theft . . . . . . . . . . . . . . . 15
16.7. Policy Oracle Risk . . . . . . . . . . . . . . . . . . . 15
16.8. Algorithm and Downgrade Attacks . . . . . . . . . . . . 15
16.9. Human Approval . . . . . . . . . . . . . . . . . . . . . 16
17. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
19. Normative References . . . . . . . . . . . . . . . . . . . . 17
20. Informative References . . . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. 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.
Ovidi Expires 31 January 2027 [Page 3]
Internet-Draft LIP-4D July 2026
2. 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.
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.
3. 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
Ovidi Expires 31 January 2027 [Page 4]
Internet-Draft LIP-4D July 2026
* 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.
4. 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.
5. 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 [RFC8259].
Ovidi Expires 31 January 2027 [Page 5]
Internet-Draft LIP-4D July 2026
`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 [RFC3986].
`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 [RFC3339].
`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 [RFC4648].
`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.
Ovidi Expires 31 January 2027 [Page 6]
Internet-Draft LIP-4D July 2026
6. 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.
7. The Four Dimensions
7.1. 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.
7.2. 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
Ovidi Expires 31 January 2027 [Page 7]
Internet-Draft LIP-4D July 2026
* `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.
7.3. 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.
7.4. 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.
8. 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.
Ovidi Expires 31 January 2027 [Page 8]
Internet-Draft LIP-4D July 2026
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.
9. Message Types and Processing
9.1. 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`.
9.2. 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.
9.3. 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.
9.4. 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;
Ovidi Expires 31 January 2027 [Page 9]
Internet-Draft LIP-4D July 2026
* `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.
9.5. 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.
9.6. 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.
9.7. 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.
10. 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:
Ovidi Expires 31 January 2027 [Page 10]
Internet-Draft LIP-4D July 2026
{
"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 [RFC8785].
A receiver MUST compare digest values using an implementation that
does not leak useful timing information.
11. 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 [RFC7515].
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.
12. 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 [RFC9110].
Ovidi Expires 31 January 2027 [Page 11]
Internet-Draft LIP-4D July 2026
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 [RFC8446].
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.
13. 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 [RFC6749]; Rich Authorization Requests [RFC9396] and
Resource Indicators [RFC8707] 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 [RFC8705] and DPoP [RFC9449].
* Token introspection can provide grant status and revocation checks
for opaque credentials. OAuth token introspection is specified by
[RFC7662].
Ovidi Expires 31 January 2027 [Page 12]
Internet-Draft LIP-4D July 2026
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.
14. 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": {
Ovidi Expires 31 January 2027 [Page 13]
Internet-Draft LIP-4D July 2026
"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"
}
}
15. 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.
16. Security Considerations
16.1. 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.
Ovidi Expires 31 January 2027 [Page 14]
Internet-Draft LIP-4D July 2026
16.2. 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.
16.3. 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.
16.4. 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.
16.5. 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.
16.6. 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.
16.7. 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.
16.8. 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.
Ovidi Expires 31 January 2027 [Page 15]
Internet-Draft LIP-4D July 2026
16.9. 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.
17. 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.
18. 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
Ovidi Expires 31 January 2027 [Page 16]
Internet-Draft LIP-4D July 2026
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
19. 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
Ovidi Expires 31 January 2027 [Page 17]
Internet-Draft LIP-4D July 2026
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
20. Informative References
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
Ovidi Expires 31 January 2027 [Page 18]
Internet-Draft LIP-4D July 2026
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
September 2023, <https://www.rfc-editor.org/info/rfc9449>.
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
This section is to be removed before publishing as an RFC.
draft-ovidi-lip-4d-00: Initial Internet-Draft version.
Author's Address
Angelo Ovidi
United Kingdom
Email: me@aovidi.com
Ovidi Expires 31 January 2027 [Page 19]