iCal Feed Credential Management Policy

1. Purpose

This document describes the handling, storage, and security of third-party credentials used to generate iCal calendar feeds via the service. The system allows users to provide credentials for external services (e.g., Bakaláři) and receive a static, read-only iCal URL that can be used across devices.

The design balances usability (static device-independent links) with security and GDPR compliance.

2. Overview of the System

• Credential Submission: Users provide login credentials for third-party services. Credentials are only used to generate a read-only iCal calendar feed.
• Encryption: Credentials are never stored in plaintext. An AES-256-GCM encryption key is mandatory and derived from a user-provided secret (password) using scrypt with a per-user salt.
• Static iCal URL: Each user receives a static URL containing a hash (derived from username/account) and the mandatory AES key. The URL acts as a read-only bearer token.
• Fetching the Feed: The server retrieves encrypted credentials from Redis using the hash, decrypts them using the AES key, fetches the calendar, and returns the ICS feed.
• Device Independence: The static URL works across multiple devices; the server does not store the AES key in plaintext.

3. Data Minimization and Retention

• Only encrypted credentials are stored; no permanent user accounts are created.
• Credentials remain stored as long as the iCal feed exists.
• Users can revoke or delete credentials at any time.
• Backups contain only encrypted credentials, stored securely and access-controlled.
• Stored data will expire the following 31st of july.

4. Security Measures

• Encryption: AES-256-GCM provides confidentiality and integrity; keys are derived using scrypt with a per-user salt.
• Access Control: Only the server handling the iCal request can decrypt credentials. URLs are bearer tokens, HTTPS-only.
• Revocation: Users can delete credentials or regenerate the AES key, invalidating previous links.
• Logging: Logs do not store AES keys or plaintext credentials. Minimal metadata (timestamp, IP) is collected for abuse detection.
• Compromise Handling: In case of server compromise, AES keys in URLs can be rotated or feeds revoked. Encrypted storage ensures leaked backups do not reveal plaintext credentials.

5. GDPR & EU Compliance

• Lawfulness: Users voluntarily provide credentials for generating iCal feeds. Only necessary data is processed.
• Data Minimization: Credentials are encrypted and stored only as needed.
• User Rights: Users may request deletion of credentials and revoke iCal feed links at any time.
• Data Protection by Design: Encryption at rest and in transit; static links minimize server-side exposure; rate-limiting prevents abuse.
• International Transfers: Data is processed within the EU or in GDPR-compliant jurisdictions.

6. Responsibilities

• Users: Must keep the AES key secret. May revoke or regenerate links at any time.
• Service Provider: Encrypts credentials before storage, ensures HTTPS access, implements revocation, rotation, and secure deletion.

7. Limitations

• Static URLs are bearer tokens; possession grants read-only access.
• Full server compromise could expose feeds temporarily; encryption protects at-rest storage only.
• The system does not prevent compromise of the third-party service itself.

8. Summary

Credentials are encrypted at rest using a mandatory AES key derived from a user secret. iCal URLs are static, read-only, and device-independent. Users retain control over revocation, and GDPR principles are followed: data minimization, encryption, and user rights enforcement.