Version: 0.1.0 (Draft) Status: Draft. Subject to change. Reference implementation under active development by Laiyr, Inc. Maintainer: Laiyr, Inc.
This repository is licensed under Apache 2.0 only for the materials expressly included here: the VBR™ JSON Schema, examples, README text, publication path conventions, and verification procedure. No license is granted to any separate runtime system, resolver service, arbitration method, governance corpus chaining method, notification subsystem, Brand Agent implementation, or other method not necessary to author, publish, retrieve, parse, or verify a static VBR™.
The architecture as a whole — including runtime brand authority services, resolver-level authority arbitration, freshness arbitration override, governance corpus chaining, dispute reconstruction workflows, proactive agent-facing notification subsystems, multi-protocol agent adapter layers, runtime trust calibration modules, brand governance directive processing modules, vertical-agnostic core architectures with pluggable vertical adapter modules, and productized Brand Agent embodiments — is the subject of one or more pending U.S. patent applications by Laiyr, Inc. and its founder.
Implementing a static VBR™ authoring, publication, validation, or signature-verification tool does not require a separate Laiyr patent license. Implementing a runtime authority, arbitration, governance, notification, or Brand Agent system may require a separate license.
For patent licensing inquiries: contact trust@laiyr.ai.
Laiyr™ and Verified Brand Record™ are trademarks of Laiyr, Inc. U.S. Patent Pending.
A Verified Brand Record™ (VBR™) is a domain-published, cryptographically signed, brand-authored identity record for AI systems.
A VBR™ is published by a brand entity at its canonical domain and is queryable by AI platforms and AI agents during description, recommendation, and transaction. It is the brand-side data structure of an open architecture for verified brand identity in AI systems. It allows brand entities — commerce brands, professional service firms, public figures, regulated organizations, agricultural operations, manufacturers, and any other declarable identity — to publish a signed source of truth about themselves that AI systems and AI agents can verify against.
VBR™ is intentionally transport-agnostic and retrieval-agnostic. It defines a signed identity primitive, not a delivery protocol. A VBR™ may be retrieved over HTTPS, over any agent-interoperability protocol that supports static document exchange, or by any other mechanism by which a receiving system can obtain the document and the corresponding public key.
AI systems describe brand entities using data assembled from training corpora, web crawls, retrieval-augmented generation (RAG) over indexed sources, third-party APIs, platform feeds, and increasingly via agent-mediated retrieval over emerging interoperability protocols (MCP, A2A, UCP, ACP, AP2). Runtime retrieval — including RAG, indexed web retrieval, platform feeds, APIs, and agent-mediated query — has become an increasingly important mechanism by which AI systems answer brand-related queries in production, often in hybrid combination with model-native knowledge. Yet none of the sources currently retrieved are cryptographically verifiable as brand-authored.
There has been no standard mechanism by which a brand entity can:
- Declare its identity in a machine-readable, cryptographically verifiable form
- Publish that declaration as the authoritative source for AI consumption
- Influence how AI systems describe, recommend, or transact in relation to the brand entity
This specification defines the data structure for such a declaration. Together with conventions for publication (at /.well-known/brand-assertions.json on the brand entity's canonical domain), discovery (via two-path discovery: the brand entity's own domain, plus optional registry pointers), and verification (via ECDSA signatures using the P-256 curve and SHA-256 over JCS-canonicalized JSON per RFC 8785), the VBR™ forms the brand-side surface of a complete architecture.
The paths /.well-known/brand-assertions.json and /.well-known/brand-key are project-defined conventions under the RFC 8615 well-known URI framework. They are not IANA-registered well-known URIs as of this draft. Formal IANA registration is anticipated as the specification stabilizes.
To bound scope explicitly, this specification does not:
- Define runtime query protocols by which AI systems request brand identity from a brand-controlled service
- Define arbitration logic AI systems should apply when reconciling a verified VBR™ against other sources
- Define agent decision behavior on receipt of a verified VBR™
- Define a wallet-mediated credential presentation flow (e.g., OpenID for Verifiable Presentations)
- Define a governance corpus, audit log, or notification mechanism for brand-AI interactions
- Define a productized agent or service architecture
- Replace existing content provenance standards (C2PA), credential standards (W3C Verifiable Credentials), or media authenticity infrastructure
These boundaries protect the schema's narrow, interoperable purpose. Components beyond these boundaries may be the subject of pending patents by Laiyr, Inc. (see the Patent Notice above).
The Apache License 2.0 grant published with this repository extends to:
- The VBR™ JSON schema as defined in
vbr.schema.json - The publication path convention (
/.well-known/brand-assertions.json) - The signing algorithm specification (ECDSA P-256, SHA-256, JCS-canonicalized JSON per RFC 8785)
- The public key publication convention (
/.well-known/brand-key) - The canonicalization rules required for signature verification
- The verification model described in this README
Under the Apache 2.0 grant, implementers may freely build tools that help brand entities author and publish VBR™s to their own canonical domain, verifiers that fetch a VBR™ and validate its signature against the brand entity's published public key, editors and libraries and SDKs that produce or consume VBR™ JSON, schema validators that check VBR™s for spec compliance, and independent registries that index publicly published VBR™s.
The grant does not extend to any component, mechanism, or method that is not expressly defined in this specification, including but not limited to:
- Runtime brand authority services
- Resolver-level authority arbitration logic between heterogeneous brand identity sources
- Freshness arbitration override mechanisms
- Governance corpus chaining and tamper-evident audit log architectures
- Dispute reconstruction workflows
- Proactive agent-facing governance notification subsystems
- Multi-protocol agent adapter layers
- Runtime trust calibration modules with cryptographically bound trust objects
- Brand governance directive processing modules
- Vertical-agnostic core architectures with pluggable vertical adapter modules
- Productized Brand Agent embodiments
These components are described in the architectural specification maintained by Laiyr, Inc. at https://laiyr.ai/architecture and are the subject of one or more pending U.S. patent applications by Laiyr, Inc. and its founder.
Permitted implementations under the Apache 2.0 grant include brand-authoring tools, signature verifiers, schema validators, libraries and SDKs for producing or consuming VBR™ JSON, static publishers that deploy VBR™s to brand-controlled domains, and independent registries that index publicly-published VBR™s.
Implementations that embody the patent-protected mechanisms enumerated above — including runtime authority services that arbitrate between heterogeneous brand identity sources, governance corpus implementations that chain audit logs as described in the architectural specification, productized Brand Agent embodiments, or any other patent-protected mechanism — require separate license from Laiyr, Inc.
If you are uncertain whether a planned implementation falls inside or outside the scope of the Apache 2.0 grant, contact trust@laiyr.ai before building.
vbr.schema.json— JSON Schema (Draft 2020-12) defining the VBR™ data structureexamples/— Example VBR™s for different entity types (commerce brand, professional service, public figure)LICENSE— Apache License 2.0NOTICE— Patent notice and trademark attributionCONTRIBUTING.md— How to propose changesREADME.md— this file
- Confirm your planned implementation falls within the Apache 2.0 grant scope described in the Patent Notice and Scope of License sections above.
- Fetch
vbr.schema.jsonfrom this repository. - Author a VBR™ for a brand entity you control (or are authorized to publish on behalf of). See
examples/_unsigned-template.jsonfor a starting template. - Generate an ECDSA P-256 keypair and publish the public key as a JWK at
https://[your-domain]/.well-known/brand-key. - Canonicalize the unsigned VBR™ using JCS (RFC 8785).
- Sign the canonicalized bytes using ECDSA with the P-256 curve and SHA-256. Encode the signature as base64url-encoded raw
r || s. - Publish the signed VBR™ at
https://[your-domain]/.well-known/brand-assertions.jsonwithContent-Type: application/vbr+json. - Verify by following the procedure in the Verification Model section below.
{
"schema_version": "0.1.0",
"brand": {
"canonical_domain": "example.com",
"name": "Example Brand",
"entity_type": "commerce_brand"
},
"claims": [
{
"claim_id": "c-001",
"claim_class": "price_positioning",
"value": "Premium tier",
"permission_class": "inferable",
"freshness_ttl_seconds": 7776000
},
{
"claim_id": "c-002",
"claim_class": "differentiator",
"value": "Sustainability-focused: every product carbon-labeled at point of sale",
"permission_class": "inferable",
"freshness_ttl_seconds": 7776000
}
],
"issued_at": "2026-05-08T14:00:00Z",
"expires_at": "2026-06-08T14:00:00Z",
"signature": {
"algorithm": "ECDSA-P256-SHA256",
"value": "[base64url-encoded raw r || s]",
"public_key_url": "https://example.com/.well-known/brand-key",
"key_id": "example-2026-Q2"
}
}See examples/ for full VBR™s covering commerce brands, professional services, and public figures.
VBR™s MUST be signed using the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve (also known as secp256r1) and SHA-256 as the hash function. The signing input is the JCS-canonicalized JSON representation of the VBR™ with the signature.value field omitted, per RFC 8785. The resulting signature MUST be encoded as raw r || s in base64url, equivalent to JWS ES256 signature encoding.
Public keys SHOULD be published as JSON Web Keys (JWK) per RFC 7517. An example public key:
{
"kty": "EC",
"crv": "P-256",
"x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
"y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0",
"kid": "2026-05-08-key-1",
"alg": "ES256",
"use": "sig"
}Public keys SHOULD be published at https://[brand-canonical-domain]/.well-known/brand-key with Content-Type: application/jwk+json.
The VBR™ document type is application/vbr+json. Formal IANA registration is anticipated as the specification stabilizes. Public key documents use application/jwk+json per RFC 7517.
Implementations SHOULD serve VBR™ endpoints with Cache-Control: max-age=3600 (one hour) by default. Brand entities updating frequently MAY specify shorter TTLs. The public key endpoint SHOULD be served with Cache-Control: no-cache during active key rotation, and otherwise with max-age=86400 (24 hours).
Implementations SHOULD distinguish at minimum between signature verification failures (signature_invalid), public key endpoint unavailability (key_not_found), malformed public keys (key_format_invalid), schema conformance violations (schema_violation), and canonicalization errors (canonicalization_error).
A receiving AI system or AI agent verifies a VBR™ as follows:
- Fetch the VBR™ from the brand entity's canonical domain at the conventional publication path (
/.well-known/brand-assertions.json) - Fetch the public key referenced in the VBR™'s
signature.public_key_url(conventionally/.well-known/brand-key) and parse it as a JWK - Construct the unsigned payload by removing the
signature.valuefield from the VBR™ JSON object (retain all othersignaturefields, including algorithm and key identifier) - Canonicalize the unsigned payload using JCS (RFC 8785)
- Verify the ECDSA signature using the P-256 curve and SHA-256 over the canonicalized bytes, decoding the
signature.valuefield as base64url-encoded rawr || s - If verification succeeds, the receiving system may treat the VBR™ as a cryptographically verified brand-authored declaration
The architectural mechanisms by which an AI system decides what to do with a verified VBR™ — arbitration against other sources, freshness evaluation, governance directive processing, runtime trust calibration, and proactive notification — are defined in the architectural specification and are subject to patent claims as described above.
Test vectors (canonical payload, public key, signature, and expected verification result) are anticipated to ship with v0.2 of this specification.
The VBR™'s entity_type and claim_class enums are intentionally non-exhaustive. The architecture supports vertical adapter modules that extend these enumerations for vertical-specific application without modifying the core schema. Vertical extensions should be proposed via this repository's issue tracker.
The claim_class field is intentionally extensible (see Vertical extensibility above). However, in the interest of interoperability and predictable AI behavior, the following claim classes are recommended for general brand entity declaration. Implementers SHOULD use these names when the corresponding semantic applies:
claim_class |
Semantic |
|---|---|
price_positioning |
Declared price tier relative to category competitors (e.g., budget, mid-market, premium, luxury) |
target_audience |
Declared primary customer demographic and psychographic |
prohibited_terms |
Terms, descriptors, or phrasings the brand entity explicitly prohibits AI from using |
certification |
Third-party certifications held by the brand entity, including issuer, identifier, and expiry |
voice |
Communication register, tone, and stylistic attributes |
differentiator |
Declared unique value propositions and competitive differentiators |
Vertical-specific implementations may add claim classes appropriate to their domain (e.g., jurisdictional_eligibility for regulated financial services, licensure for professional services, product_attribute for commerce). Implementers SHOULD prefer the recommended class above when the semantic applies, and SHOULD propose new shared classes via this repository's issue tracker when a semantic recurs across implementers.
Each claim in a VBR™ MAY declare a permission_class field that specifies how AI systems are authorized to use the claim when generating brand descriptions or making brand recommendations. This is a machine-readable policy layer, not a security mechanism — it expresses the brand entity's intent and relies on AI platform cooperation to be honored.
Defined permission classes:
permission_class |
Semantic |
|---|---|
inferable |
The declared claim may be used by AI systems as a basis for reasonable inference and extrapolation when generating brand descriptions, provided the inferences are consistent with the declared claim |
non_inferable |
AI systems may only repeat the declared claim verbatim or in direct paraphrase. No extrapolation, elaboration, or inference beyond the declared content is authorized |
restricted |
The declared claim is intended for retrieval by authorized AI applications operating in internal governance mode and is not authorized for public AI agent consumption. Brands publishing restricted claims in the public VBR™ do so explicitly; implementations may alternatively omit restricted claims from the public VBR™ and serve them via a separate authorized retrieval channel |
Implementers using friendlier UI labels (for example, displaying non_inferable as "Verbatim" or restricted as "Internal") MAY do so, but the canonical schema field values MUST be inferable, non_inferable, or restricted as defined above. UI label aliases are an authoring concern; the wire format is fixed.
If permission_class is omitted from a claim, the default is inferable.
The architectural mechanisms by which AI systems consume, enforce, or audit permission_class directives at runtime are subject to patent claims as described in the Patent Notice above.
The schema reserves a small set of optional top-level fields for forward compatibility. Reserved fields are inert in v0.1.0: they carry no normative meaning in this version, and conforming v0.1.0 verifiers MUST ignore them. They are declared in vbr.schema.json so the field names are claimed ahead of normative specification, and so records authored against a future version remain schema-valid under v0.1.0 tooling.
| Field | Status | Purpose (planned) |
|---|---|---|
authorized_entities |
Reserved — not yet implemented | An optional top-level array by which a brand entity will be able to declare external AI entities — agents, assistants, or APIs — that the brand authorizes to speak or act on its behalf. The item shape (e.g., entity_type, identifier) is provisional and MAY change before it is normatively specified in a future version. Producers SHOULD NOT rely on this field in v0.1.0. |
Because the VBR™ schema does not set additionalProperties: false, reserving a field this way is a backwards-compatible, non-breaking addition: the field is optional, it is not added to required, and existing v0.1.0 records remain valid.
This specification operates in the brand-side identity layer of an emerging stack of agentic and verifiable-credential standards. The following are adjacent or complementary, not equivalent:
C2PA / Content Credentials. Coalition for Content Provenance and Authenticity, governed under the Linux Foundation Joint Development Foundation. C2PA is concerned with the provenance and edit history of media content (images, video, audio). VBR™ is concerned with the brand entity's declared identity and is not a media-provenance format.
W3C Verifiable Credentials 2.0. W3C Recommendation, May 2025. VC 2.0 is a holder-mediated credential exchange model with a three-party ecosystem (issuer, holder, verifier). VBR™ is a domain-published, brand-authored identity record retrieved directly from the brand's canonical domain. The two are interoperable in principle: a VBR™ may reference, embed, or be referenced by Verifiable Credentials, but VBR™ is not itself a Verifiable Credential.
OpenID for Verifiable Presentations 1.0. OpenID Foundation, Final July 2025. OID4VP is a wallet-mediated credential presentation flow. VBR™ does not define a presentation flow and is not an OID4VP profile.
NLWeb. Microsoft, May 2025. NLWeb provides a natural-language conversational interface for websites; every NLWeb endpoint also acts as an MCP server. NLWeb is concerned with site capability and content; VBR™ is concerned with brand identity. A site may implement both.
AdCP brand.json. Ad Context Protocol specification, v3 (3.1 line, 2026), published at /.well-known/brand.json. The spec describes brand.json as "the canonical source of brand identity data" — name, logos, colors, tone, portfolio/house hierarchy, trademarks, and advertising preferences — consumed across the AdCP advertising ecosystem and resolvable through five document variants, including a brand_agent variant that points to an MCP agent serving identity dynamically. Trust in AdCP rests on a mutual-assertion model (a leaf brand and its house reciprocally reference one another) anchored in domain control and TLS: identity attributes are trusted on the publishing domain's TLS rather than on a document-level signature. AdCP applies cryptographic signing — RFC 9421 HTTP Message Signatures on requests and webhooks, signed JWS governance, and signed agent responses — to runtime transactions rather than to the brand.json declaration document itself, whereas VBR™ signs the declaration document. VBR™ and AdCP brand.json are complementary.
AI Domain Data Standard (AIDD). Open community specification, v0.1.1 (November 2025), published at /.well-known/domain-profile.json. AIDD provides Schema.org-aligned domain attribution metadata for AI systems. By its authors' explicit framing, AIDD is an attribution mechanism rather than a verification or trust system. VBR™ addresses the verification layer that AIDD explicitly does not.
IETF SCITT (Supply Chain Integrity, Transparency, and Trust). IETF working group on signed statements, transparency services, and trust registries. SCITT and VBR™ share architectural concerns around tamper-evident statement logging; future versions of VBR™ may reference or build on SCITT primitives where appropriate.
DNSSEC and DANE. DNSSEC provides cryptographic authentication and integrity for DNS records. DANE binds TLS certificates to DNS names. VBR™ uses HTTPS retrieval from canonical domains and is compatible with DNSSEC and DANE deployments but does not require them.
AI agent protocols (MCP, A2A, UCP, ACP, AP2). As of mid-2026: MCP (Anthropic, donated to the Linux Foundation Agentic AI Foundation, December 2025); A2A (Google, donated to the Linux Foundation, June 2025); AP2 (Google, donated to the FIDO Alliance, April 2026, alongside Mastercard's Verifiable Intent framework); UCP (Google and Shopify, announced at NRF January 2026); ACP, which denotes both the IBM/Linux Foundation Agent Communication Protocol and the OpenAI/Stripe Agent Commerce Protocol. VBR™ is protocol-agnostic and may be retrieved over any of these channels.
VBR™ is intended to be complementary to, not in competition with, these standards. The specification is published openly to enable interoperable implementation across this stack.
Laiyr, Inc. maintains an internal implementation of the specification under active development. Independent implementations of the schema are welcome and encouraged within the scope of the Apache 2.0 grant defined above.
Version 0.1.0 is an initial draft published for community review. Breaking changes are possible before 1.0.0. Independent implementations of 0.1.0 are encouraged but should expect schema evolution.
After 1.0.0, breaking changes will follow semantic versioning conventions and be announced in advance.
The maintainer's intent is to evolve this specification toward formal standardization through appropriate industry and standards bodies once a stable specification baseline is established.
Anticipated v0.2 additions:
- Test vectors (canonical payload, key, signature, expected result)
- Expanded examples covering directives, delegation, and multi-vertical declarations
- Conformance checklist for implementations
For questions, proposed changes, or implementation coordination: open a GitHub issue, or contact trust@laiyr.ai.
For patent licensing inquiries (commercial use of patent-protected components beyond the Apache 2.0 grant scope above): contact trust@laiyr.ai.
The specification — meaning the contents of vbr.schema.json, the examples, and this README — is published under the Apache License 2.0. See LICENSE for full terms and NOTICE for the patent notice and trademark attribution.
The Apache 2.0 grant extends only to the specification as defined in the Scope of License section above. Implementations of patent-protected architectural components require separate license from Laiyr, Inc.
This specification builds on prior work in cryptographic content provenance (DKIM, C2PA), domain-bound assertions (DNSSEC, .well-known conventions per RFC 8615), deterministic JSON canonicalization (JCS, RFC 8785), JSON Web Keys (RFC 7517), machine-readable identity declarations (JSON-LD, Schema.org), credential exchange (W3C Verifiable Credentials, OpenID for Verifiable Presentations), and emerging conventions for agent-discoverable web services (NLWeb, MCP server discovery, A2A Agent Cards, UCP merchant manifests). The contribution of this specification is the brand-entity-controlled, signed, machine-readable identity structure for use in AI systems and agent-mediated transactions.