[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Further - Request for inclussion to the requirementsdocument
Trevor The term "Profile" is generally used for selecting options within an existing specification. What we are suggesting in b) is the extending of the elements defined in the Core with some additional elements. Then in c) We suggest that for a particular use case we select those elements relevant to a particular usage. Independent of the number of documents required do you agree with the clear difference between adding elemenets to the core and a profile. Also, the list you produce for the core is not exactly the same as we suggest. What is "XML Simple"? Also do you agree that the "signature Policy" (which already included in the requirements document) should be included in the CORE. Nick > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: 13 May 2003 00:06 > To: Juan Carlos Cruellas; dss@lists.oasis-open.org > Subject: Re: [dss] Further - Request for inclussion to the > requirementsdocument > > > At 07:10 PM 5/12/2003 +0200, Juan Carlos Cruellas wrote: > > >Trevor, > > > >Following the discussion on the roadmap and > >core/profiles, we would like to submit to your consideration the > >following: > > > >a) In the definition of the DSS protocols, we could work on > >a two-dimensional matrix, whose dimensions would be: > > > > 1. Sets of elements (attributes) to be included in the signatures and > >in consequence to be managed by the DSS request/response protocols. > >(XAdES, CMS and potential future documents would bring them into > >the scene). > > > > 2) Profiles associated WITH use cases. A profile selects specific > >elements relevant to the associated use case. > > > >b) The DSS protocol elements would then include: > > > > - Core DSS elements > > Basic Rq / Response Protocol > > W3C XML Signature > > Time-stamp and time mark elements > > XML requestor identity elements > > XML Signature Policy element > > (Note the above is inluded in parts of the requirements document) > > > > - Additional DSS element sets > > XAdES additional element set > > CMS additional element set > > > > > >c) The relevant DSS elements for a particular use case are > selected through > >a use case profile. Example use cases are as identified in the > DSS use case > >document. A few profiles may be defined by DSS group. Other would be > >defined externally by other communities (this would include a European > >Notary Profile - which was an unfortunate example as it has many issues > >outside DSS). > > > Juan Carlos and Nick, > > I think we agree on a lot, modulo some terminology. I suggested > we produce > 2 documents - > > Protocol and Core Elements: > - request/response protocol > - XML simple (but extensible) time-stamp and time-mark elements > - XML requestor identity element > > Protocol Bindings and Signature Profiles: > - XAdES XML-DSIG profile > - CMS profile > - Other profiles? > - Bindings (WS-Security? others?) > (http://lists.oasis-open.org/archives/dss/200305/msg00024.html) > > This seems mostly the same as your (b), but it makes the division into > documents explicit, and it uses the term "signature profile" for > something > like XAdES, instead of calling it an "element set". Would these 2 > documents address everything you mention in (b)? > > In your (c), you envision "use case profiles". It sounds like this would > further profile what I call a "signature profile" or what you call an > "element set" for a particular use case. I was hoping the "signature > profiles" would make it clear how to address all the various use cases > (i.e., they'd clarify how to identify the requestor, or attach a > time-stamp, within a particular signature format), so I'm not sure what > else would be in a "use case profile". Could you give examples? > > Trevor > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]