-
Notifications
You must be signed in to change notification settings - Fork 5
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
Resolve Endpoint Error Response #136
Comments
If there are error conditions that you believe would be useful to signal to callers, please suggest their definitions in this issue. |
I can think of the following errors:
|
invalid sub and invalid trust anchor might be used also in the fetch endpoint while invalid trust chain and invalid metadata along with metadata policy error would be used in the resolve response I can do a PR for this, thank you @zachmann |
Yes the first two are more general, while the later two are more specific to the resolve endpoint. But I would say I welcome a PR. |
Note that we already have defined these error codes:
They could be construed as overlapping with |
It seems that we should harmonize the error codes defined at 8.9. Error Responses from Federation Endpoints and those defined at 12.1.3. Authentication Error Response. |
Indeed, I missed those. I agree that harmonizing makes sense. I think My understanding of the existing |
Very good points @zachmann I'd go for
|
I'm fine with the first three; |
I've updated the PR to reconcile the two different sets of error codes. Please review. |
The specification does not say much about the error response from the resolve endpoint, only that it follows section 8.9 "Responses from Federation Endpoints", which lists a few different error strings that SHOULD be used.
A resolver might limit its resolving service to only a (sub-)federation and not resolve every trust chain in the world.
In a hierarchical federation, entities therefore might want to query multiple resolvers.
In such a scenario it could make sense to have some error conditions standardized to ease the error handling.
Especially, it would be helpful to differentiate between the error cases where the resolver does not accept the request (e.g. because it does not support the specified trust anchor) and the case where it cannot find any valid trust chain.
Do you think it is in scope for the specification to specify the error responses in more detail (I would say it's enough to follow the principle of 8.9), or it's entirely up to the implementations?
The text was updated successfully, but these errors were encountered: