Complementary, not competing

Standards like Aliro, LEAF, and PKOC are popular topics of discussion. They are often discussed as if they compete for the same credential space in commercial access control. The NFID Foundation is newer and tends to come up only when the conversation turns to future standards for trusted identity on mobile. However, NFID is not meant to be a competitor to these other credential standards. It sits in a different layer.

The easiest way to see this is to visualize a stack. Credentials are issued at the bottom of the identity stack, under standards such as ISO 18013-5/7 (mDL), eIDAS 2.0 (EUDI), ICAO 9303 (Passport), and OpenID for Verifiable Credential Issuance. Wallets hold and present them, over the ISO proximity flow at a reader or OpenID for Verifiable Presentations online. Then the verifiers and access decision logic sit at the top. Underneath the identity stack is the access infrastructure the installed base already runs: panels, readers, and locks speaking OSDP and Wiegand. The NFID Foundation works in one layer between presentation and verification, which holds four things: the attestation envelope, the registry, the dual-path trust model, and the encoding profile. It does not issue credentials, specify a wallet, or define a transport.

Aliro is most closely related, so I will use it as an example. Aliro defines transport, the semantics of credential exchange, and how a reader and a credential establish trust within a session. NFID defines which credentials are eligible for trust in the first place, and how a verifier confirms that by resolving trust through the registry. Aliro therefore operates at the level of the individual reader session, while NFID operates at the level of ecosystem-wide trust, and the two sit in adjacent layers.

This matters, because a verifier consumes a credential and produces an attestation. That statement, that a presentation occurred, what was disclosed, and what it means for the access decision, needs a shared format. Without one, every implementation invents its own and interoperability fails. Each standard is doing layer-specific work, and doing it well, so this is not a criticism of Aliro. The NFID attestation envelope is built for the gaps between those layers.

The same relationship holds with the other standards NFID touches.

With ISO 18013-5 and 18013-7, the relationship is consumption. The Foundation’s work is anchored on the mDL and moves with the standard rather than forking it.

With OpenID for Verifiable Presentations and Issuance, the attestation envelope rides inside the presentation exchange, and NFID-aligned credentials are issued through the issuance protocol. The Foundation adds an access-specific payload to protocols it does not modify.

FIDO and WebAuthn handle authentication, which proves a party is who they claim to be. The Foundation’s framework handles authorization, meaning what that party may then do and how that permission is trusted. Where a deployment needs both, they work together. For eIDAS 2.0 and digital passports under ICAO 9303, the dual-path model treats each as an ecosystem-issued credential with its own trust infrastructure.

In my view, LEAF and PKOC fit the same way. They are credential standards that define what the credential is and how it proves itself to a reader. That is the deployment-issued side of the picture, and the whitepaper is clear that deployment-issued credentials, physical and mobile, remain the right choice for many environments. NFID is an addition to them rather than a replacement, since it addresses identity someone else has already issued and verified. A site can therefore run LEAF or PKOC credentials on its doors and still use NFID’s registry and envelope for the government-issued identities it also wants to accept.

The test for the Foundation is simple. Someone who builds to its specifications should be interoperable with implementations built to any of these standards.