Monitoring

A client receives an error response from a server, and in the report, as the server_message request parameter, sends something other than the content of its developer-message element.

But the specification says that is should be: "Error description received from the server. This parameter MUST be passed if the server returned a 4xx or 5xx status code along with an <error-response> element, in which case the passed value MUST be the content of the <developer-message> element, as defined in the common-types.xsd file. The parameter MUST be empty otherwise."

LOW

• A full error response XML, for example: "<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <error-response xmlns="https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd "> <developer-message>Internal Server Error</developer-message> </error-response>"

• A developer message along with its XML tags, for example: "<developer-message>Unkown client keyId: [...]</developer-message>"

• A developer message with additional description from the client, for example: "Server returned HTTP 400 (Bad request): Missing required parameters."

• An HTTP code, for example: "500"

Enforce absolute compliance with the specification. If the server didn't return an XML or there is no developer message in it, leave the server_message parameter empty.

Monitoring system, email correspondence with providers.

Problem occurred for at least 7 providers.

A client receives an error response from a server, but it is an HTML instead of the usual error-response XML, and in the report describes the error as an issue with validating the response rather than an error returned by the server.

But error responses aren't strictly required to be XML. The specification for errors 4xx says that "the response SHOULD contain an XML content with the <error-response> root element" (not "MUST"), and for errors 5xx it only says that "the response MAY contain an XML content with the <error-response> root element".

LOW

Enforce absolute compliance with the specification. Report HTML error responses as normal errors returned by servers (with empty server_message parameter).

Monitoring system, email correspondence with providers.

Problem occurred for at least 4 providers.

A client receives an error response from a server, but it is missing an HTTP signature, and in the report describes the error as an issue with authenticating the response rather than an error returned by the server.

But error responses aren't required to be signed. The specification says:

• "If you are unable to do so, then you MAY fall back to sending your error response over regular TLS."

• "The clients SHOULD be prepared for both cases. The servers MAY send their error response bodies either encrypted or not encrypted; they MAY contain a HTTP signature, or they may not. However, all such responses will be sent over TLS (HTTPS)."

LOW

Enforce absolute compliance with the specification. Report unsigned error responses as normal errors returned by servers.

Monitoring system, email correspondence with providers.

Problem occurred for at least 2 providers.

A client receives a response from a server, but some field containing private data (like signer-email in the Outgoing Mobility Learning Agreements API's GET endpoint) fails validation, and includes in the report its invalid value in the client_message request parameter.

But even if malformed, such invalid value can still contain private data that shouldn't be included in the report. The specification says: "The message MUST NOT contain any private data."

MEDIUM

• "Phone number must be valid E.164 format phone number: +(**)*********"

• "Value of parameter Contact email (*******@****.** ) must not contain leading and/or trailing whitespace(s)."

Enforce absolute compliance with the specification. Don't include in your reports values from server responses for fields that can contain private data.

Monitoring system, email correspondence with providers.

Problem occurred for at least 1 provider.