Document bootstrappingInfo and deviceCredential.value read-back policy

[clundie-CL]

Problem description

Two adjacent fields in the Trust Domain Device schemas have different response-side disclosure policies, but the spec doesn't document the distinction:

• bootstrappingInfo (and its sub-properties DppBootstrappingConfig.bootstrappingUri, MatterBootstrappingConfig.setupPayload, WksoBootstrappingConfig.bootstrappingUri) round-trips on responses to createTrustDomainDevice and is expected to be readable by any subsequently-authorized scope holder, including consent-granted federated readers (e.g. a visiting-network operator using NaaS / Zero-Touch-Onboarding flows).
• deviceCredential.value under credentialAction: "GENERATE" is server-minted and is not echoed back; it appears to the creator only and should not appear on subsequent reads.

The two policies are intentionally different because the data is different in kind: bootstrappingInfo is onboarding metadata the client provided (DPP public key material, Matter one-time commissioning payload, WKSO cert-subject identity), while deviceCredential.value under GENERATE is a server-minted persistent shared secret. But because the spec doesn't document this asymmetry, reviewers reasonably read the test-side disparity as inconsistent.

This was raised in review of #120. The relevant test wording was softened in that PR (the _03_matter_success scenario now asserts bootstrappingInfo is "present and non-null" rather than exact-match) so the tests are agnostic to the resolution here.

Expected action

1. Add a paragraph to BootstrappingInfo.description (or to each sub-config schema's description) noting that bootstrappingInfo round-trips on responses and is readable by any principal holding the appropriate scope, including consent-granted agents per the standard CAMARA OAuth/CIBA flow.
2. Add the inverse note to DeviceCredential (or to the value property specifically) — that value under credentialAction: "GENERATE" is the server's response-time secret to the creator only and never appears on subsequent reads. If value is not already marked writeOnly: true, decide whether to add the annotation.
3. Once the policy is documented, tighten the relevant test assertions: re-strengthen createTrustDomainDevice _03_matter_success to assert specific fields, and clean up updateTrustDomainDevice _02_replace_credential_success so the assertion checks the response shape directly rather than relying on "does not echo back the request body" phrasing.

Additional context

• Out of scope: operator-to-operator federation. The visitor-network / hotel scenario is handled via the existing CAMARA OAuth/CIBA + consent flow with the :read-all scope variant; no NAM-specific federation primitive is needed.
• Out of scope: Matter setupPayload post-commissioning lifecycle. The passcode is single-use and burns at commissioning, so disclosing it after the device is commissioned has no functional effect.
• The asymmetry the reviewer noticed is between createTrustDomainDevice _03_matter_success (which formerly asserted bootstrappingInfo round-trips) and updateTrustDomainDevice _02_replace_credential_success (which asserts deviceCredential.value does not echo). Both scenarios live in code/Test_definitions/.
• Related: 52 create gherkin feature file #120 (the test PR where the review surfaced this).

[clundie-CL]

Beyond device credentials: the Trust Domain accessDetails secrets are disclosed inconsistently. WpaPersonalDetail.password is writeOnly, but the Thread secrets networkKey and operationalDataset (which embeds the network key) in AccessDetail.yaml are not writeOnly, so they round-trip on GET /trust-domains[/{id}]. Whatever read-back policy we land on here should cover accessDetails secrets too, not just deviceCredential.value / bootstrappingInfo.