It adds service-side checks to verify that the CMK is the one that we think it is.
There have previously been discussions about whether the AWS KMS keyrings MUST check the CMK ARN in the response on decrypt to make sure that it matches the CMK ARN in the EDK's provider info. If we include this in the KMS call, we can make this a requirement rather than a after-the-fact check. This is very much in line with "correct by construction" and the removal of keyring trace.
It paves the way for an AWS KMS keyring that always writes the key name as the provider info rather than writing the CMK ARN in the kms:Encrypt/GenerateDataKey response.
This would enable using single-CMK keyrings for decryption that use CMK identifiers other than CMK ARN.
If all AWS KMS CMKs specify the provider info on kms:Decrypt calls, then the difference between "AWS KMS keyring that writes the CMK ARN in the response as provider info" and "AWS KMS keyring that writes the key name as provider info" could collapse to a simple optional configuration flag on initialization.
Should we say that provider info SHOULD/MUST be provided to the AWS KMS decrypt call? Do we do this for all AWS KMS decrypt calls?