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) }
`

[teamktown]

Followup from the call with the pdf and example markdown to iterate on the possible flow

openidfed-nov24-reasonSignals.pdf

Mermaid Markdown that produced the attached pdf:

``

Simplified Reason handling of key rollover

flowchart TD
    subgraph OP["Operator or Trust Anchor"]
        A[Start Key Rollover] --> B{Define Rollover Intent}
        B -->|Scheduled| C1[reason scheduled_rotation]
        B -->|Emergency| C2[reason unscheduled_emergency]
        B -->|Suspected Compromise| C3[reason suspected_compromise]
        B -->|Deprecation| C4[reason deprecation_replacement]

        C1 --> D[Add reason to historical key entry]
        C2 --> D
        C3 --> D
        C4 --> D

        D --> E[Publish updated Entity Configuration with new key]
        D --> F[Publish updated Historical Keys JWT]
    end

    subgraph Federation["OpenID Federation Resolution"]
        E --> G[Clients fetch entity configuration]
        G --> H{Old key missing}
        H -->|Yes| I[Client calls historical keys endpoint]
        H -->|No| Z[Continue using current key]
        I --> J[Historical Keys JWT with reason codes]
    end

    subgraph RP["Relying Party or AI Client"]
        J --> K{Evaluate reason code}
        K -->|scheduled_rotation| L1[Normal Acceptance Path]
        K -->|unscheduled_emergency| L2[Enhanced Scrutiny\nshort TTL and operator alert]
        K -->|suspected_compromise| L3[Reject or Quarantine\nSecurity Response]
        K -->|deprecation_replacement| L4[Graceful Migration\nUse fallback key]
    end

    L1 --> M[Continue Normal Operation]
    L2 --> M
    L3 --> M
    L4 --> M

Loading

Reason code handling identical to rfc5280

Noted during Nov24th OIDF Connect A/B call:

• not all items may have merit to be included in OpenID Federation Key Roll over reasons such as removeFromCRL

flowchart TD

    subgraph OP["Operator or Trust Anchor"]
        A[Start Key Rollover] --> B{Select CRLReason from RFC5280}
        B -->|keyCompromise| C1[reason keyCompromise]
        B -->|cACompromise| C2[reason cACompromise]
        B -->|affiliationChanged| C3[reason affiliationChanged]
        B -->|superseded| C4[reason superseded]
        B -->|cessationOfOperation| C5[reason cessationOfOperation]
        B -->|certificateHold| C6[reason certificateHold]
        B -->|removeFromCRL| C7[reason removeFromCRL]
        B -->|privilegeWithdrawn| C8[reason privilegeWithdrawn]
        B -->|aACompromise| C9[reason aACompromise]
        B -->|unspecified| C10[reason unspecified]

        C1 --> D[Add reason to historical key entry]
        C2 --> D
        C3 --> D
        C4 --> D
        C5 --> D
        C6 --> D
        C7 --> D
        C8 --> D
        C9 --> D
        C10 --> D

        D --> E[Publish updated Entity Configuration with new key]
        D --> F[Publish updated Historical Keys JWT containing CRLReason]
    end

    subgraph Federation["OpenID Federation Resolution"]
        E --> G[Clients fetch entity configuration]
        G --> H{Old key missing}
        H -->|Yes| I[Client queries historical keys endpoint]
        H -->|No| Z[Continue with current key]

        I --> J[Historical Keys JWT returned with revoked reason]
    end

    subgraph RP["Relying Party or AI Client"]
        J --> K{Evaluate RFC5280 reason}
        K -->|keyCompromise| L1[Reject or quarantine\nTrigger security response]
        K -->|cACompromise| L2[Reject or quarantine\nOperator escalation]
        K -->|affiliationChanged| L3[Graceful migration]
        K -->|superseded| L4[Normal rollover acceptance]
        K -->|cessationOfOperation| L5[Stop usage\nOperator review]
        K -->|certificateHold| L6[Temporarily disable trust]
        K -->|removeFromCRL| L7[Reenable if appropriate]
        K -->|privilegeWithdrawn| L8[Disable trust\nPolicy enforcement]
        K -->|aACompromise| L9[Reject and isolate]
        K -->|unspecified| L10[Handle as ambiguous event]
    end

    L1 --> M[RP continues with policy based on reason]
    L2 --> M
    L3 --> M
    L4 --> M
    L5 --> M
    L6 --> M
    L7 --> M
    L8 --> M
    L9 --> M
    L10 --> M

Loading

``

[RalphBragg]

I'm supportive of adopting the same reason codes in RFC5280 as a base set of reason codes. Purely as FYI; from running PKIs as part of our federation controller the vast majority of participants decline to actually select a valid reason code and simply set unspecified. Whether this is out of a genuine desire to avoid giving the reason even when it's obvious or simply because 'unspecified' is the first in the drop down list of our UI i'm unsure.

[Razumain]

Being one of the authors of RFC 5280, I would like to challenge whether introduction of reason codes for Trust Marks is necessary and part of a reasonable service contract of Trust Marks.

The RFC 5280 reason codes are related to the trustworthiness of keys so that when you validate or use cryptography that involves these keys, that you can draw conclusion on risk and trust.

A Trust Mark is a statement of conformance by an entity with respect to a set of requirements. That statement is bound to an identity, but NOT to a particular key.

When a certificate is revoked, then that particular instance of the certificate is revoked. If the same subject has 5 certificates for the same key, then all these certificates must be revoked.

Revocation of a Trust Mark is NOT bound to a particular JWT (instance) but revokes all statements of conformity issued for this subject.

As a conclusion. The act of revocation may have nothing to do with keys, but simply is a conclusion that this subject is no certified to conform to the stated requirements.

When creating the concept of Trust Marks, we only created a way to issue statements that attest that a subject has been awarded such Trust Mark. We did NOT design this concept to communicate any precise reason why such attestation can be recalled. And doing so in any meaningful way is a complex task that requires far more care than copying RFC 5280 revocation codes.

Please do not do this for Trust Mark status responses.

[Razumain]

I'm supportive of adopting the same reason codes in RFC5280 as a base set of reason codes. Purely as FYI; from running PKIs as part of our federation controller the vast majority of participants decline to actually select a valid reason code and simply set unspecified. Whether this is out of a genuine desire to avoid giving the reason even when it's obvious or simply because 'unspecified' is the first in the drop down list of our UI i'm unsure.

I think this is as with many things we did with PKI that was engineered in the 90s. We thought that computers were more like people who obviously would be curious to know why a key was invalidated.
But in reality, we only have 2 trust statuses for a key, and that is trusted, or not trusted. The importance is to revoke the key. Setting a particular reason, has no or very little practical implications. Except for the on hold status, that is the only status that can be reverted.

[teamktown]

I'm supportive of adopting the same reason codes in RFC5280 as a base set of reason codes. Purely as FYI; from running PKIs as part of our federation controller the vast majority of participants decline to actually select a valid reason code and simply set unspecified. Whether this is out of a genuine desire to avoid giving the reason even when it's obvious or simply because 'unspecified' is the first in the drop down list of our UI i'm unsure.

I think this is as with many things we did with PKI that was engineered in the 90s. We thought that computers were more like people who obviously would be curious to know why a key was invalidated. But in reality, we only have 2 trust statuses for a key, and that is trusted, or not trusted. The importance is to revoke the key. Setting a particular reason, has no or very little practical implications. Except for the on hold status, that is the only status that can be reverted.

@Razumain great to hear from one of the authors of 5280!
I'm in alignment on:

• the key having 2 trust status (trusted, untrusted)
• ensuring the key is appropriately revoked.
• Trustmarks not well equipped for Reasons of revocation as you describe

I differ on the 'no or very little practical implications' on setting the reason however.

It matters because relying parties cannot safely infer operator intent when keys change. Federation magnifies asymmetric responses to change events that could vary wildly. Offering a Reason in the historical record for the keys is a way to inline machine machine-readable signals that are not dependent on external/human co-ordination and reduce chaotic or unknown entity behaviour.

If no reason is provided key compromise, misconfiguration, scheduled rotation, and expiration all look identical at precisely the moment trust is most fragile.

The PKI from the 90's has been foundational in Federation bi-lateral and multi-lateral models and continues to be. Differentiating value though is how someone operates it for a given ecosystem. It cannot be a one size fits all model or kick it to somewhere else out of band where it would be undefined and can slow adoption as a result.
Reasons in historical keys offers flexibility for approaches of do-as-has-been-done-before and remain silent OR offer Reasons for the change in an ecosystem allowing more predictable behaviours in a world where automation, AI and other contexts existed and new ones are to come (MCP, A2A, autonomous clients etc)

[Razumain]

@teamktown This is indeed an interesting discussion. And I can agree to much you say.

But I guess my experience is a bit more pessimistic with regard to the usefulness of subjective policy enforcement data in protocols.

Subjective policy enforcement data (such as a reason code) is useful to support information to humans as means to support logging and debugging, as long as it does not give away information that can be used to attack the system.

However, the machine processed trust decision is binary and should be very predictable based on solid rules. That basically means. Revoked = not trusted. Not revoked = trusted. And that's it.

The question we have to ask ourselves here is: Is the service contract of the Trust Mark status endpoint such that it motivates a declaration of reason why a certain subject does not have a particular Trust Mark any more?

I say NO. There is no such obligation and not even a clear value that merits the complexity of defining how relevant reason data should be communicated. It is not needed for the binary trust decision. Any investigation to why a status has changed can be done out of band.

For historical keys, I don't really care. We don't intend to implement or use that endpoint anyway.

[selfissued]

I'd like to hear what others think on this interesting topic: @rohe @peppelinux @zachmann @MichaelFraser1999 @lj-raidiam @jcmelati @cicnavi @ve7jtb @surfnet-niels @fmarino-ipzs @TakahikoKawasaki @leifj - your thoughts?

As a reminder, WGLC for proposed Final status runs until Thursday, December 4, 2025. If we don't have consensus on what to do for this issue by then, we will likely defer it, since adding a reason field could be done as a non-breaking extension later.

[cicnavi]

I see Trust Marks as business-level / implementation-level assertions, and so would expect business-level / implementation-level reasons for revocation. I'm not sure about the value of it, however wouldn't mind having it as optional. In general, my thoughts are in line with what Razumain said.

For keys, I think it is valuable to have the reason (despite not being utilized, as some of you mentioned).

[zachmann]

I'm open to have an optional reason field on the trust mark status response analogous to the historical keys endpoint. I think there should be a small number of defined reasons (non-exhaustive).

At the same time I think that implementations will (mostly) not care at all about the reasons. For the implementation it's only relevant if something is valid or not.

[fmarino-ipzs]

Trust Marks may represent bilateral agreements between parties, often with domain-specific conditions. Detailed revocation reasons might be too specific to standardize generically and could be outside the core Federation protocol scope, as parties tipically handle these through out-of-band mechanisms (contracts, custom dashboards, notifications).

That said, I'm not against introducing this as an OPTIONAL parameter. If implemented, the reason values should follow a standardized vocabulary (similar to Historical Keys in Section 8.7.3) to ensure interoperability. This would also improve consistency with the Federation Historical Keys Response pattern (Section 8.7.2).

[selfissued]

This was discussed on the 8-Dec-25 working group call. @teamktown advocated not trying to rush an untried solution into the final spec. Rather, we should define it in a non-breaking extension and gain experience with it.