Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
Version 1
Current »
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
Review of Device Identifier API status
- 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)
Discussion on IMEI Fraud
- 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
AOB
- Next meeting to be held Friday 1st December 2023 @ 16:00 GMT
- One day, meetings will be held using the LFX Zoom service, but not yet