registrystack / registrystack/registry-stack
Run the OpenID conformance suite against a pinned release topology
- 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