Skip to content
Registry StackDocsv0.13.0

Capability matrix

View as Markdown

Use this page to decide what Registry Notary can do today: read the status labels, the personas and systems vocabulary, then scan the scenario matrix for the support level and main gap of each flow.

This catalog describes practical places where Registry Notary can help. It is not a protocol spec. It is a product and demo guide for deciding which flows are already supported, which are demo-only, and which need more runtime work.

The scenarios use five status labels:

StatusMeaning
SupportedWorks in Registry Notary runtime and has focused tests or existing product coverage
Lab-supportedCan be shown with demo scripts or config, but is not a complete runtime feature
PartialImportant pieces exist, but named product gaps remain
PlannedNot yet implemented
Out of scopeNot a Registry Notary responsibility

The worked scenarios and their recurring example cast live in Notary scenario patterns.

PersonaWhat they needExamples
Citizen or residentShare only the proof needed to access a serviceParent applying for child support, farmer applying for a voucher
Case workerMake an evidence-backed decision without seeing unnecessary registry dataBenefits officer, enrollment officer
Service or procedure ownerDefine requirements, decision policy, and acceptable issuersSocial protection ministry, university admissions office, licensing authority
Registry stewardProtect source registry data while answering authorized evidence questionsCivil registry, farmer registry, health facility registry
Auditor or oversight bodyVerify evidence evaluations and data exchanges were lawful, minimized, and replay-protectedInternal audit, data protection authority
Wallet or client app operatorHelp users present proofs or receive credentialsMobile wallet, service portal, case-management app
SystemRole
Source registryOperational system of record. It is not exposed directly to consumers
Registry RelayRead-only gateway and metadata publisher for source registry data
Registry NotaryEvaluates reusable Relay-backed or source-free evidence claims, signs results, issues credentials only from exact Relay-backed evaluation provenance, enforces evidence policy, and emits audit. Source-free results cannot authorize issuance
Registry ManifestPublic metadata and discovery artifact for capabilities, profiles, and evidence offerings
Registry PlatformShared crypto, HTTP, OIDC, SD-JWT, DID/JWK, replay, and audit primitives
Service portal or case systemActs as an evidence consumer; the operating institution remains the decision owner
Holder wallet or client appStores credentials, presents proofs, and receives issued credentials
Trust bundle or trust registrySigned trust metadata; not yet supported. Peer trust today is a static allowlist
Audit storeLocal audit trail for evaluations, issuance, denials, and federation exchanges

The supported scenarios return evidence. The evidence consumer determines how the evidence is used, and the decision owner remains accountable for any eligibility, qualification, entitlement, payment, referral, workflow, or action decision. A Notary claim may attest a source-owned decision, but Notary does not recompute that decision as consumer policy.

#ScenarioPatternStatusMain gap
1Civil alive predicateRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
2Age or date-of-birth evidenceRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
3Programme enrollment activeRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
4Health facility service availableRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
5Farmer registration and landholding evidenceRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
6Livestock identity and movement-status evidenceRelay-backed evaluationSupportedNone for a compiler-pinned Relay consultation
7Benefits agency asks Civil Notary for alive predicateDelegated evaluationPlannedInbound federation is source-free in this version, and no outbound Notary client ships
8Benefits agency asks Social Notary for active beneficiary predicateDelegated evaluationPlannedInbound federation is source-free in this version, and no outbound Notary client ships
9Health-linked child support across civil, social, and healthOutbound compositionPlannedNo outbound Notary client or peer-result composition runtime ships yet; you cannot compose signed peer results across authorities in one flow
10Municipality verifies residency with a national registry stewardDelegated evaluationPlannedInbound federation is source-free in this version, and no outbound client or demo wiring ships
11Citizen presents civil-status proof to a benefits serviceUser-presented proofPlannedNo proof profiles or verifier runtime ship yet; you cannot accept this user-presented civil-status proof
12Farmer presents landholding or farmer-registration proofUser-presented proofPlannedNo proof profiles or status/freshness policy ship yet; you cannot accept a user-presented landholding or farmer-registration proof
13Health worker presents professional credential for workforce assignmentUser-presented proofPlannedNo proof profiles or issuer trust policy ship yet; you cannot accept the presented professional evidence
14Parent or guardian requests a service for a child or dependentDelegated self-attestation plus proofSupportedEvaluation and rendering require the configured Relay-backed relationship proof; delegated credential issuance is intentionally unavailable in 1.0
15Household or group representative requests a serviceRepresentation plus proofPlannedNo collective subject model or representative authority policy ships yet; you cannot let a household or group representative request this service
16Civil Notary issues date-of-birth or alive credentialCredential issuanceSupportedFull EdDSA and ES256 source-tested pre-authorized flow exists; external wallet evidence remains candidate-only
17Agriculture Notary issues farmer-registration or landholding credentialCredential issuanceSupportedFull EdDSA and ES256 source-tested pre-authorized flow exists; external wallet evidence remains candidate-only
18Shared evidence service issues combined-support evidence credentialCredential issuance plus compositionPartialRelay-backed credential issuance exists, but peer-result composition is missing
19Consuming service helps holder obtain credential from remote NotaryFederated credential issuancePlannedNo holder-binding ceremony, nonce ownership, or relay rules ship yet; you cannot help a holder obtain a credential from a remote Notary through this service
20Replay and emergency peer/key denialGovernanceSupportedActive-active deployments require the typed Notary-owned PostgreSQL state schema
21Auditor verifies minimized evidence exchangeGovernancePartialSigned results and audit exist, checkpoints are planned
22Peer audit checkpoint monitoringGovernancePlannedNo checkpoint publisher, Merkle builder, or peer monitor ships yet; you cannot independently verify peer audit checkpoints

Each Relay authority uses one Notary authority, with Notary-owned PostgreSQL correctness state for production and multi-instance deployment. Wallet-facing issuance supports only issuer-initiated pre-authorized code, EdDSA did:jwk holder proof, and EdDSA or ES256 issuer signing. This matrix makes no EUDI, HAIP, PAR, DPoP, wallet-attestation, ES256-holder, or external wallet/verifier conformance claim. Those claims require frozen candidate artifacts and recorded external evidence.