The Contract.signer is unclear:

1) Now that there is a datatype "Signature" this datatype should be used. The Signature data type was patterned after the original proposal found in Contract. It contains the same elements and more that have been found to be helpful. It also explains the relationship of these elements to the content of the XML-Signature blob. It also clarifies that the blob must be base64 encoded, it can't be a signature as shown in Contract.signer.

2) The Contract.signer is unclear what is being signed. Presumably the intent of a signature across a contract, is intended to mean a "Digital Signature" across a contract.

2.1) Is there an intention to show 'signature on file' coverage? Meaning that there is some way in the contract resource to show the various places where there is a 'signature on file' managed elsewhere. That this there is a signature on file that is not a digital signature, or is a digital signature managed outside of the Contract resource.

2.2) Is there an intention to show a digital signature across the elements of binding, friendly, legal, or rule? If so, then these signature elements should be upon those elements to show context. Also if so, then there needs to be a clear differentiation between this signature and the signature that would be found in Provenance.

Given that there are many outstanding issues, and that the Provenance.signature seems capable of supporting the use-cases above; then I recommend that Contract.signer be eliminated until it can be more clearly explained in the context of these concerns.