camaraproject / OTPValidation

Repository to describe, develop, document and test the OTP Validation API family
https://wiki.camaraproject.org/display/CAM/OTPValidation
Apache License 2.0
6 stars 13 forks source link

preparing for a Release #36

Closed DT-DawidWroblewski closed 1 year ago

DT-DawidWroblewski commented 1 year ago

What type of PR is this?

Add one of the following kinds:

What this PR does / why we need it:

to create a v0.5.0 release

Which issue(s) this PR fixes:

Special notes for reviewers:

Changelog input

Additional documentation

fernandopradocabrillo commented 1 year ago

Hi @DT-DawidWroblewski @bigludo7 I'm checking the release and I can see that we still have the old securitySchemes model. We should update it to OpenId and align with the rest of APIs.

DT-DawidWroblewski commented 1 year ago

Hi @fernandopradocabrillo !

this API used client credentials from the very beginning, as it does not involve user resource. Therefore, we can use client credentials here explicitly.

I see no reason to make this update.

@bigludo7 what do you think about it?

bigludo7 commented 1 year ago

Hello @fernandopradocabrillo @DT-DawidWroblewski

This is a good sample to discuss ! .... probably should be raise here: https://github.com/camaraproject/IdentityAndConsentManagement/issues/57 I've same perspective than Dawid that Client Credentials is just good enough for this.

Question for Fernando: Do we want for an API like this one go thru openIdConnect as securityScheme type which is a bit cumbersome, and not usual for this kind of API, for the sake of CAMARA global consistency?

fernandopradocabrillo commented 1 year ago

@DT-DawidWroblewski @bigludo7

Actually my opinion on forcing OpenId is not that strong on this one. On one side I think that, for this case specifically, leaving the Client Credentials may be just good enough since the auth flow is pretty clear and not that opened to discussion as it may be in Sim swap or Number Verification. And on the other hand I also think that if we are aiming for standarization we should come to an agreement and a common way of expressing things, having a global consistency across all APIs so a developer have a sense of uniformity when implementing every service of the CAMARA family. Also, multiple documentations support the possibility of use client credentials under openId definition, so we wouldn't actually be changing the type of authorization, just the way we express it. I think my opinion tends to favour the latter, but it is something a bit complex and still under discussion I'm afraid. Definitly a topic to discuss under Commonalities WG or in https://github.com/camaraproject/IdentityAndConsentManagement/issues/57 as Ludovic mentioned.

nickvenezia commented 1 year ago

Would a solution that works with opened and meets local privacy regulation be beneficial?