Request for Information.pdf

REQUEST FOR INFORMATION (RFI)

Subject: Cloud-Native DRM Solution Issuing Agency: Library of Congress

INTRODUCTION & PURPOSE

Agency Overview Library of Congress (LOC) is responsible for storing and safely preserving digital content submitted by our users. As part of this mission, the agency manages a significant volume of sensitive digital assets requiring robust protection against unauthorized access, distribution, and leakage.

Problem Statement The Library of Congress currently manages a large-scale repository of digital assets through a custom-built, workflow/case management solution. While this tool effectively manages asset lifecycle and metadata, it lacks a native Rights Management capability. The LOC requires a commercial, API-driven, Digital Rights Management (DRM) solution to integrate directly into its’ existing application stack. The objective is to secure files at rest and in transit, and to enforce persistent usage rights throughout the lifetime of the asset.

RFI Objective This Request for Information (RFI) is issued solely for information and planning purposes. It does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. The LOC is conducting market research to understand the commercial off-the-shelf (COTS) options available for API-driven DRM solutions that meet federal security standards.

The Library of Congress may also request formal demos of potential sources’ products and services. Coordination with potential sources to obtain a demo of their products and services may occur at a future date after the LOC receives the RFI results and analyzes the information.

SCOPE OF NEED & TECHNICAL ENVIRONMENT

Current Technical Environment

Vendors should consider the following technical environment and workflows when drafting their responses:

• Infrastructure: Cloud-native environment hosted in AWS & Azure

• Custom Apps: Custom-built applications utilizing JAVA, Python and Angular will be used to interact with the DRM solution/assets.

• Asset Volume: Approximately 2+ million files (25TB) yearly

• Identity Provider: Users are authenticated via MS Entra for internal users and login.gov for external users.

• Approx external concurrent users: 5,000+

• Approx internal concurrent users: 300+

• Our supported assets are in a large number of formats. Audo, Video, Office Files, Text documents, etc.) See Appendix A

Desired Workflow (High-Level)

1. Ingest: A user uploads a file/multiple files (PDF, Office, Image, etc.) through the Agency’s web interface or API. A list of file types can be found in Appendix A.

2. Protect: The Agency’s tool calls the Vendor’s API to encrypt/wrap the file with specific policies.

3. Storage: The protected file is stored in the Agency’s cloud storage (e.g., S3/Blob).

4. Access: When a user requests the file, they are authenticated via Single Sign-On (SSO).

The DRM client (browser or agent) validates the user’s rights via the Vendor’s API and unlocks the file for viewing.

5. All assets must remain read-only and not allow any changes. The integrity of the file must remain as it was when submitted.

* Encrypted files are only accessible in real-time when an approved user requests to view it. Files should remain encrypted while at rest. Viewing these files can only be done via an approved viewer either provided by the solution, or custom built by the LOC, with integration to the decryption mechanism.

REQUESTED INFORMATION

Please provide detailed responses to the following technical areas. Please avoid providing generic marketing language or capability statements. Vendor specific technical details are required.

Company Profile & Compliance

• Brief company history and experience with U.S. Government, Federal clients.

• FedRAMP Status: Is your solution FedRAMP Authorized (Low, Moderate, or High)? If not, is the solution "FedRAMP Ready"?

• Support: Describe your U.S.-based support structure and Service Level Agreement (SLA) tiers.

Solution Architecture

• Is the solution SaaS (Software as a Service) or PaaS (Platform as a Service)? Can it be deployed as a containerized instance within the LOC’s VPC?

• Client Requirements: Does the solution require a proprietary agent installation on the endpoint, or can it function entirely in a web browser (HTML5 viewer)? If both are supported, describe the functional differences.

• For encrypted video/audio files, can the LOC leverage its’ existing web-based players/viewers, or does the LOC need to use your company’s viewer tools?

API Capabilities & Integration Strategy Developer Experience

• Protocols: Does the solution use REST, SOAP, or GraphQL? Please provide links to public API documentation.

• SDKs: Do you provide native SDKs? (Specify: Python, Node.js, .NET, Java).

• Sandbox: Do you provide a dedicated sandbox environment for development and load testing?

Core DRM Functions (Programmatic Control)

• Streaming Encryption: Can the LOC pass a file stream directly to your company’s API for encryption without first storing the file on your company’s servers? (In-memory processing).

• Policy Abstraction: Can the LOC define "Policy Templates" (e.g., "Confidential - No View") and reference them by ID in the API call?

• Revocation: Describe the API methods to revoke access to:

o A specific document ID.

o A specific User ID (globally).

