What does this mean for your panel and PACS?

The first question an integrator asks after watching a door open for a government-issued ID is a practical one. What is required of my access control system to support this? Less than you might expect, because the architecture keeps the access decision in the panel.

Today, a reader processes the credential and passes a number to the panel. The panel matches it against the internal list, and the panel makes the decision. The PACS sets the rules, and the panel enforces them. None of those changes. The only thing that changes are what the reader hands to the panel.

With a mobile driver’s license, the reader conducts the ISO 18013-5 engagement with the phone and passes the resulting identity elements to the panel over the wire it already uses. The panel then verifies the issuer’s signature, resolves trust through the Foundation’s registry, produces an attestation of what it verified, and makes the decision. Matching and decision stay in the panel, where they belong. There is one place to update trust anchors and rotate keys. Where architecture requires it, a standalone lock can do the verification itself. However, this requires more management overhead. Figure 5 in the paper traces the full flow: issuance, presentation, attestation, resolution, decision, and audit.

As for the PACS, it has two ways to take part, and the difference between them is whether it wants to be in the story.

The first option asks nothing about the PACS. In the panel, the verified identity resolves to a credential number in a format the PACS already understands. The PACS never knows the number came from a government ID. All the intelligence lives in the panel and the reader. The trade-off is that the end user is responsible for enrollment through third-party middleware.

The second option is integration. Here the PACS knows the credential is a government-issued identity. Enrollment becomes a single toggle on the person’s profile “allow this person to use their mobile driver’s license”. The PACS pushes what the panel needs and owns the authorization. Now the end user has a seamless enrollment process with their existing PACS.

The point to hold onto is that the PACS is an enhancer, not a requirement. A panel that can verify a government-issued ID is useful on day one with any PACS, and more useful with one that has integrated. A pilot does not have to wait on a PACS vendor’s roadmap.

On the hardware side, the panel needs two things: an application environment where verification logic can run, and a way to receive identity elements from the reader. Panels with a modern embedded environment already have both. Older hardware may need an add-on module or may need the reader to carry more of the work.

The reader is where the market is thinnest today. A wall reader has to conduct the ISO 18013-5 engagement with the phone and carry the resulting identity elements to the panel over OSDP, and few readers on the market do this yet. As mobile driver’s licenses spread across US states, this is the gap most worth closing, and nobody wants it closed by a single reader vendor. The OSDP technical subcommittee is looking at how this kind of reader-to-panel transfer should be specified. The reader manufacturers that implement the engagement and carry the elements over standard transport will be the ones integrators can specify.

That leaves the question a customer will eventually ask. Is this a single-vendor product, or an open standard with a choice of suppliers? The answer is both, and the boundary between them is what matters. The attestation format, the registry, and the trust governance form the Foundation’s open layer, which anyone can implement. How a verified identity maps to a legacy credential number is an implementation choice, and there will be several. An integrator who understands that boundary can specify the open parts and evaluate the rest on their merits.