Referential WS Client is the standard referential interfaces exposed by the Issuers' Bank.
ACS is therefore client of the Bank Information System.

Thanks to this API ACS can  :

• get card information from the Bank Information System ;
• update cards/users/credentials information to the Bank Information System.

Referential WS Server is the standard referential interfaces exposed by ACS.
The bank is therefore client of ACS.

Thanks to this API the bank can  :

• get card information from ACS ;
• update cards/users/credentials information to ACS.

Version 24R2-1.2 of May 14th 2024

The referential card of an issuer is required. It is used for enrollment and authentication needs of cardholders.

In mode batch the issuer sends a periodic file to the platform in order to operate the provisionning of cardholder data.

The referential management is based on a XML file. This file takes in charge the creation of cardholders, cards and authentication data.

Retro compatibility with old XML and flat file formats is managed.

Glossary :

The following list gives a description of acronyms used :

• WLP-AHB: Worldline Product – Authentication HuB
• PAN: Primary Account Number
• CAP: Chip Authentication Program
• DDN: Birthdate
• PWD: Password
• SSN: Social Security number
• PAM: Personal Assurance Message
• PGP: Pretty Good Privacy
• GPG: GNU Privacy Guard
• PCI: Payment Card Industry

1. Historic

2. Description of referential file in format xml

The structure of file is given by the following figure. The possible values of each field and potential error codes are described in the following tables.

The maximum number of cardholders in a file is limited to 999 999 records.
An example of a report with errors is also available.

  2.1. File transfer mode

File transfers are carried out through a VPN tunnel or on Internet. Two protocols are available FTPs or PesitSSL.

  2.2. Security of exchanges through file transfers

    2.2.1 File encryption/decryption

Files containing sensitive data can be encrypted using PGP.

GPG is used.

The Issuer must use an encryption program that is compatible with the free GPG program used by equensWorldline, which makes it possible to ensure the authenticity and confidentiality of the transferred file with an RSA key.

GPG is a free implementation of the RSA algorithm that complies with the OpenPGP standard (RFC2440).

A REAL NAME (e.g. IssuerName_3DSAtos), a COMMENT (e.g. Atos 3DS signature by Issuer Name) and an E-MAIL ADDRESS will be specified to generate the keys.

The encryption algorithm used is AES256.

The ISSUER and equensWorldline exchange the public keys via e-mail in ASC format.

Keys are valid for 19 months. 

To comply with PCI, the key must not be used for encryption for more than 12 consecutive months. The expiry date is set to 19 months to allow restoration for 6 months; an extra month is added to the validity period of the key.

File encryption/decryption procedure:

Exchange of keys (carried out every 12 months):

• ISSUER generates a pair of keys: Public Key (P1) and Secret Key (S1);
• equensWorldline generates a pair of keys: Public Key (P2) and Secret Key (S2);
• Issuer and equensWorldline exchange their P1 and P2 public keys.

For the encryption/decryption of a file sent by ISSUER to equensWorldline, the file is encrypted with equensWorldline’s P2 key and signed with ISSUER’s S1 private key.

For the encryption/decryption of a file sent by equensWorldline to ISSUER, the file is encrypted with ISSUER’s P1 key and signed with equensWorldline’s S2 private key.

Keys are renewed through equensWorldline’s change tool. The application manager will get in touch with the customer contact appointed during the creation of the key to ask them to send the new public key; in return, they will provide equensWorldline’s new public key. The content to exchange will be the result of the export of the public key into ASCII. This will be sent via e-mail. To validate the public keys exchanged, each person involved will have to phone their appointed contract to obtain and validate the fingerprint of the key. It is imperative that the fingerprint be validated before the public key is used.

    2.2.2. Data security

The sensitive data contained in the file must be encrypted. Authentication data and card information are considered as sensitive.

For the repository file, the data to encrypt are:

• The PAN of the Card element;
• The value of the Authentication element (Phone number, email, date of birth, etc.).

All encrypted data will be encoded in Base64.

Symmetric encryption uses the AES algorithm.

The data are encrypted using 256-bit AES in CBC mode (Cipher Block Chaining); more precisely, it uses a Java implementation called javax.crypto.Cipher "AES/CBC/PKCS5Padding".

Upon each encryption operation, an IV (Initialization Vector) set to empty is used.

