MCP Security Interoperability — tracking

[rsharath]

Tracking issue for the OpenID AIIM CG

Which columns ZeroID can claim

Role	Available
OAuth AS	yes
Resource AS	yes
OpenID Provider	no — no id_token issuance, no /.well-known/openid-configuration, no ID-JAG minting; we only redeem
MCP Client / Server / Gateway	no — firehog's entry, see below

Two of the three top-level rows are the ceiling. The event's own top-level matrix already greys out OAuth token based access for both our columns.

Status

EMA — in good shape. Valid ID-JAG alone checks the EMA box, and we implement every clause of the p.9 verification table plus single-use jti replay rejection the event does not ask for. Gaps: #265 (sub_id), #258 (resource as a request parameter).

CIMD — cannot check the box today. Qualification needs ≥1 Client ID Metadata row and ≥1 client-authentication row. We pass the first and score zero on the second, because our CIMD clients are public by construction. #264 is the fix; #263 blocks testing it with anyone.

Issues

	Priority
#263 — /oauth2/authorize has no browser GET leg	P0, blocks all CIMD interop testing
#264 — confidential CIMD clients (jwks_uri/jwks + private_key_jwt)	P0, decides the CIMD box
#265 — sub_id on ID-JAG redemption	P1, small
#258 — RFC 8707 resource request parameter	P1, pre-existing
#266 — client_credentials for CIMD clients	P2, depends on #264
#206 — private_key_jwt client auth	prerequisite for #264

Deliberately not doing

ID-JAG issuance / the OpenID Provider role. Claiming the EMA OP column means id_token issuance, refresh tokens, and OIDC discovery first. That is not a December-sized item. The test harness stubs the OP instead, which also tells us cheaply whether the real thing is worth building.

tls_client_auth / the MTLS rows. No implementation anywhere, least valuable of the three client-auth rows, already deferred in #206.

Per-client_id CIMD allow-list. The pre-registered client row is satisfied — arguably — by cimd.allowed_domains (config.go:97), a host allow-list. It is coarser than the row implies: one approved host vouches for every document on it. Worth flagging to the tester rather than building, unless a partner objects.

Test harness

highflame-regression/tests/api/mcp_interop/ — one test per matrix row, named so the pytest report transcribes into the submission form. Gaps are xfail(strict=True), so closing one turns the suite red until the marker comes off; a green run means the recorded matrix is accurate. Each issue above names the tests it flips.

Flows are MCP-native (mcp 2.0.0, protocol revision 2026-07-28) — a real MCPServer and a real OAuthClientProvider, because hand-rolled HTTP can be written to match whatever we happen to accept and will pass while a partner's client fails. The SDK speaks CIMD (client_metadata_url) and SEP-990 ID-JAG natively, and ZeroID already advertises both discovery flags, so it drives our paths with no glue.

Findings for the CG, not for us

• The plan has a typo. p.9 says the ID-JAG typ is oauth-id-jag-jwt; the draft and our implementation use oauth-id-jag+jwt (internal/service/oauth_id_jag.go:25). A partner building to the published document will hand us assertions we correctly refuse, and the row reads as our failure. Get it corrected before Aug 10.
• No CIMD matrix row for a public PKCE client — the MCP 2025-11-25 preferred shape, and what we implement.
• The reference Python SDK cannot check the scope-in-WWW-Authenticate row. mcp 2.0.0 builds the challenge from error/error_description/resource_metadata only. One of only two rows in the OAuth matrix, so most participants will leave it blank. Firehog implements it (highflame-firehog/src/gateway/proxy.rs:674).

Firehog

src/gateway/federated.rs terminates and re-originates rather than transparently proxying, and the plan explicitly disqualifies transparent proxies. So firehog can enter as a second participant and reach the MCP Gateway column and the OAuth matrix — boxes ZeroID structurally cannot touch. Confirm the client leg, then point the existing harness at it.

[rsharath]

Matrix now runs green against a live ZeroID with the EMA column fully wired.

16 passed · 19 skipped · 4 xfailed · 0 failed, stable across consecutive runs.

EMA — every claimable row passes. Valid ID-JAG (which checks the EMA box on its own), iss, aud, JWT signature, client_id binding, resource (minted aud == the ID-JAG resource), resource required, scope no-widening, single-use jti replay rejection, and the doc-typo typ guard.

