Align securitySchemes and security of CAMARA API specs with IdentityAndConsentManagement WG

[jpengar]

This issue is intended to define a single common/standard OpenID Connect security scheme for CAMARA API specs aligned with the OIDC FE/BE flows defined in https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/user-consent.md#authorization-flows--grant-types as the access flows to CAMARA APIs.

e.g.

components:
  securitySchemes:
    openId:
      type: openIdConnect
      openIdConnectUrl: https://example.com/.well-known/openid-configuration

This ensures that the CAMARA API specifications are consistent with each other and with the IdentityAndConsentManagement work:

• Any reference to other securitySchemes, such as client credentials, would generally be removed. Client credentials access (2-legged) must only be used "when user resource is NOT involved & the client belongs to confidential category".
• Those APIs without defined scopes should define the corresponding scopes that protect the API operations, and they must be associated with the OpenID Connect security scheme by means of the security property.

This has already been proposed in Commonalities in: camaraproject/Commonalities#53 where the proposal is very detailed. So we can just refer this issue in IdentityAndConsentManagement to issue #53 in Commonalities. The same Commonalities issue is not only intended to unify the usage of securitySchemes and security fields, but also to define a common scope naming format for CAMARA API specifications.

[shilpa-padgaonkar]

@jpengar : Now that we have the technical ruleset in for the 3-legged flows as well, I would suggest we also add (hint) the flow type within the security scheme. For eg. instead of the generic name openId, why not use specifically either openId-ciba or openId-authcode ?

[jlurien]

@jpengar : Now that we have the technical ruleset in for the 3-legged flows as well, I would suggest we also add (hint) the flow type within the security scheme. For eg. instead of the generic name openId, why not use specifically either openId-ciba or openId-authcode ?

Hi @shilpa-padgaonkar, Jesús is OOO. This topic is also being discussed in Commonalities: issue #53, and PR #57. In the issue there is an inventory of the current situation. The proposal there was to use "openIdConnect" as securitySchemes key everywhere, but as OIDC implies the discovery of the supported flows outside of the spec, your proposal to add some hint about the specific flow to be used with OIDC makes sense, as there is no other way to express that in OpenAPI with the openIdConnect type.

[shilpa-padgaonkar]

@jlurien how about expressing the hint as a part of the name as shown in my inventory PR here #62 (openId-ac, openId-cb)

[jlurien]

Yes, that is what I meant with "your proposal"

[jpengar]

@shilpa-padgaonkar @jlurien

In the last WG call conference (20/09) we proposed from Telefónica to define a default openIdConnect securityScheme for all CAMARA APIs and treat it as a CAMARA commonality. And ONLY consider additional securitySchemes in the API specifications YAMLs, for those APIs that have specific scenarios/requirements like APIs that only allow auth code flow (e.g. Number Verify API) or APIs without personal data processing guaranteed by Legal & Privacy teams so that Client Credentials securityScheme is included. In short, the proposal is to only handle exceptions specifically in API specification YAMLs, but by default have an openIdConnect securityScheme commonality.

This openIdConnect securityScheme would be the openId proposed above. This is already being discussed in Commonalities: Issue #53, and PR #57 as mentioned above.

