Network Working Group S. Jovancevic Internet-Draft SKGO, IKT Support Intended status: Standards Track 18 May 2026 Expires: 18 November 2026 Browser Vendor Attestation Protocol (BVAP) draft-jovancevic-bvap-01 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Abstract The HTTP User-Agent header field allows any client to claim any browser identity without cryptographic proof. Any software may assert "Mozilla/5.0 Chrome/124" regardless of its actual origin, distribution source, or software provenance. This document specifies BVAP (Browser Vendor Attestation Protocol), a mechanism by which browser vendors cryptographically attest that a browser instance originates from a legitimate, vendor-issued browser build. Attestation occurs at installation time and is periodically renewed. The resulting Vendor Attestation Seal (BVAP Seal) is carried by the browser and is primarily transmitted via the Sec-BVAP header field. The Seal MAY additionally appear in the User-Agent string for backward compatibility with legacy infrastructure. BVAP provides software provenance and vendor authenticity at the browser layer. The protocol allows servers to distinguish between: o Vendor-attested browser software, o Anonymous or self-built browser software (Unattested), and o Software falsely claiming vendor browser identity. BVAP requires no per-request cryptography and no DNS lookups during normal operation. BVAP proves browser origin, not browser behavior. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The User-Agent Problem . . . . . . . . . . . . . . . . 3 1.2. The BVAP Approach . . . . . . . . . . . . . . . . . . . 4 1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . 4 1.4. Specification Philosophy . . . . . . . . . . . . . . . 5 1.5. Relationship to Existing Code Signing . . . . . . . . . 6 1.6. Relationship to Mutual TLS . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Installation Attestation Model . . . . . . . . . . . . . . 6 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Installation Flow . . . . . . . . . . . . . . . . . . . 6 3.3. Vendor Attestation Service . . . . . . . . . . . . . . 7 3.4. BVAP Seal Format (Canonical Payload) . . . . . . . . . 8 3.5. Seal Rotation (Short-Lived Seals) . . . . . . . . . . . 10 3.6. Revocation Discard . . . . . . . . . . . . . . . . . . 11 3.7. Seal Storage and Embedding . . . . . . . . . . . . . . 12 4. Transport -- Header Integration . . . . . . . . . . . . . . 12 4.1. Dedicated Header -- Sec-BVAP (REQUIRED for BVAP use) . . 12 4.2. User-Agent Embedding (Compatibility Only) . . . . . . . 13 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . 14 5. Vendor Responsibility . . . . . . . . . . . . . . . . . . . 15 5.1. The Vendor Principle . . . . . . . . . . . . . . . . . 15 5.2. Vendor Categories . . . . . . . . . . . . . . . . . . . 16 6. Server-Side Handling . . . . . . . . . . . . . . . . . . . 17 6.1. Basic Mode (Informational Provenance Signal) . . . . . 17 6.2. Optional Verification Mode (Cryptographic Assurance) . 18 6.3. Provenance Classification . . . . . . . . . . . . . . . 19 7. Seal Revocation . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Revocation by Renewal Denial . . . . . . . . . . . . . 20 7.2. Revocation Discard Obligation . . . . . . . . . . . . . 21 7.3. Immediate Revocation (Optional) . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . 22 8.1. Vendor Trust Assumption (Foundational) . . . . . . . . 22 8.2. Seal Forgery . . . . . . . . . . . . . . . . . . . . . 23 8.3. Vendor Key Compromise . . . . . . . . . . . . . . . . . 24 8.4. Seal Cloning and Distributed Reuse . . . . . . . . . . 24 8.5. Attestation Service Availability . . . . . . . . . . . 25 8.6. Build Validation (Vendor-Defined) . . . . . . . . . . . 26 8.7. Threats Outside BVAP Scope . . . . . . . . . . . . . . 26 9. Privacy Considerations . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . 29 Appendix A. Transport Examples . . . . . . . . . . . . . . . 30 Appendix B. Vendor Attestation Service Examples . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32 1. Introduction 1.1. The User-Agent Problem Current web architecture contains no standardized mechanism for browser vendors to cryptographically attest that a browser instance genuinely originates from their distributed software. The HTTP User-Agent field [RFC9110] is informational only and carries no cryptographic authenticity guarantees. As a result: o Any software may claim any browser identity. o Browser vendor identity is trivially spoofable. o Servers cannot distinguish vendor-attested browser software from arbitrary software asserting browser identity. o Anonymous browser software and falsely claimed browser identity are operationally indistinguishable at the protocol layer. This represents a software provenance gap in modern web architecture. BVAP addresses this gap by enabling browser vendors to issue cryptographically verifiable attestations for browser software they distribute. 1.2. The BVAP Approach BVAP addresses this problem at the point of browser installation rather than at the point of each HTTP request. When a browser is installed, it contacts its vendor's Attestation Service and presents itself for verification. The vendor confirms that the installation corresponds to a legitimate, unmodified build of their software, and issues a cryptographic Vendor Attestation Seal (BVAP Seal). The browser stores this Seal and transmits it primarily via the Sec-BVAP HTTP header. The Seal MAY additionally be embedded in the User-Agent string for backward compatibility. Every subsequent HTTP request carries the Seal, allowing servers to identify the vendor that attested this browser installation. No DNS lookups occur during normal request processing. No per-request cryptography is required. Seals are short-lived and periodically renewed (Section 3.5). This is analogous to a physical inspection seal: the inspector (vendor) examines the product (browser installation), applies a seal, and periodically reissues it. The seal travels with the product but does not last forever. 1.3. Scope and Non-Goals BVAP is a browser software provenance and vendor attestation protocol. It answers exactly one question: "Does this browser instance originate from a vendor-attested browser build?" BVAP does NOT answer: o Who the user is. o Whether the user is human. o Whether the browser behavior is benign. o Whether the browser is automated or remotely controlled. o Whether the endpoint device is compromised. o Whether the request is fraudulent or abusive. Behavioral trust, fraud analysis, abuse mitigation, automation detection, and user authentication remain outside the scope of this protocol. BVAP is NOT: o A CAPTCHA replacement. o A human verification system. o A bot elimination mechanism. o A fraud prevention system. o A behavioral trust engine. o A user identity system. BVAP intentionally permits: o Anonymous browsing (no BVAP token required). o Self-compiled browser builds (Anonymous/Unattested status). o Open source browser forks (vendor registers independently). o Research browser environments. o Enterprise-managed browser deployments. o Automated operation of legitimate browser software. Non-Browser HTTP Clients: BVAP does not attempt to attest generic HTTP clients, API libraries, command-line tools (curl, wget), scripts, mobile embedded agents, IoT devices, or any non-browser HTTP software. Such clients operate as Anonymous/Unattested when interacting with BVAP-aware servers. They are not penalized for the absence of BVAP attestation. Operators of non-browser HTTP clients MAY voluntarily participate as vendors under their own domain if they wish to provide vendor attestation for their software, but no such participation is required or expected. For automated agent identity (bots, crawlers, IoT devices), see related work such as the Signed Agent Identity Protocol, which operates on the agent side of the same architectural problem. BVAP proves browser origin, not browser behavior. 1.4. Specification Philosophy BVAP is a proposal, not a prescription. This document specifies the protocol semantics required for interoperability: o Seal format (Section 3.4). o Cryptographic signature scheme (Ed25519, Section 3.4.2). o Transport (Sec-BVAP header, Section 4). o Verification procedure (Section 3.4.3, Section 6.2). o DNS-based public key publication (Section 6.2). These elements MUST be observed by conforming implementations because they define the wire-level contract between browsers, vendors, and servers. Without them, interoperability is impossible. This document does NOT prescribe: o How vendors internally validate their browser builds (Section 8.6). o How vendors operate their Attestation Service infrastructure (subject to operational privacy requirements in Section 3.6). o How servers interpret BVAP signals beyond the trust classification framework (Section 6.3). o Which vendors are trustworthy (Section 8.1 -- vendor trust is at the discretion of relying parties). Vendors and operators retain full operational discretion within the boundaries defined by this specification. The protocol establishes the rules of the game; participants choose how to play within those rules. This separation between specification (mandatory for interoperability) and implementation (vendor-defined) is consistent with established IETF practice: protocols define the wire, not the engine room. 1.5. Relationship to Existing Code Signing A natural question is why BVAP is needed given that browser binaries are already cryptographically signed through platform code signing mechanisms: Authenticode (Windows), codesign (macOS), and various Linux package signing schemes. These mechanisms validate the browser binary LOCALLY at install or launch time. The operating system verifies the signature and confirms the binary is authentic before allowing execution. However, this verification is invisible at the HTTP layer: o The server has no visibility into the local code signing state of the browser making the request. o Platform code signing signals do not traverse HTTP. o A bot or scraper pretending to be Chrome cannot fail any code signing check, because there is no code signing check at the server side to begin with. BVAP exports provenance from the local code signing layer into the HTTP layer. The vendor leverages its existing code signing and release infrastructure (Section 8.6) to issue a Seal that the server can verify, bridging the gap between local software authenticity and remote HTTP visibility. BVAP is therefore complementary to code signing, not a replacement: local code signing protects the integrity of the binary on the user's device; BVAP communicates that protection to remote servers in a privacy-preserving manner. 1.6. Relationship to Mutual TLS A second natural question is why BVAP does not use mutual TLS (mTLS) client certificates, an established IETF mechanism for client authentication. mTLS and BVAP address different problems at different layers of the identity stack: o Identity axis: mTLS authenticates the USER or organization presenting the certificate. BVAP attests the SOFTWARE making the request. These are orthogonal identity axes -- one identifies WHO, the other identifies WHAT. o Enrollment model: mTLS requires per-site enrollment. A client certificate is typically issued for a specific service, trust domain, or PKI hierarchy. BVAP requires no enrollment with any server -- a single vendor attestation works with any server that chooses to recognize it. o User experience: mTLS imposes significant UX overhead. Browser certificate selection dialogs interrupt the user and require active selection. BVAP is invisible to the user and requires no interaction. o Lifetime and tracking: mTLS certificates are typically long-lived and carry stable identity, enabling cross-site correlation. BVAP Seals rotate every 14-30 days with Revocation Discard (Section 3.6) to prevent long-term tracking by servers or by the vendor itself. o Revocation: mTLS revocation requires CRL or OCSP infrastructure. BVAP revocation is achieved through renewal denial (Section 7) with no separate revocation infrastructure required. o Deployment cost: mTLS deployment requires per-server PKI configuration, trust store management, and client enrollment workflows. BVAP deployment requires only vendor DNS key publication (Section 6.2) and Sec-BVAP header parsing. BVAP is therefore not a replacement for mTLS. The two mechanisms address different layers of the identity stack and may coexist in the same deployment when both software provenance and user authentication are required. 2. Terminology 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. Browser Vendor: Any entity that compiles, signs, and distributes a browser build to end users. Includes commercial organizations, open source projects, and individual developers who distribute browser software. Vendor Attestation A service operated by the Browser Vendor Service: that verifies browser installations and issues BVAP Seals. MUST be operated under the vendor's domain. BVAP Seal: A short-lived cryptographic token issued by the Vendor Attestation Service to a verified browser installation. Carried by the browser via Sec-BVAP and periodically renewed. Attested Browser: A browser that carries a valid BVAP Seal issued by a recognized vendor. Unattested Client: Any HTTP client that does not carry a BVAP Seal. Includes legitimate browsers without BVAP support, privacy-opt-out browsers, automated agents, and HTTP libraries. Vendor Domain: The domain under which the vendor operates their Attestation Service and publishes their attestation keys. Examples: google.com, mozilla.org, apple.com. 3. Installation Attestation Model 3.1. Overview The BVAP attestation model has three phases: Phase 1 -- Installation: The browser is installed on the user's device. At the completion of installation, the browser initiates the attestation process with the Vendor Attestation Service. Phase 2 -- Attestation: The vendor verifies that the installation corresponds to a legitimate, unmodified build of their software and issues a BVAP Seal to the browser. Phase 3 -- Operation: The browser stores the BVAP Seal locally and transmits it primarily via the Sec-BVAP header for subsequent HTTP requests. The Seal MAY additionally appear in the User-Agent string for backward compatibility. The Seal is periodically renewed per Section 3.5. Initial attestation occurs once per installation. Seal renewal occurs periodically (every 14-30 days per Section 3.5) and does not require user action. Attestation MAY also be re-triggered after browser updates at vendor discretion. 3.2. Installation Flow The following describes the attestation flow at installation: 1. Browser installation completes on the user's device. 2. The browser generates an Installation Identity: install-id = random(256-bit) The install-id MUST be: o Generated using a cryptographically secure random number generator per [RFC4086]. o Composed of pure randomness, with NO input derived from device hardware, MAC addresses, hardware IDs, CPU IDs, or any other device-specific value. o Unique per installation (per browser profile, per user account on the device). o Never reused across reinstallations. This design ensures install-id cannot be used for device fingerprinting or cross-installation correlation. An install-id is a fresh, random nonce -- not a derived device identifier. 3. The browser contacts the Vendor Attestation Service: POST https://attest./bvap/v1/attest Content-Type: application/json { "build": "-", "build-hash": "", "install-id": "", "platform": "", "ts": } 4. The Vendor Attestation Service validates: o The build-hash corresponds to a known, signed release. o The build version matches the claimed build identifier. o The request appears to originate from a fresh installation (rate limiting and anti-abuse checks at vendor discretion). 5. On successful validation, the Service issues a BVAP Seal (Section 3.4) and returns it to the browser. 6. The browser stores the Seal in tamper-evident local storage and transmits it in subsequent HTTP requests primarily via the Sec-BVAP header (Section 4). The Seal is periodically renewed per Section 3.5. If attestation fails (e.g., tampered binary, network error), the browser operates without a BVAP Seal as an Unattested Client. Attestation failure MUST NOT prevent browser operation. 3.3. Vendor Attestation Service The Vendor Attestation Service is operated by the Browser Vendor under their domain. It MUST: o Be reachable at https://attest./bvap/v1/attest during installation and Seal renewal phases. o Verify that the presented build-hash corresponds to a known, signed release build of the vendor's browser software. o Issue BVAP Seals only to verified installations. o Sign Seals using Ed25519 [RFC8032] with the VendorSigningPrivateKey held in hardware-backed secure storage (HSM or equivalent). o Include an expiry timestamp in every issued Seal (maximum 30 days from issuance). o Support Seal renewal requests from existing installations. o Implement Revocation Discard per Section 3.6. o Publish the VendorSigningPublicKey in DNS for offline server verification: _bvap.. IN TXT "v=bvap1; pk=" The Attestation Service MUST NOT: o Log or retain information that can identify the user. o Link install-id values across different installations. o Maintain any mapping between successive Seals issued to the same installation (see Section 3.6). o Share installation data with third parties. The Vendor Attestation Service is contacted at installation and at Seal renewal. It is NOT contacted during normal browser operation or per-request processing. 3.4. BVAP Seal Format (Canonical Payload) The BVAP Seal is a compact, URL-safe string with three colon- separated components. This canonical format eliminates payload reconstruction ambiguity and enables fully offline verification. Format: :: Where: vendor-domain: The vendor's domain (e.g., google.com, mozilla.org). Identifies who issued the Seal and which DNS record to consult for the public key. encoded-claims: Base64URL-encoded JSON object containing the public attestation claims. This is the payload that the vendor signs. seal-sig: Base64URL-encoded Ed25519 signature [RFC8032] over the canonical signing input (see below). 3.4.1. Encoded Claims Structure The encoded-claims component is a Base64URL encoding of a compact JSON object containing the following fields: { "ver": "", "exp": , "iat": } Field definitions: ver String. Browser build version identifier as recognized by the vendor (e.g., "chrome-124", "firefox-125"). MUST be present. exp Integer. Unix timestamp (seconds) at which this Seal expires. MUST NOT exceed iat + 30 days. MUST be present. iat Integer. Unix timestamp (seconds) at which this Seal was issued. MUST be present. The JSON object MUST be serialized in canonical form: o UTF-8 encoded. o No whitespace between tokens. o Keys in the order: "ver", "exp", "iat". The serialized JSON is then Base64URL-encoded (without padding) to produce the encoded-claims component. Note: The encoded-claims contains ONLY public attestation metadata. It does NOT contain install-id, build-hash, device information, or any user-identifiable data. The install-id used during attestation (Section 3.2) is consumed by the vendor and is NOT transmitted in the Seal. Future versions of this specification MAY define additional optional claim fields. Implementations MUST ignore unknown claim fields for forward compatibility. 3.4.2. Signing Input The signature is computed over the concatenation of the vendor domain and the encoded-claims, separated by a single colon: signing-input = || ":" || This is the exact byte sequence that the vendor signs and that the server reconstructs for verification -- character-for-character identical to what appears in the Sec-BVAP header before the second colon. seal-sig = Base64URL( Ed25519.Sign(VendorSigningPrivateKey, signing-input) ) The Ed25519 signature scheme [RFC8032] is REQUIRED for BVAP. Future versions of this specification MAY define additional signature algorithms identified by a "v" field in encoded-claims. 3.4.3. Verification Procedure To verify a BVAP Seal, the server: 1. Splits the Seal on ":" into three components: vendor-domain, encoded-claims, seal-sig. 2. Retrieves the VendorSigningPublicKey from DNS at _bvap.. (cached per Section 6.2). 3. Decodes encoded-claims (Base64URL) and parses the JSON. Validates that exp > current_time (Seal not expired). 4. Reconstructs the signing input EXACTLY: signing-input = || ":" || Note: encoded-claims is used in its original Base64URL form, NOT the decoded JSON. This eliminates JSON canonicalization ambiguity during verification. 5. Verifies the signature using Ed25519: Ed25519.Verify(VendorSigningPublicKey, signing-input, seal-sig) 6. If verification succeeds and Seal is not expired: classify as Attested Browser per Section 6.3. This procedure is fully self-contained. The server does not need to know install-id, build-hash, or any other vendor-side state. The encoded-claims provides everything needed. 3.4.4. Example Conceptual example (signature abbreviated): vendor-domain: google.com claims JSON: {"ver":"chrome-124", "exp":1746748800, "iat":1744156800} encoded-claims: eyJ2ZXIiOiJjaHJvbWUtMTI0IiwiZXhwIjoxNzQ2NzQ4ODAw LCJpYXQiOjE3NDQxNTY4MDB9 signing-input: google.com:eyJ2ZXIiOiJjaHJvbWUtMTI0... seal-sig: Final Seal: google.com:eyJ2ZXIiOiJjaHJ...: Transmitted in: Sec-BVAP: google.com:eyJ2ZXIi...: 3.5. Seal Rotation (Short-Lived Seals) BVAP Seals MUST be short-lived and periodically rotated. o Seal validity SHOULD NOT exceed 30 days. o Seal validity of 14 days is RECOMMENDED for privacy- sensitive deployments to reduce long-term cross-site correlation potential. o Browsers SHOULD initiate Seal renewal within 5 days before expiry by contacting the Vendor Attestation Service. o Renewal is silent and automatic -- no user action required. o Seals that have expired MUST be treated as absent by servers. Browsers with expired Seals operate as Anonymous/Unattested clients until renewal succeeds. Seal rotation provides three compounding benefits: Privacy: Cross-site correlation is limited to the Seal validity window (maximum 30 days) rather than the lifetime of the browser installation. After each rotation, the browser presents a different signature to all sites, breaking any correlation built on the previous Seal. Revocation: A compromised or abusive installation is revoked by refusing Seal renewal. No server-side revocation list infrastructure is required. The existing Seal expires naturally within at most 30 days. Compromise Response: A leaked or stolen Seal becomes invalid at the next rotation boundary without requiring active propagation of revocation information to servers. Auto-Renewal Flow: Day 1: Installation -> Vendor issues Seal #1 Valid for 30 days. Embedded in User-Agent. Day 25: Browser contacts Vendor Attestation Service: "My seal expires in 5 days. Issue renewal." Vendor checks: is this installation revoked? NO -> Issues Seal #2. Discards Seal #1 record. YES -> Refuses. Browser becomes Unattested. Day 30: Seal #1 expires. Browser switches to Seal #2. No user action. No service interruption. 3.6. Revocation Discard (Operational Privacy Obligation) Revocation Discard is a protocol-level operational privacy requirement imposed on participating vendors. It is NOT a cryptographic guarantee enforced by the protocol itself. The BVAP protocol cannot cryptographically prove that a vendor has discarded correlation data. Vendors are expected to comply with Revocation Discard as part of their operational obligations when implementing the BVAP Vendor Attestation Service. This is the same governance model used by Certificate Authorities in PKI: a CA is operationally required to follow its Certificate Practice Statement, even though the protocol cannot enforce CA internal behavior cryptographically. The Operational Requirement: Upon issuing a renewed Seal, the Vendor Attestation Service MUST: o Immediately invalidate the previous Seal. o Discard records linking the previous Seal to the renewed Seal -- including logs, databases, analytics pipelines, and backup systems -- within a reasonable operational window (RECOMMENDED: 24 hours). o NOT maintain any mapping between successive Seals issued to the same installation across rotation boundaries. This commitment ensures that a compliant vendor cannot reconstruct a tracking chain across Seal rotation periods. A malicious or non-compliant vendor can undermine this property; see Section 8 (Security Considerations) on the vendor trust assumption. The ONLY persistent record the vendor MAY maintain is a binary installation status: active (eligible for renewal) or revoked (ineligible for renewal). This binary status: o MUST NOT be linkable to specific Seal values. o MUST NOT be linkable to user identity or browsing history. o MUST only be used to determine renewal eligibility. Revocation Discard + Seal Rotation together provide: o Server-side privacy: servers cannot track across rotations (different signature). o Vendor-side privacy: compliant vendors cannot track across rotations (Discard obligation). The protocol is designed so that BVAP is not a tracking infrastructure when operated by compliant vendors. Non-compliance is a vendor governance issue, not a protocol-level guarantee. 3.7. Seal Storage and Embedding The BVAP Seal MUST be stored in persistent, tamper-evident storage on the user's device. Recommended storage locations: o OS credential store (Windows Credential Manager, macOS Keychain, Linux Secret Service) o Browser profile storage with integrity verification The Seal MUST survive browser restarts. Browser updates SHOULD NOT invalidate the Seal unless the vendor explicitly requires re-attestation for that update. The Seal MUST NOT be shared between different browser profiles or different user accounts on the same device. 4. Transport -- Header Integration BVAP defines two transport methods for transmitting the Seal: the dedicated Sec-BVAP header (REQUIRED for security use) and User-Agent embedding (informational compatibility only). Sec-BVAP is REQUIRED for any deployment that relies on BVAP for any operational decision beyond informational logging. User-Agent embedding is NOT RECOMMENDED for security-sensitive use. It exists solely for backward compatibility with legacy infrastructure that cannot yet process the Sec-BVAP header. 4.1. Dedicated Header -- Sec-BVAP (REQUIRED for BVAP use) The Sec-BVAP HTTP header is the REQUIRED transport for the BVAP Seal. Any server that intends to act on BVAP signals -- including Optional Verification Mode, traffic classification beyond raw logging, or any policy decision -- MUST receive the Seal via Sec-BVAP. Header format: Sec-BVAP: :: The full Seal format including the encoded-claims payload is defined in Section 3.4. The "Sec-" prefix follows the convention for security-relevant request headers [FETCH]. This prefix: o Indicates that the header is restricted from being set by JavaScript and other web content. o Signals to intermediaries that the header is security- relevant and should be handled accordingly. o Enables CDNs and analytics systems that mask Sec-* headers by default to preserve user privacy. o Allows cleaner separation from User-Agent semantics. Browsers implementing BVAP MUST support Sec-BVAP. Browsers MAY additionally include the Seal in the User-Agent string per Section 4.2 for backward compatibility. Example: GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 Chrome/124.0.0.0 Sec-BVAP: google.com:: 4.2. User-Agent Embedding (Compatibility Only) The BVAP Seal MAY also be embedded in the User-Agent string as a product token per [RFC9110] Section 10.1.2. This transport form exists solely for backward compatibility with legacy infrastructure that does not yet support Sec-BVAP. User-Agent embedding is NOT RECOMMENDED for security-sensitive use. Servers SHOULD prefer Sec-BVAP and SHOULD ignore BVAP tokens in the User-Agent string when Sec-BVAP is also present. Format: User-Agent: BVAP/ Where is the full BVAP Seal as defined in Section 3.4. The BVAP token MUST be appended at the end of the User-Agent string, separated by a single space character. Operational concerns with User-Agent embedding: o User-Agent values are commonly logged by CDNs, intermediaries, and analytics systems, exposing the Seal to broader visibility than the Sec-BVAP header. o User-Agent strings are parsed by countless legacy systems that may corrupt, truncate, or misinterpret the BVAP token. o User-Agent strings are subject to fingerprinting concerns that the Sec-BVAP transport avoids. o Future protocol evolution is harder when BVAP is bound to User-Agent semantics. Servers that rely on BVAP for any operational decision MUST use Sec-BVAP. Servers MAY accept User-Agent embedding as a secondary signal during migration periods, but MUST NOT make security decisions based on User-Agent-embedded Seals alone. 4.3. Examples RECOMMENDED -- Sec-BVAP transport: GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 Sec-BVAP: google.com:: NOT RECOMMENDED -- User-Agent embedding (compatibility only): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 BVAP/google.com:: Firefox with Sec-BVAP: Sec-BVAP: mozilla.org:: Tor Browser with Sec-BVAP: Sec-BVAP: torproject.org:: Browser without BVAP attestation (Anonymous/Unattested): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 [no Sec-BVAP, no BVAP in UA] 5. Vendor Responsibility 5.1. The Vendor Principle Any entity that compiles, signs, and distributes a browser build assumes responsibility for attesting that build. This principle applies without exception: o Google is responsible for attesting Chrome builds. o Mozilla Foundation is responsible for attesting Firefox. o Apple Inc. is responsible for attesting Safari. o The Tor Project is responsible for attesting Tor Browser. o A developer distributing a custom browser fork is responsible for attesting that fork's builds. Vendor responsibility is triggered by distribution, not by licensing model. An open source browser is not exempt from vendor responsibility if it is distributed to end users. A vendor that does not operate a BVAP Attestation Service produces Unattested Clients. This is permitted. Browsers without BVAP attestation are treated as anonymous clients, not as malicious actors. 5.2. Vendor Categories Commercial vendors: Organizations such as Google, Mozilla Foundation, Apple, and Microsoft that distribute browser software at scale. These vendors operate the Attestation Service under their established domain. Open source projects: Projects such as the Tor Project, Brave Software, and Vivaldi that distribute open source or open core browsers. These projects MUST operate their Attestation Service under their own domain. Being open source does not transfer vendor responsibility to the upstream project. Example: LibreWolf is a Firefox fork distributed by the LibreWolf Project. LibreWolf operates its own Attestation Service at attest.librewolf.net. LibreWolf browsers carry BVAP/librewolf.net seals, NOT BVAP/mozilla.org seals. Custom and fork builds: Developers distributing modified browser builds MUST NOT claim the identity of the upstream vendor in their BVAP token. A custom Chromium fork MUST use its own vendor domain, not google.com. Enterprise and managed builds: An enterprise distributing internally modified browser builds to its employees, customers, or controlled environments assumes vendor responsibility for those builds. Enterprise-managed, kiosk, government-hardened, and internally distributed browser variants MAY participate in BVAP using enterprise-controlled vendor domains. Example: A bank distributing a hardened Firefox variant to its internal users may operate an Attestation Service at attest.bank.example and issue BVAP/bank.example seals. The bank assumes vendor responsibility for these builds. This preserves provenance accountability while allowing deployment-specific browser modification, including: o Pinned versions for compliance environments. o Removed features for hardened deployments. o Added enterprise policies and managed configurations. o Localization or branding variants. Self-compiled builds: Users who compile browsers from source for personal use only and do not distribute them are NOT vendors. Their self-compiled browsers operate as Anonymous/Unattested clients. This is intentional and by design. The freedom to compile, modify, and run browser software from source is a fundamental principle of open source software. BVAP does not restrict this freedom in any way. A self-compiled browser: o Operates as Anonymous/Unattested. o Is NOT penalized or treated as malicious. o MAY optionally self-register as a vendor under their own domain if they distribute the build to others. Future work MAY define a Community Attestation model for reproducible open source builds (e.g., via established reproducible build verification infrastructure). 6. Server-Side Handling 6.1. Basic Mode (Informational Provenance Signal) Basic Mode is INFORMATIONAL ONLY. Servers MUST treat Basic Mode as unauthenticated. Basic Mode MUST NOT be used for access control decisions. In Basic Mode, the server reads the BVAP token from the request and uses it as a provenance signal for traffic classification. No cryptographic verification is performed. The vendor claim in Basic Mode is unauthenticated and trivially spoofable. Servers operating in Basic Mode MUST NOT grant security-sensitive privileges based solely on the presence of a BVAP token without cryptographic verification. Basic Mode provides provenance signaling and traffic classification benefits, but does NOT provide cryptographic assurance of vendor identity. Server logic: 1. Parse the request for a BVAP token. 2. If BVAP token present: a. Extract vendor-domain from the seal. b. Use the vendor claim as an unauthenticated provenance signal. c. Apply traffic classification policy. 3. If no BVAP token present: a. Treat as Anonymous/Unattested Client. b. Apply default anonymous policy. 4. If User-Agent claims a specific browser but no BVAP token is present: a. Apply standard anonymous policy. b. MAY log as Unverifiable Claim (per Section 6.3). Basic Mode is appropriate for: o Traffic classification and routing decisions. o Distinguishing attested-claiming from non-claiming clients. o Soft policy (rate limit tiers, log enrichment). o Telemetry and analytics on browser provenance signaling. Basic Mode MUST NOT be used for: o Authentication. o Authorization or access control. o Bypassing security controls. o Granting access to sensitive resources. o Anti-fraud or abuse prevention enforcement. Servers requiring any form of access control or cryptographic assurance MUST use Optional Verification Mode (Section 6.2). 6.2. Optional Verification Mode (Cryptographic Assurance) In Optional Verification Mode, the server cryptographically verifies the BVAP Seal signature using the vendor's Ed25519 public key retrieved from DNS. This mode provides full cryptographic assurance of vendor identity and Seal authenticity. This mode is OPT-IN and intended for deployments requiring strong assurance (security-sensitive APIs, regulated services, high-value endpoints). Verification steps (per Section 3.4.3): 1. Parse the Seal from the Sec-BVAP header: :: 2. Decode encoded-claims (Base64URL) and parse as JSON. Verify exp > current_time. If expired, treat as absent (Anonymous/Unattested). 3. Retrieve the VendorSigningPublicKey from DNS: _bvap.. IN TXT "v=bvap1; pk=" Cache the result per DNS TTL. DNS lookups MUST occur at most once per vendor-domain per cache TTL period. Servers MUST validate DNSSEC [RFC4033] where available. 4. Reconstruct the signing input exactly: signing-input = || ":" || Use the encoded-claims component in its original Base64URL form from the Seal -- NOT a re-encoded version. This is the identical byte sequence the vendor signed. 5. Verify the signature: Ed25519.Verify(VendorSigningPublicKey, signing-input, Base64URL.Decode(seal-sig)) 6. On successful verification: classify as Attested Browser per Section 6.3. On verification failure: treat as Anonymous/Unattested. MAY log as potential Seal forgery attempt. Optional Verification provides cryptographic assurance of: o Vendor authenticity: only the vendor with the corresponding VendorSigningPrivateKey can produce a valid signature. o Seal integrity: any modification to vendor-domain, encoded-claims, or the signature itself invalidates verification. o Non-forgery: without the vendor's private key, valid signatures cannot be produced for any claims. Verification is performed entirely locally by the server. The vendor's Attestation Service is NOT contacted during per-request verification. Only the DNS public key lookup occurs, and this is cached aggressively (RECOMMENDED TTL: 3600 seconds). DNS Key Pinning (Optional): Servers MAY pin vendor public keys locally to reduce operational dependency on DNS resolution during verification. Pinned keys: o MAY be obtained out-of-band from vendor publications, security advisories, or established trust channels. o SHOULD be periodically refreshed against DNS to detect vendor key rotation events. o Provide resilience against DNS poisoning, captive portals, resolver compromise, enterprise interception, and other DNS-layer attacks. When a pinned key disagrees with the current DNS record, servers SHOULD log the discrepancy and apply policy according to their security posture (treat as Anonymous/Unattested, alert administrators, or refresh pin). Pinning is OPTIONAL. Servers that do not pin keys rely entirely on DNS (RECOMMENDED with DNSSEC validation) for key distribution. 6.3. Provenance Classification BVAP defines three provenance categories that servers MAY use to inform policy decisions: +===================+================================+==============+ | Client Type | Condition | Provenance | +===================+================================+==============+ | Attested Browser | Valid BVAP Seal present. | Verified | | | Vendor claim accepted (Basic) | | | | or verified (Optional). | | +-------------------+--------------------------------+--------------+ | Anonymous / | No BVAP Seal present. | Unknown | | Unattested | OR self-compiled build, | | | | OR browser without BVAP, | | | | OR user opted out. | | | | Honest about its status. | | +-------------------+--------------------------------+--------------+ | Unverifiable | Claims specific browser vendor | Claimed but | | Claim | in UA but no BVAP Seal. | Unverified | | | Claim without proof. | | +-------------------+--------------------------------+--------------+ The distinction between Anonymous/Unattested and Unverifiable Claim is operationally significant: o Anonymous/Unattested clients make no false assertions. They are unknown, not dishonest. Default policy applies. o Unverifiable Claim clients actively assert an identity they cannot prove. This is more concerning than honest anonymity and SHOULD receive reduced trust accordingly. Provenance classification refers exclusively to confidence in software origin and vendor authenticity. It MUST NOT be interpreted as proof of human presence, benign intent, or absence of automation. Verified Provenance does NOT imply trustworthy behavior -- a Seal-attested browser may still originate from automated, headless, or malware-controlled sessions. The term "trust" is intentionally avoided in this classification because it carries behavioral semantics. BVAP operates strictly at the provenance layer. BVAP proves browser origin, not browser behavior. 7. Seal Revocation BVAP Seal revocation is achieved through Seal rotation denial rather than active revocation list propagation. 7.1. Revocation by Renewal Denial When the Vendor Attestation Service determines that a browser installation should not be renewed, it refuses to issue a new Seal when the browser requests renewal. The existing Seal continues to be accepted until its expiry timestamp. After expiry, the browser operates as Anonymous/ Unattested until it successfully obtains a new Seal -- which will not happen for non-renewed installations. IMPORTANT -- Revocation Scope and Limits: o Revocation affects ONLY BVAP attestation status. It MUST NOT prevent browser operation, web access, or any other browser functionality. o A revoked browser continues to function fully as an Anonymous/Unattested client. The user retains full access to the web. o Revocation does NOT imply maliciousness on the part of the user. A user MUST NOT be characterized as a bad actor on the basis of BVAP revocation status alone. o Vendors SHOULD publish their revocation criteria transparently. Arbitrary or opaque revocation undermines the trust model. o Servers MUST NOT use BVAP revocation status as the sole basis for blocking, denying service, or restricting access. BVAP is an informational provenance signal -- not an access control mechanism. BVAP is not an internet access control system. The protocol provides provenance signaling only. Revocation removes the provenance signal but does not remove the browser, the user, or the right to browse anonymously. This design eliminates the need for: o Server-side revocation lists. o Real-time revocation checking by servers. o OCSP-style revocation infrastructure. o Revocation propagation delays. Revocation is eventual (bounded by Seal validity period) rather than immediate. This is an accepted trade-off for the significant reduction in infrastructure complexity. 7.2. Revocation Discard Obligation The Revocation Discard commitment defined in Section 3.6 applies throughout the revocation process. Even when revoking an installation, the vendor MUST NOT: o Link the revoked Seal to any previous Seals. o Use revocation records to reconstruct browsing history. o Share revocation data with third parties in a form that identifies the installation or user. 7.3. Immediate Revocation (Optional) For deployments requiring immediate revocation (before Seal expiry), servers MAY implement optional real-time revocation checking against the vendor's revocation endpoint: GET https://attest./bvap/v1/status/ Response: { "status": "valid" } or { "status": "revoked" } This endpoint is OPTIONAL for vendors and OPTIONAL for servers. Servers that do not implement real-time revocation checking rely on natural Seal expiry for revocation enforcement. The seal signature transmitted in this request is opaque and does not reveal user identity. However, vendors MUST NOT log these status check requests in association with site identity, to prevent vendor-side correlation of browsing patterns. 8. Security Considerations 8.1. Vendor Trust Assumption (Foundational) BVAP fundamentally assumes that browser vendors operate their Attestation Service infrastructure according to the privacy, operational, and security requirements of this specification. The BVAP trust model relies on ecosystem-level trust in vendors, similar to PKI. No central authority governs vendor behavior. This includes: o Honest Seal issuance only to verified browser installations. o Compliance with Revocation Discard (Section 3.6). o Secure storage of VendorSigningPrivateKey. o Honest revocation when warranted by stated criteria. o No use of attestation infrastructure for user tracking. A malicious or non-compliant vendor can undermine BVAP privacy and security guarantees independently of the protocol mechanics. Specifically, a non-compliant vendor could: o Issue Seals to non-browser software (impersonation enablement). o Maintain hidden mappings between rotated Seals (tracking). o Share installation data with third parties. o Refuse Seal renewal arbitrarily or based on opaque criteria. This trust model is consistent with established PKI governance: Certificate Authorities operate under similar operational trust assumptions, enforced through audit, transparency, and ecosystem accountability rather than cryptographic compulsion. There is no central governing body that compels CA behavior -- trust emerges from ecosystem participation, public accountability, and the practical consequences of misbehavior. The same applies to BVAP vendors. Trust is established and maintained through: o Vendor reputation and accountability to their user base. o Public scrutiny of vendor compliance with this specification. o Server-side discretion in which vendors to trust. o User choice of browser vendor. Servers and users SHOULD evaluate vendor trustworthiness independently. Vendors with poor compliance reputation MAY be treated with reduced trust regardless of valid BVAP attestation. Conversely, a server is never required to trust any particular vendor -- vendor trust is always at the discretion of the relying party. To make this explicit: o BVAP does not define a central trust authority. o BVAP does not establish a vendor approval program. o BVAP does not maintain a mandatory vendor registry. o BVAP does not require ecosystem-wide vendor accreditation. Trust decisions remain entirely local to relying parties. A server is free to trust any subset of vendors, no vendors, or all vendors, based on its own policy. There is no protocol- level entity that compels server trust in any vendor. This design intentionally avoids reproducing the centralization patterns of established PKI ecosystems. BVAP provides the verification mechanism; relying parties retain full discretion over how that verification is used. 8.2. Seal Forgery The Seal signature is computed using Ed25519 [RFC8032] with the VendorSigningPrivateKey held exclusively by the vendor. A forger without this private key cannot produce a valid Seal signature for a given vendor-domain. In Optional Verification Mode (Section 6.2), servers detect forged Seals through Ed25519 signature verification using the vendor's public key retrieved from DNS. This is a cryptographic guarantee: forged signatures cannot pass verification. In Basic Mode (Section 6.1), the server does not verify the signature and is informationally vulnerable to forged Seals. This is by design: Basic Mode is informational only and MUST NOT be used for security-sensitive decisions. Servers requiring strong forgery resistance MUST use Optional Verification Mode. 8.3. Vendor Key Compromise If the VendorSigningPrivateKey is compromised, an attacker can generate valid Seal signatures for any installation under that vendor's domain. This is the primary cryptographic risk in BVAP. Mitigations: o VendorSigningPrivateKey MUST be stored in hardware security modules (HSM) with non-exportable key attributes. o Vendors SHOULD rotate VendorSigningPrivateKey periodically (RECOMMENDED: annually). o On detected compromise, the vendor MUST: - Immediately update the public key in DNS to a new key. - Invalidate all Seals signed by the compromised key. - Force re-attestation of all active installations. - Notify the ecosystem via standard channels (security advisories, browser vendor lists, etc.). o DNS TTL for _bvap records SHOULD be set to 300-3600 seconds to bound the propagation window for emergency key rotation. o Servers in Optional Verification Mode automatically reject Seals signed by the old key once the DNS public key has been updated. 8.4. Seal Cloning and Distributed Reuse BVAP attests to software provenance, not operational execution state or real-time orchestration. A malicious actor may extract a valid BVAP Seal from a legitimate browser installation and distribute it across a high-volume automated botnet infrastructure. This limitation is a structural property of stateless client- side delivery over the open web. BVAP does not guarantee that the executing agent is free of automation. It only guarantees that the cryptographically bound installation footprint was initially validated by the vendor. Mitigating the distributed reuse of a cloned Seal falls outside the scope of this protocol. Servers and networks MAY utilize standard rate-limiting, IP reputation profiling, or stateful tracking to detect anomalous, multi-source presentation of identical signature tokens. Protocol-level mitigations that DO apply: o Seal storage in OS credential stores (Section 3.7) reduces extractability from compromised endpoints. o Seal rotation (Section 3.5) bounds the maximum lifetime of any cloned Seal to the Seal validity window (30 days max, 14 days RECOMMENDED). o Vendor-side anomaly detection during renewal: if a single install-id is observed renewing from improbable patterns, the vendor MAY refuse renewal (Section 7). o Optional Verification Mode (Section 6.2) detects forgery but does NOT detect legitimate Seals presented by unauthorized parties. BVAP intentionally does not attempt to solve the distributed reuse problem at the protocol layer. Solving it would require per-request server interaction with the vendor, undermining the KISS principle and creating significant centralization and privacy concerns. This trade-off is intentional and consistent with the protocol's scope (Section 1.3). 8.5. Attestation Service Availability The Vendor Attestation Service is only required during browser installation. If the service is unavailable at install time, the browser operates as an Unattested Client until attestation succeeds. Service unavailability does not affect browsers that have already been attested. 8.6. Build Validation (Vendor-Defined) This specification defines the attestation transport, verification semantics, and provenance model, but does not mandate how vendors internally validate browser builds. A vendor MUST validate that a browser instance corresponds to a legitimate, distributed build of their software before issuing a BVAP Seal. The specific mechanism for this validation is vendor-defined and MAY include: o SHA256 hash matching against a list of known signed release hashes. o Signed Build Manifest verification with component-level attestation. o Platform-specific code signing chain validation (Authenticode on Windows, codesign on macOS, etc.). o Reproducible build verification for open source projects. o Any combination of the above, or other vendor-specific mechanisms. The validation mechanism is internal to the Vendor Attestation Service. Different vendors MAY implement different validation approaches based on their build, release, and distribution processes. This flexibility accommodates the operational diversity across commercial vendors, open source projects, enterprise deployments, and custom forks. Whatever mechanism is chosen, the vendor MUST NOT attest builds they cannot independently verify as their own legitimate distribution. 8.7. Threats Outside BVAP Scope BVAP does not protect against: o Automation frameworks controlling a legitimate attested browser (Selenium, Playwright, Puppeteer, etc.). o Malware controlling an attested browser installation. o Remote desktop or remote control of a legitimate browser. o Bot farms using genuine browser installations. These threats are outside the scope of a software provenance protocol. BVAP proves browser origin, not browser behavior. 9. Privacy Considerations 9.1. User Non-Identification BVAP MUST NOT enable identification or tracking of individual users. The BVAP Seal carries only: o The vendor domain (public information). o An opaque Ed25519 signature that does not contain PII. The install-id used during attestation is ephemeral and is NOT embedded in the BVAP Seal or the User-Agent string. 9.2. Cross-Site Non-Linkability via Seal Rotation BVAP Seals rotate every 30 days (Section 3.5). This means: o The Seal signature changes at each rotation boundary. o Cross-site correlation using the Seal signature is limited to the current Seal validity window (maximum 30 days). o After rotation, the browser presents a new signature that cannot be linked to the previous one by any server. The Revocation Discard obligation (Section 3.6) ensures that even the vendor cannot link successive Seals to reconstruct a long-term browsing profile. This design provides meaningful privacy protection while preserving vendor attestation functionality. The protocol is not a permanent identifier system. Servers MUST NOT attempt to link Seal signatures across rotation boundaries for user tracking purposes. Storing Seal signatures in association with user identity or browsing history MUST be considered a violation of this specification. 9.3. Opt-Out Users MUST be able to disable BVAP attestation in browser settings. When disabled: o The browser operates as an Unattested Client. o The BVAP token is NOT included in the User-Agent string. o Browser functionality MUST NOT be degraded. Browser vendors MUST NOT penalize users who opt out of BVAP attestation. 9.4. Attestation Service Privacy The Vendor Attestation Service is contacted once per installation. The service: o MUST NOT log information that identifies the user. o MUST NOT retain install-id values after issuing the Seal. o MUST NOT associate the installation with any account, profile, or identity of the user. 10. IANA Considerations This document requests IANA to register the following HTTP header field in the "Permanent Message Header Field Names" registry [RFC9110]: Header field name: Sec-BVAP Applicable protocol: http Status: standard Author/Change controller: IETF Specification: This RFC This document requests IANA to register the following product token in the HTTP "Product Tokens" registry [RFC9110]: Product token: BVAP Description: Browser Vendor Attestation Protocol seal (User-Agent backward-compatibility mode). Format: BVAP/:: Specification: This RFC This document requests IANA to create the following new registry: Registry name: BVAP Vendor Attestation DNS Parameters Registration policy: Specification Required Initial contents: v, pk as defined in Section 6.2 of this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 11.2. Informative References [RFC8809] Hodges, J., Jones, J., and M. Jones, "Registries for Web Authentication (WebAuthn)", RFC 8809, DOI 10.17487/RFC8809, August 2020, . [RFC9576] Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. Wood, "The Privacy Pass Architecture", RFC 9576, DOI 10.17487/RFC9576, April 2024, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [FETCH] WHATWG, "Fetch Standard", . Appendix A. Transport Examples (Informative) This appendix shows BVAP transport examples for both the REQUIRED Sec-BVAP header (Section 4.1) and the User-Agent backward-compatibility form (Section 4.2). Note: In these examples: o represents Base64URL-encoded JSON claims (e.g., {"ver":"chrome-124","exp":1746748800,"iat":1744156800} -> eyJ2ZXIiOiJjaHJvbWUtMTI0Ii...) o represents the 88-character Base64URL Ed25519 signature. A.1. Attested Browsers (Sec-BVAP, REQUIRED) Chrome (Windows): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 Sec-BVAP: google.com:: Firefox (Linux): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:125.0) Gecko/20100101 Firefox/125.0 Sec-BVAP: mozilla.org:: Safari (macOS): Sec-BVAP: apple.com:: Tor Browser: Sec-BVAP: torproject.org:: LibreWolf (custom fork, own vendor): Sec-BVAP: librewolf.net:: Enterprise hardened Firefox (bank example): Sec-BVAP: bank.example:: A.2. Attested Browsers (User-Agent backward-compatibility) Chrome with BVAP in User-Agent (NOT RECOMMENDED for security): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 BVAP/google.com:: Note: Sec-BVAP is REQUIRED for any deployment that relies on BVAP for operational decisions. User-Agent embedding is for backward compatibility only. See Section 4. A.3. Anonymous / Unattested Clients Anonymous browser (no claim, no BVAP): GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; Linux x86_64) Custom-Browser/1.0 [No Sec-BVAP, no BVAP in User-Agent. Honest anonymity.] A.4. Unverifiable Claim Client claiming Chrome identity without BVAP attestation: GET /api/data HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/124.0.0.0 Safari/537.36 [Claims Chrome but no Sec-BVAP and no BVAP in UA. Server treats as Unverifiable Claim per Section 6.3.] Appendix B. Vendor Attestation Service Examples (Informative) B.1. Attestation Request POST https://attest.google.com/bvap/v1/attest Content-Type: application/json { "build": "chrome-124", "build-hash": "sha256:a3f8c2d1e9b7...", "install-id": "<256-bit random nonce, Base64URL encoded>", "platform": "windows-x64", "ts": 1744200000 } B.2. Attestation Response (Success) HTTP/1.1 200 OK Content-Type: application/json { "seal": "google.com:: ", "claims": { "ver": "chrome-124", "exp": 1746748800, "iat": 1744156800 }, "signature-alg": "ed25519", "status": "attested" } The "seal" field contains the complete canonical BVAP Seal as defined in Section 3.4. The browser stores this Seal and transmits it in subsequent requests via Sec-BVAP header (Section 4.1). The "claims" field is shown decoded for clarity and is identical to the Base64URL-decoded encoded-claims embedded in the seal. B.3. Attestation Response (Failure) HTTP/1.1 403 Forbidden Content-Type: application/json { "status": "rejected", "reason": "unknown-build-hash", "detail": "Presented build hash does not correspond to any known signed release." } Browser operates as Anonymous/Unattested Client. MUST NOT retry more than 3 times within 24 hours. Author's Address Srecko Jovancevic SKGO, IKT Support Makedonska 22 11000 Belgrade Serbia Email: srecko.jovancevic@skgo.org Email: srecko.jovancevic@gmail.com URI: https://github.com/sreckojovancevic