Digital credential infrastructure · Aotearoa New Zealand

Trusted evidence. Reusable by design.

DiligenceID gives organisations the infrastructure to issue, verify and govern digital credentials through APIs, wallets and existing identity systems.

Prove identity, relationships and organisational authority without rebuilding the same evidence checks inside every service.

For issuers, verifiers and organisations that rely on trusted evidence. Get started opens the separate DiligenceID platform application.

DiligenceID sign-in interface showing issuance, verification, credentials and audit as protected trust operations
Protected platform entry

Why change

Stop rebuilding the same trust decision.

People repeatedly upload and re-enter evidence. Organisations repeatedly collect, check, retain and reconcile it across disconnected systems.

TODAY

Evidence starts over in every service

  • People upload documents and prove the same facts again
  • Organisations retain copies and repeat verification work
  • Accounts rarely explain organisational authority
  • Each integration rebuilds trust and lifecycle logic
WITH DILIGENCEID

Trusted evidence can move with purpose

  • Authoritative issuers create reusable credentials
  • Holders present defined evidence to a verifier
  • Verification includes issuer, integrity and status
  • APIs return evidence to the existing decision journey

DiligenceID is not a universal central identity database. Credential content stays in the holder's wallet or the issuing organisation's own environment; DiligenceID governs the issuance, verification and status of that evidence rather than aggregating it into one central store.

The product

A governed layer for reusable trust.

DiligenceID connects issuers, holders, wallets, verifiers and business systems across the complete credential lifecycle.

ISSUE

Authoritative credentials

Support approved issuers, credential definitions and controlled issuance from trusted source information.

HOLD + PRESENT

Holder-controlled evidence

Give people a supported wallet journey to receive and present the evidence requested for a clear purpose.

VERIFY + DECIDE

Evidence into action

Validate issuer, integrity, claims and status, then pass the result into the relying service’s own policy. Checking a cryptographic signature and current status is faster than manual document inspection and back-and-forth requests for further proof.

Operational proof

Issuer readiness is visible—not assumed.

DiligenceID separates lifecycle, signing, trust and protocol readiness so an operator can see whether an issuer is prepared for a credential journey.

Issuer directory showing lifecycle, trust, signing and protocol readiness
Issuer configuration and readiness

Product surfaces

One credential system. Clear operational boundaries.

Platform operations, holder experience, enterprise integrations and trust governance remain distinct while working as one journey.

DiligenceID product surfacesThe DiligenceID platform connects issuer and administration, verification, APIs and webhooks with the Diligence Wallet, enterprise integrations and a shared trust layer.HOLDERDiligence WalletHOLDREVIEWPRESENTPRODUCT COREDiligenceID PlatformISSUER / ADMINVERIFICATIONAPIs / WEBHOOKSINTEGRATIONSExisting environmentMICROSOFT VERIFIED IDIDENTITY + APPLICATIONSBUSINESS WORKFLOWSTRUST CONTROLSGovern the complete journeySTATUSISSUER TRUSTAUTHORITYAUDITDiligenceID product surfacesThe platform, wallet, integrations and trust controls form four connected but distinct product surfaces.PRODUCT COREDiligenceID PlatformISSUER / ADMIN · VERIFICATIONAPIs / WEBHOOKSHOLDERDiligence WalletHOLD · REVIEW · PRESENTINTEGRATIONSExisting environmentVERIFIED ID · IDENTITY SYSTEMSAPPLICATIONS · WORKFLOWSTRUST CONTROLSGovern the journeySTATUS · ISSUER TRUSTAUTHORITY · AUDIT
Platform, wallet, integrations and trust controls remain distinct while contributing to one governed credential journey.

Credential lifecycle

Design beyond the QR code.

A trustworthy credential service needs ownership from initial policy through status, expiry, revocation and operational evidence.