The encryption and decryption keys are identical.

The AES key is generated by the Issuer.

A different key will be used for each environment.

The exchange of such key whose generation remains at the responsibility of the issuer is not specified in this document.

  2.3. XML file for updating the cardholder repository

XML format è equensWorldline provides the Issuer with the .XSD file that makes it possible to generate this format.

The format will be XML in “MAJ” format according to the particularities of equensWorldline.

A different file transfer identifiers have to be defined for acceptance and production.

Description of referential file in a XML format

The structure of file is given by the following figure. The possible values of each field are described in the following tables. The maximum number of cards in a flat file is limited to 999 999 records.

  2.4. Description of fields

Each field must respect constraints in order not to be rejected. The following list gives a description of possible format controls:

• AN: Alphanumeric
• A: Alphabetic
• N: Numeric
• H: Hexadecimal
• B64: Base 64

    2.4.1. Record « Header »

    2.4.2. Structure « Header »

The field FileNumber is incremental and depends on the day when the file is received. So, if this field is valued by 728502, it means that the file is the 2nd file of day 285 of the year 2007. The batch can controls that there does not exist two files with the same identifier and reject it in case of duplication. The batch does not control the field FileNumber.

    2.4.3. Record « CardHolder »

    2.4.4. Structure « CardHolder »

    2.4.5. Structure « Card »

    2.4.6. Authentication Data

To process the authentication flow, several authentication data can be stored: 

• PHONE: the phone number (Deprecated)
• SMS : mobile phone number
• SVI : fix phone number for IVR authentication
• EMAIL: the email address
• SSN: the Social Security Number, person identifier
• PAM: the Personal Assurance Message
• TOKEN: the identifier of the token
• DDN: the birthdate
• PWD: the password
• TA: trusted authentication

HUB phone number must be in international standard E.164 format.
E.164 numbers are formatted [+] [country code] [subscriber number including area code] and can have a maximum of fifteen digits.

    2.4.7. Structure « CardData »

Note: CardData is not currently used.

    2.4.8. XML message example

Here is an example with:

• A card where all authentication data are replaces with provided ones,
• Another card where only EMAIL authentication data is created/updated,
• And a last one where nothing is created/updated/deleted (since no authentication data is provided)

Here is another example with:

• A card to which we delete the value of a credential,
• A card where all authentication data are replaces with provided ones

    2.4.9. File processing report

During the integration process of XML, a log file can be provided by file transfer. This file contains all rejected records with an error label associated to each reject. The file describes a global report of execution of integration and each error is formatted according to the following rules:

• If the reject happens in the section Header:
  • Format: Error on Header : Error Label
  • Example: Error on Header : Issuer is invalid
  • Signification: The issuer code mentioned in the Header has invalid format.
• If the reject happens in the section CardHolder
  • Format: Error on CardHolder(identifier): Error Label
  • Example: Error on CardHolder(identifier=12345678901234567890123456789012345678) : The length of the identifier must be between 1 and 36
  • Signification: The Cardholder with identifier 12345678901234567890123456789012345678 has a field Identifier whose length is too long.
• If the reject happens in the section Card
  • Format: Error on CardHolder(identifier) - Card# : Error Label
  • Example: Error on CardHolder(identifier=111447612) - Card#1 : PAN is invalid Signification: The PAN of card having the IdElement=1 in section CardHolder having identifier=111447612 is invalid or missing.

    2.4.10. Example file log report

    2.4.11. Description

For each batch, the report file starts by “start execution date” and “file name” and finishes by “returned code”, “job Id”, “end execution date” and “duration”.

Between the start and the end of execution, we have all reported data errors, as described in previous section. This is followed by a summary of the number of cards treated, and number of found records for each kind of movement.

3. Validation rules for xml format

  3.1. Header

  3.2. CardHolder

  3.3. Card

  3.4. AuthenticationData

4. Functional Validation rules

4.1.  File reject

If more than 5% of lines are in error the file is rejected with an error code 12 : “Batch KO, number of line errors greater than 5%”.

The blocking errors :

If the header is empty the file is rejected with an error code 40 : "No header specified"
If the header format is invalid the file is rejected with an error code 41 : "Specified header is incorrect"
If the header format is invalid the file is rejected with an error code 18 : "Error read input file xml"

Non-blocking errors threshold:

