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: RE: [dss-x] Scope of interop


Title: Message

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



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