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


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

bothfor signing and verification. This would make it easier forimplementors to be compliant with the core and solve the definedtestcases.

The most relevant profiles for an interop to me are 

- verification reports
- visible signatures

Butthe visible signature profile targets such a broad variety of differentstandards that I would suggest to define a conformance scope for plainPDF 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

Dearall, also during yesterday's call we started to talk about the scope ofthe interop. By scope we meant on what protocols (i.e., core andprofiles) we would like to define test cases and conduct interop tests,and for each of those profiles and/or core, what features we would liketo 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 thediscussion: 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...

Atthe meeting it was commented that the csvr profile would be one of thetargetted profiles, although maybe in not its entire extension at thefirst 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]