QR-Based Handler-Dog Team Verification: Signed URL Architecture and Privacy-First Token Design

What QR-Based Verification Actually Solves

Businesses interacting with service dog handler-dog teams face a narrow legal corridor. Under the Americans with Disabilities Act, staff may ask only two questions: whether the dog is required because of a disability and what work or task the dog has been trained to perform. Requesting documentation is not permitted. That prohibition creates a friction point that analog systems handle poorly.

QR-based verification portals do not create new legal authority. They create a voluntary, privacy-respecting channel through which a handler can choose to share vetted information about their team. The distinction matters enormously for system design. The architecture must enforce that sharing is always handler-initiated and that the portal never surfaces protected health information to a scanning party.

At ServiceDog.AI, building verification technology starts with that constraint as a first principle, not an afterthought. The focus keyword here is QR verification, and the engineering choices around it flow directly from disability rights law, not from convenience.

Signed URL Structure for Team Verification Portals

A signed URL is a URL that carries a cryptographic signature in its query string, proving that the URL was generated by a party holding a specific private key. For handler-dog team verification, the signed URL structure typically looks like this:

https://verify.example.com/team?uid=TEAM_ID&. Exp=UNIX_TIMESTAMP&. Sig=HMAC_SHA256_SIGNATURE

Three components do the work. The uid parameter is an opaque team identifier, not a handler name or medical record number. The exp parameter is a Unix timestamp encoding when the URL becomes invalid. The sig parameter is an HMAC-SHA256 signature computed over the canonical string formed by joining the uid and exp values with the server's secret signing key.

When a scanning party hits the verification endpoint, the server recomputes the HMAC over the presented uid and exp values. If the signatures match and the current time is before the expiry, the portal renders a minimal verification card. If either check fails, the server returns an opaque rejection with no information about why the check failed.

The verification card itself should show only what a legitimate business need requires: that the team is registered, the task category the dog is trained for (expressed in functional terms, not diagnostic terms) and a photograph of the dog. Handler name, address, diagnosis and medical provider information must never appear on the public-facing verification card. The ADA.gov guidance on service animals makes clear that businesses have no right to that information, and the portal architecture should make it technically impossible to retrieve.

Short-Lived Token Design and Lifecycle Management

Token expiry is where QR verification moves from a static credential to a living system. The engineering tension is real: a token short enough to limit exposure is inconvenient for handlers who may carry a printed QR code. A token long enough to be practical becomes a credential that, if photographed or scraped, can be replayed for weeks.

A workable approach for handler-dog team verification uses a two-tier token model.

• A long-lived identity token lives only on the handler's authenticated mobile session. It never appears in a QR code directly.
• A short-lived presentation token is derived on demand from the identity token, valid for a configurable window of 15 minutes to 4 hours depending on the handler's workflow context.

The presentation token is what gets encoded into the QR image. Because it is derived rather than stored, the server can invalidate entire classes of presentation tokens by rotating the signing key segment associated with a given identity token, without touching the identity token itself.

Key rotation policy for the signing key deserves explicit specification. A 90-day rotation cycle for the HMAC signing key, combined with a grace period of 24 hours during which both the old and new keys are accepted, gives operations teams a safe rollover window without forcing handlers to re-enroll mid-rotation.

The TheraPetic® Training Plus program structures credentialing in a way that maps cleanly onto this two-tier model: training records and task certifications live at the identity layer, while the presentation layer exposes only the verification status derived from those records.

Static QR Codes vs. Dynamic Rotation: The Privacy Tradeoff

Static QR codes embed a fixed URL. Dynamic QR codes embed a redirect URL that the issuing server resolves to a current target. The distinction sounds operational but carries significant privacy implications for handler teams.

A static QR code printed on a vest patch or laminated card is convenient for handlers. It is also a fixed identifier. Anyone who photographs that code now holds a persistent tracking token. Across enough scan events, a static identifier enables reconstruction of a handler's movement patterns, venue visits and public activity. For a population that already faces elevated surveillance risks, that is not a theoretical concern.

Dynamic QR rotation addresses this by ensuring the URL embedded in the physical code changes on a schedule. The redirect layer resolves the current short-lived presentation token without requiring the handler to reprint anything. The physical QR code points to a stable redirect endpoint. The redirect endpoint consults the handler's current token state and issues a fresh signed URL on each resolution.

The tradeoff is infrastructure complexity and availability dependency. A static QR code functions offline. A dynamic redirect requires the redirect server to be reachable at the moment of scan. For handlers in areas with poor connectivity, a graceful degradation path matters: the system should cache a recent signed URL locally on the handler's device so that connectivity gaps do not leave a team unable to verify.

From a privacy engineering standpoint, dynamic rotation is the correct default for any production deployment. Static codes are acceptable only for short-duration, single-event contexts where the physical code will be destroyed after the event.

