The Sygil Protocol: A Cross-Domain Personal Data Schema and Query Grammar for AI Agents

1.1. Scope

The Protocol specifies what Sygil-shaped data is on the wire. It does not specify:¶

• A storage substrate. Records may be stored in any database, file system, or in-memory representation.¶

• An encryption-at-rest scheme. Storage encryption is a runtime concern.¶

• A specific authorization mechanism. The Protocol defines a vocabulary for capability and consent proofs but does not require any specific authorization framework (OAuth, UCAN, OpenFGA, Cedar, ODRL, or any other) to underlie that vocabulary.¶

• A federation protocol. Multi-vault synchronization, cross-user record sharing, and replication are runtime concerns.¶

• A transport protocol. Records may be carried over HTTP, the Model Context Protocol [MCP], or any other transport.¶

• An identity provider. The Protocol uses Decentralized Identifiers ([W3C-DID]) to identify data subjects but does not issue, verify, or resolve them; resolution semantics are bound by DID method.¶

These boundaries are load-bearing. The Protocol is useful precisely because it can be adopted without committing to any specific vault, authorization framework, or transport. Sygil-shaped records can be produced by a connector wrapping a third-party API and consumed by a local-first application, with no intermediary vault, no authorization server, and no network protocol shared between producer and consumer beyond the medium that carries the bytes.¶

1.2. Relationship to vault implementations

Sygil distinguishes the Protocol -- the schema and query grammar specified by this document -- from vault implementations, which operationalize storage, encryption, authorization, audit, and trust enforcement on top of Sygil-shaped data. The Protocol/vault relationship is analogous to the relationship between the Linux kernel ABI and a specific Linux distribution: the kernel ABI is the open standard that multiple distributions share; each distribution makes its own opinionated runtime choices. Conformance to the Protocol does not require adoption of any specific vault implementation, and competing vault distributions are expected.¶

1.3. Status of this document

This document is an Internet-Draft submitted as an Independent Submission. Its intended status is Informational. It specifies a data protocol -- a schema, identifier and serialization conventions, an optional proof-object vocabulary, and a minimal query grammar -- rather than a transport protocol or interaction model (see Section 3.2 for the classification rationale and prior-art comparison). The document documents an open schema and query grammar developed by Sygil PBC and published under the IETF Trust Legal Provisions to facilitate community review, alignment with related IETF work (including OAuth 2.0 [RFC6749] extensions, DID resolution, and JSON canonicalization), and eventual standards-track follow-on work in relevant working groups.¶

A narrative companion to this specification, the Sygil Protocol Whitepaper [SYGIL-WP], sets out the motivation, the history of cross-domain personal-data standardization, the design principles, and the conditions that motivate the Protocol. That document is informational background; this Internet-Draft is the normative specification, and where the two differ this document governs.¶

This document does not obsolete or update any existing RFC.¶

1.4. Conventions

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

Throughout this document, the terms "Producer" and "Consumer" refer to the party that creates a Sygil record and the party that receives it, respectively. The terms "Subject" and "Vault" refer to the data subject the record is about and to a runtime that stores and serves Sygil records on a Subject's behalf, respectively. Section 2 defines these and other terms normatively.¶

Examples in this document are non-normative and use the example identifiers and domain names reserved by [RFC2606].¶

3.1. Goals

The Protocol is designed to satisfy four goals. The architectural commitments behind these goals -- in particular the decision to compose from existing standards rather than replace them, and to keep the Protocol orthogonal to storage, authorization, and runtime concerns -- are discussed further in [SYGIL-WP].¶

Cross-domain coverage. The Protocol provides a single coherent schema framework that spans identity, calendar, messages, finance, health, location, documents, preferences, media, tasks, commerce, claims, and channels (the v1 namespaces; see Section 4.7). Records in any namespace share the same envelope structure, the same identifier scheme, and the same canonicalization rule, so that Consumers reasoning across namespaces can do so uniformly.¶

Standards alignment. Each namespace declares mappings to existing external standards where they exist (vCard [RFC6350] for identity, iCalendar [RFC5545] for calendar, FHIR [FHIR-R4] for health, FDX [FDX] for finance, Internet Message Format [RFC5322] for messages, Schema.org [SCHEMA-ORG] for general entity vocabulary). Sygil does not replace these standards; it composes them under a uniform envelope and identifier scheme.¶

Runtime neutrality. A developer with a JSON Schema validator, an HTTP stack, and the canonicalization rule from Section 4.5 can produce and consume Sygil-shaped data without any vault, authorization server, or other runtime infrastructure. This is enforced architecturally: nothing in this document describes how a Vault stores, encrypts, or authorizes records.¶