A skip limit can be defined for the non-blocking exceptions if this limit is reached the file is rejected.
By default the parameter is set to 100%.

Skip limit parameter : ${app-skip-limit}

4.2.  Skipped requests

On batch process, the skipped card are corresponding to the specific use case :

• On ACS3 XML format
  • Record Card in UpdateMode = CREATE_ONLY but the card is already exist in Data Base, so we can’t create it , so request is skipped

• On ACS1 XML or CSV format

  • Record Card with ModificationType = RENEWAL but the card doesn’t exist in Data Base, so we can’t renewal it, so request is skipped
  • Record Card with ModificationType = DELETION but the card doesn’t exist in Data Base, so we can’t delete it, so request is skipped
  • Record Card with ModificationType = REPLACE but the card doesn’t exist in Data Base, so we can’t replace it and retrieve the initial credentials, so request is skipped

   

The card referential contains card holder information, PAN and credentials.

The master referential can be on ACS side or on bank side.

When the master referential is on ACS side the provisioning can be done by batch or/and an API the Referential WS Server.

When the master referential is on bank side ACS retrieves information by an API the Referential WS Client.

General Terms

1. Terminology

Here below you will find the acronyms used and their meanings:

2. Overview

ITA Sec Authentication Hub exposes a unified API for host-to-host communications.

The methods are exposed through a RESTful API built on HTTP and JSON.

As per the REST principles:

• All the methods are accessed by performing an HTTP request to the web service endpoint,
• URL are used to access the data
• HTTP bodies carry the representation of the business objects (elements),
• HTTP verbs are used to indicate the action to perform :
  • POST: create a new element for which no identifier is known
  • PUT: update an element, or create a resource for which the identifier is known in advance
  • GET: retrieve one or more elements
  • DELETE: delete an element

3. Versioning

From version 2019R2.0, the version number has been included in the service URI. By default, when the version is not provided in the URI, the version 2019R1.0 implementation is used.

Examples of URI :

/referential/rest/2019R2-1.0/public/updateCardWithCredentials/669c8c64-e71f-4e87-8966-cb578a86074e

/referential/rest/2021R1-1.0/public/updateCardWithCredentials/3aaa4686-d139-4822-b193-6a0140467264

4. Connectivity

  4.1. Network

All the services are exposed through the HTTPS protocol (RFC 2818) TLS 1. 2.

No HTTP compression (RFC 2616) is activated.

  4.2. Security

In order to secure the communication channel between the bank and authentication HUB, the mutual authentication is recommended.

     SSL Client

Authentication Hub will provide a Certificate Request based on Bank recommendation.

Bank must sign the certificate with AC of its choice.

The certificate file must comply with the PKCS10 format and be base-64 encoded.

  4.3. IP Filtering

In case of IP filtering on server side firewalls, the IP address of EWL for incoming requests are provided below:

 5. Interfaces

  5.1. Format

The data exchanged is serialized using

• JSON format (RFC 7159).

The character set supported for input and output data is UTF-8 (RFC 3629).

  5.2. Common headers (for WS Client)

       5.2.1. Hypermedia

Hypermedia is used to specify content type and charset to be used.

Currently supported values are:

• Content type: json
• Charset: UTF-8

Table 1 - Hypermedia input header

Table 2 - Hypermedia output header

       5.2.2. Oauth 2.0

API could be secure by using Oauth 2.0 protocol. All API requests using Oauth 2.0 must contain at least the following headers: Date, Digest and Authorization.

In order to verify that the message was not tampered with during transit, a signature is also requested.

Two types of signature can be implemented :

• HTTP signature, in this case, API requires a "Signature" header to be supplied
• JWS signature, in this case, API requires an "X-JWS-Signature" header.

          5.2.2.1. HTTP signature

          5.2.2.2. JWS signature

The JWS structure shall be carried in HTTP header field named "x-jws-signature".

A JWS protected header parameter is composed of parameters :

• "b64” ; the JWS header shall include b64 header parameter set to false
• “x5t#S256” is the digest (fingerprint) of the X.509 signing certificate using SHA 256. "x5t#S256" shall be checked against the certificate used to validate the signature
• crit:["sigT","sigD","b64"] - Non-standard JWS header parameters (ie. not defined in RFC 7515), which are critical
• "sigT" shall be present and set to the time that the signature was created. The time shall be indicated in UTC (ending in "Z") and shall indicate date and time to the second.
• "sigD" header parameter shall be present and shall contain :
  • “mId" set to http://uri.etsi.org/19182/HttpHeaders
  • "pars" should include the following HTTP Header field names:
    • "(request-target)" for HTTP Requests
    • "Content-Type"
    • “Digest” enables protection of the HTTP Body
  • "alg" identifies the cryptographic algorithm used to create the JWS Signature Value. Use RS256

Example of protected header

    { "b64":false,
    "x5t#S256":"dytPpSkJYzhTdPXSWP7jhXgG4kCOWIWGiesdzkvNLzY",
    "crit":[ "sigT", "sigD", "b64" ], 
    "sigT":"2023-11-26T11:26:57Z",
    "sigD":{ "pars":[ "(request-target)", "content-type", "digest" ],
    "mId":"http://uri.etsi.org/19182/HttpHeaders" 
    }, 
    "alg":"RS256"
    }

Example of protected header encoded in B64 (without line breaks or extra spaces)

eyJiNjQiOmZhbHNlLCJ4NXQjUzI1NiI6ImR5dFBwU2tKWXpoVGRQWFNXUDdqaFhnRzRrQ09XSVdHaWVzZHprdk5MelkiLCJjcml0IjpbInNpZ1QiLCJzaWdEIiwiYjY0Il0sInNpZ1QiOiIyMDIzLTExLTI2VDExOjI2O

jU3WiIsInNpZ0QiOnsicGFycyI6WyIocmVxdWVzdC10YXJnZXQpIiwiY29udGVudC10eXBlIiwiZGlnZXN0Il0sIm1JZCI6Imh0dHA6Ly91cmkuZXRzaS5vcmcvMTkxODIvSHR0cEhlYWRlcnMifSwiYWxnIjoiUlMyNTYifQ

A HTTP header parameter

• request-target :
• digest :
• content-type : application/json

Example of HTTP header

    (request-target): post /initiateAuthentication
    content-type: application/json
    digest: SHA-256=+xeh7JAayYPh8K13UnQCBBcniZzsyat+KDiuy8aZYdI=

Where digest is the hash in SHA-256 of request body

All the header parameters contained in JWS Protected Header are protected by the signature.

The data must be signed with the private key (associated with the certificate identified in "x5t#S256") by using the chosen algorithm (specified in “alg” parameter).

Data to sign is the concatenation of protected header encoded in B64 and HTTP Header separated by “.”

Example of input Data for Signature

    eyJiNjQiOmZhbHNlLCJ4NXQjUzI1NiI6ImR5dFBwU2tKWXpoVGRQWFNXUDdqaFhnRzRrQ09XSVdHaWVzZHprdk5MelkiLCJjcml0IjpbInNpZ1QiLCJzaWdEIiwiYjY0Il0sInNpZ1QiOiIyMDIzLTExLTI2VDExOjI2OjU3WiIsInNpZ0QiOnsicGFycyI6WyIocmVxdWVzdC10YXJnZXQpIiwiY29udGVudC10eXBlIiwiZGlnZXN0Il0sIm1JZCI6Imh0dHA6Ly91cmkuZXRzaS5vcmcvMTkxODIvSHR0cEhlYWRlcnMifSwiYWxnIjoiUlMyNTYifQ.(request-target): post /initiateAuthentication


    content-type: application/json


    digest: SHA-256=+xeh7JAayYPh8K13UnQCBBcniZzsyat+KDiuy8aZYdI=

Example of Signed Data

    Q9ZSYXJ0QWSoPBfBUR58Sqplw7BQcrcqVR6rvnqfBOvosbBLcsBjkjzi1kCF 2cJsHTJRtp6GcJmZplqRg-7_QBKQAgkUq0BGQpzZwhVYrvP0opdLEarVBrej YA05gt3qnleuS53DWmyZu9iNxhwJTYVPyXediwo3TIlSn-8XjSTZAVHa728E WK6XzRC9rEroXYPYd23iQLXetMygLaDhRT2lGhV5WvmO0wC0B6RbGiYl2zIv D0XliMP6MidX4SDY5zlzyWyFlHqX7eHpkH8xxqAsBdKb16y4IdOoRhil9yws vlzkG6-U9jmBU4y_m3mZArD22oRVXTywzFn9NUtY9w

