Andrew Thoelke

I think we should remove `_operation` from the `xxx_init()` functions as well. The pattern in the API so far is that a data structure `psa_foo_t` has an init macro `PSA_FOO_INIT`...

For key agreement, the `psa_key_agreement_iop_setup()` signature is not correct. It is missing the algorithm, and I think we should match the parameter ordering in the non-interruptible API: ``` psa_status_t psa_key_agreement(psa_key_id_t...

I've updated the PR with the revised naming scheme, and tidied up a couple of loose ends. This might be just about ready? I note that the introduction of the...

> I think it would be better to use the simpler iops to demonstrate the pattern, and indicate how more complex operations can use the setup/complete pattern multiple times? I...

I think that as this has a variable length element, even if the current use cases do not have a wildly varying size, it might be best to categorise this...

> Overlap, no. But stability, yes. The implementation is allowed to assume stability for an input non-buffer (e.g. `const psa_key_attributes_t *`) but not for an input buffer (e.g. `const uint8_t...

Perhaps the critical aspect here is that the `flags` field in the parameters is expected to control the behavior (code flow) within the implementation (e.g. by indicating a specific construction...

As noted in https://github.com/ARM-software/psa-api/pull/194#discussion_r1557651496 and https://github.com/Mbed-TLS/mbedtls/issues/9020, this API is unsupportable in a project that might be included and called from C++ source code. We will have to separate the structure-like...

### API design thoughts On first review of the specification, it might be tempting to try and implement the public-key encryption algorithm, K-PKE, that underlies ML-KEM, as a PSA Crypto...

> It seems technically possible to just define K-PKE ... At the moment, I am strongly leaning toward a new KEM API, and keeping K-PKE as an internal implementation detail...