Why QR Verification Belongs in Service Dog Authentication
A business employee approaches a handler in a grocery store. Under the Americans with Disabilities Act as enforced through current DOJ Title III guidance, that employee may ask exactly two questions: Is this a service dog required because of a disability? What work or task has the dog been trained to perform? That is the full legal boundary of inquiry.
No documentation is legally required. No vest, no ID card, no registry confirmation. The ADA is explicit on this point.
So why does QR-based handler-dog team verification matter at all?
It matters because the handler chooses to carry it. Voluntary verification is a handler right, not a handler obligation. When a handler opts into a QR verification system, they are choosing to reduce friction at the point of access, not waiving legal protections. The system must be architected with that power asymmetry in mind from the first line of code.
At ServiceDog.AI, our work on QR verification portals sits inside a broader mission: applying responsible AI and modern web architecture to problems that real service dog handlers face every day. The architecture choices in a verification portal are not just technical decisions. They are disability rights decisions.
The Signed URL Structure That Makes Verification Trustworthy
The core technical problem is simple to state and surprisingly hard to solve correctly. A QR code encodes a URL. Anyone who scans that URL should see enough information to satisfy a reasonable access inquiry. But the handler's full medical and clinical record should never be exposed, the URL should not be forgeable, and the system should know whether a legitimate scan or an automated scraper triggered the request.
Signed URLs solve the forgery problem. The structure looks roughly like this:
https://verify.servicedogai.com/v/{team_id}?expires={unix_ts}&sig={hmac_sha256}
The sig parameter is an HMAC-SHA256 digest computed over the concatenation of the team_id, the expires timestamp and a server-side secret key that never leaves the signing service. When the verification endpoint receives a scan, it recomputes the HMAC using the same inputs and the stored secret. If the digests match and the current timestamp is before expires, the request is valid. If either check fails, the portal returns a generic rejection page with no information about why.
The key properties here are worth naming precisely. The signature is unforgeable without the secret key. The timestamp is bound into the signature, so you cannot take a valid old URL and swap in a new expiration. The team_id is a random UUID that carries no personally identifiable information on its own. Without access to the server-side mapping table, a UUID is meaningless.
This is a well-established pattern. AWS S3 presigned URLs, Google Cloud Storage signed URLs and Azure SAS tokens all use essentially this structure. Adapting it to handler-dog team verification is a natural fit, but the data minimization constraints are stricter than typical file-access use cases.
Short-Lived Token Design and Expiration Logic
Token lifetime is where privacy engineering gets interesting and where most quick implementations make mistakes.
A static QR code printed on a laminated card encodes a URL with either no expiration or a very long one, sometimes years. That design is operationally convenient. The handler prints once and carries the card indefinitely. The failure mode is severe: if the URL leaks through a photograph, a screenshot or a shoulder-scan at a distance, it remains valid for years. Anyone with the URL can query the handler's verification status repeatedly from anywhere in the world.
Short-lived tokens address this directly. The token is valid for a defined window, typically between 15 minutes and 24 hours depending on the use case. After expiration, the URL returns nothing useful. The handler's mobile application refreshes the QR code automatically before each use, either on demand or on a rolling schedule.
The expiration logic at the server side should follow three rules. First, reject all requests where unix_timestamp_now > expires regardless of signature validity. Second, reject all requests where the expiration window exceeds the configured maximum, which prevents a client from generating a token with a forged far-future timestamp even if they somehow obtained a signing key. Third, implement a not-before window of a few seconds to account for clock skew between client and server, but keep this window small and log any request that arrives suspiciously early.
On the mobile side, the application must handle token refresh gracefully. A handler standing at a pharmacy counter should not see a spinner for three seconds while the app fetches a new signed URL. Prefetching on app foreground events and caching the current token in encrypted local storage with a refresh trigger at 80% of lifetime elapsed are standard patterns that keep the experience smooth.
The TheraPetic® Training Plus program, available through officialservicedog.com, integrates verification token management directly into the handler's training record workflow. When a handler completes task training milestones, the system can issue a fresh team verification credential tied to that record, making verification a natural output of clinical training documentation rather than a separate bureaucratic step.
Static QR vs. Dynamic Rotation: The Privacy Tradeoff
The choice between static and dynamic QR codes is the central privacy architectural decision in this space. It deserves a direct treatment because it involves genuine tradeoffs, not a clear winner.
Static QR codes have real advantages. They work without a smartphone. They work without a data connection. They are accessible to handlers who are elderly, have cognitive disabilities or lack reliable internet access. Accessibility is not a secondary concern in a system designed for people with disabilities. It is a primary engineering constraint.
Dynamic rotating QR codes reduce the persistent identifier exposure window. Each scan of the current code produces a URL that expires soon. Photographs of the QR code itself become worthless after the rotation interval. This is a meaningful privacy gain in an era where phone cameras are ubiquitous and shoulder scanning is a realistic threat model.
A hybrid architecture handles both cases without sacrificing either. The system issues a base static credential encoded in a QR code, but that static URL redirects to a short-lived dynamic token generated at request time. The static URL itself reveals nothing about the handler and contains no scannable information useful to an adversary. The server, on receiving a request to the static URL from an authenticated handler device, generates a fresh signed URL with a short expiration and returns it as a redirect. A third-party scanner following that redirect gets a time-limited view. A static photograph of the QR card yields only the opaque static endpoint, which without the server-side session context returns nothing exploitable.
This architecture adds server-side complexity and introduces a dependency on network availability at scan time, which must be documented honestly to handlers who may rely on this system in areas with poor connectivity.
Access Log Minimization and What Should Never Be Stored
Every HTTP request to a verification endpoint generates a log entry by default. Default logging configurations in nginx, Apache and most cloud load balancers record the full request URI, the client IP address, the user agent string, a timestamp and the response code. For a verification portal, this default behavior creates a serious privacy problem.
The full request URI contains the team_id. Over time, logs accumulate a history of every business, every location via IP geolocation and every timestamp at which a specific handler's team was queried. This is functionally a surveillance record of a disabled person's movements and the frequency with which their service dog was challenged. Under no interpretation of responsible data stewardship should this record exist in a retention window longer than required for immediate fraud detection.
Log minimization for verification endpoints should implement several specific controls. Strip the team_id from logged URIs before write, logging only the endpoint path without query parameters. Replace the full client IP with a hashed or truncated version, retaining enough for abuse detection but not enough for precise geolocation. Set a log retention policy of 72 hours for access logs at the verification tier, separate from application-level audit logs which may have longer retention for legitimate fraud investigation purposes. Require internal access to audit logs to go through a break-glass process with human approval and automatic alerting.
What the system legitimately needs to store is narrow. A count of verification requests per team credential in a rolling window is sufficient for rate limiting and abuse detection. A flag indicating whether a credential has been revoked is necessary for the validity check. The timestamp of last successful verification, stored without the querying party's identity, can support handler-facing transparency reporting. Nothing more is required for the system to function correctly.
The principle here aligns with guidance from the International Association of Assistance Dog Partners at iaadp.org on handler privacy and from HUD guidance on reasonable accommodation documentation, both of which emphasize that the minimum necessary information standard should govern any system that touches disability-related records.
The ADA Compliance Layer Sitting Above the Technical Stack
The verification portal does not exist in a legal vacuum. The ADA two-question rule enforced by DOJ under Title III creates specific constraints on what information the portal may surface to a scanning business employee.
The portal response page for a valid scan should display exactly three things: confirmation that a valid team credential exists, the service dog's name and trained task category expressed in functional terms, and a reference to the applicable federal law. It should not display the handler's name, the handler's diagnosis, the handler's treating provider, clinical notes or any information that a business employee has no legal right to request in person.
This is not a design preference. Displaying information beyond what the ADA two-question framework permits could be interpreted as enabling documentation demands that violate the handler's rights. The portal must be as protective as the law itself, not more invasive.
Machine learning components at the verification layer, including the computer vision task validation work described elsewhere on ServiceDog.AI, must follow the same data minimization principle. An ML model's confidence score on a task performance assessment is an internal system artifact. It does not belong on the public-facing verification response page. Handlers who engage AI-assisted verification through officialserviceanimal.com should see their credential status clearly, not a numerical score that a business employee could misinterpret as a grading system for service dogs.
How TheraPetic® Solutions Implements This Architecture
TheraPetic® Solutions Inc. approaches the QR verification problem as a clinical data stewardship challenge first and a software engineering challenge second. The architectural decisions described in this article reflect what Dr. Patrick Fisher and the clinical team at therapetic.ai have identified through years of working with licensed clinical providers on documentation systems that touch sensitive disability-related information.
The signing service runs as an isolated microservice with no direct database access to clinical records. It holds only the secret key material and the team-ID-to-credential mapping. Clinical data lives in a separate service behind authentication that the verification portal cannot reach. Even if the verification endpoint were compromised, an attacker would gain access to only the signed URL generation logic and the minimal credential metadata, not to any handler's clinical record.
Token generation is rate-limited per team credential. A handler can refresh their QR code on their mobile device without restriction in normal use patterns. Automated requests at high frequency trigger a hold and a notification to the handler, consistent with the transparency principle that handlers should always know when their credential is being queried in unusual ways.
The mobile application enforces device binding. A team credential is tied to a specific device key stored in the device's secure enclave. Transferring the credential to a new device requires re-authentication through the clinical provider relationship, which is the same chain of trust that issued the original credential. This prevents credential sharing while respecting that handlers have a right to replace phones without losing access to their documentation.
For AI engineers building similar systems, the key architectural insight is this: the privacy guarantees are only as strong as the weakest logging configuration in the request path. A carefully designed signed URL with short token lifetimes can be undermined entirely by a cloud load balancer logging full URIs to an S3 bucket with a five-year retention policy. Audit the full request path from client to database before claiming any privacy properties.
The work of building verification systems that handlers can trust is not finished. Biometric handler-dog team authentication, edge inference for public access assessment and federated credential models across clinical providers all represent open research directions that ServiceDog.AI continues to explore. The privacy architecture described here is the foundation those systems must be built on.