[FEATURE]: Consolidate component identifiers under `identifiers`

[stevespringett]

Problem

CycloneDX 1.x exposes component identifiers as a fixed set of top-level properties: purl, cpe, swid, swhid, omniborId. The model has three limitations 2.0 should address.

1. No structural place for the asserting party. Each identifier is a positive identity claim, but the claim and the party making it do not sit together. Producers, suppliers, distributors, integrators, and asset owners all assign identifiers, and consumers need to know which party stands behind each value.
2. A component can carry multiple, simultaneously valid assertions from different parties. A manufacturer asserts an MPN and a GTIN. A distributor asserts their own part number and SKU for the same part. An owner assigns an asset tag. The current model cannot express these as distinct, attributed claims without overloading or external attribution.
3. Identifier vocabulary is fixed and software-centric. Hardware needs MPN, serial number, GTIN, UDI, FCC ID, MAC address, and more. Other domains will need others. Adding each as a new top-level property does not scale; pushing them into properties makes them untyped.

The model also conflates assertion of identity with evidence of identity. Both currently land in the same property; only evidence.identity carries the inferred-versus-asserted distinction.

Proposal

Replace the five top-level identifier properties with a single identifiers array. Each entry binds a set of identity claims to the asserting party in the same object.

"identifiers": [
  {
    "party": "acme-inc",
    "identities": [
      { "scheme": "mpn",  "value": "ACME-EG-1000-RC" },
      { "scheme": "gtin", "value": "00614141999996" }
    ]
  },
  {
    "party": "globex-distribution",
    "identities": [
      { "scheme": "part-number", "value": "GLBX-EG-2026-001" },
      { "scheme": "sku",         "value": "GLBX-RESELL-EG1000" }
    ]
  }
]

The same structure carries software identifiers (purl, cpe, swid, swhid, omniborid), hardware identifiers, and any future scheme without new top-level properties.

Assertion versus evidence

identifiers carries asserted identity. evidence.identity carries inferred or collected identity, with confidence and methods. Both now share a common scheme, so an assertion and supporting evidence are directly comparable.

SWID document reference

swid as an identifier scheme is the tagId. A new swid-tag external reference type is added for the full ISO/IEC 19770-2 SoftwareIdentity XML document.

Breaking changes

Removed: top-level purl, cpe, swid, swhid, omniborId on component; the inline swid definition. Each removed value migrates to a single identity entry under an identifiers group naming the asserting party.

[schlenk]

It would be a good addition to explicitly mention if duplicate identifiers for different asserting parties are allowed and how those should be treated semantically. The proposal assumes it, but doesn't explicitly mention it.

For example a CPE identifier that is very broad for one party, with many '*' while another partys CPE pins it down to a very specific piece on a certain operating system. Same for PURLs, which might be enriched with repository details or similar.