<?xml version="1.0" encoding="UTF-8"?>
<rfc version="3"
     docName="draft-jernalczyk-intentweb-agent-manifest-00"
     category="exp"
     ipr="trust200902"
     submissionType="IETF"
     consensus="false"
     symRefs="true"
     sortRefs="true">
  <front>
    <title abbrev="AgentManifest">IntentWeb AgentManifest</title>
    <seriesInfo name="Internet-Draft" value="draft-jernalczyk-intentweb-agent-manifest-00"/>
    <author initials="M." surname="Jernalczyk" fullname="Mariusz Jernalczyk">
      <organization>IntentWeb</organization>
    </author>
    <date year="2026" month="July" day="6"/>
    <area>Applications and Real-Time</area>
    <keyword>agent</keyword>
    <keyword>manifest</keyword>
    <keyword>AI agents</keyword>
    <keyword>web discovery</keyword>
    <keyword>JSON</keyword>
    <abstract>
      <t>AgentManifest defines a JSON document that websites can publish to
      describe identity, trusted knowledge, agent-facing capabilities,
      structured bindings, risk levels, consent requirements, authentication
      expectations, audit rules, and policies.</t>
      <t>The goal is to help AI agents understand what a website knows and
      what it can safely do before scraping, guessing from visual UI, or
      executing brittle browser automation.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Note to Readers</name>
      <t>This document is an experimental individual Internet-Draft proposal
      for discussion. It is not an RFC and is not an IETF-approved standard.</t>
      <t>Source material for this draft is maintained in the AgentManifest
      repository. The draft is expected to change based on implementation
      feedback and standards discussion.</t>
    </note>
  </front>

  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>AgentManifest is an experimental open specification. Implementers are
      encouraged to test the draft, report interoperability issues, and propose
      improvements.</t>
      <t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>,
      <bcp14>REQUIRED</bcp14>, <bcp14>SHALL</bcp14>,
      <bcp14>SHALL NOT</bcp14>, <bcp14>SHOULD</bcp14>,
      <bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>,
      <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to
      be interpreted as described in <xref target="RFC2119"/> and
      <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
    </section>

    <section anchor="overview">
      <name>Overview</name>
      <t>An AgentManifest document declares:</t>
      <ul spacing="normal">
        <li>the manifest version and status,</li>
        <li>the website or organization identity,</li>
        <li>the platform and integration mode,</li>
        <li>discovery locations for the manifest and related resources,</li>
        <li>trusted knowledge sources,</li>
        <li>capabilities with type, risk, consent, state-change, binding, and
        audit metadata, and</li>
        <li>policy expectations for consent, authentication, data
        minimization, and audit.</li>
      </ul>
      <t>Capabilities describe what a website can do and under which policy.
      Structured <tt>bindings</tt> describe how that capability can be accessed
      or executed, such as through HTML, static resources, HTTP,
      OpenAPI <xref target="OPENAPI" format="none"/>,
      MCP <xref target="MCP" format="none"/>, or hosted checkout.
      OpenAPI operations and MCP tools are binding targets, not the whole
      capability contract.</t>
      <t>AgentManifest is vendor-neutral. Implementation frameworks can
      generate manifests and bindings, but the manifest does not require any
      specific generator or expose implementation ownership as a normative
      field.</t>
    </section>

    <section anchor="discovery">
      <name>Discovery</name>
      <t>Agents <bcp14>SHOULD</bcp14> attempt static discovery at
      <tt>/.well-known/agent.json</tt>. Publishers <bcp14>MAY</bcp14> also
      expose <tt>/.well-known/agent-manifest.json</tt>,
      <tt>/agent-manifest.json</tt>, or an HTML discovery hint:</t>
      <sourcecode type="html"><![CDATA[<link rel="agent-manifest" href="/.well-known/agent.json">]]></sourcecode>
      <t>If no manifest is found, agents <bcp14>SHOULD</bcp14> continue normal
      web behavior and <bcp14>SHOULD NOT</bcp14> infer that unsupported actions
      are safe.</t>
    </section>

    <section anchor="schema">
      <name>Schema</name>
      <t>The canonical JSON Schema for the repository version of this draft
      is:</t>
      <sourcecode type="text"><![CDATA[rfc/schemas/agent-manifest.v0.1.schema.json]]></sourcecode>
      <t>The schema uses JSON Schema Draft 2020-12
      <xref target="JSON-SCHEMA-2020-12" format="none"/> and keeps
      <tt>additionalProperties: true</tt> for forward-compatible
      experimentation.</t>
      <t>A conforming manifest for this draft uses the
      <tt>agentManifestVersion</tt> value <tt>0.1-draft</tt>.</t>
    </section>

    <section anchor="risk-and-consent">
      <name>Risk and Consent</name>
      <t>Capabilities declare a risk level of <tt>low</tt>, <tt>medium</tt>,
      <tt>high</tt>, or <tt>critical</tt>.</t>
      <t>Low-risk capabilities are public and read-only. Medium-risk
      capabilities submit data or start a workflow. High-risk capabilities
      modify user or business state. Critical capabilities include payments,
      orders, legal commitments, destructive actions, or irreversible
      operations.</t>
      <t>High and critical actions <bcp14>MUST</bcp14> require explicit
      confirmation and audit. Critical actions <bcp14>MUST</bcp14> set
      <tt>stateChange</tt> to <tt>true</tt>, <tt>requiresConsent</tt> to
      <tt>true</tt>, and <tt>consentMode</tt> to <tt>explicit</tt>,
      <tt>step_up</tt>, or <tt>human_review</tt>.</t>
      <t>AgentManifest declares authentication, authorization, consent, audit,
      and policy expectations. Protocol endpoints are responsible for
      enforcement. Consent must be specific to a capability invocation and must
      not be treated as broad permanent authorization. Critical actions should
      use appropriate authentication, explicit confirmation, audit, replay
      protection, and duplicate transaction controls.</t>
    </section>

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Manifests and related public files <bcp14>MUST NOT</bcp14> expose
      secrets, private tokens, unpublished data, private customer information,
      admin-only endpoints, or privileged internal operations.</t>
      <t>Servers <bcp14>MUST</bcp14> enforce authorization, consent,
      validation, replay protection, duplicate transaction controls, and policy
      checks outside prompt text. Prompt instructions are not a security
      boundary.</t>
    </section>

    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>Publishers should minimize disclosed and collected data. Knowledge
      sources should include only information intended for public agent use.
      State-changing actions should collect only fields required for the
      declared capability.</t>
      <t>Agents should provide user-visible summaries for submitted data and
      should avoid logging sensitive user information unless required for
      audit, compliance, or fraud prevention.</t>
    </section>

    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes no IANA registration request.</t>
      <t>The media type <tt>application/agent-manifest+json</tt> is proposed
      for discussion only and is not registered by this document.</t>
    </section>
  </middle>

  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner"/>
          <date month="March" year="1997"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba" fullname="Barry Leiba"/>
          <date month="May" year="2017"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="JSON-SCHEMA-2020-12" target="https://json-schema.org/draft/2020-12/json-schema-core.html">
        <front>
          <title>JSON Schema: A Media Type for Describing JSON Documents</title>
          <author>
            <organization>JSON Schema</organization>
          </author>
          <date year="2022" month="June"/>
        </front>
      </reference>
    </references>

    <references>
      <name>Informative References</name>
      <reference anchor="OPENAPI" target="https://spec.openapis.org/oas/latest.html">
        <front>
          <title>OpenAPI Specification</title>
          <author>
            <organization>OpenAPI Initiative</organization>
          </author>
        </front>
      </reference>
      <reference anchor="MCP" target="https://modelcontextprotocol.io/">
        <front>
          <title>Model Context Protocol</title>
          <author>
            <organization>Model Context Protocol</organization>
          </author>
        </front>
      </reference>
    </references>
  </back>
</rfc>
