[FEATURE REQUEST] provide html error code 428 PRECONDITION REQUIRED in case a booking is made on behalf a blocked user

[matt-wirtz]

Is your feature request related to a problem? Please describe.

When MP acts as a broker it might happen that the MP tries to book on behalf of a user which is blocked by the TO. Since the MP is not aware of the fact that the TO has blocked that user. In such situation a 428 PRECONDITION REQUIRED html error code should be returned including a 3209 TOMP error code.

Urgency

Major: if only a generic error is returned by the TO it's not possible for the MP to understand the blocked user situation

Describe the solution you'd like

A possible 428 PRECONDITION REQUIRED response should be added to POST /booking. The TOMP error code 3209 should be added to clearly state what the issue is.

[itziweb]

Question: How does the TO recognize that it is a user who has been blocked by this TO?
On another MP, the user can have different properties and will difinitly have a different id. For privacy reasons, a centralized or standardized management of user identities should be avoided.

This is definitely a hard use case.

[matt-wirtz]

Good question. I think it depends on the architecture/data structure of the TO system:

One option here is that the TO's system architecture doesn't separate it's customer data into different groups. All customers belong to a single set of data independent if they signed up directly with the TO or via an MP. In this case the TO could use verified data points like ID card number, birthday & birthplace to identify same individuals even if they signed up with different MPs. Using an external ID provider would make this easier. If the TO blocks one customer this customer will be blocked even if he has signed up via multiple MPs.

Another option is that the TO's system architecture uses different user pools e.g. for each MP one dedicated user pool. Then the MP most likely will not be able to link the customers signed up via multiple MPs to the same individual. If the TO then blocks one customer only the customer signed up via this MP will be blocked.

So I think this topic is more related to the TO's system architecture than to the TOMP-API.