Proposal: standard.site.declaration
Draft for Discussion
Abstract
AT Protocol provides portable identity, portable content, and portable social graphs. What it currently lacks is a standard mechanism for discovering machine-readable declarations associated with digital content.
Today, creators and organisations publish declarations about digital assets through websites, registries, the C2PA provenance framework, and other systems. These declarations may describe provenance, copyright ownership, licensing, AI usage preferences, authenticity, attribution, or other assertions. Within the AT Protocol ecosystem, however, they are treated as ordinary external resources. Clients cannot distinguish them from arbitrary web pages, nor can they discover, retrieve, or process them in a consistent manner.
This proposal introduces standard.site.declaration, a generic discovery mechanism that allows declaration metadata to be published within an AT Protocol repository. Rather than defining another declaration format, trust framework, or verification model, it provides a common protocol-level extension point through which existing and future declaration ecosystems can integrate with AT Protocol.
For example, a declaration may describe provenance using the C2PA provenance framework, rights information bound to an ISCC content identifier and fingerprint, or other machine-readable metadata. Clients that understand a particular declaration format may render rich information, while clients that do not can safely ignore unsupported fields.
A standard.site.declaration record is intended to complement, rather than replace, existing declaration infrastructures. Declaration metadata may continue to be hosted by external systems while being republished in a userβs AT Protocol repository, allowing clients to discover and present it through a common mechanism.
By standardising declaration discovery rather than declaration semantics, the proposal enables interoperability between declaration ecosystems without requiring consensus on how declarations are represented, verified, or trusted. It introduces a small protocol primitive that allows AT Protocol applications to support structured declarations while remaining compatible with existing standards and future extensions.
Motivation
Digital content increasingly carries machine-readable information describing how it should be interpreted or used.
Examples include:
- content authorship and attribution
- copyright ownership, licensing, and AI usage preferences
- provenance information
- authenticity and AI disclosure statements
Many existing standards and systems already publish such declarations, including:
- the C2PA provenance framework
- signed JSON-LD documents
- declaration registries
- publishing metadata repositories
AT Protocol currently provides no standard mechanism for discovering declarations associated with content published within the network. Instead, applications either invent their own conventions or simply attach URLs that clients cannot interpret consistently.
This proposal addresses only that discovery problem.
Why not simply post a URL?
AT Protocol already allows users to attach arbitrary URLs to posts. While this is sufficient for linking to external resources, it provides no semantic information about the linked object.
A client cannot determine whether a URL refers to a declaration, licence, provenance record, documentation, or an ordinary web page.
A standard declaration record provides a machine-readable signal that the referenced resource is intended to describe the associated digital content. Clients can therefore discover, retrieve, and process declarations consistently without requiring prior knowledge of individual services.
Design Goals
The proposed record should:
- remain independent of any declaration format
- remain independent of any trust framework
- support multiple declaration types
- be portable between repositories
- be interoperable across services
- allow clients to discover declarations consistently
- avoid duplicating existing standards
- support future declaration ecosystems without modification
Non-Goals
This proposal does not define:
- how content authorship is established
- how copyright ownership is determined
- legal validity of declarations
- verification policies
- trust frameworks
- client presentation
- moderation policies
- recommendation or ranking algorithms
- declaration schemas
It defines only a standard mechanism for discovering declarations associated with digital content.
Architecture
A declaration is a structured collection of one or more machine-readable assertions about a digital asset. Those assertions may describe provenance, rights, attribution, certification, AI usage preferences, or other information.
The starting point for discovery is a declaration URL shared in an AT Protocol post. Through the Standard.site discovery mechanism, a client can locate the corresponding standard.site.declaration record in the publisherβs repository. That record publishes structured declaration metadata, allowing clients to render the information they understand.
The proposal does not define the declaration format, trust model, or verification process. These remain the responsibility of the respective declaration standards and implementations.
AT Protocol post
β
βΌ
Declaration URL
β
βΌ
Well-known discovery
β
βΌ
User's PDS
β
βΌ
standard.site.declaration
β
βββ declaration metadata
βββ content identifier and fingerprint, e.g. ISCC
βββ rights and provenance information
βββ declaring party
βββ references to hosted declarations or supporting resources
β
βΌ
Client-specific rendering and verification
Proposed Record
The proposal introduces a generic record for publishing structured declaration metadata within an AT Protocol repository. It serves as a common protocol-level extension point through which existing and future declaration ecosystems can integrate with AT Protocol.
A standard.site.declaration record complements existing declaration infrastructures by allowing declaration metadata to be republished within the declaring partyβs own repository while remaining interoperable with external declaration systems.
standard.site.declaration
β
βββ declaration metadata
βββ declaration type
βββ subject
βββ references hosted declarations or supporting resources
The record may be published by a creator, publisher, archive, registry, or another declaring party. It may represent declaration metadata that is also hosted or maintained by an external declaration ecosystem.
Depending on the declaration and the applicable metadata schema, the record may contain information such as provenance metadata, rights information, attribution, certification, AI usage preferences, content identifiers and fingerprints such as ISCC, signatures, timestamps, and references to supporting resources.
The proposal does not prescribe a declaration schema, metadata vocabulary, trust framework, or verification model. Clients may process the fields and extensions they recognise while safely ignoring those they do not.
Declaration Discovery and Presentation
A standard.site.declaration record enables clients to discover and retrieve structured declaration metadata associated with digital content. Depending on the declaration schema, the record may contain information such as:
- content identifier and fingerprint, e.g. ISCC
- provenance metadata
- rights and licensing information
- attribution
- certification
- AI usage preferences
- signatures and timestamps
- references to hosted declarations or supporting resources
The record enables progressive levels of client support. A client that does not recognise a declaration schema can still indicate that a declaration exists and provide a link to the declaration URL. A client that understands the declaration schema may render the information it recognises while safely ignoring unsupported fields or extensions.
For example, a declaration may incorporate information defined by existing standards or domain-specific vocabularies, such as:
- IPTC metadata
- schema.org metadata
- Creative Commons licensing
- AI usage preferences
- human and AI contribution disclosures
The proposal does not prescribe a declaration schema or metadata vocabulary. It provides a common discovery mechanism that allows clients to retrieve structured declaration metadata while declaration formats evolve independently.
Illustrative Lexicon Structure
The exact Lexicon is intentionally left open for discussion. The following structure illustrates the information that a declaration record could contain.
| Field | Description | Required | Example |
subject
|
Reference to the digital asset described by the declaration. The representation should follow AT Protocol conventions where possible. | β | Blob, CID, content fingerprint (e.g. ISCC), or another persistent identifier |
declarationUrl
|
Canonical public URL used to discover the declaration. | β | https://example.org/declarations/12345
|
declarationType
|
Category of declaration. The representation is intentionally left open for discussion. | β | provenance, rights, license, ai-preferences
|
issuer
|
Identifier of the declaring party. | DID, domain, or organisation identifier | |
digest
|
Optional integrity identifier for the declaration metadata. | CID or another integrity identifier | |
createdAt
|
Creation timestamp. | β | RFC 3339 |
This proposal intentionally does not define a fixed declaration schema. A declaration may describe provenance, rights, attribution, certification, licensing, AI usage preferences, or other machine-readable metadata.
How declaration metadata should be represented remains an open design question. They could be expressed within a common declaration record, through specialised Lexicons, or by another extensible mechanism aligned with AT Protocol conventions.
Relationship to Existing Standards
This proposal intentionally does not define a declaration format, metadata model, or trust framework. Instead, it provides a common discovery mechanism through which existing and future declaration ecosystems can integrate with AT Protocol.
| Standard | Role |
| C2PA | Embedded provenance and manifest framework |
| W3C Verifiable Credentials | Identity, certification, and signed assertions |
| Declaration Registries | Scalable discovery of declarations |
| JSON-LD | Structured declaration representation |
| Content identifier and fingerprint (e.g. ISO 24138:2024 ISCC) | Content-based identification |
The standard.site.declaration record complements rather than replaces these standards. It allows declaration metadata to be published in an AT Protocol repository while remaining interoperable with existing declaration infrastructures. Declaration formats continue to define declaration semantics, while standard.site.declaration provides a common protocol-level mechanism for discovery and presentation.
Verification
Verification is intentionally outside the scope of this proposal.
The purpose of standard.site.declaration is to publish and make declaration metadata discoverable. It does not define how declarations are evaluated, trusted, or verified. Those decisions remain the responsibility of individual applications and declaration ecosystems.
A client may, for example:
- ignore declarations entirely
- verify digital signatures
- validate content identifiers and fingerprints
- validate certification or identity information
- consult external registries or trust services
- apply local trust policies
Different clients may apply different verification methods and reach different conclusions about the same declaration. This proposal intentionally leaves those decisions to implementations.
Example
A creator publishes an image together with a declaration URL:
https://example.org/declarations/12345
The corresponding declaration metadata is published as a standard.site.declaration record in the creatorβs PDS.
The declaration metadata includes information such as:
- creator identity
- provenance metadata
- rights and licensing information
- AI usage preferences
- asset identifier and content fingerprint
- certification information
A client encountering the declaration URL performs Standard.site discovery, retrieves the corresponding standard.site.declaration record from the creatorβs PDS, and renders the information it understands.
For example:
- β Creator verified
- CC BY 4.0
- AI training reserved
A client that does not recognise the declaration schema can still indicate that a declaration exists and provide a link to the declaration URL.
This allows declaration metadata to be discovered consistently across AT Protocol while declaration formats, metadata vocabularies, and trust frameworks evolve independently.
Benefits
A standard declaration record provides a consistent mechanism for discovering structured declaration metadata associated with digital content while remaining independent of any particular declaration format, metadata vocabulary, or trust framework.
It enables creators, publishers, archives, institutional repositories, declaration registries, and future declaration ecosystems to integrate with AT Protocol through a common protocol primitive, without requiring consensus on declaration semantics, verification methods, or trust policies.
By allowing declaration metadata to be republished in a user-controlled AT Protocol repository, the proposal complements existing declaration infrastructures rather than replacing them. Clients gain a consistent mechanism for discovering and presenting declarations while existing declaration ecosystems remain authoritative for declaration formats, trust frameworks, and verification.
Open Questions
This proposal is intended as a starting point for discussion.
Questions that would benefit from community feedback include:
- Should declaration metadata be represented within a common declaration record, through specialised Lexicons, or by another extensible mechanism aligned with AT Protocol conventions?
- Should declaration schemas or media types be exposed explicitly to improve interoperability?
- How should clients handle multiple declarations that make conflicting assertions about the same digital asset?
- Should declaration records describe exactly one digital asset, or should multiple related assets be supported?
- Should this proposal evolve as an experimental community Lexicon before consideration for the
standard.*namespace?