This securityScheme provides the flexibility to support any of the defined flows (Auth code or CIBA) to access CAMARA APIs and to decouple APIs definition from APIs use cases definition. And the inventory (being created in PR #62) could be used to include a recommended flow according to the technical rule set defined in CAMARA-API-access-and-user-consent.md.

This will ensure that the CAMARA API specifications are consistent with each other and with the IdentityAndConsentManagement work.

[shilpa-padgaonkar]

@jpengar @jlurien : I would change the sentence formulation for "or APIs without personal data processing guaranteed by Legal & Privacy teams so that Client Credentials securityScheme is included." to "or where API providers find the current security schemes too restrictive and have the needed agreement from their legal and privacy teams such that they can use client credentials security scheme."

Legal and privacy rules are different in different parts of the world. Any API provider across the globe can decide to offer Camara APIs and they should be able to do so in the most efficient way based on the legal framework they need to comply to and should be given a chance to request for these exceptions in Camara.

For the auth-code and CIBA part:
I will make the needed changes in inventory file template to mention that the ciba/auth-code detail shows only a recommended flow option to ensure alignment, and will also update the technical ruleset line in Camara. I want to precisely point out that the technical ruleset recommendation is only applicable after (or comes into the picture) the subproject has decided for 3-legged flow instead of a 2-legged flow and that it is a recommendation as you have stated above in your comment.

[shilpa-padgaonkar]

@jpengar Also to avoid any confusion, I would like to point out that the basic authN-authZ doc still applies. It clearly states the use of client credentials and OIDC.

The line above "define a default openIdConnect securityScheme for all CAMARA APIs and treat it as a CAMARA commonality." is a bit misleading, especially for the audience who might not have seen the authN-authZ doc.

So I agree that for all Camara APIs where OIDC has been agreed, we can use the security scheme as shown below & as proposed above:

securitySchemes:
openId:
type: openIdConnect
openIdConnectUrl: https://example.com/.well-known/openid-configuration

and where client credentials is agreed we use
securitySchemes:
oAuth2ClientCredentials:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://api.example.com/oauth/token
scopes: {}

[jpengar]

@shilpa-padgaonkar

@jpengar @jlurien : I would change the sentence formulation for "or APIs without personal data processing guaranteed by Legal & Privacy teams so that Client Credentials securityScheme is included." to "or where API providers find the current security schemes too restrictive and have the needed agreement from their legal and privacy teams such that they can use client credentials security scheme."

I'm afraid we at Telefónica don't feel confortable with this sentence: "API providers find the current security schemes too restrictive". Every time personal user data is processed by an API and the user can exercise their rights either via opt-in and/or opt-out, 3-legged access tokens must be used
Consider "finding current security schemes too restrictive" is not a clear critera for making this decision. The legal departments will say whether there is processing of personal data or not, or whether opt-out applies or not, etc... which depends on various factors, such as local regulations (as you mention).

@jpengar Also to avoid any confusion, I would like to point out that the basic authN-authZ doc still applies. It clearly states the use of client credentials and OIDC.

That's true. The CAMARA-AuthN-AuthZ-Concept.md doc still applies, never say the opposite. And that same document states that client credentials only apply "when user resource is NOT involved & the client belongs to confidential category".

And regarding your other comments, more specifically on the proposal we made for the securitySchemes, given your feedback, what do you think about the following:

• just leaving the openIdConnect securityScheme in the CAMARA API yamls.
• Client Credentials is not included because it can be already covered by the openIdConnect securityScheme.
• The allowed flows/grant types are detected by the `.well-known'. Including client credentials if applicable.
• This way there is no impact on the APIs yaml, keeping it generic and consistent across CAMARA.

...keeping the proposal AS IS in camaraproject/Commonalities#53. This way the API specification will remain generic and the API technical specification will be completely decoupled from local regulations, legal decisions and so on...

[shilpa-padgaonkar]

@jpengar : From DT side we are fine with this interpretation. You convey my points in better words :)

The legal departments will say whether there is processing of personal data or not, or whether opt-out applies or not, etc... which depends on various factors, such as local regulations (as you mention).

[shilpa-padgaonkar]

@jpengar For your other points:

And regarding your other comments, more specifically on the proposal we made for the securitySchemes, given your feedback, what do you think about the following:

just leaving the openIdConnect securityScheme in the CAMARA API yamls.

• fine for me

Client Credentials is not included because it can be already covered by the openIdConnect securityScheme.

• here I would tag @AxelNennker to check if this is fine.

The allowed flows/grant types are detected by the `.well-known'. Including client credentials if applicable.

• I guess here you meant to refer the inventory file? Guess there is a link typo? If this is the case, fine for me.

This way there is no impact on the APIs yaml, keeping it generic and consistent across CAMARA.

• fine for me

[jpengar]

The allowed flows/grant types are detected by the `.well-known'. Including client credentials if applicable.

I guess here you meant to refer the inventory file? Guess there is a link typo? If this is the case, fine for me.

No, I meant the `.well-known' openId configuration endpoint, but only as a way to keep the YAML securityScheme generic, as already mentioned.

Regarding the inventory file, it could actually be quite challenging... because we might even have different flows depending on local regulations, couldn't we?

[AxelNennker]

@jpengar For your other points:

And regarding your other comments, more specifically on the proposal we made for the securitySchemes, given your feedback, what do you think about the following:

just leaving the openIdConnect securityScheme in the CAMARA API yamls.

* fine for me

Client Credentials is not included because it can be already covered by the openIdConnect securityScheme.

* here I would tag @AxelNennker to check if this is fine.

Maybe @jpengar can be more specific on how client credentials is already covered by the openIdConnect securityScheme?
Are you saying that the API consumer can look at the openid connect configuration e.g.
DT mobile connect configuration
and know whether client credentials is supported?

Is a Camara API provider allowed to say: I support client credentials but not user authentication and consent collection because my legal counsel tells me it is not needed in my jurisdiction?

Would such a API provider then specify the above proposed oauth2 security scheme and not openidConnect?

The allowed flows/grant types are detected by the `.well-known'. Including client credentials if applicable.

How would this .well-known file look like in the various cases?

* I guess here you meant to refer the inventory file? Guess there is a link typo? If this is the case, fine for me.

This way there is no impact on the APIs yaml, keeping it generic and consistent across CAMARA.

* fine for me

[shilpa-padgaonkar]

Regarding the inventory file, it could actually be quite challenging... because we might even have different flows depending on local regulations, couldn't we?

I assumed the inventory because we discussed this in the last id-consent call and said that the recommended flow could be specified here. But fine for me if we don't maintain it.

Now that we agree, we could have different flows based on local regulations, I personally would prefer to have client credentials oauth2 flow separately specified in addition to oidc.

But we can ask for more feedback from other contributors here as well.

[jpengar]

@AxelNennker

Maybe @jpengar can be more specific on how client credentials is already covered by the openIdConnect securityScheme?
Are you saying that the API consumer can look at the openid connect configuration e.g.
DT mobile connect configuration
and know whether client credentials is supported?

Yes, exactly. E.g. https://auth.es-pro.baikalplatform.com/.well-known/openid-configuration

"grant_types_supported":[
   "client_credentials",
   "password",
   "urn:ietf:params:oauth:grant-type:device_code",
   "urn:openid:params:grant-type:ciba",
   "authorization_code",
   "urn:ietf:params:oauth:grant-type:jwt-bearer"
],

OpenID configuration provides the list of supported flows which could include client credentials.

OpenID Spec --> https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata

grant_types_supported
    OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Type values that this OP supports. Dynamic OpenID Providers MUST support the authorization_code and implicit Grant Type values and MAY support other Grant Types. If omitted, the default value is ["authorization_code", "implicit"].

Is a Camara API provider allowed to say: I support client credentials but not user authentication and consent collection because my legal counsel tells me it is not needed in my jurisdiction?

This is precisely what we propose to keep separate from API YAMLs and technical solution. We propose to have just one generic openIdConnect securityScheme, leaving the API spec open, i.e. not tied to legal dependencies that may change locally on each country, not tied to commercial/business dependencias on how APIs are sold by API provider, and so on... The API specification should be common and agnostic to all this.

Leave those discussions to another level, business level, legal level, etc...

[patrice-conil]

Hi @jpengar,
I agree with your proposal that separates concerns and keeps specifications open.

[Elisabeth-Ericsson]

Hi @jepengar,
thank you for explaining on how client credential flow can be supported by openId configuration.
From the discussion above I understand, that all CSP have to need to upgrade to OpenID Connect capable authorization servers, even if they only expose APIs, which work fine with plain oAuth2.0 authorization servers using client credential flows.
Wouldn't it be much more flexible to support 2 security schemas where it makes sense/is feasible for the API/CSP ?

[jpengar]

@Elisabeth-Ericsson Hi Eli,

even if they only expose APIs that work fine with simple oAuth2.0 authorisation servers using client credential flows.

What do you mean by "even if they only expose APIs"? In the context of CAMARA, this is what it is all about. And in this context, CSPs (Operators) are already required to implement OpenID Connect capable authorisation servers, for example to expose CIBA. This is because, as mentioned above, every time personal user data is processed by an API and the user can exercise their rights either via opt-in and/or opt-out, 3-legged access must be used (i.e. client credentials would not apply).

Wouldn't it be much more flexible to support 2 security schemes where it makes sense/is feasible for the API/CSP?

We propose to have only one securityScheme to keep API specs as generic as possible.

[DT-DawidWroblewski]

Hi @jpengar !

I like the idea of using "well-known" endpoint to deliver information about supported security schemes - a smart idea to give developers information about out auth server capabilities!

On the other hand, I see it as a challenge when a developer gets a sim-swap.yaml and sees in securitySchemes openIdConnect only... which is not the case in many countries.

Should we define the way we want to introduce market-specific scenarios? I like the generic approach, but it also has its challenges - a lack of precise information about how to consume API (client credentials? three-legged? pure oauth2.0? OpenId Connect?, etc.).

[AxelNennker]

I think there are two or more ways to look at "a common Camara security" scheme.
It is worthwhile to agree on security schemes used in Camara and I like to use the OpenIdConnect flow, but I think using only one security scheme for Camara shifts the problem on layer down without really providing information.

So, yes: the IDGW/AZ metadata can be at the .well-known endpoint but I think it would be clearer for developers to have a common security scheme agreed upon here for the case where there is no user-consent needed for an API and/or in a country.

securitySchemes:
  CamaraClientCredentials:
    type: oauth2
    flows:
      clientCredentials:
        tokenUrl: https://api.example.com/oauth/token
        scopes: {}

[jpengar]

Let me put it another way. I think we all tend to agree that the access flow/grant to be used to consume a CAMARA API may be different depending on business and legal dependencies, which would be different according to local regulations in each country/market and so on...

Will we change the API spec to add or remove securitySchemes depending on local regulations? If country A's local regulation does not allow API X to be used with client credentials, do we change the API spec to remove client credentials for that country? Or the other way around?... How do we expect to manage this for each API and for the different countries where CAMARA APIs are exposed? With our proposal, the API Spec could be decoupled from these business/legal dependencies.

Or, if tomorrow CAMARA decides to use a new additional flow/grant, will we update all CAMARA API Specs in all API subproject working groups to include a securityScheme that reflects that?

Given the context we are describing here, it may be that these dependencies should be handled as part of the product catalogue in a local market for the different product-purpose combinations. Keep the CAMARA API specs generic, do not restrict one flow or another at API spec level.

[Elisabeth-Ericsson]

Hi @jpengar,
I think that you are spot on.
As you stated above: dependencies should be handled as part of the product catalogue in a local market for the different product-purpose combinations.

The API should list the possible security schemas which make sense for the API.

Then the CSP must select the one (or many) supported security schemes for the API product + purpose combination depending on his local regulations.

This API Product information must be exposed by the CSP to allow the aggregator /ASPs to implement the correct flows.

The consequence is that all API invokers (the aggregators) will have to implement all of the security schemes named in the API spec, unless they want to make business with selected CSPs only.

We also need to assure that we can support client_credential or authorization_code also with native oauth2 security schemes.

[shilpa-padgaonkar]

In the OAS specs (https://swagger.io/specification/?sbsearch=security%20scheme), under security scheme object, the mandatory field "type" explicitly specifies oauth2 (specified types - "apiKey", "http", "mutualTLS", "oauth2", "openIdConnect").

I am not sure if developers could therefore understand that oauth2 is implicitly possible when the type is specified as openIdConnect in Camara as suggested here in the above comments.
I would like to follow the standard in OAS and explicitly specify oauth2 when oauth2 is a possibility alongside openIdConnect.

[jlurien]

Hi @shilpa-padgaonkar, we are having this debate also in commonalities, let's try to consolidate all opinions.

Problem here is how developers will understand the concept of "possibility". When listing several explicit securitySchemes in the OAS spec, that is saying to developers that they can use any of the listed schemes to access the API, at their discretion, and that implementations must support all of them simultaneously, while the idea behind using discovery feature of OIDC is to avoid this assumption.

The supported grant_types to access certain API will depend on the agreements between operators, based on the regulatory and business constraints of each country or market. That should be reflected elsewhere, not in the CAMARA OAS spec, which should be common and as much agnostic as possible to all of this.

[nickvenezia]

Wouldn’t the countries’ “local” legislation be an issue which should be addressed? OAuth and OpenID are authorizations for access. Why is the consent “solution” placing the problem on the carrier? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Jose Luis Urien ***@***.***> Sent: Tuesday, October 10, 2023 10:56:51 AM To: camaraproject/IdentityAndConsentManagement ***@***.***> Cc: nickvenezia ***@***.***>; Comment ***@***.***> Subject: Re: [camaraproject/IdentityAndConsentManagement] Align `securitySchemes` and `security` of CAMARA API specs with IdentityAndConsentManagement WG (Issue #57) Hi @shilpa-padgaonkar<https://github.com/shilpa-padgaonkar>, we are having this debate also in commonalities, let's try to consolidate all opinions. Problem here is how developers will understand the concept of "possibility". When listing several explicit securitySchemes in the OAS spec, that is saying to developers that they can use any of the listed schemes to access the API, at their discretion, and that implementations must support all of them simultaneously, while the idea behind using discovery feature of OIDC is to avoid this assumption. The supported grant_types to access certain API will depend on the agreements between operators, based on the regulatory and business constraints of each country or market. That should be reflected elsewhere, not in the CAMARA OAS spec, which should be common and as much agnostic as possible to all of this. — Reply to this email directly, view it on GitHub<#57 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/A2QCWCLO6KYR66CJNFHWYP3X6VO3HAVCNFSM6AAAAAA4ENFCZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJVGYZDSMJVGM>. You are receiving this because you commented.Message ID: ***@***.***>

[shilpa-padgaonkar]

@jlurien The OAS also gives some hints on how to handle multiple authN types with logical ORs + ANDs.

Eventually every API provider will anyways have to update their individual documentation/specs to add their custom details regarding specific AuthZ url or openIdConnect URl and could then remove info not relevant to their implementation?

BTW agree on your point about consolidation of all opinions on this topic. Currently several open threads in comm, id-consent and some individual subprjs.

[jlurien]

@jlurien The OAS also gives some hints on how to handle multiple authN types with logical ORs + ANDs.

I don't get this part, sorry, how are ANDs and ORs being specified in OAS?

[chrishowell]

Please bear in mind with the .well-known that the caller may not know which CSP's .well-known to call to retrieve configuration at the time that the call is created.

I still think that this should be defined within the API specification; and maybe different endpoints for 'regulation free' implementors - it's much much easier to reason about that way.

[jlurien]

In reality I doubt developers will go to any .well-known URL to discover anything. Before making any call to an API there will be an on-boarding process for developers where they have to register their applications, to consume certain APIs under certain purposes, accept T&Cs, exchange credentials, and as part of this procedure, the required grant_type and authn flows needed to consume the API have to be communicated, taking into account the purposes and regulation. This process is being designed in parallel, using TMForum APIs.

Here we are designing the APIs and as part of the OAS spec we have to complete security sections with something that is compliant to the spec but at the same time flexible enough to accommodate all possibilities. Scopes have to be standardized as a minimum, and openIdConnect as securityScheme allows to express this flexibilty. At the same time, we have to document all of this, and probably add some guidance or references in the APIs to let developers understand the whole process. This is what was agreed in the last TSC.

[jpengar]

For the record, this issue was discussed at the TSC 2023-10-19 meeting and the conclusions and next steps agreed can be found at https://github.com/camaraproject/Governance/blob/main/documentation/MeetingMinutes/TSC/TSC-2023-10-19-Meeting-Minutes.md#commonalities--icm.

[jlurien]

As a follow-up of the TSC discussion, we have to agree on some wording to be included as part of the API spec, indicating to the potential API customers why we are not listing specific grant-types in the spec, and how to discover which authorization flows they will be allowed to use. The whole documentation can be kept in an external doc, tbd. In the spec we can include something generic and short, such as:

Authorization and authentication

CAMARA guidelines defines a set of authorization flows which can grant API clients access to the API functionality, as outlined in the document CAMARA-API-access-and-user-consent.md. Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.

It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.

[bigludo7]

@jlurien Checked with @sebdewet - your proposal works for us.

@jpengar Once we get more approval, I guess we should circle back to TSC for closing. Then this text should be copied in all our API.

[jpengar]

Thanks @bigludo7 !!

Please, this is a priority issue and WG participants are encouraged to provide their feedback on the wording proposal so that this issue can be closed as soon as possible and the API subprojects can adapt their API specifications accordingly.

[hdamker]

as outlined in the document CAMARA-API-access-and-user-consent.md.

@jlurien the link within the text proposal above is not the correct one, it points currently to #57, not the document.

Beyond that the text looks good to me, but will leave it to my colleagues to provide the collected DT feedback.

[jpengar]

Thanks @hdamker !!

@jlurien the link within the text proposal above is not the correct one, it points currently to #57, not the document.

Fixed.

[jpengar]

In order to properly manage the review process, I've created the PR #93 to include in the WG documentation the final agreement reached by the TSC and the WG participants on the securitySchemes and security of the CAMARA API specification, and the mandatory template for info.description, explaining to API customers why the API specification does not list specific grant types, and how to find out what authorization flows they can use.

@bigludo7 @sebdewet @hdamker You have already approved the text template proposal above. Please could you just do the same in the PR, so that the PR can be merged directly after everyone's review.

For the rest of the WG participants, please just provide your comment in the PR to complete the review process as soon as possible.

[shilpa-padgaonkar]

@diegogonmar : I am fine with the text

[sfnuser]

@jlurien @jpengar, All,

I understand the drive towards having a generic text to keep the complex legal topics out of the spec. However, is there a compromise possible in keeping information about security schema flows within the spec? The current .well_known configuration is too vague and can cause interoperability issues, which is the main problem a spec is supposed to avoid.

1. For e.g., if I want to have different security schema for different endpoints/methods within the spec (like in QoD today), how are we going to specify that?
2. If I am an aggregator and I want to interface with two operators within the same legal jurisdiction - How do I ensure that they both support the same security schemas that are compliant with CAMARA? What if an operator decides to use 3-legged flow for all the endpoints and other supports client_credentials for some where it can be applicable? Is this possible?
3. Let's say we want to deprecate a security flow in the future (or) make a breaking change in the security flow - How are we going to deploy that with the current .well_known definition? Are we going to bump the api version without any change in the spec? Security schema is part of the API lifecycle by design - is it not?
4. With the current .well_known proposal, how can a developer know the security flows that are implemented/supported by an operator for a specific API (Note: I don't think it is realistic for an operator to have per API based .well_known configuration)? Does a developer needs to be onboarded with each operator to identify the supported security flows for that API?

May be some or all of this is discussed & documented in GSMA? I don't know but it's good to capture the discussion in public domain.

Is it not possible to add all the applicable security flows in the spec for the respective endpoints (i.e.) why not the spec be the superset with all possible security flows for an endpoint? An operator, who feels that only a subset is applicable in a geographical area because of legal reasons, can decide to do the same in their respective spec in that geographical deployment. All operators in that region will have to do the same for the same legal reasons and there will be uniformity.

From a developer point of view, the spec that clearly states all the applicable security flows for an endpoint will help them develop solutions independently based on the spec and chose a subset while onboarding to a specific operator (if needed). I feel, it should not be other way around.

[diegogonmar]

Hi @sfnuser,
As discussed and agreed in last TSC, the way forward was formerly agreed in TSC and specific text is agreed in related PR. Solution chosen will not be re-discussed.
For mid-term, any evolution is possible of course, iterations are welcome. So please move this to a different issue with mid-term perspective

[sfnuser]

Hi @diegogonmar
I agree to create a new issue.

Please note that when this proposal is agreed in TSC, it is also agreed to create a separate document - and also discussed in Commonalities here - to list the possible security schema for the APIs but we have not seen one and yet APIs have already merged this .well_known security schema in the main branch (e.g. DeviceLocation, DeviceStatus).

I want to reiterate that the current agreed proposal on TSC is a short term solution and it spreads to all the APIs already.
The earlier we address this issue, it saves the effort for all of us.

[diegogonmar]

Hi @sfnuser
The document you mention as part of the agreement is the one edited with the PR associated to this issue #93. There, the possible security schemas are mentioned** as well as the applicable rules. Finally, it defines what the info.description of each API has to include to properly reference this document.

** Client Credentials to be included to fully cover the agreement.

What you reiterate is not correct, the issue was long discussed both here and in commonalities and, following CAMARA established procedures, was escalated to TSC for agreement. Discussion happened there, considering options and choosing the best one. You link such agreement and indicates it is an agreement, not a short term one. Further, in 7/12 it was ratified again that solution is not being rediscussed.