SAIP: Signed Agent Identity Protocol
draft-jovancevic-saip-02
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-16 (Latest revision 2026-04-09) | ||
| 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-02
Network Working Group S. Jovančević
Internet-Draft SKGO, IKT Support
Intended status: Standards Track 16 April 2026
Expires: 18 October 2026
SAIP: Signed Agent Identity Protocol
draft-jovancevic-saip-02
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 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 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 modern internet lacks a reliable mechanism for verifying the
identity of automated software agents. Existing methods such as
User-Agent strings and IP-based attribution are insufficient due to
spoofing, shared infrastructure (NAT), and the rapid growth of
automated agents including AI crawlers, IoT devices, and enterprise
automation systems.
This document specifies SAIP (Signed Agent Identity Protocol), a
lightweight, opt-in mechanism for verifiable client identity at the
application layer. SAIP implements the principles defined in the
Verifiable Identity Claims and Delegation Model [VICDM] and enables
servers to distinguish legitimate automated traffic from malicious
actors through cryptographic identity at three levels of granularity:
vendor, agent type, and individual instance.
SAIP is protocol-agnostic and applicable to HTTP, SMTP, and other
header-based protocols. It introduces DNS-based key discovery as
a lightweight alternative to registry-based key lookup, making
deployment accessible to organizations of any size.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 6
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . 6
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 7
5.1. Identification vs. Authorization . . . . . . . . . . . 7
5.2. Header Format . . . . . . . . . . . . . . . . . . . . . 7
5.3. Parameters . . . . . . . . . . . . . . . . . . . . . . 8
6. Canonicalization and Signature . . . . . . . . . . . . . . 9
6.1. HTTP Canonical String . . . . . . . . . . . . . . . . . 9
6.2. SMTP Canonical String . . . . . . . . . . . . . . . . . 10
6.3. Other Protocols . . . . . . . . . . . . . . . . . . . . 10
7. Rolling Key Derivation Function (RKDF) . . . . . . . . . . 10
7.1. Key Rotation Model . . . . . . . . . . . . . . . . . . 10
7.2. Sequence Window . . . . . . . . . . . . . . . . . . . . 11
7.3. Renegotiation and Recovery . . . . . . . . . . . . . . 11
7.4. Graceful Key Rotation . . . . . . . . . . . . . . . . . 13
7.5. Forward-Only Constraint . . . . . . . . . . . . . . . . 13
8. Opt-In Telemetry (tm= field) . . . . . . . . . . . . . . . 14
8.1. Commitment-Based Model . . . . . . . . . . . . . . . . 14
8.2. Audit-on-Demand . . . . . . . . . . . . . . . . . . . . 14
8.3. Telemetry Field Registry . . . . . . . . . . . . . . . 15
9. Processing Model . . . . . . . . . . . . . . . . . . . . . 15
9.1. Client Processing . . . . . . . . . . . . . . . . . . . 15
9.2. Server Processing . . . . . . . . . . . . . . . . . . . 16
10. Trust and Key Discovery . . . . . . . . . . . . . . . . . . 17
10.1. Stateless Mode (pk=) . . . . . . . . . . . . . . . . . 17
10.2. DNS-Based Discovery . . . . . . . . . . . . . . . . . . 17
10.3. Registry-Based Discovery . . . . . . . . . . . . . . . 19
10.4. Discovery Priority Order . . . . . . . . . . . . . . . 19
11. Registration Entity (RE) Requirements . . . . . . . . . . . 20
11.1. RE Eligibility . . . . . . . . . . . . . . . . . . . . 20
11.2. RE Governance . . . . . . . . . . . . . . . . . . . . . 21
11.3. Bootstrap and Evolution . . . . . . . . . . . . . . . . 21
12. Granular Policy Model . . . . . . . . . . . . . . . . . . . 22
13. SMTP Integration . . . . . . . . . . . . . . . . . . . . . 23
14. Security Considerations . . . . . . . . . . . . . . . . . . 24
15. Privacy Considerations . . . . . . . . . . . . . . . . . . 26
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
17. References . . . . . . . . . . . . . . . . . . . . . . . . 27
17.1. Normative References . . . . . . . . . . . . . . . . . 27
17.2. Informative References . . . . . . . . . . . . . . . . 28
Appendix A. IoT Use Case . . . . . . . . . . . . . . . . . . . 29
Appendix B. Relationship to Existing Standards . . . . . . . . 30
Appendix C. VICDM Alignment . . . . . . . . . . . . . . . . . 31
Appendix D. DNS Record Examples . . . . . . . . . . . . . . . 32
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction
The modern internet increasingly relies on automated software agents
— AI crawlers, backup systems, IoT devices, monitoring agents, and
enterprise integration services — to perform essential functions.
However, these agents have no reliable, verifiable way to prove
their identity to the servers they communicate with.
Current approaches are fundamentally inadequate:
o User-Agent strings are trivially spoofable text fields with no
cryptographic binding.
o IP-based filtering causes collateral damage on shared
infrastructure and is ineffective against distributed agents.
o Existing authentication frameworks (OAuth2, JWT, mTLS) operate
at the session or user level, not the agent instance level.
SAIP addresses this gap by introducing a cryptographic identity
signal at the application layer — a single header that allows any
server to verify the identity of the agent making a request at the
level of the individual software instance, without disrupting
existing protocol semantics.
1.1. Design Philosophy: The VICDM Principle
SAIP is grounded in the Verifiable Identity Claims and Delegation
Model [VICDM], which establishes the following core principle:
Anonymous interaction is permitted.
Identity assertion is permitted.
False identity assertion is not.
This principle has a critical implication for policy:
An agent that asserts an identity it cannot prove is more
dangerous than an agent that asserts no identity at all. The
former actively corrupts trust signals; the latter is simply
anonymous. Systems implementing SAIP SHOULD treat unverifiable
identity claims with lower trust than genuine anonymous clients.
SAIP is the protocol-layer implementation of this principle:
it provides the cryptographic mechanism by which identity
assertions become verifiable.
1.2. Relationship to Anonymous Authentication
Anonymous bot authentication systems (such as Privacy Pass and
related mechanisms under development in the IETF webbotauth
working group) allow a bot to prove it is vouched for by a
trusted attester without revealing its specific identity.
SAIP and anonymous authentication are complementary:
o Anonymous authentication addresses the privacy use case.
o SAIP addresses the accountability use case.
The web needs both. Sites that require per-instance revocation,
audit trails, and fleet management need SAIP. Sites whose primary
concern is privacy-preserving rate limiting may prefer anonymous
attestation. Many deployments will benefit from both.
1.3. Changes from draft-jovancevic-saip-01
This document adds the following relative to -01:
o Explicit alignment with [VICDM] principles (Section 1.1)
o DNS-based key discovery (Section 10.2) as a lightweight
alternative to RE registry lookup
o DNS delegation record format (Section 10.2)
o VICDM identity class mapping (Appendix C)
o DNS record examples (Appendix D)
o Clarified relationship to anonymous authentication (Section 1.2)
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.
Agent: A software process that makes automated requests on
behalf of a vendor or operator. Examples include AI
crawlers, backup agents, IoT devices, and monitoring
systems.
Vendor: The organization or developer responsible for an
agent. Holds the Master Key and is registered with
a Registration Entity or publishes keys via DNS.
Instance: A specific, uniquely identified installation or
deployment of an agent. Each instance has its own
derived identity and Rolling Key state.
Master Key: A long-term cryptographic key held by the vendor,
used to derive per-instance Rolling Keys via RKDF.
MUST be stored in hardware-backed secure storage
where available.
Rolling Key: A short-lived cryptographic key derived from the
Master Key via RKDF, used to sign exactly one
request. MUST be destroyed immediately after use.
Registration An organization authorized to maintain and
Entity (RE): distribute the public key registry for SAIP
vendors. Operates analogously to a Certificate
Authority in PKI systems.
RKDF: Rolling Key Derivation Function. The mechanism by
which Rolling Keys are derived sequentially from
the Master Key and sequence state.
Sequence: A monotonically increasing integer maintained by
both client and server to track Rolling Key state.
VICDM: Verifiable Identity Claims and Delegation Model.
The conceptual framework [VICDM] that defines
the principles this protocol implements.
3. Problem Statement
Spoofability: User-Agent strings are trivial to manipulate.
Any agent can claim any identity without
cryptographic proof.
IP Fatigue: IP-based filtering is unreliable for agents
operating behind NAT, shared proxies, or cloud
infrastructure.
Automation Critical systems (backup agents, internal APIs,
Friction: AI bots, IoT devices) are frequently blocked by
generic security rules that cannot distinguish
legitimate automation from malicious traffic.
SMTP Trust Gap: Lack of granular client-level identity allows
spam and abuse from compromised mail servers.
Zero There is no existing mechanism to revoke access
Accountability: for a specific software instance without
affecting all other instances of the same vendor.
False Identity: Under [VICDM], an agent asserting an identity
it cannot prove is categorically more harmful
than an anonymous agent. Current protocols
provide no mechanism to distinguish or penalize
false identity claims.
4. Design Goals
Simplicity Minimal overhead, single-header implementation.
(KISS): No changes to existing protocol semantics.
Opt-In: No mandatory adoption. Compatible with legacy
systems. Servers that do not implement SAIP
MUST ignore the SAIP header without error.
Backward SAIP MUST NOT alter the semantics of HTTP,
Compatibility: SMTP, or any other protocol.
Protocol- Applicable to HTTP, SMTP, and other header-
Agnostic: based protocols.
Granular Policy decisions MUST be applicable at vendor,
Control: agent type, and instance level independently.
Identification SAIP is strictly an identification protocol.
Only: It MUST NOT be used as an authorization
mechanism.
Accessible DNS-based key discovery enables organizations
Deployment: of any size to deploy SAIP without RE
registration.
5. Protocol Overview
5.1. Identification vs. Authorization
SAIP provides a verifiable cryptographic assertion of WHO an agent
is. It does not determine what that agent is permitted to do.
Authorization remains the exclusive responsibility of existing
application-layer mechanisms such as OAuth 2.0 [RFC6749], JWT,
or ACLs.
Under [VICDM], SAIP clients with successful verification are
Class 3 (Fully Verified). See Appendix C for the full mapping.
5.2. Header Format
The SAIP header is structured as a semicolon-separated list of
parameters transmitted as a standard HTTP header field [RFC9110]:
SAIP: id="<ID>"; alg="<ALG>"; ts="<TS>"; nonce="<NONCE>";
[pk="<PK>"]; [tm="<TM>"]; sig="<SIG>"
Each parameter MUST be encoded as a quoted string. The order of
parameters is NOT significant for parsing. Parameter names are
case-sensitive.
5.3. Parameters
+=========+==========+==========+================================+
| Param | Type | Required | Description |
+=========+==========+==========+================================+
| id | String | MUST | Agent instance identifier. |
| | | | Allowed chars: a-z, 0-9, ., _, |
| | | | -. Maximum 128 characters. |
| | | | RECOMMENDED format: |
| | | | vendor.type.instance |
| | | | Where vendor component SHOULD |
| | | | correspond to the domain used |
| | | | in DNS key discovery. |
+---------+----------+----------+--------------------------------+
| alg | String | MUST | Algorithm: "ed25519" or |
| | | | "hmac-sha256". Implementations |
| | | | MUST support "ed25519". |
+---------+----------+----------+--------------------------------+
| ts | Integer | MUST | Unix timestamp at signing. |
+---------+----------+----------+--------------------------------+
| nonce | String | MUST | Per-request unique value, |
| | | | minimum 8 chars, cryptographic |
| | | | randomness per [RFC4086]. |
+---------+----------+----------+--------------------------------+
| sig | Base64 | MUST | Signature over canonical string|
| | | | per Section 6. |
+---------+----------+----------+--------------------------------+
| pk | Base64URL| MAY | Public key for stateless |
| | | | verification. |
+---------+----------+----------+--------------------------------+
| tm | Base64 | MAY | Opt-in telemetry commitment. |
| | | | See Section 8. MUST NOT be |
| | | | present unless explicitly |
| | | | enabled by deployment policy. |
+---------+----------+----------+--------------------------------+
Implementations MUST reject headers missing any MUST parameter.
Implementations MUST silently ignore unknown parameters.
6. Canonicalization and Signature
6.1. HTTP Canonical String
id=<id>;ts=<ts>;nonce=<nonce>;method=<METHOD>;path=<path>
Where <METHOD> is uppercase and <path> includes the query string
if present.
Example:
id=acme.crawler.nyc-042;ts=1744200000;nonce=f3k9p2m1;
method=GET;path=/api/v1/data?format=json
6.2. SMTP Canonical String
id=<id>;ts=<ts>;nonce=<nonce>;phase=EHLO;helo=<helo_name>
6.3. Other Protocols
id=<id>;ts=<ts>;nonce=<nonce>;phase=<PHASE>
The canonical string definition for each protocol binding MUST
be documented by the implementing software or a future companion
specification.
7. Rolling Key Derivation Function (RKDF)
7.1. Key Rotation Model
SAIP uses per-request Rolling Key rotation.
RollingKey_(n+1) = HMAC-SHA256(MasterKey, InstanceID || Seq_n)
Where Seq_n is a big-endian unsigned 64-bit integer.
The Rolling Key MUST be used to sign exactly one request and
MUST be destroyed immediately after use.
The MasterKey SHOULD be stored in hardware-backed secure storage
(TPM 2.0, HSM, Apple Secure Enclave, Android StrongBox).
7.2. Sequence Window
Servers MUST implement a configurable look-ahead sequence window:
o Default window size SHOULD be 5.
o Maximum window size MUST NOT exceed 10.
o Received sequence numbers within the window cause the server
to advance state and invalidate prior sequences.
o Sequences outside the window MUST be rejected.
Upon successful verification, servers SHOULD respond with:
SAIP-Next-Seq: <n+1>
Clients MUST advance sequence state on receipt of this header.
On missing response, clients MUST retry with the same Rolling Key.
7.3. Renegotiation and Recovery
Full Renegotiation MAY be initiated when a client loses sequence
state entirely.
Full Renegotiation MUST be authorized exclusively by an RE.
Endpoint servers MUST NOT authorize Full Renegotiation.
The Full Renegotiation process:
1. Client sends a Renegotiation Request to RE containing:
- InstanceID, reason code, timestamp, nonce
- Signature using previous MasterKey (valid window: 24 hours
from ts value)
- Hardware Attestation evidence per [RFC9334] (RECOMMENDED)
2. RE MUST validate:
- MasterKey signature valid and within validity window
- InstanceID not revoked
- Rate limit: maximum 3 renegotiation requests per InstanceID
per 24-hour period
- Hardware Attestation consistent with registered hardware
(if provided)
3. On success, RE issues new RKDF seed and starting Sequence.
Previous sequence range is permanently invalidated.
4. Vendor MUST be notified of all Full Renegotiation events.
7.4. Graceful Key Rotation
Key transitions use the SAIP-Key-Version header:
SAIP-Key-Version: <new>; fallback=<old>;
fallback-expires=<unix_timestamp>
o Servers with new key MUST accept new key version.
o Servers without new key SHOULD accept fallback until expiry.
o After fallback-expires, old key MUST be rejected.
7.5. Forward-Only Constraint
Implementations MUST enforce:
o Sequence numbers MUST NOT decrease.
o Algorithm MUST NOT downgrade during renegotiation.
o Full Renegotiation MUST be RE-authorized.
o Violations MUST be rejected and logged.
8. Opt-In Telemetry (tm= field)
8.1. Commitment-Based Model
The tm= field MUST NOT be transmitted without explicit opt-in.
tm = HMAC-SHA256(RollingKey, Metadata_String)
Where Metadata_String is a semicolon-separated key=value string.
The tm= value is computed using the same RollingKey as sig=.
Raw metadata MUST NOT appear in the header.
Example:
asn=1234;geo=RS;attest=trusted;fw=2.1.4
8.2. Audit-on-Demand
Servers SHOULD store tm= in audit logs. During incident response:
1. Operator obtains raw Metadata_String from client or RE log.
2. Verifier recomputes HMAC-SHA256(RollingKey, Metadata_String).
3. Match confirms metadata authenticity.
8.3. Telemetry Field Registry
RECOMMENDED standard fields (IANA registry requested):
asn Autonomous System Number
geo ISO 3166-1 alpha-2 country code
attest Hardware attestation status
fw Firmware or software version
gps Physical coordinates (IoT)
api_hash HMAC of associated API credential
9. Processing Model
9.1. Client Processing
1. Construct canonical string per Section 6.
2. Derive current Rolling Key via RKDF (Section 7.1).
3. Sign canonical string using Rolling Key and alg=.
4. If telemetry enabled, compute tm= per Section 8.1.
5. Construct and transmit SAIP header.
6. On receiving SAIP-Next-Seq response: advance Sequence state,
destroy used Rolling Key immediately.
7. On missing response: retry with same Rolling Key and Sequence.
9.2. Server Processing
1. Parse SAIP header. Reject if any MUST parameter is absent.
2. Validate ts=. MUST reject if |server_time - ts| > 300 seconds.
3. Validate nonce. SHOULD track nonces within validity window
for sensitive endpoints.
4. Obtain public key via discovery order (Section 10.4).
5. Reconstruct canonical string and verify signature using
constant-time comparison.
6. On success, include SAIP-Next-Seq in response.
7. Apply policy per Section 12 based on verified identity.
8. If tm= present and audit mode active, store in audit log.
9. Classify client per [VICDM] identity classes:
- Verified signature: Class 3 (Fully Verified)
- DNS partial match only: Class 2 (Partially Verified)
- No SAIP header: Class 0 (Anonymous)
- Invalid/unverifiable: Class 1 (treat below Class 0)
10. Trust and Key Discovery
10.1. Stateless Mode (pk=)
If pk= is present, the server MAY verify immediately without
external lookup.
Servers SHOULD verify pk= consistency with prior observations
for the same id= to detect key substitution attacks.
10.2. DNS-Based Discovery
DNS-based discovery allows vendors to publish their SAIP public
key and delegation information without RE registration, using
the existing DNS infrastructure.
Servers perform a DNS TXT query at:
_saip.<vendor-domain>.
Where <vendor-domain> is derived from the vendor component of
the id= parameter (the leftmost label before the first dot).
Example: for id="acme.crawler.nyc-042", the server queries:
_saip.acme.
The DNS TXT record format follows [VICDM] Section 6.2:
_saip.<domain>. IN TXT "v=saip1; [parameters]"
Defined parameters:
v=saip1 MUST be present. Version indicator.
pk=<key> Base64URL-encoded Ed25519 public key.
Used directly for signature verification.
re=<host> Preferred RE hostname for registry-based lookup.
MAY be used as fallback if pk= verification fails.
asn=<list> Comma-separated authorized ASNs for delegated
infrastructure per [VICDM] Section 6.1.
ip=<prefix> CIDR prefix of authorized delegated infrastructure.
Multiple ip= parameters are permitted.
exp=<ts> Unix timestamp after which this record SHOULD be
considered expired. Servers SHOULD NOT use expired
records for verification.
Example records:
; Simple public key publication
_saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd..."
; With preferred RE
_saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd...;
re=re1.saip-registry.example"
; With delegated infrastructure authorization
_saip.acme.com. IN TXT "v=saip1; pk=MCowBQYDK2Vd...;
asn=13335,15169"
DNS-based verification requirements:
o Servers MUST validate DNSSEC signatures where available
[RFC4033].
o Servers MUST NOT use DNS responses with TTL of 0 for
key material.
o Servers SHOULD cache DNS key material according to the
record TTL. Default TTL SHOULD be 3600 seconds.
o If the DNS record contains asn= or ip= parameters, the
server SHOULD verify that the client's network source is
within the authorized set before accepting the key.
o If the DNS record has expired (exp= in the past), the server
MUST NOT use the key material for verification and SHOULD
treat the request as Class 1 (unverifiable claim) per [VICDM].
10.3. Registry-Based Discovery
The server uses the id= parameter to look up the public key
from a distributed RE registry.
Implementations MUST support caching of registry responses:
minimum TTL 60 seconds, maximum TTL 3600 seconds.
10.4. Discovery Priority Order
When multiple discovery methods are available, servers MUST
apply them in the following priority order:
1. pk= parameter (stateless, highest priority)
2. DNS-based discovery (_saip.<domain> TXT record)
3. RE registry lookup (using id=)
Servers MAY skip lower-priority methods once a valid key is
found. Servers MUST NOT accept a request if no valid key can
be found through any available method.
11. Registration Entity (RE) Requirements
11.1. RE Eligibility
An organization qualifies as a Registration Entity if it
satisfies all of the following:
Global Infrastructure: Operates internet-scale infrastructure
with sufficient geographic distribution
to serve RE queries globally.
Operational Track Record: Demonstrated history of reliably
operating critical internet
infrastructure.
Neutrality Commitment: Formal agreement not to discriminate
against any vendor, agent type, or
competing RE.
Community Approval: Majority consensus approval from
existing active REs via cryptographically
signed statements.
An RE MUST maintain query availability of no less than 99.9%
on a rolling 30-day basis.
An RE MUST propagate revocation events to all peer REs within
300 seconds of issuance.
11.2. RE Governance
No single entity controls the set of Registration Entities.
A new RE MAY be added when a strict majority of existing active
REs approve via signed statements in the RE audit log.
An RE MUST be removed if:
o Availability requirement fails for more than 72 consecutive
hours, OR
o Neutrality commitment is violated (majority vote), OR
o RE ceases operations voluntarily.
All RE membership changes MUST be recorded in a publicly
accessible, append-only, verifiable audit log.
11.3. Bootstrap and Evolution
The initial RE set is defined in the SAIP RE Bootstrap Registry
(IANA, Section 16). The bootstrap set SHOULD include:
o Regional Internet Registries (RIPE NCC, ARIN, APNIC,
LACNIC, AFRINIC) — non-profit, geographically distributed,
operationally neutral by mandate.
o Academic and neutral institutions (Internet Society, ICANN,
established research universities) — independent, non-
commercial representation.
o Infrastructure operators meeting Section 11.1 criteria.
No single commercial organization category SHALL hold a majority
of bootstrap RE positions.
Vendors register with any RE of their choice. Servers configure
which REs they trust. DNS-based discovery (Section 10.2) is
available as a zero-registration alternative.
12. Granular Policy Model
SAIP enables policy enforcement at three levels independently:
Vendor Level: All agents and instances of a given vendor.
Agent Type Level: All instances of a specific agent type from
a given vendor.
Instance Level: Exactly one agent instance (full id= value).
Implementations MUST support instance-level revocation without
affecting other instances of the same vendor or agent type.
Policy actions include:
o BLOCK: Reject all requests from the targeted entity.
o THROTTLE: Apply rate limits to the targeted entity.
o DEGRADE: Reduce trust classification.
o ALLOW: Grant priority or elevated rate limits.
VICDM identity class mapping (see Appendix C) SHOULD inform
the base trust level before granular policy is applied.
Informative traffic classification:
+===================+==============+=========+==================+
| Agent Category | SAIP Status | Trust | Example Rate |
+===================+==============+=========+==================+
| 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 |
+-------------------+--------------+---------+------------------+
| False Claim | Unverifiable | Below | Reject or |
| | | Minimal | 0.1 req/sec |
+-------------------+--------------+---------+------------------+
13. SMTP Integration
SAIP MAY be applied as an agent identity layer in SMTP [RFC5321]
without modifying the SMTP protocol.
The sending server MAY transmit a SAIP header line immediately
after the server's EHLO response and before MAIL FROM.
The SMTP canonical string per Section 6.2 MUST be used.
Example exchange:
C: EHLO backup-agent.example.com
S: 250-mail.example.com Hello backup-agent.example.com
250-SIZE 52428800
250-8BITMIME
250 STARTTLS
C: SAIP: id="acme.mailer.relay-bg-01"; alg="ed25519";
ts="1744200000"; nonce="7f3k9p2m";
pk="<base64url_public_key>"; sig="<base64_sig>"
S: (validates signature, timestamp, nonce)
If invalid: 550 5.7.1 SAIP verification failed
If valid: (continue)
C: MAIL FROM:<sender@example.com>
o Non-implementing receivers MUST treat SAIP line as
unrecognized command and continue per [RFC5321].
o Implementing receivers MAY reject with 550 5.7.1 (permanent)
or 421 4.7.1 (temporary) based on local policy.
o A future SMTP extension advertising SAIP capability in EHLO
is RECOMMENDED for strict environments.
o SAIP-verified SMTP agents correspond to Class 3 per [VICDM].
Unverifiable SMTP identity claims correspond to Class 1 and
SHOULD be treated with lower trust than anonymous senders.
14. Security Considerations
14.1. Timestamp Validation
Servers MUST reject requests where |server_time - ts| > 300s.
14.2. Nonce Requirements
Nonce MUST be generated via cryptographically secure RNG per
[RFC4086]. Servers SHOULD track nonces within the validity window.
14.3. Constant-Time Verification
All signature comparisons MUST use constant-time algorithms.
14.4. Key Storage Requirements
Master Keys SHOULD be stored in hardware-backed storage:
TPM 2.0, Apple Secure Enclave, Android StrongBox, or HSM.
Rolling Keys MUST be derived on demand and destroyed after use.
14.5. Compromise Scope Limitation
Per-request RKDF limits stolen key value to one in-flight
request. Vendors MUST revoke affected InstanceIDs via RE.
Revocation MUST propagate to all REs within 300 seconds.
14.6. Header Injection Prevention
Restricting id= to a-z, 0-9, '.', '_', '-' prevents header
injection and parsing ambiguities.
14.7. Downgrade Attack Prevention
Per Section 7.5, renegotiation is strictly forward-only.
14.8. DNS Security
DNS-based key discovery MUST validate DNSSEC [RFC4033] where
available. Implementations MUST NOT rely on unauthenticated
DNS responses for key material in high-security deployments.
DNS cache poisoning could cause a server to accept a spoofed
public key. DNSSEC validation and monitoring of unexpected key
changes SHOULD be used to mitigate this risk.
14.9. False Identity Claims
Under [VICDM], clients asserting identities they cannot verify
(Class 1) SHOULD receive lower trust than anonymous clients
(Class 0). Implementations SHOULD log Class 1 interactions for
audit purposes.
14.10. Remote Attestation
Implementations SHOULD provide Remote Attestation evidence per
[RFC9334] during Full Renegotiation. Attestation status MAY be
committed in tm= (Section 8.3).
15. Privacy Considerations
The id= parameter discloses vendor and instance identity to
servers and network observers. Connections carrying SAIP headers
SHOULD use TLS [RFC8446] or equivalent transport encryption.
DNS-based key discovery (Section 10.2) causes the server to make
a DNS query for the vendor's domain, which may be observable.
Implementations in sensitive deployments SHOULD use stateless
mode (pk=) or RE-based discovery to avoid DNS-observable lookups.
The tm= field MUST NOT be transmitted without explicit opt-in.
SAIP does not provide anonymity. Agents requiring anonymity
SHOULD use anonymous attestation mechanisms instead.
16. IANA Considerations
This document requests IANA to register the following HTTP
header fields in the "Permanent Message Header Field Names"
registry [RFC9110]:
SAIP (defined in Section 5.2)
SAIP-Next-Seq (defined in Section 7.2)
SAIP-Key-Version (defined in Section 7.4)
This document requests IANA to create the following registries:
SAIP RE Bootstrap Registry
Registration policy: Expert Review
Initial contents: To be determined through IETF consensus.
SAIP Telemetry Field Names
Registration policy: Specification Required
Initial contents: asn, geo, attest, fw, gps, api_hash
(Section 8.3)
This document requests IANA to update the following registry
created by [VICDM]:
VICDM DNS Delegation Record Parameters
Add parameter: re (defined in Section 10.2 of this document)
17. References
17.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>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J.
Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith,
N., and W. Pan, "Remote ATtestation procedureS
(RATS) Architecture", RFC 9334,
DOI 10.17487/RFC9334, January 2023,
<https://www.rfc-editor.org/info/rfc9334>.
[RFC5321] Klenke, J., "Simple Mail Transfer Protocol",
RFC 5321, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034,
DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035,
DOI 10.17487/RFC1035, November 1987,
<https://www.rfc-editor.org/info/rfc1035>.
[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,
<https://www.rfc-editor.org/info/rfc4033>.
[VICDM] Jovančević, S., "Verifiable Identity Claims and
Delegation Model (VICDM)",
draft-jovancevic-vicdm-00, April 2026,
<https://datatracker.ietf.org/doc/
draft-jovancevic-vicdm/>.
17.2. Informative References
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny,
"HTTP Message Signatures", RFC 9421,
DOI 10.17487/RFC9421, February 2024,
<https://www.rfc-editor.org/info/rfc9421>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M.
Kucherawy, Ed., "DomainKeys Identified Mail (DKIM)
Signatures", STD 76, RFC 6376,
DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF)",
RFC 7208, DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed., and E. Zwicky, Ed., "DMARC",
RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
Protocol Version 1.3", RFC 8446,
DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization
Framework", RFC 6749, DOI 10.17487/RFC6749,
October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[TPM20] Trusted Computing Group, "TPM Library Specification,
Family 2.0", Trusted Computing Group, 2019,
<https://trustedcomputinggroup.org/>.
[SAIP-01] Jovančević, S., "SAIP: Signed Agent Identity
Protocol", draft-jovancevic-saip-01, April 2026,
<https://datatracker.ietf.org/doc/
draft-jovancevic-saip/>.
Appendix A. IoT Use Case (Informative)
SAIP is particularly well-suited for IoT deployments:
Vendor: Manufacturer (registered at RE or via DNS,
holds Master Key)
Agent Type: Product line (e.g., washing machines)
Instance: Individual device (identity bound to on-device TPM)
DNS-based discovery simplifies IoT deployment significantly:
the manufacturer publishes _saip.manufacturer.com TXT record
once, and all devices are immediately verifiable by any server
without RE registration. The manufacturer's cloud service
verifies device identity cryptographically; compromised devices
are revoked at the instance level without fleet disruption.
Per [VICDM], verified IoT devices are Class 3. Counterfeit
devices without TPM access fall to Class 1 and receive lower
trust than anonymous devices — removing the incentive to
impersonate legitimate products.
Appendix B. Relationship to Existing Standards (Informative)
B.1. RFC 9421 (HTTP Message Signatures)
RFC 9421 signs message content (WHAT). SAIP signs agent identity
(WHO). Complementary, not competing.
B.2. DKIM (RFC 6376)
DKIM signs email messages at domain level. SAIP signs agents at
instance level. The DNS TXT record pattern in Section 10.2 is
directly inspired by DKIM's use of DNS for key publication.
B.3. SPF (RFC 7208)
SPF authorizes IP addresses to send mail for a domain using DNS
TXT records. SAIP's DNS asn= and ip= delegation parameters in
Section 10.2 serve an analogous purpose for agent identity.
B.4. RATS (RFC 9334)
SAIP's hardware attestation requirements (Section 14.10) and
the tm= attestation field (Section 8.3) are compatible with
RATS attestation evidence formats.
Appendix C. VICDM Alignment (Informative)
This appendix maps SAIP verification outcomes to VICDM identity
classes [VICDM].
+=========+========================+=========+==================+
| VICDM | SAIP Condition | Trust | Notes |
| Class | | Level | |
+=========+========================+=========+==================+
| Class 3 | Valid signature via | High | Full SAIP |
| | pk=, DNS, or RE | | verification |
+---------+------------------------+---------+------------------+
| Class 2 | DNS record exists but | Medium | Partial: domain |
| | no valid signature | | identity only |
+---------+------------------------+---------+------------------+
| Class 0 | No SAIP header present | Low | Anonymous; |
| | | | apply default |
| | | | policy |
+---------+------------------------+---------+------------------+
| Class 1 | SAIP header present | Below | False claim; |
| | but unverifiable or | Class 0 | log; apply lower |
| | signature invalid | | trust than anon |
+---------+------------------------+---------+------------------+
The Class 1 row is operationally significant: an agent that
presents an invalid or unverifiable SAIP header MUST receive
lower trust than one that presents no SAIP header at all.
This removes the incentive to make false identity claims.
Appendix D. DNS Record Examples (Informative)
D.1. Minimal deployment (public key only)
_saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA..."
D.2. With preferred RE fallback
_saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA...;
re=re1.saip-registry.example"
D.3. CDN delegation by ASN (no pk, RE-based)
_saip.example.com. 3600 IN TXT "v=saip1; asn=13335,15169;
re=re1.saip-registry.example"
D.4. Full record with expiry
_saip.example.com. 3600 IN TXT "v=saip1; pk=MCowBQYDK2VdAyEA...;
re=re1.saip-registry.example;
asn=13335; exp=1767225600"
D.5. IoT manufacturer (devices have hardware-bound keys)
_saip.gorenje.com. 3600 IN TXT "v=saip1; re=re1.saip-registry.example"
In this case the pk= is not in DNS — each device instance has
its own TPM-bound key registered directly at the RE under the
vendor's registration. DNS provides the RE discovery pointer.
Author's Address
Srećko Jovančević
SKGO, IKT Support
Makedonska 22
11000 Belgrade
Serbia
Email: srecko.jovancevic@skgo.org
Email: srecko.jovancevic@gmail.com
URI: https://github.com/sreckojovancevic