Ships — the server provides exact-key Git signer membership resolution. Your client supplies Git signature verification and the user interface.
The useful result is precise: “This commit's signature is valid, its signing key has current persona membership, and a verified path meets your policy.” Begin with early access, an allowlisted app origin and a usable graph device on staging.
1. Verify the commit locally
Read the actual signed Git object and verify its signature. Extract the verified signing public key; an author name, email address or hosting provider badge is not a substitute.
For a TrustGraph graph-device signing key, continue below. For an OpenPGP signer, use external signing keys to resolve the verified fingerprint instead.
2. Resolve the exact graph key
Send POST /v1/graph-keys/resolve-signer with graphNodeId, targetGraphKeyId and authorization. Sign the exact two-field query under operation resolve-git-signer, using your own usable ordinary graph device and a fresh nonce.
This route uses the existing device certificate and status formats. Verify both issuer signatures, the pinned issuer origin, times and nonce. Match the returned key identifier and public JWK to the public key that verified the commit. No commit bytes, digest or repository name need to enter this lookup.
3. Verify the current trust path
Query from your own node to the returned persona with your chosen policy. Use the local proof verification flow before displaying a positive connection result. Keep the commit signature, current membership and current path results separate.
Handle unavailable evidence
Unknown and inactive target keys return the same 404. Report membership as unavailable; this is neither a signed proof of absence nor a historical revocation record. Typed SDK wrappers for signer resolution are not available yet; use the graph-key reference for the HTTP contract.