S3 and identity

The S3 API

A deployment’s endpoint is an S3 endpoint. Existing code needs a new endpoint and a credential.

• AWS SDKs and tools, unmodified. Mint an access-key pair; boto3, the AWS SDK for JavaScript, the AWS CLI or any SigV4 client works with default signing, checksums and multipart. Set path-style addressing, or virtual-hosted where your deployment has it on (and SigV4 for boto3 pre-signed URLs). → S3 compatibility
• Pre-signed URLs. One GET or PUT, valid up to seven days.
• One tenant either way. Access key or bearer: same tenant, limits and receipts.

→ S3 compatibility

Your identity, not ours

Your users sign in with your own identity issuer. Name it once; we enable it. Each user’s signed token is their credential, with nothing to mint, mail or rotate, and their tenant is created on first use.

Before your issuer is wired in, an invite link gives you a key. → Connect your app

A tenant per user

Another user with a valid credential is refused on every read, list, write and delete, and each refusal is recorded witnessed. The store enforces it, so a bug in your app’s checks can’t leak one user’s data to another.

Bucket names are visible across a deployment’s tenants. Contents aren’t.