prohibition around "passing through" claims from evidence to attestation results

[thomas-fossati]

In §4.3 we say:

[...]
They may appear in evidence or attestation results. When these claims
appear in evidence, they SHOULD NOT be passed through the verifier into
attestation results.

I understand the reasoning behind the prohibition, but the prose needs to be tightened up a bit.

First of all, this applies to attestation result that are themselves encoded as a EAT.

Secondly, it only applies in case the evidence claims would end up at the top-level in the EAT claims-set rather than in their own clearly segregated space (e.g., in a sub-map).

If the two condition hold, these claims MUST NOT (rather than SHOULD NOT) be copied as-is, because the EAT carrying attestation results could have its own and they would clash.

---

Note: In our EAT attestation result we do copy the evidence profile claim, but that's completely separate from the top-level EAT profile so there's no clash nor ambiguity.

[gmandyam]

Added 'wontfix' label for now, but please take this to the WG to ensure consensus before making this a MUST requirement.

[gmandyam]

When using the FIDO model for Relying Party (as an example), the verifier is within the boundary of the RP and can process top-level claims, yet may still be relayed as is within the RP context. It is up to the implementation, as FIDO certification programs place no such requirement on existing attestation formats. However, making this a "MUST NOT" requirement (at least without considerably more explanation than what has been proposed in this issue) may mislead developers in the FIDO context - if the claim is passed as is within the RP security boundary from an integrated verifier then it does not appear to have any drawback. Since EAT is meant to target different standards and associated ecosystems (e.g. FIDO, GlobalPlatform, etc.), the SHOULD requirement appears to be sufficient.

[thomas-fossati]

Thanks for articulating the FIDO use case.

What about:

MUST NOT unless:
* [FIDO-like situations]
* [evidence claims are segregated and therefore cannot clash with AR claims]
* [AR is not in EAT format and therefore there is no clash risk]

What is missing is a rationale for allowing exceptions, which should be present (or self-evident) when a SHOULD is used.

[carl-wallace]

Four ways forward have been discussed:

• Change SHOULD NOT to MUST NOT
• Augment SHOULD NOT to require a profile to describe why SHOULD NOT is ignored
• No change
• Remove 2119 language from 4.3

[thomas-fossati]

Four ways forward have been discussed:

• Augment SHOULD NOT to require a profile to describe why SHOULD NOT is ignored

☝️

[laurencelundblade]

I've proposed removing the sentence entirely and relying on 1.3.1 in #360. Read the PR for more justification.

[laurencelundblade]

Fixed with #360