### Discussion Topics (with strawman proposals based on current implementations)

#### File Retrieval Auth

Proposal: support use of any of the following options

1. Capability url provided by submitter (e.g., presigned url)

2. Headers provided by the submitter in manifest (may also include non-auth headers)
At manifest root and/or the file level in output (file level overrides root if present):

    "output": [{
        "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
        "headers": {"Authorization": "Basic aGVsbG86d29ybGQ="}
    }]

3. SMART backend services token use (submitter has pre-registered a recipient as a client)

At manifest root and/or the file level in output (file level overrides root if present):

    "output": [{
        "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
        "access": {fhir-base-url: "..."} //provide location for auth capability and endpoint lookup 
    }]

4. Signed JWT token (sent in a Authorization header as a bearer token when requesting file).

Receiving system would need to have it's public key in a well known location (or pre-coordiate)

At manifest root and/or the file level in output (overrides root if present):

    "output": [{
        "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
        "access": {type: "jwt-bearer-token"}
    }]

5. Asymmetric file encryption (detached JWE). Encrypted with recipient's public key.

Sending and receiving system would need to have their public key in a well known location, pre-coordiate, or share keys as part of the transaction. Moving forward would this option would require involvement from security experts.

    "output": [{
        "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
        "access": {
            type: "jwe", 
            "enc": "A256GCM",
            "alg": "RSA-OAEP",
            "iv": "Base64IV",
            "tag": "Base64Tag",
            "encrypted_key": "Base64WrappedKey",
            "aad_detached": true"
        }
    }]

6. Symmetric encryption with key directly in manifest

Maybe a slight improvment over high entropy URLs, providing an additional layer if they're guessed. Moving forward would this option would require involvement from security experts.

    "output": [{
        "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
        "access": {
            type: "jwe"
            "key": "base64-encoded-aes-key",
            "iv": "base64-encoded-iv",
            "tag": "base64-encoded-tag",
            "alg": "AES-GCM"
        }
    }]

7. ACL pre-configured for servers and buckets on the same cloud. Appears to server and client like unauthenticated access.

#### Bucket Wildcards

Proposal:
- Works for Auth #7 above or in combination with one of the other types of auth when a proxy server is used
- Requestor SHALL implement a S3 compatible `ListObjects` method

"output": [{
    "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3/*.ndjson",
    "wildcard": "true"
}]

#### File Format

Proposal: Allow import of individual resources and bundles (esp. when in bucket mode)

ndjson:

"output": [{
    "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
    "fileFormat": "application/fhir+ndjson"
}]

json:

"output": [{
    "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.json",
    "fileFormat": "application/fhir+json"
}]

#### File Metadata

Proposal: Optional SHA256 checksum, file id (for resubmission and error matching), count

"output": [{
    "url": "https://example.com/files/f6648327-1496-4ed4-9f39-944c4c6a2aa3.ndjson",
    "SHA256": "f9d08276bc85d30d578e8883f3c7e843",
    "fileId": "1234",
    "count": 100
}]

#### Partial manifests and paging

Proposal: Support multiple submissions

- `partialSubmission` boolean root element

Proposal: also support for "next link" from Bulk Optimize for paging
- Can include an "access" field with one of the auth approaches above.
- Compatible with bulk export

"link": [{
    "relation": "next",
    "url": "https://example.com/output/manifest-2.json"
    "access: {...}
}]

#### File Resubmissions

Proposal:
- `submissionId` or `resubmissionId` parameter at root of manifest
- Replacement at the file level - all resources from that file should be deleted (alternative option is to require recipients to match on file ids)
- All wildcard files share a single id?

#### Organize by Patient

Proposal:
- Include `outputOrganizedBy` at manifest root
- Include `type` for resource type files at the output file level
- Matches approach in Bulk Export

#### Manifest Format

Proposal: json or parameters based on content type / accept header
- Content type of `application/json` returns export style manifest
- Content type of `application/fhir+json` returns parameters style manifest

#### Request Metadata

Proposal: `metadata` parameter at root of the manifest for use case specific profiles in other IGs

"metadata": {
    "hcInformation": {
        "hcName": "..."
        "ueiNumber": "..."
        "grantNumber": "..."
        ...
    }
}

#### Import Directives

Proposal: `import` parameter at root of the manifest for use case specific profiles in other IGs

"import": {
    "replaceMode": "merge"
}

#### Error Return

Proposal: include severity in output from a bulk export associated with the submission

submissionId: "1234",
output: [{
    "url": "https://example.com/12345/importstatus.ndjson",
    "type": "OperationOutcome",
    "fileId": "123456",
    "countSeverity": {
        "success": 98,
        "error": 2
    }
}]