Population Density Data, as an API which is not handling personal data in any case, is agreed to consider 2-legged access tokens generically, following the agreed rules in Identity&Consent of:
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.
As stated up to now, the security mechanism is defined as "openIdConnect" generically, but it's clear that in cases like this it'd be more clear and realistic to directly define it as "oAuth2ClientCredentials".
Question raised to I&C group is whether this kind of APIs could directly be considered as 2-legged (client credentials) for clarity/simplicity, since it's not open to regulation or interpretation, as no personal data is managed.
During discussions in Population Density Data API, access/auth mechanism debate was raised. https://github.com/camaraproject/PopulationDensityData/issues/24
Population Density Data, as an API which is not handling personal data in any case, is agreed to consider 2-legged access tokens generically, following the agreed rules in Identity&Consent of:
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.
As stated up to now, the security mechanism is defined as "openIdConnect" generically, but it's clear that in cases like this it'd be more clear and realistic to directly define it as "oAuth2ClientCredentials".
Question raised to I&C group is whether this kind of APIs could directly be considered as 2-legged (client credentials) for clarity/simplicity, since it's not open to regulation or interpretation, as no personal data is managed.