Currently, MAC calculations always generates a {4: "k"} where k is the 1-long string encoded in the numeric kid:

    let mac_2 = compute_mac_2(
        crypto,
        &prk_3e2m,
        c_r,
        &cred_r.get_id_cred(),
        cred_r.value.as_slice(),
        &th_2,
        ead_2,
    );

    pub fn get_id_cred(&self) -> BytesIdCred {
        [0xa1, 0x04, 0x41, self.kid] // cbor map = {4: kid}
    }

However, as I understand the RFC, the value should be

• what we currently do iff the serialized ID_CRED_x was a number
• something similar to what we do currently on longer KID (which we don't support)
• the literal ID_CRED_x otherwise

This is only becoming apparent through the latest PRs #267, #270 and #271 -- without those, pass-by-kid was the only option anyway.

I think we'll have to overhaul a bit how we transport ID_CRED_x, CRED_x and how we link them to each other.

I anticipate that any plug test we do with a different implementation will fail as soon as we try anything but ID_CRED_x-is-KID with another implementation.