Feature p256

[dangell7]

High Level Overview of Change

Context of Change

API Impact

• Public API: New feature (new methods and/or new fields)
• Public API: Breaking change (in general, breaking changes should only impact the next api_version)
• libxrpl change (any change that may affect libxrpl or dependents of libxrpl)
• Peer protocol change (must be backward compatible or bump the peer protocol version)

[dangell7]

Love the direction here — the p256 plumbing (new KeyType::p256, 65-byte PublicKey buffer, sfPasskey / sfPasskeySignature inner objects, base64url_decode + sha256 helpers) is exactly the scaffolding session keys would also need, and I think it's worth considering a small generalization now so we don't end up maintaining two near-identical ledger objects later.

Why this matters for session keys. A session key can't meaningfully be issued server-side — checkSign runs inside the transactor during consensus, so anything a server "issues" on its own is just delegated custody of the master key, not a cryptographically enforced session. It has to be protocol-side to be real. Today the closest thing is Permission Delegation + a disposable account acting as the session key, but that costs reserve, has no native expiry, and scopes only by txn type.

The clean version, as a protocol feature, would mirror this PR exactly: a per-account ledger object listing {PublicKey, KeyType, NotAfter, AllowedTxTypes, optional SpendingLimit} entries, a set/rotate/revoke transaction, and an extension to checkSign that accepts any unexpired, in-scope entry. Raw ECDSA over the tx hash — no WebAuthn authenticatorData / clientDataJSON wrapping needed, so cheaper to verify and smaller on the wire than the passkey path.

Concrete suggestion for this PR. Rather than ship PasskeyList with a fixed {PasskeyID, PublicKey} shape and add a parallel SessionKeyList later, consider adding two optional fields to sfPasskey now:

• sfExpiration (UINT32, optional) — NotAfter timestamp, absent = no expiry
• sfAllowedTxTypes or a flags field (optional) — scope restriction, absent = unrestricted

With those, a "passkey" is just a session key with no expiry and no scope, and both use cases share one ledger object, one set-transaction, and one checkSign code path. The WebAuthn-specific verification (hashing authenticatorData || SHA256(clientDataJSON)) can stay gated on whether sfAuthenticatorData is present in the signature envelope, so raw-ECDSA session-key signatures just skip that branch.

Happy to open a follow-up issue tracking the session-key extension specifically if that's easier than expanding scope here — but locking the inner object layout before the amendment ships is the main thing, since adding fields to sfPasskey post-amendment is painful.