[Rats] Re: draft-ietf-rats-multi-verifier-00: what a Lead Verifier can conclude from a Partial Attestation Result

[Yogesh Deshpande <[e-mail]>]

Hello Joe,

Apologies, I missed the complex Scenarios Design meeting due to UK Bank Holiday and hence missed some of your points.

I will try to infer from your email and try to clarify, at few places, with marker > YD

Regards,
Yogesh Deshpande

-----Original Message-----
From: Joel Hillier <jhillier=[e-mail]>
Sent: Friday, September 4, 2026 9:13 AM
To: [e-mail]
Subject: [Rats] draft-ietf-rats-multi-verifier-00: what a Lead Verifier can conclude from a Partial Attestation Result

Hi all,

I listened on the complex scenarios call and said I'd follow up in writing, so here it is. One observation on draft-ietf-rats-multi-verifier-00 and one offer. It's a revision item rather than an objection, and the document is specific enough to be tested this way at -00, which isn't the usual case.

> YD : Thanks for the detailed read, I appreciate your comments in general.

Quoted from the -00 text. Section 4, on the Component Verifier:

    A Verifier which is responsible for the Verification of one single
    component or a layer.

and on what it hands up:

    Attestation Results produced by a Component Verifier, which contains
    partial results from atleast one or more Component Attesters.

and on how that gets resolved:

    The overall verdict may be dependent on the Appraisal Policy of the
    Lead Verifier.

So a Component Verifier appraises one component, hands up a Partial Attestation Result, and the Lead Verifier's policy decides the overall verdict from those. The question the document leaves open is what that policy is reading.

> YD: The Component Verifier Appraises based on its Appraisal Policy. The Lead Verifier which is also responsible for generating the Overall (Integrated Result) will apply its own policy before constructing the
Aggregated Attestation Results (AAR)

A Partial Attestation Result carries a value, and several different conditions at the component produce the same value. The required property was measured and it matched. The measurement was absent and the Component Verifier's own Appraisal Policy permitted the absence. The component sat outside the scope that policy covers at all. Those want different actions from whoever consumes the aggregate, and a Lead Verifier branching on the value alone can't tell them apart.
> YD I am not clear of the exact scenario, may be the text jumbled up to clarify which aspect of Policy you are talking about a CV Policy Versus an LV Policy


The consequence is pretty narrow and testable. Two implementations built from this document agree on every input where those conditions coincide, which is every input an interop exercise naturally generates, because each participant pairs a component with the policy it was appraised under.
> Correct - For Identical Component Result output the Component Appriasal Policy Part also need to be Identical...

Separating them takes a vector built by someone who already knows the collapse is there. An interop matrix won't surface it, and neither will a conformance suite derived from the document, because the document doesn't ask the question.

Stated as a test:

    For each value the Lead Verifier's Appraisal Policy branches on,
    enumerate the distinct component-side conditions that can produce that
    value. If more than one of them wants a different action from the
    Relying Party, and the branch reads only the value, the aggregation is
    lossy at that point.

That yields a finding or it doesn't, and it's answerable against the text as written rather than against a deployment.

The offer. The ask on the call was for concrete cases first and the mapping to the abstract pattern afterwards, which is the right way round. I'll run the question above across the three patterns in section 5 and report which cells collapse distinct conditions into one value and which don't, carrying the reasoning for each cell rather than a verdict. Hierarchical and hybrid both name a Lead Verifier, so the question lands on them directly. Cascaded I expect to need restating, and I'll show the restated form instead of just adapting it. It's a reading of the document and not a deployment report, and it will say so on its face.

If the authors would rather have that as a pull request than as text on the list, tell me which and I'll follow it.

> YD, we would Welcome a PR from you to understand your viewpoint in a more clear manner.

Best,

Joel Hillier
Certisyn, Inc.

_______________________________________________
RATS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.