Independent Submission R. T. Surampudi Internet-Draft Nylo Project Intended status: Informational 20 February 2026 Expires: 24 August 2026 WTX-1: Cross-Domain Context Preservation Protocol draft-surampudi-wtx1-00 Abstract This document defines the WTX-1 (WaiTag Transfer Protocol, version 1) for preserving pseudonymous user context across unrelated web domains without third-party cookies, browser fingerprinting, login requirements, or personal data collection. The protocol uses cryptographically generated pseudonymous identifiers (WaiTags), URL hash fragment transport, server-side verification, and DNS-based domain authorization to enable privacy-respecting cross-domain analytics. 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 24 August 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. Surampudi Expires 24 August 2026 [Page 1] Internet-Draft WTX-1 February 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Step-by-Step . . . . . . . . . . . . . . . . . . . . . . 5 4. WaiTag Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Generation Requirements . . . . . . . . . . . . . . . . . 7 5. Token Transport . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Primary: URL Hash Fragment . . . . . . . . . . . . . . . 8 5.2. Fallback: URL Query Parameters . . . . . . . . . . . . . 8 5.3. Parameter Names . . . . . . . . . . . . . . . . . . . . . 8 5.4. Token Cleanup . . . . . . . . . . . . . . . . . . . . . . 9 6. Token Format and Verification . . . . . . . . . . . . . . . . 9 6.1. Token Contents . . . . . . . . . . . . . . . . . . . . . 9 6.2. Verification Requirements . . . . . . . . . . . . . . . . 10 6.3. Verification Endpoint . . . . . . . . . . . . . . . . . . 10 7. DNS Domain Authorization . . . . . . . . . . . . . . . . . . 11 7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. TXT Record Format . . . . . . . . . . . . . . . . . . . . 11 7.3. Verification Flow . . . . . . . . . . . . . . . . . . . . 11 7.4. Subdomain Inheritance . . . . . . . . . . . . . . . . . . 11 8. Client-Side Storage . . . . . . . . . . . . . . . . . . . . . 12 8.1. Three-Layer Strategy . . . . . . . . . . . . . . . . . . 12 8.2. Storage Read Priority . . . . . . . . . . . . . . . . . . 12 8.3. Data Stored . . . . . . . . . . . . . . . . . . . . . . . 12 8.4. Data Obfuscation . . . . . . . . . . . . . . . . . . . . 13 9. Consent and Anonymous Mode . . . . . . . . . . . . . . . . . 13 9.1. Consent API . . . . . . . . . . . . . . . . . . . . . . . 13 9.2. Anonymous Mode Behavior . . . . . . . . . . . . . . . . . 13 9.3. Consent Restoration . . . . . . . . . . . . . . . . . . . 14 9.4. Regulatory Considerations . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10.1. Token Security . . . . . . . . . . . . . . . . . . . . . 14 10.2. Transport Security . . . . . . . . . . . . . . . . . . . 14 10.3. Input Validation . . . . . . . . . . . . . . . . . . . . 15 10.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 15 10.5. Response Headers . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 12.1. Core Privacy Commitments . . . . . . . . . . . . . . . . 16 12.2. Pseudonymous Identifiers . . . . . . . . . . . . . . . . 17 12.3. User Control and Consent . . . . . . . . . . . . . . . . 17 12.4. Data Minimization . . . . . . . . . . . . . . . . . . . 18 12.5. Cross-Domain Tracking Scope . . . . . . . . . . . . . . 18 Surampudi Expires 24 August 2026 [Page 2] Internet-Draft WTX-1 February 2026 12.6. Regulatory Compliance . . . . . . . . . . . . . . . . . 18 12.7. Limitations and Residual Risks . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Comparison with Existing Approaches . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Third-party cookies have been the primary mechanism for cross-domain user identification since the 1990s. With Safari's Intelligent Tracking Prevention (ITP [ITP]) deployed in 2017, Firefox Enhanced Tracking Protection (ETP) in 2019, and Chrome's Privacy Sandbox initiative beginning in 2024, this mechanism is being eliminated across all major browsers. When a user navigates from one domain to an unrelated domain (different effective top-level domain plus one label, or eTLD+1), analytics systems lose the ability to understand that the same visitor made both visits. This creates blind spots in patient journey analytics across healthcare providers, financial customer experience across banking portals, government service usage across agency domains, and multi-brand retail analytics. Existing solutions have significant limitations: browser fingerprinting is ethically problematic and legally risky; login- based identity excludes anonymous visitors; first-party data sharing requires business partnerships and PII exchange; Privacy Sandbox Topics API is coarse-grained, advertising-focused, and Chrome-only. WTX-1 addresses these limitations by defining a protocol that: 1. Preserves visitor context across unrelated domains 2. Never collects, transmits, or derives personal information 3. Works without cookies, fingerprinting, or login 4. Resists tracking by unauthorized third parties via DNS-based domain authorization 5. Degrades gracefully when consent is denied 6. Operates within GDPR, CCPA, and ePrivacy frameworks Surampudi Expires 24 August 2026 [Page 3] Internet-Draft WTX-1 February 2026 1.1. Requirements Language 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. 2. Terminology WaiTag A pseudonymous identifier generated per-visitor using cryptographic randomness. Format: wai__. Contains no personally identifiable information (PII). Origin Domain The domain where the user's session begins and the WaiTag is generated. Destination Domain The domain the user navigates to, which receives and verifies the WaiTag via a cross-domain token. Cross-Domain Token A time-limited, server-signed token encoding the WaiTag for transfer between domains. DNS Authorization Domain ownership verification via DNS TXT records that authorizes a domain to participate in WTX-1 identity sharing. Verification Server The server-side component that issues, signs, and verifies cross-domain tokens. Anonymous Mode A degraded operating mode where no WaiTag is generated, no identity is preserved, and identity-related API calls are no-ops. 3. Protocol Overview The WTX-1 protocol operates in seven steps across three participants: the origin domain, the destination domain, and the verification server. Surampudi Expires 24 August 2026 [Page 4] Internet-Draft WTX-1 February 2026 Domain A Verification Domain B (Origin) Server (Destination) | | | 1. User visits | | 2. Generate WaiTag | | 3. Register WaiTag ---->| | | 4. Store WaiTag | | | | 5. User clicks link | | to Domain B | | 6. Request token ------>| | | 7. Verify DNS | | authorization | |<--------- 8. Return signed token | | | | 9. Append token to | | URL hash fragment | | | | | |--- User navigates to Domain B ----------->| | | | | | 10. Read token | | | from hash | | |<---- 11. Verify token | | | | | 12. Check signature, | | expiry, domain | | | | | |----> 13. Return | | | identity | | | | | | 14. Restore WaiTag | | | Clean URL | Figure 1: WTX-1 Protocol Flow 3.1. Step-by-Step 1. *WaiTag Generation:* When a user first visits a participating domain, the client generates a WaiTag using the Web Crypto API (crypto.getRandomValues). The WaiTag format is wai__. 2. *Identity Registration:* The client registers the WaiTag with the verification server. The server stores the WaiTag, session ID, originating domain, and timestamp. Surampudi Expires 24 August 2026 [Page 5] Internet-Draft WTX-1 February 2026 3. *Cross-Domain Navigation:* When the user navigates to another participating domain, a cross-domain token is appended to the destination URL. The mechanism for link decoration is implementation-defined (e.g., server-side link rewriting, client- side click handlers, or manual URL construction). 4. *Token Generation:* The verification server generates a signed, time-limited token encoding the user's WaiTag and session context. The server SHOULD verify that the destination domain is DNS-authorized before issuing the token. 5. *Hash Fragment Transport:* The token is appended to the destination URL as a hash fragment (#nylo_token=). Hash fragments are never sent to the server in HTTP requests, providing an additional privacy layer. 6. *Token Verification:* On the destination domain, the client reads the token from the hash fragment and sends it to the verification server for validation. 7. *Identity Restoration:* If verification succeeds, the server returns the original WaiTag and session context. The client restores the user's pseudonymous identity on the new domain and removes the token from the URL. 4. WaiTag Format 4.1. Structure A WaiTag has the following structure: wai__ Surampudi Expires 24 August 2026 [Page 6] Internet-Draft WTX-1 February 2026 +===========+==========+==========+==============================+ | Component | Encoding | Length | Source | +===========+==========+==========+==============================+ | Prefix | ASCII | 4 chars | Literal "wai_" | +-----------+----------+----------+------------------------------+ | Timestamp | Base-36 | ~8 chars | Current time in milliseconds | +-----------+----------+----------+------------------------------+ | Separator | ASCII | 1 char | Literal "_" | +-----------+----------+----------+------------------------------+ | Random ID | Base-36 | 11 chars | crypto.getRandomValues (8 | | | | | bytes) | +-----------+----------+----------+------------------------------+ | Domain | Hex | 8 chars | One-way hash of hostname | | Hash | | | | +-----------+----------+----------+------------------------------+ Table 1: WaiTag Components 4.2. Properties A WaiTag has the following properties: * Not reversible: No component can be reversed to identify a natural person. * Not derived from PII: No personal information is used as input. * Domain-scoped: The domain hash binds the WaiTag to its origin, but the hash is one-way and cannot reveal the domain to a third party. * Collision-resistant: 64 bits of cryptographic randomness provides sufficient uniqueness for analytics use cases. * Not a fingerprint: No hardware, software, or behavioral signals are used. * Not deterministic: The same user on the same device will receive different WaiTags across sessions unless identity is explicitly restored via cross-domain token. 4.3. Generation Requirements Implementations MUST generate WaiTags using crypto.getRandomValues [W3C-WebCryptoAPI] or an equivalent cryptographically secure pseudorandom number generator (CSPRNG). If the Web Crypto API is not available, implementations MAY fall back to Math.random, but SHOULD log a warning indicating reduced randomness quality. Surampudi Expires 24 August 2026 [Page 7] Internet-Draft WTX-1 February 2026 5. Token Transport 5.1. Primary: URL Hash Fragment The cross-domain token MUST be transported via URL hash fragment as the primary mechanism: https://destination.example.com/page#nylo_token= Hash fragments (the portion of a URL after "#") are processed entirely client-side per [RFC3986] Section 3.5. They are: * Never included in HTTP requests to the server * Never logged in server access logs * Never sent in the Referer header * Not visible to network intermediaries (proxies, CDNs, WAFs) This provides a stronger privacy guarantee than URL query parameters, which are transmitted to the server and commonly logged. 5.2. Fallback: URL Query Parameters If hash fragment transport is not feasible (e.g., the destination URL uses hash-based client-side routing), the token MAY be transported as a query parameter: https://destination.example.com/page?nylo_token= Implementations using query parameter transport SHOULD remove the token from the URL immediately after reading it, using the History API (history.replaceState) to clean the URL without triggering a page reload. 5.3. Parameter Names Implementations MUST accept both of the following parameter names for cross-domain tokens: * "nylo_token" (primary) * "wai_token" (alternative) Surampudi Expires 24 August 2026 [Page 8] Internet-Draft WTX-1 February 2026 5.4. Token Cleanup After reading a cross-domain token from the URL, the client MUST remove it from the URL to prevent: * Accidental sharing of token-bearing URLs * Token replay from browser history * Token exposure in analytics tools that capture full URLs The client SHOULD use history.replaceState to remove the token without causing a navigation event or page reload. 6. Token Format and Verification 6.1. Token Contents A cross-domain token encodes the following fields: +===================+===============================================+ | Field | Description | +===================+===============================================+ | waiTag | The pseudonymous identifier to transfer | +-------------------+-----------------------------------------------+ | sessionId | The session identifier from the origin | | | domain | +-------------------+-----------------------------------------------+ | originDomain | The domain that issued the token | +-------------------+-----------------------------------------------+ | destinationDomain | The intended recipient domain | +-------------------+-----------------------------------------------+ | issuedAt | UTC timestamp of token creation | +-------------------+-----------------------------------------------+ | expiresAt | UTC timestamp of token expiry | +-------------------+-----------------------------------------------+ | signature | Server-generated signature (HMAC or | | | implementation-defined) | +-------------------+-----------------------------------------------+ Table 2: Cross-Domain Token Fields The token encoding format is implementation-defined. Common choices include JSON Web Tokens (JWT) [RFC7519] and opaque server-side tokens with a lookup key. Surampudi Expires 24 August 2026 [Page 9] Internet-Draft WTX-1 February 2026 6.2. Verification Requirements The verification server MUST check: 1. Signature validity: The token has not been tampered with. 2. Expiry: The token has not expired. The expiry window is configurable; the recommended default is 5 minutes. The verification server SHOULD also check: 1. Domain authorization: The destination domain is DNS-authorized to receive identities. 2. Origin matching: The token was issued for the domain making the verification request. 6.3. Verification Endpoint The verification endpoint accepts a POST request with Content-Type application/json containing the token, the requesting domain, a customer identifier, and the HTTP Referer value. Request body: { "token": "", "domain": "destination.example.com", "customerId": "", "referrer": "https://origin.example.com/page" } Success response: { "success": true, "identity": { "sessionId": "", "waiTag": "", "userId": null } } Failure response: Surampudi Expires 24 August 2026 [Page 10] Internet-Draft WTX-1 February 2026 { "success": false, "error": "TOKEN_EXPIRED" } 7. DNS Domain Authorization 7.1. Purpose Before a domain can receive cross-domain identities, it SHOULD prove ownership via a DNS TXT record. This prevents unauthorized domains from requesting or receiving WaiTags and ensures that only domains controlled by the same organization (or participating partners) can share visitor context. 7.2. TXT Record Format The DNS TXT record uses the following format: _nylo-verify.example.com. IN TXT "nylo-domain-verify=" The verification code is a unique value generated by the verification server for each domain registration. 7.3. Verification Flow 1. The domain owner registers the domain with the verification server and receives a verification code. 2. The domain owner adds the TXT record to their DNS configuration. 3. The domain owner calls the verification endpoint. 4. The server performs a DNS lookup for _nylo-verify.. 5. If the TXT record matches the expected verification code, the domain is authorized. 6. Authorization is cached server-side and periodically re-verified. 7.4. Subdomain Inheritance If a parent domain (e.g., example.com) is DNS-verified, subdomains (e.g., blog.example.com, shop.example.com) inherit authorization automatically. Implementations MAY provide configuration to exclude specific subdomains from inheritance. Surampudi Expires 24 August 2026 [Page 11] Internet-Draft WTX-1 February 2026 8. Client-Side Storage 8.1. Three-Layer Strategy The client SHOULD store identity data using multiple mechanisms for resilience against browser storage restrictions: +=======+====================+========================+=============+ | Layer | Mechanism | Persistence | ITP Impact | +=======+====================+========================+=============+ | 1 | First-party cookie | 24h (JS-set | Capped at 7 | | | | under ITP) | days | +-------+--------------------+------------------------+-------------+ | 2 | localStorage | Until | Partitioned | | | | cleared | by eTLD+1 | +-------+--------------------+------------------------+-------------+ | 3 | sessionStorage | Tab | Unaffected | | | | lifetime | | +-------+--------------------+------------------------+-------------+ Table 3: Storage Layers 8.2. Storage Read Priority When restoring identity, the client reads in order: cookie, localStorage, sessionStorage. The first valid result is used. 8.3. Data Stored The stored identity record contains: { "sessionId": "", "waiTag": "", "userId": null, "domain": "example.com", "createdAt": "2026-02-20T12:00:00.000Z", "integrity": "" } The "integrity" field is a one-way hash of the session ID, domain, WaiTag, and customer ID, used to detect tampering. Surampudi Expires 24 August 2026 [Page 12] Internet-Draft WTX-1 February 2026 8.4. Data Obfuscation Data stored in localStorage SHOULD be encoded with a customer- specific salt and timestamp to prevent casual inspection. This is obfuscation, not cryptographic security. The stored data contains no PII regardless of encoding. 9. Consent and Anonymous Mode 9.1. Consent API Implementations MUST provide a consent API that integrates with Consent Management Platforms (CMPs). The API MUST support the following operations: * setConsent({analytics: false}) - Deny consent, switch to anonymous mode * setConsent({analytics: true}) - Grant consent, restore identity tracking * getConsent() - Query current consent state, returns {analytics: boolean} 9.2. Anonymous Mode Behavior When consent is denied, the client MUST operate in anonymous mode with the following behavior: * Event tracking remains active but with no identity attached. * WaiTag generation is disabled; waiTag is null. * The identify() API call is a no-op and is silently ignored. * getSession() returns null for waiTag and userId fields. * Cross-domain identity is disabled; no tokens are generated or accepted. * Only a session-scoped anonymous identifier is used (format: anon__). * No persistent identity data is written to cookies, localStorage, or sessionStorage. Surampudi Expires 24 August 2026 [Page 13] Internet-Draft WTX-1 February 2026 9.3. Consent Restoration When consent is granted after starting in anonymous mode: 1. The client checks for previously stored identity data. 2. If found, the existing WaiTag and session are restored. 3. If not found, a new WaiTag is generated. 4. Cross-domain token checking is activated. 5. Full identity tracking resumes. 9.4. Regulatory Considerations WaiTags are designed to fall outside the GDPR [GDPR] definition of "personal data" as defined in Article 4(1) of Regulation (EU) 2016/679 because they contain no information derived from a natural person, cannot be reversed or cross-referenced to identify someone, and are not deterministic across sessions. However, the classification of pseudonymous identifiers under data protection law varies by jurisdiction and is subject to evolving regulatory interpretation. Implementers SHOULD consult local legal counsel. The anonymous mode provides a conservative fallback for jurisdictions where pseudonymous identifiers may be considered personal data. 10. Security Considerations 10.1. Token Security * Tokens MUST be signed server-side using HMAC [RFC2104] or an equivalent mechanism. * Tokens MUST have a configurable expiry window. The recommended default is 5 minutes. * Tokens SHOULD be single-use where feasible to prevent replay attacks. * Token verification MUST validate the signature and expiry. 10.2. Transport Security * All API communication between the client and the verification server MUST use HTTPS [RFC2818]. Surampudi Expires 24 August 2026 [Page 14] Internet-Draft WTX-1 February 2026 * Hash fragment transport prevents server-side token logging by design, as fragments are not included in HTTP requests per [RFC3986]. * When query parameter fallback is used, the client MUST clean the token from the URL after reading. 10.3. Input Validation * All client-supplied strings MUST be sanitized to prevent cross- site scripting (XSS) attacks. HTML entity encoding is RECOMMENDED. * String fields MUST be length-limited. The recommended maximum is 1,000 characters. * Domain values MUST be validated before use in DNS lookups or token generation. 10.4. Rate Limiting * API endpoints MUST implement rate limiting. The recommended default is 100 requests per IP address per minute. * Rate limit status MUST be communicated via X-RateLimit-Limit, X- RateLimit-Remaining, and X-RateLimit-Reset response headers. * Exceeded limits MUST return HTTP 429 (Too Many Requests). 10.5. Response Headers Servers implementing WTX-1 SHOULD set the following security-related response headers: * X-Content-Type-Options: nosniff * X-Frame-Options: SAMEORIGIN * Referrer-Policy: strict-origin-when-cross-origin * Permissions-Policy: camera=(), microphone=(), geolocation=() * Content-Security-Policy: Appropriate policy for the deployment * Strict-Transport-Security: max-age=31536000; includeSubDomains (when serving over HTTPS) Surampudi Expires 24 August 2026 [Page 15] Internet-Draft WTX-1 February 2026 11. IANA Considerations This document has no IANA actions. If this protocol achieves broader adoption, the following registrations may be requested in future revisions: * Registration of the "_nylo-verify" DNS underscore name prefix in the "Underscored and Globally Scoped DNS Node Names" registry per RFC 8552. * Registration of the "nylo_token" and "wai_token" URI fragment parameter names if a suitable registry is established. 12. Privacy Considerations WTX-1 is designed from the ground up to preserve user privacy while enabling cross-domain analytics. This section details the privacy properties, guarantees, and limitations of the protocol. 12.1. Core Privacy Commitments 1. No PII collection: The protocol never collects, transmits, or derives personal information such as names, email addresses, phone numbers, or physical addresses. 2. No fingerprinting: No hardware, software, or behavioral signals (screen resolution, installed fonts, GPU rendering, etc.) are used to generate or correlate identifiers. 3. No third-party cookies: Cross-domain identity does not use the Set-Cookie/Cookie HTTP mechanism for cross-domain transfer. 4. No login required: Identity preservation works for anonymous visitors without requiring authentication or account creation. 5. Consent-respecting: The protocol degrades to fully anonymous tracking when consent is denied, ensuring compliance with opt-out requirements. 6. Domain-authorized: Only DNS-verified domains can participate in identity sharing, preventing unauthorized cross-domain tracking. 7. Time-limited tokens: Cross-domain tokens expire (default 5 minutes), preventing indefinite tracking or token reuse. Surampudi Expires 24 August 2026 [Page 16] Internet-Draft WTX-1 February 2026 8. Client-side token reading: Hash fragment transport ensures tokens are never sent to destination servers in HTTP requests. The token is subsequently sent to the verification server via a dedicated API call for validation. 12.2. Pseudonymous Identifiers WaiTags are pseudonymous identifiers generated using cryptographically secure random number generators (window.crypto.getRandomValues). They contain no embedded personal information, device characteristics, or derivable real-world identity. A WaiTag cannot be reversed to identify a natural person without access to a separate mapping table, which the protocol does not define or require. Under GDPR, pseudonymous identifiers are still considered personal data when they can be attributed to a natural person by using additional information. Implementors MUST ensure that any additional information that could link a WaiTag to a natural person is kept separately and subject to appropriate technical and organizational measures. 12.3. User Control and Consent Implementations SHOULD provide users with clear mechanisms to: 1. Opt out of cross-domain identity sharing while retaining single- domain analytics. 2. Clear their WaiTag and session data at any time. 3. View what data has been collected about their pseudonymous identity. 4. Request deletion of all data associated with their WaiTag. When a user denies consent, the protocol MUST degrade gracefully to anonymous mode where no cross-domain tokens are generated or accepted, and only aggregate, non-identifiable analytics are collected. Surampudi Expires 24 August 2026 [Page 17] Internet-Draft WTX-1 February 2026 12.4. Data Minimization The protocol follows the principle of data minimization as required by GDPR Article 5(1)(c). Cross-domain tokens contain only the minimum fields necessary for identity verification: a WaiTag, session identifier, optional user identifier, source domain, expiration timestamp, and cryptographic signature. No behavioral data, page content, or interaction history is included in the token. 12.5. Cross-Domain Tracking Scope Cross-domain identity sharing is limited to domains that have been explicitly authorized via DNS TXT records. This prevents a domain from being included in a tracking network without the domain owner's explicit consent. The DNS verification mechanism ensures that only organizations with administrative control over a domain can authorize it for cross-domain identity sharing. Implementations MUST NOT allow wildcard domain authorization or open enrollment of domains into a tracking network. 12.6. Regulatory Compliance WTX-1 is designed to operate within the following regulatory frameworks: * GDPR (EU): Pseudonymous processing with data minimization, purpose limitation, and right to erasure support. * CCPA/CPRA (California): No sale of personal information; supports opt-out mechanisms. * ePrivacy Directive (EU): No use of cookies or similar technologies for cross-domain transfer; hash fragment transport does not trigger cookie consent requirements. * HIPAA (US Healthcare): No collection or transmission of Protected Health Information (PHI). * COPPA (US Children): Protocol does not collect age information; implementors in child-directed services MUST implement additional safeguards. Implementors are responsible for ensuring their specific deployment complies with applicable local regulations, as the protocol alone does not guarantee regulatory compliance. Surampudi Expires 24 August 2026 [Page 18] Internet-Draft WTX-1 February 2026 12.7. Limitations and Residual Risks While WTX-1 provides strong privacy guarantees, the following residual risks should be acknowledged: * Server-side correlation: Organizations operating multiple domains may correlate WaiTags server-side. The protocol limits this to DNS-authorized domains but cannot prevent the authorizing organization from performing correlation. * Token interception: Although hash fragment transport prevents tokens from being sent in HTTP requests, tokens may be visible to browser extensions or client-side JavaScript on the destination page before cleanup occurs. * Referrer leakage: Some browsers may include hash fragments in Referer headers under certain conditions. Implementations SHOULD set Referrer-Policy headers to mitigate this risk. * Long-lived sessions: If WaiTags are stored in localStorage without expiration, they persist indefinitely. Implementations SHOULD implement WaiTag rotation or expiration policies. 13. References 13.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Surampudi Expires 24 August 2026 [Page 19] Internet-Draft WTX-1 February 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [W3C-WebCryptoAPI] W3C, "Web Cryptography API", https://www.w3.org/TR/WebCryptoAPI/, W3C Recommendation , January 2017. [GDPR] European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation)", https://eur-lex.europa.eu/eli/reg/2016/679/oj, April 2016. [ITP] Apple WebKit, "Intelligent Tracking Prevention", https://webkit.org/blog/7675/intelligent-tracking- prevention/, June 2017. Comparison with Existing Approaches +========+==============+================+===========+=============+ |Property| 3P Cookies | Fingerprinting |Login-Based| WTX-1 | +========+==============+================+===========+=============+ |Cross | Yes | Yes |Yes | Yes | |eTLD+1 | (deprecated) | | | | +--------+--------------+----------------+-----------+-------------+ |Requires| No | No |Yes | No | |login | | | | | +--------+--------------+----------------+-----------+-------------+ |Collects| Varies | Yes |Yes | No | |PII | | | | | +--------+--------------+----------------+-----------+-------------+ |Browser | Declining | Declining |Universal | Universal | |support | | | | | +--------+--------------+----------------+-----------+-------------+ |Consent | Yes | Yes |Varies | Recommended | |required| | | | | +--------+--------------+----------------+-----------+-------------+ |Works on| No (ITP) | Partially |Yes | Yes | |Safari | | | | (degraded) | +--------+--------------+----------------+-----------+-------------+ Table 4: Cross-Domain Identity Approaches Surampudi Expires 24 August 2026 [Page 20] Internet-Draft WTX-1 February 2026 Acknowledgments WTX-1 was developed as part of the Nylo project to address the analytics gap created by the deprecation of third-party cookies, with a focus on privacy-respecting solutions for regulated industries including healthcare, finance, and government. Author's Address Ravi Teja Surampudi Nylo Project Email: ravisurampudi@outlook.com URI: https://github.com/tejasgit/nylo Surampudi Expires 24 August 2026 [Page 21]