SAIP: Signed Agent Identity Protocol
draft-jovancevic-saip-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Srecko Jovancevic | ||
| Last updated | 2026-04-03 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jovancevic-saip-00
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="<ID>"; alg="<ALG>"; ts="<TS>"; nonce="<NONCE>";
[pk="<PK>"]; sig="<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=<id>;ts=<ts>;nonce=<nonce>;method=<method>;path=<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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc7231>.
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="<ID>"; alg="<ALG>"; ts="<TS>"; nonce="<NONCE>";
[pk="<PK>"]; sig="<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=<id>;ts=<ts>;nonce=<nonce>;method=<method>;path=<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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc7231>.
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