Assert a role-bound relationship

If you write assertion definitions, this tutorial shows you one that binds two subjects in distinct roles and releases one Boolean: is the candidate in the child’s complete legal-parent set? You continue in the project from Control who can request evidence, with the source and Registry Evidence still running.

Outcome

A verified relationship assertion bound to a child and a candidate parent.

Time

About 10 minutes

Level

Local development with synthetic data

Prerequisites

The project, source, and Registry Evidence left running by Control who can request evidence

Check the relationship definition

In first-evidence-assertion/adult-status, run the relationship fixture on its own:

rstack evidence test . \
  --target local-target.yaml \
  --fixture fixtures/legal-parent-relationship.yaml

PASS: fixtures/legal-parent-relationship.yaml (9 cases)

The legal-parent-relationship definition in evidence.yaml names two roles under subjects:

evidence.yaml

subjects:
- role: child
  selectors:
  - record-by-id
- role: candidate-parent
  selectors:
  - record-by-id

Each role selects a record through the record-by-id selector profile. The parent-record source fetches the parent set with the child selector alone, and its response shape requires complete: true, so an incomplete set is refused before any Function runs. outputs declares one Boolean, is-parent, so the parent list never enters the assertion.

Request and verify the relationship

Prepare one request with both roles, send it, verify the response, and read it:

rstack evidence request prepare legal-parent-relationship \
  --client tutorial-client \
  --purpose relationship-check \
  --subject child:record-id=child \
  --subject candidate-parent:record-id=parent \
  --name legal-parent-relationship
rstack evidence api /v1/evidence \
  --client tutorial-client \
  --input .evidence/requests/legal-parent-relationship/request.json \
  --accept application/jose+json \
  --output legal-parent.jws.json
rstack evidence verify legal-parent.jws.json \
  --context .evidence/requests/legal-parent-relationship/verification.json \
  --output legal-parent.verified.json
jq -c '.subjects[], .supportedValues[]' legal-parent.verified.json

VERIFIED
{"binding":"urn:evidence:subject:<binding>","role":"child"}
{"binding":"urn:evidence:subject:<binding>","role":"candidate-parent"}
{"providesValueFor":"urn:example:concept:legal-parent-relationship:v1","value":true}

Each role carries its own subject binding, an opaque value scoped to your audience (subjectBinding: audience-scoped), in place of the record identifier.

Prove the role boundary

Leave out the candidate parent, and request prepare refuses before it writes anything:

rstack evidence request prepare legal-parent-relationship \
  --client tutorial-client \
  --purpose relationship-check \
  --subject child:record-id=child \
  --name missing-candidate-parent

evidencectl: subject inputs must match the definition's complete role set

Give the child role twice, and it refuses again:

rstack evidence request prepare legal-parent-relationship \
  --client tutorial-client \
  --purpose relationship-check \
  --subject child:record-id=child \
  --subject child:record-id=parent \
  --subject candidate-parent:record-id=parent \
  --name duplicate-child

evidencectl: subject inputs must contain each selected profile field exactly once

Swap the two values. The request is complete, but the source holds no parent set for parent:

rstack evidence request prepare legal-parent-relationship \
  --client tutorial-client \
  --purpose relationship-check \
  --subject child:record-id=parent \
  --subject candidate-parent:record-id=child \
  --name swapped-relationship

rstack evidence api /v1/evidence \
  --client tutorial-client \
  --input .evidence/requests/swapped-relationship/request.json \
  --accept application/jose+json \
  --output swapped-relationship.json

jq -r .code swapped-relationship.json

evidence.unavailable

Registry Evidence returns evidence.unavailable for any subject it cannot resolve, so the refusal does not say which record was missing.

Leave the source and Registry Evidence running; the next tutorial continues with them.

Next

Request evidence as an SD-JWT VC