You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When agents collaborate via A2A (Agent-to-Agent), tool schemas cross trust boundaries. SchemaPin v1.4.0 ensures that tool integrity verification extends seamlessly into A2A networks — every tool invoked through an A2A bridge is verified against its provider's signed schema.
97
+
All v1.4 additions are optional fields — fully backward compatible with v1.3 clients.
98
+
99
+
### Signature Expiration / TTL
100
+
101
+
Right now, a signature is valid forever once created. There's a `signed_at` timestamp but no `expires_at`. A signature from 2 years ago on an abandoned tool is just as "valid" as one from yesterday — there's no forcing function for developers to re-sign after security reviews, and clients can't distinguish "actively maintained" from "signed once and forgotten."
102
+
103
+
| Item | Details |
104
+
|------|---------|
105
+
|`expires_at` field | Optional ISO 8601 timestamp in both schema signatures and `.schemapin.sig`|
106
+
| Degraded vs. failed | Expired signatures are treated as degraded (lower confidence), not hard failures — avoids breaking tools when a dev misses a renewal |
107
+
| Confidence scoring | Pairs with a confidence model: recently signed > old but valid > expired > unsigned |
108
+
109
+
**Format addition to `.schemapin.sig`:**
110
+
111
+
```json
112
+
{
113
+
"signed_at": "2026-02-14T12:00:00Z",
114
+
"expires_at": "2026-08-14T12:00:00Z"
115
+
}
116
+
```
117
+
118
+
### Schema Version Binding
119
+
120
+
SchemaPin signs a schema at a point in time, but there's no concept of "this is version 3.2 of this tool's schema, superseding version 3.1." If a developer legitimately updates their tool, clients with the old schema pinned have no way to know whether the new schema is an authorized upgrade or a rug pull.
121
+
122
+
| Item | Details |
123
+
|------|---------|
124
+
|`schema_version` field | Optional version string in signature metadata |
125
+
|`previous_hash` field | SHA-256 hash of the prior signed version, creating a hash chain |
126
+
| Lineage verification | Clients verify that a schema update is part of an authorized chain rather than an out-of-band substitution |
127
+
128
+
No new crypto required — just metadata. The hash chain is lightweight and elegant.
129
+
130
+
### DNS TXT Cross-Verification
131
+
132
+
AgentPin already uses `_agentpin.{domain}` TXT records, but SchemaPin doesn't leverage DNS yet. Adding a `_schemapin.{domain}` TXT record containing the key fingerprint gives multi-channel verification without requiring a GitHub repo. DNS is controlled through a completely different credential chain than HTTPS hosting, so compromising one doesn't compromise the other.
133
+
134
+
| Item | Details |
135
+
|------|---------|
136
+
|`_schemapin.{domain}` TXT record | Contains key fingerprint (JWK thumbprint) |
137
+
| Cross-check | Clients verify that the key from `.well-known` matches what DNS says |
138
+
| Optional | Enhances confidence when present, does not block verification when absent |
139
+
140
+
**Example TXT record:**
141
+
142
+
```
143
+
_schemapin.example.com. IN TXT "v=schemapin1; kid=acme-2026-01; fp=sha256:a1b2c3d4..."
144
+
```
145
+
146
+
### Canonicalization Algorithm Identifier
147
+
148
+
The current spec hardcodes the canonicalization algorithm (sorted keys, no whitespace, UTF-8). If the algorithm ever needs to change (and JSON canonicalization is notoriously tricky across languages), there's no way to signal which algorithm was used.
149
+
150
+
| Item | Details |
151
+
|------|---------|
152
+
|`canonicalization` field | Algorithm identifier in signature metadata, e.g. `"schemapin-v1"`|
153
+
| Forward compatibility | New algorithms can be introduced without breaking existing signatures |
154
+
155
+
Trivial to add now, saves a painful migration later.
98
156
99
157
### A2A Context for Schema Verification
100
158
159
+
When agents collaborate via A2A (Agent-to-Agent), tool schemas cross trust boundaries. SchemaPin v1.4.0 ensures that tool integrity verification extends seamlessly into A2A networks — every tool invoked through an A2A bridge is verified against its provider's signed schema.
160
+
101
161
| Item | Details |
102
162
|------|---------|
103
163
|`A2aVerificationContext`| New type wrapping `VerificationResult` with A2A caller identity, delegation depth, originating domain |
104
164
|`verify_schema_for_a2a()`| Extends `verify_schema_offline()` with A2A context validation |
The `.well-known/schemapin.json` should support an array of public keys with roles rather than a single `public_key_pem`. This is the enterprise compliance differentiator — organizations can enforce policies like "require both a developer and a reviewer signature."
196
+
197
+
**Discovery document format:**
198
+
199
+
```json
200
+
{
201
+
"schema_version": "1.5",
202
+
"developer_name": "Acme Corp",
203
+
"public_keys": [
204
+
{
205
+
"kid": "acme-dev-2026-01",
206
+
"public_key_pem": "...",
207
+
"role": "developer",
208
+
"name": "Alice (Engineering)"
209
+
},
210
+
{
211
+
"kid": "acme-security-2026-01",
212
+
"public_key_pem": "...",
213
+
"role": "reviewer",
214
+
"name": "Security Team"
215
+
}
216
+
]
217
+
}
218
+
```
219
+
220
+
| Item | Details |
221
+
|------|---------|
222
+
|`public_keys` array | Replaces single `public_key_pem` (single-key remains valid as shorthand) |
|`signatures` array in `.schemapin.sig`| Replaces single `signature` field for countersigning |
225
+
| Policy enforcement | Clients can require signatures from specific roles |
226
+
227
+
Sequential countersigning approach — minimal protocol disruption, maximum enterprise value.
228
+
229
+
### Scope / Permission Declarations
230
+
231
+
SchemaPin verifies that a schema hasn't been *tampered with*, but says nothing about what the schema *claims to do*. A signed schema that says "I need filesystem access, network access, and the ability to execute arbitrary commands" is cryptographically valid but potentially terrifying.
232
+
233
+
| Item | Details |
234
+
|------|---------|
235
+
|`declared_permissions` field | Optional array in signature metadata enumerating claimed capabilities |
236
+
| Attestation record | Auditable record of what the developer attested their tool requires at signing time |
237
+
| Tamper detection | If the schema later changes to request more permissions without a new signature, verification fails |
238
+
| Policy bridge | Doesn't enforce at SchemaPin layer (that's Symbiont's job), but feeds into policy enforcement |
239
+
240
+
This bridges SchemaPin into the Symbiont policy enforcement story naturally.
241
+
242
+
### Source Repository Verification
243
+
244
+
Cross-reference signed schemas against their source repository to boost verification confidence.
245
+
246
+
| Item | Details |
247
+
|------|---------|
248
+
|`source_repo` field | Optional repository URL in signature metadata |
249
+
| Commit binding | Optional `source_commit` hash linking signature to a specific commit |
250
+
| Confidence boost | Verification that the signed artifact matches what's in the public repo |
251
+
252
+
### Advanced Revocation & Key Lifecycle
143
253
144
254
| Item | Details |
145
255
|------|---------|
@@ -154,21 +264,38 @@ All four language implementations (Rust, JavaScript, Python, Go) receive matchin
154
264
155
265
| Feature | Description |
156
266
|---------|-------------|
267
+
| Verification Telemetry | Optional `reporting_endpoint` in `.well-known/schemapin.json` for anonymized verification reports (tool_id, success/failure, error_code, timestamp). Opt-in on both sides. Feeds into transparency log. |
157
268
| Hardware-Backed Signing | HSM and TPM support for schema signing keys |
158
-
| Schema Evolution Tracking | Track schema changes over time with backward compatibility checks |
| Transparency Log | Append-only log of all schema signatures for auditability |
161
271
162
272
---
163
273
274
+
## Priority Stack
275
+
276
+
Sequenced for maximum impact with minimum effort. All items are backward compatible — every one is an optional field addition. Existing v1.3 clients ignore what they don't understand.
277
+
278
+
| Priority | Feature | Target | Effort | Impact |
279
+
|----------|---------|--------|--------|--------|
280
+
| 1 | Signature expiration | v1.4 | Small | Closes the "stale signature" gap every enterprise buyer will ask about |
281
+
| 2 | Multi-key endorsement | v1.5 | Medium | The enterprise compliance differentiator |
282
+
| 3 | DNS TXT cross-verification | v1.4 | Small | Strongest anti-compromise signal for lowest cost |
283
+
| 4 | Schema version binding | v1.4 | Small | Hash chain prevents upgrade-path attacks |
284
+
| 5 | Source repo verification | v1.5 | Medium | Strong confidence boost via cross-referencing |
285
+
| 6 | Declared permissions | v1.5 | Small | Bridges into Symbiont policy story |
0 commit comments