registrystack / registrystack/registry-stack

Run the OpenID conformance suite against a pinned release topology

Aperta
#205 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub
1.0-blocker area:notary area:relay triage:needs-implementation
Lingua principale
Rust
Stelle
2
Fork
0
Merge medio
2h 55m
PR unite (30g)
130

Descrizione

## Context

Conformance-suite evidence is the strongest public signal that applicable OpenID and OID4 claims hold. The evidence must be reproducible from pinned release images and configuration, not depend on a mutable hosted lab or on a second repository remaining available.

The current wallet-delivery surface is the supporting **registry-evidence-oid4vci** adapter and its frozen OID4VCI 1.0 Final profile for holder-bound Evidence. Historical Registry Notary OID4VCI behavior is retired and is not a conformance target.

A Solmara Lab topology may be used to exercise the run, but the harness and recorded evidence belong with the release surface they verify.

Related: #57, #689, #690.

Pinned #690 interoperability evidence: [committed receipt at `68af5eb9`](https://github.com/registrystack/registry-stack/blob/68af5eb9ed8b779afdbaf33aa1efda06ed88026c/products/evidence/fixtures/interoperability/inji-oid4vci/receipt.json). This receipt records bounded interoperability evidence for the exact pinned Inji revisions and focused test conditions. It is not OpenID conformance or certification.

## Scope

- Identify the stable OpenID conformance plans that apply to Registry Stack's OIDC bearer-validation resource servers, Registry Mint authorization-server role, Evidence verifier behavior, and the narrow Evidence OID4VCI adapter.
- Map each plan to an exact shipped role and profile. Record exclusions where the suite assumes capabilities Registry Stack deliberately does not implement.
- Run applicable plans against a pinned release topology with scripted, documented setup.
- Include at least one Relay or Evidence resource server using OIDC bearer validation rather than API-key-only demo authentication.
- Include OID4VCI plans only when the suite provides stable plans applicable to the frozen profile in #689. Do not run historical Notary plans or imply full issuer support.
- Keep #690's pinned Inji interoperability evidence distinct from conformance-suite evidence. One does not substitute for the other.
- Record the initial result set honestly. Fixing every failure can be follow-up work unless a failure contradicts a shipped profile claim or exposes a security defect.

## Acceptance criteria

- [ ] A fresh runner can reproduce the suite invocation from pinned images and checked-in non-secret configuration.
- [ ] The applicable-plan mapping names the exact Registry component and frozen profile each plan evaluates.
- [ ] Historical Registry Notary OID4VCI behavior is explicitly excluded.
- [ ] Unsupported grants, credential formats, DID resolution, persistence, and lifecycle features are documented as exclusions rather than implemented for the suite.
- [ ] Initial results are committed as release evidence with failures and unsupported cases explicit.
- [ ] Inji interoperability evidence from #690 is referenced separately and is not described as conformance or certification.
- [ ] No credential, private key, code, nonce, token, proof, selector, subject identifier, or live response appears in logs or committed evidence.
- [ ] Release gating does not require a live hosted-lab dependency.
- [ ] Suspected security defects found during conformance are routed through **SECURITY.md** before any public result describes them.

## Security note

Conformance harnesses cross authentication, proof, nonce, signing, and disclosure boundaries. Use sanitized subjects and non-secret configuration, preserve the shipped profile rather than enabling test-only protocol modes, and report suspected vulnerabilities through **SECURITY.md**.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Inizia dall'ambito e dai criteri di accettazione, quindi leggi SECURITY.md e la ricevuta fissata in products/evidence/fixtures/interoperability/inji-oid4vci/receipt.json. Mappa i piani applicabili ai ruoli e ai profili distribuiti, mantieni #690 separato dalle prove di conformità ed escludi il comportamento storico di Notary. Il lavoro è completato quando un runner nuovo può riprodurre l'esecuzione fissata e le prove incluse nel commit contengono risultati ed esclusioni espliciti e non contengono segreti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
rust
Ambito
api, backend, security, testing
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
35/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.