feat: accept compressed clientPublicKey on passkey challenge + oauth verify - #803
feat: accept compressed clientPublicKey on passkey challenge + oauth verify#803carsonp6 wants to merge 1 commit into
Conversation
…uth verify
The auth-credential challenge (`PASSKEY`) and oauth verify take
`clientPublicKey` as an ephemeral P-256 key. When Grid registers that key
directly as the session signing key (rather than sealing an
`encryptedSessionSigningKey` back to it), the key must be the compressed
SEC1 encoding — that is the form the session key is stored and matched in,
and an uncompressed key is rejected on the first session-stamped call.
Relax the challenge `clientPublicKey` to accept either encoding
(`^(04[0-9a-fA-F]{128}|0[23][0-9a-fA-F]{64})$`, minLength 66) and broaden
both descriptions. The legacy HPKE-target request bodies (export, session
refresh) keep requiring the uncompressed 65-byte point they seal to.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs. ✅ grid-typescript studio · code · diff
✅ grid-openapi studio · code · diff
✅ grid-ruby studio · code · diff
✅ grid-go studio · code · diff
✅ grid-kotlin studio · code · diff
✅ grid-python studio · code · diff
✅ grid-php studio · code · diff
✅ grid-cli studio · code · diff
This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push. |
Why
Knob-ON passkey/oauth login (
STAMP_LOGIN/OAUTH_LOGIN) registers the client-suppliedclientPublicKeydirectly as the session signing key instead of sealing anencryptedSessionSigningKeyback to it. That session key is stored and matched in compressed SEC1 form, so a client that sends the uncompressed key fails the first session-stamped call with401 "Invalid wallet signature."against real infra. (Sandbox accepts both, so it only bit production; OTP login already sends compressed and works.)The
AuthCredentialChallengeRequest.clientPublicKeyschema pinspattern: ^04[0-9a-fA-F]{128}$+minLength/maxLength: 130, so the generated SDKs reject a compressed key outright for the passkey challenge.What
AuthCredentialChallengeRequest.clientPublicKey: accept either encoding —pattern: ^(04[0-9a-fA-F]{128}|0[23][0-9a-fA-F]{64})$,minLength: 66. Description broadened to describe both encodings.OauthCredentialVerifyRequestFields.clientPublicKey: description broadened to note the compressed encoding is accepted (no pattern was set, so this is doc-only).InternalAccountExportRequest,AuthSessionRefreshRequest) are unchanged — they still require the uncompressed 65-byte point they seal credentials to.Backwards-compatible: existing uncompressed clients stay valid.
Downstream
The webdev backend already accepts both encodings server-side (hand-rolled validator). After this merges, the vendored SDK in
lightsparkdev/webdev(grid-api/) needs a regen (./update_schema.sh) so the generated model validators pick up the relaxed constraint. Left theinfo.version(2025-10-13) untouched — bump per the usual release process if required.🤖 Generated with Claude Code