-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in Trust Mark status response (8.4.2) #25
Comments
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"?
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. |
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" |
A Trust Mark is "active" if it has not reached its expiration time and has not been revoked. You really need both I agree we should think about having active=false as a 200 response. |
Note that #109 removed the |
I still sense here that there is a conceptual ambiguity if the "true" response indicate:
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 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. |
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.
One example of the latter that surfaced recently is scoped identifiers. 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. I’d propose we should use iat for that. To sum up:
|
The description of the Trust Mark status response is not logically consistent.
The text states:
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:
The text was updated successfully, but these errors were encountered: