Security & Compliance

Security

Card linking leverages RESTful APIs containing different levels of authentication and encryption to secure information being passed between Skipify and Issuers:

OAuth 2.0 Client Credential

API requests are secured by passing the access token fetched from the OAuth2.0 Client Credential flow between the backend services.

• The OAuth Client is the Skipify Server running the card linking flow
• The OAuth Authorization Server is run by the issuer to protect the APIs
• The client credentials are shared by the issuer to Skipify Administrators in a secure channel during the initial setup and rotated periodically at agreed upon intervals.

JSON Web Signature(JWS)

Used to sign data.

📘

Note

To ensure data integrity, every request will also contain signed JWS headers for verification purposes.

• Skipify generates an RSA 2048 public/private key to sign the requests
• The public key is shared with the Issuer administrator in a secure channel during initial setup and rotated periodically at agreed upon intervals. (This may also be shared using a well-known URL)
• Each request is signed using the private key
• The Signature is added to the header of the request with the format defined in JWS RFC 7515 as (BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature))
• Issuers can verify the integrity of the request payload using the Skipify public key

JSON Web Encryption (JWE)

PII fields are encrypted using JWE.

Request fields from Skipify are encrypted using the following attributes:

• PII fields will be encrypted using RFC-7516 JWE
• Skipify will use the RSA-OAEP-256 key encryption algorithm
• Skipify will use the A256GCM content encryption algorithm

Issuers will share RSA 2048 certificates with Skipify on well-known URLs

JWE encryption shall be completed by the Issuer on the PII fields of the Response as follows:

• PII fields shall be encrypted using RFC-7516 JWE
• Issuers shall use the RSA-OAEP-256 key encryption algorithm
• Issuers shall use the A256GCM content encryption algorithm

Skipify will share RSA 2048 certificates with the Issuer on well-known URLs

Mutual TLS

Mutual TLS (mTLS) is a security protocol that enhances the standard Transport Layer Security (TLS) by providing two-way authentication. In a standard TLS setup, only the server's identity is verified by the client. However, with mTLS, both the client and the server authenticate each other, ensuring that both parties involved in the communication are verified and trusted.

To implement mTLS, issuers should:

1. Obtain Certificates: Acquire a valid certificate from a trusted Certificate Authority (CA) for the server.
2. Exchange public certificates: Skipify will share the public certificate of the client and the issuer will share the public certificate of the server.
3. Configure Servers and Clients: Set up your servers and clients to use mTLS.

ID Token (JWT)

The ID Token represents a successful user authentication during the card linking flow. The ID Token is signed using a Skipify RSA 2048 Private Key and contains the parameters used during the step-up process as shown below:

Identity Hash

generateIdentityHash(String identity) {
    currentHash = identity.toLowerCase();

    // hash for 1000 times
    for (int i = 0; i < 1000; ++i) {
        currentHash = SHA256(currentHash);
    }

    return SHA256(SHA256(identity.toLowerCase()) + currentHash);
}

Compliance

Skipify’s platform is certified as PCI compliant (Level 1). Data that is shared by Issuers is stored and encrypted in the Skipify Vault. This includes:

• PII data
• Issuer payment credentials (PANs and tokens)

Skipify is SOC2 Type 1 certified ensuring that we maintain the highest standards for financial reporting.