Issue in JWT signature validation with MLE

[aks]

I am trying to consume Visa card on file API using IBM DataPower. I have followed instructions on developer portal and it works good for me. Also I have seen Java sample code for MLE and JWT creation and found it good. However, when I hit the endpoint with my message, I am getting following response:

{
    "responseStatus": {
        "status": 401,
        "code": "9209",
        "severity": "ERROR",
        "message": "Token validation failed",
        "info": ""
    }
}

So the JWT token validation is failing at VISA end. Upon further investigation, it looks like VISA is expecting 'iat' to be a number but the one contained in my message is a string? Here is my JWT token:

{
    "encData": "eyJlbmMiOiJBMTI4R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2Iiwia2lkIjoiN2VlYzI1YmYtNjA4YS00YTliLWFiOTMtYzI1ZTU0ZGUxMzgzYiIsImlhdCI6IjE1NDAyMTAzOTI4NjYiLCJ0eXBlIjoiSldUIn0.YRkUEoKdtTNyc_vfPDu65OAFd7ul6MIVS_2xts2p9zrSg0F9Cnrew9lmrJZi-Vk3lBRqoK1iFP077q0u5lzOABkmRu8xWYFY04atlgUfiGTZ07TwW02yy-LEHS5qhuS1934O-ig2G4RzcBvvok1PXGVJQCig00O_GCT51VmcqnL_EZeg3ftUgStzX2L7vdy4V-dskfyBQo0pxECeWhAcinZ2n_ROyoSec18DZrNBFi8-oI-_wAGNhm4t6rXRwZ1FciQ_vjYQ37ecfLemKUqfdRoju9Zj6EKPY-dbvaNEbEZZyREzDeOLaDsNZpEAqefZSgAJi4QHo9jd9DdTTCwB0w.oFajG9QdtMPwWmXn.dXN5LIR0efxtXFYHWM7hO4j704UXVJvd-Pl8WJZ-5WC9xWJyI0caDKWoDQq-7q-vtUb6uW7P69eJJ9GbyI2TEkew_PDkEVnPcan49xqjIhtZNXV4UnXgtg2TsWMmWkldmWaP9Uvuzc6xi_4MEqPz5EwrkH3BB4cOA4pdhX_lTIdtew3fzuQ2EHAhXK7I20qetTlwpqhza3yRAh6dsiEe0-Y2zzit0t1u9kUIzfM4nNPutym-hQ.8axp6mYu2fpH7LE20XqbvQ"
}

I won't be able to send 'iat' as a number from my side (tool limitation). Is there a way around it?

[API_Products]

Hi @aks,

The 401 Token Validation Failed error you're getting will be seen when the x-pay-token sent in the header is invalid.

A couple of things I'd like you to note while generating the token:

1. To start, please follow the Working with Visa APIs documentation to generate a valid token. https://developer.visa.com/pages/working-with-visa-apis/x-pay-token

2. APIkey in the url query param should be the same as the one used to generate xpayToken.

3. “resourcePath” sent in the xpaytoken has to be as per the documentation (eg: v2/payments?apikey={apikey}).

4. Payload sent in the request payload should exactly match along with spaces to the “requestBody” value used in xpaytoken.

Can you please provide the request payload of this API call? It's possible that you're missing a field or have an inaccurate format. I'd like to see screenshot attachments of the error provided, if possible.

Also, could you check to see if you're passing a correct value for URI. For example, make sure it’s defined correctly in the beginning of your code, and use the same value for the URI in the middle of your code. In general, for cases like this (i.e. “helloworld works, but the API XX doesn’t”) I'd like to ask of you, if you could, to please extend your SOAPUI project, and make sure that you can call a particular API from SOAPUI project first.

[aks]

I am using card-on-file API which doens't need x-pay-token. It uses two way SSL and MLE. Here is the endpoint URI

/cof/v1/cofissuerservice

Input JSON (before encryption) is:

{
 "requestHeader": {
  "messageDateTime": "2018-10-24T11:05:42.327",
  "requestMessageId": "6da60e1b8b024532a2e0eacb1af58581"
 },
 "requestData": {
  "group": " STANDARD ",
  "pAN": ["4147203781087025"]
 }
}

Once the message is encrypted, it takes the form that is posted in original post.

Unfortunately I don't have access to take screenshot and post it here. Also my project is not using SOAP UI so I don't have access to that tool.

[API_Products]

Hi @aks,

Can you please submit this inquiry to developer@visa.com because there is additional information that I would like to obtain from you so that I can provide you with further assistance.

For information on MLE, please navigate to the Message Level Encryption Documentation using this link. https://developer.visa.com/pages/encryption_guide

[bennyrodrigues]

Assuming that your JWT implementation is sound as you mentioned in the question and assuming that you trust the server that issued the token, such level of validation is not necessary after checking the signature.