Attendees & Representation
Attendee | Company |
---|---|
Eric Murray | Vodafone (chair) |
Sachin Kumar | Vodafone |
Alex Ferreira | Phronesis |
Sébastien Synold | Intersec |
Kevin Smith | Vodafone |
S, Vigneshwaran | Cognizant |
Matthew Hornsey | Phronesis |
Karthik Raj Rethinakumar | Cognizant |
Jain, Manish | Cognizant |
Huub Appelboom | KPN |
Rafal Artych | DT |
Agenda
- Review of Device Identifier API status
- Discussion on requirements for IMEI Fraud
...
- Current "work in progress" version can be found here
- Outstanding issues:
- 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)
- API currently does not return any indication of age of information or status of device (e.g. connected / not-connected)
Discussion on IMEI Fraud API
- 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)
- Should this be separately IMEI and IMEISV, or a single IMEI property with API implementor to determine which it is?
- 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
- Input should be IMEI
...