Feedback: More strongly typed errors as means to provide better diagnostics

[ricardofandrade]

Not always the error message coming from SAML makes sense in a broader context.
That's where our application sometimes struggles to offer a better diagnostic for users.

One example is the error that occurs when the configured signing certificate (in the IdP metadata) differs from the one in the received assertion:
cannot validate signature on Response: Could not verify certificate against trusted certs

The message seems sufficient in the context of SAML but we'd love to offer more insights for a quicker resolution, for example stating that metadata may need to be updated.

There's always room for improvement in error messages but we have no expectation that this package be responsible for provide such high level diagnostic in all cases. However, providing means for applications to handle errors selectively seems something within the reach of the package.

Currently to achieve this goal, we would have to watch for a particular error message with a logic based on string matching, which tends to be fragile. Instead, we'd rather match a particular error type.

In the last few years, the Go community has been moving in that direction:
https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
https://golang.org/doc/go1.13#error_wrapping
https://github.com/golang/go/wiki/ErrorValueFAQ

There are few examples of this pattern in the existing code:
https://github.com/crewjam/saml/blob/master/service_provider.go#L421
https://github.com/crewjam/saml/blob/master/service_provider.go#L405

We're looking forward to see more of those.

P.S: I made the same suggestion to russellhaering/goxmldsig#53 which originates the error message mentioned above.

[crewjam]

This sounds great! :)