Proposal: Make nonce verification in the verify method more flexible

[SakujiroInagaki]

Hello,

I would like to suggest a small change to make the nonce verification in the Key Binding JWT more flexible.

Current Behavior

Currently, the verify method requires a nonce string in the options to perform an equality check. It seems that if the nonce is not provided, the entire Key Binding JWT verification may be skipped.

sd-jwt-js/packages/core/src/index.ts

Lines 223 to 225 in b8733bc

	if (!options?.keyBindingNonce) {
	return { payload, header };
	}

sd-jwt-js/packages/core/src/index.ts

Lines 550 to 552 in b8733bc

	if (!options?.keyBindingNonce) {
	return { payload, headers };
	}

Use Case for Change

The current approach works well for a simple challenge-response flow. However, some other scenarios require more flexibility.

For example, a verifier might want to validate the Key Binding JWT's signature first, but handle the nonce check separately in cases like these:

Presenter-Generated Nonce: The presenter generates a nonce, and the verifier needs to check it against a database of previously used nonces to prevent replay attacks.

Verifier-Generated Nonce with DB State: The verifier generates a nonce and stores its status (e.g., status: 'issued') in a database. When the response is received, the verifier must look up the incoming nonce to validate its status and then mark it as used.

In both scenarios, the verifier needs to inspect the nonce value from the JWT before running its own validation logic. The current API makes this difficult, as it requires providing the expected value upfront.

Proposal

I propose making the nonce parameter in the options object truly optional with the following logic:

If a nonce string is provided: The behavior remains the same (perform a strict equality check).

If nonce is NOT provided: The method should only skip the nonce check but still perform all other Key Binding JWT validations (e.g., signature verification).

Thank you.

[lukasjhan]

Thank you so much for sharing your thoughts! @SakujiroInagaki

We’re currently preparing version 1.0 internally, and we’ll be taking your feedback into full consideration. Once we’ve set a clearer direction, I’ll share it with you again.

[SakujiroInagaki]

Thank you for your consideration. @lukasjhan
That's great news! I look forward to it.

[cre8]

Hi @SakujiroInagaki
While I understand the flexibility, I see a potential security leak:
When the issuer is generating the nonces for comparison, the approach is an allow list. For efficient garbage collection, it can store an expired date to remove the entry from the database (because it is not fresh anymore). Plus deleting nonces that are used.

For the holder generated one it is a deny list approach. If the issuer is deleting the nonces, a replay attack is possible. But if they are not deleted, the database to manage them will grow infinitely. Because of this, I would prefer not to allow it because of the risk of bad nonce management.

Transport protocols like oid4vp demand that the nonce is generated by the verifier to guarantee freshness.

[SakujiroInagaki]

Hello, @cre8

Thank you for the thoughtful discussion. I'd like to clarify my suggestion from two perspectives: 1) my immediate need, and 2) the library's general flexibility.

1. My Immediate Need (Flexible Allow List)
   To be clear, my personal use case only requires more flexibility within the secure "allow list" model. I have no plans to implement a "deny list". As mentioned, I need to verify the signature first to get the nonce, and then perform a check against my own database (e.g., updating a status field or delete a record).

2. The Library's General Flexibility (Supporting Other Patterns)
   Separately from my own needs, I believe it's valuable for a library to be versatile.
   Regarding the Holder-generated nonce (the "deny list" approach), I agree it can be less robust if not managed carefully. However, I believe the risk can be mitigated. By combining the nonce with the JWT's iat (issued at) claim, a verifier can enforce a policy to only accept nonces issued within a short timeframe (e.g., a few minutes). This approach prevents replay attacks while also allowing the verifier to safely purge expired nonces from the deny list, thus preventing its infinite growth.

My original proposal to make the nonce check optional was just one idea, and I am completely open to a better or safer interface that provides the flexibility I need.

Thank you!

[cre8]

Hi @SakujiroInagaki ,

for a "quick" fix you could just pass a static nonce value to force the kbVerify function. The nonce comparison is performed in the kbVerify function that you can override with your own logic (in your case to fetch the nonce that may be a jwt, a signed object or so).

In one way we need to signal that the verifier is requiring a kbinding. We could also say when there is no kbverifier, we assume that the verifier does not want to verify the kb. But this could also be the result of a bad implementation (verifier thinks that kb will be verified, because the instance could be initialized without a problem, but none kbverifier was passed).