Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create CAMARA-API-AuthN-Inventory.md #62

Closed
wants to merge 5 commits into from

Conversation

shilpa-padgaonkar
Copy link
Collaborator

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
Copy link
Collaborator Author

shilpa-padgaonkar commented Sep 14, 2023

@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
Copy link

jlurien commented Sep 14, 2023

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
Copy link
Collaborator Author

shilpa-padgaonkar commented Sep 14, 2023

@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
Copy link

jlurien commented Sep 14, 2023

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
Copy link
Contributor

DT-DawidWroblewski commented Sep 15, 2023

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
Copy link
Collaborator Author

shilpa-padgaonkar commented Sep 15, 2023

@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
Copy link
Collaborator

diegogonmar commented Sep 15, 2023

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
Copy link
Collaborator Author

@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
Copy link
Collaborator

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
Copy link
Collaborator

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 shilpa-padgaonkar marked this pull request as draft September 20, 2023 11:15
@shilpa-padgaonkar
Copy link
Collaborator Author

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
Copy link

ECORMAC commented Nov 29, 2023

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
Copy link
Collaborator

jpengar commented Nov 29, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Align securitySchemes and security of CAMARA API specs with IdentityAndConsentManagement WG
7 participants