Complete credential lifecycleDesign, issue, hold, present, verify, decide, monitor status, revoke or expire, and retain proportionate audit evidence. Status is an ongoing control throughout the usable credential lifecycle.01DESIGNClaims · policy · trust02ISSUEAuthoritative evidence03HOLDWallet receives04PRESENTPurpose-led request05VERIFYIntegrity · issuer · state06DECIDERelying policy07STATUSOngoing control08REVOKE / EXPIREAuthority changes09AUDITOperational evidenceComplete credential lifecycleDesign, issue, hold, present, verify, decide, monitor status, revoke or expire, and retain proportionate audit evidence. Status is an ongoing control throughout the usable credential lifecycle.01DESIGNClaims · policy · trust02ISSUEAuthoritative evidence03HOLDWallet receives04PRESENTPurpose-led request05VERIFYIntegrity · issuer · state06DECIDERelying policy07STATUSOngoing control08REVOKE / EXPIREAuthority changes09AUDITOperational evidence
Status remains an ongoing control: a verifier checks current state when evidence is presented, while expiry, revocation and audit close the operational lifecycle.

What can be proven

Evidence shaped around the transaction.

A credential can represent a trusted fact, relationship or authority—not merely a digital copy of an identity document.

Credential content and assurance must be defined by an authoritative issuer and accepted by a relying service for a specific purpose.

Identity attributesEmploymentQualificationsLicencesPermissionsCertificationsMembershipsEligibilityOrganisational authorityDelegated authority

A transparent exchange

Issuer. Holder. Verifier. A decision with clear boundaries.

The holder sees who is asking, what evidence is required and why before choosing whether to present it.

How trusted evidence movesAn issuer creates a credential, a holder controls and presents it, a verifier checks issuer integrity and current status, and a relying service makes a business decision. Status and revocation remain connected controls rather than a central store of credential data.ISSUERCreates evidenceCREDENTIALSigned claimsHOLDERControls walletPRESENTATIONPurpose-led proofVERIFIERChecks trust + stateDECISIONRelying policySTATUS / REVOCATIONOngoing issuer control checked by the verifierHow trusted evidence movesIssuer, credential, holder, presentation, verifier and decision form the main flow. Status and revocation connect credential state to verification.ISSUERCreates evidenceCREDENTIALSigned claimsHOLDERControls walletPRESENTATIONPurpose-led proofVERIFIERChecks trust + stateDECISIONRelying policySTATUS+REVOKEONGOING
The holder presents defined evidence; the verifier checks issuer, integrity and current status; the relying service owns the decision.

Organisational identity

Verify the authority behind the action—not only the person.

A sign-in can identify an account. DiligenceID can add evidence of the organisation represented, the current relationship, and the defined authority to act.

How organisational authority becomes verified evidenceIdentity evidence connects a person to an organisation, current role or relationship, scoped authority or delegation, and a verified action decided by the relying service.01PERSONIdentity evidence02ORGANISATIONEntity represented03ROLE / RELATIONSHIPCurrent connection04AUTHORITY / DELEGATIONScope · purpose · time05VERIFIED ACTIONRelying policy decidesHow organisational authority becomes verified evidenceIdentity evidence connects a person to an organisation, current role or relationship, scoped authority or delegation, and a verified action decided by the relying service.01PERSONIdentity evidence02ORGANISATIONEntity represented03ROLE / RELATIONSHIPCurrent connection04AUTHORITY / DELEGATIONScope · purpose · time05VERIFIED ACTIONRelying policy decides
Identity, relationship and authority remain separate evidence. Verification informs the action; the relying service owns the decision.

Organisation context

Authority begins with a governed organisation.

The platform keeps organisation context, issuer relationships and operational state visible before evidence is issued or relied upon.

Organisation management interface showing organisation status and issuer relationships
Organisation management

Each claim still needs an authoritative issuer and a relying-party policy. Verification supplies evidence; the relying service remains responsible for the final decision. Governance over who may then act on that verified evidence is a Delegance concern.

Identity and evidence

DiligenceID complements IAM. It does not replace sign-in.

AUTHENTICATION + ACCESS

Can this person access this system?

Microsoft Entra ID, CIAM, MFA and Conditional Access establish accounts, sessions and access policy.

CREDENTIALS + EVIDENCE

What trusted fact or authority can they prove?

DiligenceID carries evidence from an authoritative issuer into an application, portal, API or business process.

Microsoft identity

Build around Microsoft Entra Verified ID without confusing product boundaries.

DiligenceID can add journeys, trust policy, lifecycle, organisational authority and application integration around Microsoft’s managed verifiable credential capability.

