TM status response with more details

[eduperottoni]

I know each profile can define adittional claims in Trust Mark Status Response as described in the text, but I think this first version of the specification should define how to embeed the revocation reason on this response, as it's done in the Federation Historical Keys Response. Maybe defining a new and OPTIONAL reason claim to explain the status claim value? This claim may be used on both invalid and revoked situations.

Thinking about the implementation point of view, it seems very useful while it seems very simple to solve, avoiding interoperability issues.

I can write the text and create a PR if you agree with this idea.

Thanks so far!

[selfissued]

If we do this, I believe it should be parallel https://openid.net/specs/openid-federation-1_0-44.html#hist-keys-reasons, which defines reason codes and their meanings. What revocation reasons should be defined? And what reasons should be defined for a Trust Mark to be invalid?

[teamktown]

here's rfc5280 and it's reasons.

if there are only 3 in the OpenID Fed spec, it may not carry the same fidelity as rfc5280.

@selfissued : What revocation reasons should be defined?

if inspired by 5280, why not mirror them and leverage prior work thus gaining more fidelity of what happened?

• The reason is an after the fact statement/signal. The keys have already changed.
• Having reasons are signals that can enhance trust fabrics resilience and responsiveness for robust operations.
  It is often during moments when the keys / CA's change that continuity of trust is challenged or not propagating as expected because it is blind to the rationale and relies on external cues which do not exist whereas this can internalize the cues.
  It should be up to the ecosystem how maintain validity of trust and how it can adjust to different events as seen in the reasons field.
• Otherwise every change is treated with equal gravitas, which may be just a shrug of the shoulders that keys changed with no insight or criticality when it deserves it.

@selfissued : And what reasons should be defined for a Trust Mark to be invalid?

• Given trust marks can be nearly anything, it would also mean the reason could be anything.
• I suggest we rely on the validation process for trust marks for now and wait for operational needs from usage, if any at all are needed specifically for trustmarks.
• this means a jwt is valid or not, and when valid contains trustmark(s), or not with no 'reason' if a trustmark ceases to be present and the consumer of said information acts accordingly.

Summarizing

• I lean to being informative and use rfc5280 for ecosystems where they can choose how to respond to key events
• wait to see how trustmark managment unfolds through usage; do not define reasons for trustmarks.
• Do not define behaviours for reasons; defer them to ecosystem operators what to do and that they be clear about it.
• Align to the rfc5280 handling for 'unspecified' 0 element statement commenting it should be absent instead of it's inclusion.

RFC5280:

`
The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation. CRL issuers are strongly
encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value.

The removeFromCRL (8) reasonCode value may only appear in delta CRLs
and indicates that a certificate is to be removed from a CRL because
either the certificate expired or was removed from hold. All other
reason codes may appear in any CRL and indicate that the specified
certificate should be considered revoked.

Cooper, et al. Standards Track [Page 69]

RFC 5280 PKIX Certificate and CRL Profile May 2008

id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }

-- reasonCode ::= { CRLReason } CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
`