adorsys / adorsys/status-list-server
Document and test issuer registration ownership flows end to end
- Linguagem predominante
- Rust
- Estrelas
- 22
- Forks
- 5
- Merge médio
- 2d 6h
- PRs com merge (30d)
- 47
Descrição
## Objective
Close the issuer registration ownership work with documentation, OpenAPI updates, and end-to-end regression coverage.
## Scope
This issue ties together the implementation slices so the final behavior is understandable, testable, and reflected in public project documentation.
## Deliverables
- [ ] Update OpenAPI for challenge, registration, rotation, recovery, and error responses.
- [ ] Update README and operator docs with issuer onboarding examples.
- [ ] Update the trust model document with accepted proof modes and registry behavior.
- [ ] Add end-to-end tests for first registration, failed arbitrary claim, successful proof, key rotation, and recovery/revocation where implemented.
- [ ] Add negative tests for replay, duplicate issuer, wrong key, wrong domain/DID, and unauthorized rotation.
- [ ] Confirm logs and error responses do not leak keys, tokens, credentials, or proof material.
## Acceptance Criteria
- [ ] A maintainer can run a documented issuer onboarding flow locally or in a test environment.
- [ ] OpenAPI matches implemented request/response behavior.
- [ ] Security-sensitive negative cases are covered by automated tests.
- [ ] #187 can be closed once this and the implementation sub-issues are complete.
## Dependencies
- Depends on the proof, registration lifecycle, key history, and recovery implementation issues.
## Related Issues
- Parent: #187
- Related: #147, #177, #319
Guia de contribuição
Direção de pesquisa
Locate the OpenAPI spec, README/operator docs, trust model document, and existing E2E tests for issuer challenge/registration/rotation/recovery. Read those first to confirm current request/response behavior, then add the requested positive and negative coverage for replay, duplicate issuer, wrong key/domain/DID, and unauthorized rotation plus recovery/revocation flows. Finish by aligning docs and spec updates with implementation and running the project’s E2E tests; done means matching OpenAPI responses and no leaked secrets in error or log assertions.
Escrita pelo modelo de indexação a partir do texto da issue.
Avaliação
- Stack de tecnologia
- rust
- Domínio
- backend-api-design, documentation, testing
- Tipo de issue
- Documentação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Status de atividade
- Pouca atividade
- Clareza
- Razoavelmente clara
- Facilidade para iniciantes
- 48/100