A trust framework for identity‑based physical access.
Governments now issue digital identity to a large and growing share of their populations. The NFID Foundation specifies how a door can trust it.
What’s missing isn’t identity. It’s the infrastructure to consume it.
A mobile driver’s license, a digital passport, a national ID: the holder has already been proofed by the issuer, bound to keys, and can present from a phone. The access ecosystem has lacked the layer that consumes that identity without the deployment issuing anything. The Foundation specifies that layer and publishes each specification as it completes the Foundation’s lifecycle.
Issued.
Governments have done the expensive work: proofing the person, binding the result to cryptographic keys, signing it, and putting it in the wallet on their phone.
Presentable.
ISO/IEC 18013-5 and OpenID for Verifiable Presentations let a holder present that identity to a verifier with cryptographic proof of who issued it and selective disclosure of what is shared.
Not yet consumable at the door.
No shared answer to which issuers and verifiers count, no shared format for what a verifier attests, no registry that resolves trust across credential types, and no operational properties a regulated site can sign off on. That is the Foundation’s scope.
Present. Resolve. Attest.
-
Present.
The holder presents a government-issued or ecosystem-issued credential from their wallet, over the ISO 18013-5 proximity flow at a reader or OpenID for Verifiable Presentations online. The deployment enrolled nobody and provisioned nothing. The issuer did that work once.
-
Resolve.
The verifier resolves trust through the Foundation’s registry: whether the issuer is eligible under the published rules for its credential category. The registry federates the trust sources issuers already operate. It does not replace them.
-
Attest.
The verifier produces a signed attestation envelope: that a presentation occurred, what was disclosed, against which credential, and what the verifier determined. The access system consumes the envelope. The access decision stays with the deployer.
The enterprise still decides who may enter. It no longer has to manufacture a credential to decide.
Four contributions, one layer.
All four are ratified by the working group. What ratified means here
Access attestation envelope
A presentation-time record, signed with COSE_Sign1 and encoded in deterministic CBOR, that binds to the presented credential’s own trust anchors. Not a credential, and not a credential data model.
Status and scopeVerifiable registry
A resolution layer over trust sources that remain externally operated. Holds trust anchors, ratified schemas, and governance events under a verifiability contract. Storage-agnostic by specification.
Status and scopeDual-path trust model
Ecosystem-issued credentials (mobile driver’s licenses, passports, eIDAS credentials) are consumed on their own trust paths under published rules. NFID-aligned credentials cover what governments do not issue.
Status and scopeCBOR encoding profile for access devices
Deterministic encoding, bounded element sizes, and a restricted tag set, so verification runs on the processors readers and panels already ship with.
Status and scopeThree modalities. Each has a place.
Physical credentials
Durable, low-technology, dependent on no client device. The right choice for many environments.
Mobile credentials
Strong user experience and convenience features. Provisioned by the deployment to a user’s device.
Government-issued and ecosystem-aligned identity
No deployment-side provisioning. Available wherever the holder can present it, with trust anchored in the issuer rather than the deployment.
The Foundation’s specifications address the third, because it is the one the access ecosystem has had no shared infrastructure to consume.
Complementary by design.
- ISO/IEC 18013-5 and 18013-7
- Consumes
- Aliro (Connectivity Standards Alliance)
- Adjacent layer
- OpenID for Verifiable Presentations and Verifiable Credential Issuance
- Carried within
- W3C Verifiable Credentials Data Model 2.0
- Consumes
- FIDO and WebAuthn
- Complementary
- eIDAS 2.0 and the European Digital Identity Wallet
- Ecosystem credential category
- NIST identity publications
- Consistent with
- Open Wallet Foundation
- Wallet-agnostic
- ICAO Doc 9303
- Ecosystem credential category
- Matter for Access (Connectivity Standards Alliance)
- Tracked
Beyond Credentials
A Trust Framework for Identity-Based Physical Access. An NFID Foundation strategic positioning paper, 31 October 2026.
The Foundation’s full position: the architectural move from issue-then-verify to verify-at-the-boundary, the ten gaps the standards landscape leaves open for access control, the four contributions that close seven of them, the operational properties a regulated deployer needs, and the Foundation’s relationship to every adjacent standard.
The series
Seven articles by members of the working group, one idea each.
- Part 2, 6 November 2026 What does this mean for your panel and PACS?
- Part 1, 30 October 2026 The door doesn’t have to issue the credential
Frequently asked questions
Does the Foundation issue credentials?
No. The Foundation issues no credentials. It specifies how a verifier at an access boundary can trust credentials that governments and ecosystem authorities already issue, and it publishes a credential schema only for the authorizations that no government issues, such as an employee role.
Is this a blockchain or token project?
No. The Foundation’s registry is specified as a verifiability contract: a set of properties any conforming backend must satisfy. The Foundation does not specify, prefer, or require a particular storage technology. Its 2023 publication, and the 2024 launch that followed it, led with a distributed ledger and a token model; the 2026 paper explains why that preference resolved into a contract.
Does this replace cards and mobile credentials?
No. Physical and mobile credentials remain the right answer for many environments. The Foundation’s work adds a third modality, government-issued and ecosystem-aligned identity, which the access ecosystem has not had a shared way to consume.
How does this relate to Aliro?
Aliro specifies how a reader and a credential establish trust within a session. The Foundation specifies whose credentials qualify for that establishment in the first place, and how a verifier confirms it by resolving trust through the registry. Adjacent layers, not competing occupants of one. Foundation participants sit on the Aliro Insider Council.
Who can implement the specifications?
The specifications are written so that an organization other than any incumbent implementer can build a conforming implementation from the text. An open-source verifier library is the canonical reference implementation, not the only permitted one. Licensing of the specifications is governed by the Foundation’s intellectual property rights policy, available on request.
How do I participate?
The Foundation invites standards bodies, integrators, credential issuers, wallet platforms, regulated-industry deployers, and academic and research participants. Start at the Join page.