IdMatch is a method of determining if a person presented by a System of Record is already known to the Identity Management System.
A demonstration version of the PostgreSQL-based ID match engine is available to anyone who wishes to experiment with it. This engine implements the CIFER ID Match Strawman API.
The API endpoint is https://idmatch.testbed.tier.internet2.edu/match-poc
Access is via Basic Auth over https. Credentials will be assigned to a "System of Record" for use in making requests.
The match engine is preloaded with 150,000 fake records, which you can download here if you wish to craft queries against them. These records are all loaded via the "test" System of Record.
The match engine (as configured for this demo) supports the following attributes (along with their API labels):
identifiers/identifier
of type national
, use 000-00-0000
or other appropriate national ID format)names/given
of type official
)names/family
of type official
)dateOfBirth
, use YYYYMMDD
format)emailAddresses/mail
of type personal
)The following rules are configured for this demo:
If any of these rules finds exactly one match, processing stops and that match is returned. If any rule finds more than one match, the response is automatically switched to a potential match.
Canonical rules must match each attribute exactly.
DO NOT SEND REAL DATA TO THIS SERVICE. Send fake data only. |
The full specification for sending queries is available in the CIFER ID Match Strawman API, however you will most likely want to send one of two requests.
Corresponds to the Reference Identifier Request.
SOR
with the SOR label you were assigned.SORID
with your internal identifier for this record.Returns:
PUT https://idmatch.testbed.tier.internet2.edu/match-poc/v1/people/SOR/SORID { "sorAttributes": { "names":[ { "given":"Pat", "family":"Lee", "type":"official" } ], "dateOfBirth":"1983-03-18", "identifiers":[ { "type":"national", "identifier":"012-99-5678" } ] } } |
Corresponds to the Reference Identifier Request (Search Only). Parameters are as for the Search/Update request, above.
Returns:
POST https://idmatch.testbed.tier.internet2.edu/match-poc/v1/people/SOR/SORID { ... as above ... } |
The demonstration server is a stock testbed VM running CentOS 7 and a local version of PostgreSQL 9. No optimizations have been made to the hardware, virtual machine, or database configuration other than the creation of indexes as describe the installation instructions.
This table shows the processing time for the initial data load. Note that in order for a new record to be added, all defined match rules must execute (and return no matches) – that is the worst possible performance for a query.
Load # | Records | Total Time (sec) | Average Time Per Record (ms) | Non-Exact Results |
---|---|---|---|---|
1 | 10000 | 561 | 56.1 | 0 |
2 | 40000 | 2601 | 65.0 | 3 |
3 | 50000 | 6079 | 121.6 | 335 |
4 | 50000 | 11874 | 237.5 (max ~1187) | 532 |
Performance numbers reflect queries performed against localhost. Remote queries will take longer due to network latency.
The increasing average request time is likely due to the increased expense of updating the database indexes as the data set gets larger.