Network Working Group Z. V. Zhou Internet-Draft Namefi Intended status: Informational 2 March 2026 Expires: 3 September 2026 Domain-Verified Skills (DVS) Protocol draft-zzn-dvs-00 Abstract This document defines the Domain-Verified Skills (DVS) protocol, a lightweight mechanism for AI Agents to discover, verify, and execute skill definitions served over HTTPS. A skill is a directory containing a SKILL.md entry point and optional bundled resources that instructs an AI Agent to perform a specific task or adopt a specific behavior. The central design principle of DVS is that a skill's identity and trustworthiness are derived entirely from the HTTPS URL at which it is served -- no centralized registry or third-party certification is required. The operator of the URL's origin is the authoritative endorser of the skill. This trust is formalized through the concept of a Trust Root: an HTTPS URL prefix declared by the skill publisher that scopes the trust boundary for their skills. A skill is considered verified if and only if its URL begins with the declared Trust Root. For brands with first-party domains, the Trust Root is the domain origin. For brands publishing on user-generated content platforms where the platform operator does not vouch for individual publishers, the Trust Root MUST be path-scoped to content the brand controls, ensuring that trust does not extend to the entire platform. The protocol leverages the existing trust infrastructure of the Domain Name System (DNS) and Transport Layer Security (TLS) and is backward compatible with skills already served over HTTPS, including those hosted on GitHub or other platforms. 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/. Zhou Expires 3 September 2026 [Page 1] Internet-Draft DVS March 2026 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 3 September 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Core Protocol . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identity and Trust . . . . . . . . . . . . . . . . . . . 4 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Skill Specification . . . . . . . . . . . . . . . . . . . . . 5 4.1. Directory Structure . . . . . . . . . . . . . . . . . . . 6 4.2. SKILL.md Entry Point . . . . . . . . . . . . . . . . . . 6 4.3. Metadata (Frontmatter) . . . . . . . . . . . . . . . . . 6 4.4. Instructions (Body) . . . . . . . . . . . . . . . . . . . 7 4.5. Bundled Resources . . . . . . . . . . . . . . . . . . . . 7 4.5.1. Additional Instructions . . . . . . . . . . . . . . . 7 4.5.2. Executable Scripts . . . . . . . . . . . . . . . . . 7 4.5.3. Data and Reference Materials . . . . . . . . . . . . 8 4.6. Progressive Loading . . . . . . . . . . . . . . . . . . . 8 5. Security and Permissions . . . . . . . . . . . . . . . . . . 8 5.1. Same-Origin Isolation . . . . . . . . . . . . . . . . . . 9 5.2. Explicit Consent . . . . . . . . . . . . . . . . . . . . 9 5.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Composition . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Zhou Expires 3 September 2026 [Page 2] Internet-Draft DVS March 2026 1. Introduction Current AI Agent skills (such as those in the Claude Agent Skills protocol [CLAUDE-SKILLS]) are primarily distributed via centralized code repositories or platform-specific upload mechanisms. This creates several friction points: * Identity Ambiguity: Users cannot easily verify if a skill hosted on a third-party platform genuinely belongs to a brand. * Hosting Friction: Brands must manage external accounts and synchronization instead of using their existing web infrastructure. * Security Risks: Malicious skills can spoof brand names on open platforms to exfiltrate data. The Domain-Verified Skills (DVS) protocol returns to the fundamental logic of the Web: the URL is the Identity. By serving skills directly from a brand-controlled URL prefix, we leverage the existing global trust of the DNS and HTTPS infrastructure. For brands with first-party domains, the Trust Root is the domain itself (e.g., https://microsoft.com/). For brands that publish on user-generated content platforms such as GitHub or Hugging Face, the Trust Root is scoped to the brand's path on that platform (e.g., https://github.com/microsoft/). This allows DVS to provide brand- verified skill identity across all hosting configurations, without requiring brands to self-host infrastructure. This protocol is designed to be compatible with existing skill formats and distributions. A skill already hosted on GitHub (e.g., https://github.com/microsoft/repo/blob/main/.../SKILL.md) is immediately usable under DVS by registering https://github.com/ microsoft/ as the Trust Root, with no changes to the skill files themselves. In particular, a skill directory conforming to DVS can be directly consumed by any agent that understands the SKILL.md convention, while also gaining the identity and trust properties conferred by domain-verified hosting. 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. Zhou Expires 3 September 2026 [Page 3] Internet-Draft DVS March 2026 The following terms are used in this document: Skill: A directory containing a SKILL.md entry point and optional bundled resources (scripts, templates, data files, additional instructions) that directs an AI Agent to perform a specific task or adopt a specific behavior. SKILL.md: The mandatory Markdown entry-point file within a skill directory. It contains YAML frontmatter metadata and human- readable instructions for the Agent. Agent: An AI system capable of fetching, interpreting, and executing Skill instructions. Skill URL: The HTTPS URL of the skill directory (or its SKILL.md entry point). This URL serves as the globally unique identifier of the Skill. Trust Root: An HTTPS URL prefix that defines the trust boundary for a skill or set of skills. A skill is considered verified under a Trust Root if and only if its Skill URL begins with the Trust Root prefix. For first-party brand domains, the Trust Root is typically the domain origin (e.g., https://microsoft.com/). For user-generated content platforms, the Trust Root MUST be scoped to a path controlled by the brand (e.g., https://github.com/ microsoft/). Hosting Domain: The domain component of the Trust Root URL, considered the network-level endorser of the Skill via DNS and TLS. Bundled Resource: Any file within the skill directory other than SKILL.md, including additional instruction files, executable scripts, templates, schemas, and data files. 3. Core Protocol The identity of a skill is defined strictly by its HTTPS URL. 3.1. Identity and Trust Skills MUST be served via HTTPS [RFC9110]. Agents MUST NOT fetch or execute skills served over plain HTTP. The identity and trust of a skill is defined by its Trust Root. A skill's URL MUST begin with its declared Trust Root prefix for the skill to be considered verified under that root. Zhou Expires 3 September 2026 [Page 4] Internet-Draft DVS March 2026 For first-party brand hosting, the Trust Root is the domain origin: Trust Root: https://example.com/ Skill URL: https://example.com/.well-known/ skills/support/SKILL.md For user-generated content platforms, the Trust Root MUST be scoped to a path controlled by the brand. Agents MUST NOT accept a bare UGC platform domain (e.g., https://github.com/) as a Trust Root, as this would confer trust to all content on the platform: Trust Root: https://github.com/example-org/ Skill URL: https://github.com/example-org/ repo/blob/main/skills/SKILL.md A skill URL that does not begin with its declared Trust Root prefix MUST be rejected by the Agent. 3.2. Discovery Skills MAY be hosted at any valid URL path on a domain (e.g., https://example.com/skills/my-assistant/SKILL.md). Official brand skills SHOULD be served from the well-known path prefix: /.well-known/skills/{skill-name}/SKILL.md This follows the conventions established by [RFC8615] for well-known URIs. Skills MAY be indexed in the domain's sitemap.xml [SITEMAP] to enable automated agent discovery. Agents supporting discovery SHOULD check for skill entries in the sitemap when exploring a domain's available skills. A domain MAY serve a skill index document at: /.well-known/skills/index.json The index document, if present, SHOULD contain an array of objects, each with name, description, and path fields pointing to available skills on the domain. 4. Skill Specification Zhou Expires 3 September 2026 [Page 5] Internet-Draft DVS March 2026 4.1. Directory Structure A Domain-Verified Skill is a directory containing at minimum a SKILL.md file. The directory MAY contain additional files organized by purpose: my-skill/ +-- SKILL.md (entry point - REQUIRED) +-- ADVANCED.md (additional instructions - OPTIONAL) +-- REFERENCE.md (detailed reference docs - OPTIONAL) +-- scripts/ | +-- process.py (executable script - OPTIONAL) | +-- validate.sh (executable script - OPTIONAL) +-- templates/ | +-- report.html (template file - OPTIONAL) +-- data/ +-- schema.json (data/reference file - OPTIONAL) When served over HTTPS, the directory structure is represented by URL paths relative to the skill's base URL. For example, a skill at https://example.com/.well-known/skills/my-skill/ would have its entry point at: https://example.com/.well-known/skills/my-skill/SKILL.md And a bundled script at: https://example.com/.well-known/skills/my-skill/scripts/process.py 4.2. SKILL.md Entry Point Every skill directory MUST contain a file named SKILL.md. This file MUST be encoded in UTF-8 and served with the media type text/markdown [RFC7763]. The file consists of two parts: 1. YAML frontmatter (metadata) - REQUIRED 2. Markdown body (instructions) - REQUIRED 4.3. Metadata (Frontmatter) SKILL.md files MUST begin with a YAML frontmatter block delimited by --- lines. The frontmatter MUST contain the following fields: name: A short, human-readable name for the skill. MUST NOT exceed Zhou Expires 3 September 2026 [Page 6] Internet-Draft DVS March 2026 64 characters. MUST contain only lowercase letters, numbers, and hyphens. description: A brief description of the skill's purpose and capabilities, including guidance on when an Agent should trigger the skill. MUST NOT be empty. MUST NOT exceed 1024 characters. Example: name: customer-support description: Handles common customer support inquiries for Acme Corp products. Use when the user asks about product returns, warranty claims, or order status. 4.4. Instructions (Body) The body of SKILL.md, following the frontmatter, MUST contain human- readable instructions for the Agent. These instructions define the behavior, constraints, and capabilities of the skill. Instructions SHOULD be written as clear, step-by-step procedural guidance. They MAY reference bundled resources using relative URLs (e.g., [see advanced guide](ADVANCED.md) or run the script at scripts/process.py). 4.5. Bundled Resources Skills MAY include additional files alongside SKILL.md. These bundled resources fall into three categories: 4.5.1. Additional Instructions Additional Markdown files (e.g., ADVANCED.md, REFERENCE.md, FORMS.md) provide specialized guidance, detailed API references, or extended workflows. These files: * SHOULD use the .md extension and text/markdown media type. * Are loaded by the Agent only when referenced from SKILL.md or when the task context requires them. 4.5.2. Executable Scripts Scripts (e.g., Python, Shell, JavaScript) provide deterministic operations that the Agent can execute. These files: * MUST reside within the same skill directory (same-origin). Zhou Expires 3 September 2026 [Page 7] Internet-Draft DVS March 2026 * Are executed by the Agent via its runtime environment; only the script's output enters the Agent's context, not the script source code itself. * MUST be subject to the Explicit Consent requirement defined in Section 5.2 before execution. 4.5.3. Data and Reference Materials Data files (e.g., JSON schemas, CSV datasets, configuration templates, API documentation) provide factual lookup material. These files: * MUST reside within the same skill directory (same-origin). * Are read by the Agent on demand when the task requires specific reference information. * Impose no context cost until actually accessed. 4.6. Progressive Loading Agents implementing DVS SHOULD employ a progressive loading strategy to manage context efficiently: Level 1 - Metadata (always loaded): The YAML frontmatter (name and description) is loaded at agent startup or skill registration time. This enables skill discovery with minimal token cost (approximately 100 tokens per skill). Level 2 - Instructions (loaded on trigger): The body of SKILL.md is fetched and loaded into the agent's context only when the skill is triggered by a matching user request. Level 3 - Resources (loaded as needed): Bundled resources (additional markdown files, scripts, data files) are accessed only when referenced during execution. Scripts are executed and only their output is loaded into context. This three-level approach ensures that a domain can publish many skills without imposing context overhead on agents, as only the metadata of registered skills is persistently loaded. 5. Security and Permissions Zhou Expires 3 September 2026 [Page 8] Internet-Draft DVS March 2026 5.1. Same-Origin Isolation Agents MUST restrict a skill's automated access to resources within its Trust Root prefix. A skill with Trust Root https://github.com/ example-org/ MUST NOT be permitted to automatically access resources outside that prefix (including other GitHub users or repos) without explicit user consent. Bundled resources (scripts, data files, templates) referenced by a skill MUST reside within the same Trust Root prefix as the SKILL.md file. Agents MUST reject references to resources outside the skill's Trust Root unless the user explicitly approves the access. This prevents a compromised or malicious skill from leveraging its trusted context to exfiltrate data from, or perform actions on, unrelated origins or paths. 5.2. Explicit Consent Agents MUST display the source domain to the user and request explicit confirmation before executing any non-textual instructions contained in a skill (e.g., shell commands, API calls, file system operations, running bundled scripts). The consent prompt SHOULD clearly indicate: * The Trust Root of the skill. * A description of the action to be performed. * Any resources that will be accessed or modified. Textual instructions (Markdown content) MAY be loaded without additional consent beyond the initial skill activation. Executable content (scripts, commands) MUST always require explicit consent. 5.3. DNSSEC Domain operators SHOULD deploy DNSSEC [RFC4033] to prevent DNS spoofing attacks that could redirect agents to malicious skill files hosted on attacker-controlled infrastructure. 6. Composition A skill MAY reference other skills via their full HTTPS URLs. When an Agent encounters a referenced skill URL during execution, it SHOULD dynamically fetch and load the referenced skill if the current context requires the extended capabilities it provides. Zhou Expires 3 September 2026 [Page 9] Internet-Draft DVS March 2026 Each referenced skill is subject to its own Trust Root's trust and security policies. Agents MUST apply the Same-Origin Isolation policy (Section 5.1) independently to each loaded skill based on its own Trust Root. When composing skills across domains, agents SHOULD clearly communicate to the user that the trust context is being extended to additional domains. 7. Security Considerations The primary security property of this protocol is that trust is anchored to domain ownership. This inherits both the strengths and weaknesses of the existing Web PKI and DNS infrastructure. Skill spoofing is mitigated by the HTTPS requirement, which ensures that only the legitimate operator of a domain can serve skills from that domain. DNSSEC (Section 5.3) provides an additional layer of protection against DNS-level attacks. Agents implementing this protocol should be aware of the following risks: * Domain compromise: If a domain is compromised, all skills served from it should be considered compromised. * Subdomain delegation: Skills on subdomains should be treated as distinct trust contexts from the parent domain. * UGC platform Trust Roots: On user-generated content platforms, agents MUST enforce path-scoped Trust Roots. Accepting a bare platform domain (e.g., https://github.com/) as a Trust Root would allow any user on that platform to publish skills that appear equally trusted as a legitimate brand's skills. * Transitive trust in composition: When skills reference other skills (Section 6), the trust chain extends across domains. Agents should clearly communicate this to users. * Script execution: Bundled scripts execute with the permissions of the agent's runtime environment. Malicious scripts could perform unauthorized file access, network calls, or data exfiltration. The Explicit Consent requirement (Section 5.2) mitigates this risk, but agents SHOULD also sandbox script execution where possible. Zhou Expires 3 September 2026 [Page 10] Internet-Draft DVS March 2026 * External resource fetching: Skills that instruct agents to fetch data from external URLs pose particular risk, as fetched content may contain malicious instructions. Agents SHOULD treat externally-fetched content as untrusted. 8. IANA Considerations This document requests registration of the well-known URI suffix skills in the "Well-Known URIs" registry established by [RFC8615]. URI suffix: skills Change controller: Namefi Specification document: This document (Section 3.2) 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763, DOI 10.17487/RFC7763, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 9.2. Informative References Zhou Expires 3 September 2026 [Page 11] Internet-Draft DVS March 2026 [CLAUDE-SKILLS] Anthropic, "Agent Skills Overview", n.d., . [SITEMAP] sitemaps.org contributors, "Sitemaps XML Format", n.d., . Acknowledgments The authors would like to thank the broader AI agent community for discussions that informed this protocol design. Author's Address Zainan Victor Zhou Namefi Email: zzn@namefi.io Zhou Expires 3 September 2026 [Page 12]