OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Fwd: [dss-x-comment] Questions about DSS-X Local Signature Computation Version 1.0

Dear team members,

We received some comments on the local signature profile.

I have prepared a response ('Comment and Reply.doc') and a list of
changes for the XSD/document ('Changes.doc').

Hopefully we can come to some conclusions during the next conf. call.

With kind regards

Ernst Jan

-------- Forwarded Message --------
Subject: [dss-x-comment] Questions about DSS-X Local Signature
Computation Version 1.0
Date: Mon, 26 Sep 2016 14:20:48 +0200 (CEST)
From: Szabó Áron <baronsz@freemail.hu>
To: dss-x-comment@lists.oasis-open.org

Dear Members,

I am writing in connection with Local Signature Computation Version 1.0

I have seen the e-mail sent on 2015-08-25 about the announcement of
publication the specification Version 1.0. I looked through the related
descriptions and schemas and I found that somehow the "final" version of
XML schema does not correspond to "final" version of specification. I
could perform XML schema validations on sample XML files by using
"csprd02". E.g. from "final" XML schema the "RequestDocumentHash" is
missing, it contains "ReturnDocumentHash". Also there was a comment
about this in "Appendix E" but it is not clear which version may be the
last: 'Processed the comments on CSD 01; see
Renamed localsig:ReturnDocumentHash into localsig:RequestDocumentHash
(in Section in the code).' So, shall I use
"RequestDocumentHash" or "ReturnDocumentHash" in SignRequest messages?

The other thing that was interesting that at Two-Step Approach operation
mode (identified by:
"http://docs.oasis-open.org/dss-x/ns/localsig/two-step-approach";), the
"Profile" attribute at the SECOND SignRequest MUST also be
"http://docs.oasis-open.org/dss-x/ns/localsig";. For the FIRST
SignRequest, it is clear, that this identifies that returned value shall
be just a simple hash, but at the SECOND SignRequest the client shall
identify the finalized type of the result Signature structure which
should be e.g. "urn:oasis:names:tc:dss:1.0:profiles:XAdES" in case of
XAdES, isn't it?!

Anyway, just in general, I can say, that I liked the descriptions of all
uses cases in this document. They are all in conformance with NPAPI-free
operation modes that are supported by recently used, eIDAS-conform eID
systems such as German or Hungarian national eID cards.

BR, Aron

Attachment: Changes.doc
Description: MS-Word document

Attachment: Comment and Reply.doc
Description: MS-Word document

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]