<xs:extension base="dss:DocumentBaseType"> <xs:choice> <xs:element name="Base64Data" type="dss:Base64DataType"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> JSON Syntax Element name mapping table: Element JSON Member Name ConceptName A_SIMILAR_THING Element JSON member name Base64Data b64Data Type TransformedDataType The contains the following elements (in addition to the common ones listed in TransformedDataType section 2.1.1): [Required on a SignRequest] [Optional on VerifyRequest] ds:Transforms This is the sequence of transforms applied by the client and specifies the value for a <ds:Reference> element’s <ds:Transforms> child element. In other words, this specifies transforms that the client has already applied to the input document before the server will hash it. [Required] Base64Data . [Ignored on a SignRequest] [Optional on a VerifyRequest] WhichReference As there may be multiple / elements of the same document having TransformedData DocumentHash the same [RFC 2396] and on a SignRequest or VerifyRequest - their correspondence to an URI RefType already existing <ds:Reference> however needs to be established on a VerifyRequest only. is a need to disambiguate such cases. This element hence offers a way to clearly identify the ds:Reference when and match multiple / / URI RefType ds:References TransformedData The corresponding is indicated by this zero-based DocumentHash. ds:Reference WhichReference attribute (0 means the first <ds:Reference> in the signature, 1 means the second, and so on). Note: It may be possible to establish the / / ds:References TransformedData DocumentHash correspondence by comparing the optionally supplied chain of transforms to those of the having the same and in the supplied if this chain of ds:References URI RefType ds:Signature transform has been supplied. This can be quite expensive and even outweight the advantages of TransformedData / DocumentHash.
<xs:extension base="dss:DocumentBaseType"> <xs:choice> <xs:element name="Base64Data" type="dss:Base64DataType"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> JSON Syntax Element name mapping table: Element JSON Member Name ConceptName A_SIMILAR_THING Element JSON member name Base64Data b64Data Type TransformedDataType The TransformedDataType contains the following elements (in addition to the common ones listed in section 2.1.1): ds:Transforms [Required on a SignRequest] [Optional on VerifyRequest] This is the sequence of transforms applied by the client and specifies the value for a <ds:Reference> element’s <ds:Transforms> child element. In other words, this specifies transforms that the client has already applied to the input document before the server will hash it. Base64Data [Required] . WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest] As there may be multiple TransformedData / DocumentHash elements of the same document having the same URI [RFC 2396] and RefType on a SignRequest or VerifyRequest - their correspondence to an already existing <ds:Reference> however needs to be established on a VerifyRequest only. is a need to disambiguate such cases. This element hence offers a way to clearly identify the ds:Reference when URI and RefType match multiple ds:References / TransformedData / DocumentHash. The corresponding ds:Reference is indicated by this zero-based WhichReference attribute (0 means the first <ds:Reference> in the signature, 1 means the second, and so on). Note: It may be possible to establish the ds:References / TransformedData / DocumentHash correspondence by comparing the optionally supplied chain of transforms to those of the ds:References having the same URI and RefType in the supplied ds:Signature if this chain of transform has been supplied. This can be quite expensive and even outweight the advantages of TransformedData / DocumentHash.
dss-core-v2.0-wd01-2017-05-29.docx