Scheduled - Summary:
We are improving our API security. This message is relevant if you use our API.

18th of January we will phase out allowing invalid Accept headers to be communicated to our API. Please check your implementation for adhering to the http internet standards and our documentation.
Sending an Accept header for a message type we cannot and never could deliver will stop working.
We are not changing our API or removing backwards compatibility, but will strictly interpret API messages conforming to security specs.


Full message:

We are continuously improving our Signhost service with new verification methods, performance and keeping it up to date with the latest security standards. We are always striving to keep our API backwards compatible as we document it on https://api.signhost.com.

However, in the API so far we have always accepted requests that differed from what we have documented, as well as some requests that did not meet the HTTP standard and/or JSON.
API requests that do not meet the standards are not supported by us.

Because we want to be able to keep rolling out new features and we don't want to jeopardize the safety of our product, invalid requests will not be accepted anymore.
What has changed:

If there is a correct API implementation that adheres to internet standards such as HTTP/1.1 (RFC2616), ISO8601 and our documented Model types and properties then nothing will change. Our API remains as it was for you. We do not introduce a new version, the current version v1 will continue to work as it is. There is no v2 version of the API.

For reference version 1.1 of the HTTP standard can be found at https://www.w3.org/Protocols/rfc2616/rfc2616.html and is still supported by us.
Use the Model types and properties as documented and don't rely too much on example requests / responses.

We see a number of different invalid request types occurring to our API:
- a Content-Type header in a GET request to us, when you send us content of a whole differerent type (eg. JSON instead of PDF)
- null values in JSON
- Invalid Accept headers, where a type of message is requested which we cannot and never could deliver. (eg. docx. when requesting a signed pdf.)


What was done?
Our initial test of phasing out the Accept header workaround was reverted due to some unforseen issues on December the first.
Null values where succesfully phased out.
Invalid Content type GET requests will be phased out fully later in 2021. This will be communicated on this channel.
https://status.signhost.com/incidents/dr9lg69z0w1q

We have contacted customers who we suspect sending incorrect Accept headers, and advise all our API customers to double check a correct Accept header implementation.

Not sure what to do? If you do not specify an accept header, we are unrestricted in our response to your request and no issues will arise.

An easy way to test your outgoing headers is through a webhook test endpoint such as webhook.site.

Read more about accept headers here:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#:~:text=The%20Accept%20request%2Dheader%20field,for%20an%20in%2Dline%20image.
Dec 23, 10:40 CET

Maandag 8 februari van 0.00 tot 06.00 uur staat onderhoud van DigiD gepland. Release 5.18 wordt dan naar de productieomgeving gebracht. Gedurende dit onderhoud is DigiD niet beschikbaar.

Hieronder treft u de belangrijkste definitieve wijzigingen van deze release.

Release 5.18 | Definitieve wijzigingen

1. Gerichte melding bij niet-ondersteund besturingssysteem en/of browser

Update DigiD app
Logius verbetert de DigiD app continu. Een update van de app vindt plaats op maandag 15 februari 2021. De volgende wijzigingen worden doorgevoerd:

1. Nieuwe manieren voor het ontvangen van meldingen
2. App activeren met gebruikersnaam en wachtwoord
3. Extra aandacht voor uitvoeren ID-check
Posted on Jan 14, 09:21 CET

For our API implementations our customers are using postbacks to proactively process the transaction status.

We never recommended nor supported to perform IP address whitelisting for security, but some customers might use this method.
From end of February we will move our postback services and introduce flexible IP's. So any customer that still has this IP whitelisting configured , this is NOT POSSIBLE anymore from the end of February. Customers can use the checksum method.

Because we want to improve our security all the time we will introduce a new possibility to validate if the postback messages are coming from our environment. We will make it possible to configure security authorization headers in Q1.

See the full message and explanation of the new feature here.
here https://intercom.help/evidos/nl/articles/4739431-postback-header-security
Posted on Dec 21, 18:43 CET