ear.status or ear.all claim inside EAR

[dhawalfs1]

Currently, EAR is defined as follows. There is no mechanism to specify claims that are common to all submods to enable a simplified appraisal by relying party. Some examples of claims that can make sense inside EAR are

1. ear.status: Overall status across all submods
2. oemid, hwmodel and dbgstat as defined in EAT spec

It may be OK to emit the above claims only when it has same value across all submods. Would claims such as above or an ear.all claim be standardized by spec or expected to be the charter of profile?

The idea with ear.all claim is to allow profiles to define which all claims to add inside it even if they are not standardized by the spec. ear.status, oemid, hwmodel and dbgstat can all go inside ear.all.

EAR = {
  eat.profile-label => "tag:ietf.org,2025-07:ear"
  eat.iat-claim-label => int
  verifier-id-label => ar4si.verifier-id
  ? raw-evidence-label => eat.binary-data
  eat.submods-label => { + text => EAR-appraisal }
  ? eat.nonce-label => eat.nonce-type
  * $$ear-extension
}

[thomas-fossati]

I am not sure that the proposal fits well with the current design. The top-level EAR is not intended to capture information that may be common to the various component attesters (i.e., information that is redundant across the different EAR appraisal submods).

Additionally, it seems that the cited oemid, hwmodel and dbgstat may be shared or not, depending on the assembly of the composite attester. With trusted devices in particular, the HW identity tends to differ from that of the hosting platform.

If necessary, a deployment could achieve the same by designating a special EAR-appraisal submod (e.g., “top-level”, “common”, or similar) for this purpose.

[thomas-fossati]

Re: global ear.status. I believe that adding this to the top-level container is a sensible request that aligns with the spirit of the EAR as an RP-friendly attestation result format.

[thomas-fossati]

Request 1 has been assigned its own issue (#59).

Request 2 needs more discussion.