Thanks @AxelNennker, @HuubAppelboom, I totally agree that data minimization must be addressed following GDPR recommendations. That was a subject we had to work. But I'm quite surprised we should answer by multiple scopes per attribute.
Could we try to find another way to address this need or is it also a rules ?
BR
Gilles

if we see what TMF recommends using fields syntax in the query, to do something similar we should have use a GET operation.

@AxelNennker @GillesInnov35
There are also some alternatives, for example using "profile" in the scope to return all name related items
See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Another option is to use claims as an Authorization request parameter
See https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
That has the advantage that you can also specify in user consent cases which claims are essential for the API Consumer and which ones are voluntary (optional). This is something that can very well be used in the consent acquisition process as well.

@GillesInnov35

Maybe you are wondering about the kyc-fill-in:fill-in scope value? I started with that because I wanted to use the OIDC standard claim in this API. Then I discovered that this API does not use the OIDC standard claims. There are minimal differences sometimes e.g. given_name vs givenName.

I am going to remove the scope value kyc-fill-in:fill-in from this PR and always use the the attributes as scope.

The scope value in the authorization request would be "kyc-fill-in:givenName kyc-fill-in:familyName" if the API Consumer wants an access token hat allows the givenName and the familyName to be retrieved in the API call. The API call would not have any attributes as parameters because givenName and familyName would be associated with the access token.

@AxelNennker @GillesInnov35 There are also some alternatives, for example using "profile" in the scope to return all name related items See https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Another option is to use claims as an Authorization request parameter See https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter That has the advantage that you can also specify in user consent cases which claims are essential for the API Consumer and which ones are voluntary (optional). This is something that can very well be used in the consent acquisition process as well.

I wanted to propose here a minimal PR to KYC that allows retrieval of a subset of the claims the API provider has.

The attribute/claims and related scopes are defined by KYC-Fill-in and KYC-Match.

I created a discussion #158 about why KYC uses e.g. givenName instead of the OIDC standard "given_name".

I closed the discussion #158
It is not so important for this PR.

This a minimal PR that enables data-minimization.
I think it is not good that the API consumer calls this API and the API provider provides whatever they have in their subscriber database.

As for the "alternatives", yes "claims" could be an alternative. Although, I think, the "essential" claims and optional claims also gets the API provider in hot GDPR water.
E.g. when Telekom Deutschland electronically reads attributes from the German id card, then our DPO advised us to read exactly read the attributes that we are required by law (TKG §172 in German) to collect - not more.
But that is another discussion, I think.

Hi @AxelNennker , Hi all,

Ater yesterday's meeting, I have discussed this internally with my colleagues. Actually, what we are doing for the KYC Fill-in service is that, when we make contract with RPs for the KYC Fill-in API use, it is decided which parameters/attributes each RP (App client) will receive by the API call, based on each RP's requirement. Each RP's requirement for KYC Fill-in API is usually stable, and by this process, we conform to data-minimization concept.

So, our view is that for non-GDPR countries including Japan, the proposed 'atomized scope' may be too much, a kind of bother to API users, potentially creating some side effects e.g. it may result in a extremely long URL because of many scopes with percent-encoding. So we tend to be negative. But, at the same time, GDPR countries' circumstances are understandable.

One proposal. Why don't we keep 'kyc-fill-in:fill-in' and just add atomized scope proposed by this PR, to fulfill both sides' requirements?

Thanks,
Toshi

@ToshiWakayama-KDDI

Ater yesterday's meeting, I have discussed this internally with my colleagues. Actually, what we are doing for the KYC Fill-in service is that, when we make contract with RPs for the KYC Fill-in API use, it is decided which parameters/attributes each RP (App client) will receive by the API call, based on each RP's requirement. Each RP's requirement for KYC Fill-in API is usually stable, and by this process, we conform to data-minimization concept.

As you know, the agreement on allowed scope is done in CAMARA during the onboarding process of the API consumer.
There is no direct contact between API producer and API consumer.
Detemining which scopes are allowed for an API consumer is the standard CAMARA onboarding process.
If KDDI wants to offer the API directly to API consumers, that is of course still possible, but I think that hurts the "spirit" of CAMARA. Together we are stronger.

So, our view is that for non-GDPR countries including Japan, the proposed 'atomized scope' may be too much, a kind of bother to API users, potentially creating some side effects e.g. it may result in a extremely long URL because of many scopes with percent-encoding. So we tend to be negative. But, at the same time, GDPR countries' circumstances are understandable.

Current URL limits are at about 4k, I think, which should fit even long lists of scopes.
But the API consumer can always POST the scopes in the OIDC authentication request which puts the parameters into the request body and URL length is not a problem. That is also preferable because URLs are logged but requests bodies are usually not logged. DT security demands that we have a good reason not to use POST.

Please see: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 7231 [RFC7231] at the Authorization Endpoint.

One proposal. Why don't we keep 'kyc-fill-in:fill-in' and just add atomized scope proposed by this PR, to fulfill both sides' requirements?

OIDC also defines some scopes like "profile" that means that a collection of attributes is returned in the API response.
We could certainly define some special scopes that make sense for API consumers e.g. "kyc-fill-in:profile"
I would please request that those special scopes are well defined.
In my opinion a special scope like 'kyc-fill-in:fill-in' should not mean "I give you e.g. idDocument if I have it, but maybe not".
There could be a special scope address that means all attributes related to addresses. Also, please well defined.

Merge this PR and then create a new one that defines the special scopes?

//Axel

ps: I am not too happy that this API returns each attribute that is part of an address separately.
Both OIDC and eKYC-Identity Assurance have a scope "address" that returns the address as a JSON object.
It is then also easier to have scopes for billing address and fixed-line-address in the future.
See OIDC standard claims

End-User's preferred postal address. The value of the address member is a JSON [RFC8259] structure containing some or all of the members defined in Section 5.1.1.
Changing that would be another PR...

Hi Camara people, Just a couple of thoughts for you to add into your decision making...
The PAR spec https://datatracker.ietf.org/doc/html/rfc9126 solves a few issues with the authorization endpoint. You should really consider it for multiple reasons - 1 it removes the browser url size issue and it means that the request parameters do not need to pass via the browser which mitigates some security risks (particularly related to request integrity).
I also think that the claims request parameter is pretty useful as it may allow the data consumer to request less than they are technically allowed (so even better from a GDPR perspective) without affecting the possibility of the provider having policies that restrict what they will share with any given consumer.
One potential issue with the claims request parameter is that there are only elements within it that cater for id_token or userinfo endpoints but it is readily extended if you were to wish to use it in relation to your kyc-fill-in API.
MarkH