fix(notary): validate federation profile scopes

Signed-off-by: Jeremi Joslin <jeremi@joslin.fr>

Author: jeremi

crates/registry-notary-core/src/config/federation.rs

@@ -214,11 +214,15 @@ impl FederationConfig {
                 validate_federation_https_url("federation.peers[].allowed_purposes[]", purpose)?;
             }
             for profile in &peer.allowed_profiles {
-                if !profile_ids.contains(profile.as_str()) {
-                    return invalid_federation(
-                        "federation.peers[].allowed_profiles must reference an evaluation profile",
-                    );
-                }
+                let profile_config = self
+                    .evaluation_profiles
+                    .iter()
+                    .find(|candidate| candidate.id == profile.as_str())
+                    .ok_or_else(|| EvidenceConfigError::InvalidFederationConfig {
+                        reason: "federation.peers[].allowed_profiles must reference an evaluation profile"
+                            .to_string(),
+                    })?;
+                validate_federation_peer_profile_scopes(evidence, peer, profile_config)?;
             }
         }
         Ok(())
@@ -273,6 +277,44 @@ fn validate_federation_claim_inputs(
     Ok(())
 }
 
+fn validate_federation_peer_profile_scopes(
+    evidence: &EvidenceConfig,
+    peer: &FederationPeerConfig,
+    profile: &FederationEvaluationProfileConfig,
+) -> Result<(), EvidenceConfigError> {
+    let available_scopes: HashSet<&str> =
+        peer.evaluation_scopes.iter().map(String::as_str).collect();
+    let mut pending = vec![profile.claim_id.as_str()];
+    let mut visited = HashSet::new();
+    while let Some(claim_id) = pending.pop() {
+        if !visited.insert(claim_id) {
+            continue;
+        }
+        let claim = evidence
+            .claims
+            .iter()
+            .find(|candidate| candidate.id == claim_id)
+            .ok_or_else(|| EvidenceConfigError::InvalidFederationConfig {
+                reason: format!(
+                    "federation evaluation profile '{}' references an incomplete claim dependency closure",
+                    profile.id
+                ),
+            })?;
+        if let Some(scope) = claim
+            .required_scopes
+            .iter()
+            .find(|scope| !available_scopes.contains(scope.as_str()))
+        {
+            return invalid_federation(format!(
+                "federation peer '{}' evaluation_scopes must include required scope '{}' for profile '{}' claim '{}'",
+                peer.node_id, scope, profile.id, claim.id
+            ));
+        }
+        pending.extend(claim.depends_on.iter().map(String::as_str));
+    }
+    Ok(())
+}
+
 #[derive(Debug, Clone, Default, PartialEq, Eq, Deserialize, Serialize, JsonSchema)]
 #[serde(deny_unknown_fields)]
 pub struct FederationSigningConfig {

crates/registry-notary-core/src/config/tests/infrastructure.rs

@@ -285,7 +285,7 @@ pub(super) fn valid_federation_config() -> StandaloneRegistryNotaryConfig {
                 "https://purpose.example.gov/social-protection/service-delivery".to_string(),
             ],
             allowed_profiles: vec!["disability_status_predicate".to_string()],
-            evaluation_scopes: vec!["civil_registry:evidence_verification".to_string()],
+            evaluation_scopes: vec!["registry:consult:test-source".to_string()],
             ..FederationPeerConfig::default()
         }],
         evaluation_profiles: vec![FederationEvaluationProfileConfig {
@@ -350,6 +350,25 @@ pub(super) fn federation_profile_rejects_relay_inputs_unavailable_from_subject()
     );
 }
 
