v3.0 Fraud Prevention Headers released

[MrSent]

It seems that HMRC have released an updated fraud prevention header specification to make things even more difficult.

https://developer.service.hmrc.gov.uk/guides/fraud-prevention/

I get the odd email from them regarding the FPH and they complain about 2 things. The first is the IP addresses. They say that they are invalid. I keep trying to tell them I have no control over my customer's network infrastructure.

The second thing I get moaned at for is that they say that some of the required FPH values aren't being percent encoded. My biggest issue is that I have found about 5 or 6 different ways to percent encode the data and they're all slightly different. Any thoughts on how you decide which method to use? It isn't like HMRC are giving anything away on the subject.

[oobayly]

I've finally had time to dive back into this, plus now with them making the headers mandatory in July.

I've finished testing a new version of the library with the new headers. It makes the following changes:

• Add gov-client-local-ips-timestamp header with associated LocalIPsTimestamp property. This is auto-populated with the current time, and is also updated when calling PopulateLocalIPs
• Update format for gov-client-user-agent. I sent a snotty email to them asking whether we can "expect this to be the final format to be used for this header?"
• Add gov-vendor-product-name header with associated VendorProductName property

As for the IP addresses, if you're having issues then you may have to populate them manually. PopulateLocalIPs just uses all the IPv4 addresses and linklocal IPv6 addresses. Is it possible the machine has a public IP address? Or can you give me some examples? This isn't a warning we've had and we have a dual-stack network here.

As for percent encoding, the library should be encoding everything. If you can give me an example of what's not being encoded that would help.

[oobayly]

As for percent encoding, the library should be encoding everything. If you can give me an example of what's not being encoded that would help.

Apologies, I got over and discovered that a few headers weren't being percent-encoded, namely:

• Pure string values
• UserAgent
• Forwarded IPs (IPv6 addresses may contain non-ASCII characters)

[Farewell-debug]

Hi, I am invoking TestFraudPrevention and my reply contains a ValidateErrorWEB saying Server Token cannot be empty - HMRC have confirmed server token was deprecated on 1 September 2020.

[wapenshaw]

@Farewell-debug I fixed this by changing this line

TipsTrade-HMRC/TipsTrade-HMRC/Api/TestFraudPrevention/Model/ValidateRequest.cs

Line 8 in 848698f

Authorization IApiRequest.Authorization => Authorization.Application;

to

Authorization IApiRequest.Authorization => Authorization.User;

@oobayly

Seems like they added new headers, PublicIpTimestamp

https://developer.service.hmrc.gov.uk/guides/fraud-prevention/connection-method/web-app-via-server/#gov-client-public-ip-timestamp

Also percent encoding of headerValue throws an INVALID_HEADER error when using the Validate() function

ref

TipsTrade-HMRC/TipsTrade-HMRC/AntiFraud/AntiFraud.cs

Line 233 in 848698f

headerValue = HttpUtility.UrlEncode(str); // string are enumerable so catch them here