How DiligenceID works with Microsoft Entra Verified IDMicrosoft Entra ID continues authentication and access. Microsoft Entra Verified ID provides supported credential capability. DiligenceID coordinates issuer, verification, status, organisational context and API workflows for an organisation or application.MICROSOFT IDENTITYMicrosoft Entra IDAUTHENTICATIONMFA · ACCESS POLICYMICROSOFT CREDENTIAL CAPABILITYEntra Verified IDSUPPORTED ISSUANCEPRESENTATIONMICROSOFT-MANAGED INFRASTRUCTUREORGANISATIONApps + workflowsISSUER SYSTEMSRELYING SERVICESDILIGENCEID PRODUCT LAYERIntegration and lifecycleISSUER WORKFLOW · VERIFICATION · STATUS / REVOCATION · AUTHORITY · APIsTRUSTED EVIDENCE IN CONTEXTMicrosoft and DiligenceID responsibility boundariesMicrosoft identity and credential capabilities connect to the DiligenceID product layer, which connects configured workflows to an organisation or application.MICROSOFT IDENTITYMicrosoft Entra IDAUTHENTICATION · MFA · ACCESSMICROSOFT CREDENTIAL CAPABILITYEntra Verified IDISSUANCE · PRESENTATIONDILIGENCEID PRODUCT LAYERIntegration + lifecycleISSUER · VERIFY · STATUSAUTHORITY · APIsORGANISATIONApplications + workflowsISSUER + RELYING SERVICESTRUSTED EVIDENCE
DiligenceID complements Microsoft identity services; it does not replace authentication, MFA or Conditional Access, and it does not own Microsoft infrastructure.

Use cases

Trusted evidence across the moments that matter.

01

Workforce

Carry evidence of employment, contractor status, role, training or permission across organisational boundaries.

02

Qualifications

Issue and verify qualifications, certifications and completed learning without relying on copied documents.

03

Licensing

Present current evidence of a licence or professional standing at the moment it matters.

04

Onboarding

Request defined evidence before creating or linking an account, while retaining only what the process needs.

Diligence Wallet

A place to hold and present supported credentials.

Diligence Wallet is the holder experience within the DiligenceID ecosystem. It gives people a way to receive, review and present supported credentials.

It is distinct from DiligenceID administration and issuer systems, and it is not Microsoft Authenticator. Where a use case relies on Microsoft Entra Verified ID, the selected Microsoft-supported wallet journey and current product requirements must be confirmed.

Three illustrative digital credentials for identity, workforce and partner evidence
Credential examples

Privacy by design

Request the proof needed—not a copy of everything.

Privacy depends on the complete journey: what is requested, what the holder sees, what is presented and what the relying organisation retains.

From source information to a minimum-evidence decisionAn authoritative source supports a trusted credential. A verifier requests evidence for a stated purpose, the holder presents the necessary supported information, and the relying service makes its decision.01SOURCE INFORMATIONAuthoritative record02TRUSTED CREDENTIALIssuer-provided claims03EVIDENCE REQUESTPurpose made clear04NECESSARY EVIDENCESupported minimisation05DECISIONRelying policyFrom source information to a minimum-evidence decisionAn authoritative source supports a trusted credential. A verifier requests evidence for a stated purpose, the holder presents the necessary supported information, and the relying service makes its decision.01SOURCE INFORMATIONAuthoritative record02TRUSTED CREDENTIALIssuer-provided claims03EVIDENCE REQUESTPurpose made clear04NECESSARY EVIDENCESupported minimisation05DECISIONRelying policy
Selective disclosure and claim minimisation depend on the chosen credential format, wallet and implementation; the request should still be designed around the minimum necessary evidence.
MINIMISE

Minimum necessary

Design requests around the claims required for the decision rather than collecting an entire record.

CONTROL

Holder choice

Make the verifier, purpose and requested evidence clear before the holder presents it.

DISCLOSE

Selective evidence

Use selective disclosure where the selected format and platform support it.

EVIDENCE

Auditable decisions

Keep operational evidence of the trust decision without retaining unnecessary credential content.

API-first integration

Put credentials inside the service people already use.

DiligenceID is not only an administration portal. APIs and webhook events connect issuance, verification and status to existing applications and authoritative systems.

