Support binding client context to Number Verification and returning an operator-signed token as an trust anchor in a Zero Trust Arch

[yyeAduna]

Problem description
Today, Number Verification can confirm that a verified mobile number is associated with an operator-authenticated transaction. However, for some onboarding, registration, and binding use cases, a verification result alone is not sufficient. There is also a need to cryptographically bind the NV result to client-generated transaction context, such as a binding session identifier, nonce, or hash of an encrypted client payload.

In the absence of such a capability, the API consumer must perform the correlation between the NV result and its own transaction state outside the operator trust domain. This weakens the end-to-end chain of trust, because downstream relying parties must depend on the API consumer’s assertion that the verified number and the client transaction context belong to the same transaction. It limits possible use cases that NV can potentially support.

This matters in flows where relying parties need to verify not only that the operator confirmed the number, but also that the confirmation was performed for a specific client transaction. In such cases, the API consumer may need an operator-verifiable token showing that:

• the number was verified by the operator;
• the verification was performed for a specific client transaction context; and
• the resulting proof can be independently validated later without relying solely on the API consumer’s own correlation logic.

Possible evolution
Consider extending the Number Verification flow, or defining a related profile, so that the client can provide protected transaction context to be bound to the NV result.

One possible approach would be:

• allow the API consumer to supply a protected binding_context or payload_hash as part of the trusted request flow;
• require the operator side to bind that value to the verified number and the current NV transaction;
• return, together with the NV result, an operator-signed JWT token.

This would let the API consumer use Number Verification not only as a boolean check, but also as a stronger trust anchor that can be validated independently.

To minimize change, this could also be specified as an optional profile or extension rather than changing the core semantics for all existing NV deployments.

Alternative solution
An alternative would be to keep Number Verification unchanged and let the API consumer create its own local binding layer on top of the current NV result.
However, that approach has two limitations:

• the linkage between the NV result and the client transaction context remains dependent on the API consumer’s own correlation logic; and
• downstream parties cannot validate that linkage independently unless they trust the API consumer as the root of that proof.

[yyeAduna]

To make the proposal more concrete, below are a few example use cases where an operator-signed binding artifact derived from Number Verification could be useful:

1. Multi-party payment and wallet ecosystems

In some payment ecosystems, a strong binding is required between a wallet instance, device/SIM context, and the verified mobile number so that multiple parties in the ecosystem can rely on the same assurance. An operator-signed artifact derived based on NV could be used to provide independently verifiable proof of that binding to relying parties such as wallet backends, payment networks, and participating banks.

2. Digital identity and wallet-based identity ecosystems

In digital identity use cases, an identity provider or wallet operator could use this capability to obtain an operator-signed binding artifact that links a verified number/session to client-supplied context or identity data from other sources. That artifact could then be presented as one verifiable element in a broader chain of trust, helping relying parties validate that the identity or wallet context was bound to an operator-verified mobile session at a given time.

3. Delegated consent or authorization ecosystems

This example may be more of a stretch: In ecosystems where consent or authorization is collected by one party and later relied on by the same party or by another party, an operator-signed artifact could provide independently verifiable proof that specific client context was bound to a successful NV event at a specific time. For example, the signed input could include a nonce, transaction reference, or hash of the consent text, allowing downstream parties to validate the binding without requiring direct trust in the intermediary that collected the consent.