The open sharing protocol for the agentic era.

A Linux Foundation AI & Data Project

Enterprises across all industries need to collaborate with external organizations on Data and AI assets to derive joint value. Examples include a retailer collaborating with their suppliers on supply chain optimization, a life sciences company collaborating with healthcare providers on clinical trials, a financial data provider providing data and AI assets to their client banks for risk management, or an enterprise accessing its own assets across business units and platforms. Today, this process often requires custom point-to-point integrations, manual asset copies and transfers, and overall a high level of friction.

Building on the original Delta Sharing protocol, OpenSharing defines a cross-platform, vendor-neutral protocol for secure zero-copy sharing of Data and AI assets. Customers can use a consistent set of discovery API, credential vending model, and access controls across tables, volumes, ML models, and agent skills. Any compliant client on any platform can consume any asset type without format-specific or platform-specific code - breaking down silos and enabling open collaboration.

Four properties across all asset types that are important for the open agentic era:

• Open standard — Apache 2.0, governed by the Linux Foundation. Any compliant server or client is valid — no required SDK or platform.
• AI-native — covers the full range of assets organizations share today, from structured tables to models and agent skills, with more on the roadmap.
• Zero-copy — assets stay in the provider's storage. The sharing server vends temporary, scoped credentials; recipients read directly from the source.
• Works where data lives — works with cloud storage like S3, ADLS, GCS, R2, and on-premises environments. Organizations that can't move data can still share it.

OpenSharing is adopted across a broad ecosystem of data providers, storage platforms, and clients:

OpenSharing uses a three-level hierarchy:

Share
 └── Schema
       ├── Table
       ├── Volume
       ├── AgentSkill
       ├── Model
       ├── Agent (community proposal)
       └── Page (community proposal)

Share — A named, access-controlled collection of assets granted to one or more recipients. A single credential grants access to everything within a share.

Schema — A logical namespace grouping related assets within a share.

Asset — The data or AI artifact being shared. OpenSharing defines a set of standard asset types, each with its own metadata model and access API.

A provider creates a share, adds assets (tables, volumes, models, or skills), and issues credentials to recipients. Assets are never copied — recipients access them directly from the provider's cloud storage via short-lived, scoped credentials.

POST /shares/{share}/schemas/{schema}/tables/{table}/temporary-table-credentials
→ returns AWS STS / Azure SAS / GCP OAuth / R2 token scoped to that table's storage location

A recipient authenticates with a bearer token and uses standard list/get/read APIs to discover and consume assets. The same client can consume tables as DataFrames, download volume files, load model artifacts, or enumerate available agent skills — all through a unified protocol. Besides using bearer tokens, clients and servers can support other auth mechanisms such as OAuth.

GET /shares
GET /shares/{share}/schemas
GET /shares/{share}/schemas/{schema}/tables
GET /shares/{share}/all-tables
GET /shares/{share}/schemas/{schema}/volumes
GET /shares/{share}/schemas/{schema}/skills
GET /shares/{share}/all-skills
GET /shares/{share}/schemas/{schema}/models

OpenSharing uses credential vending for secure, zero-copy access. The sharing server issues either pre-signed URLs or temporary cloud credentials (e.g. AWS STS, Azure SAS, GCP OAuth, Cloudflare R2), depending on the asset type and access mode. Recipients access assets directly from the provider's storage — the sharing server is never in the data path.

Each asset type has its own credential endpoint:

• POST .../tables/{table}/temporary-table-credentials
• POST .../volumes/{volume}/temporary-volume-credentials
• POST .../models/{model}/versions/{version}/temporary-model-credentials
• POST .../skills/{skill}/temporary-skill-credentials

The protocol is defined as a set of markdown specifications in the spec/ directory:

OpenSharing is a superset of Delta Sharing. All existing Delta Sharing clients are compatible with OpenSharing.

Note: All connectors currently support Table sharing. Support for Volumes, Models, and Agent Skills is in progress.

The Python connector allows you to load shared tables as pandas DataFrames or Apache Spark DataFrames. Install via pip:

pip install delta-sharing

See the Python connector documentation for usage.

The Apache Spark connector supports SQL, Python, Java, Scala, and R, and integrates with Spark Structured Streaming for incremental data processing.

See the Apache Spark connector documentation for usage.

OpenSharing is being submitted as a sandbox project under the Linux Foundation AI & Data foundation. The protocol is developed in the open, and we welcome contributions, feedback, and implementations from across the data and AI ecosystem.

How to participate:

• Feedback on protocol design — Open an issue or discussion in this repository
• Implement a server or client — Any compliant implementation is welcome
• Propose new asset types — Open an issue describing the use case and asset model
• Join the community — [Community channels TBD]

This specification is a community proposal. Many of the AI asset types described in this document are early proposals, and we are actively soliciting input on the design choices before finalizing the spec. See ROADMAP.md for the current direction and open questions.

The OpenSharing specification is licensed under Apache 2.0.