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
|
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.
|
Greptile SummaryThis PR broadens the passkey challenge contract to accept compressed or uncompressed P-256 public keys and updates OAuth verification documentation accordingly.
Confidence Score: 4/5The PR should not merge until the compressed-key changes are moved into the modular OpenAPI source and the generated artifacts are rebuilt. The new validation itself accepts both intended encodings, but it was applied only to a generated artifact, so the repository build regenerates the old contract and detects an out-of-sync bundle. Files Needing Attention: openapi.yaml and the corresponding auth schemas under openapi/components/schemas/auth/
|
| Filename | Overview |
|---|---|
| openapi.yaml | Relaxes the bundled clientPublicKey schema correctly, but the generated file will be reverted by the unchanged modular sources and causes the OpenAPI synchronization check to fail. |
Prompt To Fix All With AI
### Issue 1
openapi.yaml:22857-22858
**Generated schema source remains stale**
When the OpenAPI build or lint workflow regenerates this bundle, the unchanged modular auth schemas restore the old uncompressed-only definition, causing the consistency check to fail and preventing the compressed-key contract from surviving regeneration.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "feat: accept compressed clientPublicKey ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| pattern: ^(04[0-9a-fA-F]{128}|0[23][0-9a-fA-F]{64})$ | ||
| minLength: 66 |
There was a problem hiding this comment.
When the OpenAPI build or lint workflow regenerates this bundle, the unchanged modular auth schemas restore the old uncompressed-only definition, causing the consistency check to fail and preventing the compressed-key contract from surviving regeneration.
Context Used: CLAUDE.md (source)
Knowledge Base Used: OpenAPI Spec Core: Structure, Build, and Shared Schemas
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi.yaml
Line: 22857-22858
Comment:
**Generated schema source remains stale**
When the OpenAPI build or lint workflow regenerates this bundle, the unchanged modular auth schemas restore the old uncompressed-only definition, causing the consistency check to fail and preventing the compressed-key contract from surviving regeneration.
**Context Used:** CLAUDE.md ([source](https://github.com/lightsparkdev/grid-api/blob/main/CLAUDE.md))
**Knowledge Base Used:** [OpenAPI Spec Core: Structure, Build, and Shared Schemas](https://app.greptile.com/lightspark/-/custom-context/knowledge-base/lightsparkdev/grid-api/-/docs/openapi-spec-core.md)
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
…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>
8eca11e to
7744316
Compare
This stack of pull requests is managed by Graphite. Learn more about stacking. |
1 participant
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