How to model overige partij identificatoren

[swrichards]

In 2.5.0, we introduced an enum for the various meta-attributes of a PartijIdentificator(#233) :

The thinking behind this was that we want no ambiguity around referring to a Partij using the formal identifiers in the various basisregistraties. In addition to this enum, we've added various forms of validation (for instance, ensuring that the various identifiers meet the relevant 11/13 checksums and so on) and uniqueness constraints (#267).

This has had the cumulative effect of making it quite difficult to register non formal identificatoren (anything which is not a primary value in the enum, that is, an "overig" identificator). For this reason, the possibility of adding overige identificatoren was removed (#351) until we can agree on a way to model these kinds of identificator properly. In #351 you can also read why the existing API spec does not properly support overige identificatoren.

The question is: should we support a mechanism for overige identificatoren and, if so, how?

Use-case

It would be good to have a few concrete examples of the kind of identificator we're talking about outside of the well-known formal ones. Are we talking about something like customer numbers which reference other CRMs? Non-official personal identificatoren (e.g. for asylum seekers who have not yet received a bsn?)

Options

Make PartijIdentificator objects polymorphic with a discriminator attribute

In this variant, we explicitly distinguish between official and overige identificator through a identificatorType = formeel | overig enum:

{
  "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
  "url": "http://example.com",
  "identificeerdePartij": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  },
  "identificatorType": "formeel",  // Determines shape of `PartijIdentificator
  "partijIdentificator": {
    "codeObjecttype": "natuurlijk_persoon",  // existing enum without 'overig'
    "codeSoortObjectId": "bsn",
    "objectId": "string",  // Validated according to current rules
    "codeRegister": "brp"
  },

  // I think we can keep this also for overige identificator
  "subIdentificatorVan": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  }
}

Then for overige identificatoren, we have essentially the same partijIdentificator nested object with less (and different) validation:

{
  "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
  "url": "http://example.com",
  "identificeerdePartij": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  },
  "identificatorType": "overig",  // Determines shape of `PartijIdentificator
  "partijIdentificator": {
    "codeObjecttype": "crm-klant",  // existing enum without 'overig'
    "codeSoortObjectId": "salesforce-id",  // Free form
    "objectId": "string",  // Free form, except that we'll enforce uniqueness per object type / soort object id/ code register
    "codeRegister": ""  // Maybe too much specificity for an overige identifier?
  },

  "subIdentificatorVan": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  }
}

We could also elect to make the overige variant simpler:

{
  "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
  "url": "http://example.com",
  "identificeerdePartij": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  },
  "identificatorType": "overig",  // Determines shape of `PartijIdentificator
  "partijIdentificator": {
    "codeSoortObjectId": "salesforce-id",  // Free form
    "objectId": "string",  // Unique with codeSoortObjectId
  },

  "subIdentificatorVan": {
    "uuid": "095be615-a8ad-4c33-8e9c-c7612fbf6c9f",
    "url": "http://example.com"
  }
}

TODO Other alternatives...