Network Working Group S. Jovančević Internet-Draft SKGO, IKT Support Intended status: Standards Track 3 April 2026 Expires: 5 October 2026 SAIP: Signed Agent Identity Protocol draft-jovancevic-saip-00 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 5 October 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The modern web lacks a reliable mechanism for verifying the identity of HTTP user agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rise of automated agents. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP enables servers to distinguish between legitimate automated traffic and malicious actors. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Header Format . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Canonicalization and Signature . . . . . . . . . . . . . . . . 4 6. Processing Model . . . . . . . . . . . . . . . . . . . . . . . 5 7. Trust & Discovery Model . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Economic Traffic Model . . . . . . . . . . . . . . . . . . . . 6 10. System Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 13.1. Normative References . . . . . . . . . . . . . . . . . . . 7 13.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The modern web lacks a reliable mechanism for verifying the identity of HTTP user agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rise of automated agents. SAIP introduces a lightweight, opt-in mechanism for verifiable client identity at the application layer, enabling servers to distinguish between legitimate automated traffic and malicious actors. 2. Problem Statement Spoofability: User-Agent strings are trivial to manipulate. IP Fatigue: IP-based filtering is unreliable for NAT users and shared cloud proxies. Automation Friction: Critical systems (backup agents, internal APIs, AI bots) are frequently blocked by generic security rules. SMTP Trust Gap: Lack of granular client-level identity allows spam and abuse from compromised local systems. 3. Design Goals Simplicity (KISS): Minimal overhead, single-header implementation. Opt-in: No mandatory adoption; compatible with legacy systems. Backward Compatibility: No changes to existing protocol semantics or HTTP methods. Protocol-Agnostic: Applicable to HTTP, SMTP, and other header-based protocols. 4. Protocol Overview SAIP defines a cryptographic identity signal transmitted via a single HTTP-style header. SAIP is designed as a supplemental identity signal, not a replacement for existing authentication or bot- detection frameworks (like OAuth2, JWT, or TLS-fingerprinting). It provides an additional layer of verifiable metadata that allows existing web-bot-auth systems to make faster and more accurate trust decisions. In practice, SAIP allows: * Application-level identification of specific software instances (e.g., a backup agent or M365 sync bridge). * Flexible key discovery, either via an embedded public key ('pk') or via external registries based on the 'id'. * Gradual, opt-in deployment alongside legacy infrastructure, without altering the semantics of HTTP or SMTP. 4.1. Header Format The SAIP header is structured as a semicolon-separated list of parameters: SAIP: id=""; alg=""; ts=""; nonce=""; [pk=""]; sig="" Each parameter is encoded as a quoted string, and the order of parameters is not significant for parsing. The header is case- sensitive for the parameter names, but implementations MUST treat them as case-sensitive identifiers in their logic. 4.2. Parameters +=========+==========+==========+=================================+ | Param | Type | Required | Description | +=========+==========+==========+=================================+ | id | String | Yes | Logical agent identifier (e.g., | | | | | "backup-001"). Allowed chars: | | | | | a-z, 0-9, ., _, -. No semicolon | | | | | or space. Max 128 chars. | +---------+----------+----------+---------------------------------+ | alg | String | Yes | Algorithm identifier. | | | | | Recommended: ed25519 or | | | | | hmac-sha256. | +---------+----------+----------+---------------------------------+ | ts | Integer | Yes | Unix timestamp for freshness | | | | | validation. | +---------+----------+----------+---------------------------------+ | nonce | String | Yes | Per-request unique value (min 8 | | | | | chars) to prevent replay. | +---------+----------+----------+---------------------------------+ | sig | Base64 | Yes | Signature computed over the | | | | | canonical string. | +---------+----------+----------+---------------------------------+ | pk | Base64URL| No | Optional public key for | | | | | stateless verification. | +---------+----------+----------+---------------------------------+ 5. Canonicalization and Signature The signature MUST be computed over a canonical string constructed as follows: id=;ts=;nonce=;method=;path= Note: The canonical string binds the identity to a specific request method and path, preventing signature reuse across different endpoints. 6. Processing Model 1. Client: - Constructs the canonical string. - Signs the string using a private key (asymmetric) or shared secret (symmetric). - Adds the SAIP header to the request. 2. Server: - Parses the SAIP header. - Reconstructs the canonical string from request metadata. - Verifies the signature (using 'pk' from header or looking up key via 'id'). - Applies policy based on the verified identity. 7. Trust & Discovery Model SAIP supports two primary trust discovery patterns: Stateless (Key-in-Header): If 'pk' is provided, the server may verify the signature immediately. Registry-Based: The server uses 'id' to lookup the public key in a distributed registry (e.g., Consortium Blockchain, DNS-based records, or internal pre-shared keys). 8. Security Considerations Timestamp Validation: Servers SHOULD enforce a strict window (e.g., ±300 seconds). Constant-Time Comparison: Signature verification MUST use constant- time algorithms to prevent timing attacks. Replay Protection: Nonce tracking is recommended for sensitive endpoints. ID Safety: By restricting the 'id' character set, SAIP prevents header injection and parsing ambiguities. 9. Economic Traffic Model (Policy) SAIP shifts traffic handling from binary filtering to incentive-based classification. +===================+==============+===========+===================+ | Agent Category | SAIP Status | Trust | Example Rate | | | | Level | Limit | +===================+==============+===========+===================+ | Internal Systems | Verified | High | Unrestricted | +-------------------+--------------+-----------+-------------------+ | Known Partners | Verified | Medium | 100 req/sec | +-------------------+--------------+-----------+-------------------+ | General Clients | Verified | Low | 10 req/sec | +-------------------+--------------+-----------+-------------------+ | Anonymous | None | Minimal | 1 req/sec | +-------------------+--------------+-----------+-------------------+ 10. System Overview +-------------------+ +-------------------+ +-----------------------------+ | CLIENT | | SERVER | | POLICY DECISION ENGINE | |-------------------| |-------------------| |-----------------------------| | 1. Generate ID | | 1. Parse SAIP | | 1. Trust Scoring | | 2. Sign Request | ----> | 2. Verify Sig | ----> | 2. Reputation Lookup | | 3. Send Header | | 3. Check Freshness| | 3. Apply Rate Limit | +-------------------+ +-------------------+ +-----------------------------+ 11. Conclusion SAIP does not enforce trust — it enables it. By providing a verifiable identity signal, SAIP allows servers to reward legitimate agents with preferential handling, effectively increasing the economic cost of abuse and impersonation. 12. IANA Considerations This document requests IANA to register the following header in the "Permanent Message Header Field Names" registry: Header field name: SAIP Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: This RFC 13. References 13.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, . 13.2. Informative References [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . Author's Address Srećko Jovančević SKGO, IKT Support Makedonska 22 11000 Belgrade Serbia Email: srecko.jovancevic@skgo.org URI: https://github.com/sreckojovancevicNetwork Working Group S. Jovančević Internet-Draft SKGO, IKT Support Intended status: Standards Track 3 April 2026 Expires: 5 October 2026 SAIP: Signed Agent Identity Protocol draft-jovancevic-saip-00 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 5 October 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract The modern web lacks a reliable mechanism for verifying the identity of HTTP user agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rise of automated agents. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP enables servers to distinguish between legitimate automated traffic and malicious actors. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 2 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Header Format . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Canonicalization and Signature . . . . . . . . . . . . . . . . 4 6. Processing Model . . . . . . . . . . . . . . . . . . . . . . . 5 7. Trust & Discovery Model . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Economic Traffic Model . . . . . . . . . . . . . . . . . . . . 6 10. System Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 13.1. Normative References . . . . . . . . . . . . . . . . . . . 7 13.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The modern web lacks a reliable mechanism for verifying the identity of HTTP user agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rise of automated agents. SAIP introduces a lightweight, opt-in mechanism for verifiable client identity at the application layer, enabling servers to distinguish between legitimate automated traffic and malicious actors. 2. Problem Statement Spoofability: User-Agent strings are trivial to manipulate. IP Fatigue: IP-based filtering is unreliable for NAT users and shared cloud proxies. Automation Friction: Critical systems (backup agents, internal APIs, AI bots) are frequently blocked by generic security rules. SMTP Trust Gap: Lack of granular client-level identity allows spam and abuse from compromised local systems. 3. Design Goals Simplicity (KISS): Minimal overhead, single-header implementation. Opt-in: No mandatory adoption; compatible with legacy systems. Backward Compatibility: No changes to existing protocol semantics or HTTP methods. Protocol-Agnostic: Applicable to HTTP, SMTP, and other header-based protocols. 4. Protocol Overview SAIP defines a cryptographic identity signal transmitted via a single HTTP-style header. SAIP is designed as a supplemental identity signal, not a replacement for existing authentication or bot- detection frameworks (like OAuth2, JWT, or TLS-fingerprinting). It provides an additional layer of verifiable metadata that allows existing web-bot-auth systems to make faster and more accurate trust decisions. In practice, SAIP allows: * Application-level identification of specific software instances (e.g., a backup agent or M365 sync bridge). * Flexible key discovery, either via an embedded public key ('pk') or via external registries based on the 'id'. * Gradual, opt-in deployment alongside legacy infrastructure, without altering the semantics of HTTP or SMTP. 4.1. Header Format The SAIP header is structured as a semicolon-separated list of parameters: SAIP: id=""; alg=""; ts=""; nonce=""; [pk=""]; sig="" Each parameter is encoded as a quoted string, and the order of parameters is not significant for parsing. The header is case- sensitive for the parameter names, but implementations MUST treat them as case-sensitive identifiers in their logic. 4.2. Parameters +=========+==========+==========+=================================+ | Param | Type | Required | Description | +=========+==========+==========+=================================+ | id | String | Yes | Logical agent identifier (e.g., | | | | | "backup-001"). Allowed chars: | | | | | a-z, 0-9, ., _, -. No semicolon | | | | | or space. Max 128 chars. | +---------+----------+----------+---------------------------------+ | alg | String | Yes | Algorithm identifier. | | | | | Recommended: ed25519 or | | | | | hmac-sha256. | +---------+----------+----------+---------------------------------+ | ts | Integer | Yes | Unix timestamp for freshness | | | | | validation. | +---------+----------+----------+---------------------------------+ | nonce | String | Yes | Per-request unique value (min 8 | | | | | chars) to prevent replay. | +---------+----------+----------+---------------------------------+ | sig | Base64 | Yes | Signature computed over the | | | | | canonical string. | +---------+----------+----------+---------------------------------+ | pk | Base64URL| No | Optional public key for | | | | | stateless verification. | +---------+----------+----------+---------------------------------+ 5. Canonicalization and Signature The signature MUST be computed over a canonical string constructed as follows: id=;ts=;nonce=;method=;path= Note: The canonical string binds the identity to a specific request method and path, preventing signature reuse across different endpoints. 6. Processing Model 1. Client: - Constructs the canonical string. - Signs the string using a private key (asymmetric) or shared secret (symmetric). - Adds the SAIP header to the request. 2. Server: - Parses the SAIP header. - Reconstructs the canonical string from request metadata. - Verifies the signature (using 'pk' from header or looking up key via 'id'). - Applies policy based on the verified identity. 7. Trust & Discovery Model SAIP supports two primary trust discovery patterns: Stateless (Key-in-Header): If 'pk' is provided, the server may verify the signature immediately. Registry-Based: The server uses 'id' to lookup the public key in a distributed registry (e.g., Consortium Blockchain, DNS-based records, or internal pre-shared keys). 8. Security Considerations Timestamp Validation: Servers SHOULD enforce a strict window (e.g., ±300 seconds). Constant-Time Comparison: Signature verification MUST use constant- time algorithms to prevent timing attacks. Replay Protection: Nonce tracking is recommended for sensitive endpoints. ID Safety: By restricting the 'id' character set, SAIP prevents header injection and parsing ambiguities. 9. Economic Traffic Model (Policy) SAIP shifts traffic handling from binary filtering to incentive-based classification. +===================+==============+===========+===================+ | Agent Category | SAIP Status | Trust | Example Rate | | | | Level | Limit | +===================+==============+===========+===================+ | Internal Systems | Verified | High | Unrestricted | +-------------------+--------------+-----------+-------------------+ | Known Partners | Verified | Medium | 100 req/sec | +-------------------+--------------+-----------+-------------------+ | General Clients | Verified | Low | 10 req/sec | +-------------------+--------------+-----------+-------------------+ | Anonymous | None | Minimal | 1 req/sec | +-------------------+--------------+-----------+-------------------+ 10. System Overview +-------------------+ +-------------------+ +-----------------------------+ | CLIENT | | SERVER | | POLICY DECISION ENGINE | |-------------------| |-------------------| |-----------------------------| | 1. Generate ID | | 1. Parse SAIP | | 1. Trust Scoring | | 2. Sign Request | ----> | 2. Verify Sig | ----> | 2. Reputation Lookup | | 3. Send Header | | 3. Check Freshness| | 3. Apply Rate Limit | +-------------------+ +-------------------+ +-----------------------------+ 11. Conclusion SAIP does not enforce trust — it enables it. By providing a verifiable identity signal, SAIP allows servers to reward legitimate agents with preferential handling, effectively increasing the economic cost of abuse and impersonation. 12. IANA Considerations This document requests IANA to register the following header in the "Permanent Message Header Field Names" registry: Header field name: SAIP Applicable protocol: http Status: standard Author/Change controller: IETF Specification document: This RFC 13. References 13.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, . 13.2. Informative References [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . Author's Address Srećko Jovančević SKGO, IKT Support Makedonska 22 11000 Belgrade Serbia Email: srecko.jovancevic@skgo.org URI: https://github.com/sreckojovancevic