Device Identifier Meeting Minutes 2023-11-17

Attendees & Representation

Attendee	Company

Current "work in progress" version can be found here
Outstanding issues:
- Security scheme definition, awaiting resolution of Commonalities PR#57
- Defined scopes and meanings, being discussed in Issue #30
  - Please contribute to this issue if you have a view
Comments raised during meeting:
- API currently does not return any indication of age of information or status of device (e.g. connected / not-connected)
  - ACTION: Eric to open discussion on this (done - see here)
- IMEI / IMEISV is sensitivity personal information. Can an alternative device identifier be returned that identifies the device to the API consumer, but cannot be used by any third-party to identify the device?
  - ACTION: Eric to open discussion on this (done - see here)

See API Proposal submission here
No representative of MTN attended the meeting
- ACTION: Eric to contact MTN to determine their intensions to drive this API
API definition
- Input should be IMEI
  - Should this be separately IMEI and IMEISV, or a single IMEI property with API implementor to determine which it is?
    - ACTION: Eric to open discussion on this (done - see here)
- Outputs should be "fraud markers"
  - But which fraud markers to allow?
  - Should fraud markers be limited to those that can be obtained from EIR, or could it be extended to other markers in, say, CRM systems?
  - For a given set of defined fraud markers, is an API implementor obliged to support all of these, or could some markers not be used by a specific API implementor?
  - ACTION: Kevin to start discussion on using EIR solely to determine available fraud markers (done - see here)
- Relationship with device fields in KYC Match needs to be considered