OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[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 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]