[Feature Request] enhance getPepper function to support offchain Keyless account verification

[yeptos]

🚀 Feature Request Description

We propose modifying the getPepper function (keyless.ts#L33-58) to:

• Accept non-secret components of the epk (public key, expiry in seconds, blind factor) instead of the EphemeralKey instance.
• Return both pepper and address values from the pepper service API response.

Motivation

This improvement supports use cases similar to ERC-4361 Sign-In with Ethereum, allowing off-chain backend services to authorize users by verifying ownership of a Keyless account without handling sensitive private key data.

Pitch

Describe the solution you would like

Modify the signature of getPepper function as something like the following and update the implementation:

// current
async function getPepper(args: {
  aptosConfig: AptosConfig;
  jwt: string;
  ephemeralKeyPair: EphemeralKeyPair;
  uidKey?: string;
  derivationPath?: string;
}): Promise<Uint8Array>

// proposed
async function getPepper(args: {
  aptosConfig: AptosConfig;
  jwt: string;
  ephemeralPublicKey: HexInput;
  expiryInSeconds: number;
  blindFactor: HexInput;
  uidKey?: string;
  derivationPath?: string;
): Promise<{ pepper: string, address: string }> // could be either string or Uint8Array

Key changes

• Replace ephemeralKeyPair with ephemeralPublicKey, expiryInSeconds, and blindFactor.
• Update return type to include both pepper and address.

Considerations

Changing the existing getPepper function would result in a breaking change. Adding a new function with a different signature could avoid this, but likely an overkill. Given that Keyless adoption (excluding Aptos Connect) is still limited, now could be the ideal time to make this change.

Describe alternatives you've considered

One can simply make the API call without using the SDK, but it is not very good for developer experience and consistency.

Are you willing to open a pull request? (See CONTRIBUTING)

Yes. However, at least the function signature should be discussed with the maintainer of the codebase.

Additional context

[alinush]

@yeptos, you are not proposing a change to the way peppers are derived, correct?

Just a change to an SDK's function signature?

Specifically, you are asking: instead of taking an ephemeralKeyPair (which has an ephemeralPublicKey, expiryInSeconds, blindFactor and more) just take in its individual necessary components (i.e., ephemeralPublicKey, expiryInSeconds, blindFactor) in the SDK?

@heliuchuan, we could do this, no? But @yeptos, why not just mock an ephemeralKeyPair that has the desired ephemeralPublicKey, expiryInSeconds and blindFactor fields and use the current SDK API?

FWIW, the pepper service API already works like you want (see here)

[heliuchuan]

@yeptos what do you think of an ability to construct a ephemeralKeyPair without a privatekey and be able to use that instead?

[heliuchuan]

Also how are you passing in the non-sensitive keypair data to off-chain services? Asking to better understand what would be the best solution

[yeptos]

@alinush hi Alin, you're right, this proposal is merely about changing the function in the SDK so it supports what I believe is a common use case for developers.

Just a change to an SDK's function signature?

Specifically, you are asking: instead of taking an ephemeralKeyPair (which has an ephemeralPublicKey, expiryInSeconds, blindFactor and more) just take in its individual necessary components (i.e., ephemeralPublicKey, expiryInSeconds, blindFactor) in the SDK?

Yes.

But @yeptos, why not just mock an ephemeralKeyPair that has the desired ephemeralPublicKey, expiryInSeconds and blindFactor fields and use the current SDK API?

FWIW, the pepper service API already works like you want (see here)

Yes it's already possible and our team is not currently blocked by this. But I just hope the SDK can be made more straightforward so other developers can use the function without needing a workaround.

[yeptos]

@heliuchuan

@yeptos what do you think of an ability to construct a ephemeralKeyPair without a privatekey and be able to use that instead?

sounds good to me!

Also how are you passing in the non-sensitive keypair data to off-chain services? Asking to better understand what would be the best solution

The offchain authentication flow is roughly as following:

1. User (frontend) calls our REST API endpoint for Keyless user authentication, sending the non-secret components along with the user's account address.
2. The backend calls the pepper service and check if the returned account matches (we could just use the address returned from pepper, so this might be more of a sanity check), and also check if the epk or jwt is not expired.
3. If all checks pass, we generate our own auth token for the account and use cookie or authorization header for subsequent requests to our privileged API endpoints. This way we don't have to call the pepper service every time user calls our APIs.