[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Further - Request for inclussion to the requirementsdocument
At 03:02 PM 5/13/2003 +0200, Juan Carlos Cruellas wrote: >I think that we should try to get a consensus on the roadmap defining >the scope of what we would like to produce and if possible on the terminology. > >As I see the messages going back and forward, I think that there is >quite a lot of common in both views as Trevor says. > >I would suggest then, based on Trevor's roadmap and on our proposal: > >1. Core Protocol. This would include to specify: > > - request/response protocol for getting and verifying signatures. > > - Format of the signature: XMLDSIG plus three elements: > - XML simple (but extensible) time-stamp and time-mark elements > - XML requestor identity element > -XAdES Signature Policy Identifier > >2. Extensions to the protocol for managing additional signature elements >(and here I propose to substitute the term "profile" and use the term >"extension" >as a way to try to overcome the problems that seem to be with that term). > -XAdES elements > -CMS elements > -Other parts of other specifications?. (the "bindings" that Trevor >mentions, and >that are not very clear for me.. perhaps you could explain Trevor?).. How do you think this should be broken into documents? I'd like to get to that level of concreteness. For our "normative" work, I was suggesting the things you mention in 1. (minus the Policy Identifier) be made into a "Protocol and Core Elements" doc: - request/response protocol - XML simple (but extensible) time-stamp and time-mark elements - XML requestor identity element I would call the latter 2 bullets "core elements" instead of part of the "core protocol". Then I was suggesting a "Signature Profiles and Protocol Bindings" doc that would include: - XAdES and CMS signature profiles. I think these are better viewed as "signature profiles" than just collections of elements, because if you're using XAdES there's a whole structure of where you put the signed/unsigned attributes that you have to use, so this is more than just a collection of elements that you can pick and choose from. - protocol bindings - these define how to use the request/response protocol messages over layers like WS-Security, or HTTP/TLS, or BEEP, or etc.. These layers have to provide transport, authentication, and confidentiality and integrity. Does this make sense? Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]