Add conformance test definitions for the new /match-identifier endpoint

[usmanTheCoder]

What type of PR is this?

Added a test definition file.
Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

Added a new feature/test definition file for the /match-identifier endpoint, aligned with the style and structure used by the existing Device Identifier ATPs

Which issue(s) this PR fixes:

Issue: #159
It verifier that all three endpoints correctly retrieve physical mobile device identifiers (IMEI, TAC, PPID) for a given mobile subscriber, across success, authentication, authorization, and error scenarios.

[ALIIQBAL786]

@albertoramosmonagas Please feel free to suggestion any changes.

[albertoramosmonagas]

Hi! @usmanTheCoder, please on the "Which issue this PR fixes" include this issue #160 to be linked

[albertoramosmonagas]

Overall this ATP is looking very solid now, thanks a lot for the work on it! Most of the key points are already covered, and I think the current structure is in a good place. The only extra thing I would still consider adding, just to make the coverage a bit more complete, would be a few additional scenarios:

• 2-legged + phoneNumber + incorrect IMEI → 200 + match=false
• 2-legged + IPv4 + incorrect TAC → 200 + match=false
• 2-legged + multiple identifiers + incorrect IMEISV → 200 + match=false

These would complement the existing positive 2-legged scenarios and make the deterministic match=false behaviour more symmetrical across the main supported identification paths. Optionally, for consistency with the existing Device Identifier ATP style, we could also add:

• 400 INVALID_ARGUMENT when device is present but empty ({})

WDYT?

[albertoramosmonagas]

One small point: the testing assets define NAI1 / NAI2, but there is currently no scenario covering device.networkAccessIdentifier. Since NAI is one of the supported subscription identification schemes in the API, I’d suggest either:

• adding at least one success scenario using device.networkAccessIdentifier, or
• removing NAI1 / NAI2 from the testing assets if we don’t want to cover that path in this first ATP version.

Otherwise the assets suggest coverage that is not actually exercised by the feature file.

[albertoramosmonagas]

For @DeviceIdentifier_matchIdentifier_422.2_service_not_applicable, I think the scenario would be clearer if we explicitly stated how the subject is identified (e.g. 3-legged token, or 2-legged token + concrete device identifier).

At the moment, “the identified subject is otherwise valid” feels a bit abstract for an ATP scenario. Making the identification path explicit would make the test more deterministic for implementers.

[albertoramosmonagas]

The device-swap mismatch scenario is very useful. Would it also make sense to add the complementary positive scenario after device swap, i.e.:

• SIMCARD1 is now in DEVICE2
• query with the same subscription context
• providedIdentifier = IMEI2 / IMEISV2 / TAC2
• expect 200 + match=true

[albertoramosmonagas]

400.5_invalid_identifier_format currently covers wrong lengths, which is good. Would it be worth adding at least one example with non-numeric characters as well? Since the OAS patterns are digit-only (^[0-9]{...}$), that would give slightly better coverage of the intended validation behaviour.

[albertoramosmonagas]

Minor typo:

Suggested change

	Feature: Camara Mobile Device Identifer API, vwip - Operation: matchIdentifier
	Feature: CAMARA Mobile Device Identifier API, vwip - Operation: matchIdentifier