Aligning on the webauthn-wallet secp256r1 auth-entry wire-shape

[justmert]

Hi Tyler. I built SoroPass, a minimal passkey SDK and drop-in create / sign / recover UI for Stellar smart accounts. The secp256r1 work (low-S normalization, the WebAuthn ceremony and payload, the Secp256r1Signature struct) is ported and hardened from passkey-kit, so thank you for the reference. I have one question about staying compatible with smart-wallet auth entries.

What I built. A small SDK (@soropass/core) that turns a Soroban auth preimage into a WebAuthn challenge, runs the assertion, low-S normalizes the secp256r1 signature, and assembles a SorobanAuthorizationEntry. It is implemented as its own minimal slice and stays ABI-compatible with the audited contract layer rather than reinventing it. It is proven on testnet against my own single-signer account (__check_auth / secp256r1_verify).

Proven on testnet. A passkey-signed auth entry passes a real __check_auth, and a wrong key is rejected on-chain:

• Passkey Payment: https://stellar.expert/explorer/testnet/tx/58cd5d6307acc61d830bdb8b3a7299761bcf6435ddf0065f652e635457f5cc60
• Wrong Key Rejected: https://stellar.expert/explorer/testnet/tx/2a89cc6f38b2af4c59fbea37ac77e426a0092060a6be2842ec2cb6b0b9645a61

Try it. You can see and test a live demo on the site below. The create, sign, and recover flows run with the SoroPass pre-built components on testnet, so you can run them yourself.

Live Demo: https://soropass.dev/
Docs: https://docs.soropass.dev/docs
Repo: https://github.com/justmert/soropass

Question. My SDK assembles the bare Secp256r1Signature struct, which my own single-signer account consumes directly. To authorize a smart-wallet, from types.rs I read that I should wrap it as Signatures(Map<SignerKey::Secp256r1(credential_id), Signature::Secp256r1(...)>). Is the Secp256r1 SignerKey the raw WebAuthn credential-id bytes, and is building that map the path you would recommend for an external SDK, or is there a helper you would point me to?

Happy to share more or test against your wallet. Thanks again for passkey-kit, a lot of this is built on it.

[kalepail]

Thanks for the detailed write-up, and for publishing the testnet proofs. I looked through the current passkey-kit smart-wallet ABI and the SoroPass shape. Your reading is correct for this repo's legacy smart-wallet contract.

For passkey-kit / webauthn-wallet, SignerKey::Secp256r1(Bytes) is the raw WebAuthn credential ID bytes.

The relevant path is:

Signer::Secp256r1(id, public_key, expiration, limits, storage)

which is reduced by process_signer to:

SignerKey::Secp256r1(id) -> SignerVal::Secp256r1(public_key, expiration, limits)

So if your app stores the WebAuthn credential as the usual base64url credential.id, decode that to bytes for the SignerKey. If you already have rawId bytes, use those bytes directly. Do not hash it, UTF-8 encode the base64url string, or include the public key in the SignerKey; the public key lives in SignerVal.

To authorize this wallet, the auth-entry signature should be the wallet's wrapper type, not the bare Secp256r1Signature:

Signatures(Map<SignerKey, Signature>)

For a passkey signature that means:

SignerKey::Secp256r1(raw_credential_id_bytes)
  => Signature::Secp256r1(Secp256r1Signature {
       authenticator_data,
       client_data_json,
       signature, // compact 64-byte r || s
     })

That is exactly what PasskeyKit.signAuthEntry assembles: it uses authenticationResponse.id as the map key, base64url-decodes it, builds Signature::Secp256r1({ authenticator_data, client_data_json, signature }), and inserts it into the auth-entry address credential signature as a one-field tuple struct (ScVal::Vec([ScVal::Map(...)])).

So yes: if SoroPass wants to target this contract ABI from an external SDK, building that Signatures map is the right path. The bare Secp256r1Signature shape is valid for your own single-signer account because that account declares:

type Signature = Secp256r1Signature;

but it will not satisfy this smart-wallet contract, which declares:

type Signature = Signatures;

The two useful implementation cautions:

1. Preserve/merge any existing signature map entries if the auth entry is already partially signed.
2. Sort the map entries canonically after insertion. The current SDK sorts the map after pushing a new entry.

There is not a lower-level public helper I would point you to in passkey-kit beyond using PasskeyKit.signAuthEntry itself. For an external SDK, I would either use the generated contract spec to encode SignerKey and Signature, or mirror the small assembly block in src/kit.ts that converts those native values into ScVal entries.

One compatibility note: passkey-kit is now the legacy precursor to smart-account-kit, which is built around the OpenZeppelin-based smart-account contracts in OpenZeppelin/stellar-contracts. The newer smart-account ABI is intentionally different: passkeys are modeled as an external signer, roughly Signer::External(verifier, key_data), where key_data is 65-byte secp256r1 public key || raw credential ID, and the auth payload carries context rule IDs plus a signer-signature map. So the SignerKey::Secp256r1(credential_id) wrapper above is the correct answer for this repo's smart-wallet ABI, but not the wire shape I would recommend for new integrations targeting smart-account-kit.

Your existing low-S normalization and WebAuthn field packing are the right pieces to reuse; the only missing layer for passkey-kit compatibility is wrapping them in the Signatures(Map<SignerKey, Signature>) contract type with the raw credential ID bytes as the map key.

[justmert]

Thanks Tyler, this is what I needed. Good to have confirmation that SignerKey::Secp256r1 is the raw credential-id bytes and that the public key stays in SignerVal. That was the part I wasn't certain about.

On my end I'll add a wallet-target layer that wraps the existing low-S normalization and WebAuthn packing into the Signatures(Map<SignerKey, Signature>) type: decode authenticationResponse.id to raw bytes for the key, merge into any existing map entries, then sort canonically, following the src/kit.ts assembly. My own single-signer account keeps the bare Secp256r1Signature since that's what its type Signature declares.

Noted on smart-account-kit/OZ being the forward path. I'd rather treat the two as separate ABI targets behind one assembly interface, since the core primitives (low-S, field packing, challenge binding) are identical and only the outer wrapper differs per contract. That keeps the SDK minimal instead of hardcoding one wallet's shape.

Thanks again for walking through flow in depth and will keep you up-to-date after that's done!