In many libraries, keys are identified by byte sequences. For example, consider
OpenSSL functions such as EVP_EncryptInit_ex, or javax.crypto methods such as
"Cipher.init" taking both a key and a parameter spec.
Tink aims to be different, and expects a key to always consist of the key material itself plus the metadata. To emphasize this, we sometimes call this a "Tink key".
A full AEAD key for example specifies in exact detail how a plaintext is encrypted, how the ciphertext is encoded (e.g. initialization vector, followed by the encryption, followed by the tag), and how decryption exactly works, i.e., it specifies the two functions \(\mathrm{Enc}\) and \(\mathrm{Dec}\) for encryption and decryption.
This is in particular different from a full AES key, which describes a permutation on 128, 192, or 256 bits. Hence, a full AES key and a full AES-GCM key are very different objects in Tink -- in many cryptographic libraries, both would just be bit strings of length 128, 192, or 256 bits.