Hi @AxelNennker

This PR was discussed at the last Device Identifier sub-project meeting. Everyone was fine with introducing PPID as a third device identifier, but controlling this via scopes through a single endpoint was not agreed.

If you want PPID to be part of the Spring 25 meta-release version, I would suggest to reformulate this PR as an additional endpoint retrieve-ppid, controlled by a single scope and returning only the ppid and lastChecked parameters. Both can be required, so that there are no options in the response.

If you want to keep the PR unchanged, then I'll put it in the backlog for now, and we can discuss following finalisation of the Spring 25 version.

Hi @AxelNennker

I opened Issue #109 and PR #110 to introduce the PPID option as an additional endpoint. If you have any comments on that approach, please comment in the issue.

If you want to pursue the approach of using scopes to customise the output of an endpoint (i.e. the MobileConnect approach), please raise an issue in Commonalities to introduce that approach to CAMARA.

I think data minimization is not optional - at least in GDPR land and also in UK.
Not every use case needs all the data.
There needs to be a Purpose that justifies handing out personal information for each bit of PII.
For example if the API Consumer does not present a justification why they need to know the "manufacturer" then this API should not and must not hand that PII to them. The same for tac etc.

@eric-murray created a PR that introduces a new endpoint for PPID.
Why isn't there an endpoint for "manufacturer" and "tac"?

Endpoints allow API Providers to return "not implemented" but #110 does not use have that error, which I applaud. So, #110 must be implemented by all API Providers.

I think we should merge this PR because data minimization is required and we get better privacy because this PR also introduces PPID.

What are the reasons not to merge this?

If you want to pursue the approach of using scopes to customise the output of an endpoint (i.e. the MobileConnect approach), please raise an issue in Commonalities to introduce that approach to CAMARA.

I think that using scopes is the OpenId way to "customize" the output of an endpoint.
This especially makes sense in APIs where the output can be very different at the same endpoint. Having an extra endpoint for each subset of claims in e.g. KnowYourCustomer FillIn is just not maintainable
https://github.com/camaraproject/KnowYourCustomer/blob/main/code/API_definitions/kyc-fill-in.yaml

DeviceIdentifier is not as flexible as KYC FillIn and here we do not really have a data-minimization problem because the data is always in IMEI or IMEISV already and returning e.g. the "vendor" is more or less a convenience function. From an API design perspective I would not include e.g. vendor, TAC etc because implementing this is extra effort and who is liable if the data is wrong?

Regarding PPID I still prefer the scope and one endpoint and change the possible output of that one endpoint, but I think that PPID is a big improvement and I just LGTM-ed the PR that introduces a new endpoint for that.
API Consumers who do not care about the IMEI but need a device identifier and the vendor now have to call the API twice and then they have the tracking enabling IMEI which they do not need and maybe tried to avoid to know because they wanted to build a privacy friendly product.

Imagine an iPhone insurance, where currently most insurers insist on knowing the IMEI because it is a globally unique identifier that identifies the device. A PPID might be enough for this use case.