o A specific Device ID.

o A specific file type.

• Does your company’s solution have customizable meta-data fields for each object? If the majority of the meta-data is stored in the LOC’s own solution, will there be a requirement to keep the meta-data in sync between our solution and your company’s solution? I.e.

Does the solution require that it stores the meta-data as well? Can the LOC store the meta-data in the LOC’s system and just leverage your company’s solution for the DRM capabilities?

Authentication & Identity

• Federation: Does the API support token exchange via OIDC or SAML 2.0?

• User Provisioning: Does the solution support Just-in-Time (JIT) provisioning based on IdP claims, or must user accounts be pre-created?

• Service Accounts: How does a client's application(s) authenticate to your company’s

API? (e.g., mTLS, OAuth Client Credentials).

• Does your company’s solution provide “Role” based access to the DRM content? Do those roles need to be managed within your company’s tool, or can the client/LOC leverage an external repo such as Entra to manage Roles?

Security & Key Management

• Algorithms: Confirm encryption standards (e.g., AES-256). Are modules FIPS 140-2/3 validated?

• BYOK: Does the API support Bring Your Own Key (BYOK) where the client retains root keys in its own HSM/KMS?

• Data Residency: Confirm whether during the API encryption process, customer data is never written to disk on Vendor servers.

Performance & Reliability

• Latency: What is the average latency (ms) for encryption calls on a standard 10MB file?

3GB file?

• Offline Access: How does the solution handle offline license validation? Can the LOC programmatically set a Time-to-Live (TTL) for offline access?

Auditing / Reporting

• What auditing does your company’s system provide?

• Does your company’s solution provide an alerting mechanism to provide real-time alerts that trigger for customizable events?

Pricing Model

• Describe the licensing model (e.g., Per User, Per Transaction/API Call, or Per Protected Document).

• Are there additional costs for Sandbox environments or Premium Support?

User Interface

Although the LOC believes that our primary access will be via the API from its’ internally developed tools, does your company’s solution have a fully functional front end?

• Is it web based or thick client based? If web, what browser versions do you support?

• Is the API functionally equivalent to the user interface?

• Is your company’s application fully accessible? Can you provide a VPAT with your response?

4.0 RESPONSE INSTRUCTIONS AND SUBMISSION DEADLINE

Submission Format

• Responses must be submitted in PDF format.

• Please limit responses to 25 pages.

• Please submit in Voluntary Product Accessibility Template (VPAT) format.

Submission Deadline

• Questions Due: May 4, 2026 at 11:00 a.m. (EST).

• RFI Response Deadline: May 20, 2026 at 11:00 a.m. (EST).

LOC Points of Contact Submit all responses and inquiries to:

Veronica Price, Contracting Officer - vprice@loc.gov Stefanie Fitte, Contract Specialist - sfitte@loc.gov

Appendix A – File Formats

FILE TYPE EXTENSION

Data .xls (Microsoft Excel Spreadsheet)

.xlsx (Microsoft Excel Open XML Spreadsheet) Image .bmp (Bitmap Image)

.dwg (AutoCAD Drawing)

.dwf (Autodesk Design)

.gif, .giff (Graphics Interchange Format)

.jpg, .jpeg, .jfif (Joint Photographic Experts Group)

.pdf (Portable Document Format)

.pic, .pict (Picture File)

.png (Portable Network Graphic)

.psd (Photoshop Document)

.pub (Microsoft Publisher)

.tga (Targa Graphic)

.tif, .tiff (Tagged Image File Format)

.wmf (Windows Metafile) Audio .aif, .aiff (Audio Interchange File Format)

.au (Audio File)

.mp3 (MP3 Audio File or Layer 3 Audio Compression)

.wav (Windows Wave Sound File)

.wma (Windows Media Audio File)

.mp4, .m4a, .m4p (MPEG-4 Part 14 Apple) Video .avi (audio video interleave)

.mov (quicktime)

.mpg, .mpeg (Moving Picture Experts Group)

.swf (Adobe Flash formerly Shockwave Flash)

.wmv (windows media video)

.3gp (.3gpp) (Third Generation Partnership Project; Multimedia Container Format) .mp4 .m4v (Apple Video Container File Format) .flv (Flash Video Format)

Text .doc (Microsoft Word Document) .docx (Microsoft Word Open XML Document)

.html (HyperText Markup Language)

.pdf (Portable Document Format)

.rtf (Rich Text Document)

.txt (Text File)

Presentation .pps, .ppt (Microsoft Power Point) .pptx (Microsoft Power Point Open XML)

Compressed .zip (Zipped File)