X-JWS-Signature is the concatenation of protected header encoded in B64 and Signature value separated by “..”

Example of JWS Signature

   eyJiNjQiOmZhbHNlLCJ4NXQjUzI1NiI6ImR5dFBwU2tKWXpoVGRQWFNXUDdqaFhnRzRrQ09XSVdHaWVzZHprdk5MelkiLCJjcml0IjpbInNpZ1QiLCJzaWdEIiwiYjY0Il0sInNpZ1QiOiIyMDIzLTExLTI2VDExOjI2OjU3WiIsInNpZ0QiOnsicGFycyI6WyIocmVxdWVzdC10YXJnZXQpIiwiY29udGVudC10eXBlIiwiZGlnZXN0Il0sIm1JZCI6Imh0dHA6Ly91cmkuZXRzaS5vcmcvMTkxODIvSHR0cEhlYWRlcnMifSwiYWxnIjoiUlMyNTYifQ..Q9ZSYXJ0QWSoPBfBUR58Sqplw7BQcrcqVR6rvnqfBOvosbBLcsBjkjzi1kCF 2cJsHTJRtp6GcJmZplqRg-7_QBKQAgkUq0BGQpzZwhVYrvP0opdLEarVBrej YA05gt3qnleuS53DWmyZu9iNxhwJTYVPyXediwo3TIlSn-8XjSTZAVHa728E WK6XzRC9rEroXYPYd23iQLXetMygLaDhRT2lGhV5WvmO0wC0B6RbGiYl2zIv D0XliMP6MidX4SDY5zlzyWyFlHqX7eHpkH8xxqAsBdKb16y4IdOoRhil9yws vlzkG6-U9jmBU4y_m3mZArD22oRVXTywzFn9NUtY9w

  5.2. Common headers (for WS Client)

 5.3. Common headers (for WS Server)

  5.3.1. Common headers request

  5.3.2. Common headers response

 5.4. Api-Key

A parameter, called “Api-Key” is automatically added in the requests by the HUB Applicative Firewall. This value contains the certificate CN provided by Client during mutual authentication process.

This field must not set or define in the API; it’s an internal field.

 5.5. Encryption

Some fields, corresponding to sensitive data, can be either encrypted or plain. In this case, there is a type, a value and a key tag attribute.

When the type is encrypted, the value attribute is a String, before encryption and after being decrypted. The encrypted result is in Hexadecimal format compliant with JSON structure. That’s why this field doesn’t need to be parsed into JSON object.

Only for plain formats, the value needs to be casted to as JSON object. As a result, all the double quotes characters need to be escaped by a backslash, resulting to the following format: "\"PWD\": {\"pwd\":\"@value\"}".

When sensitive fields are encrypted, a “keyTag” value is requested to identify the key used. The “keyTag” value must be defined per field. Same keytag value could be used for all data.

  5.5.1. Encryption

Sensitive data will be encrypted with AES256bits (RFC 3565) encryption in CBC or GCM mode with an initial vector either filled with 0 (in case parameter initializationVector is not filled or at “false”) or with the requestId without “-“ character. The data to encrypt will be padded using PKC7 padding.

The encrypted field is always exchanged in Hexadecimal format.

  5.5.2. Samples

Key

XOR1: B3EE911BA049ADBEE36B0445C8FC8A2832E7646316F111BCFA3EE062B0379E23
CCV1: BF36D7

XOR2: 50A813F0A59FFADDFEFE06904A4E4E42DF30026CE63FECEEAB92043C667FBC0C
CCV2: DA684A

Clear key: E34682EB05D657631D9502D582B2C46AEDD7660FF0CEFD5251ACE45ED648222F
KCV: 84A0D9

Encryption (CBC)

IV: 00000000000000000000000000000000
Data to encrypt (Clear PAN): 4263540111825682
Data encrypted – in hexadecimal: 11A18541F9C9E748F62186292BC2DB48BF407F2B049390FBE1037D00AF5FACDA

IV: 384000008CF011BDB23E10B96E4EF00E
Data to encrypt (Clear PAN): 4263540111825682
Data encrypted – in hexadecimal: 13FA6DE3AA4C939865D5095A14BE22E95E94C9933EA20F32369423270282EC97

Encryption (GCM)

