Problem description
Some ATP scenarios in the Device Identifier repository appear to be inconsistent with the API semantics for 2-legged vs 3-legged flows and introduce ambiguity for implementers.
In particular:
- The scenarios
@DeviceIdentifier_retrieveIdentifier_422.4_device_token_mismatch, @DeviceIdentifier_retrievePPID_422.4_device_token_mismatch, and @DeviceIdentifier_retrieveType_422.4_device_token_mismatch do not seem to provide meaningful additional coverage. In 3-legged flows, the device object must not be provided, so the expected outcome should already be 422 UNNECESSARY_IDENTIFIER, regardless of whether the supplied device matches or mismatches the token subject.
- Several ATP comments use the word "typically" to indicate whether a scenario applies to 2-legged or 3-legged tokens. This wording is too weak for behavior that is effectively mandatory and may create confusion for implementers.
- The scenario
@DeviceIdentifier_retrievePPID_422.1_device_identifiers_unsupported is not clearly marked as a 2-legged-only case, although unsupported device identifiers are only relevant when the request depends on an explicit device selector.
- There may also be some partial overlap in certain schema-validation scenarios, although that should only be addressed if a broader cleanup of negative validation coverage is planned.
Expected action
- Remove or merge the three
422.4_device_token_mismatch scenarios into the existing UNNECESSARY_IDENTIFIER coverage.
- Replace "typically" wording with explicit applicability wording for 2-legged and 3-legged scenarios.
- Mark
@DeviceIdentifier_retrievePPID_422.1_device_identifiers_unsupported as a 2-legged-only scenario, or clarify this explicitly in the scenario comments.
- Optionally review overlapping schema-validation scenarios only if a broader ATP refactor is considered worthwhile.
Additional context
Relevant API semantics:
- With a 2-legged token, the subject must be identified through the
device object.
- With a 3-legged token, the
device object must not be included.
- If a 3-legged token is used and the
device object is still provided, the expected error is 422 UNNECESSARY_IDENTIFIER.
This issue is intended as a targeted ATP consistency cleanup, not as a broader restructuring of naming conventions, shared scenario layout, or legacy test asset conventions.
Problem description
Some ATP scenarios in the Device Identifier repository appear to be inconsistent with the API semantics for 2-legged vs 3-legged flows and introduce ambiguity for implementers.
In particular:
@DeviceIdentifier_retrieveIdentifier_422.4_device_token_mismatch,@DeviceIdentifier_retrievePPID_422.4_device_token_mismatch, and@DeviceIdentifier_retrieveType_422.4_device_token_mismatchdo not seem to provide meaningful additional coverage. In 3-legged flows, thedeviceobject must not be provided, so the expected outcome should already be422 UNNECESSARY_IDENTIFIER, regardless of whether the supplied device matches or mismatches the token subject.@DeviceIdentifier_retrievePPID_422.1_device_identifiers_unsupportedis not clearly marked as a 2-legged-only case, although unsupported device identifiers are only relevant when the request depends on an explicitdeviceselector.Expected action
422.4_device_token_mismatchscenarios into the existingUNNECESSARY_IDENTIFIERcoverage.@DeviceIdentifier_retrievePPID_422.1_device_identifiers_unsupportedas a 2-legged-only scenario, or clarify this explicitly in the scenario comments.Additional context
Relevant API semantics:
deviceobject.deviceobject must not be included.deviceobject is still provided, the expected error is422 UNNECESSARY_IDENTIFIER.This issue is intended as a targeted ATP consistency cleanup, not as a broader restructuring of naming conventions, shared scenario layout, or legacy test asset conventions.