Remember which person or service supplied a file

Upload attribution distinguishes a person from a service identity.

Remember which person or service supplied a file

A file can arrive from a person, an anonymous session or a service. Wildo records the uploader as an identity and principal type, so later operations can distinguish who supplied it from where it is stored or which record owns it.

The upload flow derives that attribution from its execution context. An upload grant records the principal that delegated the upload, without claiming to identify whoever held the link.

Example — Distinguish a service upload from a person’s upload

An integration submits a document using a machine credential. Its file metadata records that machine principal instead of presenting the document as a human upload. A separately delegated upload is attributed to the grant’s minter, reflecting a different source of authority.

For engineers

The uploader resolver handles authenticated users, anonymous sessions and organization or application machine principals. For a machine, it records the authenticating credential ID and a credential-neutral principal type. These branches from file-uploader.utils.ts distinguish the two scope levels.

case ExecutionContext_ExecutionType.ORGANIZATION_MACHINE:
  return initiatorIds.machineCredential
    ? {
        uploadedBy: initiatorIds.machineCredential.credentialId,
        uploadedByEntityType: FileUploaderEntityType.ORGANIZATION_MACHINE,
      }
    : undefined;

case ExecutionContext_ExecutionType.APPLICATION_MACHINE:
  return initiatorIds.machineCredential
    ? {
        uploadedBy: initiatorIds.machineCredential.credentialId,
        uploadedByEntityType: FileUploaderEntityType.APPLICATION_MACHINE,
      }
    : undefined;

Read the resulting file metadata

These illustrative IDs show the resolver’s output for a signed-in person and an organization API key. They are metadata projections, not fields the upload request should supply.

const personUpload = {
  // executionContext.initiatorIds.userId === 'user-1'
  uploadedBy: 'user-1',
  uploadedByEntityType: FileUploaderEntityType.USER,
};

const serviceUpload = {
  // executionContext.initiatorIds.machineCredential.credentialId === 'org-key-1'
  uploadedBy: 'org-key-1',
  uploadedByEntityType: FileUploaderEntityType.ORGANIZATION_MACHINE,
};

Upload context	Recorded identity	What it tells you
Signed-in person	User ID + `USER`	Which authenticated person supplied the file.
Organization machine	Credential ID + `ORGANIZATION_MACHINE`	Which organization credential authenticated the upload.
Application machine	Credential ID + `APPLICATION_MACHINE`	Which application credential authenticated the upload.
Anonymous session	Anonymous-user ID + `ANONYMOUS_USER`	Which anonymous identity supplied it, without implying a registered account.
Delegated upload grant	The grant minter’s attribution	Who delegated the upload; not who possessed the link.

The machine type covers both API keys and OAuth clients. Its ID is the actual authenticating credential ID; it is not the organization ID, the credential creator’s user ID, or a universal service identity shared across different credentials. The execution context separately carries machineCredential.authMethod when a consumer needs the credential kind.

Keep the identity pair intact

uploadedBy and uploadedByEntityType are optional together: the file schema and service refuse a half-populated pair. Internal producers without a concrete uploader can omit both. A machine principal may be authenticated by an API key or an OAuth client; the uploader type does not collapse that distinction into an API-key-only label.

The pair is lightweight attribution, not a populated user object. Resolve a display name separately through the relevant identity surface when the interface needs one.

Separate uploader, owner and recipient

The resource scope decides ownership and file access. The uploader identifies the source of the upload; it does not grant every later reader access and it is not necessarily the owner of the parent record. Google Drive also uses the recorded user uploader to resolve the delegated connection that can fetch the remote file.

For grant uploads, the upload handler derives attribution from the validated grant’s minter metadata, for both user and machine minters. Neither identifies an unauthenticated bearer. Privacy erasure clears both attribution fields together, so a retained technical file row need not keep the uploader’s identifying value.

Remember which person or service supplied a file