End-to-End Payload Encryption for PII in CAMARA APIs

[drifterxy]

Problem description
In a KYC-match flow involving Developer→ Aggregator → MNO, is there a recommended way to protect sensitive payload parameters (e.g., ID, name, address) so that the aggregator or other intermediaries cannot view them in clear text? Has there been any discussion on introducing a standard & compliant mechanism for payload encryption in the CAMARA spec?

Possible evolution
Can existing OIDC flows be extended to support end-to-end payload encryption while maintaining routing functionality?

[AxelNennker]

The question is how to provide the public key of the operator to the API consumer.

Second problem is that that public key usually reveals information to the API consumer who the operator is, and the user might not have consented to that information being revealed.

Still the aggregator is in the middle of when the public key is provided to the API consumer, and technically it is easy for the aggregator to lie about the public key e.g. use its own public key.

Focussing on the "clear text" part of the question, hashing would also remove clear text, but hashing introduces other problems, because the API provider now has to rely on a perfect match. Different was of writing user data lead to the hash to be a mismatch, while a clear text request might match e.g. "William Henry Gates III" to "William H. Gates".
The Levenshtein distance between the two is 4 which might indicate a match, while hashes usually differ a lot.

If you have a solution for all CAMARA APIs, then please present it here.
If you have a solution for KYC-match, then please discuss it there.

[drifterxy]

Thank you for the response! Let me share the idea for standardizing aggregator platform PII protection.

The Core Idea: Selective Field-Level Encryption

Instead of encrypting entire payloads, thinking of selective encryption approach where:

• Routing fields (like phoneNumber) remain plaintext for aggregator routing
• Sensitive PII (ID, name, address, email) gets encrypted end-to-end
• Aggregators see only encrypted blobs + routing data

How It Works

1. Enhanced OIDC Flow: Extend token responses with supplier encryption metadata
2. Client-Side Encryption: Applications encrypt sensitive fields using supplier public keys
3. Zero-Knowledge Routing: Aggregators route based on plaintext fields, never decrypt PII
4. End-to-End Protection: Only the final MNO can decrypt and process sensitive data

Key Benefits

• Maintains Routing: Aggregators can still route requests effectively
• Protects PII: Sensitive data encrypted before leaving the application
• Regulatory Compliance: Addresses GDPR, PDPA, and data residency requirements
• Backward Compatible: Works with existing OIDC and CAMARA specifications

got some questions for discussion

1. Does this selective encryption approach align with CAMARA's vision for PII protection?
2. Should this be an OIDC extension or a separate CAMARA specification?
3. What security validation processes would you recommend for the encryption approach?

The goal is to enable secure multi-tier telco architectures while maintaining the efficiency of aggregator platforms. What are your thoughts on this direction?

[jpengar]

@drifterxy My 2 cents.

Specifying how aggregators should operate is outside the scope of CAMARA. The aggregation model is defined by GSMA Open Gateway, as detailed in its Realisation Guidelines. Consequently, CAMARA does not cover aspects like aggregators or telco finder. It's also important to remember that CAMARA can be applied to use cases beyond Open Gateway.

I believe we might be conflating authentication flows with KYC API calls. User data such as ID, name, and address is part of the KYC API call, not the authentication flow. In the Open Gateway model, routing decisions for aggregators are made during the access token retrieval. The information about the target operator (i.e., the user's provider) is bound to the access token. This means routing is resolved only once and not for every subsequent API call. Therefore, aggregators do not use information from the API payload to route the calls.

Separate from the routing issue is the topic of payload protection, which I suppose is what is being raised here.

[drifterxy]

Thanks @AxelNennker l and @jpengar for the clarifications — that helps a lot.

I see now that routing is already handled at the access token stage and that aggregator behavior is out of CAMARA’s scope. So the real focus here should just be payload protection for PII.

One idea I wanted to float is a lightweight payload encryption approach, where sensitive fields (ID, name, address, etc.) get encrypted end-to-end. That way only the final operator can ever see the PII, and intermediaries never get clear text.

Would CAMARA consider defining a general guideline or extension for payload encryption like this, separate from routing?

[HuubAppelboom]

@AxelNennker @jpengar The issue how to provide the public key of the operator to the API consumer, without revealing which MNO it is.

One very simple solution would be to encrypt the payload multiple times for a given country. Usually there are 3-4 MNO's in a country. You will then get 3-4 times the payload (each encrypted with a different key) in an API call.

[jpengar]

@AxelNennker @jpengar The issue how to provide the public key of the operator to the API consumer, without revealing which MNO it is.

One very simple solution would be to encrypt the payload multiple times for a given country. Usually there are 3-4 MNO's in a country. You will then get 3-4 times the payload (each encrypted with a different key) in an API call.

@HuubAppelboom There are indeed many challenges surrounding this topic. In https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/215449777/2025-08-27+Draft+Agenda+ICM+Minutes, we discussed the value of encrypting the API response (e.g. KYC data) for the API Consumer. In this scenario, the API Provider would need to use the API Consumer's public key to encrypt the data. But this is not trivial in scenarios involving Aggregators, such as those in Open Gateway.

However, other issues would also need to be discussed, such as:

• whether to encrypt specific fields (as proposed by @drifterxy), and
• how to handle/mark this in the API specifications (e.g. which fields will be encrypted) if needed.
• whether this kind of procedure would significantly increase API response time or not.
• etc.

I don't think this topic is actually specific to the ICM WG. I believe it also impacts the CAMARA commonalities as a much broader topic.

CC @rartych

[HuubAppelboom]

@jpengar @AxelNennker Which public encryption key (of the API Consumer) to use can be solved by submitting the public encryption key of the API Consumer as part of the payload of the request

You will get then in the request for example 3 times the encrypted request payload, and each of these will include also the public key with which to encrypt the answer.

The API consumer then only needs to retrieve the public keys of the MNO's in a country (which can also be shared through independent channels, not via the aggregator).