Difficulty: Expert
Type: Security / Architecture (Protocol-level)
Background: Building directly on Issue #21: once revocation checking exists, the app needs a way to actually know which keys are revoked while offline — the entire premise of docs/ATTESTATION_PROTOCOL.md's design is that attestations remain verifiable "entirely offline once cached (airplane mode compatible)." A revocation check that requires live connectivity to be meaningful would undermine that exact design goal for the specific case (a compromised/revoked key) where checking matters most.
Problem: There is currently no mechanism in the codebase for distributing revocation state in a way that's usable offline with any freshness/staleness guarantee — this is a genuine protocol design gap, not just a missing function call: what's the trust model for a locally-cached revocation list (can it itself be tampered with or rolled back to hide a revocation)? How stale can it be before an offline verifier should refuse to trust any attestation from that guild rather than risk accepting one from a since-revoked key? How does revocation data get bundled with an attestation that's being presented to a third-party verifier who has no live connection to GuildPass at all (the "portability" use case docs/ATTESTATION_PROTOCOL.md specifically calls out)?
Expected outcome: A formally-designed (RFC-style) and implemented revocation-distribution mechanism: a versioned, monotonically-increasing revocation list per guild issuer, cached locally with a bounded trust window (mirroring the QR flow's DEFAULT_KEY_REGISTRY_OFFLINE_TRUST_WINDOW_MS pattern), with explicit policy for what happens when the cache is stale/unavailable, and — for the true offline-portability case — a mechanism for bundling a recent revocation-list snapshot alongside a presented attestation so a disconnected third-party verifier has something to check against (even if it's the presenter's own responsibility to have refreshed it recently, which should be transparent and auditable).
Suggested implementation: This requires design collaboration with the @guildpass/sdk/guildpass-core maintainers, since a versioned revocation list is a protocol-level concept, not purely client-side. Start with a written design document proposing: the revocation-list format (versioned, signed by the guild issuer key itself or a higher-authority key so the list can't be spoofed), the local caching/trust-window strategy (reusing guildIssuerKey.ts's pattern), and the bundling mechanism for the offline-portability case. Implement the local-caching and staleness-policy portions once the format is agreed upon; the third-party-verifier bundling piece may reasonably be scoped as a follow-up given its cross-repo protocol implications.
Acceptance criteria:
- A design document is produced covering the revocation-list format, trust model, and staleness policy, ideally reviewed with the SDK/core maintainers given the cross-repo nature.
- Local caching and staleness-policy enforcement are implemented and tested against the design.
- The offline-verification staleness policy is fail-closed by default (a verifier that cannot confirm a reasonably-fresh revocation status refuses to treat an attestation as fully trusted, and communicates that degraded trust level clearly rather than silently accepting).
Likely affected files: src/features/attestation/issuerKeyRegistry.ts, src/features/attestation/attestationService.ts, docs/ATTESTATION_PROTOCOL.md, new design document, associated tests.
Labels: security, feature, priority: high, help wanted, GrantFox OSS, Maybe Rewarded, Official Campaign | FWC26
Difficulty: Expert
Type: Security / Architecture (Protocol-level)
Background: Building directly on Issue #21: once revocation checking exists, the app needs a way to actually know which keys are revoked while offline — the entire premise of
docs/ATTESTATION_PROTOCOL.md's design is that attestations remain verifiable "entirely offline once cached (airplane mode compatible)." A revocation check that requires live connectivity to be meaningful would undermine that exact design goal for the specific case (a compromised/revoked key) where checking matters most.Problem: There is currently no mechanism in the codebase for distributing revocation state in a way that's usable offline with any freshness/staleness guarantee — this is a genuine protocol design gap, not just a missing function call: what's the trust model for a locally-cached revocation list (can it itself be tampered with or rolled back to hide a revocation)? How stale can it be before an offline verifier should refuse to trust any attestation from that guild rather than risk accepting one from a since-revoked key? How does revocation data get bundled with an attestation that's being presented to a third-party verifier who has no live connection to GuildPass at all (the "portability" use case
docs/ATTESTATION_PROTOCOL.mdspecifically calls out)?Expected outcome: A formally-designed (RFC-style) and implemented revocation-distribution mechanism: a versioned, monotonically-increasing revocation list per guild issuer, cached locally with a bounded trust window (mirroring the QR flow's
DEFAULT_KEY_REGISTRY_OFFLINE_TRUST_WINDOW_MSpattern), with explicit policy for what happens when the cache is stale/unavailable, and — for the true offline-portability case — a mechanism for bundling a recent revocation-list snapshot alongside a presented attestation so a disconnected third-party verifier has something to check against (even if it's the presenter's own responsibility to have refreshed it recently, which should be transparent and auditable).Suggested implementation: This requires design collaboration with the
@guildpass/sdk/guildpass-coremaintainers, since a versioned revocation list is a protocol-level concept, not purely client-side. Start with a written design document proposing: the revocation-list format (versioned, signed by the guild issuer key itself or a higher-authority key so the list can't be spoofed), the local caching/trust-window strategy (reusingguildIssuerKey.ts's pattern), and the bundling mechanism for the offline-portability case. Implement the local-caching and staleness-policy portions once the format is agreed upon; the third-party-verifier bundling piece may reasonably be scoped as a follow-up given its cross-repo protocol implications.Acceptance criteria:
Likely affected files:
src/features/attestation/issuerKeyRegistry.ts,src/features/attestation/attestationService.ts,docs/ATTESTATION_PROTOCOL.md, new design document, associated tests.Labels:
security,feature,priority: high,help wanted,GrantFox OSS,Maybe Rewarded,Official Campaign | FWC26