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.

[selfissued]

Note that #109 removed the trust_mark parameter. The rest of the issue, such as having active=false as a 200 response is still pertinent.

[Razumain]

I still sense here that there is a conceptual ambiguity if the "true" response indicate:

1. If the entity has been assigned this Trust Mark ID
2. If the insane of a particular Trust Mark JWT is valid

This is relevant if the Trust Mark JWT can have a shorter validity time than the assignment of the Trust Mark ID.

Say that the entity is authorised to assert identity at LoA 3. This is represented by the Trust Mark id https://example.com/loa3 That assignment does not have any end date. It is assigned until withdrawn.

The Trust Mark issuer issue Trust Mark JWT:s for this trust mark with a 1 week validity, and re-issues them whenever requested. This is basically how we do this to avoid complex and long revocation lists.

So when our Trust Mark endpoint is asked bout the status of a Trust Mark, we respond "active" if the entity is currently assigned this Trust Mark ID. We completely disregard when any issued Trust Mark JWT expires. That is not even part of the question.

As such, the iat consequently serves no purpose as it has no influence on the response.

IF we understood this wrong, and all responses should be concerning the validity of a particular JWT, then I see this as a major problem. Our service would have to store every issued JWT, and I fail to see the benefits.

Whatever the intention is, it should be clarified.

[rohe]

This is my take on the trust mark status response.

To begin with a totally agree that negative responses (active=False) and positive responses (active=True) are both normal responses.

Regarding the other issues.

1. In its simplest form a trust mark represents A vouching that B fulfils C.
2. A slightly more complex form is A vouching that B fulfils C given D (a condition). D then being represent by one or more claims in the trust mark.

One example of the latter that surfaced recently is scoped identifiers. Such an identifier should be represented in the form "user@scope" where 'user' is a name-based identifier for the person and where the "scope" portion MUST be an administrative domain of the identity system where the identifier was created and assigned.

Here one could imaging the trust mark stating that B could issue scoped identifiers (C) but only for a limited set of domains (D).

Over time, whenever the set of domains changed a new trust mark should be issued and an old trust mark with an incorrect set of domains should then be revoked.

What will now happen when an entity encounters a trust mark of the kind described above. To begin with the trust mark might be ‘revoked’ because it doesn’t represent the correct state but at the same time the entity is still allowed to carry that type of trust mark. How would this be handled ?

I’d propose we should use iat for that. The complete set of parameters (sub, trust_mark_id and iat) identifies one specific trust mark. If iat is left out, leaving sub and trust_mark_id, those two could be thought of as pointing to the latest released trust mark for that combination of parameters. This would allow the trust mark issuer to revoke all but the last trust mark. Using the last issued as a signal that the subject is still allowed to carry trust marks of this kind.

To sum up:

• sending a Trust Mark status request with sub, trust_mark_id and iat, asks whether a specific trust mark is still valid.
• sending a Trust Mark status request with sub and trust_mark_id, basically asks whether the subject is allowed to carry this kind of trust mark or not.

[selfissued]

I propose to resolve this issue by improving the description of Trust Marks in the spec by including any information from @rohe's analysis in https://github.com/openid/federation/issues/25#issuecomment-2535363549 that is currently not clearly described in the specification.