Error in Trust Mark status response (8.4.2)

[Razumain]

The description of the Trust Mark status response is not logically consistent.

The text states:

A successful response MUST use the HTTP status code 200 with the content type application/json. The response body is a JSON >object containing the data below:

active

REQUIRED. Boolean. Whether the Trust Mark is active or not.

If the response is negative, the response is as defined in Section 8.9.

This is not consistent.

It is stated that the “active” parameter indicates if the Trust Mark is active or not. This implies that it is valid to respond with a value of “false” if the Trust Mark is not valid.

Then it is stated that a negative response should be provided as defined in section 8.9 (Error responses).

However, the error responses has no means to provide the “active” result. It only returns an error code and a description. And no error code is relevant to a non-active response.

This text should either specify that a negative response (active = false) is a normal response and not according to 8.9. Or it should state that “active” only is used to indicate a successful response if the Trust Mark is valid. The current text makes no sense.

I suggest that a negative response or a positive response are both normal responses (Http status 200) and not according to 8.9. Section 8.9 error responses are only applicable if there is some error in the processing of the request.

This is our code. And I think it is correct:

    boolean valid = hasValidTrustMark(trustMarkId, subject);
    try {
      return new EndPointResponse<>(objectMapper.writeValueAsString(Collections.singletonMap("active", valid)));
    }

[Razumain]

I think there is a deeper underlying problem here that drives the issue, that should be clarified in the standard.

The question is what it means to indicate that a Trust Mark is "active"?

1. A particular issued Trust Mark JWT is currently valid, or
2. The subject has this Trust Mark

Whether you interpret the standard as 1 or 2 will render different responses in some situations, for example if you ask the status with a certain issue time or a particular Trust Mark JWT that has expired, while the subject has the Trust Mark and all you need to confirm that is to download a new Trust Mark.

I think it would be a misstake to treat Trust Marks as X.509 certificates, where each issued token is retained and revoked separately, and it is kind of hard to see the value that comes out of this overhead.

I can only see a value in knowing if the named subject has a particular Trust Mark, or if that Trust Mark has been revoked. That means that revoking a Trust Mark is equivalent to removing the subject from the list of approved subjects for that Trust Mark.

An "active" response only states that this Trust Mark is granted for this subject. Nothing more and nothing less. I you want to validate a single Trust Mark JWT, you have all information in the JWT (signature, expiry date and so on).

Treating it this way adds a freedom to issue Trust Mark JWT with shorter expiry dates, keeping information on revocation at a minimum. If revocation is handled on a per JWT basis, short-lived JWT:s fast becomes unmanageable.

The standard should be more clear of what the intention is.

[Razumain]

There should also be a clarification of the response in case "iat" or "trust_mark" is provided in the request. Does this make the response tied to the particular JWT, or is the response only an indication that the subject has this Trust Mark.

See separate issue on the "iat" parameter.

I think it would bring a lot more clarity to the specification if the response was clarified to indicate whether the subject has this trust mark, and the request was limited to "sub" and "trust_mark_id"

[rohe]

A Trust Mark is "active" if it has not reached its expiration time and has not been revoked. What kind of expiration times an issuer wants to chose is very much dependent on what kind of trust mark it is. For those trust marks that have a very short lifespan the issuer may not bother with revocation. For the ones that have very long (infinit) lifespan you definitely want to have the possibility to revoke the trust mark.

You really need both sub, trust_mark_id and iat to uniquely find a specific trust mark. iat together with trust_mark does not make sense since iat is present in trust_mark. If they both are given and the iat values are equal an error should be raised.

I agree we should think about having active=false as a 200 response.