Demonstrate representative issuance with separate relationship and civil registries

[jeremi]

Context

Registry Stack issue #562 defines digitally authenticated representative OID4VCI issuance for credentials whose subject and wallet holder are different people.

Solmara already demonstrates a delegated two-hop child-benefit evaluation: a guardian relationship is checked before the child's civil facts are consulted. That is a useful starting point, but it does not yet demonstrate issuance. The current journey does not prove that an authenticated representative can receive a wallet-bound credential whose sub identifies the child while cnf identifies the representative's wallet key.

This repository should own the runnable adopter demo and evidence. The Registry Stack capability, schema, product tests, and public product documentation remain in registrystack/registry-stack.

Outcome

A complete Solmara journey demonstrates an authenticated parent obtaining and storing a child birth credential after:

1. one governed source proves the exact parent-child relationship;
2. a distinct Civil Registration source supplies the configured child facts;
3. Notary creates an OID4VCI offer only after both authorization and evaluation succeed; and
4. the wallet proves a key that is bound as cnf, while the child's pseudonymous target reference is issued as sub.

The demo must make the separation of representative, credential subject, relationship source, civil-fact source, and holder key visible without exposing protected values.

Demo contract

• Use the digitally authenticated representative ceremony defined by Registry Stack #562.
• Authenticate the representative through the configured Solmara eSignet/OIDC path before creating a usable offer.
• Commit the selected child and credential configuration in short-lived server-side state before authentication begins.
• Prove the relationship through the configured compiler-pinned Relay claim. Request metadata, consent UI, on_behalf_of, and wallet possession are not substitutes for relationship evidence.
• Use a distinct governed Civil Registration source for the birth facts included in the issuance evaluation.
• Use only the explicitly allow-listed representative relationship, purpose, child claim, credential profile, and OID4VCI credential configuration.
• Preserve the standard short-lived, single-use pre-authorized-code wallet flow and the interoperability constraints established by Solmara #12.
• Use synthetic Solmara identities and identifiers only.

Scope

• Pin Solmara atomically to the exact published Registry Stack candidate that implements #562.
• Extend the existing child/guardian personas and fixtures with:
  • one permitted parent-child pair;
  • one authenticated adult with no permitted relationship;
  • one alternative child for target-substitution checks; and
  • deterministic unavailable or ambiguous relationship-source controls.
• Configure a relationship proof claim against a governed relationship source and a separate registry-backed child birth credential claim against Civil Registration.
• Configure the relationship-to-credential-profile allow-list and the representative-enabled OID4VCI credential configuration.
• Add the representative initiation, OIDC return, authorization/evaluation, offer presentation, wallet redemption, and credential verification journey.
• Reuse the live wallet plumbing and evidence conventions from Solmara Restore and prove the Walt OID4VCI demo for Registry Stack 1.0 #12 rather than creating a second mock wallet path.
• Update the portal and walkthrough so they distinguish:
  • authenticated representative;
  • selected dependent subject;
  • relationship proof source;
  • child-fact source;
  • offer/issuance transaction;
  • wallet holder key; and
  • the meanings of sub and cnf.
• Add focused configuration, scenario, portal, live smoke, browser, replay, and redaction coverage.
• Capture reproducible candidate evidence with exact Registry Stack image digests, Solmara commit, wallet version, commands or user steps, result, and first blocker.

Acceptance criteria

• A seeded Solmara parent authenticates through eSignet for one previously selected child and credential configuration.
• The configured relationship authority proves the exact requester-target pair before Civil Registration is consulted.
• Civil Registration supplies the exact registry-backed child facts through the configured Relay dependency closure.
• No offer is created when relationship proof is false, missing, ambiguous, unavailable, stale, or for a different requester-target pair.
• The live wallet imports and redeems the resulting pre-authorized offer, proves possession of its key, and stores the issued SD-JWT VC.
• Verification shows sub is the child's issuer-scoped pseudonymous target reference and cnf is the representative wallet proof key.
• The representative cannot select a credential configuration or profile not explicitly enabled for the proven relationship.
• Changing the child after authorization fails without consulting or issuing for the substituted child.
• Changing the holder key, nonce, credential request, relationship, evaluation, or configuration fails without minting a credential.
• Reusing or concurrently redeeming the offer, code, token transaction, or nonce cannot mint a second credential.
• The credential endpoint uses the stored, committed evaluation and makes zero new Relay calls.
• The UI never presents consent, wallet possession, or on_behalf_of metadata as proof of parenthood, guardianship, custody, or identity.
• Logs, screenshots, retained evidence, and audit views contain no raw civil identifiers, relationship records, credential values, wallet proofs, offer secrets, access tokens, or tx_code.
• just lint, just test, just smoke, just review, the focused browser journey, and the release-candidate wallet journey pass.