IV: 00000000000000000000000000000000
Data to encrypt (Clear PAN): 4263540111825682
Data encrypted – in hexadecimal: 68e94ab51334a794c10ebdb76b7480cebb740d8d655396cf7626b1177ad9a78f

IV: 384000008CF011BDB23E10B96E4EF00E
Data to encrypt (Clear PAN): 4263540111825682
Data encrypted – in hexadecimal: 0ead51b9582223c003fcf13195fd3c83d39c2f8cb6a6000dfcc758401fb5e7ea

 5.6. Response code

  5.6.1. HTTP codes

HTTP codes are used as a first level of information as to know whether a request has been properly handled or not. The caller must consider these codes in compliance with the HTTP specification.

HTTP codes used:

  5.6.2. Error body

Whenever a business management exception occurs, in addition to the HTTP code, an error representation is returned into the body in addition of the nominal content. To ensure confidentiality, only a detailed code is returned (9 digits). This code is to be matched against the dedicated documentation to be interpreted. In the event of an unexpected error, no code is provided. The error content structure is defined below.

The body of error message contains additional optional attributes which are only provided in order to facilitate analyzing in case of issue.

Sample of error response

    {
    "issuerCode": "00006",
    "subIssuerCode": "00006",
    "requestId": "b8b1d1ae-3b65-48a2-b331-9607ab295412",
    "service": "ACS_U5G",
    "errorCode": "404030000",
    "origin": "REFERENTIAL",
    "message": "com.wl.gbl.ah.utils.services.exception.AuthenticationHUBExceptionV2: Card not found",
    "originVersion": "21R1.5-P-37",
    "originHost": "tqahx002v",
    "contextTemporary": {}
    }

This API based service is for requesting PSPs in the Worldline VoP Hub ecosystem and EPC scheme. It allows to process the verification of a payee identity via a single request to the Worldline VoP Hub, based on identification data and account data entered bv the Requester (Payer) in any payment channel of the PSP.

Features

The service will route the request to the corresponding responding bank using its dedicated directory service, obtain or compute a matching result (depending on the source of account holder information data or direct match result), and return it to the requesting PSP under 3 seconds (or timeout).

The API supports name + IBAN matching (returning a corrected name in case of a close match) as well as additional identifiers when supported by the responding bank.

Process

1. The Requesting bank gathers information from the Requester (payer) about the subject of the VoP (Payee), before initiating a payment from any Sepa Credit Transfer channel.
2. The API client authenticates towards VoP Hub and sends a request containing the gathered identification data and account reference.
3. The VoP Hub routes the request to the corresponding responding bank, part of its reachable VoP interfaces.
4. The VoP Hub receives the match result or necessary account holder information from the responding PSP.
5. The API client receives the resulting API response, which may include the corrected name according to the responding bank, in case of close matches. 
6. The Requester is informed of the matching result, applies potential corrections and proceeds with payment initiation.

API Security

• Authentication: The Worldline VoP Hub uses an authentication service that adheres to the OIDC standard protocol. 
  For enhanced security, the client must present an (qualified) SSL certificate to authenticate.
• Secure Communication: All communications utilize MTLS with TLS 1.2 or higher, ensuring that data in transit is secure.

In the EPC VoP scheme

According to the EPC Document 218-23, "Verification Of Payee Scheme Rulebook" first version for public consultation :

The Responding PSP is the Participant that receives the VOP Request from the Requesting PSP and Instantly processes that VOP Request. 
The Responding PSP is also obliged to Instantly send a VOP Response containing a matching result about the received details of the Payment Counterparty or another reason, back to the Requesting PSP.
The Responding PSP may also be the Payment Counterparty.

Worldline provides API and file exchange based services for scheme participants who need to fulfil this role and intend to comply with all its rules.

The following simplified diagram represents how the Worldline VoP services operate on behalf of Responding PSPs in the EPC scheme :

Services

To produce match results on behalf of the Responding PSP, Worldline needs access to account related information of the subject of the Verification of Payee.

Two services are available for that purpose, and are detailed at the following locations in this developer portal :

• Responding PSP API : a real time API definition to expose account holder data to the Worldline VoP Services.
• Account Data Management : an API or file exchange based service for responding PSPs to delegate the storage of account holder data to the Worldline VoP services, then used to produce match results when answering VoP requests.