feat: register SINT Protocol as trusted issuer

[pshkv]

Summary

Registering SINT Protocol (sint-protocol) as an issuer in the Open Agent Trust Registry.

What is SINT Protocol?

SINT is a runtime authorization framework for physical AI agents. It sits between AI agents and the physical world (robots, industrial systems, drones), ensuring every action is authorized, capability-constrained, and audited.

Key properties:

• Identity: Ed25519 keypairs + did:key:z6Mk... (W3C DID spec compliant)
• Capability tokens: Scoped, signed, delegatable — attenuation-only (permissions can only narrow)
• Approval tiers: T0 (observe) → T1 (prepare) → T2 (act, requires review) → T3 (commit, requires human sign-off)
• Audit: SHA-256 hash-chained EvidenceLedger — append-only, tamper-evident
• Supervision model: Tiered (T0–T3) with circuit breaker, goal hijack detection (ASI01), memory integrity (ASI06), supply chain verification (ASI04)

APS↔SINT Interop

APS and SINT arrived at the same cryptographic primitives independently. Joint interop spec: https://github.com/aeoess/aps-sint-interop — 9/9 cross-verification tests pass with zero adapter code.

Registration details

Field	Value
issuer_id	sint-protocol
kid	sint-registry-2026-04
algorithm	Ed25519
supervision_model	tiered
immutable_audit	true
attestation_format	sint-token-v1
Source	https://github.com/pshkv/sint-protocol

Verification

• Issuer JSON follows registry schema
• Proof file: signature over oatr-proof-v1:sint-protocol with registered key
• Domain verification at /.well-known/agent-trust.json — endpoint exists in gateway-server discovery routes (deployed when gateway is hosted)

🤖 Generated with Claude Code

[github-actions]

🔐 Registration Verification Results

❌ sint-protocol

Check	Status
Schema validation	✅ Pass
Proof-of-key-ownership	✅ Pass
Domain verification	❌ Fail

Errors:

• Domain verification failed: could not fetch agent.json or agent-trust.json from https://github.com/pshkv/sint-protocol — HTTP 404 Not Found

---

📖 See spec 11 — Proof of Key Ownership for the proof format.

🛠️ Generate a proof with:

npx @open-agent-trust/cli prove --issuer-id <YOUR_ID> --private-key <PATH>

[aeoess]

@pshkv — the CI failure on this PR is just a domain-verification path issue, not a substance problem. The registry verifier looks for /.well-known/agent-trust.json at a domain root over HTTPS, not at a GitHub repo URL.

The fix is to host the verification file at a domain you control rather than the GitHub repo. Two options:

1. Use sint-ai.co (or whatever domain SINT serves from): host https://sint-ai.co/.well-known/agent-trust.json with the contents:

   { "issuer_id": "sint-protocol", "public_key_fingerprint": "<the KID you used during registration>" }

   Then re-run the PR's workflow and it should auto-verify + auto-merge.

2. GitHub Pages workaround: if you don't have a domain yet, enable GitHub Pages on the pshkv/sint-protocol repo with a custom domain, then host the file there. Slower but free.

The proof-of-key-ownership check already passed (your signature is valid), and the schema check passed. Only the domain-verification step is left. Once that's green, the CI auto-merges without human approval.

Happy to help debug if the file placement doesn't resolve it on first try. APS registered through the same flow a few weeks back (registry/issuers/agent-passport-system.json), so the pattern works — it's just a bootstrap step.

[pshkv]

Confirmed: only blocker is domain verification (the verifier fetches /.well-known/agent-trust.json at a domain root, not a GitHub repo URL).

I’m going to host /.well-known/agent-trust.json on docs.sint.gg (current public docs domain) with the minimum contents required by the registry verifier. Once that’s live, I’ll re-run the verify workflow.

Proposed file (exact shape I’ll serve):

{
  "issuer_id": "sint-protocol",
  "public_key_fingerprint": "sint-registry-2026-04"
}

If the verifier expects a different field name for the fingerprint/kid (some registries use kid), tell me and I’ll match it exactly.

[github-actions]

🔐 Registration Verification Results

❌ sint-protocol

Check	Status
Schema validation	✅ Pass
Proof-of-key-ownership	✅ Pass
Domain verification	❌ Fail

Errors:

• Domain verification failed: could not fetch agent.json or agent-trust.json from https://sint.gg — HTTP 404 Not Found

---

📖 See spec 11 — Proof of Key Ownership for the proof format.

🛠️ Generate a proof with:

npx @open-agent-trust/cli prove --issuer-id <YOUR_ID> --private-key <PATH>

[aeoess]

@pshkv — two things needed to close this out. The bot is still hitting https://sint.gg/.well-known/agent-trust.json because that's what the PR's registration JSON declares in the website field ("website": "https://sint.gg"). Hosting on docs.sint.gg won't help unless the PR is updated to match.

Two paths — pick either:

Path A: Host on sint.gg root (keep the PR as-is).
Serve https://sint.gg/.well-known/agent-trust.json with:

{
  "issuer_id": "sint-protocol",
  "public_key_fingerprint": "BQBoYRC6sSrtgRwYdmX8vPxiJIiM3OlO7IZMK-OPGdI"
}

Path B: Host on docs.sint.gg (update the PR).
Change "website": "https://sint.gg" to "website": "https://docs.sint.gg" in registry/issuers/sint-protocol.json, then serve the same file at https://docs.sint.gg/.well-known/agent-trust.json.

Important correction on the fingerprint value. Your earlier proposed JSON had "public_key_fingerprint": "sint-registry-2026-04" — that's the kid string, not the fingerprint. The spec wants the SHA-256 hash of the raw Ed25519 public key, base64url-encoded (no padding).

I computed it from the public key in your PR (Yq-yYyx7sLaMHE_jmTkgYPQoSJVJMDRfdAcInJxnV0E → 32 raw bytes → SHA-256 → base64url): BQBoYRC6sSrtgRwYdmX8vPxiJIiM3OlO7IZMK-OPGdI. You can verify independently:

echo -n "Yq-yYyx7sLaMHE_jmTkgYPQoSJVJMDRfdAcInJxnV0E" | \
  base64 -d --ignore-garbage 2>/dev/null | \
  openssl dgst -sha256 -binary | \
  base64 | tr '+/' '-_' | tr -d '='

(For reference: APS's working entry at https://aeoess.com/.well-known/agent-trust.json carries a 43-char base64url fingerprint in the same format. That's the oracle for what the verifier expects.)

Once the file is live with that fingerprint value at whichever domain you picked, re-run the verify workflow. Should go green in one iteration.