This approach does not handle non-standard approaches for wrapping keys: e.g. using an application-specific format for key meta-data with a standard AEAD algorithm. Ideas for handling such scenarios:

1. Left to the application: export the key data and drive AEAD from the application. This has the key material in plaintext (for a time) in the application memory.
2. Handled as a custom wrapped-key format: the implementation has to provide built-in support for the application design.
3. Use a different (or additional) Crypto API design. For example, add an input function to an AEAD multi-part operation that updates the operation with a formatted key.

I think we need to identify a representative set of use cases to cover the important ways in which the API needs to support key wrapping. And ensure we consider agility for future key types (PAKE, PQC, etc.) as part of the process.

It may be that we need more than one API to handle standard wrapped-key formats that are self-describing (in terms of wrapping algorithm(s)); general purpose key wrapping algorithms (typically specialized AEAD algorithms); and applications that use AEAD algorithms to create non-standard key-wrapping schemes.

I'm thinking about a change of plan here. Seemy comment in Issue#50.