CAMARA and especially KYC-Fill-in use OIDC authorization code flow or CIBA when it come to personal data.

3-legged access token: Access tokens are created by the authorization server to be used by the client at the resource server. If the authorization server authenticates the user and potentially asks for their consent for the API access, then the acccess token is called a 3-legged access token, because of the three involved parties: user (the resource owner), authorization server (operator, i.e. service provider), and the client (third-party application). Typically 3-legged access tokens are created in CAMARA through OIDC Authorization Code flow or CIBA.

OIDC defines standard claims and how to request them. KYC-Fill-in can use these OIDC standard claims to request personal user data.
The API Consumer requests exactly the attributes/claims that are needed for their purpose.

We (this group) could extend the list of "standard" claims and add claims mentioned in KYC Fill-in yaml e.g. idDocument.

I think this is important for data minimization under e.g. GDPR Art. 5 (c) and ICO.

@AxelNennker Hi Axel ,

Can you please explain what you mean by the link between standard claims in OIDC and data minimization?

I think data minimization has more to do what use case you have and whether the data is really needed for the use case or not. Not so much which standards are being followed describing claims.

The current fill-in API does return everything the API provider has in there database. That response is not minimized.
There is currently no way for the API consumer to request the data they need in that moment they send the request.
Maybe the API consumer is allowed at onboarding time to request 5 attributes but in the moment they send the request they need just three?!

I suggest that we add all the fields/properties/attributes/claims from the response as scopes to the request definition.
That way the API consumer can add those to the authorization request and get the data-minimized attributes they need.

@AxelNennker I see the issue now. Scopes may be a solution for that, but don't you run the risk that the scope string may become very complex / long ?

@AxelNennker A simpler solution may be to specify the fields that are needed in the request body. That allows the answer to be minimized as well.

However, in case of a consent use case, you still need to acquire consent for all possible data fields that are allowed for that API Consumer. If you choose to handle it through scopes, you can also tailor the consent question, so that you only need to ask the consent for data that is actually asked at that time.

OIDC standardizes some standard claims and they are requested as scope values. I would go the same way with Fill-In.

hi, according to what has been designed in the KYC APIs, phoneNumber might be added as optionnal to the swagger design with the same rules of management and usage. WDYT

Gilles

@AxelNennker I see the issue now. Scopes may be a solution for that, but don't you run the risk that the scope string may become very complex / long ?

define "complex / long"... the scope value might be long but for one API consumer it is probably always the same.

regarding "long":
From OIDC 3.1.2.1

Authorization Servers MUST support the use of the HTTP GET and POST methods defined in RFC 7231 [RFC7231] at the Authorization Endpoint. Clients MAY use the HTTP GET or POST methods to send the Authorization Request to the Authorization Server. If using the HTTP GET method, the request parameters are serialized using URI Query String Serialization, per Section 13.1. If using the HTTP POST method, the request parameters are serialized using Form Serialization, per Section 13.2.

Should URL length become a concern the POST is always there.

regarding "complex":
I think a fixed string of mandatory scopes is simple. At API consumer onboarding-time a list of scopes is fixed.
(I am not a fan of optional claims. Those lead to complex UI and privacy discussions)

@AxelNennker A simpler solution may be to specify the fields that are needed in the request body. That allows the answer to be minimized as well.

However, in case of a consent use case, you still need to acquire consent for all possible data fields that are allowed for that API Consumer. If you choose to handle it through scopes, you can also tailor the consent question, so that you only need to ask the consent for data that is actually asked at that time.

Putting the OIDC request parameters in a POST request puts the fields in the request body.

The API consumer could tailor the consent question but ultimately consent management is done be the operator.
I, personally, would collect consent exactly for the scopes that are needed.

OIDC defines that the API consumer can always ask that the API producer enters the consent collection flow by issuing an OIDC request with `prompt=consent&scope="openid dpv:... kyc-1 kyc-2...".
See the Consent URL discussion.

If e.g. the API consumer's the mobile app knows the MSISDN of the device, the mobile app can add login_hint=tel:MSISDN whether on-net or off-net.
The operator starts the consent collection anyway and can use the login_hint as the (modifiable) username when the operator asks for user authentication. The user can then grant consent for that API for that MSISDN or for all MSISDNs or what ever - because consent collection is done be the operator and the operator can implement whatever privacy, transparency or consent user experience they see fit.

I would not limit KYC to "the device currently being used by the end-user" because we are breaking that paradigm with CIBA already.

@AxelNennker Hi Axel, I think that for both KYC Match and KYC Fill-In a method is required to define which attributes are allowed. In both API's, you can have use cases where not all attributes may be collected according to the GDPR. For example, verifying an ID document number may not be allowed when you just need to verify someone's address.

However, we should also try to keep matters simple for developers. How about the folllowing:

The maximum set of attributes an API Consumer is allowed to ask is defined at onboarding.

When the API's are being consumed, the API Consumer should be able to ask for either all the attributes he is allowed (as defined at onboarding), or a subset of specific attributes (in case he needs to ask at that point in the flow for less data).

Would this be an option ?

hi, according to what has been designed in the KYC APIs, phoneNumber might be added as optionnal to the swagger design with the same rules of management and usage. WDYT

Gilles

I think this may be a more business decision whether you want to include the phone number with KYC Fill In . Please note there is also a Number Verification version by which you can share the phonenumber.

And isn't the phone number already included in the current version?

hi, according to what has been designed in the KYC APIs, phoneNumber might be added as optionnal to the swagger design with the same rules of management and usage. WDYT
Gilles

I think this may be a more business decision whether you want to include the phone number with KYC Fill In . Please note there is also a Number Verification version by which you can share the phonenumber.

And isn't the phone number already included in the current version?

Thanks @GillesInnov35 , @HuubAppelboom ,

Our original proposal about a year ago included the phoneNumber, so, we would be happy to support this idea.

Best regards,
Toshi

hi @HuubAppelboom, as it is explained for Tenure, phone number (optionnal) placed in the body request could be used for 2-Legged auth. (API tests for example).
BR
Gilles

@AxelNennker A simpler solution may be to specify the fields that are needed in the request body. That allows the answer to be minimized as well.

However, in case of a consent use case, you still need to acquire consent for all possible data fields that are allowed for that API Consumer. If you choose to handle it through scopes, you can also tailor the consent question, so that you only need to ask the consent for data that is actually asked at that time.

Putting the OIDC request parameters in a POST request puts the fields in the request body.
By using scopes every off-the-shelf OpenId Provider can handle them.
Putting the attributes in the body would be proprietary.

The API consumer could tailor the consent question but ultimately consent management is done be the operator.
I, personally, would collect consent exactly for the scopes that are needed.

OIDC defines that the API consumer can always ask that the API producer enters the consent collection flow by issuing an OIDC request with `prompt=consent&scope="openid dpv:... kyc-1 kyc-2...".
See the Consent URL discussion.

If e.g. the API consumer's the mobile app knows the MSISDN of the device, the mobile app can add login_hint=tel:MSISDN whether on-net or off-net.
The operator starts the consent collection anyway and can use the login_hint as the (modifiable) username when the operator asks for user authentication. The user can then grant consent for that API for that MSISDN or for all MSISDNs or what ever - because consent collection is done be the operator and the operator can implement whatever privacy, transparency or consent user experience they see fit.