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: raw notes 2010-04-12


Dear all,

Below follow the raw notes of today's meeting.

Regards

Juan Carlos.

NOTES:

sdrees: This is the chat room for  DSS-X TC OASIS Meeting # 58 (Conference Call)

sdrees: Stefan volunteers/is available for taking meeting minutes

sdrees: but have some trouble connecting to the free conf call line, still trying to connect ...





sdrees: regrets from Oscar and Ezer

juan carlos: 1. Welcome by chair (Juan Carlos Cruellas)

juan carlos: 2. Minute taker (volunteer needed - last minute takers:


juan carlos: JC will take quick notes

juan carlos: 3. Roll call

juan carlos: AK, EJ, SD, JC
regrets from Oscar and Ezer

juan carlos: quorum is not reached.

juan carlos: 4. Approval of the agenda.

juan carlos: agenda is approved as it is

juan carlos: 5. Approval of minutes.

juan carlos: skipped

juan carlos: 6. Discussion for Interoperability

6.1 Usage of assertions
http://www.oasis-open.org/apps/org/workgroup/dss-x/email/archives/201004/msg00000.html

sdrees: Please see also: http://wiki.oasis-open.org/dss-x/Preparation%20Interop%20DSS-X

juan carlos: AK: started to look at the core on SignRequest....

 ...looking from assertions point of view, one has to identify the MUST requirements... one has to identify what has to be done, and what error has to be raised if not met

...after scanning the document, I found a number of issues.....


JC: I have difficulties in foreseeing where to put in the assertions, who has to do something, what has to be done and what must be the output....


JC: what format for defining assertions? XML as in part 2 or free structured text of guidelines?

juan carlos: AK: to be discussed in the list

juan carlos: EJ: think that we should get at least a clear understanding the assertion itself...so write it down and maybe in a later stage we could formalize them in xml...

... so let start with some written statement and then we could try to formalize this



sdrees: I tend to agree with ernstjan, since we need fast results, and the impact on the core might be less intrusive then we think, because I strongly tend to rewrite the next version of the core in docbook, so a mixin of another markup language is more feasible then in word

juan carlos: JC proposes to go through the beginning of the core and try to write some assertions in free structured text as shown in the guidelines

AK: yes

 SD: yes

sdrees: Secondly an Assertion is a node, not an edge connecting. I.e. a bunch of assertions may lead to a complex graph to be build for testing all paths

sdrees: The openness of the core, is somehow often a profiling determined by the client, i.e. per se optional elemnts/attributes may turn into a lot of required ones, if the client decides to fill them in for the request.

sdrees: meaining REQUIRED/MUST be present in response for the server

sdrees: So a path of minimal assertions (from server side) will be with minimal optional attributes/elements in requests

juan carlos: EJ: AdES interop test....

juan carlos: JC provides details on XAdES interop events: there were a language for defining testcases....

....provision of details must be approved by ETSI and the authors as the material at the portal has IPR....

juan carlos: EJ: in the interopr of AdES profiles we could: 1. carry out verification of AdES signatures or 2. just assume that the AdES signatures are valid and concentrate only on the DSS AdES profile itself

juan carlos: AP: AK to circulate two or three examples of assertions based on his findings in the core

juan carlos: AP: JC to circulate again a former message including a proposal for scoping the core interoperability

juan carlos: AP: EJ to send an email to the list for launching the issue of how to deal with AdES signatures in the AdES profile and Verification Report profile interop

juan carlos: AP: JC to check with ETSI and the authors if the test cases definition language used for AdES interop events may be distributed to the members of this TC

juan carlos: 7. Plans for other topics in the charter

juan carlos: 7.1 Progress of existing committee drafts.

juan carlos: SD: Mary was requested to open the ballot on the visible signature...but not reacted yet...will ask again....

juan carlos: SD: on the comprehensive report, we do not have draft minutes, will try to re-ensamble them and submit to Mary....

sdrees1: Stefan volunteers to reverse engineer minutes

juan carlos: 7.2 Cross Matrix for Existing Profiles
skip

7.3 Next Version of DSS Core
skip

juan carlos: 8. Any other business


8.1 ETSI draft on PDF visible signatures
URL=http://www.oasis-open.org/apps/org/workgroup/dss-x/email/archives/201003/msg00018.html

 9. Next meeting
Proposal: 26-APR-2010

Approved



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