Use Case: Learner Credential Verification

Credential verification asks a different question from patient identification. The record is not in the national register - it is in a credentialing platform, like the school records behind DiCert MCP. What NIMC adds is the link between that record and a person: this certificate is real, and the person presenting it is the person it was issued to.

Those are two separate checks, and conflating them is the common design error.

This is a reference workflow applying the NIMC Identity API to the education template.

Two checks, not one

A solution that checks only authenticity confirms the paper and not the person. One that checks only identity confirms the person and not their claim. Most real fraud lives in the gap: a genuine certificate presented by someone else.

Assurance decision

Verification here is often remote - an applicant uploading documents, an employer checking a candidate in another state. Fingerprint capture assumes an attended setting with a reader; facial authentication with liveness, through NINAuth and NIMC verification partners, does not. For a remote channel it is usually the only workable high-assurance route, and NINAuth's token model has a further advantage: the holder authorises the check from their own device, so the verifying institution never receives the NIN at all.

Workflow: verifying a presented credential

1. Check the credential first. Query the credentialing platform for the certificate number. If it does not exist as issued, stop - no identity call is needed, and querying the national register about a person whose document is already invalid is an unnecessary lookup.
2. Obtain and record consent from the presenter for an identity check, with the purpose stated: confirming that this credential belongs to them.
3. Collect the asserted identity - the NIN, or the document number recorded on the credential.
4. Call the 1:1 method: searchByNIN where a NIN is asserted, or searchByDocumentNumber where the credential carries a registered document number.
5. Compare against the credential record: names and date of birth returned by eNVS against the names and date of birth the credentialing platform holds.
6. Escalate to biometric confirmation where the decision is irreversible - verifyFingerWithData against the asserted NIN in an attended setting, or facial authentication with liveness for a remote one - so that the person is confirmed, not merely the paperwork.
7. Retain only the verification outcome, a timestamp, and the credential reference. The demographic record is not stored against the application; it was consulted, not collected.
8. Record the audit event with identifiers hashed.

Comparing names is harder than it looks

The most common false rejection is not fraud - it is orthography. A name recorded at NIMC registration may differ from the same name on a school certificate issued years earlier by:

• Diacritics and tone marks - present in one record, stripped in the other.
• Name order - surname first on one document, last on the other.
• Middle and other names - middlename, othername, maidenname in demoData, often absent or abbreviated on a certificate.
• Previous names - psurname, pfirstname, pmiddlename exist precisely because names change, most often on marriage.
• Transliteration variants of the same name across Nigerian languages.

So: normalise before comparing - case, diacritics, punctuation, and name order - and compare against previous names as well as current ones. Treat a partial match as a review case, never an automatic rejection and never an automatic acceptance. Where the decision matters, a name mismatch escalates to biometric confirmation - fingerprint or face - or to human review, with the discrepancy recorded.

Failure paths

Credential not found

The certificate does not exist as issued. Report it as unverifiable, record the attempt, and follow the awarding body's escalation route. No identity call.

Identity does not match the credential

Do not conclude fraud. Re-check the normalisation, check previous names, then route to human review with the specific discrepancy shown - "date of birth differs", not "verification failed". A registry correction is a more common explanation than impersonation.

eNVS unreachable

Fail closed on the identity check. The credential-authenticity result still stands and can be reported on its own, clearly labelled as credential verified, identity not verified. Two checks means one can be reported without the other - provided the label says so.

What the AI layer sees

This is the case where the DiCert MCP pattern is most directly applicable: AI clients - a parent's assistant checking results, a teacher reviewing class performance, an administrator pulling verification statistics - call purpose-built tools over the credentialing platform, never the identity service.

The identity check runs in the integration layer and reaches the agent as a status. A model must never be able to trigger a national identity lookup, and must never hold one in context.

Pre-launch checklist

1. Both checks specified separately, with the two-result reporting format defined.
2. Credential check ordered first, so no identity lookup runs against an invalid document.
3. Name normalisation implemented and tested against real Nigerian name shapes - diacritics, order variation, previous names.
4. Partial-match threshold agreed with the awarding body, and the review route staffed.
5. Consent wording reviewed, including for minors, where a guardian's consent applies.
6. Retention confirmed: outcome and reference only, no demographic record stored.
7. NIN confirmed absent from logs, URLs, analytics, and any learner-facing view.
8. Agent tool surface reviewed: no path from the model to eNVS.