+#[test]
+pub(super) fn federation_peer_rejects_profile_with_missing_dependency_scope() {
+    let mut config = valid_federation_config();
+    let mut dependency = config.evidence.claims[0].clone();
+    dependency.id = "disability-status-dependency".to_string();
+    dependency.required_scopes = vec!["registry:consult:dependency".to_string()];
+    config.evidence.claims[0].depends_on = vec![dependency.id.clone()];
+    config.evidence.claims.push(dependency);
+
+    let reason = expect_federation_error(&config);
+
+    assert!(
+        reason.contains(
+            "evaluation_scopes must include required scope 'registry:consult:dependency'"
+        ),
+        "unexpected: {reason}"
+    );
+}
+
 #[test]
 pub(super) fn federation_signing_key_must_reference_active_named_signing_key() {
     let mut config = valid_federation_config();
@@ -404,7 +423,7 @@ allowed_purposes:
 allowed_profiles:
   - disability_status_predicate
 evaluation_scopes:
-  - civil_registry:evidence_verification
+  - registry:consult:test-source
 "#,
     )
     .expect("private-network peer YAML parses");

docs/site/src/content/docs/spec/rs-terms.mdx

@@ -89,7 +89,7 @@ The registry stack comprises four formal products. Product names are Title Case.
 
 **wallet**: A holder-owned application that stores credentials and presents them to verifiers. Registry Notary issues credentials; the wallet that stores, unlocks, and presents them is a separate component owned by the holder.
 
-**subject access**: Registry Notary authorization pattern where an authenticated OIDC principal is the protected requester for configured claim evaluation. Registry Notary has two subject access modes: `subject_access` (direct subject access), where the authenticated principal is the subject, and `delegated_subject_access` (delegated subject access), where the authenticated principal is the requester and a configured dependent target can be evaluated only when scoped authorization details name the same target, relationship, and proof claim. Subject access never supplies claim evidence; every allowed claim remains registry-backed. Registry Stack product term.
+**subject access**: Registry Notary authorization pattern where an authenticated OIDC principal is the protected requester for configured claim evaluation. Registry Notary has two subject access modes: `subject_bound` (direct subject access), where the authenticated principal is the subject, and `delegated_subject_access` (delegated subject access), where the authenticated principal is the requester and a configured dependent target can be evaluated only when scoped authorization details name the same target, relationship, and proof claim. Subject access never supplies claim evidence; every allowed claim remains registry-backed. Registry Stack product term.
 
 **delegated subject access**: Registry Notary authorization mode `delegated_subject_access`. The requester is derived from the authenticated principal, the request target and scoped authorization details identify the same configured dependent subject, the relationship is derived from scoped authorization details, and the dependent claim can continue only after the compiler-pinned Relay proof consultation evaluates to boolean `true`. This is distinct from static-peer delegated evaluation under Notary federation. Registry Stack product term.
 

products/notary/docs/federated-evaluation-operator-guide.md

@@ -112,9 +112,12 @@ The local `peers` block is authoritative. Manifest metadata helps partners
 configure each other, but it does not grant access.
 
 `evaluation_scopes` are the scopes assigned to the authenticated federation
-principal when authorizing the selected local claim. They do not grant registry
-or Relay source access. `max_claim_result_age_seconds` bounds the age of the
-local claim result's `issued_at` timestamp.
+principal when authorizing the selected local claim. For every allowed profile,
+the list must include each `required_scopes` entry from the selected claim and
+its dependency closure. Registry Notary rejects incomplete peer policy at
+startup. These scopes do not grant registry or Relay source access.
+`max_claim_result_age_seconds` bounds the age of the local claim result's
+`issued_at` timestamp.
 
 The federation endpoint can select only a claim with
 `evidence_mode.type: registry_backed`. The verified federation request `jti`

products/notary/specs/federated-evaluation-mvp-spec.md

@@ -534,7 +534,10 @@ until every applicable item below is satisfied and reviewed.
 - Registry Notary rejects startup config when `node_id` and `issuer` do not
   satisfy the MVP binding rule.
 - Registry Notary rejects startup config when a federation evaluation profile
-  references a `registry_backed` claim.
+  does not reference a `registry_backed` claim.
+- Registry Notary rejects startup config when a peer's `evaluation_scopes`
+  omit a `required_scopes` entry from an allowed profile's selected claim or
+  dependency closure.
 - `POST /federation/v1/evaluations` is not mounted unless federation is enabled.
 - Request bodies over `inbound_body_limit_bytes` are rejected before full body
   buffering and before JWT parsing.