Investigate top-level evidence format options

[thomas-fossati]

The available options are (at least):

• EAT using the cmw claim
• Signed CMW (either using JOSE or COSE)

Dimensions to evaluate:

• ability to include nonce and other freshness-related information (e.g., epochs, timestamps)
• ability to include relevant metadata
• ability to include verification key material

[thomas-fossati]

EAT

freshness indicators	relevant metadata	verification key material
top level eat_nonce	via existing or "private" claims	in- or out-of-band via usual JWT/CWT methods (x5c, kid, etc.)

The EAT claims-set could be composed as follows:

{
  "eat_profile": "tag:github.com,2025:veraison/ratsd",
  "eat_nonce": "MIDBNH28iioisjPy",
  "iss": "ratsd",
  "exp": 1300819380

  "cmw": {
    "sub-attester A": [
      "application/...",
      "base64encoded"
    ],
    "sub-attester B": [
      "application/...",
      "base64encoded"
    ]
  },
}

The verification key material would go in the JWT/CWT header, either self-contained, using the x5c header:

{
  "x5c": [
    "MIIDqjCCApKgAwIBAgIESLNEvDA...",
    "MIICwzCCAasCCQCKVy9eKjvi+jA...",
    "MIIDTDCCAjSgAwIBAgIJAPlnQYH..."
  ],
  "alg": "RS256"
}

or using a kid that needs to be de-referenced on the JWKS endpoint, that we'd expose via https://ratsd.example/.well-known/ratsd/jwks.json

{
  "kid": "1234567890",
  "alg": "RS256"
}

Notes

• CMW labels ("sub-attester A", etc.) in the example are completely arbitrary.
• The eat_nonce claim has strict upper bounds (JSON: 88 bytes, CBOR: 64 bytes), which may be incompatible with "epoch marker" payloads, which tend to err on the hefty side. However, it is reasonable to assume that epoch markers will register their EAT claim(s).

[thomas-fossati]

Signed CMW

freshness indicators	relevant metadata	verification key material
nonce parameter in the protected header (RFC8555). Alternatively, use RFC9597 to embed an UCCS with only an eat_nonce claim in it	via existing or private JOSE/COSE headers	in- or out-of-band via usual JWT/CWT methods (x5c, kid, etc.)

The CMW would be composed as follows:

{
  "__cmwc_t": "tag:github.com,2025:veraison/ratsd",
  "sub-attester A": [
    "application/...",
    "base64encoded"
  ],
  "sub-attester B": [
    "application/...",
    "base64encoded"
  ]
}

The freshness indicator would be carried in the protected header using the nonce parameter:

{
  "nonce": "base64urlencoded"
}

The verification key material would go in the JWT/CWT header in the same way as done for the EAT.

Notes

• The nonce claim is only available in JWS. For CBOR, RFC9597-style headers can be used as described in the table above.