Re: [dss-x] Feedback on the use of the DSS visible signature profile

[Stefan Drees <stefan@drees.name>]

Dear Ernst Jan,

thank You for taking the time to express and submit this feedback with 
regard to the visible signature profile and also the core requirement cited.

The agenda of todays call has already been updated with your comments 
mail URL in the previously reserved slot (agenda item 8.1).

(Will the updated Excel for the interop follow :?)

All the best,
Stefan.

Am 14.05.12 15:23, schrieb Ernst Jan van Nigtevecht:
> Dear TC-members,
>
> Below some feedback on the use of the visible signature profile.
>
> With kind regards
>
> Ernst Jan
>
> ===============
> Related to the DSS Core:
>
> (1) Regarding message validation by means of XSD's: The OptionalInputs /
> OptionalOutputs are defined as anyType. The OptionalInputs and
> OptionalOutputs can appear in any order:
>
> DSS-Core Line 615: "Applications MUST be able to handle optional inputs
> or outputs appearing in any order within these elements. Normally, there
> will only be at most one occurrence of any particular optional input or
> output within a protocol message."
>
> Usually, an XSD defines elements in a particular order. Consequently,
> you cannot define an XSD for this. To validate a request, the part of
> the OptionalInputs will always succeed, even though the actual sub-tree
> does not adhere to a specific optional input XSD.
>
> Question 1:
> The XSD of a particular OptionalInput / OptionalOutput will be
> specified, but how can one easily validatie a message using the dss xsd
> and the profile specific xsd? It currently seems that you have to
> manipulate the dss xsd to incorporate the OptionalInputs xsd (leaving
> out the anyType for the OptionalInput, but that invalidates "any order").
>
> It could have been stated that the order of the OptionalInputs /
> OptionalOutputs has to be alphabetically.
>
> What is the experience of other implementers?
>
>
> ===============
> Related to DSS profile visual signatures:
>
> (2) It seems that the ServicePolicy is not yet used. Instead, some
> profiles define their own policy elements.
>
> DSS-Core: 2.8.1 Optional Input <ServicePolicy>
>
> DSS-profile-visualsig: 4.1.1.2.1.2 Optional Input <VisibleSignaturePolicy>
>
> Question 2:
> Why has that been done?
>
>
> (3) If a DSS profile is defined, a value is defined for the profile
> attribute. The visual-sig profile states:
>
> DSS-profile-visualsig 3.1.3 Relationship to Other Profiles
> "This profile provides means for the explicit management of signature
> policies with [DSSCore] and other existing profiles like [AdES-DSS], and
> as such, it may be used in conjunction with these specifications."
>
> Question 3:
> What does the phrase "may be used in conjunction with these
> specifications" actually mean? How can one specify the use of two
> profiles in one and the same SignRequest (the profile attribute value
> can only hold one value).
>
> (4) Creation of multiple signature fields
>
> Currently, the newly defined OptionalInput can occur 0..unbounded times,
> besides other optional input (from other profiles).
>
> Question 4:
> For ease of XML validation, and code generation (especially Java), it
> would be good to define 1 (new) element containing 1 or more elements
> defining the (currently defined) visible signatures.
>
> The OptionalInput for the visible signature profile will consist of 1
> single element. (This principle should be used by other profiles as
> well.. :-)
>
> Proposal A:
> The OptionalInput for the visible signature profile will consist of the
> element:
> <VisibleSignatures>
>
> The type defines an element consisting of a choice, consisting of
> <VisibleSignatureProfile> element,
> <VisibleSignatureConfigurations> element (as already defined in the
> current visible signature profile)
>
> The <VisibleSignatureProfile> provides a name for a visible signature
> profile id, to be used during document submission (and certification).
>
> (5) We would like to be able to use the profile for the following scenario:
>
> * The DSS client creates a SignRequest with information about the
> signature fields and the field that has to be used for certification
> * The DSS server creates the indicated fields and signs (certifies) the
> document (using the indicated field).
> * The DSS server delegates the signing operation of the other signature
> field(s) to an application (an applet for instance). An enduser will
> sign a certain field
> * The DSS server creates a SignResponse
>
> Proposal B:
> The OptionalOutput defines a means to indicate which signature field has
> been signed (in DSS delegates the actual signature operation to an
> applet by which the enduser will select a field and creates a signature).
>
> An optional output would consist of an element
> <VisibleSignatures> containing, one or more elements:
>
> <VisibleSignature> consisting of a
> <FieldName> which specifies a name of the field and an attribute
> isSigned (boolean).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dss-x-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dss-x-help@lists.oasis-open.org

Attachment: smime.p7s
Description: S/MIME Kryptografische Unterschrift