Hello Andreas,
I agree with you that the current
interoperability of visible signatures should be focused on PDF since it is the
most matured visible signature solution exists today.
Regards,
Ezer
-----Original Message-----
From: Andreas Kuehne
[mailto:kuehne@trustable.de]
Sent: Monday, February 01, 2010
2:33 PM
To: dss-x@lists.oasis-open.org
Subject: Re: [dss-x] Scope of
interop
Hi all,
here's my view on the interop scope :
I would appreciate to have the core sliced into some conformance levels like
- plain CMS
- XMLDSig
- timestamping
both for signing and verification. This would make it easier for implementors
to be compliant with the core and solve the defined testcases.
The most relevant profiles for an interop to me are
- verification reports
- visible signatures
But the visible signature profile targets such a broad variety of different standards
that I would suggest to define a conformance scope for plain PDF signatures
using CMS.
The other profiles ( even the ones I am editing ) are special interest profiles
with no need to be embedded in a first interop.
Greetings
Andreas
----- Original Message ----
From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
To: dss-x <dss-x@lists.oasis-open.org>
Sent: Tue, January 19, 2010 6:32:03 PM
Subject: [dss-x] Scope of interop
Dear all, also during yesterday's call we started to talk about the scope of
the interop. By scope we meant on what protocols (i.e., core and profiles) we
would like to define test cases and conduct interop tests, and for each of
those profiles and/or core, what features we would like to target.
Could we start a thread of discussion on this topic?
Here it comes my initial contribution, restricted to the core :
Core: I think that we should define test cases for the core. As for features
see below:
Type of input documents:
<InputDocuments>: I would say that we should deal with <Base64XML>,
<Base64Data> and <InLineXML>.
Features proposed to be tested for signing protocol (Optional Inputs):
<ClaimedIdentity>
<SignatureType> (this also relates one of the questions that were raised
during the discussion: what signatures should be tested?)
One signature detached and one enveloping (this last one requires
<IncludeObject> optional input).
<SignaturePlacement>
(not sure of SignedReference)
Will think of verification protocol and raise a proposal...
At the meeting it was commented that the csvr profile would be one of the
targetted profiles, although maybe in not its entire extension at the first
iteration, as it is rather complex....
Please make comments to this and also let us know your views on profiles that
should also be targetted...
Regards
--
Andreas Kühne phone: +49 177 293 24 97 mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht
Hamm HRB 5868
Directors Andreas Kühne Heiko Veit
Company UK Company No: 5218868 Registered in England and Wales