Dependencies

• Blocked on implementation and candidate freeze for registrystack/registry-stack#562.
• Reuse and extend the wallet lifecycle established by registrystack/solmara-lab#12. This issue owns the representative-specific ceremony and evidence, not the generic wallet restoration work.

Non-goals

• Implementing Registry Stack product behavior in Solmara.
• An assisted registrar or OpenCRVS ceremony that does not digitally authenticate the representative in Notary.
• Treating wallet possession as relationship, custody, guardianship, or civil-status evidence.
• Accepting relationship facts, child facts, raw sub, or subject-holder mappings from the portal or another caller.
• Inline proof through a separate sovereign Registry Stack federation domain.

[jeremi]

Registry Stack #562 has converged on a compact, generic Registryctl authoring contract for the adopter demo:

oid4vci:
  representative_issuance:
    relationship: parent
    proof_claim: parent-link
    target_id_type: civil_registration_id
    max_proof_age_seconds: 300 # optional, defaults to 300

The Solmara values above are example policy identifiers, not built-in Registryctl semantics. Registryctl derives the sealed digitally_authenticated_representative ceremony, the credential root dependency on the proof claim, the exact delegated closure, credential status, and a sufficient instance evaluation-age ceiling. The proof claim must be a separate registry-backed claim in the selected credential service, and its Relay consultation must bind exactly one authenticated requester identifier and the configured target identifier. The relationship source may be a different governed integration or registry from the source of the credential facts.

The demo should use the ordinary offer-start URL, authenticate the representative, submit the target only through the post-login CSRF-protected form, and then show that the issued credential uses the represented subject pseudonym as sub and the wallet key as cnf. It must explain that the relationship was proven at issuance time. Status changes are observable by verifiers, while automatic relationship-change-to-revocation delivery remains tracked in registrystack/registry-stack#568.

Please keep the two-source topology and negative cases already listed in this issue. Do not model parenthood, child identifiers, Solmara UINs, or a particular registry protocol as Registryctl product concepts.

[jeremi]

Registry Stack support is ready for review in registrystack/registry-stack#571.

The demo should consume the generic Registryctl contract already recorded above. It should not add Solmara, parent, child, or guardian semantics to Registryctl. Solmara supplies the concrete relationship source, identifiers, fixture data, and user-facing story; Registryctl supplies the reusable representative-issuance mechanism.

[jeremi]

Implementation review refinement from registrystack/registry-stack#571:

• Keep the relationship-proof consultation generic but exact: one authenticated requester identifier input and one selected target identifier input. The target-selection ceremony intentionally rejects additional proof inputs it cannot populate.
• Use a representative credential root that is exclusive to that credential profile.
• In the demo, decode the pre-authorized code and access token to show that the representative raw sub and civil identifier are absent. Registry Notary replaces them with committed HMAC handles before the offer crosses into the wallet.
• Show representative ceremony audit events with access_mode = delegated_attestation.

These are platform contracts, not Solmara-specific compiler behavior.

[jeremi]

Final platform contract correction from the #562 staff review: Registryctl now generates a delegation-only representative credential root. It stays out of the ordinary subject_access.allowed_claims and is authorized only by the selected relationship's delegated allow-list. The production validator separately checks the representative root's Relay inputs against the browser ceremony, without narrowing generic delegated evaluation.

Please make the Solmara demo use different schemes for the authenticated representative and represented child, for example solmara_uin for the representative and a civil-registration identifier for the child. That visibly proves the abstraction is requester/target policy, not a parent-child special case or an assumption that both roles share one identifier namespace.