[API Proposal] TrustWorthiness Intent API #293

[panos-ece]

• OpenAPI schema as supporting document for TrustWorthiness Intent API
• API proposal template

What type of PR is this?

• enhancement/feature
• documentation

What this PR does / why we need it:

PR for API proposal of #293

Which issue(s) this PR fixes:

Fixes #293

Special notes for reviewers:

Changelog input

 openAPI schema for API proposal
 Proposal Template

Additional documentation

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: panos-ece / name: panagiotis-pavlidis (1eda21f, 377c656, 8484943, 902cb40, a4ddc07, a7e1d88)

[albertoramosmonagas]

Hi @panos-ece, from the proposal, I understand that Infosys would have to be at this point? Also, for readability, could you remove what is part of the template and leave only the useful information? That is, from here:

### API family name

Name of the API or API family.

CAMARA TrustWorthiness INTENT API.

We would leave only:

### API family name

CAMARA TrustWorthiness INTENT API.

This makes it easier to review. If you could apply this to the rest of the document.

[panos-ece]

Hi @albertoramosmonagas , I have updated the template after your comments. One question about the infolysis P.C. part. Due to the common proposal part, should they commit as well, or is it just fine to somehow list the author in the PR description?

[albertoramosmonagas]

Would it be sufficient to put them on the list of supporters. I understand that if this API moves on to repository creation, infolysis would become a maintainer or code owner?

[panos-ece]

Hi @albertoramosmonagas, I have updated the proposal template with the infolysis as well in the supporters section.

[albertoramosmonagas]

Hi @panos-ece, thanks for the PR. I have a few points we should cover: (1) what telco capability/operator systems this maps to (CAMARA scope), (2) how cross-operator consistency of the scoring would be ensured (normative semantics + conformance), (3) what “monitoring” lifecycle you plan to add beyond POST (e.g., GET/status/subscriptions), and (4) how you mitigate privacy/compliance risks from free-text inputs.

Happy to discuss these in the next API Backlog meeting on 8 Jan 2026. Also, could you please resolve the EasyCLA check in the PR by following the link shown by the bot and registering your organization?

[panos-ece]

Hi @albertoramosmonagas , We are trying to resolve the EasyCLA and we have a following question. From NCSRD on behalf of the FRONT Research Group, I will be the main contributor to this proposal. However, the EasyCLA, should be signed by me or the Group Leader? Also, this is a step that should be done later in the process?

[albertoramosmonagas]

Hi @panos-ece, In principle, if your company or group is not registered, you or the person within your group who has the permissions to do so would first need to register. Once registration is complete, you could join that previously signed group. This step is mandatory for API evaluation by the TSC.

First, the API is brought to the backlog to evaluate and refine the proposal, and once the backlog has given the OK, it is sent to the TSC for final acceptance. Once accepted, the onboarding tracker is created to create the repository, wiki page, mailing list, etc.

[panos-ece]

Hi @albertoramosmonagas ,
I think that we have resolved the easyCLA issue. Thank you for your points for this PR. Also, what is the date that need to present this proposal in the API Backlog meeting?

[albertoramosmonagas]

Hi @albertoramosmonagas , I think that we have resolved the easyCLA issue. Thank you for your points for this PR. Also, what is the date that need to present this proposal in the API Backlog meeting?

Hi @panos-ece, as you can see at the end of the page we have on the "All checks have failed" the mentioned one, "EasyCLA — Missing CLA Authorization." Please check that this is correct.

Regarding the date of the backlog sessions, you can do so at any of them, as this API is already on the agenda and in the minutes. If you do not yet have the invitation in your calendar, you can register via:

• 2nd Thursdays at 09:00 UTC (10:00 CET / 01:00 PT) [Note: during next DST, 11:00 CEST / 02:00 PST] Registration / Join
• 4th Thursdays at 15:00 UTC (16:00 CET / 07:00 PT) [Note: during next DST, 17:00 CEST / 08:00 PST] Registration / Join

The next session is scheduled for Thursday, January 22, at 4:00 p.m. UTC.

[panos-ece]

Hi @albertoramosmonagas ,
I have pushed a pdf presentation as well as some refinements after your comments and we can further discuss them on the tomorrow's meeting.

Also, as i have seen, the easyCLA has not been resolved even after our registration for the CLA Authorization agreement. Can we have any support to solve this issue?

[albertoramosmonagas]

Thanks for the changes. Regarding to the EasyCLA is failing because the email used in your commits isn’t linked to your GitHub account.

1. Open the PR and add .patch to the end of the URL to see the exact commit email.
2. In GitHub go to Settings → Emails.
3. Add that same email address and verify it (click the verification link in your inbox).
4. Come back to the PR and re-run the check (refresh the PR; if needed, comment /easycla).

Once the email is linked + verified, EasyCLA should pass.

[albertoramosmonagas]

The name of the API does not need to include the word ‘API’ or “CAMARA” as it is implied in the context we are in. It would simply be ‘Trustworthiness Intent’.

[panos-ece]

Thank you for your comments. That was resolved as well as the EasyCLA.

[albertoramosmonagas]

Hi @panos-ece, thanks for updating the PR after the Backlog feedback. Good progress! I’ve left a few comments in the PR to review and tighten the remaining gaps.

[albertoramosmonagas]

This is a listing, not a regulatory contract. It's unclear what capability the API actually exposes, or which carrier system is invoked/conditioned upon receiving the intent. It still reeks of telco scoring and storytelling.

[albertoramosmonagas]

The semantics are still too soft for real interoperability: it doesn't define what happens at edges (e.g., score=0.0), nor a conformance rule ("if you return X you must comply with Y"), nor how to prevent each implementation from "interpreting" differently.

[albertoramosmonagas]

It's in "guidance" format, but it needs to be translated into standards and behavior; I understand we would have to reflect that in the YAML?

[albertoramosmonagas]

Hi @panos-ece ,

Following the Backlog AP (“get feedback from Backlog WG and review the telco operator capability scope”), I asked some participants for their view on this API. The suggestion is not to support taking TWIA forward in its current form, and they do not think it is ready for escalation to TSC.

Key gaps highlighted:

• CAMARA scope / telco capability fit: the core contract currently reads as “free-text intent in → score out”, which is not a telco network capability by itself, and it’s unclear what would be standardized beyond returning numbers.
• Interoperability risk: free-text interpretation will vary by implementation, making outcomes non-deterministic across operators even with bands/profiles unless semantics are strictly defined.
• Single-score reduction risk: “trustworthiness” is multi-dimensional and context-dependent; collapsing it into one score can be misleading unless model/evidence/semantics are tightly specified (hard to standardize across operators).
• Missing enforcement + lifecycle: if the intent is to drive operator controls (e.g., QoD/slicing/fraud/verification), the spec should explicitly model what controls are requested/allowed/applied, include evidence/attestation, and define a lifecycle (create/get/delete) — not only a score response.
• Subject/asset ambiguity: the “asset” concept isn’t tied to typical CAMARA subjects (device/number/service instance) and their access restrictions, which is essential for meaningful assurance.
• Business value/demand unclear: without measurable, enforceable telco controls behind it, it’s hard to justify why developers would pay for a score vs doing their own risk scoring.
• Solution-led concern: “no network/cloud capabilities required” + external AI orchestrator makes it look like a generic scoring service looking for a CAMARA problem, rather than a capability-driven API.

Suggested direction:

• Either park/decline TWIA as a CAMARA API, or
• Come back with a tighter proposal: a specific telco capability, deterministic inputs (no free text), normative semantics for profiles, and a clear contract on what the operator must/should do and expose.

If you’re open to it, I suggest we align in the next Backlog session on which path you prefer (re-scope vs park), and what minimum changes would make the proposal credible for multi-operator interoperability and eventual TSC approval.

[panos-ece]

Hi @albertoramosmonagas ,
Thanks a lot for your comments. Due to parallel undergoing activities, we will review your comments and come back to you as soon as possible.

[koumaras]

Hi @albertoramosmonagas,

Thank you for the detailed feedback.

Just to inform you that we are preparing to come back with a tighter proposa that addresses your comments, i.e. a specific telco capability, deterministic inputs (no free text), normative semantics for profiles and a clear contract on what the operator must/should do and expose.

Next week we will notify you to go first with an internal review process with you, when you are also available.

Is this plan OK with you?

Hi @panos-ece ,

Following the Backlog AP (“get feedback from Backlog WG and review the telco operator capability scope”), I asked some participants for their view on this API. The suggestion is not to support taking TWIA forward in its current form, and they do not think it is ready for escalation to TSC.

Key gaps highlighted:

* **CAMARA scope / telco capability fit:** the core contract currently reads as “free-text intent in → score out”, which is not a telco network capability by itself, and it’s unclear what would be standardized beyond returning numbers.

* **Interoperability risk:** free-text interpretation will vary by implementation, making outcomes non-deterministic across operators even with bands/profiles unless semantics are strictly defined.

* **Single-score reduction risk:** “trustworthiness” is multi-dimensional and context-dependent; collapsing it into one score can be misleading unless model/evidence/semantics are tightly specified (hard to standardize across operators).

* **Missing enforcement + lifecycle:** if the intent is to drive operator controls (e.g., QoD/slicing/fraud/verification), the spec should explicitly model what controls are requested/allowed/applied, include evidence/attestation, and define a lifecycle (create/get/delete) — not only a score response.

* **Subject/asset ambiguity:** the “asset” concept isn’t tied to typical CAMARA subjects (device/number/service instance) and their access restrictions, which is essential for meaningful assurance.

* **Business value/demand unclear:** without measurable, enforceable telco controls behind it, it’s hard to justify why developers would pay for a score vs doing their own risk scoring.

* **Solution-led concern:** “no network/cloud capabilities required” + external AI orchestrator makes it look like a generic scoring service looking for a CAMARA problem, rather than a capability-driven API.

Suggested direction:

* Either **park/decline TWIA as a CAMARA API**, or

* Come back with a tighter proposal: a **specific telco capability**, **deterministic inputs (no free text)**, **normative semantics for profiles**, and a clear contract on what the operator must/should do and expose.

If you’re open to it, I suggest we align in the next Backlog session on which path you prefer (re-scope vs park), and what minimum changes would make the proposal credible for multi-operator interoperability and eventual TSC approval.

[albertoramosmonagas]

Hi @koumaras, Great—there's a backlog session next week in case you want to resubmit the API. As far as I'm concerned, that's fine.

[koumaras]

@albertoramosmonagas we are still working on the revisions and I do not think that we will manage to participate today. We are targeting the next session. When is it scheduled?

[albertoramosmonagas]

Hi @koumaras, no problem, the next session is on 9 April.

[albertoramosmonagas]

Hi @koumaras, our last conversation was on 12th March.

We haven't received any updates since then, and seven sessions have passed without any progress on the action items. The proposal from the backlog group, in accordance with the Frozen (https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/868712456/2026-06-25+API+Backlog+Minutes#Frozen-APIs) status, would be to archive this proposal.

If we do not receive a response, we will proceed to move it to Frozen at the next backlog session on June 25.

[koumaras]

Hi @albertoramosmonagas! You are right and apologies for being inactive!
We have not abandoned the API, but we were really busy after Easter break.
We come back to this now.
The week 22-26/6 is possible to present (e.g. 25/6?) a revised version?

[albertoramosmonagas]

Hi @koumaras, next meeting will be 25th June. It's perfect for you to share their updates

[koumaras]

Hi @koumaras, next meeting will be 25th June. It's perfect for you to share their updates

Hi @albertoramosmonagas , I confirm my participation on 25/6. Please provide me the telco link (preferably by email). Thank you

[albertoramosmonagas]

Hi @koumaras, in the readme you have all of the related information.

Meeting Registration / Join

Meeting Cadence:

2nd Thursdays at 10:00 CE(S)T / 08:00 UTC / 01:00 PT

Meeting Registration / Join

4th Thursdays at 15:00 CE(S)T / 13:00 UTC / 06:00 PT

Meeting Registration / Join

Mailing List

[koumaras]

@albertoramosmonagas I am confused with the times. In the link it appears 6.00 PM

but you are mentioning 15.00 CEST.
Is the telco in one hour?

[koumaras]

@albertoramosmonagas Hi Alberto! Could you please guide me where to upload the presentation? Is here convenient?

[albertoramosmonagas]

@albertoramosmonagas Hi Alberto! Could you please guide me where to upload the presentation? Is here convenient?

Hi, totally, you can use this pull request. And here documentation/SupportingDocuments you can upload the presentation!

[koumaras]

Hi @albertoramosmonagas ,

Please find attached the revised presentation of the Network Trustworthiness Assurance API, including the requested matrix.
CAMARA_Network Trustworthiness Assurance API_Final_KOUMARAS_matrix.pptx
Once you have reviewed it, please let me know if further adjustments are needed and how we proceed further.

Thank you

Harilaos

[albertoramosmonagas]

Hi @koumaras, thanks for the update. I understand that this is the document that's been uploaded to the PR? Otherwise, it would need to be updated.

I think a few points still need to be addressed before the @camaraproject/api-backlog_codeowners can complete the review:

• Please update the API proposal itself with the revised scope and technical model; the presentation alone is not sufficient.
• Please use one consistent assurance-level model across the proposal.
• Most importantly, clarify whether this is a new telco capability or a composite/enriched service built on existing CAMARA APIs.
• Please narrow the initial scope by defining the supported assurance profiles and clarify whether privacy assurance is network-derived or an ICM/privacy-by-design requirement.

Once the proposal is updated with this information, the Backlog Code Owners can review the revised scope and decide whether it is ready to move forward.

[koumaras]

Hi @albertoramosmonagas !
I have prepared a revised version of the presentation that replies to your questions.
Please check it and let me know if further clarifications are needed.
In a nutshell

• Consistent assurance-level model across the proposal has been used.
• The proposed API is not consuming CAMARA APIs, but the NTWA API reuses the same classes of authoritative network evidence, such as NEF for example, that may also be exposed through existing CAMARA APIs, proving its feasibility. This was already addressed in the presentation, but more emphasized now.
• Two supported assurance profiles are defined.
• Privacy assurance is considered as ICM / privacy-by-design requirement, but let me know if you consider this an issue.

If we have resolved the open issues, please let me know and I will proceed with the API code.
CAMARA_NTWA_API_REVISED.pptx

[albertoramosmonagas]

Hi @koumaras, thanks for the revised presentation. If this is the final version, please upload it to the PR under the supporting documents so that the Backlog Code Owners review the same authoritative version.

However, two points remain before the review can be completed:

1. Please update the API proposal itself with the new NTWA name, scope, business value, technical model, profiles and request/response semantics. The revised presentation represents a substantial re-scope from TWIA and cannot remain only as supporting material.

2. Please strengthen the justification for why this composite assurance abstraction is a new CAMARA telco capability, rather than an enriched operator/aggregator product combining multiple existing evidence domains. Some profile rules also still use subjective terms such as “minor instability”, “weak confidence” or “within tolerance”, which will need deterministic definitions for cross-operator interoperability.

Once the proposal is updated and the latest presentation is attached to the PR, the Backlog Code Owners can review the revised scope and decide whether it is ready to move forward.

[koumaras]

Hi @albertoramosmonagas ! First of all congrats to Spain! Campeón del mundo!!!
For the presention, you are right, I am correcting the subjective terms... this is my mistake.
For point 2, I want to ask you. Do you believe that it would be better to present the new API as a service that consumes other CAMARA services? Is this compatible with CAMARA? Because, the idea is to use data from sources that are already available and consumed from other CAMARA APIs, but not using the CAMARA APIs themselves. Of course it is possible to consume the CAMARA APIs, instead of the 3GPP APIs, but then I think that the simplification approach of CAMARA is lost. However, please let me know your view on this.
Finally, we are working on the code. I will notify you when we are ready.

[albertoramosmonagas]

Hi @albertoramosmonagas ! First of all congrats to Spain! Campeón del mundo!!! For the presention, you are right, I am correcting the subjective terms... this is my mistake. For point 2, I want to ask you. Do you believe that it would be better to present the new API as a service that consumes other CAMARA services? Is this compatible with CAMARA? Because, the idea is to use data from sources that are already available and consumed from other CAMARA APIs, but not using the CAMARA APIs themselves. Of course it is possible to consume the CAMARA APIs, instead of the 3GPP APIs, but then I think that the simplification approach of CAMARA is lost. However, please let me know your view on this. Finally, we are working on the code. I will notify you when we are ready.

Hi @koumaras, thanks!! An incredible night—and a stressful one at the same time 🇪🇸

Regarding your question on architecture: this is not something Backlog needs to decide. Per the Project Charter, the transformation function (how an operator sources evidence southbound — whether via NEF/NWDAF directly or via an internal reuse of an existing CAMARA API's own implementation) is explicitly outside CAMARA's harmonization scope.

Each operator implements it as it sees fit; the API definition itself should not depend on or reference this choice. You can drop this question from the proposal entirely.

What remains genuinely open, and unanswered by the last revision, is not the architecture question but the one from my July 16 comment: whether NTWA constitutes a new, independently standardizable telco capability, or whether it is a composite/aggregator product built on evidence classes CAMARA already exposes through existing APIs. Your own description — that NTWA reuses the same classes of evidence already exposed through existing CAMARA APIs — points toward the latter, which the Charter treats as the kind of enriched product that aggregators or hyperscalers build on top of CAMARA, not something CAMARA itself standardizes. The proposal needs to make the affirmative case against this reading, with specifics, not a restatement of the reuse claim.

Two further points before this can move:

1. The subjective terms in the assurance matrix are still open, by your own admission. Until every evidence-to-level mapping rule is deterministic, cross-operator interoperability cannot be claimed, regardless of the HIGH/MEDIUM/LOW relabeling.
2. "Privacy assurance is an ICM / privacy-by-design requirement" does not resolve the ICM question; it defers it. The proposal must state which data classes are processed and which of the four CAMARA authorization flows applies, given that assurance levels appear to derive from subject-specific signals (device, SIM, location).

Please update the proposal document itself (not only the presentation) with the current NTWA scope, and address the capability-vs-composite justification directly. Happy to discuss at the next session once that is in.