Non-expiring Trust Mark validation and status endpoint usage

[cicnavi]

As per https://openid.net/specs/openid-federation-1_0.html#section-7.1-2.11, Trust Mark claim exp is optional. If not present, Trust Mark does not expire.

As per instructions for validating a Trust Mark https://openid.net/specs/openid-federation-1_0.html#name-validating-a-trust-mark, we can check the expiration and signature of the Trust Mark OR use the Trust Mark Issuer status endpoint.

Is it really OK that "status endpoint" is optional for non-expiring Trust Marks? There could be cases of issued non-expiring Trust Marks that have been revoked. Maybe consider adding a note that in the case of non-expiring Trust Marks we should use status endpoint to check if the Trust Mark has been revoked or not.

[selfissued]

I believe it's up to the ecosystem rules whether to require that there be a Trust Mark Status Endpoint or not. And to define when to use it.

If we add a note about this, I'm prone to add something along those lines. Would that work for you, Marko?

[cicnavi]

Ahhh, so creators of generic libraries would have to enable choosing in which way to actually validate trust marks, so that a library can be utilized in different "environments"...

[cicnavi]

I'll just leave this here with a "fence" that I probably miss some facts about why things are done the way they are (you know that I'll do as you guys say things should be done :)...).

I feel uneasy about the fact that it is not required to check that Trust Mark is revoked. In my mind, Trust Mark validation would work like this:

• It would be required for Trust Mark Issuer to expose federation_trust_mark_endpoint (an endpoint used to issue Trust Marks).
• I wouldn't necessarily require that the whole Trust Mark token is present in trust_marks claim in Entity Configuration. Entity could indicate that it holds a Trust Mark like this:

"trust_marks": {
  "trust-mark-id": "trust-mark-issuer-id",
}

• Entity that wants to validate a trust mark for some entity would be required to use federation_trust_mark_endpoint on Trust Mark Issuer to try and get the Trust Mark. If it gets the Trust Mark, it validates its claims and signature as usual.

I see several advantages in this approach:

• As a validator, I'm sure that I have up-to-date information about the Trust Mark. I automatically know that this Trust Mark is active and not revoked.
• No need for dedicated federation_trust_mark_status_endpoint on Trust Mark Issuer.
• Trust Mark validation is deterministic, so no worry about how different vendors would do it in different environments.
• Entities don't have to bother with acquiring Trust Mark tokens. This is simple setting on their side (no requirement for storing trust marks to dedicated storage, no requirement for probably automated refreshing of short lived trust marks, etc.)

As I'm not aware of the downsides, please feel free to disregard this as irrelevant...

[peppelinux]

According to the privacy consideration section I am going to write for the resolution of this issue there might be cases when a trust mark issuer would not deploy the trust mark status endpoint because it issues short lived trust marks that do not require any revocation check mechanisms

revocation check mechanisms using the trust mark status endpoint might introduce the phone home issue

[peppelinux]

there might be interest in enabling ietf token status lists also for federation trust marks, technically nothing prevents a trust mark issuer to use a revocation status list for their trust marks.

[Razumain]

I'm smiling while reading the thoughts of @cicnavi because this is almost exactly what went through my mind while implementing this stuff.

The whole solution around revocation checking is confused and actually needs to be clarified and reviewed.

The core problem here is a lack of clarity what it means to have a Trust Mark and what it means to have it revoked. There are two different interpretations here and we have not clearly communicated which one we use:

• The X.509 certificate model: Each issued token (JWT) is considered a Trust Mark and each such JWT can be revoked independently from other Trust Mark JWTs that may refer to the same subject, trust mark issuer and trust mark ID.
• The compliance certification model: Each Trust Mark is a proof that you have been granted a certification that assert that you comply with a defined set of requirements. You can only revoke this certification, not individual signed proofs (JWT:s).

Now depending on what model you choose here, the technical solution for it is quite different.

Today we have a mix. It is sort of an indication of that you have been granted the right, but the protocol is sort of a validation of individual JWT:s. But it is not really clear.

I believe that it is crucial that we decide clearly on one model, and I believe that we need to choose the latter model (Not the X.509 certificate model with revocation of individual JWT:s.

The consequence of this choice is that it makes no sense to ask for a specific issue time, or to provide a specific JWT in a revocation request. All you need to send in a request is the subjectID, trust mark ID and possibly the issuer ID and ask for a signed proof of this trust mark.

And if you do this, it would indeed be better to just return a signed Trust Mark if this Trust Mark has been granted. One reason for this is that a Trust Mark is a signed response. The current revocation response is an unsigned response, and can't really be trusted. I actually think that the unsigned revocation response is a security flaw that should be discussed.

This is a long post. But here is what I think must be done:

• Clarify the concept. What does it mean to have a Trust Mark, and what is and can be revoked (the grant or the JWT)
• Remove the revocation checking, or upgrade it to provide a signed response indicating if this entity currently has been granted this Trust Mark ID.
• If revocation checking is removed, we simply ask for a new Trust Mark instead of asking for a signed validity response (which essentially is the same thing)

[zachmann]

I agree with Stefan that we should clarify the concept (and I also agree that we want the compliance certification model).

But I want to note the usage of trust marks as noted by Roland in #25 (comment) where trust marks include an additional value claim; this use case what complicate things a bit more.

I also think that it would make sense to have the general concept discussion in a separate issue.