This page aims to collect the comments on the Document "STAC Requirements for PRIP", downloadable from those links;
| Version | Link | Description |
|---|---|---|
| 1.0-RC1 | CAP-TN-0XX-BE_STAC_Requirements_for_PRIP-1.0-RC1.docx | Preliminary version that will be updated with detailed requirements regarding downloading of assets from S3 buckets. |
| 1.0-RC2 (current) | CAP-TN-036-BE_STAC_Requirements_for_PRIP-1.0-RC2.docx | This version takes into accounts Jolyon’s comments on version 1.0RC1 and defines additional requirements for PRIP Instance and PRIP Client, in particular regarding the download of EOPF products from S3 buckets. |
Different solutions are identified for storing and retrieving assets on S3 buckets. Those solutions are described in following presentation.
Storing ZARR on S3 for STAC.pptx
Comments on the current version of the ICD can be added in the following table:
| Id. | Author | Section/Page number | Title | Comment |
|---|---|---|---|---|
| 1 | DLR | 2 Objectives and needs, page 8 | Scope of document | The STAC concepts are already descibed in [STAC_EOF_ICD]. The scope of this section could be more on the PRIP and its objectives and context, as in the current OData ICD. |
| 2 | DLR | 3.2 Nominal use scenario description, page 12 | Queryables and collection metadata | There is a strong relation between the Queryables, the STAC data model and the use cases of the service. Therefore we would expect this ICD to define the exact set of Queryables and the collection metadata for the PRIP. |
| 3 | DLR | 3.2 Nominal use scenario description, page 12 | Sequence diagram | The sequence diagram indicates to query the catalog metadata, queryables and collection metadata every time before doing the product search. But systematic downloaders doing regular search requests usually know the Queryables and collection metadata (see comment above). The diagram could be streamlined to reflect this case. |
| 4 | DLR | 3.2 Nominal use scenario description, page 12 | Downloading zipped EOPF products | The downloading step could be extended to also reflect the download of a zipped EOPF product (zipped Zarr hierarchy). In this case, the S3 list objects operation is not needed. |
| 5 | DLR | STAC-PRIP-ITEM-REQ-0050, page 21 | Product Type | Why is an explicit Product Type property needed here since the product type is already reflected by the collection, as stated in STAC-PRIP-COL-REQ-0020? |
| 6 | DLR | STAC-PRIP-ITEM-REQ-0050, page 21 | Expiration Date | The "unpublished" property would perhaps be semantically closer to the OData property EvictionDate than "expires". |
| 7 | DLR | STAC-PRIP-ITEM-REQ-0090, page 24 | Local Folder Name | What is the purpose of Local Folder Name property here? In case of an asset's href pointing to an individual group of measure or band of the Product, the local folder name is already included in the S3 URL as prefix. |
| 8 | DLR | 3.1 Architecture overview, page 10 | S3 Authentication | Requests to the STAC API require authentication via a bearer token. However, both the text and the architecture diagram in Section 3.1 suggest that requests to and downloads from the S3 store currently do not require authentication. The same applies to the command in 3.4.3.4 Downloading ZARR content (see comment below). Later in the document, the requirement "STAC-PRIP-API-REQ-330 – S3 API endpoint authentication" (page 27) indicates the need for an authentication mechanism. To enhance security, an authentication mechanism should also be enforced for the S3 API. If a technical solution for such a mechanism is already planned, it should be explicitly documented and specified in CAP-TN-036-BE. Additionally, would it be feasible to use the same bearer token for both the STAC API and the S3 API to ensure consistency and simplify the implementation? |
| 9 | DLR | 3.2 Nominal use scenario description, page 11 ff. | Authentication procedure | The authentication procedure for the STAC API (retrieving, submitting, and verifying the bearer token) is missing from the use scenario, even though it constitutes an essential part of the workflow. The same applies to the authentication mechanism for the S3 API. |
| 10 | DLR | 3.4.1.2 Authentication and authorization requirements, page 26 ff. | Automatic authentication token retrieval without manual interaction | Systematic downloaders must be able to automatically retrieve authentication tokens without requiring any manual interaction. A requirement should be added to address this need. Similarly, the authentication mechanism for the S3 API should also avoid manual interaction. In "STAC-PRIP-API-REQ-380 – Keeping an access token up-to-date," it is specified that the PRIP Client is responsible for maintaining its access token by leveraging the refresh token OIDC flow. However, the details of the refresh token OIDC flow are not specified in the document and should be elaborated further. Key questions include: How long is a refresh token valid? Can a refresh token be retrieved automatically? As stated above, manual interaction should be minimized wherever possible. |
| 11 | DLR | 3.4.2 PRIP Client requirements, page 28 | PRIP client authentication for S3 download | A requirement specifying the PRIP client authentication mechanism for S3 downloads, analogous to "STAC-PRIP-API-REQ-370 – PRIP Client authentication for STAC browsing," should be added to define the authentication procedure for the S3 API. Would it be feasible to use the same bearer token for both the STAC API and the S3 API to ensure consistency and simplify the implementation? |
| 12 | DLR | 3.4.3.4 Downloading ZARR content, page 37 | Downloading procedure | The command does not include authentication against the S3 API. However, an authentication mechanism is needed as stated in one of the comments above and in "STAC-PRIP-API-REQ-330 – S3 API endpoint authentication". |
| 13 | DLR | 3.4.3 Use case examples, page 30 ff. | Detailed examples for product search | It would be helpful for a client to have more examples for querying product especially in terms of filtering (by name, geography, datetime), counting and paging through search results. |
| 14 | DLR | General | Quotas | The current PRIP is supposed to apply quotas to orders and downloads. If this is also a requirement for the STAC-based PRIP, a corresponding section should be added to the document. |