Thank you Matthias! We should split this issue into several issues:
A) Adding the placeOfBirth (and countryOfBirth?) is a good idea, but it makes me also wonder why it is there, in the requested booking data. Maybe only to determine the age? Probably not for identification reasons...
B) MP_USER_ID probably refers to the bookingRequest.customer.id. This is a required field by default. Or do I misinterpret this one?
C) Splitting NAME into FIRST_NAME and LAST_NAME: might be a good idea, but what to do with the other name fields? Like middle name, pre- and postfixes?
D) RATING: not possible, unless RATING is standardized and it is already needed in the planning, in the booking it is too late. We use the 'userGroups' in the planning request for the functionality you describe since it depends on the classification of the customer which legs (and assets) can be used. Nevertheless, it is still a bilateral agreement between MP and TO.

A) Yes, placeOfBirth is used in Germany for identification issues if the person needs to be identified by authorities. And yes, would make sense to have a countryOfBirth there too.
B) You are right. That's the bookingRequest.customer.id. No need for a change there.
C) Good question if middle name and pre- and postfixes should be included here too. There are part of the customer data. Maybe all attributes of the customer object should be valid values for conditionRequireBookingData. Except the mandatory fields like customer.id.
D) Yes, this functionality is covered up by userGroups. No need for changes here.

So B & D are obsolete. Should I then create separate change requests for A and C?

So the plan is to add these fields to the required booking data:

• placeOfBirth (and add to the customer object)
• countryOfBirth (and add to the customer object)
• firstName
• lastName
• middleName
• prefix
• postfix
• knownIdentifier
• knownIdentifierProvider

I double checked with the customer object and added all fields that seem applicable. If these fields would not be part of the required booking data TOs could not ensure that the data is provided. So they would be more or less useless to have them in the customer object.

I've made another (more flexible) setup in V2.0:

requiredFields:
type: array
description: an array containing labels that identify specific fields that are required in the booking process

all fields of the bookingRequest can become required, navigating with dots, square brackets and field names.

A few examples

from.address.station implies that the station reference is mandatory,

travelers[].age requires an age for each traveler,

travelers[0].licenseTypes[].licenseCode should expose the fact that the first traveler has a driver's license (f.i. D4, for a car)

or customer.email for the email address of the customer
maxItems: 50
items:
type: string

See the last comment, we don't need to make another ticket for v2.0. This functionality is already covered by default in v2.0 (but look at the v2.0 branche for more details)