Create CAMARA-API-AuthN-Inventory.md

[shilpa-padgaonkar]

Partly Fixes #57

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

This document will provide an overview of security schemes for Camara APIs

Which issue(s) this PR fixes:

[shilpa-padgaonkar]

@hdamker @DT-DawidWroblewski @eric-murray @akoshunyadi : I have added as part of this inventory, examples that include APIs where you are code-owners/maintainers (I couldn't tag all code owners of these subprojects as not all are subscribed to this subproject). Kindly verify if the security schemes specified here are fine after alignment within your subprojects.

[jlurien]

In QoD we currently have both clientCredentials and authorizationCode. We have to align everything everywhere and decide which criteria must be applied. As QoD deals with personal information and requires consent, a 3-legged flow should be applied to the flow.

This topic is also being discussed in Commonalities: issue camaraproject/IdentityAndConsentManagement#53, and PR camaraproject/IdentityAndConsentManagement#57. In the issue there is already an inventory of the current situation. The proposal was to use "openIdConnect" as securitySchemes key, but as this is quite generic, your proposal to add some hint about the specific flow to be used with OIDC makes senses, as there is no other way to express that in OIDC.

[shilpa-padgaonkar]

@jlurien Fully agree. Hence, this inventory. The naming can be finalized as you said in camaraproject/Commonalities#57 and inventory can be maintained here using #62 as it makes more sense to keep it in this subproject. WDYT? We can also wait for more people to comment and also for @jpengar to be back from his vacation.

[jlurien]

Yes, I think we are totally aligned on this. It is OK to centralize all I&C stuff here. In the Commonalities guidelines there is also a chapter about security. We may decide to ref that part to some doc here, to avoid duplication if necessary.

[DT-DawidWroblewski]

Hi @shilpa-padgaonkar !

for SimSwap:
security scheme name:
OAUTH2.0 Client Credentials
scopes: none
OpenID Connect CIBA
scopes: retrieve-sim-swap-date, check-sim-swap

for NumberVerification:
security scheme name:
OpenID Connect
scopes: number-verification-verify-read, number-verification-share-read

for OTPValidation:
security scheme name:
OAUTH2.0 Client Credentials
scopes: none

[shilpa-padgaonkar]

@DT-DawidWroblewski : For simswap I see a different comment (#65) in issue #65 as compared to the above suggestion.

The idea of this inventory is to align on a single flow for api-scope/s. I have extended the list with the other 2 APIs you have provided details for.

After the flow has been aligned for sim swap in the subproject, feel free to make a commit directly to the PR.

[diegogonmar]

Hi @shilpa-padgaonkar, the idea is to have single one? I could think of APIs that may work both in CIBA and AuthCode, as both are 3-legged and use cases may exist valid for both flows.

[shilpa-padgaonkar]

@diegogonmar Yes the idea is to have a single flow. So if there are cases where both CIBA or AuthCode could be used as you have hinted above, the technical ruleset could be to determine which is one to add.

Technical ruleset for the Frontend flow

If all API usecases point to the need of On-net scneario and where the consumption device and authentication device are the same, the front end flow must be used. eg. NumberVerification

Technical ruleset for the Backend flow

If some usecase/s for an API point to off-net scenarios and where consumption and authentication devices could be different, the backend flow must be used.

[diegogonmar]

Yes, you're right, that was the agreed wording. I'd rather open different issue in case I think further discussion is needed about the ruleset, to cover scenarios where maybe 2 grants apply

[chrishowell]

Is there a reason why Carrier Billing requires the OIDC AuthCode flow? I can imagine a scenario where the consumption device and authorisation device are different, and the Technical Ruleset would imply that the Backend Flow should be used?

[shilpa-padgaonkar]

I have changed this PR to draft, so that we wait until subprojects are ready to piggyback their cleanup results back here & to ensure that we do not start any subproject related questions as a result of this PR review here.

[ECORMAC]

In Number Verification we have adhered to the use of OIDC security scheme as per commonalities guidelines (based on work in this group I beleive). However OIDC as per standard would also entail the use / delivery of identity tokens. In our case (Number Verification) we don't see the need for identity tokens (but see the need for Authorization code grant). I checked with commonalaties if there was some recommendation / principle that we could use to both adhere to OIDC but not use / implement identity tokens., However they pointed at this group for guidance.

[jpengar]

@ECORMAC Thank you for your comment. But I think you should open a new issue in https://github.com/camaraproject/IdentityAndConsentManagement/issues as this PR is currently on hold as a draft and is not directly related to the topic you raised above.