When validating a policy signature, we currently take the creating identity's currrent transaction list and validate the signature against it. This is mostly fine, but if the policies or admin keys have changed since the signature was created, it could invalidate the signature. Because SignV1 transactions track their position in the DAG via previous_transactions, it makes sense to reset that identity to the latest of the transactions in that prev list and try the validation again. If it succeeds, we warn the user "this signature was not valid against the current version of the identity, but was valid against a past version."
When validating a policy signature, we currently take the creating identity's currrent transaction list and validate the signature against it. This is mostly fine, but if the policies or admin keys have changed since the signature was created, it could invalidate the signature. Because
SignV1transactions track their position in the DAG viaprevious_transactions, it makes sense to reset that identity to the latest of the transactions in that prev list and try the validation again. If it succeeds, we warn the user "this signature was not valid against the current version of the identity, but was valid against a past version."