Repository navigation
Support binding client context to Number Verification and returning an operator-signed token as an trust anchor in a Zero Trust Arch #227
Description
Activity
- changed the title
[-]Support binding client context to Number Verification and returning an operator-signed assertion as an identity anchor in a Zero Trust Arch[/-][+]Support binding client context to Number Verification and returning an operator-signed token as an identity anchor in a Zero Trust Arch[/+]on Apr 24, 2026 - changed the title
[-]Support binding client context to Number Verification and returning an operator-signed token as an identity anchor in a Zero Trust Arch[/-][+]Support binding client context to Number Verification and returning an operator-signed token as an trust anchor in a Zero Trust Arch[/+]on Apr 24, 2026 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.
@yyeAduna This sounds a lot similar to what is being specified for example for the eIDAS wallet in Europe. Here you can have issuers that store information in a wallet, and the relying parties can verify with a QTSP that the information shared is valid. The concept of verifiable credentials is certainly not specific to mobile numbers, and I think it would be better to follow the specifications that are being developed. In the GSMA ASACG working group they will start to work on this topic shortly (for the eIDAS wallet).
Please note that to make it really useful, you not only need to be able te verify whether the credential belonged to the user at the date the credential was issued, you also want to verify the credential later on (when it is still valid).
I see a link here with another CAMARA API, Number Recycling.Hi @HuubAppelboom thanks for your comments.
On the eIDAS/EUDI Wallet comparison, I agree there is some similarity at the technical-pattern level, especially around binding a verification or authentication event to a relying-party context. However, the scope of this proposal is much narrower, even if the potential applicability may be broader. The intent is not to turn Number Verification into an identity credential or a transaction-authorization framework. The operator would only provide a context-bound, operator-signed telco assertion, for example by proving that an NV result was produced for a specific client-provided nonce, session identifier, or payload hash. The operator would not certify the underlying transaction, identity attributes, or legal effect. In that sense, this narrow technical building block could potentially serve as a technical supporting layer for wallet, credential, onboarding, or transaction-binding flows, but it would not replace the EUDI Wallet or the eIDAS trust framework.
On the later-validity point, I agree issuance-time proof alone is not enough. This proposal mainly addresses whether the phone number was verified and bound to a relying-party context at the time the credential or binding was created. For later validation, Number Recycling is highly relevant: the issuer or relying party could use the credential issuance date, or the last successful phone-number validation date, as the reference date to check whether the number may have changed subscriber since then. In that sense, context-bound NV and Number Recycling are complementary and working as a pair.
@yyeAduna To me the problem you describe is pretty much the same as what eIDAS2 / verifiable credentials is trying to address in a trust framework, So why is it necessary the define something new ?
@yyeAduna Regarding an operator signed token, usually the effect is that you are also disclosing which telco the phone number belongs to. In a lot of terrritories this considered privacy sensitive information, so this may not be an option (or should be addressed in a different way). Also, want still needs to be considered is that there may have been parties in the middle that may have changed the data or swapped the data between users. You will also need to proof the the whole chain is in tact, and has not been tampered with.
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:
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:
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: