[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 email address for the commit (377c656, 902cb40) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[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?

[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.