Accept-Signature and signature algorithm or key selection #50
Description
Example 3 (which is really two examples, but that's not important) appears to attempt to codify a use of keyid for signaling the expected public key to use in producing signatures. This is interesting in that it allows servers to avoid excessive signing when clients aren't going to use them.
However, this is not specified. What appears to happen here is that the type parameter, which is not specified anywhere I can find, is used to identify the algorithm.
This could have used the full integrity attribute value as the key ID. Instead, it's inventing a new parameter and a convention (?) for that parameter that takes the signature integrity algorithm identifier and adds "-integrity". That's an extension to RFC 9421 that would need to be specified properly to use it.
In practice, you can probably use this without the type parameter. Public keys are high entropy and highly unlikely to collide. You can't produce a signature if you don't have the necessary keys, so identifying via the public key is sufficient. Maybe you don't need the type parameter at all.
Of course, the next problem is that PQ signatures (you'll want those eventually, right) are a little larger than is ideal. Would it be better to hash the public key? You only need high probability of the values being collision-free, so you could use a truncated hash.