How DiligenceID fits an existing application workflowAn application calls the DiligenceID API for supported issue, verify, status and revoke capabilities. Webhook events return operational changes to the existing business workflow.EXISTING PRODUCTApplicationUSER JOURNEYBUSINESS CONTEXTPRODUCT BOUNDARYDiligenceID APIISSUEVERIFYSTATUSREVOKEEXISTING PROCESSBusiness workflowDECISIONOPERATIONAL ACTIONWEBHOOK EVENTSApplication to DiligenceID API flowThe application, API capabilities, webhook events and business workflow are stacked in reading order.EXISTING PRODUCTApplicationUSER JOURNEY · CONTEXTPRODUCT BOUNDARYDiligenceID APIISSUEVERIFYSTATUSREVOKEWEBHOOK EVENTSEXISTING PROCESSBusiness workflowDECISION · ACTION
Capability names describe the integration model without publishing or implying undocumented endpoint paths.
01 / API

Issue through APIs

Connect credential issuance to authoritative source systems and existing workflows.

02 / API

Request verification

Start presentation journeys from an application and receive a verified outcome.

03 / API

Receive events

Use webhook events to coordinate asynchronous issuance and verification journeys.

04 / API

Manage status

Connect revocation and credential-state changes to business lifecycle events.

05 / API

Keep your interface

Embed the journey into existing portals and applications using thin integration layers.

06 / API

Choose boundaries

Keep business policy separate from wallet, credential format and platform-specific concerns where practical.

Thin clients, SDKs and plugins are part of the integration direction; public availability and supported capabilities will be documented as they are released.

Why DiligenceID

Infrastructure for trust that must work beyond one screen.

01

API-first

Connect credential operations to existing products and business workflows. Issuance, verification and status changes are called from your own application rather than a separate portal.

02

Standards-led

Use supported open credential and presentation patterns to reduce lock-in. Data models and protocols such as W3C Verifiable Credentials keep evidence portable across issuers and wallets.

03

Authority-aware

Represent relationships, roles and delegation—not identity alone. A credential can describe which organisation someone represents and what they are authorised to do, not just who they are.

04

Privacy-conscious

Request proportionate evidence and define retention deliberately. Verifiers ask for the specific claims a decision needs, and DiligenceID does not require holding a copy of the underlying record.

05

Microsoft-compatible

Complement Microsoft Entra environments and Verified ID where selected. Sign-in and access stay with Entra ID; DiligenceID adds the evidence layer around it.

06

New Zealand context

Built locally for organisations operating here, using global standards. Development and support are grounded in Aotearoa New Zealand privacy and regulatory expectations.

Built in Aotearoa

Digital trust grounded in New Zealand.

DiligenceID is developed by MAITS Limited in Wellington for organisations working through real identity, privacy and authority decisions in Aotearoa New Zealand.

The product builds on MAITS expertise across Microsoft identity, access governance and security architecture. It is intended to work with existing identity providers and evolving digital identity ecosystems—including public service, business, education, iwi and community contexts where the use case and trust model support it.

About MAITS Limited

Frequently asked questions

DiligenceID, in practical terms.

What is a digital credential?

A digital credential is evidence issued by an authoritative source that a holder can present for verification. It can represent a fact, relationship or authority—not simply another account.

Is DiligenceID an identity provider?

DiligenceID is credential infrastructure. It complements identity providers and access systems by carrying trusted evidence into the decisions made by applications and business processes.

Does DiligenceID replace Microsoft Entra ID?

No. Microsoft Entra ID continues to manage authentication, sessions and access. DiligenceID helps prove trusted facts or authority relevant to a transaction.

Who holds a credential?

A person can hold a supported credential in a wallet such as Diligence Wallet. The exact wallet and holder journey depend on the selected credential ecosystem and implementation.

Can credentials expire or be revoked?

Yes. Credential designs can include expiry and issuer-managed status or revocation. Verifiers must evaluate the appropriate current status when making a decision.

Can DiligenceID represent organisational authority?

Yes, where an authoritative issuer and relying policy support it. Evidence can describe which organisation a person represents, their relationship, and the scope or duration of delegated authority.

Put trusted evidence to work

Start with the evidence and the decision.

Bring the use case, authoritative source and relying decision. Open the platform or talk with the DiligenceID team about an integration path.