Electronic PostMark (EPM) Profile of the OASIS Digital Signature Service Version 1.0
Committee Specification
13 February 2007
Specification URIs:
This Version:
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-epm-spec-cs-v0.1-r1.html
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-epm-spec-cs-v0.1-r1.pdf
Latest Version:
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-epm-spec-cs-v0.1-r1.html
http://docs.oasis-open.org/dss/v1.0/oasis-dss-profiles-epm-spec-cs-v0.1-r1.pdf
Technical Committee:
OASIS Digital Signature Services TC
Chair(s):
Nick Pope, Thales eSecurity
Juan Carlos Cruellas, Centre d'aplicacions avançades d’Internet (UPC)
Editor(s):
Ed Shallow, Universal Post Union
Related work:
This specification is related to:
Abstract:
This document defines a profile of the OASIS DSS protocol for the purpose of creating and verifying signatures and timestamps which support the extended features of the Universal Postal Union’s Electronic PostMarking service.
Status:
This document was last revised or approved by the OASIS Digital Signature Services TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/dss.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/dss/ipr.php.
The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/dss.
Notices
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS® 1993–2007. All Rights Reserved. OASIS trademark, IPR and other policies apply.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The names "OASIS" are trademarks of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.
Table of Contents
2.3 Relationship To Other Profiles
2.7.1.1 Element <InputDocuments>
2.7.1.2 Element <DocumentWithSignature>
2.7.2 Element <PostMarkedReceipt> and the PostMarkedReceipt Signature
2.7.3 Output Element <TransactionKey>
2.7.4 Input Element <OrganizationID>
3.1.1 Constraints on Element <OptionalInputs>
3.1.1.3 Element <AddTimestamp>
3.1.1.4 Optional Input <Properties>
3.1.1.5 Optional Input <SignedReferences>
3.1.1.6 Optional Input <IncludeObject>
3.1.1.7 Optional Input <SignaturePlacement>
3.1.2 EPM-specific <OptionalInputs>
3.1.2.1 Element <DocumentContainsTemplate>
3.1.2.2 Element <TransactionKey>
3.1.2.3 Element <ClaimedIdentity>
3.1.2.4 Element <OrganizationID>
3.1.3 <OptionalInputs> Processing Directives
3.1.3.1 Element <IssuePostMarkedReceipt>
3.1.3.2 Element <StoreNonRepudiationEvidence>
3.1.3.3 Element <ReturnSignatureInfo>
3.1.3.4 Element <ReturnX509Info>
3.2.2 Element <SignatureObject>
3.2.3 EPM-specific <OptionalOutputs>
3.2.3.1 Element <TransactionKey>
3.2.3.2 Element <PostMarkedReceipt>
3.2.3.3 Element <SignatureInfo>
4 Profile of Verifying Protocol
4.1.1 Constraints on Element <OptionalInputs>
4.1.1.1 Element <InputDocuments>
4.1.1.3 Element <AdditionalKeyInfo>
4.1.1.4 Element <ReturnProcessingDetails>
4.1.1.5 Element <ReturnSigningTime>
4.1.1.6 Element <ReturnSignerIdentity>
4.1.1.7 Element <VerifyManifests>
4.1.1.8 Element <ReturnUpdatedSignature>
4.1.1.9 Element <ReturnTransformedDocument>
4.1.2 EPM-specific <OptionalInputs>
4.1.2.1 Element <OrganizationID>
4.1.2.2 Element <IgnoreManifests>
4.1.2.3 Element <SignatureSelector>
4.1.2.4 Element <IssuePostMarkedReceipt>
4.1.3 <OptionalInputs> Processing Flags
4.1.3.1 Element <StoreNonRepudiationEvidence>
4.1.3.2 Element <ReturnSignatureInfo>
4.1.3.3 Element <ReturnX509Info>
4.2.2 Element <SignatureObject>
4.2.3 Element <OptionalOutputs>
4.2.3.1 Element <DocumentWithSignature>
4.2.4 Element <EPM-specific OptionalOutputs>
4.2.4.1 Element <TransactionKey>
4.2.4.2 Element <PostMarkedReceipt>
4.2.4.3 Element <SignatureInfo>
7 Element cross-reference Table
The Electronic Postmarking service is a Universal Postal Union (UPU) endorsed standard aimed at providing generalized signature creation, signature verification, timestamping, receipting, and evidence logging services for use by and across Postal Administrations and their target customers.
Although the total scope and functional coverage of the EPM’s service offering are outside the immediate scope of the DSS initiative, the UPU wishes to offer its client base a DSS-compliant subset of the EPM for clients who wish to maintain OASIS compliance in the core areas of signature and timestamp, creation and verification. This profile can be used directly as the basis for implementing interoperable systems.
Implementers wishing to take their implementations of this profile to market are asked to do so through any of the Postal Administrations participating or wishing to participate in the global EPM initiative. Any client is free to develop service request calls which adhere to this interface and receive their corresponding service responses.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]. These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.
This specification uses the following typographical conventions in text: <ns:Element>, Attribute, Datatype, OtherCode.
1.2 Normative References
[Core-XSD] S. Drees et al. DSS Schema. OASIS, February 2007
[DSSCore] S. Drees et al. Digital Signature Service Core Protocols and Elements. OASIS, February 2007
[RFC 2396] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. http://www.ietf.org/rfc/rfc2396.txt, IETF RFC 2396, August 1998. .
[TS 101733] CMS Advanced Electronic Signatures. ETSI TS 101 733, January 2007.
[XAdES] XML Advanced Electronic Signatures. ETSI TS 101 903, March 2006
[XML-ns] T. Bray, D. Hollander, A. Layman. Namespaces in XML. http://www.w3.org/TR/1999/REC-xml-names-19990114, W3C Recommendation, January 1999.
[XMLSig] D. Eastlake et al. XML-Signature Syntax and Processing. http://www.w3.org/TR/1999/REC-xml-names-19990114, W3C Recommendation, February 2002.
[RFC 2634] P. Hoffman (ed.). Enhanced Security Services for S/MIME, http://www.ietf.org/rfc/rfc2634.txt, IETF RFC 2634 June 1999.
[RFC 3369] R. Housley, Message Syntax (CMS).. http://www.ietf.org/rfc/rfc3369.txt , IETF RFC 3369 August 2002.
[EPM] Universal Postal Union, Electronic PostMark Web Service Description Language (WSDL) the UPU’s Postal Technology Centre http://www.ptc.upu.int/
1.3 Non-Normative References
1.4 Namespaces
The structures described in this specification are contained in the schema file [EPM]. All schema listings in the current document are excerpts from that schema file. In the case of a disagreement between the schema file and this document, the schema file takes precedence.
This schema is associated with the following XML namespace:
http://www.docs.oasis-open.org/dss/2004/04/oasis-dss-1.0-profiles-EPM-wd-09#
If a future version of this specification is needed, it will use a different namespace.
Conventional XML namespace prefixes are used in this document:
Ø The prefix dss: (or no prefix) stands for the DSS core namespace [Core-XSD].
Ø The prefix dsig: stands for the W3C XML Signature namespace [XMLSig].
Ø The prefix xs: stands for the W3C XML Schema namespace [Schema1].
Ø The prefix saml: stands for the OASIS SAML Schema namespace [SAMLCore1.1].
Ø The prefix epm: stands for the EPM Schema namespace [EPM].
Ø The prefix xades: stands for ETSI XML Advanced Electronic Signatures (XAdES) document [XAdES].
Applications MAY use different namespace prefixes, and MAY use whatever namespace defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML specification [XML-ns].
2.1 Identifier
urn:oasis:names:tc:dss:1.0:profiles:epm
2.2 Scope
This document profiles the DSS signing and verifying protocols defined in [DSSCore] and provides an OASIS DSS-compliant interface to selected services of the EPM. One of the primary intents of the EPM Profile is to simplify request and response processing for client callers by constraining [DSSCore] in several ways.
The EPM profile supports the creation and verification of both CMS/PKCS7 and [XMLSig] signature types.
Additional services within the EPM are supported through the extensibility mechanisms provided by the optional inputs and outputs of the [DSSCore]. This includes:
Ø Easy to use EPM “Signing Templates”
Ø PostMarked receipts
Ø Same document signatures is the default and preferred mechanism for handling signature creation and verification
Ø Certificate validation data
§ Revocation references
§ Certificate references
§ Online Certificate Status Protocol (OCSP) responses
Ø Timestamping from a CA-independent TimeStamp Authority
This profile constrains the <InputDocuments> element in that it may contain only one <Document> element. Additionally, this profile assumes that documents and their signatures are to be contained in the same XML document wherever possible. This considerably simplifies the amount of splicing that a client must perform when dealing with the protocol. This will be evident in the Input and Output constraints explained herein.
2.3 Relationship To Other Profiles
The profile in this document is based directly on the [DSSCore].
2.4 Signature Objects
This profile supports the creation and verification of XMLSig and CMS/PKCS7 signatures and timestamps as defined in [DSSCore].
2.5 Transport Binding
This profile is transported using either an XML-based HTTP payload POSTed to an implementation of this profile, or via a SOAP Transport Binding as defined in the OASIS EPM Profile Web Service Description language (WSDL).
2.6 Security Binding
2.6.1 Security Requirements
The TLS X.509 Server Authentication security binding as described in section 6.2.1 in [DSSCore] must be used. Although outside the scope of this protocol, clients are expected to authenticate to an implementation of this specification. At a minimum HTTP Basic Authorization should be used to authenticate. Implementations are expected to validate the user and password contained in the HTTP header.
2.7 Common Elements
This section describes elements used and referenced within both the Sign and Verify protocols as either Input or Output elements.
2.7.1.1 Element <InputDocuments>
The EPM profile also constrains the <InputDocuments> element such that the EPM server presently accepts only one <Document> or <DocumentHash> element (i.e. equivalent of maxOccurs="1"). This may change in a subsequent version of the EPM profile. Multiple <Reference> elements are supported. Users wishing to create signatures with multiple <Reference> elements should use EPM signing templates. See section 3.1.2.1 for details.
When the <Document> element is passed in by the user of this profile, it is assumed that it contains only the content to be signed or the signed document to be verified. When users wish to use the EPM’s “signing template” mechanism, they must also pass in a <DocumentContainsTemplate> element directive. Please also refer to section 3.1.2.1 below.
On the Verify protocol the processing differs slightly from the core in that input documents containing “same document” signatures can be passed in on a Verify request via the Document element. This avoids having to use the SignatureObject in conjunction with the SignaturePtr choice of that element. Since only one occurrence of the Document element is allowed, SignaturePtr is not required.
The dss:TransformedData choice is not supported by this profile.
The <Document> element is also used to pass in a signature to be timestamped when the <SignatureType> specifies a timestamp type. The MimeType should specify application/pkcs7-signature when passing in a signature to be RFC 3161 timestamped.
2.7.1.2 Element <DocumentWithSignature>
This element is used in conjunction with the SignatureObject element for returning signed and verified documents. For Sign operations, this element will be initialized and returned for [XMLSig] based signatures when the signature is an enveloped or detached one. Additionally if the caller is using EPM signing templates and has passed in a signing template (See section 3.1.2.1) by specifying the DocumentContainsTemplate element, then this output element will contain the signed document.
For verify operations this output element is only initialized for [XMLSig] based signatures when the <IssuePostMarkedReceipt> option is specified with a Location attribute specified as embedded. In this case the signed and verified document is returned along with the embedded PostMarkedReceipt in this output element. See also <IssuePostMarkedReceipt>.
<xs:element name="DocumentWithSignature">
<xs:complexType>
<xs:sequence>
<xs:element ref="dss:Document"/>
</xs:sequence>
</xs:complexType>
</xs:element>
2.7.2 Element <PostMarkedReceipt> and the PostMarkedReceipt Signature
A PostMarkedReceipt is a signature attesting to the validity of either the signature just created (Sign protocol) or the signature just verified (Verify protocol). It requires an additional profile element not part of [DSSCore] and that is the <PostMarkedReceipt> element. This element describes the EPM’s receipt structure, which works in conjunction with the standard <TstInfo> element of [DSSCore]. A PostMarkedReceipt signature is returned whenever the optional input <IssuePostMarkedReceipt> is included in either the Sign or Verify request. The PostMarkedReceipt is a superset of the DSS <Timestamp> element and carries specific meaning within the specific context of EPM service provisioning. Semantics as follows:
Ø Sign
When a PostMarkedReceipt signature is issued as a result of a Sign operation, the EPM is attesting to the origin of the signature and the validity of the certificate used to create it.
Ø Verify
Correspondingly, when the EPM issues a PostMarkedReceipt as a result of a Verify operation which requested an <IssuePostMarkedReceipt>, the EPM is attesting to the validity of both the verified signature as well as the validity (i.e. revocation status) of the public verification certificate contained therein.
See section 6 for a detailed example of a standalone PostMarkedReceipt signature returned after successful verification. The example illustrates a detached receipt signature representing the PostMark covering a signed and verified document. Additionally, all evidence surrounding this event is logged in the EPM’s non-repudiation database when the StoreNonRepudiationInfo Optional Input is specified.
The EPM supports the issuance of conventional timestamps, both embedded and standalone. The EPM-specific notion of a PostMarked receipt applies in both the embedded and standalone scenarios. Both are valid within the Sign protocol.
All receipts are tied to a specific EPM operational transaction as specified by the enclosed <TransactionKey> element.
The <PostMarkedReceipt> element is similar to the <dss:Timestamp> when applied to XMLSig-based signatures.
PostMarkedReceipt signatures returned in XMLSig signatures scenarios, are exactly three (3) <dsig:Reference>’s which make up the signature associated with the PostMarkedReceipt. They are as follows:
Ø <dsig:Reference> whose URI attribute references a <dsig:Object> containing the <TstInfo>
Ø <dsig:Reference> whose URI attribute references a <dsig:Object> containing the <epm:PostMarkedReceipt>
Ø <dsig:Reference> whose URI attribute references a <dsig:Object> containing the <dsig:SignatureValue> of the signature being PostMarked (Sign) or Verified and PostMarked (Verify)
EPM-produced <PostMarkedReceipt>’s, always bind the receipt to the signature just created or verified.
Please refer to the EPM documentation for additional policy and usage guidelines.
<xs:element ref="epm:PostMarkedReceipt"
<!-- imported from the EPM schema -->
<xs:element name="PostMarkedReceipt" type="epm:PostMarkedReceiptType">
<xs:complexType name="PostMarkedReceiptType">
<xs:sequence>
<xs:choice>
<xs:element name="PKCS7SignedReceipt" type="epm:PKCS7SignedReceiptType"/>
<xs:element name="XMLSignedReceipt" type="epm:QualifiedDataType"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PKCS7SignedReceiptType">
<xs:sequence>
<xs:element name="Receipt" type="epm:ReceiptType"/>
<xs:element name="ReceiptSignature" type="epm:QualifiedDataType" nillable="true"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ReceiptType">
<xs:sequence>
<xs:element name="TransactionKey" type="epm:TransactionKeyType"/>
<xs:element name="Requester" type="xs:string"/>
<xs:element name="Operation" type="xs:string"/>
<xs:element name="TSAX509SubjectName" type="xs:string"/>
<xs:element name="TimeStampValue" type="xs:string"/>
<xs:element name="RevocationStatusQualifier" type="xs:string"/>
<xs:element name="TimeStampToken" type="epm:QualifiedDataType" nillable="true" minOccurs="0" maxOccurs="1"/>
<xs:element name="MessageImprint" type="xs:base64Binary" nillable="true"/>
<xs:element name="PostMarkImage" type="epm:QualifiedDataType" nillable="true"/>
<xs:element name="ReceiptMetadata" type="epm:ReceiptMetadataType" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ReceiptMetadataType">
<xs:sequence>
<xs:element name="Name" type="xs:string"/>
<xs:choice>
<xs:element name="Value" type="xs:string"/>
<xs:element name="EncodedValue" type="epm:QualifiedDataType"/>
<xs:choice>
</xs:sequence>
</xs:complexType>
Note 1: The ReceiptSignature child element of the PostMarkedReceipt is only used when processing CMS/PKCS7 signatures where the receipt is standalone. It is simply used to protect the integrity of this standalone XML structure which contains an encapsulated CMS/PKCS7 <TimeStampToken>.
Note 2: The binary <TimeStampToken> element above can be omitted for [XMLSig]-based <SignatureType>’s since the PostMarkedReceipt is itself a signature which covers the <TstInfo> structure. EPM implementations using TimeStamp Authorities (TSAs), are however free to initialize this element with an RFC3161 Timestamp Token if they wish. The example is section 6 does not initialize the <TimeStampToken> element.
2.7.3 Output Element <TransactionKey>
This complexType is a compound key made up of 3 elements uniquely identifying each event in the an EPM Lifecycle. The EPM generates and returns a new and unique <TransactionKey> with all response operations. The <Locator> element is used to identify the particular EPM instance when multiple EPM instances are involved, as is the case with cross-border transactions. Please refer to EPM documentation for usage guidelines.
<xs:element ref="epm:TransactionKey"
<!-- imported from the EPM schema -->
<xs:element name=" TransactionKey" type="epm:TransactionKeyType">
<xs:complexType name="TransactionKeyType">
<xs:sequence>
<xs:element name="Locator" type="epm:LocatorType"/>
<xs:element name="Key" type=" xs:string"/>
<xs:element name="Sequence" type="xs:positiveInteger"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="LocatorType">
<xs:sequence>
<xs:element name="CountryCode" type="xs:string"/>
<xs:element name="Version" type="xs:string"/>
<xs:element name="ServiceProvider" type="xs:string" nillable="true"/>
<xs:element name="Environment" type="xs:string" nillable="true"/>
</xs:sequence>
</xs:complexType>
2.7.4 Input Element <OrganizationID>
This element is used when the requester’s organization name cannot or should not be derived from a public certificate (as would be the case with X509 Mutual Authentication). In those circumstances, this element should be initialized to the requester’s organizational name as an xs:string. This value will be validated at authentication time by the EPM service against registration-time information.
<xs:element name="OrganizationID" type="xs:string" nillable="true"/>
3.1 Element <SignRequest>
3.1.1 Constraints on Element <OptionalInputs>
Details on the constraints and semantics which exist with respect to the optional inputs as described in [DSSCore] follow in this section. All <OptionalInputs> not explicitly mentioned in this section are supported as defined in [DSSCore].
EPM-specific <OptionalInputs> are described below in the section entitled EPM-specific <OptionalInputs>.
3.1.1.1 Element SignatureType
The <SignatureType> element MUST be included in the EPM profile’s SignRequest.
The following <SignatureType> URNs are supported:
Ø Signature creation URNs:
§ urn:ietf:rfc:3275 (i.e. an XML Digital Signature)
§ urn:ietf:rfc:3369 (i.e. a CMS/PKCS7 binary Signature)
Ø Timestamp creation URNs:
§ oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken
§ urn:ietf:rfc:3161 (i.e. a CMS/PKCS7 timestamp token)
The first 2 URNs instruct the EPM to create a signature. The last 2 URNs instruct the EPM to create a timestamp. The context and processing rules within which the EPM creates signatures is different than the context within which the EPM creates timestamps. These differences will be highlighted below as they apply to each optional input and output, as constrained by the <SignatureType> chosen above. If no restriction is mentioned below, one may assume that the optional input is valid for timestamp <SignatureType>’s as well.
3.1.1.2 Element <KeySelector>
The <KeySelector> optional input must be supported by EPM implementations of this profile, but is not required when calling the EPM service as a client user (i.e. is optional). If the EPM cannot derive the key to use for signing from the underlying authentication being used, or if the X509SubjectName is not readily available, the <KeySelector> can be used. When using EPM signing templates, users may initialize the <KeyInfo> element in the signing template with a valid <X509SubjectName> in the <KeyName> child element of <KeyInfo>. The EPM will utilize the specified certificate/key as defined. See Example 1 in section 5 for an example of signing templates.
Note: This optional input does not apply when users are requesting a timestamp <SignatureType>. EPM implementations are, by definition, TimeStamp Authorities and will use TSA-specific signing keys expressly for that purpose.
3.1.1.3 Element <AddTimestamp>
The EPM supports this <OptionalInputs> element when used in the Sign protocol. Processing is the same as that described in [DSSCore].
See also section 3.1.3.1 <IssuePostMarkedReceipt> which delivers similar but different functionality than the <AddTimestamp> and results in the creation of an additional standalone <PostMarkedReceipt> structure which is a superset of a basic dss:XMLTimestamp. Both optional inputs are supported on a Sign operation and serve different purposes.
The <AddTimestamp> is also supported on the Verify operation, and will update the signature being verified. See also <IssuePostMarkedReceipt> which returns a timestamped receipt structure and has different semantic meaning. Please refer to section 4 covering the Verify.
Note: Content timestamps, created before signature generation, are currently not supported in the EPM profile (e.g. a timestamp created before signature generation and referenced as a signed property or attribute). They may however be added in a subsequent release of the EPM profile.
3.1.1.4 Optional Input <Properties>
This optional input element is not supported by this profile. If specialized signed or unsigned properties are required users are encouraged to use the EPM’s “signing templates” facility.
3.1.1.5 Optional Input <SignedReferences>
This optional input element is not supported by this profile. If greater control over Reference element creation is required, users are encouraged to use the EPM’s “signing templates” facility.
3.1.1.6 Optional Input <IncludeObject>
This optional input is supported by the EPM profile to produce enveloping signatures with the following constraints.The WhichDocument attribute is not required and hence not supported. The hasObjectTagsAndAttributesSet is also not supported. This profile supports only one <IncludeObject> in the request. The default and only behavior supported in this profile for this optional input is exactly as is described in the createReference attribute as specified in [DSSCore].
3.1.1.7 Optional Input <SignaturePlacement>
This element is supported with the following constraints. Only the last attribute of this element from [DSSCore] is supported. That is, the CreateEnvelopedSignature attribute is the only attribute supported. Default signature placement in this profile for enveloped signatures is to place the ds:Signature as the last child of the input Document’s root.
3.1.2 EPM-specific <OptionalInputs>
The following additional elements are specific to the EPM profile. There specific usage and constraints are documented below.
3.1.2.1 Element <DocumentContainsTemplate>
The <DocumentContainsTemplate> optional input element is a directive which tells the implementation that the <Document> element passed in on the request is a “signing template”. It is used when users elect to utilize the EPM’s “signing template” mechanism. EPM-supported signing templates contain not only the data to be signed, but also the format and directives of the signature to be created, expressed as valid [XMLSig] elements. In this fashion more elaborate signatures involving transforms, signed and unsigned properties, manifests, and multiple <Reference> elements can be supported without complex XML request constructs. [XMLSig] elements such as <SignatureValue>, <DigestValue>, and <X509Certificate> are populated by the EPM service based on the template provided. The user leaves these crypto-specific element tags empty, and the EPM service will automatically include the generated content and return the signed document in the <DocumentWithSignature> element of the <SignResponse>. See Example 1 in section 5 for an example of signing templates. More details are available in the EPM Systems Integrator’s Guide and other EPM documentation available though the UPU.
Note: When using templates, all [XMLSig] References must resolve within the single <Document> element passed in on the request. This compromise was chosen to provide maximum flexibility and ease-of-use.
<xs:element name="DocumentContainsTemplate"/>
3.1.2.2 Element <TransactionKey>
Please refer to the description in section 2.7.3 entitled Element <TransactionKey>
3.1.2.3 Element <ClaimedIdentity>
This optional complexType is an extension of the standard OASIS DSS <ClaimedIdentity> element. This extension to ClaimedIdentity utilizes the OASIS <SupportingInfo> to define EPM-specific additions required to support the authentication and assertion of the requester’s identity. The default authentication mechanism of an EPM implementation is external to the EPM profile and is supported by the conventions used in that underlying binding. In this fashion EPM implementations are free to authenticate users using standard approaches like HTTP Basic Authentication (i.e. Authorization: Basic in the HTTP header), or may decide to use stronger techniques involving Digest Authentication, encrypted cookies, one-time password schemes, two-factor tokens, or any of several other authentications schemes they chose. However there are situations where the underlying binding may not support the representation or the transport of the desired token type. For this reason, the EPM profile allows the chosen token type to be passed as “Authentication Information” as an attestation of, in support of, in addition to, or instead of the underlying authentication scheme and its assertion of identity. As such, it is not used solely as additional authentication information, but rather could be used as an adjunct to the authentication mechanism itself. This scheme-specific authentication support is carried in the abstract <AlternateIdentity> type.
The <RequesterSignature> element is optional and is used in support of “Proof-of-Possession” or “Proof-of-Delivery” in the EPM’s non-repudiation context. This element and its use-cases are further defined in the EPM Service Description documentation available through the Universal Postal Union.
<xs:element name="ClaimedIdentity">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="saml:NameIdentifierType"/>
<xs:element ref="epm:SupportingInfo">
</xs:sequence>
</xs:complexType>
</xs:element>
<!-- imported from the EPM schema