[media-types] [IANA #1452522] New Media Type Registratio n Request: application/vnd.fafa+yaml

Hi Murray,

Sending a reminder for this request from May 19th.

thanks,
Amanda

On Wed May 20 00:53:43 2026, amanda.baber wrote:
> Hi Murray,
> 
> Would you be able to review this new request from FAF by June 2nd?
> 
> thanks,
> Amanda
> 
> =====
> 
> Type name: application
> 
> Subtype name: vnd.fafa+yaml
> 
> Required parameters: N/A
> 
> Optional parameters: version
> 
> Encoding considerations: 8bit (UTF-8). Binary content, when
> present, is base64-encoded inside YAML.
> 
> 
> Security considerations:
> 
> The following addresses the questions outlined in the IANA
> media-type security considerations checklist at
> https://www.iana.org/form/media-types:
> 
> 1. Active or executable content. No. The .fafa format is a YAML
>    data document. It contains no scripts, code, executable
>    directives, or active markup. Implementations MUST treat
>    .fafa content as data, never as instructions, commands, or
>    code. Declaration is not authorization: an implementation
>    MUST NOT auto-execute a capability purely because it is
>    declared.
> 
> 2. Privacy and integrity needs. .fafa carries agent identity
>    claims and capability declarations. It is not intended to
>    carry personal data. Integrity of the endpoints and
>    signature fields is required where present; confidentiality
>    of the declaration itself is generally not required, but
>    transport SHOULD be authenticated and encrypted.
> 
> 3. Privacy and integrity services. The .fafa format itself does
>    not provide cryptographic confidentiality, integrity
>    protection, or signing. These services MUST be provided
>    externally:
> 
> - Confidentiality: TLS for all transport; encryption at rest
>   in any backend that stores .fafa documents.
> 
> - Integrity: where present, the signature field carries
>   provenance/integrity material, verified by the consumer;
>   transport-layer integrity (TLS); application-level write
>   authorization.
> 
> - Consumers MUST treat the endpoints field as untrusted
>   until verified against signature if present, and MUST
>   apply least privilege when consuming declared
>   capabilities.
> 
> 4. YAML format considerations. .fafa is built on YAML 1.2. All
>    YAML 1.2 security considerations apply, including those
>    described in RFC 9512 ("YAML Media Type") section 6. Specific
>    to .fafa:
> 
> - Parsers MUST disable custom type construction (no
>   !!python/object, !ruby/object, or equivalent
>   language-specific constructors).
> 
> - Parsers MUST enforce alias-expansion limits to mitigate
>   entity-expansion / "billion-laughs"-style attacks.
> 
> - Parsers MUST enforce nesting-depth limits to prevent stack
>   overflow.
> 
> 5. Compression. Not applicable. .fafa does not use or require
>    compression at the format layer. If transport-level
>    compression is applied to .fafa content alongside other
>    secret data, standard compression-with-secret considerations
>    (e.g., CRIME/BREACH class attacks) apply at the transport
>    layer.
> 
> 6. Container format. Not applicable. .fafa is a single YAML
>    document, not a container or archive format. No
>    packaging-level security considerations apply.
> 
> 7. Link references. .fafa documents MAY contain endpoint
>    locators (the endpoints field) and provenance references
>    (the provenance field). These are declarative pointers; a
>    .fafa document does not require resolving them to be
>    correctly interpreted. Consumers MUST treat endpoint
>    locators as untrusted until verified (see item 3) and MUST
>    NOT auto-resolve or auto-invoke them by virtue of their
>    presence in the document.
> 
> 
> Additional security considerations:
> 
> - Untrusted input / context poisoning / prompt injection. .fafa
>   documents originate from agents and third parties and MUST be
>   treated as untrusted input by consumers. Implementations MUST
>   NOT elevate .fafa content to "system instructions" or
>   "developer directives" within prompt hierarchies. Capability
>   declarations are a documented vector for over-trust and
>   prompt injection.
> 
> - Cross-context isolation. Implementations SHOULD scope
>   capability consumption to the declaring agent's verified
>   identity to prevent unintended cross-agent or cross-domain
>   influence.
> 
> - No secrets or credentials. .fafa documents MUST NOT contain
>   secrets, API keys, or credentials; MUST NOT contain
>   user-personal data (use .fafm for memory of that kind); and
>   MUST NOT contain executable code. The format is declarative,
>   not executable.
> 
> 
> Interoperability considerations:
> 
> .fafa is the Agent Card format of the FAF family, sibling to
> the IANA-registered .faf format (application/vnd.faf+yaml) and
> .fafm format (application/vnd.fafm+yaml). It is designed to
> interoperate while serving a distinct purpose:
> 
> .faf   - Foundational Context Layer  (project IS - static, read once)
> .fafm  - Voice Memory Layer (VML)    (agent REMEMBERS - mutating,
> persisted)
> .fafa  - Agent Card                  (agent IS - declarative identity
> + capability)
> 
> Three formats. Three roles. One ecosystem.
> 
> .fafa is format-level, not protocol-level. It composes with -
> does not replace - agent-interaction protocols: a protocol
> carries, references, or resolves a .fafa document; the document
> declares the agent the protocol acts upon.
> 
> The .fafa schema extends application/vnd.faf+yaml - a .fafa
> document remains a valid YAML file. Consumers that only
> understand .faf will safely ignore the agent-specific blocks
> and still extract identity from top-level fields. Consumers
> that understand .fafa gain the full agent declaration.
> 
> .fafa is YAML 1.2 / RFC 9512 compliant. Consumers MUST use
> YAML safe-load, MUST treat unknown top-level fields and unknown
> subfields within agent, capabilities, and endpoints as
> forward-compatible extensions, and SHOULD use UTF-8 encoding.
> 
> All three formats share the same family branding, YAML
> philosophy (YAML 1.2 / RFC 9512 baseline), and MIT license.
> Multiple .fafa documents per scope are permitted, distinguished
> by agent.id.
> 
> 
> Published specification: https://github.com/Wolfe-
> Jam/faf/blob/main/AGENT-FORMAT.md
> 
> Applications that use this media type: faf-agent-mcp (reference
> implementation), xAI/Grok, claude-faf-mcp, gemini-faf-mcp and
> future FAF MCP-family integrations.
> 
> Fragment identifier considerations: None
> 
> Additional information - File extension: .fafa
> 
> Person & email address for further information: James Wolfe,
> [email protected]
> 
> Intended usage: COMMON
> 
> Restrictions on usage: None
> 
> Author: James Wolfe
> 
> Change controller: FAF Foundation

_______________________________________________
media-types mailing list -- [email protected]
To unsubscribe send an email to [email protected]