Open APIs

Hello everyone.

In our country, a new law related to personal data protection is being implemented, and from the cybersecurity area we have received the directive not to expose sensitive data in URLs.
Example: ID, MSISDN, etc.

However, we have some TMF GET operations that send sensitive data through query parameters. Examples:

TMF637
Request:
/tmf-api/productInventory/v5/product?realizingResource.resourceCharacteristic.name=msisdn&realizingResource.resourceCharacteristic.value=56900000000

TMF632
Request:
/tmf-api/party/v5/individual?individualIdentification.identificationType=RUT&individualIdentification.identificationId=11111111-1

The suggestion from the cybersecurity team is to switch to the POST method with sensitive data in the body, but this does not seem to align with the standard.

The questions are:

• Have other companies encountered these cases?
• How have they resolved them?
• Is there any implementation guidance from TM Forum?

Thank you, best regards.

Soledad.

Hi Maria,

we at Deutsche Telekom have the same issue, security department forbids having sensitive data in URLs (which also includes query parameters).
So far our solution was also to use POST, but meanwhile, a new HTTP method "QUERY" has been defined, and is supported by the latest OAS Version 3.2.0. In essence, QUERY is a GET with the quenry parameters in the body (possibly also using more complex query syntax), which solves the problem.

At TMF, it is currently discussed when/how to switch to OAS 3.2, and I assume that latest in the next Version 6, but maybe even before, using QUERY will be introduced.

Regards,
Lutz

Hello everyone.

In our country, a new law related to personal data protection is being implemented, and from the cybersecurity area we have received the directive not to expose sensitive data in URLs.
Example: ID, MSISDN, etc.

However, we have some TMF GET operations that send sensitive data through query parameters. Examples:

TMF637
Request:
/tmf-api/productInventory/v5/product?realizingResource.resourceCharacteristic.name=msisdn&realizingResource.resourceCharacteristic.value=56900000000

TMF632
Request:
/tmf-api/party/v5/individual?individualIdentification.identificationType=RUT&individualIdentification.identificationId=11111111-1

The suggestion from the cybersecurity team is to switch to the POST method with sensitive data in the body, but this does not seem to align with the standard.

The questions are:

• Have other companies encountered these cases?
• How have they resolved them?
• Is there any implementation guidance from TM Forum?

Thank you, best regards.

Soledad.

Hello María/Lutz,

This is a topic we are actively evaluating as well.

Across multiple operators, we are seeing the same tension between:

• TMF Open API patterns (GET + query parameters), and

• Security and regulatory guidance that forbids sensitive data in URLs (including query parameters).

Beyond method semantics (GET vs POST vs QUERY), one practical approach we are exploring is protecting the TMF API layer itself, so that:

• Sensitive identifiers are secured and normalized on ingress, regardless of where they appear

• Responses and events are inspected on egress to prevent unintended exposure of personal or regulated data

The goal is to make this non-disruptive to existing TMF API implementations and aligned with current specs, while still meeting local regulatory and cybersecurity requirements.

We are evaluating how this can be applied consistently across TMF 6xx/7xx APIs (e.g., Party, Product, Service, Resource) without forcing immediate spec or contract changes.

Happy to exchange experiences or discuss further with anyone interested.
Feel free to reach out by email.

Thanks,
Raj

Hi Maria,

we at Deutsche Telekom have the same issue, security department forbids having sensitive data in URLs (which also includes query parameters).
So far our solution was also to use POST, but meanwhile, a new HTTP method "QUERY" has been defined, and is supported by the latest OAS Version 3.2.0. In essence, QUERY is a GET with the quenry parameters in the body (possibly also using more complex query syntax), which solves the problem.

At TMF, it is currently discussed when/how to switch to OAS 3.2, and I assume that latest in the next Version 6, but maybe even before, using QUERY will be introduced.

Regards,
Lutz

Hello everyone.

In our country, a new law related to personal data protection is being implemented, and from the cybersecurity area we have received the directive not to expose sensitive data in URLs.
Example: ID, MSISDN, etc.

However, we have some TMF GET operations that send sensitive data through query parameters. Examples:

TMF637
Request:
/tmf-api/productInventory/v5/product?realizingResource.resourceCharacteristic.name=msisdn&realizingResource.resourceCharacteristic.value=56900000000

TMF632
Request:
/tmf-api/party/v5/individual?individualIdentification.identificationType=RUT&individualIdentification.identificationId=11111111-1

The suggestion from the cybersecurity team is to switch to the POST method with sensitive data in the body, but this does not seem to align with the standard.

The questions are:

• Have other companies encountered these cases?
• How have they resolved them?
• Is there any implementation guidance from TM Forum?

Thank you, best regards.

Soledad.

Hi Raj,

I thought I would weigh in on the subject.

Securing the content of the URL - ie. making sure it is not malicious through securing and normalising it does not address all the new security requirements.

We should also be obfuscating customer information.

