docs: new architecture RFC

[alukach]

What I'm changing

This PR adds a new RFP and accompanying ADRs to the codebase.

How I did it

This RFC (adrs/rfc-001.md) describes a new architecture for our data proxy; some of which has been partially actualized in #109. Accompanying the RFC is various ADRs that go into greater detail about components of the architecture. The new architecture is future facing (ie it includes designs for new features) but attempts to be constrained, only thoroughly exploring a first wave of near-term features and only acknowledging later-stage features like metering and rate-limiting.

How to test it

Review, comment inline on PR.

[github-actions]

🚀 Latest commit deployed to https://source-data-proxy-pr-115.source-coop.workers.dev

• Date: 2026-04-07T20:19:45Z
• Commit: dbbe470

[tylere]

It would be useful to visualize both the current (non-Cloudflare) data flow vs. the new Cloudflare data flow.

[tylere]

How significant is the added latency?

[tylere]

Suggested change

	1. Parse `RoleArn` → extract `account_id` and `role_name`
	2. Load Role definition from policy store (cached, 30–60s TTL)
	3. Extract `iss` from JWT (without verification)
	4. Match `iss` against the Role's allowed IdPs — reject immediately if no match
	5. Fetch JWKS from the matched IdP (cached, 1hr TTL, 3s timeout, stale-while-revalidate on fetch failure)
	6. Verify JWT signature, `exp`, `nbf` (60s clock skew tolerance), and `aud`
	7. Evaluate claim constraints for the matched IdP binding
	8. Validate `DurationSeconds` ≤ Role's `max_session_duration`
	9. Generate credentials (see ADR-001 for token structure) and return response
	1. Parse `RoleArn` → extract `account_id` and `role_name`
	2. Load Role definition from policy store (cached, 30–60s TTL)
	3. Extract `iss` from JWT (without verification)
	4. Match `iss` against the Role's allowed IdPs — reject immediately if no match
	5. Fetch JWKS from the matched IdP (cached, 1hr TTL, 3s timeout, stale-while-revalidate on fetch failure)
	6. Verify JWT signature, `exp`, `nbf` (60s clock skew tolerance), and `aud`
	7. Evaluate claim constraints for the matched IdP binding
	8. Validate `DurationSeconds` ≤ Role's `max_session_duration`
	9. Generate credentials (see ADR-001 for token structure) and return response
	````mermaid
	flowchart TD
	Start["Receive AssumeRoleWithWebIdentity request"] --> Parse["1. Parse RoleArn<br/>→ account_id + role_name"]
	Parse --> LoadRole["2. Load Role from policy store<br/>(cached, 30–60s TTL)"]
	LoadRole --> ExtractIss["3. Extract iss from JWT<br/>(without verification)"]
	ExtractIss --> MatchIdP{"4. Does iss match<br/>Role's allowed IdPs?"}
	MatchIdP -- No --> RejectIdP["Reject:<br/>IDPRejectedClaim"]
	MatchIdP -- Yes --> FetchJWKS["5. Fetch JWKS from IdP<br/>(cached 1hr TTL, 3s timeout,<br/>stale-while-revalidate)"]
	FetchJWKS --> VerifyJWT{"6. Verify JWT<br/>signature, exp, nbf, aud"}
	VerifyJWT -- Invalid --> RejectJWT["Reject:<br/>InvalidIdentityToken"]
	VerifyJWT -- Valid --> EvalClaims{"7. Evaluate claim<br/>constraints"}
	EvalClaims -- Fail --> RejectClaims["Reject:<br/>IDPRejectedClaim"]
	EvalClaims -- Pass --> ValidateDuration{"8. DurationSeconds ≤<br/>max_session_duration?"}
	ValidateDuration -- No --> RejectDuration["Reject:<br/>ValidationError"]
	ValidateDuration -- Yes --> GenCreds["9. Generate short-lived<br/>SigV4 credentials"]
	GenCreds --> Return["Return credentials response"]

[tylere]

I'm not sure the mermaid diagram is worth the extra space, but I do find it easier to understand the decision flow.

[tylere]

Note that the STS log entries may include PII (e.g. assumed_by and client_ip), and that a future logging ADR will need to address retention/redaction policies.

[tylere]

Does the current version of object_store compile to WASM? Or is the risk that future versions of object_store may not be compatible?