Domain-Verified Skills (DVS) Protocol

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

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

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

Trust Root: https://example.com/
Skill URL:  https://example.com/.well-known/
            skills/support/SKILL.md

Trust Root: https://github.com/example-org/
Skill URL:  https://github.com/example-org/
            repo/blob/main/skills/SKILL.md

/.well-known/skills/{skill-name}/SKILL.md

/.well-known/skills/index.json

4. Skill Specification

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)

https://example.com/.well-known/skills/my-skill/SKILL.md

https://example.com/.well-known/skills/my-skill/scripts/process.py

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.

5. Security and Permissions

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

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

• 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

Acknowledgments

The authors would like to thank the broader AI agent community for discussions that informed this protocol design.¶

Author's Address