Machine identity must match the revenue authority

What the public implementation shows

Strict mode requires p2g-authority and checks token azp or client_id against RevenueAuthority.Code, with separate policies for SIPS Connect, dashboard, and configuration users.

The endpoint derives authority context from route and token rather than accepting an arbitrary authority claim in the payload. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA valid token proves authentication; client binding proves institutional authority.

The decision behind the mechanism

Client-to-authority binding prevents one correctly authenticated machine client from acting for another institution.

Role-only authorization can grant every authority service account the same cross-tenant reach. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Validate issuer, signature, audience, and lifetime.
• Read client identity from trusted token claims.
• Match client identity to the route authority.
• Separate human dashboard and machine policies.

How the control should be operated

Client registration, service-account role, audience, authority code, secret or certificate, and revocation owner should be managed as one onboarding record.

Institutional boundaries survive even when many clients share one API and role vocabulary. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.