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

[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