Agent legibility. Sygil records are designed to be legible to AI agents without out-of-band context. Stable, predictable record types (NSIDs); predictable resource identifiers (sygil://); declared relationships between records; typed fields with documented semantics; a minimal, predictable query grammar; and optional proof metadata that agents can consume without verifying -- these properties together let an agent that has never encountered a particular Sygil-shaped record identify its type, parse it, follow its references, and reason about it.¶

3.2. Protocol nature and classification

This document specifies a data protocol: a schema, a set of identifier and serialization conventions, an optional proof-object vocabulary, and a minimal query grammar. It does not specify a wire protocol in the sense of a request/response interaction model, a session lifecycle, or a transport binding. Sygil records are carried over whatever transport the deployment chooses (HTTP, the Model Context Protocol [MCP], file-based exchange, others); the Protocol is what makes a JSON object recognizably and validatably a Sygil record on either side of that transport.¶

This classification is consistent with prior IETF practice for data-protocol specifications:¶

• [RFC8259] (The JavaScript Object Notation (JSON) Data Interchange Format) specifies a syntax and semantics without specifying any interaction model.¶

• [RFC5545] (Internet Calendaring and Scheduling Core Object Specification, iCalendar) specifies a record format, a set of property and component definitions, and conventions for cross-system exchange -- without specifying a wire protocol per se. (iCalendar Transport-Independent Interoperability Protocol, RFC 5546, is a separate document.)¶

• HL7 FHIR [FHIR-R4] (referenced informatively here, as it is not an IETF specification) follows the same shape: a resource model with normative wire format, with REST and other transport bindings defined separately.¶

Sygil follows the same shape. The wire format (envelope, identifier scheme, canonicalization, namespace declarations, proof object vocabulary) is normative; transport bindings, request/response patterns, and runtime composition are out of scope. A future Sygil specification may define a transport binding; this document does not.¶

3.3. Non-goals

The Protocol explicitly does not require, and rejects any attempt to require:¶

• A specific storage substrate.¶

• Encryption at rest.¶

• A specific transport protocol.¶

• A specific authorization mechanism, framework, or policy language.¶

• A specific federation primitive, replication scheme, or cross-Vault synchronization protocol.¶

• A specific identity-provider relationship beyond the use of DIDs.¶

• Witness cosigning, transparency logs, or other trust infrastructure beyond the optional sygil.proof.audit and sygil.proof.attestation proof objects, whose verification is out of scope.¶

The Protocol MAY define fields and proof object types that allow these systems to express output (for example, sygil.proof.capability references a capability token by ID and hash; sygil.proof.attestation references an attestation report by URI). It does not require those systems to exist or to be used.¶

This document does not specify how a Vault implementation computes an authorization decision, derives a proof object from underlying policy state, or evaluates trust across multiple proof objects. These are runtime concerns. The Protocol specifies only the on-the-wire vocabulary by which the result of such a computation may be conveyed.¶

3.4. Major components

A Sygil-shaped data system is built from five components, each specified in subsequent sections of this document. This subsection introduces them at the conceptual level so that subsequent sections have an established vocabulary to reference.¶

3.5. Reference architecture

The Protocol contemplates four roles that interact through Sygil- shaped records:¶

            +------------+        produces        +-----------+
   Subject  |  Producer  | ---------------------> |  Vault    |
   (DID)    | (Connector,| <- - - - - - - - - - - | (storage, |
            |  Agent,    |    optional sync       |  access   |
            |  Subject   |                        |  control) |
            |  herself)  |                        +-----+-----+
            +------------+                              |
                                                        | serves
                                                        v
            +------------+         queries        +-----------+
            |  Agent     | <--------------------- |  Consumer |
            |  (LLM,     | ---------------------> | (Agent,   |
            |  app, ...) |        records         |  app, or  |
            +------------+                        |  another  |
                                                  |  Vault)   |
                                                  +-----------+

   Wire boundary: Sygil records (envelope + namespace fields + _proofs)
   Out of scope:  Vault internals, transport, authorization computation

The wire boundary -- what crosses between parties -- is the subject of this document. What happens inside the Vault to produce records served to a Consumer is the subject of vault-implementation specifications.¶

3.6. Composition with external standards

The Protocol composes with existing standards in three ways.¶

Aligned namespaces (Section 4.7) declare their primary external binding. A sygil.v1.calendar.event record aligns to iCalendar [RFC5545] and Schema.org Event; a sygil.v1.health.observation record aligns to FHIR Observation [FHIR-R4]; a sygil.v1.identity.person record aligns to vCard 4.0 [RFC6350] and Schema.org Person. Implementations are not required to emit external forms; the alignment exists so that Consumers already speaking the external vocabulary can map Sygil records into it via published JSON-LD contexts (Section 4.7).¶

Referenced vocabularies (Section 5) appear in proof object types. The sygil.proof.consent proof object refers to consent receipts that may follow the W3C Data Privacy Vocabulary, ISO/IEC TS 27560:2023 [ISO-27560], or other consent-receipt schemes. The sygil.proof.capability proof object refers to a capability token by identifier and hash; the token format itself is unspecified by the Protocol but is commonly UCAN, OAuth 2.0 access token, or a similar construct.¶

Informative comparators include the AT Protocol repository format [ATPROTO] (whose Lexicon discipline inspires the Sygil NSID immutability rule), W3C Verifiable Credentials [W3C-VC2] (which the reserved sygil.v1.credential.* namespace will adopt verbatim when specified), and the Model Context Protocol [MCP] (a common transport for agent-mediated record retrieval). None of these are normative dependencies of this document.¶

The Protocol does not require any specific authorization framework. Implementations are free to compose policy frameworks (OAuth 2.0 [RFC6749], OAuth 2.0 Demonstrating Proof of Possession [RFC9449], OAuth 2.0 Rich Authorization Requests [RFC9396], capability tokens, authorization engines such as OpenFGA or Cedar, or policy languages such as ODRL [W3C-ODRL] or the W3C Data Privacy Vocabulary) as best fits their deployment; the Protocol's role is to define the vocabulary by which the result of such authorization (a proof object) travels with a record. How the proof object was derived is a runtime concern.¶

3.7. Architecture boundary

The boundary between Protocol and runtime is enforced throughout this document. Anywhere this document slips into runtime specification -- storage, encryption, authorization computation, audit log structure, Vault federation -- the text is wrong and should be moved to a vault-implementation specification.¶

The reverse holds for vault-implementation specifications: anywhere they specify the on-the-wire shape of a record, identifier, hash, or proof object, they are duplicating this document. The Protocol is the single source of truth for wire format; vault specifications are the single source of truth for runtime behavior.¶

The table below makes the boundary explicit. For each Sygil-relevant concern, the table indicates whether the Protocol defines it, defines vocabulary for it without specifying behavior, or treats it as out-of-scope. The latter two columns are not normative for this document; they are shown to make the runtime delegation auditable.¶

A row that says "Defines" in the Protocol column means the specification for that concern lives in this document; vault implementations use what the Protocol defines. A row that says "Out of scope" means this Protocol will reject any attempt to specify the concern; the vault implementation's specification is where it belongs. A row that says "Optional proof vocabulary" or "Optional proof reference" means the Protocol defines a way for the result of the runtime concern to be carried on the wire (as a proof object or proof field) without specifying the runtime concern itself.¶

4.1. Record

A Sygil record is a JSON object [RFC8259] carrying the envelope fields defined in this section plus namespace-specific fields defined by the record's NSID.¶

Record identity is defined strictly by the id URI (Section 4.4): two records with the same id are the same record version, and two records with the same stable_id (Section 4.6) are versions of the same logical record. Semantic equivalence beyond identity -- whether two records "represent the same thing" in some application sense when their id URIs differ -- is out of scope for this Protocol. Applications and Consumers that need semantic equivalence relations construct them outside the Protocol.¶

Identity entails deduplication. Records with identical id URIs represent the same canonical content; differences in fields excluded from the content hash (_proofs, updated_at, version, supersedes, obsolete, obsolete_reason -- see Section 4.5) MUST NOT be treated as creating distinct record identities for caching, deduplication, storage, or transport purposes. Two encounters with the same id are encounters with the same record, even if the encounters differ in proof attachments.¶

This rule prevents a class of implementation divergences in storage and transport layers. An implementation that stored two records with the same id separately because their _proofs arrays differed would be holding what the Protocol considers one record as two; downstream Consumers retrieving via either copy would receive divergent views of the same canonical content. The current text makes this explicit so that storage, caching, and deduplication implementations align on what counts as one record.¶

A Consumer that needs to track multiple proof variants of the same record (for example, an audit log that records every proof attachment seen for a given id) MUST use a separate implementation-private metadata structure keyed on the id URI; it MUST NOT model these as separate records under the Protocol's identity rules.¶

4.2. Envelope

nsid           = core-nsid / community-nsid

core-nsid      = "sygil." version "." namespace "." record-type
                 ; e.g., "sygil.v1.calendar.event"

community-nsid = "sygil.community." publisher "." namespace "."
                 record-type
                 ; e.g.,
                 ; "sygil.community.acme.example.com.media.album"

publisher      = label *( "." label )
                 ; reverse-DNS publisher identifier

4.3. NSID (namespace identifier)

NSIDs use reverse-DNS structure to distinguish core Sygil namespaces (prefix sygil.) from third-party namespaces (prefix is the publisher's reverse-DNS domain).¶

Examples:¶

sygil.v1.calendar.event
sygil.v1.identity.person
sygil.v1.finance.transaction
com.example.customapp.myrecord

The reverse-DNS pattern is consistent with prior practice for vendor extensions, including the AT Protocol Lexicon system [ATPROTO] and the recommendation in [RFC6648] to use reverse-DNS or domain-prefixed naming for vendor extensions to existing protocols.¶

4.4. sygil:// URI scheme

The sygil:// URI scheme is the content-addressed identifier scheme used as a record's id. Its grammar is:¶

The grammar of the sygil:// URI, in ABNF [RFC5234], is:¶

sygil-URI    = "sygil://" subject-did "/" nsid "/" content-hash

subject-did  = "did:" method-name ":" method-specific-id
                 ; structure governed by [W3C-DID];
                 ; method-specific-id is opaque to this Protocol
                 ; (see Section 4.9)
method-name  = 1*( ALPHA / DIGIT )
method-specific-id = 1*( unreserved / pct-encoded / ":" )

nsid         = label *( "." label )
                 ; reverse-DNS structure (see Section 4.3)
label        = ( ALPHA / DIGIT ) *( ALPHA / DIGIT / "_" / "-" )

content-hash = algorithm "-" 1*base64url-char
algorithm    = 1*( ALPHA / DIGIT )
                 ; v1 implementations MUST emit "blake3"
base64url-char = ALPHA / DIGIT / "-" / "_"
                 ; base64url alphabet per [RFC4648] Section 5,
                 ; encoded WITHOUT padding ("="). A BLAKE3-256
                 ; digest (32 octets) encodes to exactly 43
                 ; characters.

unreserved   = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded  = "%" HEXDIG HEXDIG

ALPHA, DIGIT, and HEXDIG are the core rules defined in [RFC5234] Appendix B.1.¶

Example:¶

sygil://did:web:vault.example.com/sygil.v1.calendar.event/blake3-Cn8vJk2qR7sT1uV4wX9yZ0aB3cD6eF8gH1iJ2kL4mN5

4.5. Canonical serialization

Content-addressed identifiers require deterministic serialization. Without a precise canonicalization rule, two implementations can produce different id values for the same logical record, and the content-addressing model collapses.¶

Sygil mandates JSON Canonicalization Scheme (JCS) per [RFC8785].¶

4.6. stable_id (logical-identity URI)

Every v1 record carries a stable_id, which identifies the record across versions; for mutable record types it is the stable handle that successive versions share. Its grammar, in ABNF [RFC5234], is:¶

sygil-stable = "sygil-stable:" nsid-short ":" logical-hash

nsid-short   = label ":" label
                 ; the last two dot-separated components of the NSID,
                 ; with the dot replaced by a colon
                 ; (e.g., "calendar:event", "identity:person")

logical-hash = algorithm "-" 1*base64url-char
                 ; algorithm, base64url-char, and hash format identical
                 ; to those used in content-hash (Section 4.4)

(label and algorithm are as defined in Section 4.4.)¶

Example:¶

sygil-stable:calendar:event:blake3-3a4b5c...

4.7. Reference resolution semantics

Sygil's two URI forms -- sygil:// (content-addressed, identifies a specific version) and sygil-stable: (logical-identity, identifies a record across versions) -- present different resolution properties. This section specifies the resolution model the Protocol expects of Consumers, while remaining silent on the mechanism by which resolution is performed (mechanism is a runtime concern).¶

4.8. References

Records reference other records by sygil:// URI. Two reference patterns are defined.¶

"organizer": "sygil://did:example:user/sygil.v1.identity.person/blake3-abc..."

"attendees": [
  {
    "@type": "sygil.v1.calendar.attendance",
    "person": "sygil://did:example:user/sygil.v1.identity.person/blake3-xyz...",
    "response_status": "accepted"
  }
]

4.9. DID handling

DIDs appear throughout the Protocol: in the sygil:// URI prefix, in the optional subject_did, issuer_did, and subjects[] envelope fields, and in foreign references in namespace-specific fields. Because DID methods proliferate (did:web, did:key, did:plc, did:ion, did:ethr, did:cheqd, others), any conforming implementation will encounter unfamiliar DID methods over time.¶

4.10. v1 namespaces

The v1 schema, specified canonically in the companion Sygil Protocol Schema document referenced in Section 11 (Informative References), defines a namespace set structured as 10 production-depth namespaces, 2 minimal-shape namespaces, and 3 NSID-reserved namespaces. The production-depth ten are specified at full depth in the Schema (every field, enum, supporting object, normalization mapping, and conformance test resolved). The minimal-shape two ship in v1 with a single record type each at minimal-but-extensible depth. The NSID- reserved three commit reverse-DNS namespace identifiers in v1 without committing internal structure; full specification awaits a v1.x patch when forcing functions accumulate.¶

The sygil.v1.credential.* namespace is reserved for a future specification that will adopt the W3C Verifiable Credentials data model [W3C-VC2] verbatim.¶

The sygil.v1.social namespace models the data subject's social presence: content the subject deliberately published to a public audience (posts, replies, reposts, quote-posts) and the relationships and actions the subject owns (follows, blocks, mutes, likes, lists, and list memberships). It is scoped to subject-authored-and-subject- owned data; third-party statements about the subject (tags, mentions, posts by others) and identity-level inbound engagement (the identities of accounts that interacted with the subject's posts) are out of v1 scope. Two classes of social-platform data route to other namespaces rather than to sygil.v1.social: profiles map to sygil.v1.identity (a profile is an identity record; the platform handle is carried as an identity attribute), and direct messages map to sygil.v1.message (a direct message is structurally a message). The social namespace is the first to use the intent-posture classification axis described in Section 9 (Privacy Considerations).¶

The sygil.v1.conversation namespace models the data subject's archive of conversations with AI models: threads and turns (core), plus standing instructions, persisted model-held memory, and projects (extended). It is an ImportOnly namespace -- the major LLM providers expose conversation completions over their APIs but not the subject's conversation archive, so the only acquisition path is the provider's self-serve data export, and the subject's upload of that export is the grant event (Section 7 cooperation modes export_only and user_mediated_capture; no new mode is introduced). A thread is the subject's archived artifact (subject_scope sole); a turn carries the archival subject explicitly and represents authorship separately, via a role and an author-kind plus an optional model slug, so that non-human turns are owned by the subject without being authored by the subject and the model is never modeled as a person. No conversation- archive standard exists; the two flagship export shapes (a branch- capable node graph and a flat ordered list) both normalize to turns plus a parent-turn edge, with branch state preserved. Content blocks use a closed type enumeration for query stability plus an open subtype and a lossless source-native escape hatch, so that block types a future model product invents are preserved rather than dropped. Every conversation record is highly sensitive by default (Section 9).¶

The Protocol does not require implementations to support all v1 namespaces. Conformance is asserted per (namespace, tier) pair (Section 6.2). For minimal-v1.0 namespaces, conformance is against the single record type that v1 specifies; for NSID-reserved namespaces, no v1 conformance surface exists until the full structure ships in a v1.x patch.¶

4.11. Query response envelope

A query response wraps zero or more records in the following envelope:¶

{
  "type": "sygil.v1.calendar.event",
  "cursor": "opaque-pagination-cursor",
  "records": [ /* zero or more records */ ]
}

Optional fields:¶

Per-record proof objects travel inside each record's _proofs field. The query response envelope itself does not embed authorization metadata, aggregate proof information, or audit information; aggregate runtime concerns are not part of the Protocol.¶

4.12. Query grammar

This section specifies a minimal, portable query semantics that any Tier 2 implementation MUST honor. The grammar is deliberately small -- its purpose is to define a stable interoperability surface, not a full query language. Implementations MAY expose richer query surfaces (GraphQL, MCP tool primitives, multi-hop traversal, full-text ranking, aggregation) on top of the Protocol's grammar; those richer surfaces are out of scope.¶

query        = parameter *( "&" parameter )

parameter    = type-param
             / time-range-param
             / equality-param
             / reference-param
             / text-search-param
             / pagination-param
             / quality-param

type-param   = "type=" nsid
time-range-param = ( "start_after="  iso8601 )
                 / ( "start_before=" iso8601 )
                 / ( "end_after="    iso8601 )
                 / ( "end_before="   iso8601 )
equality-param = field-name "=" field-value
reference-param = field-name "=" sygil-URI
text-search-param = "q=" 1*VCHAR
pagination-param = ( "limit=" 1*DIGIT )
                 / ( "cursor=" opaque-token )

quality-param = freshness-min-param
              / completeness-min-param
              / verifiability-min-param
              / cooperation-mode-in-param

freshness-min-param = "freshness_min=" freshness-value
completeness-min-param = "completeness_min=" completeness-value
verifiability-min-param = "verifiability_min=" verifiability-value
cooperation-mode-in-param = "cooperation_mode_in="
                            mode-value *( "," mode-value )

freshness-value = "realtime" / "hours" / "days" / "weeks" / "unknown"
completeness-value = "authoritative" / "best_effort" / "partial"
                   / "known_incomplete" / "unknown"
verifiability-value = "source_signed"
                    / "sygil_signed_after_ingestion"
                    / "unsigned" / "disputed" / "unknown"
mode-value   = "native_sygil" / "cooperative_api" / "restricted_api"
             / "export_only" / "user_mediated_capture"
             / "manual_subject_assertion" / "unknown"

field-name   = 1*( ALPHA / DIGIT / "_" )
field-value  = 1*VCHAR
                 ; URL-percent-encoded if necessary
nsid         = label *( "." label )
                 ; per Section 4.3
iso8601      = 1*VCHAR
                 ; an ISO 8601 timestamp per [RFC3339]
sygil-URI    = "sygil%3A%2F%2F" 1*VCHAR
                 ; URL-percent-encoded form of a `sygil://` URI
                 ; per Section 4.4
opaque-token = 1*VCHAR
                 ; an implementation-defined cursor; treated as
                 ; opaque by the Consumer

5.1. Role of proof objects

Proof objects are optional vocabulary. A record without any _proofs is structurally valid. Consumers MAY ignore proof objects entirely; doing so does not invalidate the record. The presence of a proof object on a record asserts that the Producer claims the relevant property (provenance, capability, consent, attestation, or audit); whether the claim is correct is a separate question that verification (an out-of-scope runtime activity) determines.¶

The expectation that proof objects are populated rises with the adoption tier (Section 6):¶

• Tier 1 records do not require any proof objects.¶

• Tier 2 records sourced from upstream systems SHOULD carry sygil.proof.provenance. Records imported from a connector classified by the runtime as authoritative MUST carry it (Section 5.4).¶

• Tier 3 records served under agent access carry capability and consent proofs, with provenance baseline and attestation and audit proofs added as their respective trust claims are made. Integrity is implicit at every tier via the content-addressed id; no separate proof type is required.¶

The Protocol's vocabulary establishes consistent shapes for these claims so that Consumers across implementations can recognize them without per-implementation parsing.¶

5.2. Common proof object structure

All proof object types defined in this section share a common shape. Each proof object is a JSON object carrying:¶

• A required @type field whose value is the proof type's NSID (sygil.proof.provenance, sygil.proof.capability, sygil.proof.consent, sygil.proof.attestation, sygil.proof.audit, or a third-party reverse-DNS extension).¶

• A required @type-specific body of fields whose semantics are defined per type in Section 5.4 through Section 5.8.¶

• Where applicable, an issued_at field (ISO 8601 timestamp with timezone, per [RFC3339]) indicating when the proof was issued by the producing party.¶

The Protocol does not require proof objects to carry signatures inline. A signed proof object MAY embed a signature (typically as a JWS-shaped [RFC7515] field over the canonical serialization of the remaining fields), MAY reference an out-of-band signature, or MAY remain unsigned. The choice is per-type and per-deployment; signed forms allow Consumers to verify the proof against a public key, and unsigned forms are useful when the binding to the record's content-addressed identifier is sufficient.¶

The proof object's binding to the record is positional: the proof appears in the record's _proofs array. The record's id URI binds the proof to the record's content-addressed identity (because the _proofs array is excluded from the content hash, the proof can be added or removed without changing the id; the proof's claim is about the record identified by that id, not about the bytes including the proof).¶

A proof object MUST NOT depend on its position within the _proofs array; arrays are ordered but the order is not significant for any proof type defined in this document.¶

The remaining subsections specify the type-specific body for each defined proof type. Section 5.3 first specifies the interpretation model that applies across all types.¶

5.3. Proof semantics and interpretation model

This section specifies the wire-vocabulary semantics that apply to proof objects across types: how a Consumer interprets multiple proofs on a record, how proof types compose, what conflicts mean, and what minimum behavior the Protocol expects.¶

The Protocol does not specify how a Consumer evaluates trust given the presence or absence of proofs -- that is a runtime, deployment, and trust-anchoring concern. The Protocol does specify the structural rules a Consumer follows to read the wire vocabulary correctly.¶

5.4. sygil.proof.provenance

Attests the upstream source from which the record was derived, including trust dimensions describing how the data was acquired.¶

{
  "@type": "sygil.proof.provenance",
  "source_system": "google_calendar",
  "source_record_id_hash": "blake3-source-id-hash...",
  "connector_id": "sygil.connector.google_calendar.v1",
  "imported_at": "2026-04-26T10:14:00Z",

  "cooperation_mode": "cooperative_api",
  "freshness": "hours",
  "completeness": "authoritative",
  "verifiability": "sygil_signed_after_ingestion",
  "mode_transition_history": []
}

5.5. sygil.proof.capability

Attests that the access represented by this record was authorized by a capability token.¶

{
  "@type": "sygil.proof.capability",
  "token_id": "ucan:blake3-tokenid...",
  "token_hash": "blake3-tokenhash...",
  "issued_at": "2026-04-26T10:14:00Z"
}

The Protocol does not specify the capability token format. UCAN, OAuth 2.0 access tokens with rich authorization requests [RFC9396], custom capability formats, and other constructs are all permitted. The proof identifies a token by ID and hash; verification -- fetching the token, checking signatures, evaluating caveats -- is a runtime concern.¶

5.6. sygil.proof.consent

Attests that a consent receipt covers the access that produced this record.¶

{
  "@type": "sygil.proof.consent",
  "receipt_id": "rcp:blake3-receiptid...",
  "dpv_categories": ["dpv:Schedule", "dpv:Communication"],
  "purpose": "scheduling_assistance",
  "legal_basis": "dpv:Consent",
  "issued_at": "2026-04-26T10:14:00Z"
}

Consent receipts MAY follow the W3C Data Privacy Vocabulary, ISO/IEC TS 27560:2023 [ISO-27560], or other consent-receipt schemes. The Protocol specifies the proof-object shape; the receipt format itself is a runtime concern.¶

5.7. sygil.proof.attestation

Attests that the record was produced inside a verifiable execution environment.¶

{
  "@type": "sygil.proof.attestation",
  "attestation_report_uri": "sygil://did:web:vault.example.com/sygil.v1.attestation.report/blake3-...",
  "tee_type": "amd-sev-snp",
  "issued_at": "2026-04-26T10:14:00Z"
}

The Protocol does not mandate that a record carry an attestation proof, nor that Consumers verify one. Attestation verification is typically tied to specific TEE platforms and trust-anchor management disciplines (RATS [RFC9334] provides the architectural framing) and is out of scope for this document.¶

5.8. sygil.proof.audit

Attests that the access generating this record was logged in a per-user audit log.¶

{
  "@type": "sygil.proof.audit",
  "log_entry_uri": "sygil://did:web:vault.example.com/sygil.v1.audit.entry/blake3-...",
  "logged_at": "2026-04-26T10:14:00Z"
}

The structure of audit log entries, the cryptographic protections of the log (signed records, transparency log integration, witness cosigning), and the rules under which entries are produced are runtime concerns and out of scope for this document.¶

5.9. Composition and extensibility

A record's _proofs field is an array of zero or more proof objects. Multiple proof objects of the same @type MAY appear (for example, a record with both a subject-attested integrity proof and a Vault-attested integrity proof). The order of proof objects in the array is not significant.¶

Proof object types are extensible. A Producer MAY define a new proof object type using the reverse-DNS pattern (e.g., com.example.custom-proof-type). Unknown proof types MUST NOT cause a Consumer to reject the record. Consumers MAY ignore unknown proof types; doing so does not invalidate the record. Consumers MUST preserve unknown proof types when forwarding records.¶

The sygil.proof.* namespace is reserved for proof types defined by the Sygil specification. Future Sygil-defined proof types will appear in this namespace; third-party extensions MUST use the third party's own reverse-DNS prefix.¶

A Sygil Proof Object Types registry is to be established with IANA per Section 10 (IANA Considerations) to track the Sygil-namespace proof types and provide a stable reference for extensions registered through the Specification Required policy.¶

5.10. What this section does not specify

For clarity, this section does not specify:¶

• How a Producer decides whether to issue a proof object.¶

• How a Vault implementation composes underlying policy frameworks (OAuth 2.0 [RFC6749] and its extensions [RFC9449] [RFC9396], capability tokens, authorization engines, policy languages such as ODRL [W3C-ODRL], and so on) to derive the state that a proof object describes.¶

• How proof objects are revoked.¶

• How trust is established between a Consumer and an unfamiliar Producer of a proof object.¶

• The cryptographic verification procedure for any specific proof type beyond the integrity proof's hash recomputation.¶

These are runtime, deployment, and governance concerns addressed by vault-implementation specifications and by deployment-specific trust documents.¶

6.1. Tiers

The Protocol defines three adoption tiers. Each is a strict superset of the previous.¶

6.2. Per-namespace conformance

Conformance is asserted per (namespace, tier) pair. An implementation that supports sygil.v1.calendar.event fully but does not support sygil.v1.finance.transaction at all is conformant for calendar and silent for finance. There is no requirement to implement the full v1 namespace set to claim Tier 1 conformance.¶

An implementation MAY claim Tier 1 conformance for one namespace and Tier 2 conformance for another. The conformance assertion is fine-grained.¶

6.3. Schema language and generated artifacts

The Sygil schema is authored in LinkML [LINKML], a YAML-based schema modeling language with multi-target code generation. LinkML serves as the single source of truth for namespace structure; from the LinkML source the Protocol's specification maintainers generate the artifacts implementations consume directly:¶

• JSON Schema 2020-12 ({namespace}.schema.json) -- the wire validation artifact. Records validate against the JSON Schema for their declared NSID; this is the artifact the Tier 1 schema- validation conformance test category references.¶

• JSON-LD context ({namespace}.context.jsonld) -- the vocabulary-mapping artifact described in Section 4.2.6. Optional for Sygil-native Consumers; the path to interop for tools speaking Schema.org, W3C VC, or FHIR vocabularies.¶

• GraphQL SDL fragments ({namespace}.graphql) -- informative; for Tier 2 implementations exposing GraphQL surfaces.¶

• SHACL shapes ({namespace}.shacl.ttl) -- informative; for semantic-web consumers requiring shape constraints.¶

• SDK type definitions per language ({namespace}.types.ts, .py, .go, .rs, .swift) -- informative; convenience artifacts for application authors.¶

• Example record corpora ({namespace}.examples.json, {namespace}.invalid.json) -- the test fixtures referenced by the conformance test categories below.¶

• Normalization rule documents ({namespace}.normalization.md) -- informative; mappings to and from external source systems.¶

The JSON Schema artifact is normative for conformance: a Tier 1 implementation that emits records claiming to be of a given NSID MUST emit records that validate against the JSON Schema for that NSID. The other artifacts are informative; their availability is a deliverable commitment of the Protocol's specification maintainers but their use is not required for any tier of conformance.¶

The artifacts are byte-reproducible from the LinkML source: the specification maintainers operate continuous integration that regenerates artifacts on every schema source change and rejects commits where committed artifacts diverge from regenerated artifacts. The byte-reproducibility property lets implementations rely on the artifacts without re-running the LinkML generator locally.¶

6.4. Conformance test categories

A claim of Tier 1 conformance against a namespace means passing the schema validation, identifier, canonicalization, and proof-object preservation tests for that namespace. A claim of Tier 2 conformance adds the query tests. Tier 3 conformance is asserted against a separate test suite, specified by vault-implementation documents, that exercises proof attachment, audit log presence, and per-Subject isolation.¶

The test categories are:¶

Test fixtures, expected outputs, and the test harness itself are deliverables of the Sygil Protocol companion documents and are out of scope for this Internet-Draft.¶

6.5. Compatibility policy

The compatibility rules below apply across all conformant implementations.¶

7.1. Invalid records (schema validation failure)

A record is invalid when it fails to validate against the schema for its declared NSID.¶

• Producers MUST NOT emit invalid records.¶

• Consumers MUST reject records that fail schema validation against their declared NSID. Acceptance of an invalid record is itself a Protocol violation.¶

• Tier 2 surfaces SHOULD return a structured error envelope identifying which constraint failed.¶

• Consumers MUST NOT attempt to repair invalid records by inferring missing fields, coercing types, or substituting defaults.¶

7.2. Unknown namespaces

Covered by compatibility rule 2 above.¶

7.3. Malformed references

A reference is malformed when it does not parse as a sygil:// URI (Section 4.4) or a sygil-stable: URI (Section 4.6).¶

• Consumers MUST treat malformed references in required fields as invalid record content. Records containing such references fail schema validation.¶

• Records containing malformed references in optional fields SHOULD be accepted with the malformed reference field elided from the Consumer's view; the malformed value is preserved in implementation- private metadata for diagnostic purposes.¶

• Consumers MUST NOT silently substitute a default value (e.g., null or a placeholder URI) for a malformed reference.¶

7.4. Unresolvable references

A reference is unresolvable when its URI is well-formed but the referenced record cannot be retrieved.¶

The Protocol does not specify how references are resolved; resolution is a runtime concern. The Protocol does specify how Consumers represent the result:¶

• Consumers SHOULD distinguish three resolution states: resolved (the referenced record was retrieved), unresolved (well-formed reference, no record found or accessible), and forbidden (the reference resolved but access was denied).¶

• Consumers MUST NOT fabricate referenced record data when resolution fails. Returning a stub marked unresolved is correct; returning an empty record without indication is not.¶

• Tier 2 surfaces returning collections containing unresolved references SHOULD include a per-reference resolution status in the response envelope.¶

7.5. Unsupported enum values

Covered by compatibility rule 3 above.¶

7.6. Hash mismatches

A hash mismatch occurs when a record's id is supposed to equal BLAKE3(JCS(record_body)) (with the standard exclusions from Section 4.5) but does not.¶

• Tier 1 implementations are NOT required to verify hashes.¶

• Any implementation that claims to verify integrity (whether by recomputing the BLAKE3 hash and comparing to id, or by any other explicit integrity check) MUST treat hash mismatch as a hard failure: the record is corrupt or has been tampered with.¶

• A Consumer that detects a hash mismatch MUST NOT silently use the record as if it were valid. The minimum acceptable response is to mark the record as integrity-failed in any output that includes it.¶

• A Consumer that asserts integrity to its own callers (e.g., emits a "verified" flag, returns content as authoritative, persists the record under its id) MUST verify the content hash before doing so.¶

7.7. Unsupported schema versions

A Consumer that supports sygil.v1.* and encounters a sygil.v2.* record handles it under the unknown-NSID rule (compatibility rule 2): pass through, log, do not reject. The Consumer SHOULD log the unsupported version specifically so that operators can detect when their implementation is lagging the published schema. A Consumer asked to interpret a sygil.v2.* record as if it were sygil.v1.* MUST decline. There is no implicit version downgrade.¶

7.8. Failure mode summary

The "MUST NOT emit" Producer rules describe the strict-output side of the Postel's-law stance from Section 6.5. The Consumer rules describe the lenient-input side, with the constraint that leniency does not extend to silent corruption -- unknown content is preserved and surfaced, never dropped or fabricated.¶

8.1. Threat model

Per [RFC3552], the threat environment includes deployment across the global Internet across multiple administrative boundaries without assuming that firewalls are in place.¶

For Sygil, the threat model assumes:¶

• Producers, Consumers, Vaults, Subjects, and any intermediaries are each individually capable of being honest, compromised, or adversarial.¶

• Network paths between parties are fully adversarial: an attacker can observe, drop, modify, replay, and inject traffic.¶

• Endpoint compromise is in scope: a Producer's signing key, a Vault's storage, or a Consumer's verification logic may each be compromised.¶

• Pervasive monitoring [RFC7258] is in scope: an attacker capable of observing large volumes of traffic across the Internet is part of the adversary class.¶

The Protocol does not assume any specific transport-layer security posture. Implementations carry Sygil records over transports of their choosing (HTTP, MCP [MCP], others); transport security is the transport's responsibility.¶

8.2. What the Protocol does and does not protect

The Protocol provides:¶

• Structural integrity of records, via content-addressable identifiers (Section 4.4) and a deterministic canonicalization rule (Section 4.5). A Consumer that recomputes a record's content hash detects any modification that occurred after the Producer computed the original hash, modulo the standard hash exclusions.¶

• A vocabulary for trust evidence in the form of proof objects (Section 5). The vocabulary is sufficient for a Producer to claim integrity, provenance, capability, consent, attestation, or audit properties about a record, and for a Consumer to recognize and preserve those claims.¶

The Protocol does NOT provide:¶

• Confidentiality of records on the wire. The Protocol does not specify any encryption mechanism. Confidentiality is delegated to the transport (TLS for HTTP transport, encryption inherent to the transport for other carriers) and, where applicable, to Vault-level encryption-at-rest.¶

• Authenticity of unsigned records. A sygil:// URI is content-addressed, not signed. A record carrying no proof object is structurally valid but does not assert anything about who produced it. Authenticity comes from proof objects (notably sygil.proof.provenance) and from the underlying signing infrastructure that produces them.¶

• Authorization decisions. The Protocol's proof object vocabulary conveys evidence of authorization; the Protocol does not specify how a Vault decides to grant or deny access. Authorization is a runtime concern.¶

8.3. Confidentiality

Records on the wire are not confidential by Protocol design. A deployment requiring confidentiality MUST employ a transport that provides it (e.g., HTTPS with TLS 1.2 or later) or wrap records in an application-layer encryption envelope before transmission.¶

The hash exclusions in Section 4.5 do not affect confidentiality of the excluded fields: a record's _proofs, updated_at, version, supersedes, obsolete, and obsolete_reason fields all travel on the wire alongside the rest of the record. They are excluded from the content hash, not from the serialization. (The query response envelope's redaction_state field, defined in Section 4.10, is similarly visible on the wire; it is not part of the record envelope at all.)¶

The query response envelope's redaction_state field (Section 4.10) signals that a served record is a projection (redacted, summary, or hash_only) rather than the full original. Vault implementations that produce projections are responsible for ensuring that projected records do not inadvertently include redacted content; the Protocol provides the labeling but does not enforce the redaction.¶

8.4. Integrity

Integrity protection is provided by content-addressable identifiers. A Consumer that verifies hashes detects post-Producer modification of the canonicalized hash inputs.¶

Integrity is verified by recomputing the BLAKE3 content hash over the canonical serialization of the record (with the hash exclusions from Section 4.5) and comparing to the value encoded in the id URI. No separate proof object is required; the content hash is the integrity guarantee.¶

Integrity verification is OPTIONAL at Tier 1. Implementations that accept records without recomputing hashes are exposed to in-flight modification; the trade-off is a runtime decision. Implementations that claim to verify integrity (whether at Tier 1 by choice, or at Tier 2/Tier 3 as a baseline expectation) MUST treat hash mismatch as a hard failure per Section 7.¶

The hash exclusions in Section 4.5 mean that a malicious party can:¶

• Add, remove, or modify proof objects without changing the content hash.¶

• Update updated_at, version, supersedes, obsolete, or obsolete_reason fields without changing the content hash.¶

Consumers that depend on the integrity of these fields MUST obtain their assurances from elsewhere -- typically from a sygil.proof.audit proof object referencing a tamper-evident audit log, or from transport-layer signatures, or from a Vault implementation's out-of-band integrity guarantees.¶

8.5. Authenticity

A bare Sygil record asserts no authenticity. The producing party is implicit in the id URI's Subject DID (which identifies the data subject, not the producer) and in the optional issuer_did envelope field (which identifies the producer if populated, but is not signed by the Protocol).¶

Authenticity is conveyed by proof objects:¶

• sygil.proof.provenance (Section 5.5) asserts the upstream source and connector that produced the record. A Consumer that has a trust relationship with the named connector and that verifies the connector's signature on the proof can attribute the record to that connector.¶

• sygil.proof.attestation (Section 5.8) asserts that the record was produced inside a verifiable execution environment.¶

The Protocol does not specify how proof objects are signed. Common choices include JWS [RFC7515] over the canonicalized record with the proof object as the payload, or detached signatures referenced by URI.¶

8.6. Replay

A sygil:// URI is content-addressable: the same record body produces the same URI. A Consumer cannot distinguish a replayed delivery of a known record from a fresh delivery solely from the URI.¶

Where replay matters (e.g., a sygil.proof.capability proof should not authorize the same access twice), Consumers MUST rely on out-of-Protocol mechanisms: the capability token's own nonce or expiry, the audit log entry referenced by sygil.proof.audit, or transport-layer freshness signals (e.g., DPoP [RFC9449] when OAuth 2.0 is in use).¶

The envelope expires_at field (Section 4.2.4) signals retention expiry, not authentication freshness. A record whose expires_at has passed should be treated as expired by retention-aware Consumers but this is not a defense against replay of an authentication artifact.¶

8.7. Limits of Protocol-level guarantees

The Protocol's proof object vocabulary is sufficient for a Consumer to verify what a Producer claims:¶

• The claim's structure is valid (the proof object validates against its @type schema).¶

• The claim is correctly bound to the record (the proof appears in the record's _proofs array).¶

• The record's integrity can be verified locally against the canonicalized record by recomputing the BLAKE3 content hash and comparing to the value encoded in the id URI; this verification is performed without any proof object.¶

The Protocol's proof object vocabulary is NOT sufficient for a Consumer to verify whether a Producer's underlying claim is correct under any specific runtime policy. A Producer could be configured with a permissive runtime authorization policy and issue technically-valid sygil.proof.capability proofs for records that would not pass a stricter Consumer's policy. Protection against this -- typically by trust-anchoring Producers to a known issuer infrastructure, by verifying the underlying capability token, or by maintaining a Consumer-side policy that filters records by Producer trust -- is a deployment and trust-establishment concern, not a Protocol concern.¶

Consumers SHOULD NOT treat the presence of a proof object as evidence of underlying policy correctness. Proof objects are evidence of assertion by the Producer; verification of the assertion is a separate, runtime-defined activity.¶

8.8. Proof forgery

A proof object asserts a property of a record. The mechanism by which a Consumer concludes the assertion is genuine is signature verification: the proof's signature, computed over the proof's canonicalized body, must verify against the public key of the issuing party. The Protocol does not specify the signing mechanism; common choices include JSON Web Signatures [RFC7515] over the canonical serialization of the proof object body and detached signatures referenced by URI.¶

A proof forgery occurs when an attacker produces a proof object that appears valid but is not signed by the party it purports to come from. The Protocol's defenses are:¶

• Connector identity verification. A sygil.proof.provenance proof's connector_id field names the connector that produced the record. A Consumer that acts on provenance MUST verify the connector_id matches the connector's known identity per the minimum evaluation expectations of Section 5.3.4. Without that check, an attacker that knows a connector's identifier can mint forged provenance proofs at will.¶

• Issuer signature. A signed proof object binds the proof's contents to the issuing party's signing key. Forgery requires compromise of the signing key (Section 8.10) or a cryptographic break in the signature scheme.¶

• Independence rule. The Protocol's proof-independence rule (Section 5.3.1) means a forged proof of one type does not infer properties associated with other proof types. Forgery of a single proof type does not yield record-level forgery of all properties.¶

A Producer MUST NOT attach a proof object whose underlying claim it cannot defend; doing so is a Producer-side Protocol violation (a Producer that emits forged proof objects is a malicious Producer). The Protocol cannot prevent malicious Producers from emitting syntactically valid records; defense is at the Consumer side, by trust-anchoring the Producers and Vaults the Consumer is willing to accept proof objects from.¶

8.9. Trust downgrade attacks

A trust downgrade attack is one in which an attacker manipulates trust-bearing fields on a record to lower the apparent trust level the record claims, in a way that lets the attacker substitute a lower-trust record for a higher-trust one without triggering Consumer protections.¶

Three concrete attack patterns are addressable at the Protocol level:¶

• Provenance downgrade. An attacker substitutes a cooperation_mode: "user_mediated_capture" (user-mediated capture) provenance proof for a cooperation_mode: "native_sygil" (native integration) one, hoping the Consumer's quality-aware filter (cooperation_mode_in=native_sygil,cooperative_api, Section 4.10.6) will exclude the record from results -- denying the Consumer access to a record it was entitled to. Defense: the provenance proof is signed; substitution by a non-issuer fails signature verification.¶

• Authoritative-source bypass. An attacker emits a record from a connector locally known to the Consumer as authoritative, but without attaching a sygil.proof.provenance proof, hoping the Consumer will treat the record as authoritative without examining whether the proof is present. Defense: the conditional rule of Section 5.4.2 requires authoritative-source records to carry the proof; the Consumer MUST treat missing-proof cases as carrying a provenance-warning state and MUST propagate the warning to its caller, and MUST NOT silently treat the record as authoritative.¶

• Verifiability downgrade. An attacker claims verifiability: source_signed on a sygil.proof.provenance proof to mislead the Consumer's quality filter, while the underlying record is not source-signed. Defense: a Consumer that acts on the verifiability claim (e.g., requires verifiability_min= source_signed) MUST verify the source signature is actually present and verifies; the proof's claim alone is insufficient per the minimum evaluation expectations of Section 5.3.4.¶

The general principle is that trust claims at the wire level are evidence of assertion, not of correctness; a Consumer that needs correctness MUST verify the underlying cryptographic or external property, not rely solely on the proof's stated value.¶

8.10. Cross-domain correlation

Sygil's design intentionally enables cross-domain reasoning: an Agent holding records under subject_did = did:web:user.example.com for calendar, finance, health, location, and message namespaces can join across them by subject_did. This is a feature; it is also a re-identification surface.¶

The attack scenario is direct. An adversary who obtains records from multiple namespaces under the same subject_did can construct a profile far more identifying than any individual namespace's records provide. A calendar event for a doctor's appointment, a financial transaction for a copay, a health observation for a diagnosis, and a location record for a clinic -- joined by subject_did -- disclose information no individual record discloses.¶

Mitigations are deployment-level and policy-level, not Protocol-level:¶

• Authorization scoping. A Vault implementation SHOULD scope Consumer authorization per-namespace (or finer); a Consumer authorized for sygil.v1.calendar.event SHOULD NOT thereby be authorized for sygil.v1.health.observation under the same Subject. The Protocol's tier definitions (Section 6) require per-namespace scoping at Tier 2 and beyond.¶

• Per-context Subject DIDs. Subjects MAY adopt distinct DIDs for distinct contexts (e.g., a did:key per Consumer relationship); records under different DIDs are not joinable. The Protocol does not require this practice but allows it; the trade-off is that unlinkable records cannot be joined by Agents that should legitimately reason across them.¶

• Quasi-identifier discipline. Even with Subject DID concealed, envelope fields (created_at, updated_at, language[], connector_id) and per-namespace fields can themselves identify a Subject by joining attributes. A serious privacy posture requires Vault implementations to apply data-minimization at the projection layer (Section 4.2.6) and consider quasi-identifier exposure when serving cross-namespace results. Earlier drafts also listed an envelope jurisdiction[] field as a strong quasi-identifier; that field was removed in the v0.3 reconciliation, but runtime systems that derive jurisdictional binding from subject_did and source-system content should be aware that the same quasi-identifying signal exists in those derivations and should be handled with the same care.¶

The Protocol does not provide an in-band correlation-prevention mechanism. Section 9 (Privacy Considerations) addresses re-identification and linkability further; the formal Privacy Properties subsection (Section 9.1) makes explicit which protections the Protocol does and does not provide. Section 9.5 (Derived data amplification) addresses a related concern: derived records may disclose information beyond what their source records disclose individually, even before any cross-namespace join.¶

8.11. Algorithm agility

The Protocol pins:¶

• Hash algorithm: BLAKE3 [BLAKE3] for v1.¶

• Canonicalization: JCS per [RFC8785] for v1.¶

Algorithm agility is provided by major-version protocol bumps (sygil.v2.* may select different algorithms). Within v1, all implementations MUST agree on BLAKE3 and JCS; mixing algorithms within v1 produces non-reproducible content hashes and breaks the content-addressing invariant.¶

Implementations preparing for post-quantum-relevant changes should note that:¶

• BLAKE3 is a hash function; post-quantum cryptanalysis affects preimage and collision resistance and current consensus is that hash-function security degrades less than asymmetric primitives under quantum attack. BLAKE3 is acceptable for the v1 Protocol horizon.¶

• The Protocol does not specify any asymmetric primitive. Signatures on proof objects, transport-layer authentication, and DID-method cryptographic primitives are all out of Protocol scope. The cryptographic agility of these is the responsibility of the runtime layer that uses them.¶

8.12. Pervasive monitoring

Per [RFC7258], pervasive monitoring is an attack on confidentiality and on user privacy at scale. Sygil records, if observed in transit, reveal:¶

• The Subject DID (in the id URI prefix).¶

• The record type (@type NSID).¶

• The record contents (the body and the _proofs array).¶

The first two are revealed even when the body is encrypted, because they are part of the URI and the JSON envelope. Implementations that require subject-DID confidentiality on the wire MUST employ a transport or application-layer scheme that conceals them; the Protocol does not provide concealment for identifying envelope fields.¶

The proof-bearing response shape arguably increases traffic-analysis revelation compared to opaque-blob protocols, because each record carries its own metadata trail. Implementations sensitive to traffic analysis (high-stakes journalism, source protection, regulated populations under surveillance) SHOULD employ transport-layer mitigations (mixing networks, padding, dummy traffic) and SHOULD consider whether the Protocol's tier of detail is appropriate to their threat model.¶

8.13. Producer key compromise

A Producer's signing key (used to produce signed proof objects) is the hinge of authenticity for that Producer. Compromise of the key allows an attacker to forge proof objects asserting any property under that Producer's identity.¶

The Protocol does not specify a key-rotation, revocation, or key-compromise-recovery mechanism. These are runtime concerns, typically addressed by the underlying DID method's key-rotation support (where present) and by Vault-level revocation and re-issuance discipline.¶

A Consumer that detects a compromised Producer key SHOULD invalidate or downgrade trust in records carrying proofs signed by that key, through a Consumer-side policy outside the Protocol's scope.¶

8.14. Subject impersonation and Vault compromise

The Subject DID in a sygil:// URI is the identifier of the data subject; it does not authenticate them. A malicious party can mint records with any Subject DID and emit them as syntactically valid Sygil records. Defenses are:¶

• Producer-level authenticity (the Consumer trusts only records carrying proof objects from known Producers).¶

• Vault-level authentication (the Consumer obtains records only via a trust relationship with a Vault that is expected to authenticate Subject access).¶

• DID-method cryptographic primitives (e.g., signed Subject statements derived from the Subject's DID-controlled keys, as in Verifiable Credentials [W3C-VC2]).¶

A compromised Vault can produce records that appear to be authoritative for any Subject the Vault hosts. Consumers relying on a Vault as a trust anchor inherit the Vault's compromise. The Protocol does not specify Vault attestation; vault-implementation specifications may specify it via sygil.proof.attestation.¶

8.15. Denial of service

The Protocol specifies content hashes (computationally bounded by serialization size), schema validation (computationally bounded by schema size), and reference resolution (potentially network-bounded).¶

A malicious Producer can emit records:¶

• With pathologically large bodies, increasing canonicalization and hash cost.¶

• With many cross-references, increasing resolution cost on the Consumer.¶

• With deeply nested structure, stressing JSON parsers.¶

These vectors are general JSON-processing vectors and not Sygil-specific. Implementations SHOULD apply size limits to record bodies, depth limits to JSON parsing, and rate limits to reference resolution. The Protocol does not specify limits because they depend on deployment.¶

8.16. Privacy considerations

Privacy considerations specific to personal data carried by the Protocol are addressed in Section 9.¶

9.1. Privacy properties

This subsection makes explicit what the Protocol does and does not guarantee at the privacy level. The framing is deliberately formal: privacy guarantees that are not stated here are not provided. Implementations seeking specific privacy properties beyond those listed here must obtain them from runtime, deployment, or policy mechanisms outside the Protocol.¶

9.2. Data minimization

The Protocol does not enforce data minimization on records. A namespace specification declares which fields a record may carry; a Producer chooses which optional fields to populate.¶

Two Protocol features support data minimization at the runtime level:¶

• The redaction_state envelope field (Section 4.2.4) labels a served record as original, redacted, summary, or hash_only. Vaults producing projections for less-trusted Consumers SHOULD use these labels and SHOULD enforce that projections actually omit the excluded content.¶

• Per-namespace privacy classification. Each namespace specification declares default privacy classes (public, redacted, invisible) for individual fields. These are descriptive metadata for runtimes; the Protocol does not enforce them.¶

Implementations SHOULD apply data minimization at the projection layer: records served to Agents performing narrow tasks should carry only the fields necessary for the task. The Protocol provides the labels that make this discipline possible; the Vault implementation applies it.¶

9.3. Subject consent and control

The sygil.proof.consent proof object (Section 5.7) carries consent-receipt evidence on the wire alongside a record. Consent receipts MAY follow the W3C Data Privacy Vocabulary, ISO/IEC TS 27560:2023 [ISO-27560], or other consent-receipt schemes; the Protocol specifies the proof shape but not the receipt format.¶

The presence of a sygil.proof.consent proof object asserts that the Producer claims a consent receipt covers the access. As discussed in Section 8.7 (Limits of Protocol-level guarantees), the proof's presence is evidence of assertion, not of correctness. A Vault implementation is responsible for actually obtaining, recording, and honoring consent; the Protocol provides the wire vocabulary for referencing the resulting receipt.¶

A Subject's withdrawal of consent is reflected in the envelope via obsolete: true with obsolete_reason: withdrawn_consent. Runtime cascades -- propagating the withdrawal to derived records, to caching Consumers, to downstream Agents -- are runtime concerns and not specified by the Protocol.¶

9.4. Re-identification

Sygil records carry rich personal data and explicit cross-namespace references. A record's subject_did is by design stable across all records about the same Subject; this enables interoperability but also makes cross-domain join attacks straightforward for an attacker with access to records across namespaces.¶

The Protocol's subject_did is intentionally linkable. Implementations that require unlinkable Subject identifiers MUST employ a different identifier scheme outside the Protocol; the trade-off is that unlinkable records are not interoperable across namespaces, which defeats much of the Protocol's purpose.¶

Specific re-identification considerations:¶

• Cross-namespace joins. A subject_did shared across calendar, health, and finance records yields a much more identifying profile than any single namespace's records. Implementations serving records across namespaces SHOULD apply per-namespace authorization and SHOULD NOT serve unrestricted cross-namespace queries without policy controls.¶

• Quasi-identifiers in metadata. Envelope fields such as created_at, updated_at, language[], and the connector_id and imported_at fields of sygil.proof.provenance can themselves be quasi-identifying. A record claiming language ["pt-BR"] and import via a specific Brazilian banking connector identifies the Subject's locale and banking relationship even if the Subject DID is concealed. Earlier drafts also included a jurisdiction[] envelope field which would have been a strong quasi-identifier; that field was removed in v01, but runtime systems that derive jurisdictional binding from subject_did and source-system content should be aware that the same quasi- identifying signal exists in those derivations and should be handled with the same care.¶

• Reference graphs. The derived_from[] lineage and inline references between records form a graph that may be more identifying than any individual record. Anonymization of records does not anonymize the reference graph.¶

• Social graphs are strong quasi-identifiers. The sygil.v1.social namespace carries the Subject's follow, block, mute, and like edges. A social graph is among the strongest quasi-identifiers in the Protocol: an individual's set of follows is frequently near-unique, and block and mute lists reveal conflict, estrangement, and private judgment that the Subject specifically chose not to make public. The Protocol classifies follow and like edges as redacted and block and mute edges as invisible by default for this reason (the social namespace's privacy classification hints), but implementations should treat the aggregate social graph as more sensitive than any single edge, and should be aware that joining a Subject's social graph with their public posts (which the Subject deliberately published) is a powerful correlation surface even though the posts themselves are public.¶

9.5. Intent posture and deliberately-published content

The sygil.v1.social namespace introduces content that is public by the Subject's deliberate act -- posts, replies, reposts, and quote-posts the Subject broadcast to a public audience. This is a different privacy posture from every other namespace in the Protocol, where the default is protect-unless-told-otherwise. To represent it, the Schema defines a second field-classification axis, the intent posture (public_by_intent), orthogonal to the sensitivity axis (public / redacted / invisible).¶

The intent posture makes a narrow assertion: that re-exposing content the Subject deliberately published is not a new disclosure of originally-private data, because the content was never private. It does not assert that the content is safe to surface in any context -- re-surfacing appropriateness remains the joint product of the sensitivity axis and the projection context. A Subject can deliberately publish sensitive content (a public post disclosing a medical condition); such a field is public_by_intent (the Subject broadcast it) and may also warrant redacted sensitivity handling (an implementation should not casually re-surface it in unrelated contexts). The two axes are independent; neither is derivable from the other.¶

The posture attaches only to content the Subject authored or affirmatively published. It does not attach to content that is merely about the Subject, merely visible on a public platform, or merely retrievable through an API. In particular, a Subject's social graph (follows, blocks, mutes, likes) is not public_by_intent even when a platform exposes it publicly: platform exposure is the platform's decision, not the Subject's act of publication. This distinction is what prevents the publicness of a post from leaking onto the surrounding graph -- the most sensitive social data -- when an implementation reasons about social records.¶

The intent posture is descriptive classification metadata that runtime projection policy consumes; it does not override projection. The authorship constraint (the posture is invalid for records where the Subject is referent rather than author) is enforced by the social namespace's validation rules in the companion Schema. Implementations processing sygil.v1.social records SHOULD honor the intent posture as an input to projection decisions and MUST NOT treat it as a blanket license to re-surface published content without regard to the sensitivity axis and the projection context.¶

9.6. Conversation archives

The sygil.v1.conversation namespace carries the data subject's archived conversations with AI models. These are among the most sensitive payloads the Protocol can carry -- often more candid than any other source, because subjects reason out loud with an assistant in a way they may not with any person. A conversation archive routinely contains health, legal, financial, relationship, and other intimate disclosures; political and religious views; and unfiltered first-draft thinking, including abandoned branches the subject may consider more private than the conclusion they reached.¶

Two properties of the data class warrant specific note. First, the content frequently concerns other people who were not party to the conversation and did not consent to its archiving -- a subject discussing a colleague, a family member, or a third party. The Protocol does not represent this as a subject_scope distinction (the turn remains the subject's archived artifact regardless of whom it discusses); it is handled by the sensitivity axis, with every conversation record classified highly sensitive (concealed) by default, so that third-party content within a transcript is concealed along with everything else. Second, the content commonly contains embedded secrets -- pasted credentials, private keys, proprietary source. The Protocol treats conversation content bodies as opaque highly-sensitive material; an implementation MAY scan for secrets on import, but any such scan result is implementation-private and is not part of the Protocol's record shape, and scanning MUST NOT silently alter content (which would break the record's content-addressed identity).¶

Because the namespace is ImportOnly, the Protocol's revocation model for it is purge rather than token revocation: the subject's grant is the act of uploading an export, and revocation is the deletion of the materialized records. Implementations SHOULD treat conversation content bodies as ineligible for any informational log stream and SHOULD retain raw uploaded archives only as long as parsing requires.¶

9.7. Derived data amplification

Sygil's derived_from[] envelope field (Section 4.2.4) captures the case where a record was produced by combining or transforming other records. This case is common -- an agent producing a weekly health summary from daily wearable observations, an inference engine extracting a calendar event from an email thread, an analyst aggregating financial transactions into a quarterly cash-flow projection.¶

The privacy concern this subsection addresses: a derived record can have higher sensitivity than the records it was derived from. The classic example: ten individually low-sensitivity location records (a coffee shop, a gym, a grocery store) aggregated into a single record may reveal a home address with high precision. Ten individually low-sensitivity transaction records may aggregate into a record that discloses health conditions through inference (a sequence of pharmacy charges, copay amounts, and lab fees). Each source record carries its namespace's standard privacy classification; the derived record's classification is not mechanically derivable from the sources.¶

9.8. Linkability

By design, records about the same Subject share a subject_did and are linkable. This is a deliberate trade-off; it enables cross-domain agent reasoning, which is the primary use case the Protocol exists to serve.¶

Implementations that require unlinkability for specific records or specific Subjects MUST employ separate Subject DIDs (e.g., per-context did:key identifiers) and accept that records under those identifiers are not joinable to records under the Subject's primary DID. The Protocol does not provide an in-band linkage-control mechanism beyond this segregation.¶

9.9. Subject rights and erasure

Most jurisdictions in which Sygil is likely to be deployed (EU GDPR, US state-level CCPA-equivalents, Canadian PIPEDA, Brazilian LGPD, others) recognize Subject rights including access, rectification, and erasure. Sygil's content-addressable identifiers complicate naive erasure: the id URI is bound to the canonicalized record body and the same body always hashes to the same URI, so an erased record's URI remains a stable referent.¶

The Protocol provides:¶

• Soft-delete via obsolete: true with obsolete_reason (Section 4.2.4). The original record's id URI remains stable, but the record is marked as no longer current. Runtimes that honor soft-delete filter obsolete: true records out of query results by default.¶

• The obsolete_reason: withdrawn_consent value specifically signals consent withdrawal, supporting GDPR Article 17 erasure flows.¶

• The NSID extension pattern (Section 4.2.5) and _proofs extensibility allow vault implementations to attach erasure-specific metadata. Deletion-receipt records can be published under the implementation's community namespace (sygil.community.{publisher}.deletion_receipt.*); retention- honoring audit log entries are referenced via sygil.proof.audit per Section 5.8. Neither requires modifying the canonical record being soft-deleted.¶

Hard erasure -- actually removing the record from storage -- is a Vault runtime concern. The Protocol does not specify how a Vault implements erasure under regulatory requirement; vault-implementation specifications address this.¶

The expires_at envelope field and retention_policy reverse-DNS identifier (Section 4.2.4) support retention-driven expiry. Records whose expires_at time has passed are signaled as expired; how a Vault implements expiry-driven deletion is a Vault concern.¶

9.10. Reserved invariant on canonical content addressing

A reserved invariant of the Protocol, surfaced during the v0.3 reconciliation that produced this v01 increment, is that all v1 records are canonical self-contained Sygil records. Every record carries a complete envelope; the id is hash-over-canonical-form (per Section 4.4-4.5); content addressing is byte-stable across implementations.¶

Any future transmission optimization that omits fields from individual records on the wire -- for example, a token-efficient batch projection that strips repeated subject DIDs across a batch of records returned to an Agent -- MUST preserve id as hash-over-canonical-form. The optimization can transmit fewer bytes; the records' identity must remain hash-equivalent to what canonical-form transmission would produce.¶

This invariant is normative for the Protocol's evolution: future specification increments that introduce batch optimizations, columnar projections, agent-shaped formats, or any other non-canonical wire forms MUST specify how each form maps back to a canonical Sygil record before content-hash verification. v01 does not specify any such optimization; the invariant exists to preserve the design space.¶

The Protocol's regulatory-agnostic stance (a value preserved across all v1 increments) means that jurisdictional binding, cross-border data transfer rules, and similar regulatory-routing concerns are runtime, deployment, and legal concerns, not Protocol-level concerns. Earlier drafts of this Protocol reserved a jurisdiction[] envelope field for jurisdictional binding; v01 removes the field per the v0.3 reconciliation because runtime derivation from subject_did, source system, and record content is the more honest model. Implementations operating across jurisdictional boundaries SHOULD ensure that runtime policies honor jurisdiction-specific requirements; the Protocol does not provide a wire-level mechanism for declaring or enforcing jurisdictional bindings.¶

9.11. Identifier privacy

A Subject DID embedded in every sygil:// URI for that Subject's records is, by design, a stable identifier of the Subject. Where DID methods support pairwise-pseudonymous identifiers (e.g., generating a fresh did:key per relying party), Subjects may employ them to limit cross-relying-party correlation; the Protocol does not require or prohibit this practice.¶

The source_record_id_hash field of sygil.proof.provenance (Section 5.4) hashes rather than embeds the upstream source-system identifier, to avoid leaking that identifier to downstream Consumers. Implementations MUST NOT include un-hashed upstream identifiers in this field.¶

9.12. Query-based inference and side channels

The Protocol's query grammar (Section 4.10) lets Consumers retrieve records by namespace, time range, field equality, reference traversal, text search, and quality dimensions. Even when individual records are appropriately classified, redacted, and projected, the queries themselves can leak sensitive information through side channels that the Protocol does not defend against.¶

The principal classes of query-based inference attack:¶

• Presence/absence inference. A query like ?q=specific_term returning zero results vs. one or more results discloses that the queried term does or does not appear in any record visible to the querying Consumer. For sensitive terms (medical conditions, legal proceedings, particular relationships), presence/absence is itself disclosure, even when the underlying records would have been served redacted.¶

• Count inference. A query returning a specific count discloses how many records of a given shape exist for the Subject. Counts across queries can be combined to infer attributes the records themselves are redacted to conceal (e.g., counts of records in pharmacy, lab, and clinic namespaces over a time range can imply health conditions even when the records are individually hash-only or summary-projected).¶

• Timing side channels. The latency at which a Vault responds to a query can disclose whether the query traversed an index, hit a cache, was filtered by an authorization rule, or required a cross-namespace join. A Consumer measuring response timings can infer record existence, projection level applied, or authorization policy structure.¶

• Pagination cursor leakage. Opaque pagination cursors may encode position information that, in aggregate, discloses ordering or count properties of the underlying record set. Cursors that round-trip through Consumer storage can also unintentionally persist record-existence signals.¶

The Protocol does not provide defenses against any of the above. Mitigations are runtime concerns and depend on properties of the Vault implementation, the transport, and the deployment posture:¶

• Constant-time response policies that pad to a deployment-defined minimum response latency.¶

• Differential-privacy-style noise injection at the count- or histogram-aggregate level for queries known to be at risk of inference.¶

• Authorization rules that refuse queries whose result-set size would itself disclose information (e.g., refusing queries that would return exactly zero or exactly one record).¶

• Cursor formats that contain only opaque identifiers and no position information, sized identically across the cursor space.¶

These mitigations are deployment-level engineering choices, not Protocol-level mandates. The Protocol's position is that query- based inference is real and material, that the wire format does not defend against it, and that Consumers needing protection against these attack classes obtain it from the Vault implementation and the transport, not from the Protocol.¶

This subsection complements Section 9.1's "What the Protocol does not guarantee" list, where wire-level confidentiality, quasi- identifier protection, and unlinkability are also stated as non-guarantees. Query-based inference is the active counterpart of those static non-guarantees: a Consumer with access to the query surface has more inference power than a Consumer reading static records would have, and the Protocol does not constrain the query surface to remove that power.¶

9.13. Implications of proof-bearing responses

The Protocol's proof-object vocabulary means that records served to a Consumer carry metadata about their provenance, the consents that authorize their access, and (where applicable) the audit log entries referencing the access. This is by design -- agents reasoning about trust need this metadata -- but it has privacy implications:¶

• Proof objects increase the data footprint of each record on the wire. A sygil.proof.consent proof carrying DPV categories and legal basis reveals more about the access pattern than a record served without provenance metadata.¶

• Audit log URIs are themselves data. A sygil.proof.audit proof with log_entry_uri reveals the existence and location of an audit log entry; in some threat models this metadata is sensitive.¶

Implementations sensitive to these leaks MAY omit specific proof types from records served to less-trusted Consumers; doing so does not invalidate the records (proofs are optional). The trade-off is that Consumers cannot then verify the corresponding trust property.¶

9.14. Subject-protective defaults

Implementations producing records on behalf of a Subject SHOULD apply subject-protective defaults:¶

• subject_scope defaults to sole (the most restrictive interpretation).¶

• obsolete defaults to false (no soft-delete by default).¶

• language[] defaults to empty (no language assertion until one is needed).¶

• derived_from[] defaults to empty (no derivation lineage until one is asserted).¶

The defaults are conservative: a record produced with default values makes minimal claims, which limits the Consumer's exposure to overstated trust assertions.¶

9.15. Data Privacy Vocabulary alignment

The sygil.proof.consent proof's dpv_categories, purpose, and legal_basis fields align to the W3C Data Privacy Vocabulary (DPV), which provides standardized terms for consent records, processing purposes, and legal bases under GDPR and equivalent frameworks. This alignment is informative; the Protocol does not require the use of DPV terms, but recommends them where applicable.¶

ISO/IEC TS 27560:2023 [ISO-27560] consent record information structure is similarly aligned with DPV via the W3C DPV community group's published implementation guidance. Implementations using 27560-shaped consent receipts as the substrate for sygil.proof.consent proofs are encouraged to populate the DPV-aligned fields for cross-system interoperability.¶

10.1. Registration of the sygil URI scheme (provisional)

This document requests the provisional registration of the sygil URI scheme per [RFC7595].¶

URI scheme name:

sygil¶

Status:

Provisional¶

Applications and/or protocols which use this URI scheme name:

The Sygil Protocol, an open schema and query grammar for cross-domain personal data, as specified in this document.¶

Contact:

Evan Carr <evan@sygil.id>¶

Change controller:

Sygil PBC, until such time as a community-governed entity (e.g., a W3C Community Group, an IETF working group, or an independent foundation) assumes change control. Subsequent changes will be recorded in updates to this registration.¶

References:

This document.¶

URI scheme syntax:

sygil-URI    = "sygil://" subject-did "/" nsid "/" content-hash
subject-did  = "did:" method-name ":" method-specific-id
               ; per [W3C-DID]
nsid         = label *( "." label )
               ; reverse-DNS, per Section 4.3
content-hash = algorithm "-" 1*base64url-char
algorithm    = "blake3"
               ; v1 uses BLAKE3; future major Protocol versions
               ; may register additional algorithms
base64url-char = ALPHA / DIGIT / "-" / "_"
               ; base64url alphabet per [RFC4648] Section 5,
               ; without padding (see Section 4.5.3)

¶

URI scheme semantics:

A sygil URI identifies a Sygil record by the cryptographic hash of its canonical serialization. The URI is implementation-neutral; it does not encode hostname, port, or path. Resolution to a record representation is a separate concern handled by the carrier protocol or by Vault implementations.¶

Encoding considerations:

The URI is composed of US-ASCII characters. The DID component, NSID component, and content-hash component are all already restricted to US-ASCII per their respective specifications.¶

Interoperability considerations:

All v1 implementations of the Sygil Protocol use BLAKE3 as the content-hash algorithm and JCS [RFC8785] as the canonicalization rule. Implementations that produce or consume sygil URIs MUST agree on these or interoperability fails.¶

Security considerations:

See Section 8 of this document.¶

10.2. Registration of the application/sygil+json media type

This document requests the registration of the application/sygil+json media type per [RFC6838].¶

Type name:

application¶

Subtype name:

sygil+json¶

Required parameters:

None.¶

Optional parameters:

None.¶

Encoding considerations:

Binary; UTF-8 only. Records are serialized in canonical JSON per [RFC8785] (Section 4.5 of this document).¶

Security considerations:

See Section 8 of this document.¶

Interoperability considerations:

Records labeled with this media type MUST validate against the Sygil envelope specified in Section 4.2 and against the schema for the namespace declared by the record's @type field. The canonical serialization rules of Section 4.5 apply.¶

Published specification:

This document.¶

Applications that use this media type:

Implementations of the Sygil Protocol; storage systems handling Sygil records; Vault implementations; Consumer applications (including AI Agents).¶

Fragment identifier considerations:

None defined by this document.¶

Additional information:

Magic numbers:

None.¶

Deprecated alias names:

None.¶

File extensions:

.sygil, .sygil.json¶

Macintosh file type code:

None.¶

Person and email address to contact for further information:

Evan Carr <evan@sygil.id>¶

Intended usage:

Common.¶

Restrictions on usage:

None.¶

Author:

Evan Carr¶

Change controller:

Sygil PBC, until such time as a community-governed entity assumes change control.¶

10.3. Sygil Proof Object Types registry

This document requests the establishment of a new IANA registry named "Sygil Proof Object Types" per [RFC8126].¶

Registry name:

Sygil Proof Object Types¶

Description:

Identifiers for proof object types that may appear in the _proofs array of a Sygil record (Section 5).¶

Registration policy:

Specification Required (per [RFC8126] Section 4.6).¶

Designated expert review criteria:

Designated experts are responsible for ensuring that:¶

• The proposed @type value follows the reverse-DNS pattern (e.g., sygil.proof.{name} for proof types defined by the Sygil specification, or {publisher.domain}.{name} for proof types defined by other parties).¶

• The @type value does not collide with an existing registration.¶

• The proof object's intended semantics, field set, and verification procedure are documented in a published specification.¶

• The registration includes a stable contact and change controller.¶

Experts SHOULD reject registrations whose @type value uses the sygil.proof.* prefix unless the registration is made by the Sygil specification's change controller.¶

Required information for registrations:

• Proof object type identifier (@type value).¶

• Brief description of the proof's semantics.¶

• Reference to the specification defining the proof object's field set and verification procedure.¶

• Change controller (party responsible for future changes to the registration).¶

• Contact information.¶

Initial registry contents:

Change procedures:

Once registered, a proof type's @type value, semantics, and field set are immutable per the Protocol's compatibility policy (Section 6.5). Additional optional fields may be added in successor registrations under a different @type (e.g., sygil.proof.provenance.v2); no in-place modification of an existing proof type is permitted.¶

10.4. Sygil NSID Extension Publishers registry

This document requests the establishment of a new IANA registry named "Sygil NSID Extension Publishers" per [RFC8126].¶

Registry name:

Sygil NSID Extension Publishers¶

Description:

Identifiers for publishers of records under the sygil.community.{publisher}.* extension namespace (Section 4.2.5).¶

Registration policy:

Expert Review (per [RFC8126] Section 4.5) for publisher identifiers not under controlled domains. Publisher identifiers identical to a domain controlled by the registrant MAY be registered without expert review, subject to verification of domain control by the change controller.¶

Designated expert review criteria:

Designated experts are responsible for ensuring that:¶

• The proposed publisher identifier follows the reverse-DNS label-dot-label grammar.¶

• The publisher identifier does not collide with an existing registration.¶

• The registrant has a credible affiliation with the namespace they propose to publish under (e.g., they control the domain, they operate the product, they are the maintainer of the open-source project).¶

• The registration includes a stable contact and change controller.¶

Required information for registrations:

• Publisher identifier (the reverse-DNS-shaped value).¶

• Brief description of the publisher and the records they intend to publish under sygil.community.{publisher}.*.¶

• Change controller (party responsible for future changes to the registration).¶

• Contact information.¶

Initial registry contents:

(none -- the registry opens empty)¶

Change procedures:

Publisher identifiers are immutable once registered. To change an identifier, register a new one and migrate; the old registration MAY be marked deprecated but MUST NOT be reassigned.¶

draft-carr-sygil-protocol-00

Initial version. Defines the Sygil protocol: the record envelope and content-addressed identifier scheme, the NSID namespace grammar, the v1 namespace ladder (10 production-depth, 2 minimal-shape, and 3 NSID-reserved data namespaces, plus infrastructure-reserved prefixes), the canonicalization and hash-input rules, the cooperation-mode and provenance vocabulary, the query and conformance model, and the privacy considerations including the sensitivity axis and the social-namespace intent posture.¶