Internal SDD Testing

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

Title

Context

DroneUp must achieve ASTM F3548-21 Strategic Deconfliction (SDD) compliance. To verify this, we developed an internal prototype to run the InterUSS uss_qualifier. This prototype successfully demonstrated that the DroneUp USS and DSS can achieve a clean “Pass” status.

However, the current prototype relies on a “Dummy Auth” model. While effective for initial logic verification, it introduces operational overhead (maintaining a separate OAuth server and manual key management) and deviates from the authentication patterns used in the official InterUSS qualification environment. We need a long-term, secure, and low-maintenance method for internal testing that mirrors official qualification requirements.

Decision

Decision Drivers

1. Operational Simplicity: Minimize the number of custom services (like dummy_oauth) that need to be maintained.
2. Security: Leverage managed identity providers and automatic key rotation over manual RSA key management.
3. Parity: Ensure internal testing auth flows match the official “qual-partners” environment (Service Account Impersonation) to reduce Gate 2 integration risk.
4. Repeatability: Facilitate easy test execution for developers and CI/CD without managing local auth state.

Alternatives Considered

Option 1: Maintain Current Prototype (dummy_oauth)

Description: Keep the existing custom OAuth server and GSM-backed RSA keys.

• Pros: Already implemented and passing tests.
• Cons: Requires maintaining a custom server; does not mirror official qualification auth; manual key rotation overhead.

Option 2: GCP Service Account Impersonation (Proposed)

Description: Use Google’s OIDC provider to sign tokens. The uss_qualifier impersonates specific DroneUp service accounts to generate tokens, which the USS/DSS validate using Google’s public JWKS.

• Pros: Zero server maintenance; automatic key rotation by Google; identical flow to official qualification; removes the need for public key endpoints.
• Cons: Requires themis-api to trust https://accounts.google.com as an issuer.

Decision Outcome

Chosen Option: Option 2: GCP Service Account Impersonation

We will decommission the dummy_oauth server and move to a managed OIDC flow.

Argument

The move to GCP Service Account Impersonation provides a “Serverless Auth” model for testing.

Although the iss claim (https://accounts.google.com) is shared across Google, security is maintained because the tokens are scoped to our project and must contain the specific UTM scopes that only our configured service accounts can obtain.

Safety Impact

Assessment: Positive / No Negative Impact.

• Reliability: Using Google’s managed OIDC is inherently more reliable than a custom-deployed dummy_oauth server.
• Security: Eliminates the risk of managed RSA private keys being leaked from a custom server.
• Integrity: Ensures the auth handling logic in themis-api is tested against real-world OIDC standards.

Implications

1. Code Cleanup: Deletion of dummy_oauth deployment and associated Dockerfiles.
2. Endpoint Removal: The /interuss/oauth/public_key endpoint will be removed from the environment entirely.
3. Authority Matching: We will explore adding sub (Subject) or email claim validation to themis-api to further restrict the Google-issued tokens to only our specific test service accounts.