Problem description
The Device Identifier API now includes a new POST /match-identifier endpoint, but there are currently no dedicated conformance test definitions covering its behaviour.
Without test coverage, the new endpoint may be interpreted differently by different implementers, especially in areas such as:
match=true vs match=false semantics- 2-legged vs 3-legged token handling
- supported identifier types (
IMEI, IMEISV, TAC)
- validation of identifier formats
- distinction between
400, 404, 422 and other error conditions
- privacy expectations in the response payload (i.e. no
IMEI / TAC / PPID returned)
This creates a risk of inconsistent implementations across providers.
Expected action
Add a new feature/test definition file for the /match-identifier endpoint, aligned with the style and structure used by the existing Device Identifier ATPs.
The new test definitions should cover at least:
- successful
match=true scenarios
- successful
match=false scenarios
- both 3-legged and 2-legged access token flows
- all supported
providedIdentifierType values:
- request validation errors (
400)
- authentication / authorization errors (
401, 403)
- subscription not found (
404)
- business / applicability errors (
422), including:
MISSING_IDENTIFIERUNNECESSARY_IDENTIFIERSERVICE_NOT_APPLICABLE
- response contract checks, including:
- mandatory
match
- mandatory
lastChecked
- echoed
x-correlator
- no exposure of
IMEI, IMEISV, TAC or PPID in the response body
Additional context
The intention is to ensure that the semantics of /match-identifier are implemented consistently across providers and remain aligned with the merged OpenAPI definition.
The tests should be modelled in the same way as the existing Device Identifier ATPs (for example retrieve-identifier, retrieve-type, and retrieve-ppid) and should reflect the final agreed behaviour of the new endpoint:
200 + match=true/false only for deterministic comparison results404 when the subscription cannot be resolved422 for business / applicability conditions- no persistent identifier returned in the response
Problem description
The Device Identifier API now includes a new
POST /match-identifierendpoint, but there are currently no dedicated conformance test definitions covering its behaviour.Without test coverage, the new endpoint may be interpreted differently by different implementers, especially in areas such as:
match=truevsmatch=falsesemanticsIMEI,IMEISV,TAC)400,404,422and other error conditionsIMEI/TAC/PPIDreturned)This creates a risk of inconsistent implementations across providers.
Expected action
Add a new feature/test definition file for the
/match-identifierendpoint, aligned with the style and structure used by the existing Device Identifier ATPs.The new test definitions should cover at least:
match=truescenariosmatch=falsescenariosprovidedIdentifierTypevalues:IMEIIMEISVTAC400)401,403)404)422), including:MISSING_IDENTIFIERUNNECESSARY_IDENTIFIERSERVICE_NOT_APPLICABLEmatchlastCheckedx-correlatorIMEI,IMEISV,TACorPPIDin the response bodyAdditional context
The intention is to ensure that the semantics of
/match-identifierare implemented consistently across providers and remain aligned with the merged OpenAPI definition.The tests should be modelled in the same way as the existing Device Identifier ATPs (for example
retrieve-identifier,retrieve-type, andretrieve-ppid) and should reflect the final agreed behaviour of the new endpoint:200 + match=true/falseonly for deterministic comparison results404when the subscription cannot be resolved422for business / applicability conditions