CIMD — all 13 rows still skip on the /oauth2/authorize 503 (#263). That is now the only thing between us and the CIMD box.

Reproducible setup landed in highflame-regression/tests/api/mcp_interop/deploy/:

tests/api/mcp_interop/deploy/run-interop-zeroid.sh ../zeroid
eval "$(tests/api/mcp_interop/deploy/run-interop-zeroid.sh --env)"
pytest -m mcp_interop

Three things have to be pinned because ZeroID reads them at startup: the fixture origin's port, the CA (SSL_CERT_FILE), and the stub OP's signing key. The last one is the non-obvious one — ZeroID caches an external issuer's JWKS for jwks_cache_ttl (5 min default) with no invalidation hook, so a freshly generated key against an already-running ZeroID is verified against the cached one and fails as assertion verification failed. Rotating means deleting deploy/.ca/ and restarting ZeroID.

One new issue out of the setup work: #268 — a stock ZeroID has no way to create its first OAuth client (DCR needs an initial access token that needs a client), so the ID-JAG client had to be seeded by raw SQL. Not an interop blocker, but it is the first thing anyone standing up ZeroID hits.

[rsharath]

Status update — the CIMD column moved.

Matrix: 21 passed, 1 skipped, 14 xfailed, 0 failed (was 16 passed / 15 skipped), against a live ZeroID carrying #270.

What changed

zeroid#270 makes the authorization_code flow reachable, so the 13 CIMD rows execute instead of skipping on the 503. Three causes, one of which this tracker had not identified: authorization_endpoint was missing from AS metadata, which is a required field on the MCP SDK's OAuthMetadata model — the document failed to parse, the client saw no metadata, skipped CIMD and fell back to dynamic registration. Only the real SDK client surfaced it.

A stock mcp 2.0.0 client now discovers ZeroID and negotiates CIMD end to end, sending our document URL as client_id.

Where the two columns stand

EMA — submittable. Every claimable row green, including single-use jti replay rejection the event does not ask for. Remaining gaps are #265 (sub_id) and #258 (resource as a request parameter).

CIMD — still cannot check the box, and the blocker changed. It is no longer the 503; it is #271, no interactive user-authentication surface.

This is the part worth planning around. Our harness drives the CIMD rows with an api_key and the AS-side rows pass — but the event scores interoperability with another participant (plan p.11), and our counterparty for the OAuth AS column is somebody else's MCP Client. An MCP client builds an authorization URL and hands it to a browser. Confirmed against a #270 build: it gets 401. Every partner stops there.

So the December ordering is:

#271 — interactive auth surface	P0 — without it no partner can test CIMD with us at all
#264 — confidential CIMD clients	P0 — decides whether the qualification rule is satisfied
#265 — sub_id	P1, small
#258 — resource request parameter	P1
#266 — client_credentials for CIMD	P2
#268 — first-client bootstrap	P2, not interop-blocking

#263 closes when #270 merges.

Also unchanged

The three findings for the CG still need raising, and the oauth-id-jag-jwt typo especially — it wants correcting before the commit date, or a partner building to the published document hands us assertions we correctly refuse and the row reads as our failure.

Harness setup is reproducible in highflame-regression/tests/api/mcp_interop/deploy/ (highflame-regression#190).

[mahirhir]

For hardening the ID-JAG verification and confidential CIMD client authentication (#264):

1. Deterministic jti Replay Defense & Proof Binding:

   • Track single-use jti tokens in a bounded in-memory sliding window or Redis set keyed by (iss, jti) with an exact TTL matching the JWT exp:

     func (s *OAuthService) VerifyIdJag(ctx context.Context, tokenStr string) (*IdJagClaims, error) {
         claims, err := parseAndVerifyJwt(tokenStr, s.opJwks)
         if err != nil {
             return nil, err
         }
         // Enforce single-use jti replay prevention
         if !s.replayCache.SetNX(ctx, fmt.Sprintf("jti:%s:%s", claims.Issuer, claims.Id), claims.ExpiresAt) {
             return nil, ErrJtiReplayed
         }
         return claims, nil
     }

2. CIMD private_key_jwt Client Assertion Verification:

   • When redeeming credentials, fetch and pin the client's jwks_uri declared in its client_metadata_url document, caching the public key digest to prevent repeated network round-trips while verifying client assertion signatures offline.

We use this single-use jti replay barrier and offline-verifiable client metadata attestation in https://github.com/TraceFold/tracefold (architecture in docs/TRACEFOLD_TR.md §4.1) for zero-trust MCP gateway authentication.

[rsharath]

Interop test plan: ZeroID ID-JAG ↔ Okta Agent SSO / Cross App Access

Phase 0 — spec diff (desk work, ~1 day)

• Diff our ID-JAG implementation against Okta's published XAA profile (their AI-agent token-exchange docs: ID token → ID-JAG → scoped access token, 300s default TTL, JWT-bearer client auth) — enumerate every claim/parameter delta
• Support the sub_id claim on ID-JAG redemption (EMA matrix row) #265 (sub_id claim on redemption) is the one known delta — confirm whether Okta-minted assertions carry it and in which form
• Check audience/resource semantics: what aud does Okta stamp on the ID-JAG, and does our redemption binding (draft §9.1 intended-party check, oauth_id_jag.go:171) match their value shape

Phase 1 — ZeroID as the app-side AS (the core test, ~1 week)

• Okta developer org with Agent SSO / XAA enabled; register a test enterprise app whose authorization server is ZeroID
• Redeem an Okta-minted ID-JAG at /oauth2/token: assert claims mapping (buildIDJAGCustomClaims — IdP group/role → principal attributes), single-use jti enforcement (id_jag_jti), observed-resource recording (Persist the MCP servers we already observe: record ID-JAG resource values per tenant #259 surface)
• Negative matrix: replayed assertion, wrong audience, expired assertion, unknown issuer, tenant mismatch — each must fail with the draft's error semantics, no 500s
• Token lifetime interplay: Okta's 300s ID-JAG TTL vs our credential-policy ceilings

Phase 2 — end-to-end through a live ISV (~1 week, depends on Phase 1)

• Claude's XAA integration as the first counterpart: Claude (agent) → Okta (IdP mints ID-JAG) → MCP server whose EMA authorization server is ZeroID; verify the full MCP Enterprise-Managed Authorization flow with our token on the wire
• Repeat with one non-Anthropic ISV (Notion or Linear) to catch Claude-specific assumptions

Phase 3 — findings out the door

• Close spec deltas found (starting with Support the sub_id claim on ID-JAG redemption (EMA matrix row) #265); file anything XAA-profile-specific as new issues
• Add an id_jag_xaa_interop row to tests/integration/COMPLIANCE.md with the negative matrix as greppable tests
• One line earned for README + the ODIS role-capability statement: "interoperates with the Okta Agent SSO / Cross App Access ecosystem"

Exit criteria: an Okta-minted assertion redeems at ZeroID with correct claims, replay/audience/tenant negatives all 4xx cleanly, and one live ISV flow works end-to-end. Estimate: ~2–3 weeks elapsed, mostly Phase 1–2 environment setup; the implementation already exists, which is the entire point.

[saucam]

Correction: the OP-column row is now partly stale

The "Which columns ZeroID can claim" table gives three reasons for OpenID Provider → no:

no id_token issuance, no /.well-known/openid-configuration, no ID-JAG minting; we only redeem

The middle one is now false. #313 landed (zeroid v1.8.11, live on dev1) and ZeroID publishes /.well-known/openid-configuration — the RFC 8414 document plus subject_types_supported and id_token_signing_alg_values_supported. Verified from outside the cluster: https://auth-dev.highflame.dev/.well-known/openid-configuration returns 200 over public HTTPS, all seven OIDC Discovery §3 REQUIRED members present, issuer matches the fetch prefix (§4.3), and the advertised algs are exactly the algs at the live jwks_uri.

The column is still no, and I am not proposing otherwise — the other two reasons stand unchanged. But the "Deliberately not doing" note reads:

Claiming the EMA OP column means id_token issuance, refresh tokens, and OIDC discovery first. That is not a December-sized item.

That list is now two items, not three, and the remaining discovery work is zero. Worth re-pricing on that basis rather than leaving the original estimate to stand — the reason to defer the OP column should be id_token issuance and the design question underneath it, not discovery.

The design question that actually gates it

Minting an ID-JAG requires being the IdP holding an identity assertion for the principal — i.e. issuing an id_token first. The hard part is not the JWT plumbing: an id_token has one sub, and ZeroID's differentiated asset is delegation chains that preserve the human in act.sub. How "this agent, acting for that human, three hops down a chain" projects into a single-subject id_token — and what a receiving ISV is expected to do with it — is unanswered, and it is the thing to settle before any OP-column work is scoped.

Housekeeping on this issue

• RFC 6749 §4.1.2.1: /oauth2/authorize returns JSON errors instead of redirecting them to the client #263 (browser GET leg, listed P0, blocks all CIMD interop testing) is closed — landed in 04aa7de. The issue table still lists it as open. The remaining P0 for the CIMD box is Confidential CIMD clients: parse jwks_uri/jwks and accept private_key_jwt #264, which needs private_key_jwt client authentication: enforce what registration already accepts (tls_client_auth deferred) #206 first.
• The scope note in tests/integration/COMPLIANCE.md now records OIDC Discovery 1.0 as Partial — metadata only, with the deliberate out-of-scope list (§5 UserInfo, §2 WebFinger, every ID Token clause). Worth mirroring here if this table is what gets transcribed into the submission form.