This means if we pass a substantial query in the URL - there is every chance that we will 'leak' information about customers (id's, names, addresses etc.)

I think it is of paramount importance that the TMF API's ALSO support the QUERY operator (essentially a specialized POST).

Hello María/Lutz,

This is a topic we are actively evaluating as well.

Across multiple operators, we are seeing the same tension between:

• TMF Open API patterns (GET + query parameters), and

• Security and regulatory guidance that forbids sensitive data in URLs (including query parameters).

Beyond method semantics (GET vs POST vs QUERY), one practical approach we are exploring is protecting the TMF API layer itself, so that:

• Sensitive identifiers are secured and normalized on ingress, regardless of where they appear

• Responses and events are inspected on egress to prevent unintended exposure of personal or regulated data

The goal is to make this non-disruptive to existing TMF API implementations and aligned with current specs, while still meeting local regulatory and cybersecurity requirements.

We are evaluating how this can be applied consistently across TMF 6xx/7xx APIs (e.g., Party, Product, Service, Resource) without forcing immediate spec or contract changes.

Happy to exchange experiences or discuss further with anyone interested.
Feel free to reach out by email.

Thanks,
Raj

Hi Maria,

we at Deutsche Telekom have the same issue, security department forbids having sensitive data in URLs (which also includes query parameters).
So far our solution was also to use POST, but meanwhile, a new HTTP method "QUERY" has been defined, and is supported by the latest OAS Version 3.2.0. In essence, QUERY is a GET with the quenry parameters in the body (possibly also using more complex query syntax), which solves the problem.

At TMF, it is currently discussed when/how to switch to OAS 3.2, and I assume that latest in the next Version 6, but maybe even before, using QUERY will be introduced.

Regards,
Lutz

Hello everyone.

In our country, a new law related to personal data protection is being implemented, and from the cybersecurity area we have received the directive not to expose sensitive data in URLs.
Example: ID, MSISDN, etc.

However, we have some TMF GET operations that send sensitive data through query parameters. Examples:

TMF637
Request:
/tmf-api/productInventory/v5/product?realizingResource.resourceCharacteristic.name=msisdn&realizingResource.resourceCharacteristic.value=56900000000

TMF632
Request:
/tmf-api/party/v5/individual?individualIdentification.identificationType=RUT&individualIdentification.identificationId=11111111-1

The suggestion from the cybersecurity team is to switch to the POST method with sensitive data in the body, but this does not seem to align with the standard.

The questions are:

• Have other companies encountered these cases?
• How have they resolved them?
• Is there any implementation guidance from TM Forum?

Thank you, best regards.

Soledad.

Hi Peter,

Your point about obfuscating customer information in TMF APIs is spot-on. It got us thinking about something fundamental: when and where should obfuscation actually happen? At egress from the telco? At ingress from clients? Both?

We've started building a solution that can obfuscate sensitive data at multiple points in the request/response cycle-as close to the source (client/partner) as possible, or at egress when data leaves your infrastructure. Flexible, no sdk, just policy-driven.

But here's what we're really thinking about: What if TMF APIs were delivered security-native from day one?

A turnkey cloud VPC built specifically for the TMF ecosystem that eliminates any installation overheads for you, zero (and we mean it) firewall rules to configure, no routing configuration, identity-integrated on the backend. Just spin it up and go.

We're in midway, but the vision is clear: API security-first infrastructure for TMF, not security bolted on afterward.

I'd love to get your thoughts on this approach. What are your biggest concerns when it comes to API and data exposure in TMF APIs?

Thanks

Raj.

Hi Raj,

I thought I would weigh in on the subject.

Securing the content of the URL - ie. making sure it is not malicious through securing and normalising it does not address all the new security requirements.

We should also be obfuscating customer information.

This means if we pass a substantial query in the URL - there is every chance that we will 'leak' information about customers (id's, names, addresses etc.)

I think it is of paramount importance that the TMF API's ALSO support the QUERY operator (essentially a specialized POST).

Hello María/Lutz,

This is a topic we are actively evaluating as well.

Across multiple operators, we are seeing the same tension between:

• TMF Open API patterns (GET + query parameters), and

• Security and regulatory guidance that forbids sensitive data in URLs (including query parameters).

Beyond method semantics (GET vs POST vs QUERY), one practical approach we are exploring is protecting the TMF API layer itself, so that:

• Sensitive identifiers are secured and normalized on ingress, regardless of where they appear

• Responses and events are inspected on egress to prevent unintended exposure of personal or regulated data

The goal is to make this non-disruptive to existing TMF API implementations and aligned with current specs, while still meeting local regulatory and cybersecurity requirements.

We are evaluating how this can be applied consistently across TMF 6xx/7xx APIs (e.g., Party, Product, Service, Resource) without forcing immediate spec or contract changes.

Happy to exchange experiences or discuss further with anyone interested.
Feel free to reach out by email.

Thanks,
Raj

Hi Maria,

we at Deutsche Telekom have the same issue, security department forbids having sensitive data in URLs (which also includes query parameters).
So far our solution was also to use POST, but meanwhile, a new HTTP method "QUERY" has been defined, and is supported by the latest OAS Version 3.2.0. In essence, QUERY is a GET with the quenry parameters in the body (possibly also using more complex query syntax), which solves the problem.

At TMF, it is currently discussed when/how to switch to OAS 3.2, and I assume that latest in the next Version 6, but maybe even before, using QUERY will be introduced.

Regards,
Lutz

Hello everyone.

In our country, a new law related to personal data protection is being implemented, and from the cybersecurity area we have received the directive not to expose sensitive data in URLs.
Example: ID, MSISDN, etc.

However, we have some TMF GET operations that send sensitive data through query parameters. Examples:

TMF637
Request:
/tmf-api/productInventory/v5/product?realizingResource.resourceCharacteristic.name=msisdn&realizingResource.resourceCharacteristic.value=56900000000

TMF632
Request:
/tmf-api/party/v5/individual?individualIdentification.identificationType=RUT&individualIdentification.identificationId=11111111-1

The suggestion from the cybersecurity team is to switch to the POST method with sensitive data in the body, but this does not seem to align with the standard.

The questions are:

• Have other companies encountered these cases?
• How have they resolved them?
• Is there any implementation guidance from TM Forum?

Thank you, best regards.

Soledad.