Pilot Identity and Non-Repudiation

Andi Lamprecht ·2026-05-11· 12 min read· Draft

1. OAuth2 / OIDC User Identity Verification

The Authorization Server (e.g. login.gov) authenticates the user and issues a signed JWT containing claims like sub, email, and exp. The client verifies the signature using the AS’s public keys fetched from /.well-known/jwks.json — mechanically similar to how a browser verifies a CA-signed certificate.

Comparison to CA chain of trust

The fundamental difference

In the CA model, trust is cryptographically hierarchical — it terminates at a root whose key was distributed out-of-band by your OS vendor, independent of any single party. No website can subvert it unilaterally.

In OAuth2, trust is unilateral. The client decides to trust an Authorization Server — there is no higher authority certifying that login.gov or Okta is a legitimate identity provider. That relationship is a business and policy decision, not a cryptographic one. If the Authorization Server lies about a user’s identity, the client has no way to detect it. The HTTPS connection to /.well-known/jwks.json relies on the CA chain to confirm the server’s identity — but that only proves you reached the real server, not that it is being honest.

2. IdP Federation Breaks the Chain

When an application trusts an intermediary IdP (e.g. Auth0) that is itself federated with an upstream IdP (e.g. login.gov), the user authenticates with the upstream provider, but the application only ever sees a token issued by the broker. Auth0 validates the upstream assertion and re-issues its own JWT.

Is the upstream IdP visible in the token?

Yes, if Auth0 is configured to include it. Relevant claims:

{
  "iss": "https://your-tenant.auth0.com/",
  "idp": "login.gov",
  "amr": ["govt-identity-proofed", "mfa"],
  "acr": "http://idmanagement.gov/ns/assurance/ial/2"
}

• idp — identifies the upstream provider
• amr — how the user was authenticated
• acr — assurance level (login.gov uses NIST 800-63 URIs)

Can it be verified?

Only partially. The application can cryptographically verify that Auth0 signed the JWT. It cannot verify that login.gov’s original assertion to Auth0 was legitimate — it must trust Auth0 to have validated it correctly.

Federation extends the unilateral trust chain

Your app
  → trusts Auth0          (unilateral, policy decision)
    → Auth0 trusts login.gov  (unilateral, policy decision)
      → login.gov trusts its own identity proofing

Each hop is a policy and contractual decision, not a cryptographic one. There is no equivalent of a Root CA certifying that Auth0 is a legitimate broker — unlike the CA chain of trust, there is no ultimate authority anchoring the chain.

3. Preserving the Chain of Trust to the Identity Issuer

Standard OAuth2 federation breaks the cryptographic chain. Two approaches restore it.

PIV / CAC smart cards

Used by the US government for employees. The card holds an X.509 certificate issued by a government CA that chains up to the Federal Common Policy Root CA. Authentication produces a signature verifiable all the way to that root — no intermediary can lie. The limitation is that it requires physical hardware, making it impractical for consumer applications.

Verifiable Credentials (W3C)

The modern general-purpose solution. The issuer (e.g. login.gov) signs a credential with its private key and gives it to the user, who stores it in a digital wallet. When authenticating, the user presents the credential directly to the application, which verifies the issuer’s signature against the issuer’s published public key. No broker in the middle.

The trust chain becomes: issuer's key → credential → your app — analogous to the CA chain of trust, with the issuer’s published key as the trust anchor.

Verifiable Credentials are not yet mainstream — the ecosystem lacks a universal wallet and consistent government adoption. The EU is ahead with the EUDI Wallet, mandated across member states by 2026.

Comparison

4. Non-Repudiation and Cross-Agency Evidence

When ATOMx must produce credible evidence that a specific government user initiated an action — evidence that a third-party agency will accept — an intermediary IdP is architecturally incompatible with that requirement.

If Auth0 or a similar broker is in the middle, the government’s reasonable response to “John Doe authorized this flight” is: “we trust login.gov, we don’t trust Auth0 — Auth0 could have fabricated or modified that claim.” The intermediary breaks the evidentiary chain.

What is required: non-repudiation

Non-repudiation is the property that a user cannot deny having performed an action, and that a third party can independently verify they did. For this to hold across organizational boundaries, the proof must chain back to an authority the third party already trusts — with no intermediary in between.

Options

Direct OIDC federation — ATOMx federates directly with each agency IdP (login.gov, DoD, etc.) and retains the original government-signed JWT in the audit record. The agency can verify their own signature on it without trusting ATOMx as an intermediary.

PIV / CAC — the user signs the action with their smart card’s private key. The signature chains to the Federal Common Policy Root CA and is self-contained and verifiable by any agency that trusts that root. The strongest option for non-repudiation.

Verifiable Credentials — the government-issued credential is presented directly and attached to the audit record, with no intermediary in the trust chain.

Recommendation

The audit record must contain either the original government-signed JWT or a user-generated cryptographic signature — something the government can verify without trusting ATOMx as an intermediary. This points to direct federation at minimum, and PIV / Verifiable Credentials where strong non-repudiation is a hard requirement.

5. NIST 800-63 Assurance Levels

ATOMx pilot identity maps to NIST SP 800-63-3 assurance levels. Each level constrains which trust-ladder cell a pilot can occupy.

acr claims in OIDC tokens (§2) carry the IAL/AAL URIs (http://idmanagement.gov/ns/assurance/ial/2, etc.). Verifiers that ignore acr are effectively treating IAL2 and IAL3 as equivalent — the trust-ladder mapping requires reading and enforcing these claims.

6. FIDO2 / WebAuthn and Passkeys

PIV / CAC are excellent for federal personnel but are not feasible for the broader pilot population. FIDO2 / WebAuthn is the practical successor: a hardware authenticator (security key, platform authenticator, or attested mobile device) generates a per-relying-party keypair, never reveals the private key, and produces a signed assertion at authentication time.

For ATOMx pilots without a federal credential, a FIDO2 authenticator paired with login.gov-grade IAL2 proofing approaches the non-repudiation property of PIV without the smart-card logistics. Passkeys (synced credentials) are accepted at AAL2 but capped below AAL3 because the private key may exist on multiple devices.

7. Mobile Driver’s License (mDL)

ISO/IEC 18013-5 mDL is the natural Verifiable-Credential bridge for state-issued identity. As state issuers come online and mDL wallets stabilize (timeline 2026–2028), ATOMx will accept mDL presentations as identity-proofing evidence with the issuing state’s public key as the trust anchor — analogous to PIV chaining to the Federal Common Policy Root. mDL is not in MVP scope but the trust-ladder is designed to admit it without re-architecting.

8. Identity Lifecycle and Edge Cases

9. The Pilot Identity Channels in ATOMx

PRDs and the whitepaper reference “verified pilot identity” abstractly. The concrete channels named across meetings are:

FAA DiSCVR is referenced as a correlation source, not as a primary identity-proofing channel — its availability for direct identity verification is constrained.

10. Cross-References

• The PKI substrate this page assumes: PKI and Chains of Trust
• The trust-ladder cells driven by pilot identity: Trust Ladder §4
• How the verified pilot identity is bound into the authorization package: Authorization Package §1
• Pilot enrollment lifecycle: Onboarding Operators and Pilots
• Pilot-identity-related threats (impersonation, broker compromise, stolen authenticator, Sybil): Threat Model §2 and §10

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.