Clarify scope, data sources and accepted device identifiers (alignment with DeviceIdentifier) #32

Problem description

Some design questions are not yet answered in the API definition:

• Scope of "authenticity": the API returns the register status of an IMEI. Whether a device is genuine (e.g. allocated TAC, valid check digit, no duplicated IMEI) is not addressed. Either the scope is extended, or info.description states that authenticity is assessed via the register status only.
• Data sources: it is not stated whether the status comes from the operator's own EIR, a national register, or a global source such as the GSMA Device Registry ("any accessible database"). For resale and insurance use cases a device reported stolen in another network or country is relevant, and consumers cannot tell what an allowed or unknown answer covers. It is also not defined when 422 SERVICE_NOT_APPLICABLE applies.
• Device identifiers: only a 15-digit IMEI is accepted. The README refers to a "provided device identifier". The naming discussion in [Onboarding Tracker] DeviceAuthenticity APIBacklog#279 mentioned other identifiers, e.g. the PPID returned by DeviceIdentifier. The original proposal New API Proposal from Chenosis : IMEI Fraud Check API APIBacklog#63 mentioned the phone number for account-takeover use cases. DeviceIdentifier returns imei, imeisv and ppid; an IMEISV currently has to be truncated by the consumer, and a PPID cannot be used.
• Shared schemas: DeviceIdentifier defines Imei (with minLength: 15) and lastChecked (required, nullable, maxLength: 64). DeviceAuthenticity defines its own variants, with lastChecked optional.
• Access token: info.description does not state which access token types apply. With an IMEI in the request body the subject is not identified by the token (two-legged access token). If a device object is added, Design Guide Appendix A applies. The privacy aspects of checking arbitrary IMEIs are not described.

Possible evolution

Discuss within the DeviceIdentifier meeting and document in info.description:

• the intended scope of "authenticity" and the data sources
• the accepted identifiers (IMEI, IMEISV, PPID, device), reusing the DeviceIdentifier schemas where applicable
• the access token model and privacy considerations

Additional context

• DeviceIdentifier API definition
• To be resolved before the next release after r1.1.