Access Log Minimization and Audit Trail Design

Every scan of a verification QR code generates a server-side access log entry. By default, web server logs capture IP address, user agent, timestamp, request path and response code. For a handler-dog team verification portal, that default is a privacy liability.

The IP address of the scanning party may reveal the business location. The timestamp reveals when the handler was present. Enough log entries construct a detailed movement record. None of that information is necessary to operate a functional verification system.

Access log minimization for verification portals should implement the following:

• IP truncation at ingestion. The last octet of IPv4 addresses and the last 80 bits of IPv6 addresses are zeroed before any log write. This is the same approach used by analytics platforms that claim GDPR compatibility.
• User agent hashing. The raw user agent string is replaced with a salted hash. Verification integrity is maintained without storing browser fingerprint data.
• Log retention caps. Verification access logs are retained for no longer than 72 hours by default, sufficient for operational debugging but not sufficient to build movement profiles.
• Separation of audit logs from access logs. A separate audit log records only cryptographic outcomes: token valid or token invalid, plus a non-reversible hash of the team identifier. The audit log has a longer retention window (90 days) to support compliance review without exposing movement data.

This separation is not just good privacy practice. It is the architecture that makes it possible to respond honestly to a subpoena or legal hold: the system can confirm whether a specific team's credential was validated on a specific date without producing a location history for the handler.

Where Verification Technology Meets the ADA Two-Question Rule

Verification portals exist in a space that ADA Title III does not explicitly contemplate. The DOJ's Title III regulations, codified at 28 CFR Part 36, do not authorize businesses to require documentation. The two-question rule remains the legal ceiling for what a place of public accommodation may ask.

What the portal architecture must enforce is that scanning is always an offer from the handler, not a demand from the business. The system design implications are concrete:

• The portal must never be required for access. A handler without a smartphone or without a printed QR code retains full rights under the ADA.
• The verification card must not reveal information the business has no right to receive. Displaying diagnosis, prescribing provider or medical history on the scan result would turn voluntary disclosure into a documentation requirement by another name.
• The portal must not log the identity of the scanning party. Businesses scanning handler credentials should not become identifiable in the handler's data record.

At TheraPetic®.AI, clinical AI systems are built around the same boundary principle: the tool augments human judgment within legal and ethical limits rather than attempting to replace or circumvent those limits. Verification portal design follows the same logic.

The International Association of Assistance Dog Partners (IAADP) has long documented the harassment and access challenges handler-dog teams face in public settings. Technology that adds friction rather than reducing it, or that exposes handler data to third parties, makes that problem worse. Signed URL architecture, short-lived tokens and log minimization are the engineering choices that keep verification technology on the right side of that line.

Implementation Considerations for Verification Portal Builders

Building a production verification portal for handler-dog teams requires decisions that do not appear in generic QR code tutorials. Several deserve explicit attention.

Key Management Infrastructure

HMAC signing keys must be stored in a hardware security module or a managed key service such as AWS KMS or Google Cloud KMS. A signing key stored in application configuration or environment variables is one leaked secrets file away from wholesale credential forgery. Key management is not optional complexity.

QR Code Error Correction Level

Verification QR codes should use error correction level H (30% damage tolerance). Handler-dog teams operate in physically demanding environments. A vest patch accumulates wear. Error correction level H ensures the code remains scannable through real-world degradation without requiring reissuance after every deployment.

Mobile-First Rendering

The scanning party in most real-world verification scenarios is using a smartphone camera natively, not a dedicated QR scanner app. The verification card rendered at the signed URL must load in under two seconds on a 4G connection and must render correctly on a 375-pixel viewport. A verification portal that requires a desktop browser to display correctly will fail in the settings where it matters most.

Liveness and Replay Attack Mitigation

A short token expiry window mitigates replay attacks but does not eliminate them within the validity window. A nonce-based consumption flag, where the server marks a presentation token as consumed after first use, provides stronger replay protection at the cost of requiring handlers to generate a fresh token for each distinct verification event. For high-security deployments this is worth the UX cost. For standard public access scenarios, a 15-minute expiry window without nonce consumption is a reasonable default.

Accessibility of the Portal Itself

A verification portal built for service dog handlers must itself be fully accessible. The verification card must be screen-reader compatible with proper ARIA labels. Color choices must meet WCAG 2.1 AA contrast ratios. The QR generation interface must be operable by keyboard. Building an accessibility tool that is not itself accessible is a failure of product ethics as much as a technical shortfall.

For teams building verification infrastructure that connects to training record systems, the OfficialServiceAnimal.com verification registry provides a reference implementation of how training credentials and team records can be surfaced through a verification layer without exposing underlying medical or diagnostic data.

QR verification done correctly is not a credential check. It is a privacy-preserving handshake that gives handlers a voluntary tool to smooth public access interactions while keeping protected information exactly where it belongs: under handler control.