Alignment with Guidelines and linting rules for OWASP API Security Top 10

[GillesInnov35]

Possible evolution

(New guidelines for OWASP API Security)

Following camaraproject/Commonalities#596 the maxLength requirement must be applied to all string properties regardless of whether format or pattern is also specified.

[GillesInnov35]

From what I understand from new Commonalities requirements, it MUST be applied to all CAMARA API. That means maxLength value for all string fields should be estimated/calculated. If it's right, same should be done for the others KYC API

[GillesInnov35]

opening the discussion, find my proposal - to be updated

Field	maxLength	Why
x-correlator	256	pattern: ^[a-zA-Z0-9-_:;./<>{}]{0,256}$ & Commonalities 8.0.0
phoneNumber	16	pattern: '^+[1-9][0-9]{4,14}$' & Commonalities 8.0.0
idDocument	50
idDocumentType	50	enum: [passport, national_id_card, residence_permit, diplomatic_id, driver_licence, social_security_id, other]
name	256	Large compatibilité internationale
nameKanaHankaku
nameKanaZenkaku
firstName	100	international compatibility
familyName	150	international compatibility
middleName	100	international compatibility
streetName	150	international compatibility
streetNumber	20	international compatibility
address	256	international format compatibility
houseNumberExtension	20	international format compatibility
region	100	international compatibility
locality	100	international compatibility
country	2 (ISO 3166‑1 alpha‑2)	Standard
postalCode	20	international compatibility
email	254	standard
countryOfBirth	2 (ISO 3166‑1 alpha‑2)	Standard
gender	6	enumeration
nationality	2 (ISO 3166‑1 alpha‑2)	Standard

[GillesInnov35]

@ToshiWakayama-KDDI , @fernandopradocabrillo , @albertoramosmonagas , WDYT ? I guess you've also your feedback. Thanks

[ToshiWakayama-KDDI]

Thanks, @GillesInnov35 .

On the KDDI side, we already have a similar length constraint (like maxLength) for our kyc-match product. I would like to check with our product team first to see how this affects us.

Best regards,

[GillesInnov35]

corresponding PR #72

[ToshiWakayama-KDDI]

Hi @GillesInnov35 , Hi all,

Thanks, @GillesInnov35 , for the PR.

I have a fundamental question on this topic.

Although I haven't fully reviewed the related discussions in Commonalties yet, my understanding is that setting a maxLength does not mean each MNO's backend database must be expanded to match that length. Since each operator has its own backend database, the maximum supported length naturally varies by operator.

Assuming this is correct, if the maxLength defined in the API is smaller than the maximum length supported by a paticular operator's database, it will cause issues for that operator. Therefore, the maxLength for each attribute should be set to a value larger than the maximum limit of any operator.

I hope this makes sense, and I look forward to your thoughts.

BR

[GillesInnov35]

@ToshiWakayama-KDDI , agreed

Therefore, the maxLength for each attribute should be set to a value larger than the maximum limit of any operator.

[ToshiWakayama-KDDI]

Thanks @GillesInnov35 ,

We have another question for clarification.

My understanding is that the maxLength of a string attribute refers to the maximum number of characters, rather than the byte size. Is this correct?

The reason I am asking this is that CAMARA uses the UTF-8 encoding. In UTF-8, characters can be represented by 1 to 4 bytes, making it difficult to enforce a strict byte-size limit for string attributes.

I would appreciate your confirmation on this.

Best regards,

[GillesInnov35]

@ToshiWakayama-KDDI , as I said during today's meeting it refers only to the number of characters.