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

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]