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

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.

Comments (4)