Skip to main content
did:key derivation and verification for Glide agents. Extracts the verified P-256 EC public key from an Apple App Attest credCert (or Android Key Attestation certificate) and encodes it as the W3C did:key form that downstream agent-payments protocols — AP2, ACP, x402 — expect. Every function in this package is pure. No network calls, no Node-specific side effects beyond node:crypto for PEM parsing (Node 18+, Bun, Deno).

Install

npmjs.com/package/@glideco/agent-identity

Why hardware-bound keys?

Glide signs every grant with a per-grant did:key so external verifiers can resolve the agent’s public key without making a Glide API call. The key material is bound to a hardware-attested credential — the did:key is cryptographically derived from Apple App Attest’s P-256 key, not client-asserted. The alternative — deriving the did:key from the device_attestations.ed25519_pub column — is explicitly rejected. That column carries no hardware binding. The P-256 key extracted by the App Attest verifier is bound by Apple’s PKI to the device’s Secure Enclave; Android Key Attestation provides the same guarantee via StrongBox. The did:key emitted here inherits both assurances.

Wire format

did:key for a P-256 key is did:key:z<base58btc(multicodec || 33-byte-compressed-pubkey)>. SEC1 compressed format: byte 0x02 when Y is even, 0x03 when Y is odd, followed by the 32-byte big-endian X coordinate.

API surface

Worked examples

From an App Attest credCert (most common path)
Round-trip: encode then decode
Guard clause in a Zod refinement

Error handling

All functions throw Error with a message that identifies the failure point: pemToCompressedP256 throws on non-P-256 curves or malformed PEM; compressedP256ToDidKey throws on wrong-length or invalid SEC1 prefix; parseDidKeyP256 throws on wrong multicodec or bad base58btc. isValidDidKey swallows these and returns false — use it at API boundaries where you want a boolean gate rather than exception propagation.

Reading list