Skip to content

feat: accept compressed clientPublicKey on passkey challenge + oauth verify - #803

Draft
carsonp6 wants to merge 1 commit into
mainfrom
passkey-clientpublickey-accept-compressed
Draft

feat: accept compressed clientPublicKey on passkey challenge + oauth verify#803
carsonp6 wants to merge 1 commit into
mainfrom
passkey-clientpublickey-accept-compressed

Conversation

@carsonp6

@carsonp6 carsonp6 commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Why

Knob-ON passkey/oauth login (STAMP_LOGIN / OAUTH_LOGIN) registers the client-supplied clientPublicKey directly as the session signing key instead of sealing an encryptedSessionSigningKey back 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 with 401 "Invalid wallet signature." against real infra. (Sandbox accepts both, so it only bit production; OTP login already sends compressed and works.)

The AuthCredentialChallengeRequest.clientPublicKey schema pins pattern: ^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).
  • The legacy HPKE-target bodies (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 the info.version (2025-10-13) untouched — bump per the usual release process if required.

🤖 Generated with Claude Code

…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>
@vercel

vercel Bot commented Aug 5, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
grid-flow-builder Ignored Ignored Aug 5, 2026 10:13pm
grid-wallet-demo Ignored Ignored Aug 5, 2026 10:13pm

Request Review

@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

docs(api): update client-public-key parameter description in auth credential challenge

go

docs(api): update clientPublicKey documentation in auth credential challenge

kotlin

docs(api): update clientPublicKey description in auth credentials

openapi

fix(types): support compressed P-256 keys in clientPublicKey fields

php

docs(api): update clientPublicKey parameter description in auth credentials

python

docs(api): update client_public_key parameter description in credentials challenge

ruby

docs(api): update client_public_key parameter description in auth credentials

typescript

docs(api): update clientPublicKey parameter description in auth credentials challenge

Edit this comment to update them. They will appear in their respective SDK's changelogs.

grid-typescript studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ❗test ✅

npm install https://pkg.stainless.com/s/grid-typescript/73760e93558e30027123ac7d69d4b63597b349a1/dist.tar.gz
grid-openapi studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️

grid-ruby studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ✅test ✅

grid-go studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ❗test ❗

go get github.com/stainless-sdks/grid-go@708b5d8372d7a037d09a0b79be218bbe59289611
grid-kotlin studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ✅lint ✅test ❗

grid-python studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ❗test ❗

pip install https://pkg.stainless.com/s/grid-python/6d75c3c09e428a4801f72d7b53f6b62d51585790/grid-0.0.1-py3-none-any.whl
grid-php studio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅lint ✅test ✅

grid-cli studio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ❗lint ❗test ❗


This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-08-05 22:18:58 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant