wasp
Experian's "WASP" ("Web Access Security Protocol") system uses mTLS to issue auth tokens for use with other Experian services (like "iCache").
Usage
Base URLs:
cert := `
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
`
key := `
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
`
baseURL := "https://secure.wasp.uk.experian.com/"
client, err := wasp.NewClient(baseURL, cert, key)
token, err := client.Login(context.Background(), "test")
The resulting token can be used with other Experian services. These tokens do stop working (through expiry, revocation, replacement etc). Speculatively, it appears they may last for 9 hours, but there is no way to know this for sure.
If the Experian service you are calling indicates the auth token is not valid, you should run the WASP login process again. If attempting the request 1-2 times more with new tokens does not work, you should not keep trying forever.
Client certificate
You'll need a client certificate to use in the mTLS process. Experian will provide you with a "reference number" and "authorisation code" to obtain this.
Generate certs here:
You can use OpenSSL to generate your CSR and convert your certificate and private key into PEM format.
It is possible to take a private key generated by Experian and avoid using your own CSR. That is intentionally excluded from this documentation, as it is poor practice.
Sources
Built against the Experian PDF doc titled "Web Services" and "Deployment Guide for Certificate Access". If you are integrating, you should have been provided with this doc or similar.
Info can also be seen here: https://secure.wasp.uk.experian.com/WASPAuthenticator/tokenService.asmx?op=LoginWithCertificate
And the WSDL file here: https://secure.wasp.uk.experian.com/WASPAuthenticator/tokenService.asmx?wsdl
Notes
The checkIP
field is always set to true, as it does not appear to be valid to use the system while it is set to false.
The application name input is an arbitrary string. You should set it to something meaningful indicating the source of requests using the resulting auth token, so it can be useful for auditing.
Although the resulting auth token is clearly hex (e.g. 00-1A-FF
etc), it should be treated as an opaque string. When using the auth token, you should base64-encode the string as-is - don't decode the token first.
There is no proper way to determine whether the request to generate the token was actually successful - the structure, headers and status of the response are the same even if an error is returned. As such, a simple case insensitive search is done for the term error
in the auth token. It is possible that this will prove to be insufficient.