The iat parameter in Trust Mark status requests creates great overhead for no good reason

[Razumain]

The Trust Mark status endpoint takes the issue time as an input parameter.

As the text is written now, the Trust Mark issuer would need to keep track of all issued Trust Marks.

In our implementation, we will issue a new Trust Mark whenever asked, without regard to whether a previous one already exists. There is a very good reason for that. This avoids a complicated algorithm that decides how long a valid TrustMark must be valid in the future in order to deliver it. If we don’t we could ship an existing TrustMark that will expire 1s later, and that is not very useful. By issuing a new one when requested, we make sure that it has the standard lifespan when it is sent.

In order to correctly process the iat parameter, we would have to store issue times for every TrustMark ever issued. And the response will not be very useful if the subject has the requested Trust Mark, but that particular JWT has expired.

In our usage, all the requester is interested in, is if the subject has this TrustMark at this moment in time. No more and no less. We do not plan to store all issued versions of that Trust Mark. It is the verifiers responsibility to check the expiration time. They don’t need the validation service to do that.

I see no legitimate reason for the iat parameter and suggest that it is removed. The status indication is not even assuming the latest issued Trust Mark. This would give a strange result if a status request would be sent for a subject who has that Trust Mark, but where no one has requested a JWT for it in a while. The status response would say false (The latest JWT has expired), but the subject has the Trust Mark, and a new fresh one can be requested.

At least I would request that The Trust Mark issuer is allowed to ignore this parameter if received.

Currently we have to reject all requests that includes iat.

[selfissued]

What is the current text in the spec that you believe causes Trust Mark Issuers to have to keep track of all issued Trust Marks?

[Razumain]

That is part of the problem. There is no discussion about this, but a reader can hardly draw any other conclusion.

If you don't keep track of previously issued Trust Mark, then what are you supposed to do if the "iat" parameter is provided?

The text also says that if "iat" is not provided, then the latest Trust Mark is assumed. That surely also indicate that you need to keep track of issued Trust Marks to know which is last.

I lack a clear description of what a user of this endpoint can expect from a response. Is this a request for the status of a subject in relation to a Trust Mark (i.e. does this subject have this Trust Mark) disregarding any particular issued Trust Mark JWT, or is this a validation service for a particular Trust Mark JWT (Like a X.509 certificate revocation service)?

If this the former (does the subject have this Trust Mark), then "iat" (or even "trust_mark") makes no sense. The requester can easily check if the JWT they have has expired, they don't need the validation service to tell them that. All they need to know is if the subject currently has been granted this Trust Mark.

I would personally prefer this to be clarified and the request parameters reduced to just "sub" and "trust_mark_id". Then we could also make this a GET in line with other endpoints and not require a POST.

If I would allow me to be really radical here. I would actually like to delete the whole Trust Mark Status endpoint. For me it is completely redundant and only adds complexity. The difference between returning the status, or just returning a fresh Trust Mark is trivial. If you want to know if a Trust Mark is valid, just ask for a new Trust Mark.

That of course requires the Trust Mark endpoint to be open to all entities. But I really can't se any compelling reason why it shouldn't be that. It's public information spread throughout the federation anyway.

This would materially reduce the complexity of providing and validating Trust Marks. But I assume that such radical changes is a no-go.

[zachmann]

In general I agree with @Razumain, however I would not be so radical to remove the trust mark status endpoint all together. I would say there's at least a semantic difference between asking for a trust mark status and asking for a trust mark. As you said I would expect the trust mark status endpoint to answer me the following question: "Does this subject have this Trust Mark?" I'm not interested in having the actual trust mark. Furthermore, it should be cheaper to answer to that question with yes or no than to issue and sign a new trust mark.

Anyway, I would suggest to remove the iat parameter. In my opinion it is enough to have the sub and trust_mark_id parameters and the trust_mark parameter could be removed as well. I would argue that the endpoint's purpose is really to answer the question if a certain entity is trust marked with a certain trust mark or not, not if an individual JWT is valid or not; therefore the trust_mark would only be used to extract the sub and trust_mark_id. It might be a shortcut for the client to have the option to request by trust_mark, but I think it is not necessary: we can expect the client to extract the information itself from the jwt and the client should already know in which sub-trust_mark_id combination it is interested.

I can formulate those things and submit a PR if the change is welcomed.

[zachmann]

Note that such a trust mark status endpoint would be similar to the trust marked entity listing endpoint used with a sub request parameter, except of the response format.

I would argue that the sub request parameter on the trust marked entity listing endpoint is then not needed or the trust mark status endpoint might not be needed.

[selfissued]

I'm not sure what you mean by "In order to correctly process the iat parameter, we would have to store issue times for every TrustMark ever issued." No processing rules are specified for "iat", so I don't know what processing you perform for it.

That said, it's normal for a JWT to indicate when it was issued. Having that information is a useful signal to recipients for them to use as they choose. Why should we not provide this signal?

[zachmann]

The statement relates to the iat request parameter of the trust mark status endpoint: https://openid.github.io/federation/main.html#name-trust-mark-status-request

The spec states:

OPTIONAL. Number. Time when this Trust Mark was issued. This is expressed as Seconds Since the Epoch, as defined in [RFC7519]. If iat is not specified and the Trust Mark issuer has issued several Trust Marks with the identifier specified in the request to the Entity identified by sub, the most recent one is assumed.

The last sentence implies that if the parameter is present the trust mark issuer should evaluate that specific trust mark; in order to do so it needs to keep track of the individual trust mark jwts.

[Razumain]

I agree with all of Gabriels comments here. I do think that just asking for a Trust Mark would work instead of asking for its status. The cost of doing that is minimal, but I won't insist. But I throw in one more argument.

Receiving a signed Trust Mark is a signed statement that can't be spoofed. An unsigned trust mark status response can. And this response can be security critical. Yes, we have TLS, but the TLS entity is seldom checked in implementations and compared with the expected source. We don't.